joebre
7c8dfbbb79
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.
Custom structured data format definitions
Files in this folder describe structured data formats that are generated by GNSS-SDR. They use Protocol Buffers' proto3 syntax.
From those files, the protocol buffer compiler creates classes that implement automatic encoding and parsing of the protocol buffer data with an efficient binary format. The generated classes provide getters and setters for the fields that make up a protocol buffer and take care of the details of reading and writing it as a unit. Importantly, the protocol buffer format supports the idea of extending the format over time in such a way that the code can still read data encoded with the old format.
Just grab these files if you are developing a client application for GNSS-SDR.
You are free to use C++, Java, Python, C#, Dart, Go or Ruby, among other
languages. A tutorial to create a simple application using Protocol Buffers and
a .proto file in C++ is available at
https://gnss-sdr.org/docs/tutorials/monitoring-software-receiver-internal-status/