nrf9160 modem XFILEWRITE gps almanac

RE: nrf9160 modem XFILEWRITE gps almanac

Simonr — Thu, 09 Dec 2021 12:52:46 GMT

For anyone looking around for something similar to this feature, here's the pull request implementing support for minimal GNSS assistance consisting of factory almanac, time (from LTE network), and rough location based on MCC.

Best regards,

Simon

RE: nrf9160 modem XFILEWRITE gps almanac

Simonr — Wed, 10 Feb 2021 08:41:15 GMT

Hi again

Okay, thank you for clarifying. If you populate the following struct here and include it in your application, that shoud let you get time to the GPS module as you describe it. We don't have an example project doing this as you describe it yet, so it will have to be added manually I'm afraid.

Best regards,

Simon

RE: nrf9160 modem XFILEWRITE gps almanac

LordLucan — Tue, 09 Feb 2021 09:11:00 GMT

Thanks for prompt reply. I should have been clearer with the question.The original thread was to do with TTFF for the GPS. Let us suppose I have the current time by sme means. I need to get this current time into the nrf9160 GPS module _without_ doing a complete AGPS SUPL session. How do I get the time into the GPS module to achieve faster TTFF ?

Regards,

Paul

RE: nrf9160 modem XFILEWRITE gps almanac

Simonr — Tue, 09 Feb 2021 08:36:11 GMT

Hi You can get time from the LTE by subscribing to time notifications using the %XTIME AT command. Alternatively, you can get the time (somewhat slower) from the GPS as well.

Best regards,

Simon

RE: nrf9160 modem XFILEWRITE gps almanac

LordLucan — Mon, 08 Feb 2021 11:48:46 GMT

I'm just returning to this thread after a while. As suggested I'd like to get the current time into the GPS on startup. What is the recommended way of doing this?

Regards,

Paul

RE: nrf9160 modem XFILEWRITE gps almanac

Simonr — Thu, 02 Jul 2020 11:40:07 GMT

Hi Paul

The reason you might not have seen it work initially is that the device needs to fetch the almanac initially. This takes ~12.5 minutes of continuous GPS reception if it's fetched from a satellite. It can also be fetched by AGPS, which I guess you have done in your latest reply.

In order to utilize the almanac/ephemeris to speed up TTFF optimally, coarse time and place are needed as well. The device will have both if it made a successful fix recently (less than 30 minutes ago). The coarse place is also stored in Flash at a graceful power-down. However, time can not be stored, so at power-up, you'll need to get the coarse time from somewhere, either LTE or an external source, and inject it to GPS to speed up TTFF.

As for the constants you're referring to, it should not be a problem on the GPS side of things to inject this from the application. Question is, where would you like to get these from, and how. All of them can for example come from AGPS, but if you don't want to use SUPL or MQTT, I suppose you'll have to get it from a PC. The almanac can be injected with some AT command, and time can be fetched from the LTE modem with an AT command and then injected.

Please note that we're entering the summer vacation period here in Norway, so delays must be expected as we are low on staff for the month of July. Sorry about the inconvenience!

Best regards,

Simon

RE: nrf9160 modem XFILEWRITE gps almanac

LordLucan — Wed, 01 Jul 2020 13:10:20 GMT

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

RE: nrf9160 modem XFILEWRITE gps almanac

LordLucan — Wed, 01 Jul 2020 10:55:17 GMT

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

RE: nrf9160 modem XFILEWRITE gps almanac

Simonr — Wed, 24 Jun 2020 07:54:33 GMT

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

RE: nrf9160 modem XFILEWRITE gps almanac

LordLucan — Tue, 23 Jun 2020 09:44:30 GMT

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

RE: nrf9160 modem XFILEWRITE gps almanac

Simonr — Tue, 23 Jun 2020 08:59:27 GMT

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