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

[ibiglari]

Hello Patrick,

I have been able to use SUPL Library with Google. I started from the sample code, and copied the relevant parts into Asset Tracker v2.

The reason I was trying to use US Coast Guard GPS information was, I am not a fan of Google.

Cheers,

Iman

[papatel]

Thank you for replying Iman!

We too have SUPL working with supl.google.com but I've found GPS performance to be marginally better than no assistance data at all.  It could be due to the fact that we're not getting almanac data from google anymore but I'm not sure.  Another user noticed this earlier in the year and I commented on their thread.  Our best repeatable TTF results have been with P-GPS with data provided by nrfCloud.  I get 1-3 second fixes with open sky on the 9151 DK consistently.  With A-GNSS, this varies widely, sometimes taking up to 25s with fresh A-GNSS data from nrfCloud.  I'm thinking there is a serious bug there but I don't have the resources to track it down.  I'm curious what your GPS TTF results have been with google's SUPL server if you don't mind sharing

For our testing we always run AT#XGPSDEL=383 and clear the P-GPS partition before each and every GPS fix experiment to guarantee we are comparing apples to apples.

Thank you!

-Patrick

[ibiglari]

My TTF using SUPL with Google is less that 10 seconds outdoors.with Thingy91 and no external antenna

[papatel]

Thank you Iman!  We are testing from India and the Philippines so I wonder if google's SUPL responses are just not well suited for these regions of the world?  Can you confirm you get almanac data in your SUPL responses from google's server?

In any case, we will do more testing if we can't figure out a workable solution with P-GPS and nrfCloud.

[helsing]

Hi Patrick,

papatel said:

With A-GNSS, this varies widely, sometimes taking up to 25s with fresh A-GNSS data from nrfCloud.

There is no reason P-GPS should be better than A-GNSS from nRFCloud. If you are seeing longer TTFF with A-GNSS, then it is something we could check.

papatel said:

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

We do not have any insight why Google SUPL works as it does (ephemerides that are not that fresh and almanac data often missing).

nRFCloud A-GNSS always provides up-to-date ephemerides and almanacs. It also supports assistance for QZSS satellites, which may be helpful depending on the region. nRFCloud also provides NeQuick ionospheric corrections, which can be used for more accurate iono corrections by the device. (You might also have seen the nRF Cloud and SUPL library comparison.)

If you have problems with nRFCloud A-GNSS, then that's something that we can have a look at.

[papatel]

Thank you Helsing for the response.  Totally agree on the issues with google SUPL.  We have done enough testing to conclude that this is absolutely not viable as is.  Nor should we expect it to as Google has zero incentive to make this server good for our use case.

Our data definitely contradicts your statements regarding A-GPS and P-GPS.

I would ask that your engineering team run their own experiments with the latest modem firmware and unmodified SLM on 91x1.  In addition to mediocre A-GPS TTF, we often see a strange bug where the GPS engine will Never get a fix even with a full view of the sky when A-GPS data is injected.  This is extremely disturbing so we moved to de-feature A-GNSS entirely.  Please tell us what we are doing wrong because we are following the guides exactly and running top of tree radio and slm firmware on unmodified 91x1 dev kits...