Busy Timeout!

[schroepfer]

Hello,
i use your newest V16.4 and have problems to connect. 16.3 works correct.
It runs on a TTGO ESP32-WROVER.

ets_ Jun 8 2016 00:22:57
rst:0x10 (RTCWDT_RTC_RESET),boot:0x33 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:1100
load:0x40078000,len:9232
load:0x40080400,len:6400
entry 0x400806a8
Connecting to: FRITZ2
WiFi connected at: 192.168.8.102
Busy Timeout!
Entering 157-secs of sleep time
Awake for : 19.987-secs
Starting deep-sleep _period...

and here:
....
Icon name: 04n
Icon name: 04d
Voltage = 4.17
Busy Timeout!
_PowerOn : 10001028
Busy Timeout!
_Update_Full : 10001015
Busy Timeout!
_PowerOff : 10001015
Entering 860-secs of sleep time
Awake for : 41.301-secs
Starting deep-sleep period...

[G6EJD]

Interesting as there is little difference, in fact no difference in the http fetch functions. I did change the time server to the recommended ‘pool.ntp.org’ rather than a specific ‘0.europe.pool.ntp.org’ or ‘0.de.pool.ntp.org’ but getting time is early in the start-up, so not that.
I’ll do some difference checks and test it this morning. Thanks.

[schroepfer]

in the WAVESHARE_2_9 example i get the same problem:

Connecting to: FRITZ2
WiFi connected at: 192.168.8.104
Failed to obtain time
Busy Timeout!
Entering 1800-secs of sleep time
Awake for : 18.999-secs
Starting deep-sleep period...

but i changed the 5 sec to 15 and it worked!
while (!getLocalTime(&timeinfo, 5000)) { // Wait for 5-sec for time to synchronise

[G6EJD]

Thanks for the feedback. I assume your using the top-level pool NTP server address in the credentials file
default 'pool.ntp.org' ? Which is what they recommend, but I'm thinking that address is taking a long time to be resolved and hence the need to increase connection time-out, it should connect in millis-secs.
Please try '0.de.pool.ntp.org' in the credential file. That is a more direct route to your nearest time server. Or 1.de.pool.ntp.org Or 2.de.pool.ntp.org

[schroepfer]

I use this one:
configTime(0, 0, "0.de.pool.ntp.org", "3.de.pool.ntp.org");

[G6EJD]

Yes, those are your local time-servers so best solution. The NTP Pool advice works but takes too long to resolve the address. BTW ideally set the 0,0 to GMToffset, DSTOffset.

I'm changing the credentials text and examples to reflect this, thanks for your help.

[schroepfer]

I changed it to: (in your newest Waveshare_7_5)

const char* ntpServer = "1.de.pool.ntp.org";
int gmtOffset_sec = 0;
int daylightOffset_sec = 3600;

here the result: (it does update the weather, but don't update the epaper) :-(
....
Icon name: 04d
Icon name: 04d
Voltage = 4.19
Busy Timeout!
_PowerOn : 10001028
Busy Timeout!
_Update_Full : 10001015
Busy Timeout!
_PowerOff : 10001015
Entering 1710-secs of sleep time
Awake for : 40.294-secs
Starting deep-sleep period...

[G6EJD]

Interesting, actually it got time OK, but that Busy TimeOut error is as a result of getting trying to get Forecast Weather. So your country code is DE and Language DE ?
This could be a OWM server issue at the moment, I've seen it many times, that Weather data is always received, but Forecast data is not.

[schroepfer]

yes DE and DE. I'l try another coutry.

[G6EJD]

I’ve just checked my two (7.7 and 4.2”) and they both show no connection to OWM so I think that’s the (OWM) issue. I’m going to report errors on screen so it’s possible to know what’s going wrong as a next update.

[schroepfer]

This is a realy good idea!

I tryed it with you MELKSHAM-data. Busy Timeout!

[schroepfer]

It is runng now!
I must use the LOLIN 32 PRO for correct working with my TTGO ESP-32 WROVER.
But: it doesn't wake up from deepsleep. Only when i press the reset-button!?
And yes, the time is between wakuptime and sleeptime.

[AWSW-de]

Hi, I think I have the same „too“-deep sleep issue too. I updated yesterday to 16.4 and it seems that it does not wake up after some cycles/hours.

With the before used 16.0 version I think it stopped after about 3 days and needed a reset click.

I read about this deep sleep problem somewhere else and there a hint was named that after the Serial.begin(115200) command line you should add a at least 500ms delay to fix this. Within my own sketches I followed this and they seem to work... maybe a hint for this too?

Link (only in German)
https://www.az-delivery.de/blogs/azdelivery-blog-fur-arduino-und-raspberry-pi/sleep-timer-esp32?ls=de&cache=false

[schroepfer]

Thank you! I will try this tomorrow and tell you if it helped.

[G6EJD]

@AWSW2017 I've added a delay after Serial.begin to see if that improves reliability, plus I've added an error log facility, I'll upload it soon. Thanks for your help.