A-GPS API Documentation incomplete

RE: A-GPS API Documentation incomplete

Håkon Alseth — Wed, 14 Dec 2022 14:19:33 GMT

I can confirm that this is indeed a bug from our side.

Thank you so much for making us aware of it! We will fix this in the next version of the supl library.

Hope you have a wonderful day!

Cheers,

Håkon

RE: A-GPS API Documentation incomplete

Håkon Alseth — Fri, 02 Dec 2022 16:58:27 GMT

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

RE: A-GPS API Documentation incomplete

HFE — Thu, 01 Dec 2022 14:58:55 GMT

[quote userid="2115" url="~/f/nordic-q-a/94274/a-gps-api-documentation-incomplete/398554"]Could this be an endian-issue in the representation in wireshark? If you shift 48 (dec) down 5 LBS, 0x30 >> 5 = 1?[/quote]

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.

RE: A-GPS API Documentation incomplete

Håkon Alseth — Thu, 01 Dec 2022 13:29:08 GMT

Hi,

[quote user="S9HFE"]But what is then on bit0, nothing? And where is SV#32?[/quote]

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

[quote user="S9HFE"][bit length 11, 5 LSB pad bits, 0000 0110 000. .... decimal value 48][/quote]

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

RE: A-GPS API Documentation incomplete

HFE — Wed, 30 Nov 2022 00:36:27 GMT

[quote userid="2115" url="~/f/nordic-q-a/94274/a-gps-api-documentation-incomplete/398015"]SV#1 is bit 1.[/quote]

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

[quote userid="2115" url="~/f/nordic-q-a/94274/a-gps-api-documentation-incomplete/398015"]

Could you point to where this happen?

[/quote]

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

RE: A-GPS API Documentation incomplete

Håkon Alseth — Tue, 29 Nov 2022 08:03:16 GMT

Hi,

[quote user=""]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?[/quote]

No, you will get UTC:

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

[quote user=""]struct nrf_modem_gnss_agps_data_frame:

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

[/quote]

SV#1 is bit 1.

[quote user=""]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?

[/quote]

Could you point to where this happen?

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

Yes.

[quote user=""]Is there a specific order required when feeding the A-GPS data into the receiver?[/quote]

Not that we are aware of.

[quote user=""]For a fast TTFF, is it important to have almanachs or are the ephermis enough?[/quote]

Both is preferred.

Kind regards,

Håkon