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.
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).
You could build a circuit that has an RTC that is fed by the GPS and it can fake the messages with time when the GPS loses lock. Probably with an Arduino even.
No, it doesn’t work like that. Please read the how the protocol works. If you try and “fake” the timestamps, you’re going to end up with garbled audio (at best).
Not only do you need NMEA/TSIP messages with the timestamp, you also need accurate PPS input.
NMEA/TSIP is used to give a “rough” timestamp of the audio packet, and then PPS is used to fine tune the synchronization when it builds the packets to send to the host.
When the host receives all the packets from all the receivers, it can then correlate all the timestamps to accurately line them all up, and THEN decide which is the quietest audio packet to vote (based on the voting criteria) to send to the transmitter(s).
If you absolutely must have a satellite receiver online all the time feeding the audio, then you MAY be able to achieve some results by making it a “mix” client.
You’re probably better off figuring out WHY you are losing GPS to begin with, that should be an easier problem to solve. Cheap patch antennas are garbage in a high RF environment. You must have a proper GPS antenna with an LNA and SAW filter to help reject interference.
N5ZR’s response makes sense to me. With a stable enough RTC, I would think it could “free run” by being disciplined by PPS and NMEA and then with a brief loss it would run for a few minutes.
What actually would be a much more useful feature for starters would be a way to automatically set up the master RTCM as a non-voting mix if GPS is lost. Therefore you could run standalone repeat and not lose AllStar connectivity.
If the master RTCM loses GPS, you can have it revert to offline repeat so that you still have a basic repeater with CWID.
Again, if you’re having issues losing GPS, troubleshoot that problem, rather than trying to add features that in 99% of use cases aren’t needed.
The current RTCM/VOTER hardware has no space on the PIC for any new features. In fact, switching to the “BEW” firmware means deleting the “diagnostic” routines in order to free up code space.
Yeah I agree the firmware is pretty limited for addons. It would be cool to try to see if there’s enough room to squeeze in a simple “if gps offline, act like non-voting mix”.
GPS is not bulletproof. Some of us may not be fortunate enough to have sites in 100% clean GPS areas. I’m thinking of one site I have in NM in proximity to WSMR and implications if I were to add a voted repeater there.
