Compact raw measurements

Introduction

In several scenarios, transmitting payloads of hundred of bytes is not possible because of constrains imposed by the WAN technology or simply not recommended because the message transmission takes too much time thus draining the battery of constrained device.

In those scenarios you can take advantage of the CloudLocate compact messages option to reduces significantly the size of GNSS raw measurement.

CloudLocate supports three types of compact raw measurement:

  • UBX-RXM-MEAS50 - 50 bytes - supported natively by M10 GNSS and available in M8 and M9 through a conversion library for the host processor

  • UBX-RXM-MEAS20 - 20 bytes - M10 GNSS module/chip is required

  • UBX-RXM-MEAS12 - 2x12 bytes - M10 GNSS module/chip is required

How to use compact raw measurements

u-blox M10 GNSS with FW 5.10 provides natively these three types of raw measurement. So it extremely easy to generate the selected one and send it to CloudLocate service (see Getting started guide)

When using M8, you can use the 50 bytes raw measurement through the conversion library provided jointly to the reference implementation in the Download section; just configure to true the CONVERT_MEASX_T0_MEAS50 parameter in the main script and include the measx_to_meas50 library

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:

  • 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.

  • 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 next section. For more information look at M10 Interface description

  • MEASX (>164 bytes)

    • UBX-RXM-MEASX - Class: 0x02 - Message ID: 0x14

  • 50 bytes raw measurements

    • UBX-RXM-MEAS50 - Class: 0x02 - Message ID: 0x86

  • 20 bytes raw measurement

    • UBX-RXM-MEAS20 - Class: 0x02 - Message ID: 0x84

  • 12 bytes raw measurement

    • First message - UBX-RXM-MEASD12 - Class: 0x02 - Message ID: 0x80

    • Second message - UBX-RXM-MEASC12 - Class: 0x02 - Message ID: 0x82

NOTE: Before sending the UBX-RXM-MEAS* message to the server, the host must remove the UBX frame (8 bytes) from the message leaving just the 12-, 20- or 50-bytes payload. Also checksum shall be removed.

When sending UBX-RXM-MEASX instead, the device shall send also header and checksum

Example of a 50 byte compact measurement

Here below and example of JSON payload in case the measurement is sent to service endpoint as a delayed message

{

"body": "E+NhB5mAVzhHDrA1Asp5ePIZcSuQENasfnpB0Xk3Kh2o1Qa8OASPjQAAAAAAAAAAAAA=",

"headers": {"UTCDateTime": "2021-05-29T12:37:35" }

}

The above compact message would translate to following location:

{

"Lat":47.285222999999995,

"Lon":8.565314899999999,

"Alt":549.3580000000001,

"Acc":15.805,

"MeasTime":"2021-05-29T12:37:35",

"Epochs":1

}

If you can send the raw measurement immediately after that it has been generated by the device, you can still use the JSON format but avoiding to add the "headers" parameter or use the binary format as explained in a following section.

Example of 20 byte compact measurement

Here below and example of JSON payload in case the measurement is sent to service endpoint as a delayed message. As for the previous format, you can decide to use the JSON format or the binary format.

{

"body": "I4Mi80XDVJK5QVlfGXct64C62lc=",

"headers": {"UTCDateTime": "2021-05-29T12:36:56" }

}

And the estimated position is:

{

"Lat": 47.2852189,

"Lon": 8.5653086,

"Alt": 552.164,

"Acc": 31.469,

"MeasTime": "2021-05-29T12:36:56",

"Epochs": 1

}

Example of 12 byte compact measurement

Differently from the previous raw measurement types, when using the 12 byte message, you need to:

  • send 2 measurements, one for doppler and one for code phase. The M10 GNSS provide in output 2 subsequent messages: UBX-RXM-MEASD12 (doppler) and UBX-RXM-MEASC12 (for code phase)

  • use the Service to Service access mode. The API payload shall contain doppler and code phase measurements and the used constellation and shall be formatted as described below


{

"Constellation": "GPS",

"Doppler" : "AuVPRZoYW7MON8pS",

"CodePhase": "bJ9ZdHY8GxDE+kc7"

}

In case you are sending a delayed message, you need to append the date and time information in the header of the API call, as described in the API documentation

Here below a typical response for the estimated position

{

"Lat": 47.2851463,

"Lon": 8.5653601,

"Alt": 563.629,

"Acc": 96.931,

"MeasTime": "2021-05-14T08:05:03",

"Epochs": 1

}

NOTE: when sending also date and time, the information shall be related to the UBX-RXM-MEASC12 frame. If using the reference implementation provided by u-blox you need to run the script twice modifying the message type.

Doppler and code phase measurement should be collected in a time range not bigger than 3-5 minutes.

Using binary format

For high latency networks, it is extremely important to keep small the payload size. Using the JSON format, you could not be able to send the raw measurements to the service because it add extra bytes that makes the payload exceeding the Maximum Transmission Unit allowed by the WAN (Wide Area Network).

In such case it is suggested to use the binary format: it consist in sending the raw measurement, exactly as received by the GNSS without adding any extra information and neither formatting characters. The reference implementation available in the Download section provides an option that allows you to decide whether to send the message in the JSON or in Binary format for all the message type except for the 12 byte format.

Note: when using Binary format you cannot add the Date and Time information, therefore you can send to CloudLocate service only "live" measurements (within 60 seconds form generation). You cannot store the measurement on the device for a post processing. If you are in this use case, the only option is to use JSON format.

Conversion library

To convert a message from MEASX to MEAS50 for M8 GNSS models you can refer to the reference implementation available in the Download section.