After power-on, an RTK receiver moves from a single-point solution through a float solution into a fixed solution, and that initialisation takes time. The YUEETEK H13 product data gives a typical time to first fix of <10s; state changes inside that window are part of normal convergence. What needs investigation is a fixed solution that is repeatedly lost and regained within a short time after it has already settled, or coordinates at the same fixed point that keep moving.
At least three kinds of information should be read together: whether the positioning state is switching between fixed and float; whether differential age, satellite count and C/N0 are changing at the same time; and whether the position change follows a network handover, a vehicle start, device warm-up or a change in obstruction. Only by lining the symptom up with the time of occurrence can you tell which part of the link is at fault.
Diagnosis principle: change one variable at a time. Complete one baseline record first with the same receiver, the same pole and the same fixed point, then change only one condition per round — a different mountpoint, a different SIM card, a different power source, or a move to open sky. Keep the raw log for every round, so that several variables changing at once does not make attribution impossible.
01Differential link: is the data reaching the receiver continuously
NTRIP/CORS, a radio or a local base station supplies differential data that enters the receiver as standard messages such as RTCM. A wrong mountpoint, an account concurrency limit, a mobile-network handover, a serial baud-rate mismatch or radio interference can each make the differential data intermittent. If the fixed-solution jumps always come with a rising differential age, larger packet intervals or network reconnects, check the link first rather than adjusting the positioning algorithm.
In the field, connect the same receiver to NTRIP and to a local radio in turn: if the jumps appear on only one of the links, the problem can be narrowed to that link. Record the mountpoint, the data-source IP or domain, differential age, packet-loss times and reconnect count; do not write only "poor signal".
02Base station and pole height: a fixed solution does not mean the coordinate frame is correct
The base station coordinates, the antenna height and the coordinate transformation parameters determine the final coordinate result. A wrong base coordinate shifts the whole result; a wrong base antenna height or rover pole height mainly affects elevation; inconsistent coordinate systems, projection parameters or seven-parameter sets make the coordinates appear to jump or fall on the wrong grid. The RTK solution state can still read fixed while the result does not meet the project coordinate requirement.
During investigation, verify whether the base station was changed, whether the mountpoint corresponds to the same base, whether the base antenna height was re-measured, and whether the rover pole height and the way it is measured match the controller parameters. The further the rover is from the base, the weaker the spatial correlation of atmospheric and other errors, so long-baseline scenarios should follow the project network design instead of judging the result only by the fixed state.
03Satellite environment: use C/N0, satellite count and PDOP to find obstructions
When the antenna is obstructed by a building, a vehicle body, a metal bracket or tree canopy, the number of usable satellites and the C/N0 fall, PDOP rises, and the fixed solution is more likely to repeat. Near glass curtain walls, metal shelving, water surfaces or large reflecting surfaces, multipath error also increases. It is not enough to look at how many satellites can be seen; satellite count, C/N0 and PDOP must be compared with the fixed-solution state on the same time axis.
At a suspect point, run a control measurement in open sky: keep the device and pole height unchanged and move to an open area to record continuously for 10 minutes. If the open area is stable while the original position keeps jumping, continue to deal with the mounting position, the reflecting environment and the antenna field of view, rather than masking the problem by raising the mounting height.
04Power and thermal stability: do the jumps coincide with load changes
Mobile-network transmission, screen brightness, external modules and low or high ambient temperature change the receiver load. An ageing battery, cable voltage drop, a poor USB contact or an oxidised connector can cause supply fluctuation under transient load, showing up as intermittent positioning-state or communication faults. Temperature-related drift may also come from prolonged exposure to the sun, restricted heat dissipation or module warm-up.
During re-testing, record input voltage, power method, cable length, connector condition and device surface temperature, and compare against a second power source that has already been verified. The H13/H11 data specifies a USB-C 5V/2A adapter; external supplies should leave margin for the peak current of the whole unit and for cable voltage drop — "it powers on" is not a substitute for a power acceptance check.
05Logs and reproduction: turn an intermittent problem into confirmable evidence
RTK data is a time series, and a single screenshot is not enough to prove a problem. At a 10Hz rover output, 10 minutes gives roughly 6,000 positions; the H13 and H11 Pro support up to 20Hz, corresponding to about 12,000 points. A continuous raw log shows the number of state changes, the spread of coordinates, and the differential age and satellite metrics before and after an anomaly.
The log should contain at least UTC time, solution state, latitude/longitude and elevation, satellite count, PDOP, differential age, data age, primary-antenna C/N0, input voltage/temperature (if supported by the device) and network reconnect events. When reproducing, do not trim the 60 seconds before and after the anomaly, or causality becomes hard to judge.
H13 centimetre-level RTK handheld terminal
- Positioning: full-constellation centimetre-level RTK; NTRIP CORS differential support; typical time to first fix <10s.
- Update rate: 1-20Hz (10Hz default), which preserves a continuous time-series log.
- Communication and interaction: 4G full-network + Bluetooth 5.1; ISP high-definition screen and voice broadcast.
- Protection and runtime: IP67, 2m drop resistance, 4000mAh, RTK runtime ≥20h, USB-C 5V/2A.
H11 Pro portable multi-frequency positioning terminal
- Core platform: 1408 channels, based on NebulasIV, the same module family as the H13.
- RTK accuracy (RMS): horizontal 0.8cm+1ppm; elevation 1.5cm+1ppm.
- Update rate: 1-20Hz; NTRIP, MQTT and dual-mode Bluetooth support.
- Environment and configuration: OLED display, IP67, USB-C 5V/2A adapter, GboxTools configuration.
The parameters above are compiled from the YUEETEK website product pages and product specifications, checked on 2026-10-10. For an actual project, the specification of the corresponding batch, the delivered configuration and the technical agreement take precedence.
An acceptable conclusion should contain reproducible data, for example: "At the same point and pole height, the original mountpoint showed 18 fixed-solution changes over 10 minutes, with a median differential age of 1.8s; after switching to the backup mountpoint the same period showed 0 changes, and the horizontal coordinate range at the fixed point fell from X cm to Y cm." This kind of record points directly at the differential link and lets later maintenance staff verify it again.
By contrast, "it worked after a restart", "it was fine after swapping the unit" and "the signal is poor here" do not prove a root cause. If the problem disappears after replacing a single unit, keep the original unit's log and run a cross-test, to confirm whether the difference is in the device, the configuration or the environment.
Is a jumping fixed solution always a module problem?
No. An interruption in the differential data, a wrong base configuration, obstruction and multipath, or supply fluctuation can each produce the same symptom, so rule them out in link order first.
Can results be produced as soon as a fixed solution appears?
The state alone is not enough. Also check the base, the pole height, the coordinate parameters, the repeatability of the fixed point and the project accuracy requirement.
Why record continuously for 10 minutes?
An intermittent jump needs enough samples and the context before and after the anomaly. At 10Hz, 10 minutes already gives about 6,000 points, which supports a conclusion better than a single screenshot.
