apply_conf_defaults() picked the plotted signal-type label as
signals[0].signal whenever --first-channel/--channels was passed
explicitly to override the conf-derived channel range. signals[0] is
just the first enabled signal in SIGNAL_ORDER for the given conf, so
it is only correct when the manually requested range happens to start
at channel 0 of that same signal; for any other range it mislabels
every plot with the wrong signal type, even though the correct .dat
files are read (since --file-prefix is typically also given
explicitly in that case).
For example, running
--conf EVK1029_Galileo_E1_E5a.conf --file-prefix trk_GalileoE5a_ch \
--first-channel 10 --channels 10
correctly reads the Galileo E5a tracking dumps but titled every plot
"Galileo E1B", the conf's first enabled signal.
Resolve each requested channel's signal type from the conf's own
per-signal channel ranges (SignalConfig.channels) instead, falling
back to the previous behavior only when no conf is available at all.
Signed-off-by: joebre <joel.brenner@saphyrion.ch>
SIGNAL_ORDER in utils/python/lib/gnss_sdr_conf.py is meant to mirror
signal_mapping in src/core/receiver/gnss_block_factory.cc, which
GetChannels() walks in a fixed order to assign absolute channel IDs
(consuming Channels_<type>.count channels per entry; the per-channel
Channel<N>.signal lines in the conf file are not used for this).
SIGNAL_ORDER was missing "1D" (BeiDou B1C) and "S1" (SBAS L1), both
present in signal_mapping. Any configuration enabling BeiDou B1C or
SBAS alongside other signal types would get every later signal's
inferred channel range shifted, mislabeling tracking dump plots for
those channels. Added both entries, in the same relative position as
signal_mapping, along with their SignalType metadata.
Signed-off-by: joebre <joel.brenner@saphyrion.ch>
For some reason, the old script calculated "mean()" of PRN numbers
in a tracking channel. E.g., channel 1 tracked PRN 3 for few seconds,
then tracked PRN 16 for the rest. The script would add legend PRN 9
(3+16)/2 = .... Fixed that and added "PRN-wise tracking indicator" in
addition to the existing "channel-wise tracking indicator"
Signed-off-by: minhaj <minhaj.sixbyte@gmail.com>
The KF tracking dump reader now follows the parameters dumped by kf_tracking.cc
lib/gps_l1_ca_kf_read_tracking_dump.py:
- Rewrite using the same _RECORD_FORMAT / _FIELD_NAMES architecture as
dll_pll_veml_read_tracking_dump.py: one struct.unpack per record and
EOF handling, dropping the v1..v22 / bytes_shift / seek.
gps_l1_ca_kf_plot_sample.py:
- map innovation -> carr_error; drop r_noise_cov
lib/plotKalman.py, lib/plotTracking.py:
- Skip the "Estimated Noise Variance" panel when r_noise_cov is absent.
- Replace fig.canvas.set_window_title() with
fig.canvas.manager.set_window_title(). The canvas method was deprecated
in matplotlib 3.4 and is gone in current matplotlib (3.6.3 here), where
it raised AttributeError. Ref: https://github.com/raysect/source/issues/383
Signed-off-by: minhaj <minhaj.sixbyte@gmail.com>
two fields (TOW_ms and WN). Probably because this file was written at a time when
these fields were not present in the tracking dump.
This commit fixes that, and plot_tracking_quality_indicator.py is operational now.
This script now also lays out a _RECORD_FORMAT such that it is easily maintainable
if the structure changes again in future in the dll_pll_veml_tracking.cc
Thanks!
Signed-off-by: minhaj <minhaj.sixbyte@gmail.com>
- Added a plot_positive_acq filter option, to enable plotting only the positive
acquisitions.
- Improved the file path processing. Previous version used hardcoded character
offset that will not work if someone sets custom dump prefix. Now we use
python's built-in pathlib and split-parse using the "_" separator.
- The scripts used to use two different ways of encoding system,channel,chips,
one with python dict another with massive if-else nest. This has been uniformed.
- The script used to assume all files in the dump folder would be acquisition dump
but now we filter for acq dumps using pathlib's glob()
Signed-off-by: minhaj <minhaj.sixbyte@gmail.com>
Carles Fernandez