Deep sleep maximum time 8266

meathome2017 · August 4, 2020, 6:30pm

Good evening all
I’m using a ESP8266 standard development port and trying to increase the time limit on deep sleep as I cannot seem to go above 36 minutes
#define SleepTime 35* 60* 1000000
anything over that time produces this error:
src\TimeSetup.cpp: In function ‘void Run_Time()’:
src\TimeSetup.cpp:5:28: warning: integer overflow in expression [-Woverflow]
#define SleepTime 37* 60* 1000000 // 5-min = 5601000000uS
^
src\TimeSetup.cpp:123:19: note: in expansion of macro ‘SleepTime’
ESP.deepSleep(SleepTime, WAKE_RF_DEFAULT);

But reading this article seems to imply that you can obtain 3.5 hours

An seems to hint that all I need to do is to upgrade to the latest version this I believe I have done but still receiving the same error.

The publication seems to say that the definition was set as a standard int an is now 64 bits long hence hours instead of minutes.

Could somebody please confirm whether the article is correct and it’s my coding that is the problem, or something else entirely.
the sleep command I’m using is:
#define SleepTime 37* 60* 1000000
ESP.deepSleep(SleepTime, WAKE_RF_DEFAULT);

Thank you in advance for any thoughts you may have.

pfeerick · August 5, 2020, 4:13am

That error message sounds like you’re trying to put too big a number into an int… which has a maximum value of 32767 Or something similar… hard to tell with a blindfold on (no code).

You can use uint64_t deepSleepMax = ESP.deepSleepMax(); to get the maximum sleep time as reported by the SDK. I’d use that in a dummy sketch to output to serial and check that the value is correct. It seems from this issue that it’s possible that if set to exactly the maximum value it could rollover, and not wake up, or at least that was the thought at the time. The poster suggested using uint64_t deepSleepMax = 0.95 * ESP.deepSleepMax(); to wind back the time slightly.

Looking at the article you linked, I see mention of trying to go beyond the deepSleepMax value (which changes each time you run it due to temperature drift of the RTC - probably another reason to use a lower than max value) resulting in lockup.

maxgerhardt · August 5, 2020, 7:29am

So this function is defined as

github.com

esp8266/Arduino/blob/9afb084159096aefa509aa2a9f962d15c7f5f146/cores/esp8266/Esp.h#L96


      
          class EspClass {
              public:
                  // TODO: figure out how to set WDT timeout
                  void wdtEnable(uint32_t timeout_ms = 0);
                  // note: setting the timeout value is not implemented at the moment
                  void wdtEnable(WDTO_t timeout_ms = WDTO_0MS);
          
                  void wdtDisable();
                  void wdtFeed();
          
                  void deepSleep(uint64_t time_us, RFMode mode = RF_DEFAULT);
                  void deepSleepInstant(uint64_t time_us, RFMode mode = RF_DEFAULT);
                  uint64_t deepSleepMax();
          
                  bool rtcUserMemoryRead(uint32_t offset, uint32_t *data, size_t size);
                  bool rtcUserMemoryWrite(uint32_t offset, uint32_t *data, size_t size);
          
                  void reset();
                  void restart();
          
                  uint16_t getVcc();

And thus uint64_t means the range of this value is between 0 and (2^64)-1 equals

18446744073709551615

your expression evaluates to

2220000000

which is below the max value; however you are doing int aka int32_t arithmetic when you don’t suffix the values with stuff like U, UL or ULL. And int32_t has a range of

−2147483648 (most negative)
2147483647 (most positive)

2220000000 (your number)

so as you can see you are above the int32_t limit; No need to worry though, just do unsigned long long arithmetic (for uint64_t) and write

 #define SleepTime (35ULL* 60ULL* 1000000ULL)

and you should be good to go.

Too-long-didn’t-read-version: You made a int32_t overflow, use ULLto calculate sleep time as the correct uint64_t value.

meathome2017 · August 5, 2020, 1:34pm

Thank you for your comments and of course you were right, what I was looking for doesn’t seem possible using deep sleep. Due to the temperature drift of the RTC. In the limited time I’ve been testing the devices available to myself I sometimes get as much as 10 minutes error(usually it is a lot less than this), over the period of two hours. But thanking you again for your comments and again I have learned something new.

Thank you your time and trouble.

maxgerhardt · August 5, 2020, 7:21pm

Really interesting, I didn’t read the article but just looked at the code / compilation side of things.

Some question that boggle me are

Can’t the ESP8266 be connected to an RTC crystal (aka 32.768kHz) which is temperature compensated (TCXO)? Or ist the time innaccuracy only for the default when there isn’t even a normal crystal oscillator connected?
If the RTC goes inaccurate after 3.5h doesn’t that mean that an ESP8266 constantly has to resnc its RTC via NTP?

meathome2017 · August 5, 2020, 8:42pm

I am just using the standard development board E12 if you are clever enough to cut up the board or have the expertise to make your own thing indeed perhaps you can add a temperature controlled crystal, I think what I’m going to try to do is just purchase a separate RTC module that is stabilised.
As for your second question to synchronise NTP would mean bringing up the network which would be extremely expensive time/battery/power . There is also no network/Internet for it to connect to.

For what this module needs to do it will probably need a temperature controlled/insulated case as the normal running temperature will be -18 centigrade and will need to go down to -64 if possible. But there comes another problem to generate heat you need power.
And I was hoping not to use a truck battery to power it.

Anyway it keeps my grey matter churning, if I can’t solve this one it might just have to be the professional model which costs £3200, and only does half of what you can do on a microcontroller.

If you have any bright ideas please shout