Extend the QZSS L1 C/A LNAV treatment to the L5 CNAV chain: the QZSS-
configured L5 telemetry decoder now publishes dedicated Qzss_CNAV_Iono
and Qzss_CNAV_Utc_Model objects instead of the shared GPS CNAV types,
and PVT keeps them in their own Rtklib_Solver members.
- RINEX 4.02 navigation files get "> STO J CNVX" QZUT records with the
UTC(NICT) identifier and "> ION J CNVX WIDE" Klobuchar records. The
WIDE subtype, compulsory for the QZSS CNVX ION message type, is
correct because CNAV Message Type 30 broadcasts the Wide Area
coefficient set (IS-QZSS-PNT-006; the Japan area set of Message Type
61 is not decoded).
- QZSS CNAV parameters no longer overwrite the GPS CNAV ones in mixed
configurations.
- The QZSS slots of the RTKLIB navigation structure take the LNAV
values with CNAV as fallback, and QZSS-only configurations keep
feeding the broadcast ionospheric model and the leap second count.
- The XML storage output gains qzss_cnav_utc_model.xml and
qzss_cnav_iono.xml.
The Klobuchar coefficients and the UTC(NICT) offset broadcast by QZSS
satellites in LNAV subframe 4 (both the wide-area and Japan-area pages)
were stored in the shared GPS structures, overwriting the GPS-sourced
values in mixed GPS + QZSS configurations and making it impossible to
label them correctly in RINEX output.
New Qzss_Utc_Model and Qzss_Iono storage classes are now published by
the QZSS-configured L1 C/A telemetry decoder and kept in dedicated
Rtklib_Solver members. With this in place:
- RINEX 4.02 navigation files get "> STO J LNAV" QZUT records with the
UTC(NICT) identifier and "> ION J LNAV" Klobuchar records, and the
LEAP SECONDS header is updated from QZSS data in QZSS-only setups.
- QZSS-sourced parameters are no longer mislabeled as GPS corrections
(GPUT / GPS ION or TIME SYSTEM CORR / IONOSPHERIC CORR lines).
- The QZSS slots of the RTKLIB navigation structure (utc_qzs, ion_qzs)
are now populated; QZSS-only configurations keep feeding the broadcast
ionospheric model and the leap second count as before.
- The XML storage output gains qzss_utc_model.xml and qzss_iono.xml.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Activated by setting PVT.rinex_version=4 in the configuration file (or
with the -RINEX_version=4.02 command-line flag). The default behavior
when the parameter is not set remains unchanged (RINEX 3.02).
Observation files are generated in the 4.02 version format. Navigation
files use the data record structure introduced in RINEX 4.00:
- EPH ephemeris records preceded by "> EPH <sat> <msg-type>" header
lines: GPS/QZSS LNAV, GPS/QZSS CNAV (with its own record layout, Table
A10), Galileo INAV/FNAV, GLONASS FDMA (including the new BROADCAST
ORBIT - 4 line with status flags, group delay, URAI and health flags),
and BeiDou D1/D2.
- Ionospheric corrections logged as ION data records (Klobuchar for GPS
and BeiDou, NeQuick-G for Galileo) and time system corrections logged
as STO records (GPUT, GAUT, GAGP, GLUT, GLGP, BDUT) instead of header
lines, written as soon as the corresponding data are received.
- The compulsory LEAP SECONDS header record, written blank if the data
are not available yet and updated in place afterwards.
- Navigation data records use the recommended 'e' exponent indicator
instead of the deprecated FORTRAN 'D' notation.
Also fix update_obs_header() so that the end-of-file position is
preserved after rewriting the header, preventing the destructor from
mistaking an updated observation file for an empty one and deleting it.
ion_cmp[5] and ion_cmp[6] were both set to beta0 instead of beta1 and beta2. Currently harmless since ion_cmp has no readers yet, but the stored parameters were wrong. Spotted by @OuWenhao16 in #1039.
Validate GPS and QZSS ephemeris map keys and PRNs when loading XML assistance. Restore QZSS system and satellite block metadata after deserialization, and load LNAV assistance for QZSS-only configurations. Guard RINEX generation against malformed records and missing satellite block metadata to prevent exceptions in the PVT worker.
Carles Fernandez