Advanced Users can post their questions and comments here for the not so Newbie crowd.

Moderator: eriksl

User avatar
By eriksl
#81514 At which point are timezones used actually? I think only in the conversion routines from unix epoch time to text. That's, as said before, not really SNTP functionality.

Starting from a such a timestamp, it's a fairly standard route to convert it to text, I'm sure there are numerous implementations available on internet. At some point I will do the same. We really don't need Espressif for that.

SNTP itself uses microsecond precision, but if we want to "see" it, we'll have to make our own SNTP implementation (which, as said, I was going to do anyway). But in which case do you actually care for sub-second exact time stamps? I can imagine you'd want to have the internal clock stepping in milliseconds or even microseconds, but need it to be exact equal to "wall clock" time? My code does something like that, the base is the time in seconds from SNTP and from there it increments in milliseconds. Which will deviate from wall clock sooner or later and that is why SNTP should be run frequently and not, like Espressif does, once.
User avatar
By eriksl
#81515 BTW in the process finishing up I found even more Espressif'isms in the LWIP code (and removed them). Did you know four traits of TCP and DHCP are kept in RTC memory from where they can be tweaked by, what?, SDK code? I removed all of it, I don't need nor want to change these values on the run.

They did it very ugly by replacing some #define <value> by #define *(volatile uint32 *)0x600xxx. Some code in LWIP depends on these #defines being constant, so they simply commented it out.
User avatar
By davydnorris
#81520
eriksl wrote:At which point are timezones used actually? I think only in the conversion routines from unix epoch time to text. That's, as said before, not really SNTP functionality.

Starting from a such a timestamp, it's a fairly standard route to convert it to text, I'm sure there are numerous implementations available on internet. At some point I will do the same. We really don't need Espressif for that.

SNTP itself uses microsecond precision, but if we want to "see" it, we'll have to make our own SNTP implementation (which, as said, I was going to do anyway). But in which case do you actually care for sub-second exact time stamps? I can imagine you'd want to have the internal clock stepping in milliseconds or even microseconds, but need it to be exact equal to "wall clock" time? My code does something like that, the base is the time in seconds from SNTP and from there it increments in milliseconds. Which will deviate from wall clock sooner or later and that is why SNTP should be run frequently and not, like Espressif does, once.


Espressif use it in their conversion functions - if you're using your own then you won't need any time zone correction. As soon as I can I'll dump their SNTP time routines as I need to convert to ISO 8601 format and their code doesn't do that so I've already written my own.

Don't confuse accuracy and precision in your (S)NTP discussions - you may be getting back microsecond values, but "NTP can usually maintain time to within tens of milliseconds over the public Internet, and can achieve better than one millisecond accuracy in local area networks under ideal conditions." Note also that this is NTP and not SNTP, which has a much worse precision and is considered to be +-1s at best if you don't do any internal correction.

For hard core audio applications, most people prefer RTP or PTP, which can get down to microsecond precision, however you need latency correction built into the hardware and I don't think the ESP8266 has it, or if it does it's not exposed.
User avatar
By eriksl
#81535 My question remains, why would you need microsecond (or even millisecond) precision on an ESP8266? I am quite sure none of the timers of the ESP8266 has the required accuracy to maintain this precision, even only for a few minutes (microseconds). I've found the RTC to be off several minutes within just 24 hours and that's supposed to be the accurate one (as opposed to the internal timers).