[time-nuts] ``direct'' RS-232 vs. RS-232 via USB vs. PPS decoding cards
David J Taylor
david-taylor at blueyonder.co.uk
Sat Feb 18 04:53:36 EST 2017
I was wondering whether there is some data/information available on the
claimed +/- 100 ns jitter?
Regarding the PPS -> USB (using the CTS line of a FTDI FT232R), I
plotted, using some lines of Python, the time offset as attached. Just
to get an overview how it is 'worst case', i.e., user program, python,
etc. The 1PPS signal comes from a GPS rx.
Looks like a standard deviation of around 150 us.
y-axis: measured pps offset from full second (computer time) in us,
x-axis pps pulse number.
On the long term it looks interesting (while measuring I played with the
NTP server on this computer)
Until ca. second 10000: ntpd synchronization via internet
Until ca. second 17000: made an additional LAN NTP server (GPS) available
Until the end: replaced ntpd with chrony (still using internet and local
-It looks surprisingly bad with using the normal ntpd (especially, there
is not really an improvement having an local GPS based server
available, did I do something wrong? Only the offset changes by ca. 3
-It looks surprisingly good with chrony. But there are continuously
outliers of up to 4500 us, is this a result of the chrony control loop?
The time is wandering around with ntpd, but has less jitter.
Despite the 150 us stddev, the using PPS over USB gives some interesting
inside of what the local ntp server is actually doing. It looks to me
like it would be an improvement to use it when using ntpd, but not when
Raw data is here, if you want to zoom in: (1.7 MiB, one row per PPS
offset in us)
I've done some tests with PPS over USB with Windows some time back, which
showed that PPS?USB could be better than LAN-sync alone, but that also
included a reduction of the poll interval from possibly 64 seconds for LAN
sync to 16 seconds for PPS sync, which may have influenced the results.
<pet-peeve>It would be helpful to have some units on the axes - 10000 what?
I'm guessing microseconds....</pet-peeve>
For comparison, here is a Raspberry Pi running NTP, with the reported offset
plotted against time.
This Raspberry Pi (running a seismic detector) is using an Ethernet
connection via Power-line Ethernet (yes, I know, QRM etc. etc.), and a
couple of switches to a very good stratum-1 server. I would estimate from
your graph that the jitter in offset is about 1 millisecond peak-to-peak,
but it seems that I get less than that - perhaps 100 microseconds
peak-to-peak with occasional excursions outside that. This is with the
latest reference version of NTP.
remote refid st t when poll reach delay offset
*192.168.0.20 .GPS. 1 u 17 32 377 12.351 0.000
+192.168.0.11 .uPPS. 1 u 2 32 377 12.432 -0.106
-192.168.0.3 .kPPS. 1 u 13 32 377 21.366 -4.524
+192.168.0.83 .kPPS. 1 u 27 32 377 21.614 -4.511
uk.pool.ntp.org .POOL. 16 p - 64 0 0.000 0.000
-184.108.40.206 220.127.116.11 3 u 38 64 137 32.343 2.738
-18.104.22.168 22.214.171.124 3 u 30 64 375 53.337 -1.225
-126.96.36.199 188.8.131.52 2 u 56 64 377 46.089 2.220
-184.108.40.206 249.224.99.213 2 u 169 64 214 42.499 -3.015
-220.127.116.11 18.104.22.168 2 u 487 64 200 37.210 -0.725
SatSignal Software - Quality software written to your requirements
Email: david-taylor at blueyonder.co.uk
More information about the time-nuts