deepsleep maximum time

[dhk111]

@seb thank you for the reply.
can you please tell me why 3 byte value.

[seb]

I don't think there is a specific reason why 3 bytes were chosen, that is just how the firmware on the deepsleep shield was created.

[livius]

@dhk111
just curious - why do you need to sleep board forever? I can not imagine design.

[dhk111]

@livius I am measuring temperature from attiny85 if the temperature rises certain limit it would send signal on pin17 and lopy wakes do the needful and go to sleep until temperature rises again. So the period between successive temperature rises, may be less than 27.7 weeks or greater. During this period, I need to lopy to sleep.

[seb]

@dhk111
I think it would be ok to sleep for 27.7 weeks and then wake up, check the wake reason, if it was not a pin change, go back to sleep. Waking twice a year is not really going to use a lot of power

[livius]

@dhk111

do the needful

I am really curious :) what it do then, send message to the server?

[combaindeft]

@seb

Regarding Deepsleep mode, does one really have to use a "Deep Sleep Shield"?

I'm wondering, since the case we use is tight on space, and we only can fit a PyTrack & LoPy board inside the case ... could we do some sort of "deep sleep" mode with just the two? (without a deep sleep sheield...)

/Daniel

[seb]

With the LoPy/SiPy/WiPy2 the onboard regulator remains in a high performance mode even when the device does into sleep mode, hence the need for the additional board to externally disconnect the power. If you are tight on space I would recommend one of our newer boards (LoPy4/GPy/FiPy/WiPy3) which dont have this issue and work perfectly with just the eps32 deep sleep

[jmarcelino]

This post is deleted!

[dhk111]

@seb thank you. 27.7 weeks is more than enough for my project.

[dhk111]

@livius needful= check if temperature is really high, then send mail,notification

[livius]

@dhk111
Ok, i assume that this notification is not critical?
Because you have not any info between wake up, that control device still is working.

[combaindeft]

@seb

Then I guess, we'll have to go for a LoPy4 or FiPy :)

Thanks @seb

[ssmith]

@dhk111 You're going to have issues with this system design. A sensor need to periodically wake up and report in so you know it is still alive. Waiting 27 weeks for it to wake up and check in???

[jcaron]

@combaindeft if you use a Pytrack or Pysense you don’t necessarily need the deep sleep shield. The Pytrack and Pysense have equivalent functionality, though wake on pin is a bit more problematic.

Of course if you use one of the newer boards you don’t need either.

@seb are you sure about the 24-bit value being in seconds? On a mobile right now so I’m too lazy to check, but IIRC the value in seconds is multiplied by a calibration factor, and it’s the result which is sent on 24 bits. Don’t know the typical values of the calibration factor, but it can decrease the max time quite a bit (and you would certainly get an overflow if you tried to use 2^24-1)

It would probably be a good idea to check for overflows in the library and document a sensible max time.

While you’re in the docs, it would be helpful for many people to add details of the « external deep sleep » requirements in the machine.deepsleep docs.

[seb]

@jcaron

You are correct, upon further investigation I now see that there is a clock calibration multiplier that will multiply the value given by a value in the the range 0.75 - 1.25, so yes the longest duration of deep sleep can vary slight on a per device basis. Also, like you pointed out, this is not bounds checked so this multiplier could overflow, I will fix this in the code now.

In regards to the various deep sleeps, I agree the documentation around these features does need to be clearer. I am adding it to my to-do list

[combaindeft]

@jcaron We bought a set of PyTracks & LoPy's in Januari ;)

and wake on pin isn't that of a high priority for us ... we'd just like to put the device in "deepsleep mode" ... and have it wake up now-and-then ... and "check in" with some values ...

so it doesn't have to "wake up" on pin from some other external sensor ... more or less we are ok with a "deepsleep cycle loop" :)

Do you by any chance have some samples code?

[seb]

@combaindeft

Since you are using the LoPy, you will need the deepsleep shield to have the deepsleep to work correctly. Examples on how to use it can be found here: https://docs.pycom.io/chapter/datasheets/boards/deepsleep/api.html

[jcaron]

@seb there's a Pytrack available, so no need for a deep sleep shield...

@combaindeft are you using LoRa?

Witout LoRa, the code is as simple as:

• do whatever to need to do
• setup_sleep
• go_to_sleep

With LoRa, you need to add nvram_restore and nvram_save.

[seb]

@jcaron

Sorry, yes you are correct, looks like I need a stronger morning coffee! @combaindeft The Pytrack has the same functionality as the deepsleep shield built in, the example code should be very similar and can be found here: https://docs.pycom.io/chapter/pytrackpysense/apireference/sleep.html