CloudLocate getting started
Last update: September 27th, 2022
The service provides several benefits:
battery drain minimization: typically the GNSS consumes from 25% to 50% of the device battery. With CloudLocate the GNSS is switched on for few second (1 to 10) and therefore it consumes significantly less power than a standard approach where the GNSS takes at least 30 seconds to fix a position.
data consumption minimization: the device sends to the cloud only the GNSS raw data sent to cloud (from 12 bytes to 50 bytes). As explained in the next point there is no need to download form server any additional data.
no need of assistance: the GNSS does not need any type of assistance data (ephemeris, almanac) therefore it's the best solution for high latency/low bandwidth networks (i.e. LoRa, Satellite connectivity, NB-IoT) where downloading assistance is definitely not an option.
latency reduction: the estimated position reaches your cloud application immediately thanks to the Cloud-to Cloud-connection
fast prototyping: through very few simple configurations you are ready for the field tests
scalability: once you move to production, you do not need to worry about additional complexity. Device configuration remains the same for all the devices
secure: CloudLocate use a per-device authentication; optionally you can decide to protect the transmitted raw data with additional TLS protection
In this section
CloudLocate works in a pretty simple way. The GNSS, during acquisition phase, generates a raw measurement to be sent to the service endpoint. The cloud location engine takes in input this measurements and through a sophisticated algorithm estimates the position and send it directly to your cloud application. If needed, the position can be also sent back to the device.
A raw measurement is a binary u-blox message, containing the satellites information in an optimized format.
CloudLocate is the most appropriate solution in all the use cases in which the priority is to extend the battery life and you need an accuracy in the range of 10 meters, with few position updates per day.
Typical applications are
Logistic, supply chain
Cold chain management
As mentioned, CloudLocate is independent by the network connectivity of the device and it offers an incomparable advantage if your device runs in a low bandwidth network; the raw measurements generated by GNSS can easily fit in the small MTU (Maximum Transmission Unit) typically allowed in these Wide Area Network.
Also if your device has multiple connections you can easily and dynamically switch between them without any service configuration.
Because you do not need to download any data from the service, CloudLocate works even in unidirectional connectivity (uplink)
To use the service you need
a u-blox GNSS or a u-blox combo module (CEL+GNSS) that support the service as listed in the next section
the access to Thingstream, that is the u-blox service delivery platform. More information are provided in a following section.
an internet connection to send the data from the device to the service and get the estimated position
To evaluate the service, you can use:
any from factor of the u-blox GNSS modules M8/M9/F9/M10, or a corresponding EVK available in the u-blox product selector
u-blox M10 GNSS with FW SPG 5.10 offers an out-of-the-box experience and a significant power saving that makes it the best choice for every IoT application, especially for power constrained devices.
u-blox service platform sign-up
u-blox Thingstream is the service delivery platform providing a management console that you can use to enable and manage the entire suite of u-blox services , including IoT Location-as-a-Services and your Location Things (the logical representation of your location device in the Thingstream platform).
Sign-up is free, quick and easy. Just go to the management console and register with your company information. If you already have a Thingstream domain for IoT Communication-as-a-Service (MQTT Anywhere, MQTT Here or MQTT Now), or for IoT Security-as-a-Service you do not need to register again.
To use CloudLocate service you are requested to:
select the most appropriate u-blox GNSS for your device
select the most appropriate raw measurement type according to your use case
CloudLocate is supported by all the latest generation of u-blox GNSS M8/M9/F9/M10 in all the available form factors. If your use case is in the typical application listed above or you are using a low bandwidth network we suggest to take advantage of the latest generation of GNSS (M10) that is consuming 70% less than the previous M8. The next section describes all the steps to configure the service for M10.
In case you want to retrofit your u-blox M8/M9 already in the field you can still take advantage of all the benefits listed above. In such case, proceed with this guide
Raw measurement selection
To select the proper raw measurement type you should consider the following aspects:
maximum payload size (bytes) supported by network
desired accuracy for your application
Regarding position accuracy, while UBX-RXM-MEASX and UBX-RXM-MEAS50 can provide in median an accuracy of 10 meters, UBX-RXM-MEAS20 accuracy is 20-30 meters and, UBX-RXM-MEAS12 is 30-40 meters.
Step by step guide
CloudLocate configuration needs 3 simple steps:
Configure the u-blox M10 GNSS
Configure the service in u-blox Thingstream service delivery platform
Generate the raw measurement in the GNSS and obtain the estimated position in the cloud service
Configure the M10 GNSS
For the complete GNSS configuration you can refer to the guide M10 firmware 5.10 interface description, independently from the form factor (section UBX-CFG-VALSET). Here below you can find the list of the most relevant configurations:
Enable the GPS constellation only and disable the others.
Enable the desired raw measurement, (only one) according to your design. If your network support a 50 byte payload, enable the MEAS50 raw measurement that can deliver the best performance.
By doing this configuration, the GNSS starts sending in output the selected message (2Hz rate) that will be used by the service to estimate the position.
in case you want to use the 12 bytes raw measurement, you shall enable two messages (UBX-RXM-MEASC12 and UBX-RXM-MEASD12), each of them 12 bytes long
If you want to further minimize the transmitted data you can use only UBX-RXM-MEASC12 raw measurement under the condition that you can provide a corse position in advance with 100 Km of accuracy. Contact the support for more information.
To use MEASX raw measurement, you need to implement a filtering logic in the host processor to validate the quality of the satellite signals (this is done internally in the GNSS for the other measurements type). In such case you can refer to the guide for M8/M9 GNSS that only support MEASX measurement type.
In case you need to disable the raw measurement, you can use the following UBX configuration message
Note: the message configurations will only be saved in RAM. To store it in flash, refer to section UBX-CFG-VALSET
Configure the Thingstream platform
Thingstream is the u-blox service delivery platform just described above in this guide.
Sign-in/Sign-up in the platform
Create a Location Thing for each of your device, that is the logical representation of your device in the platform:
select Location Services from the side bar of the Thingstream console and click on Add Location Thing in the top right of the screen.
then select the "Add CloudLocate Thing", and give it a name.
assign to it a price plan. To get started, use the Developer plan which offers 100 free requests per month or purchase a plan from the selection available. You can find more information about the CloudLocate plans on our pricing page.
Get the MQTT credentials and the list of topic to configure the MQTT client in the device. as explained in the following section
Note: when moving to production you can automate steps 2 and 3 using the Zero Touch Provisioning feature.
Test the service
Just need few additional steps to test the service.
Configure the MQTT client in the device with the credential and the endpoint that you have retrieved in the previous section.
Configure the MQTT client in the device to publish data in the CloudLocate/GNSS/request topic
Send the UBX-CFG-RST command to simulate a GNSS cold start
Capture the selected raw measurements (UBX-RXM-MEAS50/MEAS20/MEAS12) sent in output by the GNSS and publish it in the CloudLocate/GNSS/request topic. In normal signal conditions, GNSS takes around 3 seconds to generate the first measurement, and then it generate a new measurement every 500 milliseconds. You can decide to send the first measurement or wait more time and send one of the following message
Note: the just generated raw measurement shall be sent to the service within 60 seconds. If you need to store it and send to service in a later time you can leverage the not-real time option described at the end of this guide.
Note: Before sending the UBX-RXM-MEAS* message to the server, the host must remove the UBX header (8 bytes) from the message leaving just the 12-, 20- or 50-bytes payload. Also the checksum shall be removed
To get the the estimated position, the device shall subscribe to the response topic that is reported in the Topic section of the thing detail. As an example:
The estimation takes few tens of milliseconds, without considering the network latency.
In most of the use cases you need to get the estimated location on your application in the cloud, rather than on the device. This option is explained in the next section
Note: for more information about the structure of the u-blox GNSS message containing the GNSS raw measurement, you can refer to this guide
Here below a typical response of the CloudLocate server
To simplify your initial tests you can use the sample code available in the Download area of the Thingstream platform in the section IoT Location-as-a-Service > CloudLocate: Python reference Implementation for M10 in standalone configuration
Other interfaces to access to CloudLocate
The just described way to access to CloudLocate is named Device to Service, in which the device sends the GNSS raw measurement to the CloudLocate service endpoint and the estimated position can be retrieved both by cloud application and/or by the client (device)
There are other two ways, that are more convenient for different architectures:
Service to Service, that can be used if you need to send the raw measurement to your cloud application and get the estimated position using a REST API
Premium extension, that is preferred if you are already using one of our Communication-as-a-Service solution, like MQTT Anywhere, MQTT Now, MQTT Flex, MQTT Here. Through the Data Flow Manager you can combine multiple premium extension you can create your own logic to manipulate the data and much more using a simple drag and drop interface.
Zero Touch Provisioning
If using the Device to Service access, when going in production it becomes complex to deal with MQTT credential configuration in the device as well as for Location Things creation in the Thingstream platform, because these are all manual tasks.
To simplify and automate this activity you can refer to Zero Touch Provisioning solution.
Not real-time measurements
There are some use cases in which the device does not have connectivity all the time. Even in this case you can use CloudLocate service by storing the time and date of the snapshot and send it in the following format:
Note: The Base64 encoded measurement consists in the payload of UBX-RXM-MEAS* message to the server, without the UBX frame header (8 bytes). Just take the payload of 12-, 20- or 50-bytes payload (no checksum) and encode in base64.
You can find more information about the structure of UBX-RXM-MEAS/50/20/12 GNSS messages in this guide.
Mixed mode allows you maximize the power efficiency and the reliability by using CloudLocate for most of the position estimation and addressing the remaining challenging signal conditions by leveraging the device GNSS engine to estimate the position. This Mixed mode guide explains how to set up the client application.
Get the location on your cloud application
To get the location from your cloud application you need:
create an IP Thing in the Thingstream platform. This is a logical object that provides you the credential to access to the platform with MQTT protocol. Through this Thing you can get the location of all your devices
Select the Things item on the left sidebar
Click on "Add Thing" and then on "Add new IP Thing"; give it a name
Select a plan. For test purpose you can select the developer plan
configure an MQTT client in your cloud application with the credentials and the endpoint provided in the related section of the new IP Thing
Subscribe from the MQTT client in your cloud application to CloudLocate/+/GNSS/response topic to get the position of all the devices using CloudLocate. If you want the position of a single device you can replace the + with the device ID device:xyzwe-9999-1234-5678-9abcdefg
Note: you can decide to get the estimated position on both side (cloud and device) or only on one side by simply subscribing to the right topic. When getting the position on the device you cannot use the wildcard + but only the topic that include the device ID in the path
Payload format summary
This section summarize which are the supported formats accepted by the CloudLocate service according to selected service access mode and the selected raw measurement type.
Regardless the service access mode
when using UBX-RXM-MEASX, the service requires in input the entire UBX message sent in output by the GNSS, including all the headers and the checksum;
when using UBX-RXM-MEAS50/MEAS20/MEAS12 the service needs in input only the payload of the UBX message sent in output by the GNSS, removing the headers and the checksum.
More information about the payload structure is available in the Compact raw measurement section
Device to Service access mode
Real time location:
Option 1: UBXM-RXM-MEAS* payload, header and checksum excluded; the encoding can be base64 or binary. Base64 ensures a safer transmission over the network nodes between the device and the service endpoint but it increase the packet size. This option is not applicable to UBX-RXM-MEASX and to UBX-RXM-MEAS12
Option 2: UBXM-RXM-MEAS* payload, header and checksum excluded; it shall be base64 encoded and inserted in the body attribute of the JSON object while the headers attribute containing the date and time is not required. This option is not applicable to UBX-RXM-MEAS12
Not real-time location: as Option 2 of real-time location, but the JSON object shall include the Date/time information.
Note: MEAS12 is not supported in Device to Service mode, but only in Service to Service access mode
Service to Service access mode (REST API)
Real time location:
Option 1: UBXM-RXM-MEAS* payload, header and checksum excluded, with Base64 encoding . The content type of the API shall be set to plain/text. This option is not applicable to UBX-RXM-MEASX. This option is the best one to minimize the data transmission and so the base64 encoding should be done in the cloud application before issuing the API request
Option 2.: UBXM-RXM-MEAS* entire message, including header and checksum. The message shall be encoded in Base64 and added to the payload parameter. In this case the application/JSON content type shall be set in the API and the JSON format shall be used. Since it's a real-time location, Date/time information is not mandatory
Not real-time location: as Option 2 of real-time location, but the JSON object shall include the Date/time information.
Additional info are available in the API documentation
Premium extension (flow)
Real time location: refer to Device to Service access mode described above
Not real-time location: refer to Device to Service access mode described above