Aller au contenu
Accueil » Ublox – CloudLocate Evaluation

Ublox – CloudLocate Evaluation

ublox cloudlocate

This one has been waiting on the to-do list for a while. CloudLocate is a location service announced by u-blox around 2021, and it’s part of the Thingstream Location-as-a-Service package. The primary goal of the service is to reduce Time-To-First-Fix (TTFF) by offloading satellite measurement data to the cloud. This allows position calculation to happen remotely, eliminating the need for the host device to perform local GNSS computations.

More information is available on the u-blox website:

As outlined in the documentation, CloudLocate offers more capabilities than just GNSS offloading. It also supports location determination based on Wi-Fi hotspots and cellular cell IDs, which is especially useful when GNSS signals are unavailable. However, these features will not be covered in this article.

According to u-blox, CloudLocate can achieve a TTFF of less than 5 seconds, compared to the typical ~30 seconds required for a GNSS cold start. This is particularly advantageous for low-power applications, as it significantly reduces the energy needed to acquire a position fix. That said, the benefits of CloudLocate go beyond just power efficiency. It can also be useful in scenarios with limited satellite visibility, such as:

  • Cold start under challenging environments.
  • Devices with design constraints (e.g., small or low-gain antennas)
  • Applications like personal locator beacons, where obtaining a fast initial fix is critical—even at the cost of some accuracy

As always with these articles, this test will focus on those aspects. The goal is not to replicate the controlled performance figures published by u-blox, but rather to evaluate how CloudLocate performs under real-world, uncontrolled, and less-than-ideal conditions.


A-Test Methodology

Two sets of measurements will be taken:

  1. Reference Setup: Using a u-blox EVK-M101 evaluation kit with an ANN-MB antenna. This represents an ideal hardware integration with known, validated performance. It establishes a baseline for what can be expected under good hardware conditions but limited sky visibility.
  2. Custom Device: A custom design that uses an 18×18 mm patch antenna on a small ground plane, along with nearby electronics that reduce clearance around the antenna. This kind of constrained integration is typical in compact, portable devices. The aim is to evaluate performance under both limited sky visibility and suboptimal hardware conditions.

A.1-Measurement Procedure

For each setup, 10 individual fixes are taken following this sequence:

  1. Cold Start: The module is cold-started using the CFG-RST command.
  2. Wait for MEAS50 Message: The test waits for a MEAS50 message, which is specific to the u-blox M10 family and used by CloudLocate.
  3. Send to CloudLocate: The MEAS50 message is uploaded to the CloudLocate service. If no valid position is returned, the process repeats from step 2 until a valid location is received.
  4. Measure CloudLocate TTFF and Accuracy: The CloudLocate TTFF (CL.TTFF) is the elapsed time from cold start to the moment a valid position is returned. The returned position is compared to the known real-world location using Google Maps. The CloudLocate Accuracy (CL.ACC) is defined as the distance between these two points.
  5. Determine Local TTFF: The module continues running after the cloud-based fix, and the time it takes for the local GNSS engine to reach an accuracy estimate equal to or better than CL.ACC is recorded. This is the Local TTFF (L.TTFF).

The purpose is to quantify how much time is saved by using CloudLocate to achieve a similar accuracy level.

A.2-Limitations of the Method

This approach however introduces two related caveats that may impact the validity of the Local TTFF measurement:

  • The recorded Local TTFF may be greater than or equal to the TTFF reported internally by the module via the UBX-NAV-STATUS message.
  • The Local TTFF relies on the module’s self-estimated accuracy, which may be less reliable than the actual error when manually compared on a map.

A.3-Reported Metrics

The following metrics will be reported for each fix:

  • CL.TTFF (s): CloudLocate TTFF – time from cold start to the first valid cloud-based fix.
  • CL.ACC (m): CloudLocate Accuracy – distance between CloudLocate fix and the known position (measured via Google Maps).
  • L.TTFF (s): Local TTFF – time for the GNSS module to match or exceed CloudLocate accuracy, based on its self-reported estimate.
  • AVG CN₀ (dB-Hz): Average signal-to-noise ratio, computed from the “Static View” in u-center, provided for reference on reception quality.

