Wipy3 Low power modes

[alvaroav]

Dear all,

I have spent few days to check and test the different options for Wipy3 with the wipy expansion board related to Low power modes with WiFi connection ON as station.
I connect the expasion module to a USB with a USB Volt/current meter with real time measurement

Based on machine methods, I found:

1. machine.deepsleep([time_ms]) --> Very low power achieved, BUT once the device is awake, the device is reseted, and therefore must reconnect to wifi (some time to do it), and program variables reinitialized.

2. machine.idle() --> At the beginning I found 2 main problems:
   2.a machine.idle() just awake without any control, I read somewhere that it is an internal clock at 1ms cycle which awake from this mode. To avoid continuing with the program flow, I build a Clock alarm (https://docs.pycom.io/tutorials/all/timers.html), and I set up a flag, keeping the flag ON for 10 seconds, and shifting to 0 after this time. Therefore, I placed the machine.idle() within a while(clock_flag) loop. This way I am able to re-enter in machine.idle() mode up to the clock_flag shift.
   2.b However, the measured power with e WLAN.STA was similar to the power comsuption out of the machine.idle() aprox ~ 80 mA. Looking into the docs, I found this (https://docs.pycom.io/firmwareapi/pycom/network/wlan.html):
   wlan.init(mode, * , ssid=None, auth=None, channel=1, antenna=None, power_save=False, hidden=False)
   but withou details on the "power_save" properties. I play a bit just starting the wifi with power_save=True, and I found that when I go to machine.idle() loop, now the power is reduced to roughly 10-20 mA, AND most important, when it is out of the machine.idle() loop the wlan connection is alive, and therefore I do not need to reconnect to the wifi, just being able to send/receive data! and all variables avialable as previously to the idle status! No reset on the board done.

3. machine.sleep() --> result, NO low power achievements

This is the summary, which I hope might help people to understand low power modes a bit. There is not too many info available, and some of them is out dated. Moreover, there are some old manuals from Adafruit related to the wipy with older libraries (wipy instead of pycom) or not implemented functions (like the RTC alarm, when for wipy3 the RTC is just a clock without alarm or interrupt capabilities), which lead to confusion.

The last remaining open topic which I might need some help from the forum, is the one related to the behaviour of the machine.idle() method.
I is anyway to set-up the wakeup interruption? something like machine.idle(10000) for 10 seconds, or which inner timer alarm is latched to this function?

Thanks for your help!

[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.

[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

[alvaroav]

Hi @robert-hh

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

[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]

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]

@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.

[rcolistete]

@robert-hh Edit to explain that the test was on 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]

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.

[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.

[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.