CloudLocate mixed mode
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)
Before going through this section, please read:
the CloudLocate Getting started guide
the section Getting real time measurements from GNSS
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.
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.
Note: If Tx expires without having received a UBX-NAV-PVT message, the code provides in output the following warning 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.
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
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:
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.