In this post, I will explain how to do this, using two different NTP servers: chrony and ntpd-rs.

Hardware

Before we get into the details of configuration, let me say something about GPS hardware. When using a Raspberry Pi, the PPS signal is connected to a GPIO pin on the Pi. This means that the time of the PPS edge is measured in software by the kernel, rather than in hardware. The accuracy you will get is in the microsecond range. Basic GPS receivers can achieve an accuracy of 50ns in normal conditions. So my main hardware advice is that in this context a fancy, expensive GPS receiver will not deliver any measurable benefit.

GPS receivers are available in a Pi HAT form factor, which plugs into the 40-pin GPIO header. These HATs typically wire the GPS PPS signal to pin 12 (GPIO 18). I do not recommend these when using PHC hardware, because the GPS PPS signal needs to be wired to the SYNC_OUT pin on a different header. But when using a normal Raspberry Pi, they are very convenient, although you typically pay a premium for this convenience.

Setup

The following steps can be done exactly as described in SatPulse Setup Guide.

1. Install Raspberry Pi OS
2. Configure the UART
3. Install SatPulse but choose the 0.2 pre-release
4. Verify the GPS serial connection; the device will be /dev/ttyAMA0

Configuration of kernel PPS is different. First, configure pin 12 (GPIO 18) as a PPS pin, by adding the following at the bottom of /boot/firmware/config.txt

dtoverlay=pps-gpio,gpiopin=18

Reboot after this. To verify the PPS signal is working, install pps-tools using

sudo apt install pps-tools

Then do:

sudo ppstest /dev/pps0

It should show PPS events once per second:

trying PPS source "/dev/pps0"
found PPS source "/dev/pps0"
ok, found 1 source(s), now start fetching data...
source 0 - assert 1775392263.000000336, sequence: 170178 - clear  0.000000000, sequence: 0
source 0 - assert 1775392264.000000215, sequence: 170179 - clear  0.000000000, sequence: 0
source 0 - assert 1775392264.999998780, sequence: 170180 - clear  0.000000000, sequence: 0
source 0 - assert 1775392265.999999085, sequence: 170181 - clear  0.000000000, sequence: 0

Exit with Ctrl-C.

Now you need to edit /etc/satpulse.toml. Most important point is to remove the [phc] section. All you need is this:

[serial]
device = "/dev/ttyAMA0"
# fix to match your serial device speed
speed = 9600

[gps]
config = true
vendor = "u-blox"

# Enable HTTP monitoring on port 2000
[[http]]
listen = ":2000"

[ntp]
# Use this for chrony
sock.path = "/var/run/chrony.satpulse.sock"
# Use this for ntpd-rs
# sock.path = "/run/ntpd-rs/satpulse.ttyAMA0.sock"

Uncomment the sock.path line for whichever of chrony or ntpd-rs you use.

You can now start SatPulse using

sudo systemctl start satpulse@ttyAMA0

You can point a browser at port 2000 and you should get a page showing information from the GPS receiver.

Chrony

To configure chrony, first install with

sudo apt install chrony

Then create a file /etc/chrony/conf.d/satpulse.conf with the following:

refclock PPS /dev/pps0 poll 2 lock GPS refid PPS
refclock SOCK /var/run/chrony.satpulse.sock offset 0.1 delay 0.2 refid GPS noselect

The refclock PPS line makes chrony use the kernel PPS API to read PPS samples from /dev/pps0. These are accurate but lack time-of-day information. The refclock SOCK line makes chrony read samples generated by satpulsed. These are inaccurate but include time-of-day. The offset 0.1 corrects for serial messages coming 0.1 second after the top of the second.

Chrony can use the samples from satpulsed to complete the PPS samples. Chrony can also use samples from other NTP servers to complete the samples, so if you want to check that this is really working, you should at least temporarily comment out the pool line from /etc/chrony/chrony.conf.

ntpd-rs

Ubuntu has announced plans to adopt ntpd-rs as its default NTP server, replacing chrony, primarily because of memory safety. Since SatPulse is written in Go, the combination of ntpd-rs and SatPulse provides a fully memory-safe timing stack. Like SatPulse, ntpd-rs uses TOML for its configuration files and supports Prometheus, so the combination makes for a pleasantly harmonious configuration and observability experience.

To install, download a deb file from the Releases page. You need at least version 1.7.2. (The version in Raspberry Pi OS will not work.)

Next, you will need to remove your existing NTP daemon (e.g. systemd-timesyncd or chrony):

sudo apt remove systemd-timesyncd chrony

Then install ntpd-rs

sudo dpkg -i ./ntpd-rs_1.7.2-1_arm64.deb

Now you need to set things up so that ntpd-rs can access /dev/pps0. Create a file /etc/udev/rules.d/99-ntpd-rs-pps.rules containing the line

KERNEL=="pps0", GROUP="ntpd-rs", MODE="0640"

This ensures that when /dev/pps0 is created at boot time it will have a group and permissions that enables ntpd-rs to access it. To make this take effect without booting, do

sudo udevadm control --reload
sudo udevadm trigger /dev/pps0

Now we need to configure ntpd-rs. Put the following in /etc/ntpd-rs/ntp.toml:

[observability]
log-level = "debug"
observation-path = "/var/run/ntpd-rs/observe"

[[source]]
mode = "pps"
path = "/dev/pps0"
precision = 1e-7
accuracy = 1e-6

[[source]]
mode = "sock"
precision = 1e-2
path = "/run/ntpd-rs/satpulse.ttyAMA0.sock"
accuracy = 0.2

[synchronization]
minimum-agreeing-sources = 1

[[server]]
listen = "0.0.0.0:123"

When I tried initially to get this working with version 1.7.1 of ntpd-rs, it didn’t work. I submitted an issue, and within a day one of the developers, David Venhoek, had added a feature to enable this configuration. This was included in version 1.7.2, released a few days ago. It adds the ability to specify the accuracy of sources as distinct from their precision. Accuracy means how close measurements are to true time. Precision means how much measurements vary from each other. The serial timing measurements from satpulsed are quite precise but are extremely inaccurate. Specifying a low accuracy for samples from satpulsed ensures that ntpd-rs uses the PPS samples as the primary source, and uses the satpulsed samples just to complete the PPS samples. But note that if you specify an accuracy of 0.25 or worse, you need to increase maximum-source-uncertainty from its default of 0.25.

Now you can start ntpd-rs using

sudo systemctl start ntpd-rs

You can verify it’s working by using

ntp-ctl status

The release notes have more information.

I would be grateful if you could try it out and let me know how you get on.

I created a discussion thread where you can ask questions and share experiences.

