RTC crystal required?

[kriswiner]

Just curious if this requires a 32.768 kHz crystal on RTC pins 32 and 33 and uses the internal RTC hardware and SDK native RTC functions to implement RTC time keeping, or is this simply a fancy timer based om the HSE?

Lore is that managing an RTC on the ESP32 requires the SDK. SO another way to ask my question is, is this an Arduino wrapper for an SDK RTC function?

In any case, it seems to work, so thanks for the library!

[fbiego]

Yes, this is a wrapper library for RTC functions on ESP32 On Arduino, there is no way of changing the clock source unless by recompiling the libraries. This library uses the default which is the internal 150kHz RC oscillator. The 32.768kHz crystal is not required unless you change the clock source.

espressif/arduino-esp32#3964

[kriswiner]

Thanks for the info.

I have a 32.768 kHz crystal on many of my ESP32 designs. How could I change the clock source to this LSE? Also, is there a provision for RTC alarms and such and do you plan to add this capability to your library?

If the ESP32 is in deep sleep, does the RTC continue to keep time?

And lastly, do you have any idea how accurate the internal RC oscillator-based RTC is? On STM32, the RTC is quoted at +/- 1 ppm, so it loses a second or so a month.

Sorry for all of the questions and thank you for your patience and answers ina advance!

On Mon, Mar 15, 2021 at 9:11 AM Felix Biego @.***> wrote:

Yes, this is a wrapper library for RTC functions on ESP32 On Arduino, there is no way of changing the clock source unless by recompiling the libraries. This library uses the default which is the internal 150kHz RC oscillator. The 32.768kHz crystal is not required unless you change the clock source.

espressif/arduino-esp32#3964 https://github.com/espressif/arduino-esp32/issues/3964

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/fbiego/ESP32Time/issues/3#issuecomment-799544393, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKWNQLRXB266IVPTYK3TDYWRVANCNFSM4ZFVPTOA .

[aovestdipaperino]

I plan to play with this as well. If the RTC keeps running in deep sleep mode it would be awesome.

[aovestdipaperino]

It is awesome: snippet The only issue is why it takes 5010 millisecs to get the time from the RTC (it might be my board).

[aovestdipaperino]

Apparently, the full signature of getLocalTime is bool getLocalTime(struct tm * info, uint32_t ms) with a default value of 5000 ms.

The purpose is pretty obscure:

bool getLocalTime(struct tm * info, uint32_t ms)
{
    uint32_t start = millis();
    time_t now;
    while((millis()-start) <= ms) {
        time(&now);
        localtime_r(&now, info);
        if(info->tm_year > (2016 - 1900)){
            return true;
        }
        delay(10);
    }
    return false;
}

Seems like the RTC might not have been reliable and keep reading until the year returns in the 1900-2016 range. Opening a bug there.

[kriswiner]

This is likely due to the use of the internal RC Oscillator as timing source, which will be inaccurate (to say the least) and slow. A better solution would be to recompile the library for a version that requires an external 32.768 kHz crystal, then long latency issues "should" be eliminated.

But I know next to nothing about the internals of the ESP32 RTC sector, so maybe this kind of long latency is time measurement is inherent in the API? Shouldn't be...

On Tue, Mar 16, 2021 at 9:53 PM Paperino @.***> wrote:

Apparently, the full signature of getLocalTime is bool getLocalTime(struct tm * info, uint32_t ms) with a default value of 5000 ms.

The purpose is pretty obscure:

bool getLocalTime(struct tm * info, uint32_t ms) { uint32_t start = millis(); time_t now; while((millis()-start) <= ms) { time(&now); localtime_r(&now, info); if(info->tm_year > (2016 - 1900)){ return true; } delay(10); } return false; }

Seems like the RTC might not have been reliable and keep reading until the year returns in the 1900-2016 range. Opening a bug there.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/fbiego/ESP32Time/issues/3#issuecomment-800792605, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKW74HBXBFGO2R2DRYTTEAYSZANCNFSM4ZFVPTOA .

[aovestdipaperino]

No, this seems to be a bug in the code. Clearly they are expecting a date range that is wrong (2016?). But I reduced the latency to 10msec by forcing 0 as second parameter. It works great, no recompilation. still like your idea of an external crystal but I am afraid it might require GPIO pins so I don't think it will survive a deep sleep. Interesting topic, I want to dig more. (I updated the snippet to the bare minimum)

[fbiego]

the getLocalTime() function is taken from esp32-hal-time.c which is used in the SimpleTime example.

void printLocalTime()
{
  struct tm timeinfo;
  if(!getLocalTime(&timeinfo)){
    Serial.println("Failed to obtain time"); // time is less than 2016, ie. not set
    return;
  }
  Serial.println(&timeinfo, "%A, %B %d %Y %H:%M:%S");
}

The RTC time is considered not set if the time is below the year 2016 since it starts counting from the year 1900

[aovestdipaperino]

You are right, you can close this issue then Thanks! I didn't even know the ESP32 had an RTC. How convenient.