Ephemeris health fields

[ljbade]

I ended up having to modify the orbits.json file as I was having problems with the decoding of the health bits. I think this was mainly due to the mix of LNAV and CNAV types in there at the moment. The different ephemeris types tend to have quite different definitions of how they encode the health information.

[gwbres]

@ljbade
the orbits descriptor should be more complex, to fully describe modern navigation frames

[larsnaesbye]

@ljbade Would you like to share the changes in a pull request?

[ljbade]

Sure I can put up the changes I made, there are not pretty but was enough for my immediate need. Shouldn't be too hard to polish it up though.

[gwbres]

Hello @ljbade,

I started working on this issue in this branch.
It will take a little time for this to conclude, feel free to join the effort.

I find the specifications not enough detailed or sometimes unclear. So far, the only straightforward has been Galileo.
For example, I'm having a hardtime relate the pseudo specifications in the RINEX4.pdf and the QZSS specs.

[ljbade]

I agree the RINEX document doesn't always line up clearly with the ICDs. Hopefully I will get some time to check your branch later in the week.

[gwbres]

I agree the RINEX document doesn't always line up clearly with the ICDs. Hopefully I will get some time to check your branch later in the week.

Awesome 👍

Yeah.. it's hard to consider those as real specifications:

bit[17]..[22] I presume represent the 6 bits mentioned in the QZSS specs, dunno what w 3 sf 1 though.

I also don't know how to interpret GPS CNAV1/CNAV2, while GPS LNAV is correctly documented.
I presume one should read 52(LSB)..54(MSB) (typo) and L1, L2, L5 starting from LSB ?

[ljbade]

w 3 sf 1 I believe is trying to say "Word 3 in Subframe 1"

One thing to keep in mind with QZSS is that it tries to be very close to the GPS signal, so many things in the raw data should line up with how to extract them in GPS.

[ljbade]

So here is Word 3 of Subframe 1 of the "LNAV" data for QZSS taken from IS-QZSS-PNT-005 section 4.1.2.3 (pg 46):

Basically they are talking about the "SV HEALTH" 6 bits field.

The next page gives the interpretation of these bits:

[ljbade]

I spent some time working on https://github.com/georust/rinex/pull/150/files

The bitflags approach doesn't work well for the ephemeris types were some of the health values are integers rather then single bit flags. Please change this if there is a better way to do it.

I can look at GLONASS and BDS later once you get the basics ready. The details are spread amongst a few different ICDs unfortunately.

ICDs for BDS - http://en.beidou.gov.cn/SYSTEMS/ICD/
on page 2 the Version 2.1 is best one for the D1 and D2 ephemerides, in version 3.0 they removed references to the B2I signal as it is not on the newest satellite generation
the newer ones for B1C, B2a and B2b cover the various CNAV ephemerides

ICDs for GLONASS - https://glonass-iac.ru/en/documents/
the website the ICD PDFs were hosted on was blocked from all countries that supported Ukraine in the war early last year but you can get an archive of them at http://web.archive.org/web/20220108173540/https://russianspacesystems.ru/bussines/navigation/glonass/interfeysnyy-kontrolnyy-dokument/
the version 5.1 covers the legacy NAV
the CDMA ones cover the CNAV ephemerides

[gwbres]

@ljbade,

the CDMA ones cover the CNAV ephemerides

they keep mentionning a possible Glonass NavMsgType::CDMA message, supposedly in EOP frames

but it's missing in the main Glonass NAV Table ; is that a typo ?

the current NavMsgType enum does not have such a field