Before getting into the details of the supported modules, I want to talk about what supporting a GPS module means. All GPS modules support NMEA which provides information about navigation solutions as they are computed by the module. GPS modules also support RTCM, which is used both to consume corrections provided to the module and to provide corrections for use by other modules. Apart from that, every GPS module supports one or more vendor-specific protocols. The messages used by these protocols can be divided into two groups. The first group performs a similar function to NMEA: they are messages periodically emitted by the module to provide information about the navigation solutions computed and other aspects of the ongoing operation of the module. The second group performs configuration: these include both requests that are input to the module to query and alter configuration, and messages that are output by the module as responses to these requests. Supporting a module involves enabling SatPulse to make use of both kinds of message.

SatPulse supports vendor-specific periodic messages in the obvious way, by converting vendor-specific messages into a uniform abstraction. In the source code, this abstraction is defined by the gpsprot (GPS protocol) package. In 0.1, there were abstract messages that provide information about

• the current time in either UTC or TAI; also includes sawtooth error/quantization error and time accuracy
• the progress of a survey-in operation
• the next scheduled leap second
• satellite positions and signal strengths

In 0.2, there are additional messages that provide information about

• the characteristics of a navigation solution; this includes
  • the technique used to compute the solution (e.g. ranging code or carrier phase)
  • dimensionality of the fix i.e. 3D, 2D or time only
  • what sensors beyond GNSS contributed to the solution (e.g. INS)
  • kinds of corrections used (e.g. SBAS, RTK, PPP)
  • accuracy (position, velocity)
  • DOP in all its flavours
  • age of differential corrections
  • GNSS constellations and bands used in computing the solution
• position, in ECEF or geodetic coordinates
• velocity, in ECEF or geodetic coordinates (i.e speed and course-over-ground, or NED)

These abstract messages can be serialized as JSON, and can be seen in the event log, which also includes information about pulse edges. The messages also feed the observability subsystem, which exposes them as Prometheus metrics.

For configuration, there are now two kinds of configuration support as I described in more detail in my earlier blog.

• high-level configuration, intent-based configuration, where you describe what you want, and SatPulse turns that into the appropriate messages for the specific module
• low-level configuration, which is based on message files

High-level configuration in 0.2 provides a similar set of features as in 0.1. There are a couple of new properties that can be set:

• minimum elevation angle for satellites to be used in the navigation solution
• RTCM base ID - the reference station ID for the RTCM messages that the module generates

I have added a few features to the message file implementation since the last blog:

• the message file implementation now understands the request/response patterns of various protocols, which allows it to identify which messages from the module are responses to messages sent
• there is a file inclusion capability, which is useful for allowing model-specific message files to share messages that work across multiple vendor models

The high/low-level configuration split leads naturally to two tiers of support. In both tiers, there is

• support for generating the full range of abstract messages from the vendor-specific messages
• support for the protocol in the message file implementation

The difference is that Tier 1 provides configuration support primarily via the high-level mechanism; message files are used to supplement this to support vendor-specific features that are not exposed via high-level configuration, whereas Tier 2 uses message files to provide configuration support. For Tier 2, the provided message files use a common set of conventions for tags, which provides a degree of vendor-independence in the user interface.

SatPulse 0.1 had support only for u-blox. In 0.2, there is support for the following vendors

1. u-blox - tier 1
2. Unicore - tier 1
3. Quectel - tier 2
4. Zhongke/CASIC - tier 2
5. Allystar - tier 2
6. Techtotop/Taidou - tier 2
7. ByNav - tier 2
8. ComNav/SinoGNSS - tier 2

Apart from u-blox, these vendors are all based in China. There are other Western vendors, but they are all either much more expensive than u-blox (Septentrio, Trimble, NovAtel) or the chips are designed to be integrated into mobile phones and are not available as modules that you can buy separately (e.g. Broadcom). Septentrio has recently come down in price a bit and they also have an excellent reputation for timing, so I hope to add support for Septentrio in the future. I already have some support for NovAtel, because some Chinese vendors have adopted the NovAtel OEM 6/7 series protocol.

I have chosen which Chinese modules to support based on a number of factors:

• Are they at least dual-band? Given the low cost of dual-band modules, there are relatively few cases where single-band modules remain interesting.
• Do they have any features that are particularly interesting for precision timing and/or positioning?
• How common and popular are they on Taobao?
• Are there any Western vendors that resell them?

Taobao recently started supporting direct shipping to my country of residence, which makes using Taobao much more convenient. I have found Taobao vendors to be considerably more knowledgeable about what they are selling than AliExpress vendors. If you can buy from Taobao, I recommend it.

u-blox

SatPulse supports all u-blox modules starting from LEA-6T all the way through to ZED-X20P. I have tested it on all timing modules:

• LEA-6T
• LEA-M8T
• LEA-M8F
• ZED-F9T (both L1/L2 and L1/L5 variants)
• NEO-F10T

and on both current high-precision modules:

• ZED-F9P
• ZED-X20P

and on many standard precision modules, including:

• NEO-M9N
• M10050-KB
• NEO-F10N (which is L1/L5)

In 0.2, the improvements in u-blox support are:

• support for richer information (navigation solution characteristics, position, velocity)
• support for additional configuration properties (minimum elevation and RTCM base id)
• support for ZED-X20P

I have done much more testing on u-blox modules than on any other brand.

Unicore

There is tier 1 support for the UM980 family, which consists of

• UM980, base model, which includes support for Galileo HAS (which is promised but not yet available for u-blox ZED-X20P)
• UM981, adds INS
• UM982, adds dual antennas
• UM960, lower end version, without PPP support

These use a protocol which is similar to that used by NovAtel OEM6/7 messages. Periodic data messages have dual binary/ASCII formats; the packet formats are similar, but the binary packet format has different sync bytes. Configuration messages are ASCII lines, similar but different from NovAtel. These modules also have some undocumented support for some periodic data messages that use the same packet format as NovAtel. This includes the RANGECMPB raw message which can be used by RTKLIB to generate RINEX observation files.

In the West, these modules are distributed by ArduSimple, gnss.store and SparkFun.

SparkFun have a GitHub repo with the latest UM980 firmware.

Unicore have another range of modules UM6XX, which uses a completely different protocol, which is not yet supported.

Quectel

Quectel have a bewildering array of GNSS modules. There are two families that I find interesting and that SatPulse supports:

• LG290P family - this is Quectel’s high-end module which includes support for Galileo HAS in the most recent firmware
  • LG290P is the base model
  • LG580P is the dual antenna variant
  • LG680P is the LG290P in the 22x17mm u-blox ZED form factor
• LC29H family - this is a relatively inexpensive L1/L5 model based on the Airoha AG3335 chipset; there are several variants, of which the most interesting are:
  • LC29H(AA) is the best fit for base-station case; it can produce RTCM corrections but does not have the RTK engine that can consume them; it is supposed to get OSNMA support at some point
  • LC29H(DA) is the one that is suitable for use as an RTK rover

