WIP tweaks #150
WIP tweaks #150
Conversation
rinex/src/bibliography.rs
Outdated
| @@ -39,6 +39,6 @@ pub enum Bibliography { | |||
| /// [DOI](https://cdn.taoglas.com/wp-content/uploads/pdf/Multipath-Analysis-Using-Code-Minus-Carrier-Technique-in-GNSS-Antennas-_WhitePaper_VP__Final-1.pdf). | |||
| MpTaoglas, | |||
| /// QZSS Signal and Constellation interface specifications. | |||
| /// [DOI](https://qzss.go.jp/en/technical/download/pdf/ps-is-qzss/is-qzss-pnt-004.pdf) | |||
| /// [DOI](https://qzss.go.jp/en/technical/download/pdf/ps-is-qzss/is-qzss-pnt-005.pdf) | |||
| QzssPnt, | |||
There was a problem hiding this comment.
I think we might also want to add reference to the Galileo and QZSS ICDs
There was a problem hiding this comment.
Yes definitely, this is work in progress, QZSS was the first dedicated specs I looked into, that's why it's there.
| @@ -1,88 +1,84 @@ | |||
| //! GAL Sv Health specifications | |||
| use bitflags::bitflags; | |||
| //! GAL SV Health specifications | |||
There was a problem hiding this comment.
I changed all Sv to SV as SV is an acronym for Satellite Vehicle
|
|
||
| /// GAL Sv Health indication | ||
| #[derive(Debug, Clone, PartialEq, PartialOrd)] | ||
| /// GAL INAV & FNAV SV Health indication. |
There was a problem hiding this comment.
In RINEX v3 and v4 the Galileo health definition is the same for both INAV and FNAV
Though there is another field "data source" that indicates as well if INAV or FNAV (mainly for v3)
For INAV only bits for E1B and E5b can be set (since E5a not transmitted in INAV).
For FNAV only bits for E5a can be set (since E1B & E5b not transmitted in FNAV).
| INAV(Health), | ||
| /// GAL FNAV Sv Health indication | ||
| FNAV(Health), | ||
| pub struct GALHealth { |
There was a problem hiding this comment.
I changed to a struct (with to/from u32 conversions) as HS is actually a 2 bit integer and not two separate bit flags
| /// GPS CNV2 Sv Health indication | ||
| CNV2(Civilian2Health), | ||
| /// GPS Legacy SV Health indication | ||
| LNAV(LNAVHealth), |
There was a problem hiding this comment.
I think having the names of the structs similar to the enum cases is less confusing
| const L2Healthy = 0x02; | ||
| const L5Healthy = 0x04; | ||
| } | ||
| /// GPS Legacy SV Health indication. |
There was a problem hiding this comment.
Similar to the Galileo struct, I also made this a struct as the lower 5 bits are actually a 5 bit integer
To tell health of just L1 or L2 some complex switch would be needed
| } | ||
| } | ||
|
|
||
| bitflags! { | ||
| /// GPS CNAV-2 Sv Health indication. | ||
| /// See [Bibliography::RINEX4] for more information. | ||
| /// GPS CNAV & CNAV-2 SV Health indication. |
There was a problem hiding this comment.
GPS has same definition of health bits in CNAV and CNAV-2 so I changed this to a single struct used in both enum cases
| const L2Healthy = 0x02; | ||
| const L5Healthy = 0x04; | ||
| pub struct CNAVHealth: u8 { | ||
| /// L1 Signal Health |
There was a problem hiding this comment.
I renamed from L1Healthy to just L1 as Healthy makes it sound like true = healthy when the definition is actually the opposite
| /// L1 Health | ||
| /// `false` = Healthy | ||
| /// `true` = Unhealthy | ||
| const L1 = 0x20; |
There was a problem hiding this comment.
Renamed it to L1 to match QZSS ICD
| const L1C = 0x01 << 18; | ||
| const L1C_B = 0x01 << 17; | ||
|
|
||
| pub struct LNAVHealth: u64 { |
There was a problem hiding this comment.
Changed the bit definitions as the RINEX spec is trying to say that this value is 6 bits long, taken from bit positions 22-17 of the navigation data Word 3 of Subframe 1
| const L5 = 0x01 << 54; | ||
| const L2 = 0x01 << 53; | ||
| const L1 = 0x01 << 52; | ||
| pub struct CNAVHealth: u8 { |
There was a problem hiding this comment.
Changed the bit definitions as the RINEX spec is trying to say that this value is 3 bits long, taken from bit positions 54-52 of the navigation data Message 10
| impl std::fmt::UpperExp for GALHealth { | ||
| fn fmt(&self, f: &mut std::fmt::Formatter) -> std::fmt::Result { | ||
| let value: u32 = u32::from(self); | ||
| write!(f, "{:e}", value as f32) |
There was a problem hiding this comment.
FYI, all the NAV ecosystem implements the UpperExp formatting because that's how we (intend) to format those fields in file production contexts.
I say intend because NAV files production is the most problematic still to this day, while OBS and Meteo RINEX have been completed already.
| /// LNAV data health | ||
| /// `false` = all LNAV data are OK | ||
| /// `true` = some or all LNAV data are bad | ||
| data: bool, |
There was a problem hiding this comment.
| data: bool, | |
| unhealthy: bool, |
easier to grasp ?
|
Ideally, we want to converge to an interface that makes it easy for us to apply a Healthy/UnHealthy And mask ( |
No description provided.