As is well known, modern weak-signal digital modes (such as FT8, WSPR, JT65, etc.) require an extremely precise time reference: even a deviation of about one second can completely compromise signal decoding. Older versions of the Raspberry Pi lack a built-in hardware real-time clock (RTC) and rely on the network to retrieve the correct time. However, both the Raspberry Pi 5 and traditional PCs include a quartz RTC which, while able to preserve time when the system is powered off, is subject to drift and does not provide the precision required by weak-signal modes. Therefore, even on these platforms, a more accurate synchronization method is necessary.

For the Raspberry Pi, which is designed for mobile use, I integrated a GPS receiver to make the system both autonomous and precise. It is used both to determine geographic position and as a time reference source. In this context, it is useful to clarify the role of the Network Time Protocol (NTP), which is the standard mechanism used by operating systems to synchronize the clock. NTP works by exchanging packets with one or more remote servers and estimating network delay and jitter; under good conditions it can achieve millisecond-level precision, but the quality of the result strongly depends on connection stability. On mobile or congested networks, the error can increase significantly, making this method not always suitable for radio applications requiring strict timing.

To achieve higher precision, it is necessary to use a hardware time source such as the Pulse Per Second (PPS) signal available on some GPS receivers. The GPS does not only provide position data but also an absolute time reference derived from the atomic clocks aboard satellites. However, the time information transmitted in the NMEA serial stream is not sufficiently precise due to transmission and processing latency. The PPS signal solves this by providing an electrical pulse precisely aligned with the start of each UTC second. In practice, while the NMEA stream tells what time it is, PPS tells exactly when the second begins, allowing system clock alignment with microsecond-level accuracy. The two sources are therefore complementary: PPS alone is not sufficient without the temporal context provided by NMEA.

From a software perspective, the system is based on gpsd—a subsystem dedicated to GPS receiver management—and chrony for system clock synchronization. Chrony is particularly well suited for this configuration because it can combine multiple sources (NTP, GPS, PPS) and handle intermittent signals. When PPS is available and properly locked, it is used as the primary reference (stratum 1), while NMEA data provides the temporal context required to correctly interpret the PPS signal. If PPS is not available, chrony continues operating using GPS-derived serial time or, if available, network NTP servers.

This distinction is particularly important because the system is available in two hardware variants with different characteristics. In my Raspberry Pi–based version I use a VK-2828 GPS module, connected directly to the GPIO pins and equipped with a PPS output. In this case, the signal is acquired at kernel level and allows chrony to discipline the clock with very high precision, typically in the microsecond range. This is the ideal configuration for weak-signal modes, where timing accuracy is critical. It should be noted that the GPS module is affected by EMI noise generated by the Raspberry Pi; if possible, it should be placed at least ten centimeters away, or shielded using copper or aluminum foil to reduce signal degradation.

In the amd64 version, on the other hand, a USB GPS receiver is generally used. These devices most often do not provide a usable PPS signal, or only in a limited way. As a result, the system must rely exclusively on the NMEA stream received via USB, which is subject to buffering, driver latency, and operating system scheduling. This introduces significantly higher timing uncertainty: in practice, achievable precision is typically in the millisecond range, with possible spikes in the tens of milliseconds under heavy load. While this level is sufficient for many uses, it is still a limitation compared to a PPS-based configuration and should be considered for more demanding applications. In the case of FT8 this is not a problem, since the protocol requires a timing accuracy of ±0.5 seconds (ideally between -0.1 and +0.25 s).

Therefore, the synchronization logic differs between the Raspberry Pi version—where PPS is always the most reliable reference—and the amd64 version, where, if internet connectivity is available, NTP is generally more accurate than GPS without PPS. Chrony continuously monitors available synchronization sources in real time and selects the one that provides the best precision. In both cases, whether GPS or NTP, the achieved accuracy is far better than what is required for operating time-referenced digital modes.

The system works transparently for the user, but it is still important to quickly assess synchronization quality. For this purpose, I developed a small utility called gpsclock, which displays UTC time along with other useful information such as Maidenhead locator, altitude, number of satellites, GPS fix status, and most importantly the active clock source (PPS/GPS, NTP, or local clock). This allows immediate verification that the system is operating under optimal conditions.

In the screenshot, the following are displayed: (1) UTC time, (2) locator computed from GPS coordinates, (3) altitude if the GPS is in 3D mode, (4) number of visible satellites, (5) GPS operating mode, (6) system clock source.

For advanced users who want deeper analysis, chrony diagnostic commands such as chronyc sources and chronyc tracking can be used to inspect available sources, time offsets, and synchronization quality in detail. In addition, chrony is configured to act as an NTP server on the local network (192.168.0.0/16), allowing other devices to synchronize using this system as a reference even without an Internet connection.

Finally, GPS data is made available on the local network via gpsd on TCP port 2947, allowing other devices or applications on the network to use it. The Accessories menu also includes an entry called xgps, which allows real-time visualization of detailed receiver status, position, and visible satellites.

The result is a compact and fully autonomous system housed in a 3D-printed enclosure, capable of providing both a high-precision time reference and reliable position data.

In summary

Hamlinux can use a GPS receiver to maintain accurate time and position even without an internet connection. Depending on the available hardware, clock precision may vary significantly, but the flexibility of the configuration is sufficient to meet even the most demanding radio applications.

Info