GNSS/GPS TTFF with A-GNSS after upgrade from v2.4 to v2.5

Hi,

we have product which is close to the asset tracker v2 on the v2.4 which works fine. Now to upgrade to v2.5 we made the changes from agps to agnss. Everything works fine, but the unit is seeing nearly no satellites. With all logging on I can see that the A-GNSS data is moved into the modem/gps receiver. Return code is ok.

A-GPS data we get via MQTT, but we split almanac and ephemeris.

Looks like flashing v2.4 firmware, getting a GPS fix and the flashing the v2.5 firmware without powercycle so it looks like we still see some satellites and get a fix. After a powercycle we don't see satellites. So, I guess there is a problem with the A-GPS data, which is still cached after a reset, but not after a power cycle.

Are there other differences that are made here between 2.4 and 2.5? Any ideas how can I debug from here?

Parents
  • Hello, 

    Are you seeing the same issue if using e.g. cellular GNSS sample? Are you using A-GNSS/GPS

    A-GPS data we get via MQTT, but we split almanac and ephemeris.

    I assume that you are not using our nRF Cloud A-GNSS library, could you please elaborate more on how your method works?

    Now to upgrade to v2.5 we made the changes from agps to agnss

    What changes have you done? 

    Kind regards,
    Øyvind

  • Partially we use the nrf Cloud A-GNSS library. The overall structure/code is close to the asset tracker v2 (with roots down to connect v2.3 and ported to v2.4).

    The flow is very similar:

    1. We get a LOCATION_MODULE_EVT_AGNSS_NEEDED event
    2. We encode a agnss request (or two one for almanac one for ephemeris if needed)
    3. We send it to an mqtt topic (AWS iot)
    4. The backend forward this to nRF Cloud rest API
    5. The result is published over mqtt to the device
    6. The agnss handler uses nrf_cloud_agnss_process (nRF Cloud A-GNSS library) to send the data to the modem.
      1. in case the almanac/ephemeris is splitted we call the function twice, once for each reply

    This works with perfectly with v2.4 and it seems to work with v2.5 going through all steps and nrf_cloud_agnss_process returns OK for almanac and ephemeris. Just that with v2.5 the modem has a hard time to find GPS satellites, as if there was no A-GNSS data.

    The changes to v2.5 here are only in changing the names of everything (datastructures, events, apis) from A-GPS to A-GNSS.

    So concrete point I found now is, that there is a new REST endpoint location/agnss and agps is marked deprecated. Is it required to upgrade the backend to use the new endpoint?

    And is there a description of the binary format for the A-GNSS data? Has this changed?

Reply
  • Partially we use the nrf Cloud A-GNSS library. The overall structure/code is close to the asset tracker v2 (with roots down to connect v2.3 and ported to v2.4).

    The flow is very similar:

    1. We get a LOCATION_MODULE_EVT_AGNSS_NEEDED event
    2. We encode a agnss request (or two one for almanac one for ephemeris if needed)
    3. We send it to an mqtt topic (AWS iot)
    4. The backend forward this to nRF Cloud rest API
    5. The result is published over mqtt to the device
    6. The agnss handler uses nrf_cloud_agnss_process (nRF Cloud A-GNSS library) to send the data to the modem.
      1. in case the almanac/ephemeris is splitted we call the function twice, once for each reply

    This works with perfectly with v2.4 and it seems to work with v2.5 going through all steps and nrf_cloud_agnss_process returns OK for almanac and ephemeris. Just that with v2.5 the modem has a hard time to find GPS satellites, as if there was no A-GNSS data.

    The changes to v2.5 here are only in changing the names of everything (datastructures, events, apis) from A-GPS to A-GNSS.

    So concrete point I found now is, that there is a new REST endpoint location/agnss and agps is marked deprecated. Is it required to upgrade the backend to use the new endpoint?

    And is there a description of the binary format for the A-GNSS data? Has this changed?

Children
Related