I’m looking to incorporate Xbee3 LTE-M as a backup communications path in a [product that currently uses copper ethernet. It’s generally a low-density (1 packet every few minutes) using XML-wrapped data in a single UDP packet, typically on the order of 300 bytes. It then would expect a return ACK, similarly wrapped, about 100 bytes. At the most, it might have to send a couple of dozen messages over a dozen seconds or so.
In the current usage, there’s no connection (no sockets), everything is done with simple UDP packet exchange. There may be hundreds of these devices, each signalling asynchronously to a single host, and all expecting ACKS in a timely fashion (a couple of seconds, typically).
It’s not clear to me from what I have read of the tecnical support documents that this is possible with this device. I see mention of a “udp” socket that needs to be established and maintained, and it’s not clear that this is workable. I can’t keep these devices connected when they’re not sending data or receiving ack’s. The current copper-based protocol is send the packet, wait for ACK, send next packet or, most of the time, sit there silently.
Is what I am looking for possible in the Xbee3 LTE-M?
UDP is of course connection-less so there is not need to establish or maintain a connection with a host ever, including on the XBee3.
Using UDP does consume an internal socket resource in the XBee. Those internal resources are limited so that is what is documented to avoid issues. For the most part management of these internal resources is automatic and you would not be expected to explicitly track the lifecycle of them.
It sounds to me that each of your devices would transmit to a single destination. That means that you could easily satisfy your use-case with either transparent mode or API mode. In transparent mode you would define your remote host as the destination of any data that you put on the serial interface and the XBee would encapsulate that send it off. In API mode you would use the API frame format to create TX frames, and would need to process RX frames but would have the flexibility to target and identify multiple remote hosts.
It’s connectionless, but you still do have to call socket.connect() to establish the destination address, don’t you? That’s the way it works in BSD sockets - you either connect() or you use sendto() (and the documentation says sendto() is not supported in Xbee micropython). It’s still not completely clear to me how UDP sending is supported from micropython. Is there an example of sending a UDP frame on an Xbee3 LTE module?
sa = socket.getaddrinfo(‘50.19.87.121’,5683)
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.connect(sa[0][-1])