ESP8266 Community Forum

- Sun Jun 11, 2017 8:15 am #67014 this seem to be the biggest problem with this company:
a) they are bad on documentation
b) the are even worse on communication

I will have a look at the api_docu and see what I can make out of that

- Sun Jun 11, 2017 10:04 am #67016 Sooner or later you will understand why I said that we prefer to use proper hardware RTC's in our projects.
The uncertainty degree is far too high using a RTC software implementation with ESP8266. And ESP32 looks also to have a lot of different issues. The silicon bugs erata has become quite big. See latest jun release.

ESP8266 MPDMv4 AC MAINS Dimmer Home: http://esp8266-projects.com/2016/04/mpdmv4-mains-dimmerswitch-html/
Available on Tindie: https://www.tindie.com/products/nEXT_EVO1/universal-ac-mains-dimmer-mpdmv41/

- Sun Jun 11, 2017 11:06 am #67019 up to now I didn't come across any "uncertainties" with deep-sleep, apart from the gpio16/rst topic.
It should be well known fact right now that a direct connection is really bad but still 0Ohm is purported in the relevant mfg. document, allthough the have people on payroll being members in the forum.

Yes I follow the development around the esp32 know the errata sheet. I was baffled that they dared to market a piece of silicone even worse than the esp8266, intimidating developers for "brands industry". With this attitude they will remain a niche product.

But for arduino-type projects it is still great.

- Thu Jun 29, 2017 12:56 pm #67729 ok I had a look at the new documents.
if I reformulate

Code: Select all(max time_in_us / cali) << 12 = 2^31 - 1

taking <<12 for multiply by 2^12 (4096) I get

Code: Select allmax_us = ((2^31-1)/2^12)*cali

or approx

Code: Select allmax_us < 2^19*cali

with system_rtc_clock_cali_proc() returning values in the range 22300 - 23100 (even varying on continous readings w/o reboot ???)
taking 22000 for safety, this gives max deep sleep of ~11500s ~~ 3.2h

so nothing "uncertain" about deepsleep if datasheets are interpreted correctly ...

n.b.:
a) the 2.1.0 fork of the esp8266 arduino core is faulty for new deepsleep (still uint32) and lacks system_rtc_clock_cali_proc().
b) Serial.printf does not print uint64 (%ull) correctly (won't do more than %ul appended with one "l").

You do not have the required permissions to view the files attached to this post.

Last edited by schufti on Thu Jul 13, 2017 4:22 am, edited 1 time in total.