GNSS SSR: Avoiding Resets and Common Integration Pitfalls
In SSR (sometimes written SRR) you do not receive a remote base: you receive orbit, clock and bias models that the receiver integrates into its filter. If the equipment remains in RTK/OSR mode and also ingests SSR, corrections are duplicated and decimetre-level jumps appear that are difficult to explain. Verify that the active profile is PPP-RTK/SSR and that no RTK assist aids or parallel differential base corrections are enabled. The reference frame is paramount: consistent ITRF, correct PCV/antenna offsets and firmware with updated bias tables. ISB/OSB between constellations and frequencies are not optional; mixing GPS, Galileo and GLONASS FDMA without them means integer ambiguities will not fix. Changing SSR provider without reinitialising the filter introduces offsets due to differing references and DCBs; clear the state when switching. Latency is more damaging than bandwidth: jitter of seconds decorrelates the clocks and prevents fixing. Use NTRIP with a short buffer and jitter control; on SATCOM links, prioritise stable QoS and avoid reconnections caused by aggressive NAT. 1 ns of clock error is equivalent to approximately 0.3 m in pseudorange; for centimetre-level positioning the margin is minimal, so take care of the IP chain end to end. If you observe refixing every time the Issue of Data of the clocks changes, increase the smoothing by a few seconds and avoid forcing resets. In mobile applications, the Hatch filter assists the code, but an excessive tau introduces delay during manoeuvres and can trigger cycle-slips. With an active ionosphere, the uncombined formulation with an SSR ionosphere model generally performs better than the classical ionosphere-free combination. Adjust the elevation mask to 10–15° and use adaptive CN0; attempting to fix below approximately 30 dB-Hz on L5 under vibration is unreliable. If a PRN systematically breaks residuals, suspect RF first: connectors, LNA or coaxial cable with losses and mismatches. Do not mix SSR with base corrections in the same data stream, nor allow internal filters to duplicate biases: that constitutes structural noise. Also log the internal state of the estimator and the received SSR messages; debugging without that traceability means working blind. In UAS, use realistic acceleration models; an excessively aggressive process noise may sacrifice ambiguities in favour of dynamic tracking. If you combine Galileo HAS by satellite with IP backup, define priority and switching policy so as not to break coherence. Perform a daily smoke test: cold-start, time to fix, residuals per constellation and static drift over 30 minutes. If all of the above is correct and fixing is still not achieved, review the firmware and bias tables published by the provider: sometimes the bug is there.
NASSAT - Network Satellite Systems