Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Implement deep sleep between readings #2

Closed
amotl opened this issue Jun 7, 2019 · 12 comments
Closed

Implement deep sleep between readings #2

amotl opened this issue Jun 7, 2019 · 12 comments

Comments

@amotl
Copy link
Member

amotl commented Jun 7, 2019 •
edited
Loading

People have been asking [1,2] for Deep Sleep on FiPy. While @einsiedlerkrebs and others [3] tried already,

I have tried deep sleep, but without success. Tried 1s sleep but device didn't wake up.

I have to admit that I did not do any debugging on this yet.
see: hiveeyes/hiveeyes-micropython-firmware@191a46b

it looks like it would be harder than expected. As usual, the devil might just be in the details.

We will try to dedicate some time to that exceptionally important detail.

[1] https://community.hiveeyes.org/t/bob-platine-im-lipo-betrieb-ohne-deep-sleep/2055
[2] Hiverize/FiPy#2
[3] pycom/pycom-libraries#26
@amotl
Copy link
Member Author

amotl commented Jun 7, 2019

Please recognize there's also the Deep Sleep Shield [1-4]. However, while Pycom and Espressif might have had their times [5-7], the devices might now be ready [8] to eventually feature the promised ultra low power operation (~1uA in deep sleep) [9], even when using only the RTC module for implementing Deep Sleep.

[1] https://docs.pycom.io/datasheets/boards/deepsleep/
[2] https://docs.pycom.io/.gitbook/assets/deepsleep-schematic.pdf
[3] https://media.digikey.com/pdf/Data%20Sheets/Pycom%20PDFs/Deep_Sleep_Shield_Web.pdf
[4] https://forum.pycom.io/topic/3977/power-supply-issue-by-vin-on-sipy-deep-sleep-shield

[5] https://forum.pycom.io/topic/543/lopy-deep-sleep-mode
[6] https://forum.pycom.io/topic/1022/root-causes-of-high-deep-sleep-current-lopy1-wipy2-and-sipy-all-the-new-modules-do-not-have-deepsleep-issues
[7] https://forum.pycom.io/topic/989/pycom-oem-modules-are-here-4-mbytes-of-ram-and-deep-sleep-test
[8] https://pycom.io/l01-oem-module-deep-sleep-test/
[9] https://www.kickstarter.com/projects/pycom/fipy-the-worlds-first-5-network-iot-dev-board

@amotl
Copy link
Member Author

amotl commented Jun 7, 2019 •
edited
Loading

Please recognize there's also the Deep Sleep Shield.

After some quick research, it appears to us that the Deep Sleep API documentation @ClemensGruber was referencing the other day is solely suitable for talking to the Deep Sleep Shield. On the other hand, another part of the documentation just called Sleep tells us that the respective routines for controlling sleep mode there would be embedded into the Pytrack and Pysense libraries.

So, as the native MicroPython's machine.deepsleep will probably not be available on the ESP32-based Pycom platform, we should nevertheless bring in the use of pycoproc.py in order to see what we can get from that running on a bare FiPy module without any of the Deep Sleep Shield or Pysense or Pytrack extension boards.

the devices might now be ready [8]

[8] https://pycom.io/l01-oem-module-deep-sleep-test/

Please also recognize Pycom is only talking about the WiPy and LoPy OEM modules in this video.

@amotl
Copy link
Member Author

amotl commented Jun 7, 2019 •
edited
Loading

as the native MicroPython's machine.deepsleep will probably not be available on the ESP32-based Pycom platform

However, they actually are using machine.deepsleep() in this video.

image

So, we will turn away from our last argument about favoring pycoproc.py and will try the vanilla way first, still not being sure whether this will actually work with our current hardware configuration.

@ClemensGruber
Copy link
Contributor

The PyCom deep sleep shield is only necessary for older WiPy / LoPy devices! It was necessary due to a hardware bug and was a workaround to get this older boards in a power saving operation mode!

It is NOT necessary for the current WiPy, LoPy or FiPy version!! See https://forum.pycom.io/topic/1022/root-causes-of-high-deep-sleep-current-lopy1-wipy2-and-sipy-all-the-new-modules-do-not-have-deepsleep-issues/88

