NTP accuracy on ESP8266

General discussions and questions abound development of code with MicroPython that is not hardware specific.
Target audience: MicroPython Users.
Post Reply
MikeNick42
Posts: 3
Joined: Sat Feb 20, 2021 4:17 pm

NTP accuracy on ESP8266

Post by MikeNick42 » Sat Feb 20, 2021 4:21 pm

Hi,

I'm working on a timing related application for the ESP01. I understand that the internal clock is hot garbage, and that's ok, I can make frequent calls to my internal NTP server. But it looks like ntp.settime() only has whole second resolution.

From ntptime.py:

Code: Select all

machine.RTC().datetime((tm[0], tm[1], tm[2], tm[6] + 1, tm[3], tm[4], tm[5], 0))
That 0 at the end is the usecond field
Is there a way to get better time setting accuracy with uPython?

User avatar
Roberthh
Posts: 3667
Joined: Sat May 09, 2015 4:13 pm
Location: Rhineland, Europe

Re: NTP accuracy on ESP8266

Post by Roberthh » Sat Feb 20, 2021 4:32 pm

You could think of adding fractions using tick_ms or tick_us. But that is kind of wasted effort, because you do not know how long it takes for the ntp response to arrive. The ticks time us based on the main crystal, and usually pretty precise. So at least starting from a certain point you could get a constant offset.

MikeNick42
Posts: 3
Joined: Sat Feb 20, 2021 4:17 pm

Re: NTP accuracy on ESP8266

Post by MikeNick42 » Sat Feb 20, 2021 5:13 pm

There's not an exact way to know the one-way delay for NTP, but typically the round trip time is halved to give a pretty good estimate, and should give much better than 1s accuracy.
I could get a constant offset but it seems like it would still be unknown because settime() is artificially setting the time to a whole second?

User avatar
pythoncoder
Posts: 5956
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: NTP accuracy on ESP8266

Post by pythoncoder » Sun Feb 21, 2021 10:00 am

I would draw a distinction between absolute and relative accuracy. NTP provides absolute time, but because of transport latency it is hard to get better than 1s accuracy. I believe there are ways, but it's specialist stuff. GPS may be easier. But absolute time to μs level is a laboratory grade requirement...

However most applications requiring μs level timing need only relative accuracy: typically you are timing the duration of an event or the time between two events. These need only relative accuracy, and for the reason Robert has explained the time.ticks methods provide this.

It's perhaps worth noting that ESPx platforms don't excel in this regard, especially if you're using interrupts. A Pyboard is the platform I'd use for precision timing.
Peter Hinch
Index to my micropython libraries.

MikeNick42
Posts: 3
Joined: Sat Feb 20, 2021 4:17 pm

Re: NTP accuracy on ESP8266

Post by MikeNick42 » Sun Feb 21, 2021 5:33 pm

I understand the difference between absolute and relative time. I'm trying to get absolute time. The goal is a project similar to this (https://www.instructables.com/WWVB-radi ... NY45-or-A/) where the 8266 board uses NTP to get "truth" and controls the 60kHz wave. Exactly how the wave is controlled is a question for later.

I have a Raspberry Pi as a local time server connected to GPS with a PPS signal so while I don't need microsecond accuracy, I strongly disagree with your assertion that <1s is difficult with NTP and it seems like hard coding 0 in the usecond field is an artificial limitation. Even over the internet it should be possible to get within a couple hundred ms.

For uPython's ntp module it seems like even changing:

Code: Select all

machine.RTC().datetime((tm[0], tm[1], tm[2], tm[6] + 1, tm[3], tm[4], tm[5], 0))
to:

Code: Select all

machine.RTC().datetime((tm[0], tm[1], tm[2], tm[6] + 1, tm[3], tm[4], tm[5], 500000))
Would be more accurate by making the error +-1/2s rather than up to 999ms behind.

I will admit, I didn't realize quite how bad these chips were for timing and was mainly interested in using it instead of another GPS because of cost. I'm not too concerned with that weakness of the chips though because I can always query the server more frequently.

Post Reply