@jcaron So you get a curve that varies during the whole awake time between 30 and over 100 mA. Ah I see. I think I confused myself when I saw the LoRa transmit in the documentation of 105mA and thought it was somehow the overall current draw of the awake time because it was similar to the 100mA you had mentioned before but I get it now. So the current draw is about 100mA (conservative) on average over the awake time. You've been a really great help. Thanks for all your patience :)

Thank You

@crumble : do you have more information on this failure mode or found a work around? I think I have been bothered by something similar, See this post: Fipy does not always wake from deepsleep: My Fipy does not wake once in a while, and can only be recovered by pressing the reset button or power cycling the module. I can always wake it. Either by a reset from deepsleep or by Watchdog timer. It might be that in the case of the watchdog timer wakeup it is not deepsleep, and when it is in deepsleep it does not wake by the WDT. That would explain all the behaviour I observe. Needless to say is that I need it to go to deepsleep always for battery life reasons.

@edward-dimmack said in Storing variables in between deepsleep: @elizar Do you mean to a file on an SD card? Because we are not using an SD card in this application. You can use the filesystem of the internal flashl. Your program files are stored there as well. But mind the wear. Depending on your task, the NVRAM shall be the better solution.

Dear @martijnthe, we have been able to successfully get the boot time of our Terkin-Datalogger [1] from about 25 seconds down to about 3 seconds by freezing the modules like outlined by @robert-hh. The code base including all third-party modules is around 10 kLOC and we have released the result as builds called Annapurna [2]. With kind regards, Andreas. [1] https://github.com/hiveeyes/terkin-datalogger [2] https://community.hiveeyes.org/t/annapurna-firmware-for-pycom-esp32/2754

@rcolistete I did. And here is the result : https://forum.pycom.io/topic/4153/sipy-pytrack-deepsleep-and-power-consumption-problem Can you help me?

Nevermind. It works now. The correct function is: lora.nvram_save() and lora.nvram_restore()

@alexpul said in Turn GPS back on after pytrack.go_to_sleep(gps=False): I am using pytrack.go_to_sleep(gps=False) in the lib/pycoproc.py define your own funcion: def gps_state(self, gps=True): # enable or disable back-up power to the GPS receiver if gps: self.set_bits_in_memory(PORTC_ADDR, 1 << 7) else: self.mask_bits_in_memory(PORTC_ADDR, ~(1 << 7)) easiest way is for you to search for "def go_to_sleep(self, gps=True)" in the file, and place your custom function above or below it :-) ... and then you can execute it (Turn on): pytrack.gps_state() and (Turn off): pytrack.gps_state(gps=False) good luck 👍🏻

@averri said in High current consumption in deep sleep: 80 mA: OSError: the requested operation failed We just mitigated this through [1] by invoking lte.deinit() with the "reset" operation like lte.deinit(detach=False, reset=True) [1] https://github.com/hiveeyes/hiveeyes-micropython-firmware/commit/ec7c80e1219fb119c2881a0019cecdfad220f29f

@gda45-78 Hi, don't you have loaded a back WLAN process on the board that consume too much ? (see your post 3 months ago in your profile). regards.

I have summarized my current understanding of the various was to enter sleep mode in this post. The general idea though is that sleep allows the board to still run (but with reduced power) and it does not reset when you exit sleep. Deep sleep resets the board (will not execute any code after the deep sleep command and will reboot and run boot.py and main.py)

Hi, Have you fix it? I'm facing the same problem

@StijnK setup_sleep() is a function contained in the pycoproc.py library, and according to its code the maximum value is 2^24 - 1. So the maximum sleep time you could set is 16777215 seconds, which is about 4660 hours (more than six months). Here is the code of pycoproc.py in Github: https://github.com/pycom/pycom-libraries/blob/f848adcfb937e7b7bbc5f78db95840fa26dabe11/pybytes/pysense/lib/pycoproc.py#L24

@tuftec In fact, lorawan callback in the network operator that i have used (objenious and orange) doesn't allow dynamic downlink data setup via callback service. I have to prepare the downlink data and when (even several hours/day later) the device send an uplink message the downlink data is send to the device. So, if you know the periodicity of your uplink frame you can predict the time to send to your device on his next uplink frame and set your operator downlink frame in advance. With Sigfox, when the device send an uplink frame with download request bit (by device choice) set, there 2 choices -default call back method can send back to the device network time and some static data -you have 20 secondes to send back from your device (from your own callback service) some data and time. With NB-IOT , network time availability is not mandatory so it depend of your network provider.