• State Verified Answer
  • Replies 3 replies
  • Subscribers 74 subscribers
  • Views 727 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 313146
Options

A-GPS almanac request

JordanYates

What are the conditions under which the `sv_mask_alm` field in `struct nrf_modem_gnss_agps_data_frame` will stop being 0xFFFFFFFF?

I am providing almanac data for SV's 2-32 (generated from nRF Cloud today) by writing with `NRF_MODEM_GNSS_AGPS_ALMANAC`.

The modem is continuously getting a good location fix (<5 meters) within 10 seconds after restarting, implying that it has a good idea of current time, almanacs and ephemeris.

However each time the modem restarts, the `sv_mask_alm` field is still set to 0xFFFFFFFF.

Printing out the almanac expiry times for each SV from `nrf_modem_gnss_agps_expiry_get` confirms that the modem thinks the almanac data is valid for the next 2 weeks.

[00:16:49.185,699] <inf> act_gnss: Fix started
[00:16:49.185,699] <inf> act_gnss: Providing almanac assistance ffffffff
[00:16:49.265,625] <inf> act_gnss: Providing time assistance (1376279646)
[00:16:49.266,143] <inf> act_gnss: Providing location assistance (APP)
[00:16:49.269,561] <wrn> act_gnss: EXP: 00000023 7200 0
[00:16:49.269,561] <wrn> act_gnss: A EXP: 144162 1353761 1353761 1353761
[00:16:49.269,592] <wrn> act_gnss: A EXP: 1353761 1353761 1353761 1353761
[00:16:49.269,592] <wrn> act_gnss: A EXP: 1353761 1353761 1353761 1353761
[00:16:49.269,622] <wrn> act_gnss: A EXP: 1353761 1353761 1353761 1353761
[00:16:49.269,622] <wrn> act_gnss: A EXP: 1353761 1353761 1353761 1353761
[00:16:49.269,622] <wrn> act_gnss: A EXP: 1353761 1353761 1353761 1353761
[00:16:49.269,653] <wrn> act_gnss: A EXP: 1353761 1353761 1353761 1353761
[00:16:49.269,653] <wrn> act_gnss: A EXP: 1353761 1353761 1353761 1353761

After a large number of runs, eventually the bits will be cleared to 0, but there is no reasoning that I can detect as to why this occurs.

I am looking to get a better understanding of these flags, in case there are further improvements I can make to my assistance data.

Parents
  • +1

    Hi, 

    There are two ways to query assistance data need from GNSS. nrf_modem_gnss_agps_expiry_get() can be called anytime and will report expiration times in seconds for all A-GPS data.

    Another way is to wait for an NRF_MODEM_GNSS_EVT_AGPS_REQ event and then read the data need using function nrf_modem_gnss_read() and type NRF_MODEM_GNSS_DATA_AGPS_REQ. As the documentation says, the event is sent when GNSS needs new assistance data. This can happen at most once an hour and the data is only updated when the event is sent. If nrf_modem_gnss_read() is called again before the new NRF_MODEM_GNSS_EVT_AGPS_REQ event is received, it will just return the same same as before.

    So, if you want to check the A-GPS data need before GNSS asks for new data, you must use nrf_modem_gnss_agps_expiry_get().

    Regards,
    Amanda H.

Reply
  • +1

    Hi, 

    There are two ways to query assistance data need from GNSS. nrf_modem_gnss_agps_expiry_get() can be called anytime and will report expiration times in seconds for all A-GPS data.

    Another way is to wait for an NRF_MODEM_GNSS_EVT_AGPS_REQ event and then read the data need using function nrf_modem_gnss_read() and type NRF_MODEM_GNSS_DATA_AGPS_REQ. As the documentation says, the event is sent when GNSS needs new assistance data. This can happen at most once an hour and the data is only updated when the event is sent. If nrf_modem_gnss_read() is called again before the new NRF_MODEM_GNSS_EVT_AGPS_REQ event is received, it will just return the same same as before.

    So, if you want to check the A-GPS data need before GNSS asks for new data, you must use nrf_modem_gnss_agps_expiry_get().

    Regards,
    Amanda H.

Children
  • 0 in reply to Amanda Hsieh

    > This can happen at most once an hour and the data is only updated when the event is sent.

    Great, this is the information I was looking for and explains the behaviour I was seeing. I was expecting that additional calls would take into account provided information, not cache old state.

    As a side note, it is kind of annoying that `nrf_modem_gnss_agps_expiry_get` returns expiry in seconds, and that the value is 0 until the time is known. This means that while "can be called anytime" is technically true, in practice it can only usefully be called once the modem has the time. A function that returns absolute expiry time would be more useful to me personally (and would be trivially convertible to a relative time if desired).

    Thanks for your help.

Related
Terms of service