Wipy3 Low power modes

[jcaron]

@alvaroav Note that power draw through USB is usually higher than via the battery connector, you may want to try that.

The expansion board may also draw a bit for the PIC, though I have no idea how much it uses. If you use an SD card, that's a bit more power used still.

Good catch on power_save + machine.idle in a loop, 10-20 mA with the ESP32 not in deep sleep is pretty nice. Not sure if you'll be able to reduce that a lot more as things stand.

Note that officially (per ESP32 docs), light sleep is not compatible with maintaining WiFi connections, though there is an "automatic light sleep" feature that should help. No idea if that is implemented in the Pycom firmware.

[alvaroav]

@jcaron you are rigth, but I was just comparing the best performance algorithm with the wipy and WLAN ON.
Now, this can be decreased also with the battery instead of the USB, and also playing around with the deepsleep and idle.

Hopefully soon pycom will also implement the ESP lightsleep feature, just to avoid the reset of the program after a deepsleep.

[rcolistete]

Light sleep is available since Pycom firmware v1.19.0.b1 :
Light sleep (firmware >= 1.19)
It* consumes 3.5 mA (I think it is with WiFi off, but I don't remember) and takes 16 ms to wake up.
EDIT : (*) means LoPy4.

[robert-hh]

@rcolistete Just tried that on a FiPy. It is machine.sleep([ms_off])
The current of the module decreases from ~110 mA first to about 20 mA, and then after a few seconds to ~1mA. When waking up, the current settles at 20-30 mA and WiFi is still off. So you have to enable it again if required.
Funny enough, sometimes that does not work. After the command machine.sleep(), the current sticks at 50mA.

[rcolistete]

@robert-hh Edit to explain that the test was on LoPy4.

[robert-hh]

@rcolistete I tried the same on a WiPy3 and LoPy4. The difference: both reduce the current immediately. What I found interesting is the relative low current consumption (~20 mA) once WiFi is off.

[alvaroav]

Dear @rcolistete

Thanks for your reply!
I dind't noticed this update in the development version. As I told in my first message, the documents for modules and so on are all mixed, old with newer versions, beign not so easy to handle everything.

Fortunately the forum works almost perfect, and with people like you helping others, is more easy to progrees.

I have spend some time on the lightsleep function(your link lead to a post with old links, this is the new one I found):

lightsleep function: machine.sleep([time_ms], resume_wifi_ble)

I place the machine.sleep(10000, True) within my while loop, and I got some unexpected results.
For the first run, the function worked as expected, the wipy slept for 10 seconds, it woke up, automatically reconnected to the Wifi, do some stuff with UDP sockets, and went back to the beginning of the loop with a new machine.sleep(10000, True)
Unfortunately for the 2nd run, it raised an Errno 118 EHOSTUNREACH.
I found that this error come from an incorrect net connection. I solved it just placing a ConnectToWlan() routine just after waking up [ConnectToWlan() is my routine to perform wlan.init+wlan,ifconfig+wlan.connect... which jwas just intended for the start up, NOT for waking up from a lightsleep)

Therefore, it seems that the True value for resume_wifi_ble (boolean value that enables or disable restoring after wakeup any WiFi or BLE connection that was interrupted by light sleep) just works once!! and for a second or succesive run is not working.

Can someone check with their own wipys?

Thanks and BR

PS: Once I fully check the lightsleep mode I will edit the first message to include this new mode.

[robert-hh]

@alvaroav said in Wipy3 Low power modes:

Therefore, it seems that the True value for resume_wifi_ble (boolean value that enables or disable restoring after wakeup any WiFi or BLE connection that was interrupted by light sleep) just works once!! and for a second or successive run is not working.

Confirmed on a WiPy3. V1.20.0.RC6

[alvaroav]

Hi @robert-hh

Thanks!
I understand from your message that you confirmed the bug.
I will acknowledge pycom guys.

[ChangedDaily]

@robert-hh Hi, I have just found the machine.sleep function and thought it looked like what I needed (boot time from deepsleep is way too long when you want to advertise Bluetooth for 100ms out of every 1 second). I have programmed Firmware Release Candidate v1.20.0.rc7 but on first resume from sleep I get "ASSERT_PARAM(512 0), in rwble.c at line 230". I must admit I can't find this file to investigate further.
I have tried de-initialising Bluetooth before sleep, re-initialising after but can't get it to work. Is there a workaround or will it be fixed soon?

Thanks

[robert-hh]

@changeddaily said in Wipy3 Low power modes:

rwble.c

Sorry, I cannto find the file either. It is only referenced in the libraries.