nrf9160 modem XFILEWRITE gps almanac

[LordLucan]

Hi,

I see in the nrf9160 1.2.0 AT document there is a command XFILEWRITE that suggests the GPS almanac can be written and persist in the modem.

Can you provide more documentation on this command and the format of the data you can write?

I'd like to improve the TTFF for the GPS. I've got the SUPL GPS client example working and it does indeed speed up TTFF to a few seconds. But I'd like to be able to store that information in the modem in cases where I have no LTE connection or it is simply unavailable for other reasons. That is I want the GPS data to persist. Suggestions welcome!

Regards,

Paul

[Simonr]

Hi Paul

The GPS almanac/ephemeris data is stored into flash "by default". Flash storing of data happens regularly but rather infrequently (every 8 hours), but also on "graceful power-down". So the ephemeris and almanac data sit in RAM until either of the above happens. If the power-down is not graceful (e.g. battery is forcefully removed or upon a crash), the data will be lost.

Almanac is valid for months, so if it has at least once been stored in the not too distant past, it'll still be valid, even if there's a subsequent non-graceful power-down. Ephemerides are renewed every 2 hours regardless of whether it has been stored to flash or not.

If you need to store this data to flash more frequently, I guess you could call the XFILEWRITE AT command in order to do this manually upon, I.E. lost LTE connection or similar.

Best regards,

Simon

[LordLucan]

Hi,

Thanks for this. What do you consider a "graceful power-down" of the modem, can you elaborate please?

How can I tell whether the almanac/ephemeris is out of date or not? ie when was it last updated?

I'm not seeing any evidence at the moment that this data persists. In the GPS sample with SUPL support the data is _always_ fetched. That is the modem sends out a NRF_GNSS_AGPS_DATA_ID request with just about all flags set. If the data is fetched then TTFF is very short, a few secs. If not then it can take about 30s. So clearly the data is not persisting at the moment.

Regards,

Paul

[Simonr]

Hi Paul

A graceful power-down in this context is referring to a graceful power-down of the modem, as specified in the documentation here. If you're powering down the modem by using AT+CFUN=0 the almanac will be stored to flash. 

Best regards,

Simon

[LordLucan]

I'm sorry, but I'm not convinced this is working at all. Either I'm not shutting down the modem correctly or the almanac/ephemeris is not being preserved.

To recap, I've now modified your gps sample to send to the modem AT+CFUN=0 once a fix is obtained. Hoping that the alamanac/ephemeris will be preserved. Now ...

1. If I run your gps sample with SUPL support an LTE connection is made, SUPL data comes down, is written to the modem. The gps then gets a fix within seconds. That's great. Once a fix is obtained I close down the modem by sending AT+CFUN=0. I also wait for a valid OK from the modem. If I then reset the board with LTE turned off, so no SUPL data is fetched, then gps does not get a fix, or if it does it takes many minutes.

2. If I compile out SUPL support, then reflash your app again GPS TTFF is very intermittent if at all. I have to wait somtimes upwards of ten minutes to get a fix. This is after doing 1. I would expect from your description the almanac/ephemeris to persist in flash over a reset and be loaded back again. I've no evidence this is happening.

In summary the only way I can get a fast TTFF is to pull down SUPL data over LTE and write this to the modem. I'm not at all convinced the data is being preserved.

Modem firmware version is 1.2.0. GPS antenna is on open land, not indoors.

Can you please consult your GPS expert on how to preserve the almanac/ephemeris. Also, can I read it back using your socket library to check it?

Regards,

Paul

[LordLucan]

I've also done a bit more work on this trying to discover why gps TTFF is so slow.

What I've noticed with the GPS SUPL sample is that in nrf_scoket.h there are a number of constants NRF_GNSS_AGPS_* that are used to write AGPS data to the modem. Thinking about this a bit more maybe the issue is that from a cold start the GPS modem needs to get either the current UTC time or an approximation of the current location for faster TTFF.

So I've now modified your GPS sample to filter out NRF_GNSS_AGPS_EPHEMERIDES and NRF_AGPS_ALMANAC. If I do this then the GPS locks quickly in a few seconds still. So, I'm thinking that almanac/ephemeris data is persisting but what is required is either position or time to be uploaded to the modem.

So the question is. Can you please document or point me to the details of the data formats for the NRF_GNSS_AGPS_* constants? I'd like to set these myself without having to connect to the supl server.

Just generally, Nordic have done a great job with the nrf9160 but we as customers should not be having to reverse engineer how the GPS works in order to get good performance. This should all be documented somewhere.

Regards,

Paul