Quectel’s vendor specific protocol uses the NMEA proprietary extension mechanism. The NMEA sentences start with $PQTM (The P is the NMEA proprietary extension mechanism, and QTM is Quectel’s 3-letter identifier). The LG290P supports a richer set of PQTM messages than the LC29H. The LC29H also supports some NMEA proprietary sentences defined by Airoha; these start with $PAIR.

In the West, SparkFun sell an LG290P board. They also have a GitHub repo with the latest LG290P firmware.

On Taobao, a good shop to buy from is Mozi Technology/Mozihao.

Zhongke/CASIC

Zhongke Microelectronics is best known for the ATGM332D and ATGM336H series of modules. The difference between these is the form-factor: ATGM332D uses the u-blox NEO form factor, whereas the ATGM336H uses the MAX form factor. The notable feature of these modules is that they are extraordinarily cheap. The bare module (without a board) is about $1.25 on Taobao.

The vendor-specific protocol is CASIC. CAS stands for Chinese Academy of Sciences, and Zhongke in Chinese also refers to the Chinese Academy of Sciences. The CASIC protocol is UBX-like.

There are literally dozens of different versions of these modules, and there are some very significant differences between them.

The most common version is ATGM332D-5N31. These module names follow a common pattern. The ‘5’ indicates the generation of the chip used (in this case, the AT6558). ‘N’ likely stands for navigation. The ‘3’ designates which constellations are supported: 1 means GPS, 2 means BeiDou, 4 means GLONASS, and these are added together to indicate the set of constellations supported. So 3 means GPS+BeiDou and 7 means GPS+BeiDou+GLONASS. I haven’t figured out how the final digit works.

There is a more recent and less common 6 series (e.g. the ATGM332D-6N74) which adds support for Galileo. This uses the AT6668 chip. More interestingly, there is also an F8 series (e.g. ATGM332D-F8N76), which is dual-band. This uses the AT9880 chip. It is not common yet but I expect it will become common: like the rest of the ATGM332D series this is extraordinarily cheap, about $2.15 on Taobao; it seems to be the cheapest dual-band module in the world.

The 5 series use a default baud rate of 9600, whereas the 6 and F8 series use 115200. More significantly, although they all use the same packet format, the 6 and F8 series support a different set of messages. The 5 series uses NAV class messages, whereas the 6 and F8 series uses NAV2 class messages.

There is some English language documentation available for the version of CASIC that uses NAV messages; there is nothing available on the NAV2 messages. Fortunately, one of my Taobao sellers was able to supply me with a Chinese language protocol manual which describes this version of CASIC. SatPulse has support for both the NAV messages and the NAV2 messages.

As well as the low-end ATGM332D/ATGM336H modules, Zhongke also make higher-end modules designed explicitly for timing. I have the AT632-6T-30. This is similar to the 6 series of the ATGM332D, and is L1 only, but has a full set of timing features, which makes it interesting. These use a TIM2 class of message. In particular it has a TIM2-TPX message including quantization error. It is interesting to have a modern L1 timing module; u-blox have not done an L1 timing module since the LEA-M8T. One noticeable difference is that the peak-to-peak amplitude of the sawtooth error is about 6ns on the AT632 compared to 21ns on the M8T, presumably reflecting the higher clock speed of the more modern module.

Zhongke provide a GnssToolkit3 application for Windows for configuring their modules.

Allystar

I first came across Allystar because of their TAu1201 module, which has been one of the cheapest L1/L5 modules available. The StarRiver store on Taobao sell a variant of their SR1723 board with the TAU1201. This costs about $7.50. With various fees, shipping and tax to Thailand, the all-in cost is about $10.50. In the West, it will be a bit more. The TAU1201 uses their Cynosure III chip. Their latest chip is Cynosure IV, which is available in the TAU951M-P200. This is a more expensive module that also does RTK.

Allystar provide a Windows app called Satrack for working with Allystar modules.

Allystar’s binary protocol is UBX-like. They haven’t done a particularly thorough job of it. For example, the message that provides information about satellite positions and signals provides less information than is available via NMEA, and Satrack doesn’t make use of it.

Bynav

Bynav makes M20/M10 series of modules based on their own Alice 22nm SoC. They are strong in the automotive industry. I have been mainly testing with the M20, but have also tried the M10. The M21 adds an IMU on top of the M20; the M22 adds a slightly better grade of IMU. The M20D adds dual antennas. The M10 is a smaller-footprint, cheaper, lower-end version of the M20 (update rate of 10Hz vs 50Hz on the M20). They seem pretty decent for RTK.

Bynav’s vendor-specific protocol is NovAtel-style. Their binary and ASCII packet formats for periodic messages (called logs in NovAtel parlance) are exactly the same as documented by NovAtel for the OEM6/7 range. Bynav support some messages defined by NovAtel and add some messages of their own. The configuration commands are NovAtel-style, but not compatible.

In the West, they are sold by gnss.store.

ComNav/SinoGNSS

This company brands itself as ComNav Technology for Western audiences, but uses SinoGNSS for Chinese audiences. Their latest modules are the K9xx series. Base module is K901. K902 adds an IMU. K922 adds dual antennas. They all have support for Galileo HAS. These are widely available on Taobao.

The protocol documentation on the ComNav site is rather out of date. My Taobao seller gave me the current Chinese-language protocol documentation, which was from another company called Qeetek, which also advertises these modules. So I suspect these modules are actually made by Qeetek.

The situation with the protocol is very similar to Bynav. Their binary and ASCII packet formats for periodic messages are exactly the same as NovAtel. They support some messages defined by NovAtel and some of their own. The configuration commands are NovAtel-style, but not compatible. But the configuration system is not in my view well-designed. One major deficiency is that it does not allow the current configuration to be queried. Another problem is that responses to configuration commands are not designed to be machine readable: they are not wrapped in a protocol packet that allows them to be distinguished from other traffic from the module.

Apart from the weakness in the configuration protocol, I found convergence of both Galileo HAS and its BeiDou equivalent (B2b-PPP) to be flaky.

Techtotop/Taidou

I had not heard of Techtotop, known in Chinese as Taidou, until a month or so ago. They make their own GNSS silicon, but they seem to be almost completely unknown outside China.

I find them interesting because they have relatively inexpensive modules specifically designed for timing. The one I have is the T303-5D, which is an L1/L5 module. This isn’t on their web site, but I believe it is just a smaller footprint version of the T302-5D. I got this module from this shop on Taobao.

It uses a UBX-style protocol called SDBP, about which there appears to be exactly zero information available in English. My Taobao seller was able to provide a Chinese language protocol manual with full details. The quality of documentation and protocol design seem good to me: it has everything I expect of a timing module, including quantization error reporting.

Techtotop also provide the TDMonitor application for Windows, which is similar to u-center (although the UI is all Chinese).

Where SatPulse is heading

