The legacy -10 value is still supported for compatbility with old
configs, but new configs should just select an appropriate gain e.g.
60dB.
rtlsdr default gain continues to be the highest regular gain step (~ 49.6dB)
on upgrade to 6.0. (Not extensively tested yet)
We do this for two reasons:
1) the config file layout is completely different, it's error-prone
and tedious to force the user to manually transfer their customizations
on upgrade;
2) if there are user modifications to the config file, an upgrade triggered
remotely via piaware will prefer to keep the original config file intact
rather than installing the new version, and the old version just won't
work correctly with the new infrastructure.
Now we have specific config options for different features rather
than just a big list of command-line options. You can still provide
custom options via EXTRA_OPTIONS or OVERRIDE_OPTIONS.
Also adds adaptive gain settings, and a "slow cpu" setting which
can turn on cpu-reducing options automatically when a slower (armv6)
CPU is in use.
This makes the adaptive gain code only process some fraction of all samples,
rather than every sample. This helps a lot with CPU on slower machines.
We default to a 50% duty cycle to save some CPU without really affecting
the behavior much.
We split the one-second adaptive gain blocks into 20* 50ms "subblocks"
Each subblock is either entirely processed or not processed at all,
based on the configured duty cycle. (This means that the duty cycle
can only be specified in approx 5% increments, but that should be
fine)
For adaptive dynamic range, there's no further complications - we
just look at fewer samples to compute the noise floor.
For adaptive burst, we need to scale up the measured burst rate by
1/duty cycle to account for the samples that we didn't process. It's
also more likely to cause functional changes as it's quite possible
for a relatively small number of loud messages being missed to
affect the computed rate substantially. Not many options there other
than increasing the duty cycle when adaptive burst handling is wanted.
Update adaptive gain control loop to handle interactions between burst detection and dynamic range control.
Internal doc updates & naming cleanups.
Stats tweaks.
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.
This reinstates the fastpath in the 2.4MHz demodulator that
aborts message demodulation early if the DF bits don't match a message
type that we know how to decode, or stops early if the DF bits can
only correspond to a short 56-bit message.
Do this in a more general form where we test against a set of valid
DF values, rather than a switch/case. Then populate the sets based on
the current error-correction settings (e.g. if we are allowed to repair
DF damage with 1 bit error correction, then a DF17 message could appear
with any of DF=17, DF=16, DF=19, DF=21, DF=25, or DF=1 and still be
correctable to a valid DF17 message)
In the default case this produces a small CPU improvement as short
messages might be able to stop earlier and a few DF values can be ignored
early. With --no-fix-df it produces a larger improvement as relatively few
DF values are valid in that mode.
To further reduce CPU, the default behaviour has changed to _not_
decode DF24 messages (Comm-D ELM messages). These are rarely seen in
the wild and dump1090 can't do anything useful with them. Disabling
them allows us to further reduce the set of valid DF values as they
effectively use all DF values from 24..31, 25% of all possible values.
To re-enable DF24 decoding, use the new `--enable-df24` option.
Finally, avoid doing some CRC calculations twice. This was only happening
once per valid decoded message, not per demodulation attempt, so it's not
such a large win.
Oliver Jowett
wiedehopf
eric1tran
Chris Carini
Турченко Василий Владимирович
Emilien Klein