This PR adds basic adaptive gain support, which adjusts SDR gain on the fly based on the noise & signal levels seen.
There are two control mechanisms:
Dynamic range control is enabled by the --adaptive-range option. This adjusts SDR gain to try to achieve a minimum dynamic range, regardless of the exact hardware in the RF path.
Burst (loud message) control is enabled by the --adaptive-burst option. This decreases SDR gain when undecodable loud messages are heard, allowing for better reception of nearby aircraft at the expense of range.
This is only the basic implementation - see the PR for remaining work to do.
Give up and exit after 30 seconds of no sample data, rather than just warning and continuing.
background & discussion: https://discussions.flightaware.com/t/cpu-hikes-crash-dump1090-fa/74759
The scenario this addresses is:
* Hardware wedges, USB bulk endpoint stops providing data
* librtlsdr remains in rtlsdr_read_async() waiting for either USB data which never arrives,
or a cancellation via _a different thread_ calling rtlsdr_cancel_async().
* main thread notices the lack of SDR data and complains
* something external e.g. piaware tries a restart and sends SIGTERM
* the signal handler sets Modes.exit = 1; the main thread starts waiting for receive thread termination
* because we're never getting callbacks from rtlsdr_read_async(), we never call rtlsdr_cancel_async
* dump1090 hangs waiting on receive thread termination
To fix this, add a sdrStop() handler function where the general contract is "make the receive thread terminate".
In the rtlsdr case, this calls rtlsdr_cancel_async directly, which will make rtlsdr_read_async() return even
if the hardware is stuck.
The main thread then calls sdrStop() before waiting for receive thread termination.
Also, as discussed in the thread above, there's not really much point in continuing to run if the SDR
has wedged, so bail out after 30 seconds of no sample data.
Also, if pthread_timedjoin_np is available, use it in preference to pthread_join so that we do not wait
indefinitely for the receive thread on shutdown. If the join times out, give up and abort() as we can't
safely continue a clean shutdown while the receive thread is running.
Reorder --ifile pseudo-sdr after the "none" SDR so that a build with no real
SDR support defaults to "none" not --ifile
If the "none" SDR was selected and network mode is not enabled, tell the
user about the problem rather than just failing to do anything useful.
The commit provides a basic implementation of support for LimeSDR USB
receivers based on LMS7002 chip. The solution has several limitations:
- passing parameters for tune LimeSDR receiver via command-line
options is not implemented;
- only hardcoded configuration is used (channel 0 of lower band LNA,
LMS_FMT_I16 format, gain, bandwidth and timeout);
- only one device is supported and it is not possible to select a
desired one in case if several devices are connected to the host.
Test: compare the output of the program for RTL and LimeSDR receivers.
Environment:
- RTL2832SDR dongle;
- LMS7002M based USB LimeSDR board;
- 800MHz-2200MHz omnidirectional antenna with SMA connector.
Procedure:
- connect RTL dongle to the host and start the program with the
following parameters:
$ ./dump1090 --device-type rtlsdr --interactive
- wait until several planes will be detected;
- stop the program, connect the LimeSDR board to the host and restart
the program with the following parameters:
$ ./dump1090 --device-type limesdr --interactive
- ensure that the same planes are detected.
Acceptance criteria: the same planes are detected using both receivers
and track information matches with information from the
FlightRadar24 application.
Signed-off-by: Gluttton <gluttton@ukr.net>
Oliver Jowett
Gluttton
Carlos Pizarro
Oliver Jowett