Using C++ 11 threading routines to create a worker thread that can
perform the FFT for acquisition in a non-blocking manner. By default
'blocking' is set to true, which is identical to the previous behaviour
(with the added overhead of an extra thread). When 'blocking' is set to
false, then the main thread does not wait for the worker, thereby
letting the receiver continue even when the FFT thread is working. This
is very useful for using FFT acquisition at higher sampling rates, where
the FFT cannot be performed in real-time.
The aim is to replace the separate pcps_multithread_acquisition_cc.
TODO: implement the same thing for the pcps_acquisition_sc
GNSS-SDR.internal_fs_sps
The old name was misleading, since the units are samples per second and
not Hertz.
Backward compatibility is kept, so this change does not break any
existing configuration.
Change the initialization of max_dwells in pcps acquisition adpaters
due its value is forced to be 1 in gr_block constructor if boolean
"bit_transition_flag" is set to TRUE
Resolves: #24
Rename "shift_resolution_" variable in some Acquisition adapters to
"doppler_max_" according to its meaning and change "ifreq" to "if"
because the value was not properly read. Delete unused variables.
Resolves: #23
message system. Removing the deprecated channel internal queue and its
references. Some tests that are using the old channel queue are disabled
in this version
the post correlation noise floor. If enabled
(.Acquisition_1C.use_CFAR_algorithm=true) as an option in the
acquisition configuration, it allows setting more stable thresholds in
the presence of non-gaussian front-end noise (which is the usual
behavior of front-ends....)
Reduced zero_padding_factor in pcps acquisition
This was 16, I'm processing data at about 16MHz, this oversampling
factor caused memory allocation issues
Previously dump file name was not being read from the configuration
Added fix for non-zero IF in pcps_acquisition_cc
Added linear correlation to pcps acquisition.
Bug fix in galileo tracking
Several improvements in Galileo telemetry decoder.
Code cleaning in observables
Galileo PVT is able to decode Galileo time and get satellite ECEF positions
Galileo PVT soluton is still under development
git-svn-id: https://svn.code.sf.net/p/gnss-sdr/code/trunk@432 64b25241-fba3-4117-9849-534c7e92360d
gps_l1_ca_pcps_multithread_acquisition
gps_l1_ca_pcps_tong_acquisition
galileo_e1_pcps_cccwsr_ambiguous_acquisition
galileo_e1_pcps_tong_ambiguous_acquisition
galileo_e1_pcps_8ms_ambiguous_acquisition
and test for all the algorithms.
git-svn-id: https://svn.code.sf.net/p/gnss-sdr/code/trunk@411 64b25241-fba3-4117-9849-534c7e92360d
- Some channel and acquisition properties are now common for all channels
- You can choose between channel-specific properties or properties common to all
- Updating config file with the new options
git-svn-id: https://svn.code.sf.net/p/gnss-sdr/code/trunk@360 64b25241-fba3-4117-9849-534c7e92360d
1) Galileo E1 Acquisition adapter block added (Gnuradio block modification to use the same block with the 2 systems with 2 adapters)
2) Tests and signal samples for Galileo E1 Acquisition signal block
3) Library for Galileo E1 signal processing
4) Galileo_E1.h with constant variables for this system
git-svn-id: https://svn.code.sf.net/p/gnss-sdr/code/trunk@209 64b25241-fba3-4117-9849-534c7e92360d
Carles Fernandez