A practical incident record for developers and engineers operating GNSS correction pipelines.
Disclosure: This article was generated with AI and checked against the primary technical references below. It proposes an operational workflow; it does not report a field trial, benchmark, or named customer's experience.
A green connection indicator is a useful observation, but a weak incident report. It does not tell the next engineer whether the client received correction bytes, whether the receiver decoded them, or whether the resulting coordinates passed an independent check. Restarting everything can hide those distinctions before anyone records them.
Treat the path from caster to accepted observation as several observable boundaries. The aim is to identify the earliest boundary without supporting evidence, then investigate that boundary before changing the rest of the system.
1. Separate transport, payload, receiver, and acceptance
NTRIP is a transport mechanism. BKG describes broadcasters as distributing streams without changing their data. Those streams can contain different GNSS products, including observations, ephemerides, or orbit and clock corrections. A successful subscription therefore does not establish that a chosen stream is appropriate for a particular RTK rover. [1]
Give each boundary its own status:
| Boundary | Evidence to retain | What it does not establish |
|---|---|---|
| Session | Requested service, mountpoint, response, disconnect times | That correction payload is arriving |
| Payload | Received-byte counter, observation interval, decoder summary | That the receiver accepts or uses it |
| Receiver | Accepted messages, correction age, solution state, receiver alarms | That the project coordinates are correct |
| Acceptance | Independent control comparison, coordinate-system settings, tolerance decision | That future observations will remain valid |
Use “unknown” when instrumentation cannot observe a boundary. A dashboard that silently converts missing telemetry into “healthy” creates a second fault: loss of diagnostic evidence.
2. Build one timeline before changing configuration
Record the incident start, last known satisfactory operation, first disconnect, reconnections, and first recovery. Use UTC for shared timestamps and document how each device's clock was checked. For local elapsed-time measurements, a monotonic clock avoids jumps caused by wall-clock adjustment.
Capture the client version, receiver firmware, configured mountpoint, connection path, and recent configuration changes. Keep public incident notes separate from credentials and precise operational locations. Do not copy authorization headers, passwords, or complete connection URLs into tickets.
A small structured record is easier to compare than a screenshot alone. This is a proposed schema, not measured telemetry:
{
"observed_at_utc": null,
"session_state": "unknown",
"payload_bytes_in_interval": null,
"receiver_correction_age_s": null,
"receiver_solution_state": "unknown",
"control_check_result": "not_performed"
}
Define each field's observation point. Bytes counted in the NTRIP client are different evidence from bytes accepted at the receiver input. Retain missing values rather than inventing zeroes, and record the reporting interval beside each counter.
3. When the session works but payload does not
First check the exact requested mountpoint against the provider's documented stream. A source table is a catalogue, not proof that the selected mountpoint is delivering an appropriate live payload.
Check whether the service requires the rover's approximate position through NMEA GGA. For example, Bavaria's official SAPOS description states that RTCM delivery follows transmission of the rover position. That is a service-specific requirement, not permission to assume every mountpoint requires GGA. Follow the actual provider's requirements for position, format, and update interval. [2]
Compare session events with payload-counter changes. A session repeatedly reconnecting while counters remain unchanged suggests a different investigation from a continuous stream reaching an incompatible receiver. Keep the distinction visible in the ticket.
Do not conduct uncontrolled reconnect loops. Respect the provider's connection limits and ask its operator about service-side errors with timestamps and the mountpoint, without exposing credentials.
4. When bytes arrive but the receiver cannot use them
Read the receiver's documented input status. Verify that the correction stream's message family, supported signals, and selected input interface match the receiver configuration. A forwarding application and the receiver can disagree about which serial, Bluetooth, or network input is active.
Inspect correction-age and solution-state fields together. NovAtel's BESTPOS documentation illustrates why: it reports differential age and distinguishes low-latency processing from matched observations. Its specific field meanings and timeouts belong to that implementation. Do not copy a timeout from one receiver manual into a fleet-wide acceptance rule. [3]
Also collect receiver alarms. NovAtel's troubleshooting guidance separates power, communication, antenna visibility, cabling, and interference checks. These are useful categories for an incident record, even when the deployed receiver uses different commands. [4]
Change one variable at a time. Record the expected observation before the change: for example, accepted-message counts should begin advancing. If the expected observation does not occur, preserve that result instead of declaring recovery from the connection icon alone.
5. A fixed solution still needs a coordinate check
A receiver's fixed-ambiguity state is a processing result. It is not an independent audit of the reference coordinates or the project's height convention.
NovAtel documents a multi-base example in which inconsistent base information can produce jumps while the receiver continues reporting RTK Fix. The general lesson is to retain source identity and investigate changes of reference; it is not a recommendation to combine independent streams. [5]
Before accepting observations, compare against independent control using the project's agreed procedure. Record the reference frame and epoch where applicable, projection, units, antenna-height convention, and whether heights are ellipsoidal or derived using a geoid model. Have the responsible survey professional resolve any mismatch. A repeatable offset deserves investigation even if the displayed uncertainty is small.
6. Close the incident with evidence, not a reset
Define recovery before making the final change. A practical closure record states which boundary failed, what was changed, which observations recovered, and what remains unknown. Include the observation duration and the agreed acceptance criteria; there is no universal duration or correction-age threshold suitable for every deployment.
If payload delivery recovered but no control check was performed, close the transport fault separately and leave positional acceptance open. That distinction lets software operations and field teams exchange useful evidence without asking either team to certify something it has not measured.
Top comments (0)