application: serial_lte_modem: BUG-FIX GNSS scheduled download

[junqingzou]

Currently GNSS scheduled download is disabled for SLM AGPS/PGPS periodical tracking to save power as AGPS/PGPS data has the info.

There is a need to disable it for SLM GPS periodical tracking as well, due to scheduled download would generate fixes not according to the interval configuration, i.e. fix per second.

From mfw_2.0 the fix by scheduled download will be flagged and the libmodem GNSS could filter the unwanted fix.

[NordicBuilder]

Test specification

CI/Jenkins/NRF

• Integration Platforms

CI/Jenkins/integration

Test Module	File based changes	Manually selected	West overwrite
test-fw-nrfconnect-nrf-iot_serial_lte_modem	X

Detailed information of selected test modules

Note: This message is automatically posted and updated by the CI

[tomi-font]

This is a feature of the periodic navigation mode. From nrf_modem_gnss_fix_interval_set()'s comments:

@note In periodic navigation mode, when GNSS determines it needs to download ephemerides or almanacs from the broadcast, the fix interval and fix retry parameters are temporarily ignored. GNSS will perform scheduled downloads until it has downloaded the data it needs, after which normal operation is resumed.

In my understanding this shouldn't happen often.
Using NRF_MODEM_GNSS_USE_CASE_SCHED_DOWNLOAD_DISABLE may have downsides when not using cloud assistance:

It is also possible to use this option without A-GPS, but it should be noted that in that case GNSS will never get some data (for example ionospheric corrections), which may affect the accuracy.

I don't know whether we really want to do that. Can you provide some more explanation as to why this change should be made, what has been experienced?

Also, I didn't quite understand your last sentence:

From mfw_2.0 the fix by scheduled download will be flagged and the libmodem GNSS could filter the unwanted fix.

[tokangas]

In my understanding this shouldn't happen often. Using NRF_MODEM_GNSS_USE_CASE_SCHED_DOWNLOAD_DISABLE may have downsides when not using cloud assistance:

Downloading all almanacs takes about 13 minutes. GNSS splits this into one minute parts, so in the best case GNSS would be running continuously 13 times 1 minute. In case there are errors, the corresponding pages are retried later. After almanacs have been downloaded, the next download should happen only after a couple of weeks, if I remember correctly.

Additionally, if the interval is less than 30 minutes, GNSS also does scheduled downloads for the ephemerides. Downloading an ephemeris takes something like 16 seconds, I think, but because each satellite is only transmitting it's own ephemeris, GNSS will have to repeat this again when it acquires a new satellite for which it does not yet have an ephemeris.

If scheduled downloads are disabled and GNSS assistance is not used, GNSS will be most likely using less satellites for the fixes and it probably never gets almanacs for the satellites. This impacts fix accuracy.

I don't know whether we really want to do that. Can you provide some more explanation as to why this change should be made, what has been experienced?

The problem is, that if scheduled downloads are not disabled, GNSS does not always respect the given fix interval. The application may for example expect a fix every 60 seconds, but GNSS may suddenly start running continuously for one minute because of the scheduled downloads.

Also, I didn't quite understand your last sentence:

From mfw_2.0 the fix by scheduled download will be flagged and the libmodem GNSS could filter the unwanted fix.

MFW v2.0.0 has a new flag in the GNSS PVT, which indicates if the PVT notification was sent because of a scheduled download. With this flag, the application could ignore those PVTs which are not "real" fixes with the requested interval. The GNSS API implementation in libmodem can also use this flag to determine when it should send the NRF_MODEM_GNSS_EVT_FIX event. Now this event is sent once a second also during scheduled downloads, which may be confusing.

[tomi-font]

The problem is, that if scheduled downloads are not disabled, GNSS does not always respect the given fix interval. The application may for example expect a fix every 60 seconds, but GNSS may suddenly start running continuously for one minute because of the scheduled downloads.

Maybe the choice between time and position accuracy could be given to the user.

Anyway, the GNSS AT commands have been reworked and the PR is ready to get merged, so @junqingzou I think you need to base your changes on it.

MFW v2.0.0 has a new flag in the GNSS PVT, which indicates if the PVT notification was sent because of a scheduled download. With this flag, the application could ignore those PVTs which are not "real" fixes with the requested interval. The GNSS API implementation in libmodem can also use this flag to determine when it should send the NRF_MODEM_GNSS_EVT_FIX event. Now this event is sent once a second also during scheduled downloads, which may be confusing.

This is confusing... Fake fix events are sent or NRF_MODEM_GNSS_EVT_PVT? Why and what data do they contain if actual data is not available?

[tokangas]

This is confusing... Fake fix events are sent or NRF_MODEM_GNSS_EVT_PVT? Why and what data do they contain if actual data is not available?

When GNSS is running because of a scheduled download, NRF_MODEM_GNSS_EVT_PVT events are sent once a second like always when GNSS is running. The flags field tells if the fix is valid or not. If the fix is valid, also the event is sent NRF_MODEM_GNSS_EVT_FIX.

This is confusing, that's why the GNSS periodic mode hasn't been used much. Later, we got the option to disable scheduled downloads. It's the only way to guarantee that GNSS runs only when it's time for the next periodic fix. One thing to consider is that running GNSS continuously for 13 minutes to download the almanacs uses a lot of energy. During a scheduled download, nRF9160 consumes more than 40 mA all the time.

[tomi-font]

This is confusing, that's why the GNSS periodic mode hasn't been used much. Later, we got the option to disable scheduled downloads. It's the only way to guarantee that GNSS runs only when it's time for the next periodic fix. One thing to consider is that running GNSS continuously for 13 minutes to download the almanacs uses a lot of energy. During a scheduled download, nRF9160 consumes more than 40 mA all the time.

Yeah, not ideal. This does not happen at all in continuous navigation mode?

This gets me wondering, how bad is the loss of accuracy. It may be worth the gain of time accuracy and consumption.

What do you think? Does it make sense to always disable the scheduled downloads in periodic navigation mode?

[tokangas]

Yeah, not ideal. This does not happen at all in continuous navigation mode?

In continuous navigation GNSS runs all the time and is continuously decoding data from the satellites, so there's no need for such behavior.

This gets me wondering, how bad is the loss of accuracy. It may be worth the gain of time accuracy and consumption.

Well, that's pretty much impossible to say. Running several tens or hundreds of fixes would give some kind of idea. But then again, results from different signal conditions would probably be different.

There are two different ways the accuracy is affected. One is the number of usable satellites, which is pretty much unpredictable. Another are the Klobuchar ionospheric corrections, which would never be received without scheduled downloads or A-GNSS. The benefit from Klobuchar correction parameters probably isn't that big, though.

What do you think? Does it make sense to always disable the scheduled downloads in periodic navigation mode?

If you want the periodic mode to work logically, there's not much choice. I think it's probably better to always disable scheduled downloads. And A-GNSS usage is always a good idea.

[tomi-font]

Good to me. Changes will have to be re-made if #12359 gets merged before this.

[junqingzou]

Good to me. Changes will have to be re-made if #12359 gets merged before this.

Will wait in pipe.
PS tested OK with SLM+SoftSim (original environment).

[junqingzou]

@tomi-font rebased to #12359
NOTE in that PR you have disabed scheduled download unconditioanlly for A-GPS, P-GPS and A-GPS + P-GPS, and this PR changed it back to periodical mode of GPS, A-GPS, P-GPS, A-GPS + P-GPS only.

[NordicBuilder]

You can find the documentation preview for this PR at this link. It will be updated about 10 minutes after the documentation build succeeds.

Note: This comment is automatically posted by the Documentation Publishing GitHub Action.