Selecting a GPS receiver for use as a NTP server reference involves some trade offs. It can be a deep rabbit hole with seemingly no bottom if you just start studying spec sheets.
I believe the first step is define the role of the server and needed vs desired accuracy on your real network. My goal was 1 millisecond time with sub 500 microsecond jitter / wander. Remember that network traffic and congestion in network devices like switches can have impacts greater than instability of the time source. So some extended ping testing under varying network conditions can be helpful to get an idea of network induced error. Looking at standard deviation of ping time is one good indication of problems to be solved before proceeding.
Assuming your goals are relatively modest like mine and the network checks out OK, the next step is finding a suitable GPS receiver.
A few things we are looking for here are: Standard NMEA 183 output, 1 PPS output pulse and serial rather than USB interface. Provision for an external antenna is a great feature and may be a requirement depending on the situation. Although a USB interface may sound good, because of the way communication is achieved by asynchronous polling of the host device, a lot of uncorrectable variability occurs compared to old-fashioned RS232 serial, even at low baud rates like 4800. I haven’t actually evaluated USB and what this means from a practical standpoint, however. The PFSense document on NTP does not recommend USB.
GPS receivers can be divided into two broad classes with some crossover. Most receivers are position/navigation optimized devices. But there are those that are designed specifically for timing applications. Navigational units need to deal with triangulation from multiple sats at different elevations and also with motion. Their algorithms have location parameters as their priority which slightly degrades timing accuracy. Timing GPS receivers are different. They can go into a “position hold” mode at previously established coordinates and even look at just one satellite to achieve very low jitter on the 1 pps pulse. The internal circuits including the clock oscillator and those that process the pulse are also optimized so that 10-15 nanosecond specs are typical of this class. About 10 to 100 times better than your average navigation GPS. These are probably overkill for a home lab though. They tend to be expensive ‘niche” devices. Another class of receivers from the innovative U-Blox people have part numbers that end in “T” like 5T 0r 6T. The T stands for timing, and they are a hybrid design that combine good positional performance, but can go into position hold and behave as very accurate timing receivers. They use an internal TCXO rather than a regular crystal oscillator for better hold-over stability.
Thus far, I have evaluated three receivers and compared their relative NTP performance on PFSense. One was already in stock and the other two were purchased.
The first RX was a CSI Mini-Max, a marine oriented unit with WAAS and differential GPS capability, but no pps output. The second was a Garmin GPS18x-LVC, a hockey-puck style OEM 12 ch receiver with a built-in patch antenna, WAAS, and PPS pulse output. The third was an inexpensive U-Blox 6M module modified to generate PPS from it’s blinking LED and it’s 3.3V logic i/o converted to RS232 by way of a Max3232.
All performed well enough in a home lab, for all but the most critical applications. That said, the addition of the 1 pps pulse makes a significant improvement. See the graph below. It shows the Garmin unit running without the PPS signal line connected in the first portion, and the effect of connecting the PPS line toward the mid-portion of the graph. Jitter, wander and dispersion all decrease dramatically.
The Garmin 18x is a very good performer. It had adequate sensitivity to pick up 8-10 sats indoors. A real achievement with the foil-backed insulation in the ceiling. It’s also very convenient to use. It has standard RS232 serial output, and just needs 5V at about 60 mA; that can be robbed from a nearby USB port. I have it sitting on the top of my 6ft rack staring up towards the roof. It also has a handy magnet on the bottom to hold it to ferrous metal.
Finally, the little U-Blox 6M also worked very well. Maybe just a bit more jitter at times than the Garmin, but still well within my design goals. Again, this was indoors. It was eventually assembled in a 3D printed PETG case that can be mounted outdoors with a 20M length of shielded Cat5 cable carrying both the serial data and 5v power. A modified RJ45 to DB9 adapter inserts the power at the computer end of the cable. The base has screw holes to fasten to a flat surface. The UBlox people have a very nice piece of software (Windows only) called U-Center that allow many, many different parameters to be changed and saved to flash in these modules. I merely set the baud rate, turned on the PPS LED and set it’s duty cycle, but there are a lot more options to explore here. I might have missed something really good…
Next NTP experiments may be using a Raspberry Pi4. I also have a U-Blox LEA-5T based surplus timing board coming on a slow boat from China (literally) It’s a GPS/GNSS module optimized for timing applications. It has the fixed position mode available and can use a single satellite. Should be interesting to compare and program with U-Center. More fun to come.
Dave, K7DMK