B-Test Environment

Both the reference setup and the custom device are tested in the same environment: a mostly obstructed, covered balcony, which limits GNSS visibility and simulates a realistic challenging use case.


C-Measurements and results

C.1-EVK-M101 & ANN-MB

C.1.1-Measurements

EVK-M101 TTFF VS CloudLocate TTFF Measurement
EVK-M101 TTFF VS CloudLocate TTFF graph

C.1.2-Test Observations

  • The average Local TTFF (L.TTFF) was approximately 30 seconds, which aligns with typical expectations for a cold start.
  • The CloudLocate TTFF (CL.TTFF) was consistently below 5 seconds across all samples.
  • When compared to L.TTFF, CloudLocate offers an average TTFF improvement of approximately 8.3×.

C.1.3-Side Notes and Considerations

  • During testing, it was observed that in most cases, the Local TTFF matched the TTFF reported by the UBX-NAV-STATUS message. This suggests that in a real-world application operating under similar conditions, CloudLocate could provide a first position fix up to 8.3 times faster, regardless of accuracy considerations.
  • Developers should keep in mind that longer measurement periods typically yield more accurate results. This test focused on the absolute earliest possible fix, which is ideal for time-critical applications. However, use cases requiring higher positional accuracy should allow the device to remain active for a longer duration before relying on the fix.

C.2-Custom Design: MIA-M10Q with Passive 18x18mm Antenna

Custom MIA-M10 design

This setup represents a typical integration found in small, portable devices—where compromises are often necessary due to size and layout constraints. In this design:

  • A compact 18x18mm passive antenna is used.
  • The antenna does not follow the manufacturer’s recommended integration guidelines, regarding the ground plane size.
  • There is minimal clearance between the antenna and other components on the PCB (with miscellaneous components occupying the orange-shaded area).

By definition, this kind of integration is not expected to match the performance of a more ideal setup, such as the 50x50mm active antenna used on the EVK board.

However, while the standalone GNSS performance of this board is sufficient for its intended use case—primarily outdoor, open-sky scenarios—it serves as an excellent candidate to evaluate the benefits of CloudLocate under suboptimal hardware and limited visibility conditions, particularly in improving Time-To-First-Fix (TTFF).

Custom design VS CloudLocate TTFF Measurement
Custom design VS CloudLocate TTFF graph

C.2.2-Test Observations

  • As expected, the design compromises had a noticeable impact on performance: Average CN₀ values were lower, indicating weaker satellite signal reception. The average Local TTFF (L.TTFF) roughly doubled compared to the EVK setup. Results showed greater variability and reduced predictability.
  • Despite the limitations, CloudLocate still improved TTFF by a factor of 2.07. While this is lower than in the optimal setup, it remains a significant benefit for battery-powered devices, where every second of reduced power-on time contributes to energy savings.

C.2.3-Side Notes and Considerations

  • Interestingly, the CloudLocate accuracy (CL.ACC) in this setup was better than in the previous test. This is likely due to the module spending more time collecting satellite data before a successful fix was returned.
  • The MIA-M10 typically starts generating MEAS50 messages within 4 to 5 seconds of a cold start. However, CloudLocate may still return a “Location not found” response on the first attempts, probably caused by the degraded signal conditions.

D-Conclusion

Despite signal or hardware limitations, CloudLocate significantly reduces Time-To-First-Fix (TTFF), delivering up to 8.3× faster fixes in ideal conditions and still 2× faster in constrained hardware designs. This results in valuable power savings and improved responsiveness—critical for battery-powered and time-sensitive applications.


Disclaimer

Test results shown in this article are only indicative, tests were performed in uncontrolled environment, repeatability is not guaranteed.

#ublox #gnss #cloudlocate

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

fr_FRFrançais