Please note that the very first fix after device start-up is a rather different measurement than any of the following consecutive fixes.

[Roman Veselskyi]

Hello,

We’re testing the nRF9160 GNSS performance on our custom PCB and have noticed that, even with A-GPS, the first fix after powering on the device takes significantly longer than subsequent fixes. This is a bit confusing because we’re using the GNSS sample for testing, and it should clear the GPS data during TTFF testing. While reading an article, we came across the following statement:

"Please note that the very first fix after device start-up is a rather different measurement than any of the following consecutive fixes."

Could someone please explain why this first fix behaves differently and is also related to AGPS? 

[Håkon Alseth]

Hi,

 

Roman Veselskyi said:

This issue is critical for our device because we request GPS location infrequently—perhaps only once a month. If the first fix, even with AGPS enabled, does not benefit from faster acquisition (because additional satellite data is still required), then AGPS offers no real advantage. We only need that one fix, so faster subsequent fixes provide no benefit.

If you are acquiring the position approx. once a month, then most of your stored data (ephemerides) from the previous fix is outdated, except the almanac. Please note that the dilution of precision (DOP) is degraded when the almanac ages, but its still usable for up to 90 days.

This means that each "1 month fix" is not a complete cold-start.

 

As you have found, there are still certain parameters stored in RAM after deleting the gnss data, so a full reset/reboot is then a "cleaner" way to test your TTFF.

 

Using AGPS will require a network connection - this will cause a delay in when the GNSS can start.

This is because the LTE and GNSS are shared, and cannot run simultaneously. They can both be enabled, but will be time-multiplexed.

It is then important to ensure that you are in a LTE-wise idle state (eDRX or PSM) when starting GNSS services and measuring your TTFF.

 

Roman Veselskyi said:

Now the question is, may we update this TCXO somehow without launching the GNSS?

Yes, you can append the "delete_mask |= NRF_MODEM_GNSS_DELETE_TCXO_OFFSET;" - but please only use this for development/debugging purposes. Still, a reboot/reset is the best way of simulating a GNSS cold start.

In newer mfw v2.0.1 (nRF91x1 devices), you have an additional mask to reset the filter values as an example:

https://github.com/nrfconnect/sdk-nrfxlib/blob/main/nrf_modem/include/nrf_modem_gnss.h#L921

 

Kind regards,

Håkon

[Roman Veselskyi]

Håkon Alseth thanks for the detailed explanation. 

My question was if we may update the TCXO value without launching the GNSS. For example we update this one each 1 day so it is easier for the GNSS modem to get fix is it possible? 

[Håkon Alseth]

Hi,

 

Sorry for misunderstanding. Time (in most cases atleast) is provided via the LTE network, so this will help in general when using the GNSS. AGPS (and potentially PGPS) will be a better way of refreshing the GNSS data, but this will require downloading the info via nrfcloud.

 

What are the TTFF values that you are seeing?

 

Kind regards,

Håkon