GPS L5 is pre-operational, and the L5 health bit of CNAV message type 10 (IS-GPS-200N 30.3.3.1.1.2) is broadcast as "unhealthy" on every SV. As a result, every GPS L5 signal was reported with healthy = false in the monitor_pvt tracked_satellites list, and "not used for navigation" was printed for every GPS satellite. Neither affected the PVT solution: CNAV L2C/L5/J5 observables are not gated on these bits (the L5 exclusion was dropped in v0.0.17), and the CNAV ephemeris handed to RTKLIB carries no svh. GPS L5 now reports the LNAV SV health of the same satellite; GPS L2C and QZSS L5 keep the CNAV bits; and the console message is replaced by a LOG(INFO) line.
TrackedSatelliteInfo.used only says whether a tracked satellite/signal
contributed to the fix, not why it didn't -- below PVT.elevation_mask,
RAIM FDE, and broadcast-unhealthy are all indistinguishable to a monitor
client. Add a `healthy` field (proto field 8, default true) alongside it.
GPS health comes from the decoded ephemeris's SV_health, falling back to
the almanac (broadcast by every satellite) when no ephemeris has been
decoded yet. Galileo health is resolved per-signal via the existing
get_galileo_signal_health(), with the same almanac fallback when no
ephemeris is available for that signal's service. Other systems default
to healthy=true.
A field named "used" inside a message called UsedSatellite read
oddly, especially since the message reports every tracked satellite
(used or excluded), not only used ones. Renamed the message and its
repeated field (tracked_satellites), plus the matching C++/protobuf
serialization types (Monitor_Pvt::TrackedSatelliteInfo,
tracked_satellites), so "used" now reads sensibly as a per-satellite
flag on a TrackedSatellite rather than inside a UsedSatellite.
rescode() (rtklib_pntpos.cc) computes each satellite's azimuth/elevation via
satazel() before checking it against PVT.elevation_mask, and pntpos() copies
that azel into ssat[] unconditionally -- only ssat[].vs is gated by the mask
(the same applies to a satellite dropped by RAIM FDE). The used_satellites
loop in rtklib_solver.cc was keying its entire per-satellite entry on vs, so
a tracked satellite excluded from the fix (below the elevation mask, or by
RAIM) disappeared from MonitorPvt entirely -- indistinguishable from a
genuine tracking problem.
Key entries on whether azel was actually computed this epoch instead, and
add a separate `used` flag (default true) reflecting vs. A satellite that
is tracked but excluded from the fix now still reports its real az/el, with
used = false.
An application monitoring gnss-sdr (e.g. for a sky plot or a per-satellite
status view) typically needs to know which satellites and signals actually
contributed to the current PVT solution, and their azimuth/elevation --
none of that is currently exposed on the MonitorPvt UDP interface, only the
scalar solution.
Adds a repeated UsedSatellite field to MonitorPvt (proto field 37), one
entry per satellite/signal used in the fix: PRN, constellation, signal ID,
azimuth, elevation, and whether that satellite's signals were combined
(e.g. Galileo E1+E5a iono-free). Signals are kept as separate entries
rather than merged into one per-satellite record, since a receiver may
track more than one signal of the same satellite independently and a
consumer may care which ones specifically contributed.
Populated in Rtklib_Solver::get_PVT() from RTKLIB's per-satellite azel
solution (pvt_ssat[]) intersected with the observables actually used in
that epoch.
Signed-off-by: joebre <joel.brenner@saphyrion.ch>
Carles Fernandez