My vision for SatPulse 0.1 was quite narrow: to transfer time from a GPS module to a PTP hardware clock. But it turns out doing a really good job of that requires a complex and sophisticated GPS subsystem. The subsystem should work for GPS modules from many vendors not just from u-blox. When monitoring a timing GPS, you want rich information about the current state of GPS, including the characteristics of the navigation solution. And it turns out that getting position information from the GPS is also useful: for example, you may want to use HAS to establish the fixed position to be used in timing. If you have done the work to create a GPS subsystem that works well for timing, you have done at least 80% of the work to create a GPS subsystem that works well for a wide variety of other applications. It makes sense to do that extra work, because the market for timing is relatively small: many more people care about precision positioning than care about precision timing. So this is where I am heading with SatPulse: precision timing is still a core part of the mission; but I want to add the few extra features that are needed to make SatPulse useful for a broader range of applications, in particular precision positioning.

I have hooked this up to SatPulse’s GPS auto-configuration system (enabled with config=true in the [gps] section). So when you have an [ntp] and no [phc] section, it will configure the GPS appropriately (e.g enable a PPS, enable time mode, enable messages reporting UTC time). I think this will provide quite a nice way of running an NTP server: as well as auto-configuration, you get the other SatPulse conveniences like a Web dashboard and Prometheus metrics.

I have only tested this very lightly. I used the chrony PHC extpps option to test, since all my machines are currently set up with the PPS connected to a PHC. I used the following as the satpulsed configuration:

[serial]
device = "/dev/ttyACM0"
speed = 38400
[gps]
config = true
vendor = "u-blox"
[ntp]
sock.path = "/var/run/chrony.satpulse.clk.sock"

and then used this as my chrony configuration:

refclock PHC /dev/ptp0:extpps:pin=1 width 0.1 poll 2 lock NMEA refid PPS
refclock SOCK /var/run/chrony.satpulse.clk.sock offset 0.1 delay 0.2 refid NMEA noselect

The lock NMEA option tells chrony to use the samples from SatPulse to complete the PHC samples; the noselect option tells chrony not to use the SatPulse samples as an independent time source.

Using chrony to read the PHC like this has one advantage over using SatPulse with a [phc] section: SatPulse will adjust the phase and frequency of the PHC, which is what you want for PTP, whereas chrony will leave it free-running. This makes it easy to use the hardware-timestamping feature of chrony, which requires a free-running PHC. With SatPulse, you would need to use a virtual PHC, which I have not yet implemented support for. So using chrony like this is right now the best approach if you want NTP hardware timestamping and are not interested in PTP.

How GPS receivers communicate

To understand why this feature is useful, it helps to understand how GPS receivers work at the protocol level. There are three layers: packet format, periodic messages, and configuration.

GPS receivers communicate over a serial connection by sending and receiving a byte stream consisting of a sequence of packets. Each packet has a specific format, and the stream can mix packets in different formats. A packet format defines how to represent a message type and a type-specific structured payload as a sequence of bytes with a checksum. NMEA 0183 is the most important standard packet format. A NMEA packet is called a sentence: it starts with $ and ends with a two-character hex checksum and CR/LF. The payload is represented as comma-delimited ASCII fields. RTCM 3 is another standard packet format, used for GPS correction data such as RTK base station observations. It uses a binary encoding with a 24-bit checksum. Many vendors define their own proprietary binary packet formats. For example, u-blox defines the UBX format.

GPS receivers compute position-velocity-time (PVT) solutions periodically, typically once per second. For each solution, they output messages with the results of the solution, and other information about how the solution was computed (such as the satellites used). These messages will be represented as message types in a packet format. NMEA defines standard sentence types, such as RMC, GGA, GSV for this and all GPS receivers support them. Almost all GPS receivers can also emit other periodic messages that provide information beyond what can be expressed by standard NMEA sentences. Some GPS receivers make use of the extensibility mechanism provided by NMEA (“proprietary sentences” beginning with $P), but many others use messages in proprietary binary packet formats.

All GPS receivers provide a configuration mechanism. At a minimum they provide a way to control the speed of the serial connection and which messages are emitted. But most GPS receivers allow for many aspects of their operation to be configured, for example, which constellations they should use or the width of the PPS pulse that they should generate. For GPS configuration, it is completely vendor-dependent: there is no standard. Configuration requires communication in both directions: from host to GPS receiver and well as from GPS receiver to host. As with periodic messages, configuration uses packets. RTCM 3 messages go both from host to receiver as well as from receiver to host, so GPS receivers need to be able to deal with a mix of packet formats in the input they receive.

I have seen three different approaches to configuration.

• Configuration uses the same binary packet format used for periodic messages. UBX is the most common example of this. A few other vendors use UBX-like protocols: CASIC (Zhongke Microsystems) and Allystar
• Configuration requests (from host to receiver) use NMEA proprietary sentences; responses may be either standard NMEA TXT sentences or proprietary sentences. Quectel is one vendor that uses this approach.
• Configuration requests use plain ASCII lines (usually CRLF terminated); responses are typically some sort of ASCII packet. Septentrio and NovAtel both use this approach. Their products are both very high-end, but several Chinese vendors have adopted protocols based on NovAtel, notably Unicore, SinoGNSS (ComNav) and ByNAV, in more affordable products.

SatPulse 0.1

SatPulse 0.1 internally uses protocol-independent interfaces for all three layers, but they are implemented only for UBX.

It might seem unnecessary to have such abstraction for only one protocol, but in fact UBX has many versions which have major differences. Only the packet layer of UBX remains constant between versions. The periodic message layer has significant differences: different versions of receivers support different messages. With the configuration layer, u-blox receivers from generation 9 onwards use a completely different approach from receivers of generation 8 and earlier. The earlier generations have separate message types for each aspect of configuration. The later generation uses a single message that wraps a completely separate key-value configuration system: this allows multiple configuration changes to be performed atomically by a single message.

The fundamental idea in 0.1 is to create protocol independent representation of all the configuration that needs to be done. This representation has two parts:

• it specifies the desired values for various properties; for example, it might say that the time pulse should have a pulse width of 0.1s,
• it specifies various operations that should be performed; for example, it might say that the configuration of the receiver should be saved to non-volatile memory This representation is handed over to a protocol-specific subsystem, which does as much of what was requested as the receiver supports. It then returns the actual properties that the receiver was able to implement. For example, there is a property for the set of GNSS signals that should be enabled. If you request that L1 and L5 signals should be enabled, but the receiver only supports L1, then it will enable L1 and return a property with only L1 being enabled.

You might ask: why bother with all this? SatPulse works best if the receiver is configured in very specific ways. My goal is to provide a “just works” experience: so I want SatPulse to be able to detect what kind of receiver it is and automatically configure it so that it works optimally. SatPulse 0.1 does achieve this for a broad range of UBX receivers.

Multi-protocol support

