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

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

Parents Reply Children
  • 0 in reply to ibiglari

    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

  • 0 in reply to Einarh

    Hi,

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

    Thanks for your reply,
    Iman

  • 0 in reply to ibiglari

    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.

  • 0 in reply to papatel

    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

  • 0 in reply to ibiglari

    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 Slight smile

    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

Related