GNSS is now widely used in automotive systems, industrial handheld devices, and IoT equipment. Yet a datasheet claim of “supports GPS, Galileo, BDS, and other constellations” does not guarantee that the finished product will perform as expected. Antenna and mechanical design, firmware algorithms, and how mature the support for each constellation is can all introduce performance gaps after integration that the datasheet won’t reveal. Drawing on measurements from three types of products, this article examines GNSS positioning risks that are easily overlooked before mass production and launch.
1. DUT Overview and Key Findings
We tested three types of GNSS-enabled products: (1) an automotive information display terminal (with the GNSS module and antenna both built into the enclosure); (2) an industrial handheld tool module (whose datasheet claims multi-constellation support, including GPS and Galileo); and (3) a gateway from a Japanese IoT service provider. In Cases 1 and 3, the DUT was measured side by side with an industry reference module (u-blox). The tests revealed two key issues that could directly affect the quality of mass-produced units:
- Antenna sensitivity loss caused by the enclosure:
The tracking sensitivity of the automotive display terminal was 8 dB worse than the reference module, mainly due to shielding and impedance mismatch caused by the plastic housing and internal metal parts. - A gap between “claimed support” and actual multi-constellation performance:
The same chipset showed vastly different levels of support maturity for GPS and Galileo. Galileo’s cold-start time was more than 7× that of GPS, and dynamic positioning failed outright at standard signal strength.
The three cases below present the full measurement data along with Allion’s recommendations.
2. Test Equipment and Setup
| Item | Equipment / Environment | Function and Purpose |
|---|---|---|
| Test environment | Fully anechoic chamber / shielded room | Lined with high-performance RF absorbers to simulate reflection-free, free-space propagation and isolate external noise |
| Satellite signal source | R&S SMBV100B vector signal generator | Generates multi-constellation GNSS RF signals with precise, user-configurable carrier-to-noise ratio (C/N), frequency band, and signal power |
| Device under test (DUT) | Automotive information display terminal / industrial handheld tool module / IoT Gateway | Production units with built-in GNSS modules and antennas, used to evaluate how the enclosure and hardware design affect antenna performance |
| Industry reference module | u-blox Reference Module | Serves as the industry benchmark (golden sample) for consistent baseline comparison |
3. Case 1: Automotive Information Display vs. Industry Reference Module
Test conditions:
GPS, L1 band, 6 visible satellites; DUT and reference module measured simultaneously.
| Test Item | Automotive Display | Reference Module (u-blox) | Gap | Allion Analysis |
|---|---|---|---|---|
| Cold-start TTFF | 45 s | 36 s | +9 | The gap narrows at warm start, where the DUT even edges ahead slightly. The cold-start gap is mainly due to ephemeris download and initial satellite search efficiency. |
| Warm-start TTFF | 29 s | 34 s | −5 | |
| Hot-start TTFF | 3 s | 2.3 s | +0.7 | |
| Static position accuracy | 5 m | 0 m | 5 | Used mainly for navigation, so 3–5 m is acceptable on open roads |
| Dynamic position accuracy | 1 m | 1 m | 0 | |
| Tracking sensitivity | −127.25 dBm | −135.25 dBm | +8 dB (degraded) | Key Issue: Sensitivity degraded by 8 dB, mainly due to shielding and impedance mismatch caused by the plastic housing and internal metal parts |
| Acquisition sensitivity | −118.25 dBm | −126.25 dBm | +8 dB (degraded) | |
| Reacquisition time | 2 s | 2.5 s | −0.5 | Recovery after signal loss is comparable; the algorithm’s state-machine transitions work as expected |
Measured on its own, a DUT reading of −127.25 dBm is hard to judge. Benchmarking against an industry reference module, however, clearly pinpoints an 8 dB sensitivity loss, giving the mechanical and antenna teams concrete data for improving the antenna keep-out area. We recommend first reviewing metal-part routing around the antenna and the dielectric constant of the enclosure material.
4. Case 2: Industrial Handheld Tool Module – Real-World Performance Gaps in Multi-Constellation Support
Test conditions:
Independent performance tests for GPS (L1) and Galileo (E1) at a fixed carrier-to-noise ratio (C/N).
| Metric | GPS (L1) | Galileo (E1) | Gap / Status | Allion Analysis |
|---|---|---|---|---|
| Cold-start TTFF | 26 s | 184 s | More than 7× | Key Issue: GPS warm start is slower than cold start, possibly because the ephemeris caching mechanism actually slows down the position solution. Galileo TTFF shows a significant startup delay. |
| Warm-start TTFF | 32 s | 91 s | 3× | |
| Hot-start TTFF | 3 s | 56 s | 18× | |
| Static position accuracy | 1 m | 1 m | Comparable | Static accuracy of 1 m meets the engineering requirements for GIS data collection, but dynamic accuracy of 5 m may cause marker offsets in densely built facility areas |
| Dynamic position accuracy | 5 m | 4 m | ||
| Tracking sensitivity | −151.02 dBm | −148.9 dBm | −2.12 | Comparable |
| Acquisition sensitivity | −141.48 dBm | −129.63 dBm | −11.85 | Key Issue: Galileo performance significantly degraded |
| Reacquisition time | 2.71 s | 4.65 s | −1.94 | Comparable |
| Overall performance | Meets specifications | Significantly degraded | — | The chipset’s satellite selection algorithm and firmware architecture are not optimized for Galileo ephemeris to the same degree as GPS |
A datasheet claim of “multi-constellation support” does not mean performance is consistent across constellations. This case shows that the same product can perform very differently on different satellite systems, and only constellation-by-constellation testing can uncover these hidden defects before launch. We recommend that the firmware team optimize Galileo satellite-selection weighting and the ephemeris solution process separately, rather than reusing GPS default parameters.
5. Case 3: IoT Gateway vs. Industry Reference Module
Test conditions:
BDS, B1 band, 6 visible satellites; DUT and reference module measured simultaneously.
| Test Item | IoT Gateway | Reference Module (u-blox) | Gap | Analysis |
|---|---|---|---|---|
| Cold-start TTFF | 35 s | 32 s | +3 | Comparable to the reference module |
| Warm-start TTFF | 39 s | 38 s | +1 | |
| Hot-start TTFF | 1 s | 1 s | 0 | |
| Static position accuracy | 0 m | 0 m | 0 | The gateway is used mainly for network time synchronization, so a 4 m gap is acceptable |
| Dynamic position accuracy | 5 m | 1 m | +4 | |
| Tracking sensitivity | −152.66 dBm | −155.16 dBm | +2.5 | Comparable to the reference module |
| Acquisition sensitivity | −137.66 dBm | −136.39 dBm | −1.27 | |
| Reacquisition time | 3 s | 3 s | 0 | Comparable to the reference module |
Overall performance is close to the reference module, with TTFF, sensitivity, and reacquisition time all within 3 dB / 3 s, showing that baseline positioning capability is ready for mass production. The one exception is dynamic accuracy: 5 m for the DUT versus 1 m for the reference module, a 4 m gap. Whether this affects actual service quality depends on the IoT provider’s internal accuracy specifications. If the customer requires tighter accuracy (e.g., 3 m), we recommend further tuning the dynamic trajectory-tracking algorithm. This case also shows that even when results meet expectations, side-by-side benchmarking against an industry reference module provides quantified evidence of quality that can serve as the data basis for shipment acceptance.
6. Summary and Key Improvement Metrics
These three cases reveal two hidden risks that cannot be caught during datasheet review: shielding loss from the enclosure, and performance gaps in multi-constellation support. Both can only be quantified through system-level testing in a controlled signal environment.
The IoT Gateway in Case 3 performed close to the reference module, underscoring that “even products that perform well need data to back them up”: without benchmark comparison data, there is no way to prove to customers that quality meets the bar.
| Key Metric | Measured Result | Quality Implication |
|---|---|---|
| Sensitivity loss from enclosure shielding | 8 dB (tracking and acquisition degraded equally) |
The enclosure and metal structures are a risk that must be quantified before mass production; the antenna team should use this data to work out keep-out area requirements |
| GPS vs. Galileo cold-start gap | More than 7× (26 s vs. 184 s) |
GPS results cannot be used to infer performance on other constellations; each one must be validated independently |
| Galileo acquisition sensitivity loss | 11.85 dB (vs. GPS) |
In weak-signal environments, Galileo contributes almost nothing to positioning, greatly reducing the real-world benefit of multi-constellation support |
| Constellation that failed dynamic positioning | Galileo (Fail at standard C/N) |
Satellite-selection logic must be debugged separately for each constellation, and single-constellation dynamic trajectory tests should be run before launch |
| Value of benchmark comparison | IoT Gateway within 3 dB of the reference module | Even when results are normal, quantified data is essential evidence for proving quality to end customers |