[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 09:53:36 UTC 2017


Hi,

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
servers)

Interesting points:
-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
ms.)
-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.

Conclusion:
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
using chrony.

Best regards,
   Thomas
   DK6KD
   SA6CID

PS:
Raw data is here, if you want to zoom in: (1.7 MiB, one row per PPS
offset in us)
http://petig.eu/pps-usb.txt
=================================================

Thomas,

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.

  http://www.satsignal.eu/mrtg/raspi14_ntp_3.html

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 
jitter
==============================================================================
*192.168.0.20    .GPS.            1 u   17   32  377   12.351    0.000 
0.428
+192.168.0.11    .uPPS.           1 u    2   32  377   12.432   -0.106 
0.824
-192.168.0.3     .kPPS.           1 u   13   32  377   21.366   -4.524 
0.804
+192.168.0.83    .kPPS.           1 u   27   32  377   21.614   -4.511 
1.206
uk.pool.ntp.org .POOL.          16 p    -   64    0    0.000    0.000 
0.001
-193.150.34.2    133.150.251.233  3 u   38   64  137   32.343    2.738 
1.477
-80.87.128.17    94.125.129.7     3 u   30   64  375   53.337   -1.225 
1.516
-192.146.137.13  82.148.230.254   2 u   56   64  377   46.089    2.220 
2.535
-129.250.35.250  249.224.99.213   2 u  169   64  214   42.499   -3.015 
12.507
-213.130.44.252  145.238.203.14   2 u  487   64  200   37.210   -0.725 
13.232

73,
David GM8ARV
-- 
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor at blueyonder.co.uk
Twitter: @gm8arv 




More information about the Time-nuts_lists.febo.com mailing list