ESP8266 Community Forum

- Tue Dec 26, 2017 2:02 pm #72714

Afaik it is only a sntp client, so no subsecond or transport delay compensation.

It is and I think that the key issue is the lack of transport delay compensation.

The only other way (apart from writing/porting a proper NTP client which I shall consider) that I can think of is to use a GPS module. I haven't really looked into this properly but if it's I2C there still may be a delay in setting the time due to the fact that it's asynchronous.

- Wed Dec 27, 2017 8:52 am #72727 As regards a GPS timestamp. Sqwarking dumping a sequence of NMEA sentences every second is often what a GPS will do. This won't get you an instantaneous time stamp. Maybe adjusting the NTP time with the ping time to the NTP server might help.

- Fri Dec 29, 2017 1:11 pm #72769 I did find an NTP library that appears to do some (rather crude) transport delay compensation here https://github.com/arduino-libraries/NTPClient.

It still doesn't provide the <10ms accuracy that NTP is capable of but it got me within about 0.5 seconds. This isn't ideal but it better than the other libraries I've tried.

- Fri Dec 29, 2017 5:51 pm #72775 I can*t see where in this libraries code you find "some (rather crude) transport delay compensation".
0.5s is the average that you can expect using just the 32bit seconds part of the answer.
To be exact it is -0.0 ... -1.0 seconds, averaged -0.5s, but allways late since the time you receive is allways in the past. Adding 0.5s would be best but adding 1s will bring you sufficently close to +/- 0.5s average taking into account for some transport and processing delay.

a good gps receiver has a timing pulse, giving the exact timing for the begin of the signalled second+1, this should give better than 10ms accuracy.