One of my main goals for SatPulse after version 0.1 is to make it truly multi-protocol. It is one thing to design an interface to be protocol-independent. It is another thing for it to actually work well for a range of protocols. In choosing the second protocol to support, I wanted a protocol that was rich and sophisticated, completely different from UBX and has decent documentation.

I decided on the protocol implemented by the UM98x series of GPS receivers from Unicore, which is based on the NovAtel OEM 6 and 7 protocols. This is primarily designed for the RTK market, but it works well for timing also. Periodic messages (which are called logs in the NovAtel world) have dual binary/ASCII representations. Configuration requests use plain ASCII lines; responses are NMEA-like.

In implementing the configuration support for the UM98x, I substantially reworked the configuration interface. The objective is to make the protocol-specific code as simple and testable as possible. The protocol-specific code is completely deterministic and does no IO. An intermediate protocol-independent orchestration layer does IO and manages retries and timeouts.

The documented UM98x packet formats and logs are similar but distinct from the NovAtel OEM6/7 ones. But it turns out that UM98x can also be configured to generate packet formats and logs that are exactly as defined in the NovAtel documentation. These packet formats and logs are also implemented by a couple of other recent Chinese GNSS receivers (Bynav M20 and SinoGNSS K901), so I also implemented support for these.

GPS message files

The approach to configuration in 0.1 has some fundamental limitations:

• it’s a lot of work to implement configuration support
• if this work has not been done for a receiver, then SatPulse provides no help at all in configuration
• if you want to configure a receiver feature that SatPulse does not support, then again SatPulse provides no help

Most vendors provide a proprietary, but free-to-use Windows GUI app that can be used to configure their receivers. For example, u-blox provides u-center. In practice, for many configuration tasks with SatPulse 0.1, users would have to rely on these Windows apps. For users living on Linux or macOS, this is not a good situation.

The multi-protocol support is a nice addition but does not address these limitations.

In the last week, I have implemented an alternative, more pragmatic approach to configuration that tries to address these limitations. The approach is a simple one: have a file that defines messages that can be sent to the GPS receiver. There is a new -m/--msg-file option for satpulsetool gps that specifies the message definition file. This does not use the configuration abstraction at all and allows arbitrary messages to be sent to the receiver. Since the main SatPulse configuration file is TOML, I also chose TOML for the format of this definition file.

Here’s a simple example. The Unicore UM980 supports Galileo HAS, but SatPulse configuration abstraction does not yet have anything for this. To enable Galileo HAS, create a file um980-has.toml.

[[line]]
text = "CONFIG PPP ENABLE E6-HAS"
[[line]]
text = "CONFIG PPP CONVERGE 10 20"

Each [[line]] block defines a text command. Run it with:

satpulsetool gps -d /dev/ttyUSB0 -s 115200 -m um980-has.toml

This will send each line, terminated with CR/LF by default. When used in this simple way, the main problem that this solves is enabling the user to see how the GPS receiver responded to the message. Since SatPulse knows about packet formats, it can intelligently identify which packets might be responses to the message and display only those. If you use cat and stty, you have no idea how the receiver responded. If you try to use a terminal emulator, the periodic messages being continually output by the receiver (which may include binary) makes it difficult to see the responses. There is also a --packet-log option that allows you to capture all packets sent and received.

NMEA message type

The nmea message type is similar to line, but it knows about NMEA checksums. For example, this is how to configure PPS on a Quectel LG290P.

[[nmea]]
text = "PQTMCFGPPS,W,1,1,100,2,1,0"

The tool prepends $ if missing and appends the checksum automatically.

Message libraries

The message file can also be used to create a library of messages. Each message can be given a tag and a description.

[[nmea]]
text = "PQTMCFGMSGRATE,W,RMC,1"
tag = "nmea-daemon"
description = "Enable NMEA messages understood by satpulse daemon"
[[nmea]]
text = "PQTMCFGMSGRATE,W,GGA,1"
tag = "nmea-daemon"
[[nmea]]
text = "PQTMCFGMSGRATE,W,GSA,1"
tag = "nmea-daemon"
[[nmea]]
text = "PQTMCFGMSGRATE,W,GSV,1"
tag = "nmea-daemon"
[[nmea]]
text = "PQTMSAVEPAR"
tag = "save"
description = "Save configuration to NVM"

Run specific tags with -t:

satpulsetool gps -d /dev/ttyUSB0 -s 460800 -m quectel.toml -t nmea-daemon,save

The --show-tags flag lists available tags with descriptions.

satpulsetool gps -m quectel.toml --show-tags

Binary messages

Sending binary messages is a less straightforward.

You can specify the exact bytes to send. For example, with u-blox L5 receivers, there is a special command you need to send get GPS L5 signal to work. The u-blox docs give it as a hex string.

[[binary]]
hex = "B562068A0900000100000100321001DEED"
tag = "gps-l5-health"
description = "Use GPS L5 signal regardless of health status"

But usually it is not convenient to specify the full byte sequence directly.

When SatPulse has support for a binary packet format, you can use this to specify things in a more readable way. For example, let’s take the CASIC binary protocol, which is similar to UBX. SatPulse has support for the packet format layer, but does not have configuration support. There’s a CFG-TP message for controlling the time pulse. The CASIC specification describes it like this.

CFG-TP (0x06 0x03)

Payload Content

We can use this to define a message as follows:

[[casbin]]
tag = "pps-gps"
description = "Enable PPS aligned to GPS time"
class = 0x06
id = 0x03
payload.types = "U4U4U1I1U1U1R4"
payload.values = [1000000, 100000, 3, 0, 1, 0, 0.0]

Each type descriptor in the payload.types string specifies how to encode corresponding entry in payload.values. SatPulse doesn’t know about the CFG-TP message but it does know how CASIC binary packets work, and it can use this to produce the right packet from this higher-level description (the packet has two sync bytes, the payload length, the class, the message id, the payload with values in little-endian byte-order and then a checksum).

Using AI to create message libraries

I have had good success using AI to create message libraries. The workflow is:

1. convert the protocol spec from PDF into a more AI-friendly format such as Markdown
2. prompt a coding agent (e.g., Claude Code) to generate a message library, giving it:
   • the protocol spec
   • description of the message file format
   • a few examples of a message library
3. allow the agent to use satpulsetool to access the GPS receiver:
   • try a message in the message library and see whether the receiver ACKs it
   • capture output from the receiver before and after to see whether the configuration message has had the expected effect on the output (use --capture N with --packet-log to capture packets for N seconds)

Examples

The configs/gpsmsg directory in the repository has some example message libraries.

For the last six months or so, I have been working on some major changes that are potentially destabilising. So I wanted to push out 0.1 based on the code before merging in these changes. I have now merged these changes into the master branch. Before I did the merge I was curious how much had changed.

$ git diff --stat master..v0.2-pre | tail -1
215 files changed, 41769 insertions(+), 5171 deletions(-)

