CloudLocate mixed mode – u-blox Services

Introduction

CloudLocate provides an incredible benefit by reducing the battery drain in most of the conditions. There can be some edge situations in which the GNSS module cannot converge to a meaningful raw measurement, for example because the configured parameters to collect the raw measurements cannot be met because of very weak signal.

In such challenging conditions it is beneficial for the whole application design (client and server side) to estimate the position in the GNSS and send this information in a compact form over the same CloudLocate interface so that client application and server application do not need to implement any additional logic to adapt to different conditions.

The main advantages of mixed mode is

Simplify client application, without switching context/profile to send data to a different end point
Simplify Server application by receiving the position information always from the same endpoint
Optimize energy budget by always using CloudLocate when possible (most of the time)
Always get a position relying on GNSS local engine in challenging conditions (weak signal)

Prerequisites

Before going through this section, please read:

the CloudLocate Getting started guide
the section Getting real time measurements from GNSS

Procedure overview

To implement the mixed mode you can use the M10 reference implementation available in the Download section that implements the flow explained below through a dedicated fallback option (FALLBACK_RECEIVER_POSITION). The usage of the fallback options is explained in the Getting started guide.

The TIMEOUT parameter in the sample code corresponds to the Tc value reported in the picture. Once expired, the function will not search anymore for the a raw measurement but waits Tx seconds the UBX-NAV-PVT message sent in output by the GNSS that contains the position information. The UBX-NAV-PVT message contains the location and accuracy information; you can find the frame structure in the Receiver protocol specification of M10 (and M8) GNSS.

mixed_mode -image 1.png

To configure the Tx parameter refer to the last configuration option as highlighted below in bold. The number is expressed in seconds and it has to be considered in addition to Tc.

FALLBACK_CONFIG = {

   # this will not use any fallback, and is the default when running this script

   FallbackConfig.FALLBACK_DO_NOT_SEND: True,

   # this will fallback to only match # of satellites (irrespective of CNO value, psuedoRange and multipath index)

   FallbackConfig.FALLBACK_NO_OF_SATELLITIES_ONLY: 4,

   # this will extend the timeout value, so if a match is not found without original time it will add this more seconds

   FallbackConfig.FALLBACK_EXTEND_TIMEOUT: 5,

   # this will use main configuration but override number of epochs set to 1

   FallbackConfig.FALLBACK_EPOCHS: 1,

   # this is number of seconds to wait to get receiver position

   FallbackConfig.FALLBACK_RECEIVER_POSITION: 15

}

Note: If Tx expires without having received a UBX-NAV-PVT message, the code provides in output the following warning message.

No message found while using fallback configuration. Please tweak your desired criteria (or choose a different fallback methodology) to get MEAS message

You can decide to trigger a new search or switch OFF the GNSS because the signal is to weak.

Using assistance data

Optionally, to improve the Time To First Fix during the Tx period, you can rely on the assistance data provided by the Assist Now Offline service that delivers Almanac information to GNSS.

More information about Assist Now service are available in the u-blox web site and in the developer section.

Service response

On server side, your application can detect if the position estimation has been done by the GNSS in the device or by the service using the raw measurement, looking at the LocationSource parameter.

LocationSource parameter is equal to GNSS in the first case, while it is equal to CloudLocate if position is estimated on server side by the service

{

"Lat": 51.6387347,

"Lon": 0.1121669,

"Alt": 105.926,

"Acc": 26.926,

"MeasTime": "2020-08-17T20:18:12",

"LocationSource": "CloudLocate"

}

How to test Mixed mode

If during your testing phase you are in a very good sky visibility condition, you can set the Tc parameter to 1 (second) so that the fallback condition is immediately triggered and Tx to 40 (seconds) so that the GNSS has enough time to estimate a position locally (without using assistance data).

In case you are in challenging signal conditions, we suggest you to set Tc to 10 seconds and Tx to 120 seconds or lower if this is not applicable for your use case.

Position information encoding

When submitting to CloudLocate service the position information estimated in the device you need to comply to the Location Open Data Format, that allows to limit the payload size to maximum 20 bytes for:

Header
WGS84 latitude
WGS84 longitude
WGS84 height
horizontal accuracy

To implement this conversion, you can use the function get_open_location_message(lon, lat, alt, acc) available in the reference implementation for M10 GNSS in the Download section

The UBX-NAV-PVT message is 100 bytes long and therefore it cannot be sent over several types of WAN networks that are limited in regards of max payload size, therefore using the Location Data Open Format you reduce the total payload size to 20 bytes and send only the relevant information.

Note: date and time information to support delayed messages will be released soon.