Testing GPS Cold Start Performance

[Akash Patel]

Hello,

I want to test cold start performance of GPS on the nRF9160 DK using the gps example from the SDK. If I run the example unmodified from the sdk, get a fix, power cycle the DK, run the example again, and get a fix, will that second fix be considered hot, warm, or cold? My guess is hot because nrf_gnss_delete_mask_t delete_mask is set to 0 in the example. Can someone confirm?

If I change nrf_gnss_delete_mask_t delete_mask to 0xFF will that be enough to cause a cold start or are there other settings that need to be modified?

Another question is what is the purpose of setting nrf_gnss_use_case_t use_case to NRF_GNSS_USE_CASE_SINGLE_COLD_START? What is the meaning of "targeted start performance"?

Regards,

Akash

[Håkon Alseth]

Hi Akash,

 

I want to test cold start performance of GPS on the nRF9160 DK using the gps example from the SDK. If I run the example unmodified from the sdk, get a fix, power cycle the DK, run the example again, and get a fix, will that second fix be considered hot, warm, or cold? My guess is hot because nrf_gnss_delete_mask_t delete_mask is set to 0 in the example. Can someone confirm?

If you use power-cycle as a means of testing cold start, you are not guaranteed to have a cold start every time. If we look at what the _mask_t actually holds:

https://github.com/nrfconnect/sdk-nrfxlib/blob/master/nrf_modem/include/nrf_socket.h#L1244-L1255

Some of these are stored in volatile (RAM) memory, and some, like the almanac, are stored to non-volatile (flash) memory when successfully received.

Without deleting, you are likely getting somewhere between a warm and cold start. 

 

If I change nrf_gnss_delete_mask_t delete_mask to 0xFF will that be enough to cause a cold start or are there other settings that need to be modified?

This shall give you a cold start. 

 

Another question is what is the purpose of setting nrf_gnss_use_case_t use_case to NRF_GNSS_USE_CASE_SINGLE_COLD_START? What is the meaning of "targeted start performance"?

This is a setting towards how your application wants to use the GNSS.

Are you taking several positions when you're using the GNSS? or are you taking only one, then waiting for the next period?

 

Kind regards,

Håkon

[Akash Patel]

Hi Håkon,

Thanks for the information.

Håkon Alseth said:

Are you taking several positions when you're using the GNSS? or are you taking only one, then waiting for the next period?

Right now, I changed the GPS to operate in single shot mode by setting nrf_gnss_fix_interval_t fix_interval = 0. Therefore, the application is just working to acquire a single fix (from a cold start because delete_mask = 0xFF) and then in a while(1) once the fix is achieved. After that, it needs a power cycle or pin reset to start over and try getting another fix.

Should I set nrf_gnss_use_case_t use_case to NRF_GNSS_USE_CASE_SINGLE_COLD_START? What is the default setting of this use_case parameter and what difference will setting it to NRF_GNSS_USE_CASE_SINGLE_COLD_START make?

Regards,

Akash

[Håkon Alseth]

Hi,

 

Akash Patel said:

Should I set nrf_gnss_use_case_t use_case to NRF_GNSS_USE_CASE_SINGLE_COLD_START? What is the default setting of this use_case parameter and what difference will setting it to NRF_GNSS_USE_CASE_SINGLE_COLD_START make?

If that is your use-case then, yes.

This tells the modem that the application will do one position, then the next position is expected to be a cold start (or close to atleast). The ephemerides needs to be refreshed, so does other things like time-of-week etc.

 

Kind regards,

Håkon