This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nrf9160 modem XFILEWRITE gps almanac

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

Parents
  • 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

  • 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

Reply
  • 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

Children
No Data
Related