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

[Håkon Alseth]

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

[HFE]

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

[Håkon Alseth]

Hi,

 

HFE said:

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

My apologies, you are correct. Bit 0 = PRN1, bit 1 = PRN2 etc.

This is the representation as expected received from a supl server, there's some discussions on this on this forum:

https://groups.google.com/g/android-porting/c/GPpMPB53XXU/m/u5DAB9UZ4bYJ

HFE said:

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

Could this be an endian-issue in the representation in wireshark? If you shift 48 (dec) down 5 LBS, 0x30 >> 5 = 1?

 

Kind regards,

Håkon

[HFE]

Håkon Alseth said:

Could this be an endian-issue in the representation in wireshark? If you shift 48 (dec) down 5 LBS, 0x30 >> 5 = 1?

The IOD value is encoded as "iod BIT STRING (SIZE(11))" according to the ASN specification. To get the value 48 you have to decode the bit string correctly. The value 48 is also the IODC value noted in the RINEX files for this SV. Therefore, I believe that the SUPL Client Library may not decode the bitstring correctly.

[Håkon Alseth]

Thank you for the detailed description! I will make an internal bug on this matter and ask the R&D team to look into this.

 

Kind regards,

Håkon