nRF9160 GNSS solution retention

[sjacobsen]

From the gnss_extension.rst documentation shown below, it appears as thought the GNSS receiver can retain solution information from previous fixes/tracking in order to speed up the acquisition of new fixes (warm/hot).   Can you please confirm:

1) RTC maintained as long as Vdd1/Vdd2 is present on module

2) Does GNSS receiver maintain its own RTC or share with M33?

3) Solution information is stored in non-volatile, as indicated below, and will survive disruptions to Vdd1/Vdd2?

Thanks!

Starting the GPS
****************

After the GNSS socket is created, the GPS module must be started for the module to start generating GPS fixes.
This is done using the :c:func:`nrf_setsockopt` function with the ``NRF_SOL_GNSS`` socket option level and the :c:type:`NRF_SO_GNSS_START` socket option.

.. code-block:: c

   nrf_gnss_delete_mask_t  delete_mask  = 0;

   nrf_setsockopt(gnss_fd, NRF_SOL_GNSS, NRF_SO_GNSS_START, &delete_mask, sizeof(delete_mask));



During a session (when the GPS is running), the socket stores the information to the non-volatile memory.
This is done to generate a quick fix in a subsequent session and is termed as a hot or warm start (depending on the data that is used from the last session).
Such session data can be deleted using the delete mask that is supplied to the :c:func:`nrf_setsockopt` function call while starting the GPS module.
A value of zero in the delete mask is an indication to keep all the previous data.
The bit masks for the different types of data that can be deleted is defined in the GNSS socket API documentation of :c:type:`nrf_gnss_delete_mask_t`.

Stopping the GPS
****************

The GPS module can be stopped through the GNSS socket by using the :c:type:`NRF_SO_GNSS_STOP` socket option. 
A delete mask must also be supplied when stopping the GPS module as shown in the following code:

.. code-block:: c

   nrf_gnss_delete_mask_t  delete_mask  = 0;

   nrf_setsockopt(gnss_fd, NRF_SOL_GNSS, NRF_SO_GNSS_STOP, &delete_mask, sizeof(delete_mask));

[Håkon Alseth]

Hi,

 

1) RTC maintained as long as Vdd1/Vdd2 is present on module

As long as the modem is active, the time is kept. If you turn off the modem, you will also stop any running clocks.

2) Does GNSS receiver maintain its own RTC or share with M33?

The modem and application is separated. They do not share any specific peripherals, but clock sources do source both the modem and the application. 

 

3) Solution information is stored in non-volatile, as indicated below, and will survive disruptions to Vdd1/Vdd2?

 As long as you have gotten to the point of successfully downloaded the ephemerides, almanac, etc; it should be stored and loaded after a reset, provided that the delete_mask bits isn't populated:

 *          - Bit 0 denotes ephemerides data.
 *          - Bit 1 denotes almanac data (excluding leap second and ionospheric correction parameters).
 *          - Bit 2 denotes ionospheric correction parameters data.
 *          - Bit 3 denotes last good fix (the last position) data.
 *          - Bit 4 denotes GPS time-of-week (TOW) data.
 *          - Bit 5 denotes GPS week number data.
 *          - Bit 6 denotes leap second (UTC parameters) data.
 *          - Bit 7 denotes local clock (TCXO) frequency offset data.

 

Kind regards,

Håkon