Replacing the GNSS Module and Antenna Did Not Improve Accuracy: A Seven-Step Troubleshooting Record

2026-11-04/ By Admin

In my years providing technical support for SKG123 series GNSS modules, one of the most common requests is “accuracy won’t improve.” The opening is often similar: the module was replaced, the antenna was replaced, parameters were restored to default, and the number is still the same.

Replacing one hardware component after another often leads nowhere: positioning accuracy is determined jointly by satellite geometry and ranging error, positioning error ≈ DOP × ranging error; replacing any one link does not mean the entire error chain has changed. DOP is the factor by which satellite geometry amplifies ranging error; on the ranging-error side, the seven steps can address multipath, obstruction, and receiver noise. Ionospheric, tropospheric, and ephemeris/clock residual errors are not listed as separate troubleshooting steps: the customer side has no interface to adjust or read them individually, so they can only be judged indirectly from the overall state of the differential/dual-frequency link. The seven steps are organized as follows: Step 1 confirms the geometry factor; Steps 2 and 5 examine ranging error item by item; Steps 3 and 4 use configuration and log cross-checks to localize the problem to a layer; Steps 6 and 7 handle special links and firmware.

Try to avoid skipping steps; the conclusion from an earlier step determines whether later checks are needed. The only step that can be skipped entirely is Step 6, which pure positioning applications can skip directly.

Step 1: Geometry — First Distinguish “Not Enough Satellites” from “Poorly Distributed Satellites”

Open the NMEA log and look at two quantities: the satellite count in GGA and HDOP (GSA also contains PDOP/VDOP).

These two quantities are often confused, but they mean different things:

• Satellite count is the number of observations and reflects “whether there are enough”;
• DOP is the geometric dilution factor and reflects “whether these satellites are well distributed.” In a partially obstructed scenario, around ten satellites may be visible while HDOP still hovers around 2; in that case, look first at the satellite azimuth distribution rather than just counting satellites.

The corresponding actions follow the criteria: for a single constellation with few visible satellites, first confirm whether multiple constellations (GPS/BDS/GLONASS/Galileo) are all enabled, then use the per-constellation PRN lists in GSA to verify which satellites are actually used in the solution; do not rely only on the status shown in the configuration interface. If multiple constellations are enabled but the satellite count is still low, check antenna gain, mounting location, and obstruction. If multiple constellations are fully enabled and the satellite count is sufficient but DOP is high, constellation switches offer no further gain; record this as environmental geometry and proceed to Step 2 to examine ranging error.

Step 2: Environment Identification — Only Identify Multipath, Do Not Mitigate It

The criterion is the CN0 of each satellite in GSV. Do not apply an absolute threshold first; use relative comparison: within the same environment and the same module, compare differences among satellites and the fluctuation of each individual satellite.

• Uniform drop: under obstruction (tree canopy, enclosure, vehicle interior), the CN0 of all satellites drops together, and the heavier the obstruction, the larger the drop;
• Individual anomalies: a few satellites have persistently low CN0 with significant fluctuation while their elevation is not low — a common signature of multipath (a fixed-geometry reflection path happens to hit these satellites). Note that when direct and reflected signals add in phase, CN0 may also be elevated; when they are out of phase, a pronounced dip appears. When interpreting, look at the fluctuation pattern, not just whether CN0 has dropped;
• Environmental comparison: compare the azimuth of satellites with abnormal CN0 against the azimuth of glass curtain walls, water surfaces, or traffic flow at the site. If they match, record it as suspected multipath and leave it for Step 5; if they do not match, return to Step 4 to check whether GSV and GSA are consistent, then decide whether to rule out multipath.

Step 3: Configuration Check — The Two Most Common Errors

Default configurations do not necessarily match the site, so “restore defaults” cannot be treated as a fallback action.

Error 1: The expected differential-positioning accuracy does not match the actual positioning state. The customer expects centimeter-level accuracy, but the GGA position quality field remains at 1 (single point) or 5 (RTK float). First determine where it is stuck: if it is stuck at 1, first check whether the differential data source and base-station link are connected; if the link is normal but it remains at 1, confirm whether this module supports differential positioning. If it does, continue checking the format, checksum, and age of the differential data; if it does not, this is a selection issue. If it is stuck at 5, differential data is already arriving, and the problem is failure to reach a fixed solution; focus on base-station link quality, baseline conditions, and fix rate. The two paths have different inspection targets, so first determine which path the customer’s expected metric should follow, and do not mix adjustments.

Error 2: Elevation mask. The satellite elevation mask can be set from 1° to 20°, with a default of 5° (read/write via PAIR072); there is also a minimum SNR threshold (Min SNR) from 9 to 37 dB, with a default of 9 dB (PAIR058). If set too low, low-elevation observations bring in multipath and atmospheric errors; if set too high, the number of usable satellites decreases, and even good mid-elevation satellites may be filtered out. The check is straightforward: read back the effective threshold with PAIR072 and compare it with the configuration, changing only one parameter per retest.

