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>
log_data() read the data-arm Prompt correlator's real/imaginary parts
directly instead of going through map_correlator_to_iq(), unlike
assign_correlators_to_synchro() which already applies that mapping
correctly. For signals whose data and pilot components are true RF
quadrature (Galileo E5a/E5b, GPS L5), d_interchange_iq is true and the
actual data bits live on the imaginary axis of d_Prompt_Data, not the
real one used unconditionally by the dump.
This only affected the tracking .dat/.mat dump used by the Python/MATLAB
plotting utilities (utils/python/dll_pll_veml_plot_sample.py and
utils/matlab equivalents) for signals such as Galileo E5a: the "Prompt
I" / "Bits of the navigation message" plots showed pilot phase-noise
leakage on the wrong axis instead of the actual navigation bits, while
receiver operation itself (telemetry decoding, PVT) was unaffected
since it uses assign_correlators_to_synchro().
Signed-off-by: joebre <joel.brenner@saphyrion.ch>
Add a sample configuration enabling GPS L1 C/A, Galileo E1, GLONASS
L1 C/A, and BeiDou B1I simultaneously through the new native
Bladerf_Signal_Source, following the same single-capture, multi-band
split already used by the existing USRP X300 and HackRF multichannel
templates.
One 56 Msps / 56 MHz wideband capture centered at 1584 MHz (the
maximum bandwidth supported by a bladeRF 2.0 Micro) is split via
SignalSource.RF_channels=3 into three Freq_Xlating_Fir_Filter
sub-bands tapping the same physical stream: BeiDou B1I (1561.098
MHz), GPS L1 C/A + Galileo E1 (co-located at 1575.42 MHz), and
GLONASS L1 C/A (FDMA, centered near 1602 MHz). The frequency plan and
per-system acquisition/tracking parameters are carried over from the
existing USRP X300 four-constellation template.
Verified against a physical bladeRF 2.0 Micro: the receiver
simultaneously acquired and tracked real satellites on all four
systems from a live antenna.
Signed-off-by: Oleksandr Suvorov <cryosay@gmail.com>
Add a Bladerf_Signal_Source that streams RX samples directly from
bladeRF front-ends (bladeRF x40, x115, and bladeRF 2.0 Micro xA4/xA9)
through libbladeRF, instead of going through the generic gr-osmosdr
wrapper. gr-osmosdr's bladerf backend does not expose usable per-stage
gain control on bladeRF2 hardware and has no support for the RX bias
tee used to power an active antenna on the 2.0 Micro.
The new gr::sync_block (bladerf_source) talks to libbladeRF's
synchronous streaming API directly; the adapter (BladerfSignalSource)
follows the existing SignalSourceBase pattern used by the other signal
sources, with valve and dump support wired the same way. Building it
is gated behind -DENABLE_BLADERF=ON, degrades gracefully when
libbladeRF is absent, and requires libbladeRF v2.6.0 or newer,
enforced at configure time.
Verified against a physical bladeRF 2.0 Micro: the receiver opens the
device, streams live samples, and acquires and tracks real GPS
satellites end to end using the new sample configuration file.
Only single-channel (SISO) reception is supported for now; the second
RX channel is not yet exposed.
Signed-off-by: Oleksandr Suvorov <cryosay@gmail.com>
Carles Fernandez