[time-nuts] can of worms: time-of-day in a community radio station

[Fiorenzo Cattaneo]

>
> > With this setup you have no single point of failure, and even if the
> > connection to internet fails, they can still provide time as they are peering
> > and synchronizing with each other.
> No, it doesn't work that way.  You need connectivity to at least one stratum 1
> server.
> There is an option to elect one, orphan mode, if you get disconnected from the
> net.  That keeps all the local clocks close together.  They will all drift
> along with the chosen leader.

My understanding is that it would work moderately well even without a
stratum-1 server, at least be able to operate within a few tens of
milliseconds for several hours. Although I confess I haven't used
peering in a very long time. In my workplace we added stratum-1 GPS
symmetricom NTP servers about 6 months after the above mentioned
setup.

>
>
> > You can use this list to pick stratum 1 servers:
> >                           http://www.advtimesync.com/docs/manual/
> > stratum1.html
>
> There is no date on that list.  At a quick glance, a few systems I'm familiar
> with are way out of date.  I wouldn't trust any of the details.  Same for
> other lists of stratum 1 servers.  They might be a good starting point.  In
> particular, many servers that say "open access" on lists like that have
> changed their rules, often going off the air.

My apologies, I just did a quick googling because I was on the phone
and didn't have access to my desktop bookmarks. This is the list I
normally use

http://support.ntp.org/bin/view/Servers/StratumOneTimeServers


>
>
> > server time.nist.gov
>
> That's a bad example.  NIST has servers at several locations.  That name
> rotates across them.  You might get a good one, or you might get one on the
> other side of the country.  If it works well today, it may not after you
> reboot and pick a different server.
>   https://tf.nist.gov/tf-cgi/servers.cgi

100% agree on this...... DNS roundrobin is good enough for 10s of
milliseconds, but for best results you should always pick nearby
servers. The worst thing of DNS round robin is that it gives
unpredictable results.

>
>
> > just a cheap GPS receiver (serial is best, but USB should be OK
>
> There are 3 levels of GPS receiver.  GPSDO is best.  GPS with PPS is second - serial prefered, but USB works.  Low cost GPS (without PPS) on USB is last.
>
> USB is polled -- no interrupts.  That adds a millisecond of jitter.  That's probably not an issue if your goal is 100 ms.  (If you are a geek, be sure you understand hanging bridges.)
>
> The timing on the serial port from low cost GPS receivers is often crappy.  This is a horrible example:
>   http://users.megapathdsl.net/~hmurray/ntp/GPSSiRF-off.gif
> Anyway, you need to check the device you select.  (Or get suggestions from people who are using them for NTP.)

Ouch, that looks pretty awful.

>
> The PPS signal will fix that.
>
> The GPSDO will continue providing decent time if your GPS stops working.  Holdover is the buzzword.


Currently my stratum-1 servers are as follows, in decreasing order of accuracy:
* amd64 PC with Symmetricom/Microsemi BCP635 timing board, fed with
the 1 PPS signal from a UBLOX-7 receiver.
* amd64 PCENGINES with GPSDO with PPS fed to serial port. I very
recently got two GPSDO, a BG7TBL and a Oscilloquartz STAR 4 receiver.
The latter is very nice as it also provides the receiver state
(calculating stationary mode, stationary mode, GPS lock info and
holdover info).
* amd64 PCENGINES with vanilla UBLOX-7 receiver with PPS fed to serial port.


Thus far I have been playing with PPS on the serial port. I just
modified the serial port driver to support PPS_ECHOASSERT and
PPS_ECHOCLEAR so that I can use the oscilloscope to get a quantitative
understanding of what the interrupt latency and jitter is. Perhaps I
should experiment with PPS on the parallel port as well. RS232 is far
from ideal, mainly due to the fact that the rise time of the PPS edge
on a 12 volt signal is very high. The UBLOX-7 PPS has a TTL output and
the RS232 port I use is TTL compatible so I'm hoping this ameliorates
the issue with the rising edge on the RS232, but I'll only know for
once I get the measurements with the oscilloscope.

I keep comparing the time between these three servers, and I've
observed an absolute lock offset of approximately 10 to 20
microseconds between the timing board server and the PPS on RS232
servers. That is what I would expect by RS232 timings. Once I have the
oscilloscope measurements I should be able to adjust and correct for
the average interrupt latency, although I won't be able to do anything
for the jitter.


>
>
> --
> These are my opinions.  I hate spam.
>
>
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com
> To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.