Using GNSS raw measurements
A GNSS raw measurement is a binary u-blox message, generated by u-blox GNSS containing the satellites information in an optimized and very compact format. Delivering these measurements to u-blox cloud hybrid positioning service, you can get an estimation of the position and save up to 90% of the GNSS energy by reducing the on-time period of the GNSS receiver.
As explained in the Getting started guide of CloudLocate, combining the GNSS raw measurements with other sources like Wi-Fi Access points scan and/or cellular base stations scan you can maximize the overall position fix rate also in complex environment for GNSS like urban canyons or areas with limited or null sky view. Therefore you always obtaining the best possible position of the device saving energy at the same time.
Raw measurement selection
There are two options available:
Option 1 uses the format named MEAS50: it's a 50 byte message (plus header and checksum) that contains all the relevant information of the satellites in view, so that the cloud engine can estimate a position
Option 2 uses the format named MEAS20: it's similar to the previous one but it contains the minimum number of satellite required for the position estimation.
If your application support MEAS50 option, it suggested to use this one since it's more accurate and reliable than MEAS20.
Generating a GNSS raw measurement with u-blox M10
The following explanation is based on u-blox M10 GNSS receivers with Firmware version SPG 5.10 or higher.
If you are using a different Firmware version or a different u-blox GNSS (M8 or M9 generation), please contact the support to get further assistance
Step 1 - Configure the 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 the relevant configurations for the raw measurement generation:
Enable the GPS constellation only and disable the others.
GPS Enable: b562068a0900000100001f00311001fb80
Galileo Disable: b562068a0900000100002100311000fc89
BDS Disable: b562068a0900000100002200311000fd8e
Glonass Disable: b562068a0900000100002500311000009d
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.
UBX-RXM-MEAS50: b562068a09000001000049069120019baa
UBX-RXM-MEAS20: b562068a09000001000044069120019691
By doing this configuration, the GNSS starts sending in output the selected message (at 2Hz rate) that will be used by the service to estimate the position.
Send the UBX-CFG-RST command to simulate a GNSS cold start
UBX-CFG-RST: b56206040400ffff01000d5f
Capture the selected raw measurements (UBX-RXM-MEAS50/MEAS20), to be added to the JSON payload as explained below. The captured date shall be converted from binary to Base64, before adding it to the JSON object.
Notes:
In case you need to disable the raw measurement, you can use the following UBX configuration message
UBX-RXM-MEAS50: b562068a09000001000049069120009aa9
UBX-RXM-MEAS20: b562068a09000001000044069120009590
the message configurations will only be saved in RAM. To store it in flash, refer to section UBX-CFG-VALSET
if the quality of the data is not good enough, the GNSS receivers start sending in output the selected message MEAS20 or MEAS50 without any payload, so you need to check the size of the message in the host application before using it. At the end of the guide you can find an indication of the message structure
Step 2 - test GNSS Raw measurement
Depending on network connectivity there are two options to build the JSON payload.
Low-bandwidth connectivity
If you are using LoRAWAN, Satellite or other low bandwidth connectivity, you probably need to minimize the payload size to be sent to the cloud by the IoT device.
In such case there are two options:
send the pure binary payload that is exactly 20 or 50 bytes. Referring to the UBX frame structure reported below you can remove all the preambles and the checksum and just send the payload field. This option is valid only for Device to Service access.
encode in Base64 the binary payload, removing (as just described) all headers and checksum. In such case the raw data is greater than pure binary payload. This option is valid only for Service to Service access
Note: In case you need to store the RAW data in the device and estimate the position at a later time, you need to save also the date and time information for each RAW measurement and get the position estimation through the REST API (Service-to-Service access mode)
Other connectivity type
For connectivity with higher bandwidth, the JSON format is suggested since it can carry more information. A typical payload using MEAS50 is
{
"RequestId": "82cb34c9-88c9",
"GNSSMeasurements": {
"Payload":"tWIChjIAG/M7CcimDqBmvpr+A9pGYVEPdxhiyIqPToNAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAyAA==",
"DateTime": "2023-04-05T12:50:16"
}
}
where the MEAS50 raw measurement is specified in the Payload attribute.
The "Payload" field contains always the MEAS20 or MEAS50 data, including UBX headers and checksum (see below), as sent to the Host by the GNSS receiver, and it's always encoded in Base64.
The DateTime attribute, that indicates the generation time and date, is not required as long as the generated measurement is delivered to the service within 60 seconds from the generation time
This (working) example returns the following position
{
"Location": {
"Lat": 51.4964168,
"Lon": -0.1096041,
"Unc68": 5.35
},
"DateTime": "2023-04-05T12:50:16",
"RequestId": "82cb34c9-88c9",
"LocationSource": "GNSS"
}
The LocationSource attribute shows that the location has been calculated using the provided GNSS raw measurements
Note: when using GNSS Raw data the DateTime parameter in the location response provides the information about the exact UTC date and time when the RAW measurement have been generated with reference to the satellite clock and it might differ from the IoT device date and time.
As second step, if this is a applicable to your use case, you are suggested to build payload using GNSS raw measurements plus Wi-Fi and/or Cellular scans. You can always check the LocationSource attribute to verify which source have been used.
UBX frame structure
The M10 interface description available in the u-blox website specifies the structure of the message (raw measurement) sent-out by the GNSS. It is shown in the following picture:
In this section
Still need help?
CloudLocate getting started guide
If you need more help or have any questions, please send an email to support@thingstream.io
Every frame starts with a 2-byte preamble consisting of two synchronization characters: 0xb5 and 0x62.
A 1-byte message class field follows. A class is a group of messages that are related to each other.
A 1-byte message ID field defines the message that is to follow.
A 2-byte length field follows. The length is defined as being that of the payload only. It does not include the preamble, message class, message ID, length, or UBX checksum fields. The number format of the length field is an unsigned little-endian 16-bit integer (a "U2" in UBX data types).
The payload field contains a variable number (= length) of bytes. In case of MEAS20 or MEAS50 the payload contains exactly 20 or 50 bytes
The two 1-byte CK_A and CK_B fields hold a 16-bit checksum whose calculation is defined in UBX checksum section of interface description
For your reference we briefly summarize below the Class and Message ID for each of the relevant messages described in the previous section that you can use to identify the measurement
50 bytes raw measurements
UBX-RXM-MEAS50 - Class: 0x02 - Message ID: 0x86
20 bytes raw measurement
UBX-RXM-MEAS20 - Class: 0x02 - Message ID: 0x84
Using u-blox M8/M9 receivers
With u-blox M8 and M9 GNSS receivers is still possible to leverage CloudLocate service by using a different type of RAW data (UBX-RXM-MEASX) that is bigger than the MEAS20 and MEAS50 and thus is not applicable to low bandwidth network. The message size is 44 bytes for the header plus 2 bytes for each satellites, therefore at least 164 bytes are required. It is anyway a good option in case to retrofit the devices already in the field.
The CloudLocate M8/M9 guide provides a detailed description on how to test the service.
Using GNSS raw measurement in high speed motion
If your application requires to use CloudLocate in motion with a speed greater than 40 km/h, to improve the fix rate you are suggested to use the 'Approximate Position' option that allows to indicate a coarse position of the asset with an accuracy of 150 kms. This additional information will greatly improve the estimation result and can be used also at lower speeds.
{
"GNSSMeasurements":{
"Payload":
"tWIChjIAG/M7CcimDqBmvpr+A9pGYVEPdxhiyIqPToNAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAyAA==",
"DateTime": "2023-04-05T12:50:16",
"ApproximatePosition":
{
"Lat": 47.285,
"Lon": 8.565,
"Alt": 549.36
}
}
}
When using the Service to Service access (REST API), you can avoid to use the ApproximatePosition option by using the DeviceId attribute, that allows the service to use the previous estimated position for that device as approximate position.
The DeviceId attribute shall report the unique identifier of your device and can be any alphanumeric string that is meaningful in your device.
{
"DeviceId":"MyDeviceSerialNumber",
"GNSSMeasurements":{
"Payload":
"tWIChjIAG/M7CcimDqBmvpr+A9pGYVEPdxhiyIqPToNAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAyAA==",
"DateTime": "2023-04-05T12:50:16"
}
}
In both cases the approximate position is used as an aiding information to increase the capability of the service to estimate the device position.