About a third of this is test data, but that’s a pile of code. There are two main changes.

The first change is a complete rewrite of the core functionality of SatPulse: synchronizing the PTP hardware clock (PHC) to GPS time using timestamps and messages from the GPS. Although the current code works, it is a mess and not a good foundation for future improvements. I had been struggling for quite a while to come up with a better approach, but I now have something that feels much cleaner. The most important aspect of this is that there is now a simulator that allows realistic testing to be done without needing GPS or PHC hardware. The simulator has taken a lot of time, but I think it’s an investment that will pay off in the long-term.

The second change is to make the GPS support truly multi-protocol. Version 0.1 supports the u-blox UBX protocol only. Although the code was designed to be protocol-independent, there is a big difference between designing it to be protocol independent and it’s actually working well for other protocols in practice. What makes this hard is that my goal is to provide not only a protocol-independent representation of the relevant information transmitted by a GPS receiver, but also a protocol-independent model for querying and changing the configuration of a GPS receiver. The code on master now supports the Unicore UM980, which uses a protocol based on the protocol used by NovAtel OEM series of GPS receivers. One of the reasons I chose to work on this is that the protocol is both rich and completely different from UBX.

I plan to go into more detail about these changes in future posts.

These changes are working but there is lots of polishing, tweaking and testing still to do before a 0.2 release.

Typical NTP stratum-1 setups connect the PPS output of a GPS to a serial port or GPIO pin, which limits accuracy to the microsecond range. The tinyGTC and GPS generally is capable of much greater accuracy, but taking advantage of this requires a different way of connecting the PPS output to a computer, which takes advantage of hardware designed for use with PTP (Precision Time Protocol). Specifically, it requires an ethernet controller with a PTP hardware clock (PHC) that has pins, sometimes called Software Defined Pins (SDPs), that can be used for PPS input and PPS output. This allows synchronization with an accuracy in the tens of nanoseconds. Although PHCs are designed primarily for use with PTP, the chrony implementation of NTP allows PHCs to be used with NTP to achieve similar accuracy.

A tinyGTC connected to a PHC can be used in two different ways:

• connecting a PHC to the PPS output of a tinyGTC allows the tinyGTC to provide time to a PTP server (often called a grandmaster)
• connecting a PHC to the PPS input of a tinyGTC allows the tinyGTC to measure how accurately a PTP client is synchronized

There are two suitable inexpensive ethernet controllers: the Intel i210-T1 and the one on-board the Raspberry Pi CM4/CM5. (The one on-board the Raspberry Pi 5 is not suitable.) The Intel i210-T1 can be used in a PC; the Raspberry Pi CM4/CM5 require a separate IO board. In both cases, this works only with Linux.

Fortuitously, the 3.3V PPS signal level used by the tinyGTC is exactly what the SDPs on these ethernet controllers expect. To connect them up, you need a special cable which has an SMA connector on one end and a pair of Dupont female leads on the other. You can buy these for a few dollars on eBay or AliExpress: search for “SMA Dupont test cable”. The SMA end can be male for direct connection to the tinyGTC, but for a more robust setup it’s better for the SMA end to be a female bulkhead connector: this bulkhead connector attaches to a hole in the case or a wifi bracket, then the SMA male-male cable that comes with the tinyGTC is used to connect from the bulkhead connector to the tinyGTC.

My SatPulse project provides software and documentation to make it easy to take advantage of the capabilities of PHCs for precision network timing. It includes detailed guides on hardware setup both with the CM4/CM5 and with the i210.

TinyGTC is still relatively new, and I did find a few issues, but the developer is very responsive to bug reports, so I am hopeful everything will be resolved. The testing described here was done with firmware version 1.023.

Providing time to a PTP server

For providing time to a PTP server, the tinyGTC needs to be set up as follows:

• GPS disciplining the internal oscillator
• Enable aligned PPS output on the OUT connector (this needs tinyGTC firmware at least 1.023)
• GPS through mode (so NMEA messages from the GPS are available over USB)

Two physical connections are needed:

• an SMA cable connecting from the OUT on the tinyGTC to the SMA-Dupont cable which is connected to the SDPs of the PHC
• a USB cable connecting from the tinyGTC to a USB port on the host computer

The SatPulse setup guide explains how to set up the software side of things. When editing the satpulse.toml configuration file, you will need to specify the serial speed and the serial device. A tinyGTC exposes three USB serial devices, usually /dev/ttyACM0, /dev/ttyACM1 and /dev/ttyACM2. In my tests, the one that passes through the GPS output is /dev/ttyACM1. You need the one with interface number 02, i.e. cat /sys/class/tty/ttyACM1/device/bInterfaceNumber should show 02. You can check if you have the right one by using satpulsetool gps -d /dev/ttyACM1 -s 115200; it should say Packet formats detected: NMEA.

So how does a tinyGTC compare to using a GPS module directly? On the positive side, being a GPSDO rather than just a GPS means that much of the short-term jitter is smoothed out, and also gives some holdover capability. There are very few GPSDOs available that tick the same boxes as tinyGTC: relatively inexpensive, 3.3V PPS, aligned PPS, and access to GPS output (the BG7TBL CM55 is the only other one I know of).

On the negative side, the tinyGTC’s GPS module is single-band (L1 only); this limits its ability to compensate for ionospheric effects, which can introduce phase inaccuracies of tens of nanoseconds over a 24 hour cycle. Also SatPulse does not (yet) have support for the CASIC protocol used by the tinyGTC’s GPS module, so you cannot use satpulsetool gps to configure it.

Measuring PTP synchronization accuracy

The main point of the tinyGTC is to be a time counter, and this can be used with PHCs to measure synchronization accuracy. There is only one other inexpensive device that I know of that provides this capability, which is the TAPR TICC, but that needs a separate 10Mhz reference.

A PHC without PPS input/output SDPs is sufficient for a client to be able to synchronize to a PTP server with high accuracy. Such PHCs are very common: for example, the Raspberry Pi 5 has such a PHC. But if you want to be able to measure the synchronization accuracy, then you need a PHC with an SDP with PPS input/output capability, just as is needed for a PTP server, such as a Raspberry Pi CM4/CM5 or Intel i210.

In order to do measurements, the tinyGTC needs to be set up as follows:

• GPS disciplining the internal oscillator (same as when providing time to the PTP server)
• make Counter A DC-coupled with a trigger level of 2V
• measure Channel A against the internal oscillator

You also need to physically connect the SDP on the PHC of the PTP client to the A connector on the tinyGTC (in the same way as was described for the OUT connector above).

On the PTP client you need to do two things:

• use ptp4l to synchronize the client to the server
• configure the PHC to output a PPS signal; you can use satpulsetool sdp to do this; on a Raspberry Pi CM4/CM5, the command would be simply satpulsetool sdp -o eth0

