Time is an overlooked element in APRS comms. Few operators consider it, and many gateways/digipeaters ignore it. Yet it impacts how packets are handled.
Time-keeping
All hardware TNCs have some kind of RTC (Real Time Clock), which is usually a simple, uncompensated quartz clock. A quartz clock gains or loses about 15 seconds a month, which may not seem like much. But as these devices run month after month, year after year, the discrepancy becomes significant. After a single year, that hardware RTC could be fast or slow by three minutes.
In the case of software TNCs (YAAC, DireWolf, Xastir, etc.) the accuracy depends on the computer running the software. If that computer is connected to the internet, the clock will be kept adjusted to within a few seconds. But a remote digipeater using a software TNC may not have an internet connection to perform that task. In other cases, the TNCs time may be ignored in favor of the client's time. For example, a Mobilinkd TNC will use the time from the smartphone running APRSDroid -- which is using the cellular network to update the current time.
I've long wondered why so many hardware TNCs do not allow GPS to be used for time correction. I'm unsure if there are many computers that would allow you to use GPS for time correction, either. An aftermarket accessory that would perform time correction using WWV (such as the so-called "atomic clocks" commonly sold) could also be useful. But I know of none existing.
Instead, either the internet or cellular networks tend to be used, if at all. Those who use FT8 (or variants) know that accuracy outside one second can degrade performance. These operators often install software to use NTP over the internet to keep their computer's clock corrected continuously.
Timestamps
Some of this problem is mitigated in a somewhat clumsy way by stations refusing/neglecting to transmit a timestamp with their packets. The purpose of a timestamp is not to tell the world what time it is. It's supposed to tell the world what time your station thinks it is.
Here's an example of a timestamp sent by N0ANC-2, near St. Cloud:
2026-01-16 17:00:58 CST: N0ANC-2>APMI04,TCPIP*,qAS,N0ANC-12:@162300z4528.75N\09410.42W-St. Augusta Mn VHF APRS Igate
2026-01-16 17:29:58 CST: N0ANC-2>APMI04,TCPIP*,qAS,N0ANC-12:@162329z4528.75N\09410.42W-St. Augusta Mn VHF APRS Igate
2026-01-16 17:58:58 CST: N0ANC-2>APMI04,TCPIP*,qAS,N0ANC-12:@162358z4528.75N\09410.42W-St. Augusta Mn VHF APRS Igate
The timestamp is sent as part of the packet, along with location and various other station info. In this case, N0ANC-2 uses a Microsat WX3-in-1 TNC. One of the mostly forgotten features of this TNC is the NTP capability when connected to the internet, such as being used for a gateway.
If your station is using DireWolf, YAAC, or Xastir (for example), it will not generally transmit a timestamp, regardless of how accurate the clock is. Likewise, digipeaters running UIDIGI do not transmit a timestamp. Neither does APRSDroid or the Kantronics KPC3 TNC. I haven't seen any mobile or HT rigs that have native APRS send a timestamp, though it may be possible. APRSICE32 and the newer Microsat TNCs can be configured to transmit a timestamp.
With so many stations virtually incapable of sending a timestamp, this creates a lot of ambiguity. It can make it much more difficult for a gateway (or the -IS network itself) to detect duplicate packets ("dupes"). The order of packets can also become tenuous. A timestamp is a reference point that can be used to distinguish one packet sent from another packet sent shortly afterward. Or the same packet being gated/digipeated twice, even though they are heard at slightly different times by the gateway or digipeater. A timestamped packet can also be compared with the packet data as shown on the -IS server, giving an idea of delay and latency. Using time stamped packets, I've been able to see digipeaters holding on to packets for a second or more -- which is forever when dealing in milliseconds.
Summary
Operators can work on the margins to improve this situation, but the long-term solutions will ultimately come from hardware manufacturers and software developers.
Hardware manufacturers can upgrade their firmware to make it possible to use GPS for time correction of the onboard RTC. They can also add timestamp capability for anything transmitted (RF or -IS). This would allow things like remote digipeaters to maintain the correct time. If we can have cheap "atomic clocks" that use WWV to keep accurate time, it should be relatively simple to add a device to a hardware TNC that will perform that function for the TNC's RTC.
Software developers can (and should) add NTP time correction as an option when networked. If DireWolf, UIDIGI, and YAAC would implement this change, significant improvement would be seen across the network. Adding a timestamp function would seem to be simple, and would improve efficiency across the network.
No comments:
Post a Comment