RTCM Free Run after Lost GPS

The RTCM voter units immediately kill connection to the host after GPS is lost, which makes sense conceptually because the timing reference is gone.

However, if this is just for a voted receiver system, not simulcast (whole different animal), I would not imagine the microprocessor loses count of time via its internal clock that quickly, and even something like a 1/16 of a second time inaccuracy between sites in my opinion would be better than complete loss of comms.

Typical TDD cellular base stations (with much better built in oscillators, yes I will give them that) can free run for about 24-48 hours before GPS signal needs to be re-acquired.

Any thoughts on the reasoning for immediate host kill after GPS lost? I'd be interested to see what the performance looked like if the RTCM was set to still free-run for say up to 10 minutes after GPS loss.

There is no real time clock in the uC in the RTCM. Timestamps for encoding audio packets are directly derived from the NMEA/TSIP data, along with the PPS signal, and encoded in the IP packets. When you lose that, it's lights out.

Have a read through https://allstarlink.github.io/voter/voter-protocol/ and the various other pages that describe how it is all put together.

As for Cellular base stations, you answered your own question. The GPS modules in those systems often have/had OCXOs to keep synchronization if GPS were lost, you also have/had recovered time synch from the incoming transport data to help keep things aligned too. Also, that is a completely different beast, where you're not relying on the actual real time timestamp to put packets back together (those protocols used other schemes).

Lee