Depending on which hardware version of the Pysense you're using, you should load the correct pycoproc file. You can find the latest versions of the file here: https://github.com/pycom/pycom-libraries/tree/master/shields/lib pycoproc_2.py is for Pysense v2.0 X, where pycoproc_1.py is for Pysense 1. This also changes the initialisation argument. For Pysense 1, you should put py = Pycoproc(Pycoproc.PYSENSE), whereas Pycoproc 2 does not require an argument To get a working example, you can load one of the zip files from here: https://github.com/pycom/pycom-libraries/releases/tag/v2.0.0 for the correct board version

@d-alvrzx the ESP32 has various sleep modes with various possibilities for wake up sources. The lowest power modes are indeed quite limited by design. IIRC the Pycom firmware uses ext1 wake up. You’ll find details of the different wake up sources of the ESP32 in the ESP IDF docs: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/system/sleep_modes.html

@kjm The Pycom devices need between 1-2 seconds to start up. There is some analysis of that in the forum, based on the supply current analysis. LTE devices are slower than e.g. the WiPy. I do not know what's in your main.py script. But that one may take some time. LTE.attach() from power on for instance takes at my place 15 seconds and more. P.S.: Your formula above looks a little bit strange, because in the statement: sleep=600-diff you mix physical units. The unit of 600 is implicitly s (seconds), the unit of diff is ms (milliseconds).

You could look for NVRAM here: https://docs.pycom.io/firmwareapi/pycom/pycom.html

thanks for the response @jcaron. Unfortunately all the methods you suggest only work on the expansion board types, not the deepsleep shield. The only way I can see to do this is to use an exception handler. Not very pythonic, but it does work. import deepsleep ds = deepsleep.DeepSleep() try: ds.get_wake_status() shield = True except: shield = False print(shield)

Wow! Thanks for the followup on this @PeterB, that looks great. I'm glad the idea works, though concerned by the issues you are still having. I appreciate the code sample and will be integrating it soon. If I learn anything more, I'll pass it along.

I have noticed that upon wake up, that *.py files randomly get errors but when i reset its fine. Didn't know I had to do machine.deepsleep first to close down OS! I really enjoy the pycom ecosystem BUT the effort should be on a robust OS and not extra hardware. This will bite them...Reliability always win in the long term..

@kjm This is indeed a major issue in debugging when using deepsleep. As soon as the system goes to sleep the USB connection and WiFi connection are gone. You then have to reconnect manuually first. As you describe, Atom is then also a major issue as the butons disappear and it thinks it is not fully connected while it is. This makes checking the functionality of a program using sleep very difficult. The only solution I found is using blinking LEDs of several colors to communicate with me the debugger. I am also busy with a logger which writes the state of the program to a file for later inspection. def blink(color, counts, intensity=0x1f, speed=0.5): colors = { "red": 0xFF0000, "green": 0x00FF00, "blue": 0x0000FF, "yellow": 0xFFFF00 } pycom.rgbled(0x000000) for i in range(counts): col = colors.get(color, 0xFFFFFF) col = int(col * intensity / 255.0) pycom.rgbled(col) time.sleep(speed) pycom.rgbled(0) # off time.sleep(speed) def blink_long(color): pycom.rgbled(color) time.sleep(4) pycom.rgbled(0)

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

@jcaron said in Sleep Mode Description: @paul-thornton To be precise, it actually starts from the top of boot.py :-) While you're in the docs, I don't think the read_battery_voltage method for the Pysense/Pytrack/etc. is in the docs, you may want to add that as well. Thanks ill get this added today if its missing.

@Giorgio Did you find out how? I have the same problem here, using a gPy+Expansion Board V3.1. I can't find a way to put the board in deepsleep mode. It is currently using 14mA. I can only find documentation for Pysense/Pytrack/DSboard, etc.. but nothing for the Expansion Board!? :\ Where's the info I am missing? Fakstory

I actually gave up on the FiPy for not getting this sorted out. The problem is not in the use of a GPIO to wake the board. The problem is in entering or exiting the deepsleep mode. Now reading some more in the forum I found one reference to sometinh that might be related to the issue that I experienced: @crumble said in Deep Sleep Not Waking Up: @jcaron said in Deep Sleep Not Waking Up: Also, remember that machine.deepsleep never returns. Depends :) If it behaves like the pytrack, it may never go to sleep and never increase the program counter. I assume a catched i2c issue in combination with the pytrack. If the OP has a USB volt meter, he can simply verify this. If it still draws a lot of power, it does not sleep and can therefore never wake up. The software watchdog is able to get it out of this state. On my system it is not easy to reproduce. It may need a few hundred deepsleeps before this error occurs.

Found a start of an answer here: https://forum.pycom.io/topic/3624/machine-pin_deepsleep_wakeup-function-is-not-working-in-lopy4-firmware-version-1-19-0-b2 Link to developemtn documentation on github: https://github.com/pycom/pycom-documentation/tree/development_release/firmwareapi/pycom/machine The method is renamed to pin_sleep_wakeup()

Hi Drop an email to sales@pycom.io with the details :)

@robert-hh Thanks for the reply! So basically an unstable power supply can lead to flash errors. Good to know. (And you had it, I was using a Li-Ion 3.6V battery. I'll make sure to mention that next time)

From the pycom module documentation : "pycom.nvs_erase_all() Erase the entire NVRAM memory area." AFAIK, there is no way to see all of the contents of nvram on ESP32/Pycom boards.

@devinv it takes a while for a GPS chip to get a fix. You definitely won’t get a position right after wake up, the chip needs to receive ephemeris data, lock onto satellites, compute a position... This has been discussed several times in the forum, search for the relevant topics for details.

@reidfo No I've got everything in try/except loops so it can't crash. This is always when it wakes from deepsleep, instead of running boot or main .py it jumps into dreaded 4s blue flash mode. Grim!

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