LoPy deep sleep mode ?

[robrush]

@fgaultier The three following function are not documented here

• machine.sleep()
• machine.deepsleep()
• machine.idle()

However, machine.idle() appears in network tutorials (called while device is not connected to WiFi). It's could be a copy/paste mistake from previous documentations (pyboard or ESP8266 doc).

I have the feeling that functions are defined but empty. You can call them without error but it does nothing.

I dealt with a WiPy 6 months ago and when you called deepsleep() , everything after this call was ignored until you woke up the WiPy with a special interrupt signal.

I also tried to measure the current consumption of my LoPy while using machine.idle(), I couldn't see any differences.

[Ralph]

@fgaultier The sleep modes on the ESP32 are indeed not implemented yet. It's high on our list to do, but we have to do it together with our friends at Espressif.
Idle should now be implemented though, on 1.4.0.b1, as mentioned here.

[danielm]

@Ralph do you have any time estimation for sleep modes implementation?

[Ralph]

@danielm I don't have a time estimation for that unfortunately. It's not entirely in our control. When we have more info, you'll hear about it on the forum.

[tfaure]

Hi,

I would like to used LoPy like a LoRaWAN sensor powered by battery (expected autonomous: several months). Everything works fine except the power consomption: I measured the current on Vin pin: 120mA (@3.5V) ! It is huge! In LoPy datasheet, the typical current value is 15mA in LoRa Tx/Rx and ~1uA in standby...

I try to disable Wlan, Server, Bluetooth and used machine.deepsleep() function but the current value is always 120mA... Do you have any tips to reduce current?

[mbbest]

I am also relying on this 'critical' feature that I see as a basic requirement for an iot device. I want to deploy inside a weatherproof container (plastic enclosure welded/glued shut) into a remote area - so physical access of the enclosure or access to the device itself is impossible unless I travel a long way and then 'break' into the container. Basic reliability and 'featured/specified/advertised' power consumption are my primary requirements. Looking forward to the 'sleep' and 'deepsleep' functions being realised. -(add) Just viewed other forum topics and am comforted by the post regarding timelines/tasks/Expressif dependant implementation of features. I assume you're all knee deep in pressure to get stuff done - but I am close to finishing the 'design' for a device that was to rely on these advertised specifications (semi manufactures often plaster "PRELIMINARY" on pre-production devices). I will soon be under pressure to produce my device - working and reliable - and indicating, on handover, that operation as initially arranged is not going to be achieved is not an option. Please consider those who rely on released specifications who try to create a solution for a client that demands compliance with agreed requirements. I currently appear to be several orders of magnitude out with my consumption requirements. Your consumption specs may be implemented 'soon' by a firmware upgrade - but they are currently wrong and misleading.

[Fred]

@danielm We're pushing Espressif again to ensure it is released in the IDF asap. We will come back very shortly with a timeframe. Thanks

[pform]

@Fred I have been looking across at the ESP32 forum and found this. Is this not what we/you are looking for?

[daniel]

@pform that's some of what we need, but last time we tested it, it was not working properly after enabling Bluetooth and WiFi (current was dropping but only to like 20mA). So, that's why we are waiting for the fix to switch off the radios promised by Espressif. Also, deep sleep does not have memory retention, which means that the application resumes from reset point.

Other than that we also need/want the light sleep modes which are a lot more flexible.

[blsmith]

I am reading ~10 mA draw when LoPy is in deepsleep. This seems high to me...

Has anyone else got a measurement for a reality check?

I am measuring while running on pure battery, in series with a battery lead. LiPo, currently charged and providing 3.96VDC.

I am also assuming (hard to really tell from this thread) that deepsleep is currently functional. If we are still waiting on a firmware update then please ignore.

[juriw]

@Fred We are also having issues with this in my team regarding deepsleep on Sipy running at 17mah. This is not good. Looking forward to an update.

[Fred]

@juriw Hi, I have asked Daniel to check latest and come back with some input. Thanks! Fred

[daniel]

@juriw @blsmith deepsleep current should be in the range of uA. Do you have anything else connected to the board or the GPIO pins? is the RGB LED off? Is the module mounted on the expansion board or on a custom PCB?

Cheers,
Daniel

[blsmith]

Just went back and doublechecked.

Nothing connected to LoPy.

RBGLED and board led are both off.

It is installed on the "official" expansion board.

Getting 10.1 mA passing through battery lead.

[daniel]

What if you place the LoPy on a bread board and measure via the battery lead powering via 5V?

Can you also power the LoPy directly on the 3V3 pins (with a regulated 3V3 supply) and measure again? Thanks

Cheers,
Daniel

[juriw]

Hi, @daniel we have just tested SiPy without anything attached to it, with 5V input and deepsleep still pull 14.7mAh. That is unacceptable.
The IoT product we are developing on your platform is taking our calculations for battery lifetime from around +7 years down to a couple of days. It seems useless at the moment.

We tested the energy consumption with the following code

import machine
import time

while(True):
   
   print("Starting Deepsleep")
   machine.deepsleep(10000)
   print("Deepsleep ended")
   time.sleep(10)

[swohl]

I can confirm that in my case as well the Lopy in deepsleep mode is pulling ~10mAh while in the expansion board . Also the expansion board seems to pull ~140uAh with the Lopy unplugged. Could this be a result of the quiescent current of the BQ24040?

With the lopy not in the expansion board it seems to be pulling ~5.5mAh. It is an improvement, but still orders out from the specification.

I have a real world main.py running, so the lora, wifi and the adc are turned on while not in deepsleep, but when in deepsleep I assumed these peripherals would go into standby or be turned off.

For my application the current battery consumption renders the device well outside what could be deemed usable or practical to prototype with. Hopefully I am doing something terribly wrong, or this could be fixed in a firmware update.

[daniel]

Hello,

We know this is very important so we are working on sorting out this deep sleep current issue ASAP. We'll come back with feedback shortly.

Cheers,
Daniel

[juriw]

@daniel Sounds good! We are really looking forward to this. We are doing a master thesis that is currently not working and we need to get our devices out asap :)

[juriw]

Hi @daniel Any news? We need to get our prototype out next week.