Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

It's not obvious that sntp re-runs (IDFGH-2237) #4386

Closed
will-emmerson opened this issue Nov 21, 2019 · 1 comment
Closed

It's not obvious that sntp re-runs (IDFGH-2237) #4386

will-emmerson opened this issue Nov 21, 2019 · 1 comment
Assignees

Comments

@will-emmerson
Copy link

  • IDF version: master

Problem Description

Maybe I'm just stupid but the sntp example doesn't mention anywhere that synchronization will happen automatically based on delay CONFIG_LWIP_SNTP_UPDATE_DELAY. I had assumed it was one-shot and was calling sntp_init myself on a regular basis.
The example and (non-existant, future?) documentation should mention this, and ideally touch on the accuracy of the internal RTC which would allow a more informed decision about the value of CONFIG_LWIP_SNTP_UPDATE_DELAY.

@github-actions github-actions bot changed the title It's not obvious that sntp re-runs It's not obvious that sntp re-runs (IDFGH-2237) Nov 21, 2019
@KonstantinKondrashov
Copy link
Collaborator

Thanks, @will-emmerson for your report. You are right we do not have information about CONFIG_LWIP_SNTP_UPDATE_DELAY option except in Kconfig file related to LWIP/SNTP
I have created an MR to add a description of this for the example and additional chapter System time where provide info about the accuracy of all time sources and RTC clock sources.
The MR is in the stage of review. After merged this issue will be closed automatically.

BlueAndi added a commit to BlueAndi/esp-rgb-led-matrix that referenced this issue Feb 14, 2020
…on is necessary.

See espressif/esp-idf#4386 and https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/system/system_time.html

Attention, calling getLocalTime() may block for 5s if case no timeout is set explicit! Therefore in the ClockDrv::getTime() the timeout is set to 0 to avoid blocking.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants