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
A "reliable" message is a DF17 or DF11 with good CRC.
A "reliable" aircraft is one that's probably real - we decide it's reliable when
we've seen enough reliable messages, or just enough messages in total, that it's unlikely
to be noise.
The old matching process which tracked mode A values as pseudo-aircraft
got very, very expensive with a large number of mode A/C messages (and
with lots of single-bit errors, which seems common with a Beast doing
the reception)
Instead just count A/C messages directly into a 4096-entry array (which
is very fast) and periodically scan the mode S aircraft list to see if
we can match anything up (which is fixed overhead + cost proportional
to the number of mode S aircraft)
Notice synthetic mlat messages by looking for messages with a magic
timestamp value. If they arrive, tag the derived data as mlat-derived.
Don't include mlat-derived output in FATSV output to avoid loops.
Track NUCp when we compute positions.
Do speed checks when we have an updated position with the same or worse NUCp
before accepting the new position. Don't do speed checks on new postions if
they improve NUCp - assume that the new position is better.
Include NUCp in aircraft.json
Gather stats on reasons for rejecting CPR data due to range/speed check failures.
Expire old positions if we have had no updates for 60 seconds.
Closes#16, closes#17.
This is possible now that the SBS output doesn't rely on the global block timestamp;
the output will look like this:
MSG,8,111,11111,4AC954,111111,2015/02/08,17:57:53.917,2015/02/08,17:57:53.936,,,,,,,,,,,,0
MSG,7,111,11111,392AEB,111111,2015/02/08,17:57:53.744,2015/02/08,17:57:53.936,,15375,,,,,,,,,,0
MSG,8,111,11111,392AEB,111111,2015/02/08,17:57:53.917,2015/02/08,17:57:53.936,,,,,,,,,,,,0
MSG,6,111,11111,800387,111111,2015/02/08,17:57:53.919,2015/02/08,17:57:53.936,,,,,,,,4745,0,0,0,0
where the "receive timestamp" (first time column) goes backwards to reflect the original reception
time of the delayed message, but the "forwarded timestamp" (second time column) reflects the actual
forwarding time.
(except in --net-verbatim mode, where we emit them all)
Move aircraft tracking into track.[ch].
Clean up references to "interactive mode" when tracking
aircraft - we always track aircraft, even in non-interactive
mode.
Oliver Jowett
George Joseph
Oliver Jowett