• LoPy4 deepsleep gives guru meditation error

    LoPy deepsleep
    1
    0 Votes
    1 Posts
    33 Views
    No one has replied
  • 0 Votes
    2 Posts
    43 Views
    G
    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
  • 0 Votes
    4 Posts
    50 Views
    J
    @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
  • 18s wakeup time from deepsleep

    GPy gpy deepsleep
    2
    0 Votes
    2 Posts
    226 Views
    robert-hhR
    @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).
  • 0 Votes
    2 Posts
    222 Views
    T
    You could look for NVRAM here: https://docs.pycom.io/firmwareapi/pycom/pycom.html
  • 0 Votes
    3 Posts
    278 Views
    philwilkinsonP
    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)
  • Proper way to deepsleep....

    LoPy deepsleep
    16
    1 Votes
    16 Posts
    1k Views
    John BairdJ
    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.
  • board and pycom deep sleep

    Expansion Board lopy4 deepsleep
    8
    1 Votes
    8 Posts
    571 Views
    M
    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..
  • 0 Votes
    2 Posts
    176 Views
    P
    @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)
  • Deep Sleep Not Waking Up

    FiPy fipy pycom deepsleep deep sleep
    12
    0 Votes
    12 Posts
    1k Views
    S
    @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.
  • Sleep Mode Description

    Discussion deepsleep
    7
    0 Votes
    7 Posts
    797 Views
    P
    @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.
  • 0 Votes
    2 Posts
    362 Views
    F
    @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
  • 1 Votes
    6 Posts
    807 Views
    S
    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.
  • object has no attribute 'pin_deepsleep_wakeup

    FiPy fipy pytrack deepsleep wakeup
    2
    0 Votes
    2 Posts
    420 Views
    S
    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()
  • deepsleep pulse counting

    GPy deepsleep gpy nvram amr
    2
    0 Votes
    2 Posts
    379 Views
    P
    Hi Drop an email to sales@pycom.io with the details :)
  • boot.py reliability

    GPy gpy boot.py deepsleep
    30
    0 Votes
    30 Posts
    4k Views
    A
    @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)
  • deepsleep & memory

    GPy rtc memory gpy deepsleep flash
    3
    0 Votes
    3 Posts
    639 Views
    rcolisteteR
    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.
  • 0 Votes
    8 Posts
    1k Views
    J
    @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.
  • The 4s blue flash blues

    GPy main.py gpy deepsleep
    8
    0 Votes
    8 Posts
    757 Views
    K
    @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!
  • 0 Votes
    14 Posts
    1k Views
    A
    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