Serial LTE Modem: When and how is downloaded P-GPS data used? AT#XPGPS vs. AT#XGPS command

Hi there!

BACKGROUND: The (preliminary) plan is to use the nRF9160 with the Serial LTE Modem app as a support peripheral for LTE and GNSS in a proprietary asset tracking product. It will use another method of communication and tracking most of the time but sometimes it will need to fall back to LTE and GNSS. Battery life is of the utmost importance.

I have been tasked to measure and predict the power consumption of getting regular GNSS fixes versus downloading 84k of P-GPS data and using that to get faster GNSS fixes over a period of a week.

I am monitoring log output over Segger RTT to get more insight and have set CONFIG_SLM_LOG_LEVEL_DBG=y and CONFIG_NRF_CLOUD_LOG_LEVEL_DBG=y.

Is it possible to download a week's worth of P-GPS data using AT#XPGPS and then using AT#XGPS to get a faster GNSS fix using the P-GPS data? How would I observe in the log output that it is using the P-GPS data to get a faster fix?

The reason I'm asking is that nRF Cloud support must be enabled (AT#XNRFCLOUD=1) for the AT#XPGPS command and this means that I have no control over LTE comms which could be a big drain on the battery if not properly managed.

I have observed a case where the P-GPS download failed at 85% but it still proceeded to provide P-GPS fixes. Will it use the available data? When will it attempt another download? Here is the log:

thingy91_2023-01-17_pgps_download_failed.log

Thanks in advance,

Pieter

  • Hi, and sorry for the late reply.

    How would I observe in the log output that it is using the P-GPS data to get a faster fix?

    Set CONFIG_NRF_CLOUD_GPS_LOG_LEVEL_DBG=y

    Is it possible to download a week's worth of P-GPS data using AT#XPGPS and then using AT#XGPS to get a faster GNSS fix using the P-GPS data?

    Looking at the code, I believe you should use AT#XPGPS every time, and it will download data if necessary, or used the stored data if available.

    However, I might be wrong here, so it is worth checking out.

    Best regards,

    Didrik

Related