You can do this at the same time as using tinyGTC to provide time to the server. (So you would need two CM4/CM5s or other suitable PHCs and two SMA-Dupont cables.) In this configuration, the same time is being provided to the PTP server and to the reference against which the PTP client is being measured, so you are mostly measuring how well PTP is working. (It will work much better with a direct back-to-back connection than going through a non-PTP aware switch.)

You can also measure the client against a PTP server with an independent source of time. In this case, you would be measuring how accurately your entire PTP setup is synchronizing a client to UTC.

It is also possible to compare the relative synchronization of two clients by connecting one to input A on the tinyGTC and one to input B. For some applications what is important is not the absolute accuracy of the synchronization to UTC but the synchronization of clients relative to each other. You can set things up to have lines showing A against the GPSDO, B against the GPSDO and A against B.

Detailed tinyGTC setup instructions

Enable GPS disciplining of internal oscillator

1. Tap REFERENCE
2. Tap REFERENCE
3. Select INT GPS
4. Tap BACK

Enable PPS output on OUT connector aligned to disciplined oscillator

1. Tap OUTPUT
2. Tap ALIGNED PPS
3. Wait for it to say “Touch screen to continue”
4. Tap screen

Enable GPS Through Mode

1. Tap CONFIG
2. Enable ADVANCED MENUS
3. Tap BACK
4. Tap REFERENCE
5. Tap SETTINGS
6. Tap GPS THROUGH

Make Counter A DC-coupled with trigger level of 2V

1. Tap COUNTER
2. Tap SOURCE
3. Select A
4. Select TRIG LVL
5. Tap 2
6. Tap ENT

Measure Channel A against disciplined oscillator

1. Tap MEASUREMENT
2. Tap MEASURE
3. Tap PHASE
4. Select PHASE
5. Tap AGAINST NCO
6. Select NCO FREQ
7. Tap 1
8. Tap x1

Kernel devices

There are four key kernel devices involved.

• System clock. There is an underlying raw hardware counter. The kernel exposes three kinds of clock based on this.
  • the raw monotonic clock corresponds to this hardware counter, and is not adjusted for phase or frequency
  • the monotonic clock is adjusted by NTP for frequency, so that it can accurately measure time intervals
  • the realtime clock is adjusted by NTP for both frequency and phase, so that it corresponds closely to UTC (this implies it can jump)

• PTP Hardware Clock (PHC). This is a hardware clock within the ethernet controller. It is important to understand that this is completely independent of the system clock. It has a software-defined pin (SDP) connected to the GPS receiver’s PPS output. It has the capability to timestamp a pulse received on the SDP, i.e. record the time of the PHC at which the pulse occurred. The PHC can be adjusted for phase and frequency.

• Network interface. This is provided by an ethernet controller and is responsible for sending and receiving network packets with PTP or NTP messages. Crucially, it has an associated PHC and can timestamp ingoing and outgoing packets using the PHC i.e. the hardware records the time of the PHC at which each packet is sent or received.

• Serial port. This is connected to the serial or USB interface of the GPS receiver. The kernel TTY subsystem exposes this as a /dev/ttyX device.

Processes

Apart from satpulsed, which is the main daemon program in SatPulse, there are two other processes involved.

• ptp4l, which is part of LinuxPTP, implements the PTP standard. The PTP standard focuses on transferring time over the network from the PHC of one device to the PHC of another device. It does not concern itself with the system clock nor does it specify a mechanism for transferring time from an external source such as a GPS receiver into a PHC. When used in a time server with satpulsed, it is satpulsed rather than ptp4l that adjusts the PHC. Ptp4l interacts with the PHC primarily via hardware timestamping: when it sends and receives packets containing PTP messages it instructs the network interface to record the time of the PHC at which the packets were sent or received, and to provide it with those times.

• chronyd, which is part of chrony, implements the NTP standard. Whereas PTP is focused on the PHC, NTP is focused on the system clock. Chrony accepts information from NTP servers and from reference clocks and uses this to update the system clock and to provide information to NTP clients.

The fundamental role of satpulsed is to transfer time from the GPS receiver to the PHC. This involves the following.

• Reading timestamp events from the PHC. The PHC hardware can record the time of the PHC at which a time pulse occurs on a PHC SDP. The GPS emits time pulses that are precisely aligned with the beginning of a second. So if the timestamp says the pulse is 45 nanoseconds after the beginning of the second, this indicates that the PHC differs from the true time by 45 nanoseconds plus some integral number of seconds.
• Reading messages from the GPS receiver over the serial port. These messages give the approximate current time. By correlating these messages with the timestamp events, it becomes possible to determine which second the pulse is marking the beginning of, and thus calculate exactly how much the PHC differs from the true time.
• Adjusting the PHC. From the timestamp events and GPS messages, satpulsed derives a measurement once per second indicating how much the PHC differs from the true time. When the process starts up, this information is used to set the PHC time. After that, it continually adjusts the frequency of the PHC to keep the difference between the PHC and true time as small as possible. Note that setting the PHC time is relatively imprecise, because this involves separate operations to read and write the PHC time. To get the PHC time precisely right, frequency adjustment is necessary.

The PTP standard requires that when time is transferred in from an external source, certain metadata relating to the time is also transferred in. With ptp4l, this metadata is provided using a specific PTP management message defined by ptp4l (called GRANDMASTER_SETTINGS_NP, NP for non-portable). To support this, satpulsed implements a PTP management client and uses it to send GRANDMASTER_SETTINGS_NP messages to ptp4l over a socket. The kinds of metadata that PTP requires can be divided into two.

The first kind of metadata relates to the offset between TAI time and UTC time. The time of the PHC uses the PTP timescale, which is based on TAI. TAI differs from UTC time by an integral number of seconds, which changes when leap seconds occur. It turns out that all GNSS systems (other than GLONASS) work in a similar way: their clocks use a timescale based on TAI, but they also provide metadata about the offset between TAI and UTC time. Usually GPS receivers hide all this complexity and output messages with UTC time, which is suitable for NTP. But for PTP, the GPS receiver should output messages with TAI time (or rather GNSS time, which is a fixed number of seconds from TAI time) and also messages about leap seconds. During start-up, satpulsed sends configuration messages to the GPS receiver to make it do this, and then it uses these messages to provide the appropriate metadata to ptp4l.

The second kind of metadata relates to clock quality, which indicates whether the PHC is synchronized to GNSS at all, and if it is, how accurately it is synchronized. A PTP server broadcasts its clock quality; clients use this information to choose the best available PTP server. The synchronization state is continuously monitored by satpulsed. If there’s a problem with the GPS receiver that prevents satpulsed from keeping the PHC synchronized with the GPS receiver time, then satpulsed notifies ptp4l, so that ptp4l can update the clock quality metadata it sends to clients. This allows clients to switch over promptly to a better-synchronized PTP server or to be aware that they are no longer properly synchronized by PTP.

