[time-nuts] ``direct'' RS-232 vs. RS-232 via USB vs. PPS decoding cards
kb8tq at n1k.org
Sat Feb 18 08:36:51 EST 2017
> On Feb 18, 2017, at 4:53 AM, David J Taylor <david-taylor at blueyonder.co.uk> wrote:
> I was wondering whether there is some data/information available on the
> claimed +/- 100 ns jitter?
I guess the previous was not complete enough.
I routinely measure PPS jitter on GPS modules down well below 10 ns on a 53131.
That’s after sawtooth correction is applied. Without sawtooth correction, the +/- 24
or +/- 12 or +/- 1.25 ns of the sawtooth adds into that.
The reference used is an HP 5071 with a high performance tube option.
> 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
> 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
> -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
> using chrony.
> Best regards,
> 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 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
> -184.108.40.206 220.127.116.11 3 u 38 64 137 32.343 2.738 1.477
> -18.104.22.168 22.214.171.124 3 u 30 64 375 53.337 -1.225 1.516
> -126.96.36.199 188.8.131.52 2 u 56 64 377 46.089 2.220 2.535
> -184.108.40.206 249.224.99.213 2 u 169 64 214 42.499 -3.015 12.507
> -220.127.116.11 18.104.22.168 2 u 487 64 200 37.210 -0.725 13.232
> David GM8ARV
> SatSignal Software - Quality software written to your requirements
> Web: http://www.satsignal.eu
> Email: david-taylor at blueyonder.co.uk
> Twitter: @gm8arv
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
More information about the time-nuts