Disclosure: I work with KALMIX. This post documents a real test using KALMIX Trace v1.5.7 and a SCOUT Pro GNSS receiver. It is a workflow and troubleshooting example, not an accuracy benchmark.
When a Windows NTRIP client says Connected, it has reached the correction service. That does not by itself prove that the GNSS receiver is using the corrections or that it has reached RTK float or RTK fixed.
This is an easy distinction to miss during a first RTK setup. A receiver can still report a standalone position while a correction link is connected. Satellite visibility, signal quality, the correction stream, RTCM forwarding, and the receiver's own ambiguity resolution all still matter.
This post shows the workflow we used to check those layers with a SCOUT Pro receiver and KALMIX Trace on Windows.
Figure 1. The SCOUT Pro receiver connected to a Windows laptop for the test workflow.
The data path to verify
The useful mental model is:
SCOUT Pro -> USB serial / COM port -> KALMIX Trace -> Windows
[Correction delivery path]
NTRIP caster -> RTCM3 corrections -> KALMIX Trace -> SCOUT Pro
[Receiver output path]
SCOUT Pro RTK engine -> NMEA position and solution status -> KALMIX Trace
KALMIX Trace opens the Windows serial port, displays NMEA output, receives NTRIP corrections, forwards RTCM3 to the receiver, and records the resulting status and logs. The RTK solution itself is calculated inside the receiver.
That means a reliable diagnosis has four layers:
- Is readable NMEA arriving through the correct COM port and baud rate?
- Does the receiver have a usable GNSS solution and reasonable satellite visibility?
- Is the NTRIP correction service connected and delivering RTCM?
- Is RTCM actually being forwarded to the receiver, and what solution status does the receiver report afterwards?
Baseline: live NMEA is not the same as RTK
We first confirmed that the Windows serial connection was working. Trace showed a live NMEA stream from the receiver on COM17 at 115200 baud. The receiver reported Standalone (1), with 12 satellites and an HDOP of 1.7. At this point the correction service was disconnected and the RTCM received / forwarded counters were both zero.
Figure 2. Live NMEA confirms the serial path is working. The receiver is reporting a standalone solution before the correction service is connected.
This is the first useful checkpoint. If NMEA is missing, garbled, or not updating, it is too early to troubleshoot NTRIP. Check the selected COM port, baud rate, cable, and receiver output configuration first.
A connected correction link can still leave the receiver in standalone mode
We then connected the correction service. Trace showed that the link was connected and that RTCM data was both received and forwarded: 41.7 kB received and 41.7 kB forwarded in this capture. This verifies that corrections were no longer stopping at the Windows PC.
However, the receiver still reported Standalone (1). The skyplot showed limited satellite availability, and the receiver had not yet reached RTK float.
Figure 3. The correction link is connected and RTCM is forwarded, but the receiver remains in standalone mode. Connection alone is not the final RTK test.
This is the key troubleshooting point: NTRIP connected does not equal RTK float or RTK fixed. In this test, the receiver was initially in an indoor or obstructed location. It could produce a standalone position, but satellite visibility was not sufficient for an RTK solution.
Move to open sky, then check the receiver status again
After moving the receiver to a more open outdoor location, Trace showed a larger usable satellite set. In the following capture, the receiver reported RTK fixed (4) with 26 satellites, HDOP 1.1, a connected correction link, and a 1.0-second correction age.
Figure 4. After moving to a more open environment, the receiver reports RTK fixed. The skyplot is a useful context check alongside status and correction counters.
The live NMEA view provided the final confirmation for this test: the receiver reported RTK fixed (4), corrections were connected, and the received and forwarded RTCM totals matched in the displayed session.
Figure 5. Final status check: live NMEA, correction connection, RTCM forwarding, and RTK fixed are visible in one view.
What this test does and does not prove
This result shows one tested workflow: the SCOUT Pro serial connection was live, corrections reached and were forwarded through Trace, and the receiver subsequently reported RTK fixed after it was moved to a more open environment.
It 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 accuracy. RTK performance also depends on the receiver configuration, antenna placement, sky view, multipath, correction source, baseline, local conditions, and time to resolve.
A practical Windows RTK checklist
When RTK float or fixed does not appear, work through the stack in this order:
- Serial: Is the correct COM port open? Is live NMEA readable and updating?
- GNSS: Does the receiver have a normal standalone solution and adequate satellite visibility?
- Corrections: Is the NTRIP service connected? Is the RTCM received counter increasing?
- Forwarding: Is the RTCM forwarded counter also increasing?
- Receiver status: Does the receiver report standalone, RTK float, or RTK fixed after it receives corrections?
Do not publish NTRIP usernames, passwords, private mountpoints, customer information, or precise test coordinates when sharing screenshots or logs.
Resources
Which part of your Windows RTK workflow is hardest to verify: serial data, correction delivery, or receiver status?
Top comments (0)