joebre
a78865b555
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>
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/