[time-nuts] GPSDO+PC as a NTP server

[Fiorenzo Cattaneo]

I also have a BG7TBL, version 2019-03-25, and I use it with a small
embedded X64_64 pcengines box with a dedicated mPCI RS232 receiver.
See picture attached, the PCENGINES box is the black box below the
GPSDO.

>
> 1. The GPS chip onboard can be set via RS232C, for instance by u-center
> program. I currently set stationary mode, disabled SBAS, 3D fix mode only,
> minimum elevation 20 degrees, position and time accuracy masks of 40
> meters, C/No threshold 20 dbHz.  All of this filters out some satellites
> and increases DOP, but my understanding is it also removes some errors and
> makes the GPS more suitable for timing? Unfortunately, this chip can only
> use only 1 constellation of satellites at once. The question here is then:
> is it better to have less precise, high DOP fix or more precise fix that
> can be absent from time to time?

GPS and GLONASS are the best GNSS around, they are operated by the
military as a military operation and have the best reliability record.
Beidu is fairly new, and Galileo is operated by civlian agencies.
They've had major operational issues. So this leaves GPS and GLONASS.
GLONASS tends to have better coverage on the polar regions, but
otherwise I think GPS is better, and GPS has better time and space
accuracy. Although I'm not that with the accuracy of RS232 interrupt
handling it would be possible to even tell the time differenbce.
between UTS(GPS) and UTC(GLONASS).

I'm not even sure than running GLONASS and GPS together will give you
a better time solution, although it will definitely improve
availability.

>
> 2. I would like to get both NMEA and PPS signal from it on the NTP server.
> Currently PPS is on pin 8 (CTS) but according to
> http://doc.ntp.org/4.1.1/driver22.htm and
> https://www.satsignal.eu/ntp/NTP-on-Windows-serial-port.html it should
> rather be on pin 1 (DCD).

Well actually the PPS RFC https://tools.ietf.org/html/rfc2783
while referring to "DCD implementations for serial line" does not
specify at all which signals should be used. Which makes sense because
is PPS for parallel port as well. At any rate, I've seen that most
GPSDOs (including the two I have, BG7TBL and Oscilloquarts STAR 4) use
CTS, whereas the use of DCD typically applies for standalone GPS
receivers. There are two things you could one of these:
(1) build your own RS232 cable and hook the PPS signal from the GPSDO
db9 pin 8 (CTS) to the db9 pin 1 (DCD) on the other side.
(2) recompile the RS232 driver and swap DCD with CTS in Linux
(3) use FreeBSD instead, which supports runtime configuration of
either DCD or CTS for PPS

I use the latter, as I am big fan of FreeBSD

> Is it possible to use it anyway on Linux NTP
> servers, or is it better to split it to 2 different COM ports – one for
> NMEA, second for PPS? Or maybe is it better to use PPS from BNCs or get
> some additional device and use 10MHz signal?

Even if you are distributing the PPS signal you are still distributing
a clock with strict timing requirements. Clock termination is very
complex especially if you are distributing it. You are probably better
off at using either an RS232 buffer or a TTL buffer and have two
separate outputs. But you should probably seek other opinions here,
and I am not hugely familiar with the analog aspect of clock
distribution.

>
> 3. I'm thinking of using Linux as the NTP server with recompiled kernel
> options for some better precision. But maybe there is a Linux/FreeBSD/other
> system distribution prepared especially for NTP servers?

As mentioned above, I am big fan of FreeBSD despite of -- or perhaps
because of -- having done kernel development on both. To answer your
specific question, there is no distro especially "tuned" to for NTP.
PPS support is standard on both. Which kernel, OS and distro you
should use is a matter of preference, unless you want to use FreeBSD's
already built-in runtime configuration for DCD/CTS support.

> I will probably
> install additional Intel i210 network card for future PTP usage.

This is a great idea. I've been thinking to do the same, provide both
NTP and PTP time services. Note that PTP can also be implemented with
a pure software stack, although you'll use hardware timestamping, and
so it'll be less accurate than a pure hardware solution.

> Do you have any other suggestions for the hardware/software of NTP server?

My *TOP* recommendation would be to avoid using the PC's built COM
port, as many implementations rely internally on an ISA bus instead of
PCI, which has higher interrupt latencies. Personally I use a separate
RS232 port on PCI-e (PCI express), which also has the added advantage
of proving either 12V or 5V on the  pin 9 RING signal, so you can use
it to directly power a GPS receiver like the Garmin 18 with serial
output.

I use this one for a PC:

https://cdn.cnetcontent.com/53/1c/531c2b50-18a9-416a-967b-2104530b205f.pdf

You can buy it on Amazon for about $35

If you decide to go to a smaller embedded box like PCENGINES, you can
use this mPCI RS232 card:

https://www.sybausa.com/index.php?route=product/product&path=64_77_189_81&product_id=719

Another advantage is that these chipsets typically support higher baud
rates (which I hope translate into higher rise time detection for
DCD/CTS) as well as accepting TIA-RS232-F signalling, which is to say
TTL signals with 0V = false, 5V = true. One of the other stratum-1
servers I have uses one of these cards with the Garmin 18x LVC, which
outputs TIA-RS32-F signals.


The biggest problem for using RS232 for PPS input is interrupt
latency. Generally speaking it is in the order of approximately 10
microseconds (from PPS signal assertion to the kernel's interrupt
handler which records the pps event). I just modified the UART driver
in FreeBSD to support PPS_ECHOASSERT and PPS_ECHOCLEAR. Right after
recording the timestamp the interrupt handler echoes DCD to DTR, or
CTS to RTS, depending on how CTS/DCD is configured. This be used to
get an accurate measure of the interrupt latency. You will still have
interrupt latency jitter, but you can at least eliminate the delay.

I just wrote the code and tested it with an RS232 led dongle. I'm
going to then use the oscilloscope to measure my interrupt latency.
Even though I haven't done this yet, I'll happily share the source
code. I'd just need to put in my github repo.

Bets of luck :-)

>
> Thank you all in advance,
> Adam Kumiszcza
> _______________________________________________
> 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.