Add ability to set the combined normalized gain via command line
options. By default the gain is equal to 0.75.
Test: connect LimeSDR device, try to set different gain and check logs:
$ ./dump1090 --device-type limesdr --limesdr-gain 0.01
$ ./dump1090 --device-type limesdr --limesdr-gain 0.5
$ ./dump1090 --device-type limesdr --limesdr-gain 0.99
Signed-off-by: Gluttton <gluttton@ukr.net>
Add ability to set RF oversampling ratio via command line options. By
default the default value is used.
Test: none.
Signed-off-by: Gluttton <gluttton@ukr.net>
Add ability to select a desired LimeSDR device by serial number. It is
not necessary to pass a whole serial number, but its key part is enough.
The first device which serial contains the passed key is selected.
Test: connect LimeSDR device and try to select it by serial number,
below an example for a device with serial 0009081C05C00000:
OK: $ ./dump1090 --device-type limesdr --limesdr-serial 9
OK: $ ./dump1090 --device-type limesdr --limesdr-serial 90
OK: $ ./dump1090 --device-type limesdr --limesdr-serial 908
NG: $ ./dump1090 --device-type limesdr --limesdr-serial 999
It hasn't been tested with several devices!
Signed-off-by: Gluttton <gluttton@ukr.net>
Add ability to set verbosity level for LimeSDR messages via command line
options. The range of available levels is from 0 to 4 and defined by the
constants from the `LimeSuite.h` file:
- LMS_LOG_CRITICAL 0;
- LMS_LOG_ERROR 1;
- LMS_LOG_WARNING 2;
- LMS_LOG_INFO 3;
- LMS_LOG_DEBUG 4.
By default the verbosity level is 3 (INFO).
Test: launch the program with different verbosity level and ensure that
number of messages is changed, for example:
$ ./dump1090 --device-type limesdr --limesdr-verbosity 4
$ ./dump1090 --device-type limesdr --limesdr-verbosity 3
$ ./dump1090 --device-type limesdr
Signed-off-by: Gluttton <gluttton@ukr.net>
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>
When `unreliable_tracks` was added to the JSON output, the trailing `}` after `single_message` should likely have been removed.
Side note: should this just be `unreliable` since it is nested inside `tracks`? `all` and `single_message` don't have the `tracks` suffix.
residual, use the full 24-bit syndrome.
Previously this would mask off the low 7 bits, which isn't particularly
great - it doesn't really make sense in that it implies a somewhat
random IID value, and it would actually only correct 20 possible bit
errors out of the 51 possible errors, 16 of which were errors in
the top 16 bits of the CRC itself. It is also risky as it will accept
a larger number of possible garbage messages as the lower 7 bits may take
any value.
Instead, use the full syndrome, assuming that the damaged message
had IID=0 - which seems more likely than assuming a random IID, since
IID=0 is used for acquisition squitters and should be arriving regularly.
The reduced rate of corrections for DF11 messages shouldn't have
much of an impact as DF11s carry very little data themselves - they
are mainly used to acquire the aircraft address. Once one good message
for an aircraft turns up (which would require IID=0 anyway before we'd
accept it) it doesn't really matter if we discard more damaged messages,
as they're not contributing to anything useful in the aircraft state
beyond air/ground status, which is also carried in many other messages.
nb: messages with a correctable 2-bit error are only forwarded to network
clients that have enabled verbatim mode (and they will be forwarded with
the 2-bit error still present, so the downstream client must apply its own
correction if desired)
Gluttton
Eric Tran
Oliver Jowett
Jade Michael Thornton
byronbest
Oliver Jowett
Dan McGee