I got a esp32 ntp sever using gps as time source when i test it, i got fine offest:
hugo@Hugo:~$ ntpdate -q
24 Oct 22:45:16 ntpdate[368030]: no servers can be used, exiting
hugo@Hugo:~$ ntpdate -q time.zetalon.com
server 203.30.14.27, stratum 1, offset -0.115989, delay 0.10777
24 Oct 22:45:25 ntpdate[368087]: adjust time server 203.30.14.27 offset -0.115989 sec
hugo@Hugo:~$ ntpdate -q time.zetalon.com
server 203.30.14.27, stratum 1, offset +0.218531, delay 0.15965
24 Oct 22:48:17 ntpdate[368633]: adjust time server 203.30.14.27 offset +0.218531 sec
However when u test it with Ad-hoc NTP Server Check, the offset is high!!! any idea why and how to fix it??
Results
-
usdaa1-1tcp71g
Offset: -1944.76862ms
RTT: 297.418551ms
-
ussjc1-1a6a7hp
Offset: -1503.31495ms
RTT: 316.710409ms
-
nlams2-1a6a7hp
Offset: -1203.1666ms
RTT: 454.926428ms
Hi hugodonotexit, welcome!
What are you trying to veryfy against what?
Can it be that the time.zetalon.com server distributes a borderline accurate time? The first time i ran a check against it, it reported time as inaccurate (a few minutes later its acceptable, however).
when i test time.zetalon.com (203.30.14.27) using the NTP pool montors i get:
(notice the high offset).
When using an external NTP test website to check against time.zetalon.com i sometimes get:
You might want to use an alternative, external time source.
Are you sure that your server has GPS-sync?
yes i am sure my sercer has gps sync, i also compare it with timewindows.com and pool.ntp.org
hugo@Hugo:~/CBudgie$ python3 test.py
Data from time.windows.com:
Server Time (Unix): 1729779291
Offset: -0.413982 seconds
Hex Data:
±-------------------------------+
| 1c 03 00 e9 00 00 00 74 |
| 00 00 06 b9 19 42 e6 02 |
| ea c4 d4 21 9a 99 a4 81 |
| 00 00 00 00 00 00 00 00 |
| ea c4 d4 db be 70 95 94 |
| ea c4 d4 db be 70 bd d8 |
±-------------------------------+
Data from time.zetalon.com:
Server Time (Unix): 1729779291
Offset: -0.521369 seconds
Hex Data:
±-------------------------------+
| 24 01 06 fa 00 00 01 ff |
| 00 00 08 06 47 50 53 00 |
| ea c4 d4 db aa 0e 62 99 |
| 00 00 00 00 00 00 00 00 |
| ea c4 d4 db aa 0e 62 99 |
| ea c4 d4 db aa 0e e8 d1 |
±-------------------------------+
Data from pool.ntp.org:
Server Time (Unix): 1729779291
Offset: -0.558236 seconds
Hex Data:
±-------------------------------+
| 1c 03 00 e7 00 00 02 6c |
| 00 00 00 54 0a a5 08 0a |
| ea c4 d4 9c 18 08 b5 93 |
| 00 00 00 00 00 00 00 00 |
| ea c4 d4 db e2 47 e0 9f |
| ea c4 d4 db e2 4c 82 56 |
and the these offest and time are very similar
We need more information about the NTP server. It doesn’t behave as expected. As I type this, the root delay is 7.8 msec; a GPS-driven stratum 1 is normally a small value, typically 0. The root dispersion is steady at 31 msec; GPS/stratum 1 should be well under 1 msec.
Over the past several days I see errors of 60 seconds, 1729760431 seconds, even 54 years. At other times the error is small.
Most of my GPS/NTP servers are raspberry pi based. I have no direct experience with the Arduino. The principles are the same though.
What software is being used?
What GPS is being used & how is it connected to the computer?
src: ESP32-GPS-NTP-server/gpsntp.ino at main · Hugodonotexit/ESP32-GPS-NTP-server · GitHub
“Over the past several days I see errors of 60 seconds, 1729760431 seconds, even 54 years. At other times the error is small.” that’s because i was testing it
it doesn’t connect to pc it connected to the internet directly
gps sent a pulse every second which will tiggler the ESP32 to read the time, and reset the built in timer (in microsecond) to 0
Can expand on:
“gps sent a pulse every second which will tiggler the ESP32 to read the time, and reset the built in timer (in microsecond) to 0”
- What GPS chipset/device is used?
- How is it physically connected to the ESP32?
- Is the TCP stack running on the ESP32?
- Is the NTP protocol implemented on the ESP32?
Is this something that you built / designed? What are your goals for the system?
That helps, thanks.
It sounds like the ESP32 - Internet connection is WiFi based. that can introduce many milliseconds of jitter. The jitter can be higher when aggressive power savings is used.
The server currently has a somewhat steady offset error of about 200 msec. This shouldn’t happen with a PPS. There are frequent errors of 1 second; sporadically the errors are much higher. The transition between high errors and much lower errors are sudden. The alarm bits (LI field) appears to be unused. This and your previous statements suggest that custom software is being used rather than NTP software most of us are familiar with.
This doesn’t appear to be an NTP Pool issue, at least not yet.