Network/ESPNow lightsleep() interaction issue found and resolved

[mmliam]

I have an application that uses ESPNow to send to a receiver, then go into lightsleep(5000) for 5 seconds of low current draw. Initially every thing was working well. Then I made a slight code alteration; and even though lightsleep(5000) did delay for 5 seconds it was still drawing full current.

In both cases, just before lightsleep() I turned off the network station eNet_STA.active(False). In the case where it worked, and drew low current there was an "if" statement, between eNet_STA.active(False) and the lightsleep(). In the case where it failed (drew full current) I had removed the "if" statement so the lightsleep() immediately followed eNet_STA.active(False).

The only way to get it to function correctly again was to place a sleep_ms(1) after the eNet_STA.active(False).

eNet_STA.active(False)
sleep_ms(1)
lightsleep(5000)

My hypothesis is even though the eNet_STA.active(False) was executed the transmitter was still in the process of shutting down, and when immediately followed by lightsleep() the transmitter shutdown was suspended, and did not complete until after returning from lightsleep().
In the original code that worked the "if" statement provided sufficient delay for the transmitter to shutdown prior to the lightsleep().
Anyone have similar experiences or comments?

[davefes]

In the one place where I put a remote into lightsleep using ESPNow I see I had a wdt.feed() between the two lines. And not because I thought that I may have had a problem.

[glenn20]

Warning: incorrect statements (see reply below).
WLAN.active(True/False) (and WLAN.connect()/disconnect()) return after making the request for the action. You have to wait to confirm the action is complete if you want to be sure (this is frequently overlooked), eg.:

eNet_STA.active(False)
while eNet_STA.active():
    time.sleep_ms(50)
lightsleep(5000)

Of course, just inserting a long enough sleep (as you did above) will also work.

(Caveat: I haven't tested that this code works in all cases, but based on how the code works, I expect it should resolve the problem).

[davefes]

What about "standard" Micropython ESP32 connect and disconnect? Maybe explains why I had to "throw" 1 second sleeps in my connect routines. Where is this documented? Or should one just know this when dealing with WiFi?

[glenn20]

Yes, you should always do:

sta.connect(ssid="", key="")
while not sta.isconnected():
    time.sleep_ms(100)

if you want to wait until the connection is successful and complete before moving on (or some other more complex logic if you want to handle continued failures to connect). There is an example at the top of https://docs.micropython.org/en/latest/library/network.html.

[davefes]

OK, all my connects do follow that strategy for the last year or more. I have not been as careful with disconnects and sta.active(False). I have just about transitioned all my Wifi to wifi.py then those problems will completely disappear :)

[glenn20]

Apologies - everything I said about WLAN.active(True/False) is wrong (I just checked). Apologies for the misleading statements. @mmliam it appears the best fix is exactly what you suggested. I will do a little more testing to see if I can see what is happening and if there is a more deterministic solution.
However - what I said about connect()/disconnect() is correct ;).

[mmliam]

As for the connect() I do check for connection in a loop.

I did find another timing issue regarding lightsleep()
For the code:

from machine import lightsleep
lightsleep()

I followed it with an instruction that put the module into hibernation, normally it should have reduced the current draw to 35ua, but it only reduced to 3.5ma.
I moved the import statement to the top of the code, then the current dropped to 35ua. Apparently, there is some interaction where the import is incomplete prior to the lightsleep().

UPDATE: I believe I solved the 3.5ma issue. It appears to have been the way I was driving certain external hardware that caused the issue, not the placement of the import statement (although that did indirectly affect the hardware drive).

Looking forward to whether Glenn can find "a more deterministic solution" to the delay in initiating a shutdown of the transmitter, and it actually completing.