When used with chrony, satpulsed in addition takes readings of the PHC and the realtime clock that are as simultaneous as the hardware allows. When the PHC is in sync with the GPS receiver time, then these readings can be used to generate a sample saying how much the realtime clock is off from the true time; satpulsed will send these samples to chrony over a socket using the refclock SOCK protocol. Chrony can use this as a reference clock.

Comparison to classic NTP server

This architecture differs from a classic NTP server, using an NTP server such as ntpd or chrony together with gpsd. Apart from the addition of a PTP implementation, the key difference is in the presence of a PHC. In a classic NTP architecture, the GPS receiver is attached to a seria port pin or GPIO pin. When a GPS receiver emits a pulse, an interrupt will occur and the kernel will record the time of the pulse. The kernel makes these timestamps available to applications via a PPS kernel device, which will be read by either gpsd or the NTP server.

The crucial difference is that with a PPS signal connected to a PHC, the hardware records the time of the PHC at which each pulse occurs without the intervention of the kernel. This enables the timestamps to be accurate to a few nanoseconds, whereas with a PPS device the accuracy is several orders of magnitude worse. The PHC also enables hardware timestamping of network packets, which enables similarly accurate measurement of the offset between the PHC on the server and the PHC on the client.

Here is an example of how you can fit a GPS to the Raspberry Pi CM5 IO board in the official IO case, so that it can be used with SatPulse.

I chose a GPS in the form factor that I have found easiest to fit inside CM4/CM5 cases, which:

• is really small, almost thumbnail-sized; it is 17mmx23mm excluding the connectors and 17mmx40mm including the connectors;
• has a single hole that can be used to secure the board; it is small and light enough that a single hole is enough to securely support the board;
• has both U.FL (IPEX) and SMA connectors; the U.FL connector works best inside the case, but the SMA connector is useful for testing outside the case;
• has 5 Dupont pins for connecting power, serial port, and PPS; these are the same kind of pins that are used on the IO board, so is the easiest to work with;
• includes a tiny battery;
• has both power and PPS LEDs.

There are quite a number of GPSs on the market in this form factor. The board I am using here is the Star River SR1723U10. I got it from Star River’s official shop on AliExpress. (The shop is called Xing He Wei; Xing He means star river, which is a poetic name for the Milky Way in Chinese.) The SR1723 range has GPS boards in the same factor with a variety of different modules. This one uses the Star River SR1612U10 module, which uses the u-blox UBX-M10050-KB chip. So from a software perspective, it behaves like a u-blox 10th generation standard precision module. It costs about $7.

You will of course need an antenna; this module is single-band L1, so a basic GPS puck antenna with a cable ending in a SMA male connector is sufficient.

On the left we have the case assembled but without the GPS. The parts for this are:

• Raspberry Pi Compute Module 5
• Raspberry Pi Compute Module 5 IO board
• Raspberry Pi Compute Module 5 IO Case
• Raspberry Pi Cooler for Compute Module 5
• CR2032 coin cell battery for the RTC

You will also need a USB PD power supply, which I haven’t shown. Note that 5V3A is plenty for this configuration, so you can use any old USB PD power supply you have handy; there is no need to buy the special Raspberry Pi 27W supply which supports 5V5A.

To fit the GPS to the IO board, I used:

• a 15cm 5-pin Dupont female-female ribbon cable; this came with the GPS board; if you don’t have this, then you can just use 5 separate jumpers
• a 10cm U.FL to SMA female bulkhead pigtail (note that it is SMA female without a pin, rather than RP-SMA female with pin; RP-SMA is used for wifi antennas)
• a male-female 10mm M2.5 nylon standoff and screw

The assembled result is on the right. The assembly process involves

• removing the screw on the upper right that secures the board to the case, and replacing it by the standoff;
• using the hole in the case designed for a wifi antenna for the GPS antenna (rather surprisingly the wifi is still usable with the on-board wifi antenna)

It is important to note here that silkscreen on the IO board labels pin 9 as the SYNC_OUT (as it was on the CM4 IO board), but this is incorrect: the SYNC_OUT pin is actually pin 6 (top row, third from the left, on the J2 14-pin jumper set). The VCC pin on the GPS accepts between 3.3V and 5V, so it could alternatively be connected to a 3.3V pin.

The setup guide explains how to install and configure the necessary software. The initial speed of the serial port is 38400.

Here is a table of the results:

• GPS is the GPS used (configuration detailed below)
• Mean is the mean of the absolute value of the offsets in nanoseconds
• 95% is the 95th percentile, i.e. 95% of the absolute values of the offsets are within this
• Std dev is the standard deviation of the offsets
• Cost is the approximate cost in US$ without shipping or tax

The systems are as follows:

• F9T is u-blox ZED-F9T in a USB dongle from gnss.store attached to Lenovo M720q Tiny PC (using Intel i3-9100T) with an Intel i210-T1 card, running Fedora 41
• F9P is a u-blox ZED-F9P in a simpleRTK2B M.2 card from Ardusimple, in an Asus S500SD PC (using an Intel i5-12400) with an Intel i225-T1 card, running Debian Bookworm
• GPSDO is a BG7TBL GPSDO with an RS232 connection to a Raspberry Pi CM4 in a Waveshare PoE Board B, running Debian Bookworm
• M8F is a u-blox LEA-M8F in a Timebeat sandwich board (which they don’t seem to sell any more), in a CM4 running Debian Bullseye
• M8T is a u-blox LEA-M8T in a Huawei board from ebay, in a CM4 running Fedora 41
• M10 is a Star River SR1612U10 module (using a u-blox UBX-M10050-KB chip) in a SR1723-U10 board, in a Raspberry Pi CM5 running Debian Bookworm

SatPulse did its automatic configuration on all of these, apart from the GPSDO. The systems share two antennas (using GPS splitters). The antennas are both survey antennas, which can see about 50% of the sky.

Some thoughts:

• The M8F is a bit different. It effectively is a mini-GPSDO. I was surprised to see it beat the F9P and F9T. I am also surprised that it is so much better than the BG7TBL GPSDO, which is physically much bigger.
• The dual-band high-precision models (F9P and F9T) do better than the single-band models, which is to be expected.
• The single-band timing model (M8T) does a bit better than the single-band standard precision model (M10), which is also to be expected.
• The M10 model is pretty decent for its price.
• The F9P, which is designed for RTK (precision positioning), and F9T, which is designed for precision timing, have essentially the same performance. I should mention that I flashed the F9P with older firmware that supports reporting the quantization error (sawtooth correction) in the UBX-TIM-TP message. I haven’t tested whether this makes a difference. The F9T supports a differential timing where multiple F9Ts can work together to provide better precision. But if you don’t need this, the F9P is the more cost-effective option. These are both dual-band. They have separate models which support L1+L2 and L1+L5.