Home/Support/Support Forum/Async transmit from MicroPython

Async transmit from MicroPython

0 votes
The xbee.transmit() function appears to only be blocking. Is there a way to transmit a message asynchronously from MicroPython? In other words, issue the transmit() then check another function for the result later. Surprisingly, the receive() function is non-blocking.

This seems like a major omission as it means that the MicroPython script can't transmit a message if it has any time sensitive activity it handles (e.g. flashing an LED).

asked 6 days ago in MicroPython by RossJ New to the Community (17 points)

Please log in or register to answer this question.

3 Answers

0 votes
Yes you just need to put it in a different loop if I recall.
answered 4 days ago by mvut Veteran of the Digi Community (12,786 points)
I'm not sure I understand your response. Does MicroPython have intrinsic multi-threading or concurrency? If not, what do you mean by 'different loop'? I already employ cooperative multitasking but even that falls down if just one task is blocking (such as transmit).

I didn't mention that I'm working with XBee3 (ZigBee firmware).

Cheers, Ross
0 votes
You are correct, the transmit() method currently blocks so it can generate errors if the module is unable to transmit for some reason.

If you were requesting asynchronous transmit as a feature, what sort of API would you expect? How would you check whether the transmission was still pending, had completed, or had erred out?
answered 3 days ago by TomCollins Veteran of the Digi Community (1,833 points)
0 votes
Hi Tom,

The usual way this situation is dealt with is to have the transmit function return a 'future' (object) immediately, rather than blocking and returning the final result. The future object can have functions which return the final result in a blocking manner (like currently) or non-blocking manner which can be polled by the application.

Importantly, the reason I have raised this issue is simply that blocking on an unsuccessful transmit (esp. to a sleeping end device, which could take quite some time), is really not great when any kind of user interface is also being managed. For example, simply flashing an LED should be simple but can't be done properly if a message must be transmitted from time to time.

There are other consequences to the transmit call blocking... WDT for example continues running during transmit and can trip if its timeout isn't made longer than the transmit timeout (which could be very long for a sleeping end device).

Cheers, Ross
answered 3 days ago by RossJ New to the Community (17 points)