Build1 publisher3 min readPublished
A connected NTRIP link left this receiver standalone until it was moved outdoors
A KALMIX test post logged RTCM received and forwarded in equal amounts while its SCOUT Pro receiver still reported a standalone solution, and the status changed only after the unit was carried into open sky.
The Engineer · Build desk
What happened
- A KALMIX post documenting a test with Trace v1.5.7 and a SCOUT Pro receiver argues that an NTRIP client reporting Connected has only reached the correction service.
- The baseline capture showed live NMEA on COM17 at 115200 baud with the receiver in Standalone (1), the correction service disconnected, and both RTCM counters at zero.
- Once the service was connected and RTCM was both received and forwarded in equal amounts, the receiver kept reporting Standalone (1) with limited satellite availability on the skyplot.
- After the receiver was carried to a more open outdoor location, the client showed RTK fixed (4) with a connected correction link and a 1.0-second correction age.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint A green Connected string cannot serve as an acceptance test for a crew waiting on centimetre work, because the layer that resolves ambiguities reports separately in the receiver's own output.
- decision The checklist changes what an operator touches first: caster credentials and mountpoint names come after a readable serial stream, so the first hour goes to the serial stream.
- capability Matched received and forwarded byte totals give a cheap way to split a PC that is not sending from a receiver that is not accepting, without instrumenting the receiver.
- cost When the limit is sky view, someone has to move the receiver, and no amount of client-side reconfiguration moves the solution status.
Three indicators in that workflow describe three different subsystems, and only one of them belongs to the receiver. KALMIX Trace opens the Windows serial port, displays the NMEA output, receives the NTRIP corrections, forwards RTCM3 to the receiver, and records status and logs; the RTK solution is calculated inside the receiver [4]. "Connected" describes a session with the caster. The byte counters are the PC's. The solution status arrives on the receiver output path, which the post models as RTK engine to NMEA position and solution status to Trace [16].
In the capture taken after the link came up, Trace showed 41.7 kB received and 41.7 kB forwarded [8]. Those totals are displayed to a tenth of a kilobyte, so agreement bounds any loss on the Windows side at under 100 bytes [14]. It confirms the bytes left the PC, not that the receiver parsed them, and in that same capture the receiver was still reporting Standalone (1) with limited satellite availability [9].
The correction link was connected in that capture and connected again in the one where the receiver reported RTK fixed (4) [15]. What differed was sky view. Satellites went from 12 to 26 and HDOP from 1.7 to 1.1, an increase of fourteen satellites [6] [11] [13]. The post attributes the first result to an indoor or obstructed location where visibility was not sufficient for an RTK solution [10]. The corrective action was carrying the unit outside.
The one displayed figure that speaks to ingestion is correction age, reported as 1.0 second alongside the fixed solution [11]. The post does not say whether that age is read back from the receiver or computed by Trace from its own last received packet. Only the first is evidence that the receiver consumed the stream.
The post runs the checks in this order:
1. readable NMEA arriving at the correct COM port and baud rate; 2. a usable GNSS solution with reasonable satellite visibility; 3. an NTRIP service connected and delivering RTCM; 4. RTCM actually forwarded to the receiver, and the solution status the receiver reports afterwards [5].
If NMEA is missing, garbled, or not updating, the post says it is too early to troubleshoot NTRIP, and to check the COM port, baud rate, cable, and receiver output configuration first [7].
The author, who discloses working with KALMIX, wrote: "It is a workflow and troubleshooting example, not an accuracy benchmark." [1] [2] The post also states that the result does not prove that every indoor installation will fail, that every outdoor installation will achieve RTK fixed, or that the displayed status is an independent measurement of absolute positioning [12]. RTK fixed (4) is the receiver's claim about its own ambiguity resolution. Testing that claim needs a known coordinate, which is a different test from the one run here [12].
What to watch
- A capture where RTCM forwards cleanly but the receiver rejects the mountpoint's message types would test the fourth layer of the checklist directly.
- Whether Trace's correction age is read back from the receiver or computed by the client, which decides if it counts as ingestion evidence.
- A run against a known coordinate would show what RTK fixed (4) is worth as an accuracy statement, which the post says it does not claim.