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? 

[Edvin]

Hello,

I believe this would be as expected. Even though you have A-GPS, you still need to download the Almanac from the network. So you need to connect to the cellular network, download the Almanac, and then use this to get a fix (which would be quicker than doing a cold start of the GPS). But when you have your first fix, the GPS data is already present on the nRF91, and it is more accurate than the Almanac data that you would download (I think). So 1: You don't need to download the data, and 2: it is more accurate. Therefore the consecutive fixes will be quicker.

Please note that we are short staffed due to public Holiday in Norway. Please expect some delay in our answers for the next week. We will be almost full staffed from Tuesday next week.

Best regards,

Edvin

[Roman Veselskyi]

Hello,

Thank you for your response, but with all due respect, your explanation unclears for me. Using phrases like “I believe” or “I think” can create concern that even the chip manufacturer's support team is unsure about how the device works.

Have you checked the GNSS sample in TTFF (Time to First Fix) testing mode? The usual approach is for the firmware to delete all GPS data for each test, then search for satellites from a cold start. You can enable AGPS or run it without AGPS (assisted or unassisted GNSS).

When we delete the GPS data, we expect each fix to require roughly the same amount of time. However, we see the first fix taking longer. This raises the question: is the sample not actually deleting all GNSS data, or is there something else at play?

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.

[Edvin]

Hello,

I discussed this with a colleague now, and even though you delete the GPS data, parts of this is still stored in RAM. You need to reset the nRF after deleting the GPS data to make the TTFF consistent. 

It is mentioned in the ncs\nrf\samples\cellular\gnss sample's readme that you should:

"1. Connect your nRF91 Series DK to the PC using a USB cable and power on or reset your nRF91 Series DK."

If I understand your claim correctly, you are saying that it takes longer the first time you get the fix than the consecutive ones (after deleting the GPS data). Try deleting it, and then reset the application, and you should see that the time is more consistent.

Best regards,

Edvin

[Roman Veselskyi]

Hi Edvin,

Thanks for your support. I believe your college give a bit more precise answer in another ticket we create but that one is private. 

The GNSS sample does not delete the learned TCXO offset from the device memory. 
If the device is new and has never been running for more than a day or the modem 
has never been shutdown with AT+CFUN=0, it is possible that the correct TCXO offset 
is not saved on the flash. In this case what could possibly happen is that the device 
starts off with the factory calibrated TCXO offset (may differ quite a lot from the 
current actual offset) and the satellite search takes more time than usual. 
After the first fix, new TCXO offset is resolved, but it is not written to flash at 
this point yet. It remains in RAM (until the device is rebooted), however, and will 
make subsequent fixes faster.

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

[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