• State Not Answered
  • Replies 6 replies
  • Subscribers 65 subscribers
  • Views 813 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 299128
Options

A-GPS API Documentation incomplete

HFE

Hello,

I've some questions regarding missing or incomplete information in the documentation (https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrfxlib/nrf_modem/doc/api.html#gnss-api):

  • struct nrf_modem_gnss_datetime:
    • Does the date-time provided by the GPS contain leap seconds? How is the relation to UTC, do I have to subtract the leap seconds in order to get UTC?
  • struct nrf_modem_gnss_agps_data_frame:
    • mask-fields: Is SV#1 masked in bit0 or bit1?
  • struct nrf_modem_gnss_agps_data_ephemeris:
    • IODC: Why is the data provided by the SUPL Server shifted by 3 bits by the SUPL Client library? Shouldn't IODC correspond directly to the value from the SUPL Server (or  RINEX file)?
    • health: Bit mapping?
  • struct nrf_modem_gnss_agps_data_almanac:
    • sv_health: Bit mapping?
  • struct nrf_modem_gnss_agps_data_system_time_and_sv_tow:
    • sv_mask: SV#1 is Bit0?
  • struct nrf_modem_gnss_agps_data_tow_element:
    • tlm: From the documentation: "First two bits (MSB) ..." => The "first two bits" are in this case Bit15 (=reserved bit) and Bit14 (=integrity status), right?
  • struct nrf_modem_gnss_agps_data_integrity:
    • integrity_mask: SV#1 is bit0?
    • Can the integrity-mask be assembled from the health information in the ephemeris or almanachs?
  • Is there a specific order required when feeding the A-GPS data into the receiver?
  • For a fast TTFF, is it important to have almanachs or are the ephermis enough?

Thank you in advance.

Best Regards
HFE

Parents
  • 0

    Hi,

    Does the date-time provided by the GPS contain leap seconds? How is the relation to UTC, do I have to subtract the leap seconds in order to get UTC?

    No, you will get UTC:

    https://github.com/nrfconnect/sdk-nrf/blob/main/samples/nrf9160/gnss/src/main.c#L605

     

    struct nrf_modem_gnss_agps_data_frame:
    • mask-fields: Is SV#1 masked in bit0 or bit1?

    SV#1 is bit 1.

    struct nrf_modem_gnss_agps_data_ephemeris:
    • IODC: Why is the data provided by the SUPL Server shifted by 3 bits by the SUPL Client library? Shouldn't IODC correspond directly to the value from the SUPL Server (or  RINEX file)?
    • health: Bit mapping?

    Could you point to where this happen?

     

    tlm: From the documentation: "First two bits (MSB) ..." => The "first two bits" are in this case Bit15 (=reserved bit) and Bit14 (=integrity status), right?

    Yes.

    Is there a specific order required when feeding the A-GPS data into the receiver?

    Not that we are aware of.

    For a fast TTFF, is it important to have almanachs or are the ephermis enough?

    Both is preferred.

     

    Kind regards,

    Håkon

  • 0 in reply to Håkon Alseth
    Håkon Alseth said:
    SV#1 is bit 1.

    But what is then on bit0, nothing? And where is SV#32?

    Håkon Alseth said:

    Could you point to where this happen?

    I've used the SUPL Client Library and monitored the results from the callback. The IODC value which comes from the SUPL Client Library is shifted by 3 bits compared to the IOD value which directly comes from the SUPL Server. For example: SUPL Client Library returned the value 6 for SV#1; but according to Wireshark[1] the value should be 48

    [1]: iod: 0600 [bit length 11, 5 LSB pad bits, 0000 0110 000. .... decimal value 48]

    Kind Regards
    HFE

Reply
  • 0 in reply to Håkon Alseth
    Håkon Alseth said:
    SV#1 is bit 1.

    But what is then on bit0, nothing? And where is SV#32?

    Håkon Alseth said:

    Could you point to where this happen?

    I've used the SUPL Client Library and monitored the results from the callback. The IODC value which comes from the SUPL Client Library is shifted by 3 bits compared to the IOD value which directly comes from the SUPL Server. For example: SUPL Client Library returned the value 6 for SV#1; but according to Wireshark[1] the value should be 48

    [1]: iod: 0600 [bit length 11, 5 LSB pad bits, 0000 0110 000. .... decimal value 48]

    Kind Regards
    HFE

Children
Related