Deep sleep and pending network output

[tshead]

Gang:

I’ve got a WiPy 2.0 and PySense, sending sensor readings to a UDP socket before entering deep sleep. Everything works fine, so long as I put a call to time.sleep() between the calls to socket.sendto() and machine.deepsleep(). Without it, the receiving end never receives anything. I assume that deep sleep is shutting-down the radio before the packet has been transmitted? Is there a way to do a synchronous send on a socket that doesn’t return until the data is well-and-truly sent? The time.sleep() workaround is unsatisfying, since the correct duration is indeterminate.

Thanks in advance,
Tim

[jcaron]

@tshead have you tried setting to socket to blocking?

[tshead]

@jcaron - thanks for the quick response. Calling socket.setblocking(True) does not eliminate the need for a sleep() before deepsleep(). On some level this makes sense to me because I assume that under the hood the WiPy network stack is off handling sends and receives in a separate thread. If there isn’t API to know when then radio is finished sending, it would be useful to have some sort of official best practices / rule of thumb on how to wait (is machine.idle() better than time.sleep()?) and for how long.

Cheers,
Tim

[daniel]

@tshead we'll have a loot to see how this can be improved, but the best practice would be to wait for a reply from the other side confirming the reception of the packet before calling machine.deepsleep(). In your tests, what value do you have to pass to time.sleep() in order to make it work?

Cheers,
Daniel

[ssmith]

@daniel This is an issue I've seen in various places. Is there a flag that can be checked to know when this has completed? Random delay loops are very dangerous and usually come back to bite you.

[daniel]

@ssmith we'll check if there's a flag that we can add and check. I don't recommend random delay loops but instead adding a response from the other end to the protocol confirming that the packet was received.

[tshead]

@daniel - Fair enough, I’ll think about switching from UDP to TCP (or BLE). I haven’t explored the sleep duration thoroughly, it’s set to 100ms at the moment, which has been reliable enough for my purposes.

Presumably this would be an issue for any networking stack on any machine, but we don’t think about it because we aren’t focused on putting a workstation to sleep immediately following a sendto().

Many thanks,
Tim