nrf_modem_gnss_agps_data_almanac Field Mapping to YUMA Almanac

[ibiglari]

Hi,

I am downloading GPS Almanacs from U.S. Coast Guard Navigation Center web site to inject into the modem using nrf_modem_gnss_agps_write(). Below is current almanac for one satellite:

******** Week 197 almanac for PRN-01 ********
ID:                         01
Health:                     000
Eccentricity:               0.1223945618E-001
Time of Applicability(s):  589824.0000
Orbital Inclination(rad):   0.9890724625
Rate of Right Ascen(r/s):  -0.8114623721E-008
SQRT(A)  (m 1/2):           5153.605957
Right Ascen at Week(rad):  -0.1638998176E+001
Argument of Perigee(rad):   0.938111269
Mean Anom(rad):            -0.1604865606E+001
Af0(s):                     0.2212524414E-003
Af1(s/s):                  -0.3637978807E-011
week:                        197

I cannot map ioda member of nrf_modem_gnss_agps_data_almanac struct to any field in the YUMA (or SEM AL3).

Below is the mapping I have worked out:

nrf_modem_gnss_agps_data_almanac Member	YUMA Field
sv_id	ID
wn	week
toa	Time of Applicability
ioda	???
e	Eccentricity
delta_i	Orbital Inclination
omega_dot	Rate of Right Ascen
sv_health	Health
sqrt_a	SQRT(A)
omega0	Right Ascen at Week
w	Argument of Perigee
m0	Mean Anom
af0	Af0
af1	Af1

I understand that nrf_modem_gnss_agps_data_almanac expects certain values to be in semi-circle and not radians, and am using YUMA format just as a sample, due to it being easier on the eyes compared to SEM AL3.

Could you please advise what is ioda exactly, and how can it be calculated / deducted from GPS Almanac information?

Kind Regards,
Iman

[Einarh]

Hello

ioda stands for Issue of Data, Almanac, and should represent some sort of timestamp from what I understand.

Hope this clears things up.

Best regards,

Einar

[ibiglari]

Hi,

I figured that much out, but since it's not part of the almanac data published by U.S. Coast Guard, I thought it might have a custom implementation in the modem library or GPS hardware. Is this the case?

Kind Regards,
Iman

[Einarh]

Hi, sorry for the late response.

Have you made any progress on this?

From what I understand, the ioda value is used to differentiate data from different batches, for example received from different satellites.

Also note that the ioda value only contains two bits, so it can only take values 0, 1, 2 or 3.

If you're injecting almanac data manually, you should be able to set the ioda value as you see fit.

-Einar

[ibiglari]

Hi,

I had realised iota doesn't affect the data while testing. Now I know why

Thanks for your reply,
Iman

[papatel]

Hello Iman,

DId you ever write anything usable to automate injecting fresh almanac data from the coast guard website?  If so, did you do the same for ephemeris data?

We implemented the SUPL library but to our disappointment there is no usable SUPL server out there.  The only one we found is supl.google.com and no matter what we do, we can't get that service to return us almanac data consistently.  Google is not going to support our use case...

Any guidance you can provide would be really helpful.  Recent posts on this topic from Nordic's team haven't been helpful at all, especially when it comes to SUPL and A-GPS outside of nrfCloud (which we do not want to use).

Thank you!

-Patrick.