Step 4: Log Cross-Validation — Five Metrics Must Be Consistent

Without logs, there is little basis for adjusting configuration or replacing hardware. Export raw NMEA over a period and read five metrics sentence by sentence: satellite count (GGA), DOP (GGA/GSA), CN0 (GSV), position quality (GGA), and the list of satellites used in the solution (GSA). A single metric describes a state; when metrics do not agree, it becomes easier to localize the problem to a specific stage:

1. Many satellites but high DOP → constellation geometry problem; return to Step 1;
2. Few satellites but high CN0 on every satellite → the elevation mask may be too high (filtering out good mid-elevation satellites); return to Step 3 for review;
3. A satellite with acceptable CN0 in GSV is absent from GSA → first suspect that it has been removed by the quality strategy, and use Step 5 to judge whether the rejection is reasonable. Conversely, if a satellite is present in GSA but cannot be found in GSV, first check GSV output completeness; only after these two checks should you discuss “missing satellites”:
   1. Whether that constellation’s GSV output is complete across multiple sentences (each GSV sentence carries at most four satellites, and missing one of several sentences is common), and whether the per-constellation GSV output switches (each constellation can be disabled separately) have been changed;
   1. Whether the “rotate output” mode (disabled by default on the platform) has been enabled — when rotation is on, GSV sentences rotate across fix epochs, and a capture window that is too short will make satellites “appear missing” when in fact the capture was incomplete.
4. Position quality oscillates between 1 and 5 → unstable differential link; return to the RTK path in Step 3, focus on the fix rate, and do not calculate statistics on a single-point error basis.

When more detailed satellite status is needed, the platform also provides extended PVT SV status / PVT SV in view output (PAIR120/PAIR124), which provides detailed status of satellites used in the solution and is suitable for satellite-by-satellite verification.

Our support process therefore requires that logs be accompanied by the firmware version and a configuration snapshot: only with the version and configuration can we determine whether the anomaly comes from parameters, firmware, environment, or hardware.

Step 5: Quality Control and Rejection of Observations

Step 2 identified contaminated observations; this step decides how to handle them. The positioning solution weights observations by quality. If all observations enter the solution with the same weight, a single pseudorange severely contaminated by multipath can bias the solution. Receiver-side quality control usually has two layers: stochastic-model weighting based on elevation/CN0, plus gross-error rejection based on residual testing.

This layer is built into the firmware in our modules; the customer side has no direct weight-adjustment interface. What the customer can do is tighten the thresholds in Step 3 or directly exclude a specific satellite. Three relevant interfaces are documented on the platform: the global minimum SNR threshold (PAIR058, default 9 dB), dual-threshold satellite selection based on “satellite count + CNR” in Drone mode (PAIR150, 0–78 satellites / 0–65 dB), and the SV blacklist (blacklisting by PRN/SV, PAIR130/PAIR131; for SBAS, PAIR418/PAIR419).

To determine whether the problem lies on the environment/differential side or the firmware side, follow these two paths: if the contaminated observations can be correctly suppressed by the built-in strategy, first return to Step 1 to review environmental geometry, then return to Step 3 to review the differential link; if the contaminated observations persistently break through the strategy — a satellite with abnormal CN0 fluctuation is always used in the solution and its residuals do not converge — the manufacturer needs to investigate according to the firmware quality strategy. When such a breakthrough occurs, retain the raw NMEA, firmware version, and configuration snapshot, and then contact the manufacturer for analysis.

Step 6: Timing-Chain Review (Timing Applications Only; Not a General Step)

Only products that use PPS/timing output need this step; pure positioning applications can skip it.

Timing metrics and positioning metrics should be counted separately: PPS intra-second jitter and time offset belong to timing accuracy, while position drift belongs to positioning accuracy. If the two are suspected of interfering with each other, perform an isolation test: keep the positioning configuration unchanged, first disable PPS output and re-measure positioning metrics, then restore output and repeat the measurement. If the two rounds agree, PPS output does not affect positioning; return to Step 4 to look for conflicting metrics. The positioning solution itself is not affected by the PPS output switch.

Step 7: Firmware Version and Wrap-Up

Version check: confirm whether the firmware is the latest released version and whether a version optimized for the scenario exists. During operation, PAIR020 can be used to query firmware version information directly.

If problems remain after the first six steps, contact the manufacturer with logs, firmware version, configuration snapshot, and reproduction steps. The manufacturer’s software team can verify the quality strategy at the firmware level and provide parameter adjustments for the specific scenario; this process starts with logs, and without new logs, continuing to replace hardware will not narrow the problem down.

Closing: A Consistency Quick-Reference Table

The troubleshooting order narrows the range layer by layer: geometry, environment, configuration, data, and firmware. If you replace hardware before looking at logs, the logs reflect the post-replacement state, and you lose the baseline for comparison with the original fault state.