* Switch all conversion routines to use starch.
main user-visible changes:
* ensure you check out submodules ('git clone --recurse-submodules")
* --version shows the CPU features and DSP implementations in use
* --wisdom allows overriding of the built-in architecture wisdom
* --dcfilter no longer supported
* "starch-benchmark" binary will benchmark all options on the
current machine and can produce a wisdom file to feed to
the --wisdom option
If you have a usecase for --dcfilter, please get in touch and
let me know - it's an edge case and for now there's no starch/DSP
support for it, but support can be written if needed.
In almost all cases the new conversion routines are slightly or
substantially faster than the old conversion routines. The only case
that is slower is SC16/SC16Q11 on a Pi 0, which is around 10% slower
due to changing from heavily approximated lookup tables to higher
quality results (but SC16 is probably already out of reach of a Pi 0)
* No need to build with SC16Q11_TABLE_BITS any more
* Add oneoff/uc8_capture_stats
(reads a UC8 capture; measures min/max/mean I and Q)
* Switch UC8 conversion to 127.4 center, 128 range.
Looking at actual UC8 captures from a RTL2832, the mean I and Q
are actually at 127.4, so use that as the zero point.
This means that the resulting I/Q maximum values could be as large as
127.6. Switch to 128 for simplicity.
* Switch to the new UC8 zero offset in benchmarks, fix some bugs
* Fix some bugs in SC16/SC16Q11 validation, tighten the max error requirements
* Ditch UC8 approximation path, add a NEON VRQSQRTE path.
* Tweak the SC16 exact path, add a new impl that uses a mix of
u32 & floats.
* SC16Q11 impl tweaks:
* add a u32->float exact path
* ditch the approximation path
* add a NEON VRSQRTE path
* add a 12-bit table path (using the full signed I/Q value, not absolute value)
* Ditch SC16 approximation path, add NEON vrsqrte path
* Add oneoff/dsp_error_measurement
This runs sample input through the DSP functions that are
allowed to be inexact and dumps the results as a TSV suitable for
feeding to gnuplot to look at the actual errors.
* Update make clean, make wisdom targets
* Update wisdom based on benchmarking
* Preserve the raw wisdom benchmark data
* Update to latest starch
* Update .gitignore for new wisdom files
* Update starch generated code
* Build starch-benchmark as part of the 'all' target
* Use wisdom from /etc/dump1090-fa/wisdom.local if present
* Package starch-benchmark and a helper script to generate local wisdom data
* Remove submodules in preparation for importing them directly
* Import cpu_features v0.6.0 from https://github.com/google/cpu_features/releases/tag/v0.6.0
* Import starch at commit a725c8491dc33a321565d451b385131e589d8490
from https://github.com/flightaware/starch
It was possible, due to an off-by-one error in normalize_timespec, that
the computed deadline passed to pthread_cond_timedwait had tv_nsec == 1000000000.
glibc would reject this with EINVAL. While I never caught this in the act, there
seem to be two follow-on problems from this:
1) we were looking for a negative return from pthread_cond_timedwait and testing errno.
This is not how errors are reported, instead pthread functions return the error value
directly. So the enclosing loop could spin forever, repeatedly passing the bad deadline
value.
2) even if the error handling caught the EINVAL return, it assumed that the mutex was
no longer held and didn't release it; but on error returns, the mutex state is actually
untouched.
Fix both cases (probably), and log about unusual returns from pthread_cond_timedwait
These updates were designed to assist those using interactive
mode to tune antennas and SDR gain.
* Add options to display distance and bearing in interactive mode
Distance and bearing instead of latitude and longitude can now be
displayed in interactive mode using the following options to
dump1090-fa and view1090-fa.
--interactive-show-distance Show aircraft distance and bearing
instead of aircraft lat/lon
(requires --lat and --lon)
--interactive-distance-units Distance units ('km', 'sm', 'nm')
(default: 'nm')"
You have to specify a reference --lat and --lon for this to
work of course.
* A new line now shows at the top of the interactive display that
has for the current sample:
Total valid aircraft count
Vidible aircraft count
Will be less than total if the screen hasn't enough lines to show
them all.
Max RSSI
Min RSSI
Mean RSSI
Max Distance
Tot: 47 Vis: 47 RSSI: Max 25.4+ Mean -29.5 Min -36.9- MaxD: 197.3nm+
* Add max distance and min/max RSSI indicators
A '+' after the distance in a row indicates it's the row with the
maximum distance.
A '+' after the RSSI in a row indicates it's the row with the highest
RSSI.
A '-' after the RSSI in a row indicates it's the row with the lowest
RSSI.
The summary line at the top of the screen always shows the values for
ALL aircraft, even those not visible. The row indicators only mark
visible rows though.
In this example, the first aircraft is both the farthest away and has
the weakest RSSI. The second aircraft has the strongest RSSI.
Tot: 47 Vis: 47 RSSI: Max 25.4+ Mean -29.5 Min -36.9- MaxD: 197.3nm+ -
Hex Mode Sqwk Flight Alt Spd Hdg Dist(nm) Bearing RSSI Msgs Ti
────────────────────────────────────────────────────────────────────────────────
A8D5A4 S2 34000 438 252 197.3+ 85 -36.1- 26 2
A39A13 S2ac 5740 FFT525 30750 439 256 98.8 68 -25.4+ 123 0
A70B23 S2ac 2744 LXJ553 43000 419 258 136.1 39 -33.6 174 0
* Finally, a new option '--interactive-callsign-filter' has been added
to allow filtering interactive by callsign. The value can be a
simple string, in which case aircraft with that string anywhere in its
callsign will be displayed, or a regular expression should you want a
more precise match.
Examples:
--interactive-callsign-filter UAL
will match all aircraft with UAL anywhere in its callsign.
--interactive-callsign-filter "^UAL"
will match only those callsigns that start with UAL.
--interactive-callsign-filter "^(UAL|AAL)"
will match only those callsigns that start with UAL or AAL.
--interactive-callsign-filter "^N[0-9]" or "^N[[:digit:]]"
will match only those callsigns that start with "N" and a number
If you need more info on regular expressions, see this link:
https://en.wikipedia.org/wiki/Regular_expression
Oliver Jowett
Edwin Groothuis
eric1tran
Eric Tran
MAUGIN Thomas
George Joseph