[time-nuts] GSP+PPP and GPSDO NTP servers - notes and questions

[Fio Cattaneo (.US)]

Great graphs and screenshots, thanks for sharing 😊 I have a couple
questions for you (see answers/comments below):
a) Which cmd line tool did you use for the sreenshots in zegar_stats_pl.png
and gpsdo_stats_pl.png ? Is that what you call your "simple perl script"?
mind sharing it, I like it 😊
b) When collecting data for the phase error (offset) and jitter, what do you
use a reference time source to calculate these offsets? I have struggling
myself to get "good" data when collecting these statistics, as I am not
quite sure which reference to trust.

>>>> 1. To calculate fudgetime2 of GPS NMEA driver you can set GPS as
>>>> noselect and calculate the vallue from peerstats,

This is definitely the best way to do it, average out among many samples.
I've noticed though is that it's not really necessary when you are enabling
PPS for the second synchronization.  Looking at refclock_ppsrelate()
function in ntpd/refclock_nmea.c code, you can see ntpd code will
synchronize the PPS event with the GPS timestamp so long as it occurs within
0.45 seconds from PPS.
That said, I think it's best practices anyway to set "fudge time2"
correctly.

>>>>> 4. You can use PPS and GPS drivers separately, or just GPS driver

Using both doesn't seem to work very well for me, I found that NMEA refclock
alone is better, as you also seem to suggest. My config file portion for
NMEA refclock is:

# NMEA with kernel PPS - time2 fudge not strictly needed
server 127.127.20.0 mode 0x11 maxpoll 4
fudge 127.127.20.0 flag1 1 flag3 1
#fudge 127.127.20.0 flag1 1 flag3 1 time2 0.155

>> Question 3 .... I would like to share PPS signal (along, onto DCD line)

I haven't seen replies from more experienced time nutters, so I'll dare an
answer here. I'm not actually sure I understand your question, so I'll
answer both ways I interpret it 😉
* If you want to use DCD instead of CTS, you can build your own RS232 cable,
with the GPSDO side connecting PPS wire signal to DB9 pin 8 (CTS) and the PC
side connecting PPS wire signal to DB9 pin 1 (DCD). One tools that I've
found of great help when troubleshooting/debugging RS232 lines is this one:
https://www.amazon.com/EZSync-Tester-Indicators-Female-EZSync911/dp/B0786WLCYF
For prototyping, this also helps, although for "production" purposes I'd
just use a couple DB9 and solder the wires I need:
https://www.amazon.com/GGLABS-RS-232-DB9M-DB9F-Break-Out-Monitor/dp/B01LYVJSUH/ref=pd_sbs_147_t_2/133-8628981-8720228?_encoding=UTF8&pd_rd_i=B01LYVJSUH&pd_rd_r=ed830a44-26bd-46ed-b435-ac6082f1caa7&pd_rd_w=iEaRG&pd_rd_wg=QyERt&pf_rd_p=5cfcfe89-300f-47d2-b1ad-a4e27203a02a&pf_rd_r=CDNE2EDPAHYNMNRDPEXZ&psc=1&refRID=CDNE2EDPAHYNMNRDPEXZ


* If you want to share one single PPS signal to multiple consumers, I would
recommend to use a logic buffer for each consumer, so that the signal is
kept clean from cross interference. I haven't checked yet what the CTS
voltage for the GPSDO is... If it is 0 to 5 volts you can use a very simple
TTL buffer for each output line. This one for instance should do :
https://www.nteinc.com/specs/7400to7499/pdf/nte74LS125A.pdf  it has both
inverted and non-inverted outputs, and propagation delay seems really good
at < 20 ns. If it uses RS232 levels, I don't know of any ready-made single
chip solution. There are plenty of circuit samples you can google which at
their simplest use a couple transistor and a few capacitors/resitors.


One of the things that I've been wondering is the serial line interrupt
latency (time from PPS line assert and the PPS timestamping code in
interrupt handler) and jitter, as well as compatibility issues between TTL
levels and RS232 standard levels and signal termination. For the most part
communication happens seamlessly on modern RS232 transceivers regardless of
TTL/RS232 levels, but how well a TTL signal can drive an input which expects
an RS232 signal, I'm not sure. I'm wondering about the rise time of the
signal and about the fact that a 0V-5V TTL signal is barely within specs to
be recognized by a serial input - maybe it affects jitter and latency?
To this end though, I've bought a fairly cheap digital function generator,
and I am planning to do a bunch of experiments about this to collect some
hard data. I'll share results when I have them.

Cheers,