@ClemensGruber
Copy link
Contributor

Ok, the "DeepSleep library" is for the deep sleep shield only as @amotl mentioned! I found this remark for the new boards:

The WiPy3 has its own deep sleep functionality, which is part of the machine module https://docs.pycom.io/chapter/firmwareapi/pycom/machine/

Link is outdated, current is https://docs.pycom.io/firmwareapi/pycom/machine/ and here you can find

machine.deepsleep([time_ms])

Stops the CPU and all peripherals, including the networking interfaces (except for LTE). Execution is resumed from the main script, just as with a reset. If a value in milliseconds is given then the device will wake up after that period of time, otherwise it will remain in deep sleep until the reset button is pressed.

The products with LTE connectivity (FiPy, GPy, G01), require the LTE radio to be disabled separately via the LTE class before entering deepsleep. This is required due to the LTE radio being powered independently and allowing use cases which require the system to be taken out from deepsleep by an event from the LTE network (data or SMS received for instance).

amotl added a commit that referenced this issue Jun 7, 2019
@amotl
Add deep sleep, see #2
3e73a3f
@amotl
Copy link
Member Author

amotl commented Jun 7, 2019 •
edited
Loading

Introduction

With one of the recent commits 3e73a3f, the Hiveeyes MicroPython Datalogger Firmware should support deep sleep.

Screenshot

It looks like this guy is sleeping well

...
27.5273 [terkin.datalogger        ] INFO   : Telemetry status: SUCCESS
27.7685 [terkin.datalogger        ] INFO   : Entering deep sleep for 5.0 seconds

and even wakes up again.

4.7042 [terkin.datalogger         ] INFO   : Reset cause and wakeup reason: {'reset_cause': {'code': 3, 'message': 'DEEPSLEEP'}, 'wakeup_reason': {'code': 2, 'message': 'RTC'}}

Please note

that

  • we upgraded to the most recent Pycom MicroPython 1.20.0.rc11 firmware with no effort [1] to stay up to date.
  • we switched from FatFS to LittleFS with no effort [2] to stop filesystem corruption in brownout conditions.

[1] https://github.com/hiveeyes/hiveeyes-micropython-firmware/blob/master/doc/pycom-firmware-upgrade.rst#install-and-acquire-prerequisites
[2] https://github.com/hiveeyes/hiveeyes-micropython-firmware/blob/master/doc/getting-started.rst#switch-to-littlefs

Happy testing!

@amotl
Copy link
Member Author

amotl commented Jun 7, 2019

@ClemensGruber confirmed this would also work for him, thanks for testing! So we are closing this but feel free to reopen.

@amotl amotl closed this as completed Jun 7, 2019
@einsiedlerkrebs
Copy link
Contributor

einsiedlerkrebs commented Jun 8, 2019 via email

@amotl
Copy link
Member Author

amotl commented Jun 16, 2019

@ClemensGruber told us at [1] that

I believe deep sleep still does not work as intended. When configuring

'interval' 60.0,
'deepsleep': True,

it feels like the WiPy is only sleeping for 5 seconds.

[1] https://community.hiveeyes.org/t/sammelthread-kontinuierliches-bugfixing-der-hiveeyes-micropython-software/2115/3

Thanks for the report!

@amotl amotl reopened this Jun 16, 2019
amotl added a commit that referenced this issue Jun 16, 2019
@amotl
Fix deep sleep to solve #2 again
4034b71
@amotl
Copy link
Member Author

amotl commented Jun 16, 2019

We still had a glitch in there but it should work now.

@amotl amotl closed this as completed Jun 16, 2019
@ClemensGruber
Copy link
Contributor

It's working now as a kind of delay after doing sensor reading and submitting. I had to do make install to get the fix running. make sketch-and-run is not sufficien only!

@amotl
Copy link
Member Author

amotl commented Jun 16, 2019

Dear @ClemensGruber,

this issue was really just about making machine.deepsleep() work at all ;]. Sorry that you are having problems updating your program. The documentation is gradually improving and we will be happy about appropriate contributions.

Also, we would like to tell you that we are tracking the appropriate computation of the delay as a real interval with #4.

With kind regards,
Andreas.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@amotl @einsiedlerkrebs @ClemensGruber