Usually, all message candidates are speculatively corrected as if
they were DF11/17/18, even if the DF field has a different value. This
allows correction of messages when there is correctable damage to the
DF field.
However, running every message candidate through a couple of CRC checks
is expensive, CPU-wise, when decoding messages off the air, as there are
a large number of message candidates that are actually just junk data, and
computing CRCs for all of those adds up. The --no-fix-df option allows
disabling this sort of correction. The tradeoff is that messages with
damage to the DF field will not be corrected.
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
Update all the SDR implementation to use it.
This was getting pretty ugly with code getting copy&pasted in all the SDR
implementations. Unify it all and give it a simpler API. Linked list works out
much simpler than the circular buffer. Also, simplify copying the overlap region
around by just using a separate buffer (it's only a few hundred bytes long, so
the double copy is not a big deal).
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)
Make --net-verbatim just control the default setting.
0x1A '1' 'v' disables verbatim mode (send "cooked" output);
0x1A '1' 'V' enables verbatim mode
Support clients with different settings by switching them between output
writers depending on what setting they want, so clients with different
settings can co-exist (unlike the Mode A/C setting)
In cooked mode, FEC corrections are applied to messages before they are send
and only trustworthy messages are forwarded; this is the default case for
downstream clients that don't want to apply their own rules and are happy with
the decisions that dump1090 makes.
In verbatim mode, all messages are forwarded, but no FEC corrections are applied;
the downstream client needs to make its own FEC / noise filtering decisions.
Usually the default for new connections is cooked mode. --net-verbatim changes the
default to be verbatim mode.
This turns it into a handy debug tool for looking at raw messages
from an existing running dump1090 without having to mess around with
a separate copy of dump1090 and netcat tunnels etc.
This lets different things dynamically create the services they need,
and sorts out the horrible hacks that view1090 used to make outgoing
connections. Now you can explicitly create a service and tell it to make
an outgoing connection.
This means that view1090 can now just set all the ports to zero (to disable
the listeners), do a normal net init, then explicitly construct the beast
input service without a listener and tell it to make a connection as needed.
(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.
view1090 was using close to 100% CPU before, with the non-blocking
commits and the reconnection code. sleep a bit between loop iterations
to keep CPU usage low.
CPU usage with this addition was down to <1% in testing.
Make the modifications necessary to compile dump1090 for WinXP, Win7 and
hopefully Win8.
The files can be compiled using M$ Visual Studio/C++ 6.0. Due to various
licensing issues, I haven't included the libraries or DLLs. You will
need to locate pthreadVC2.lib and rtlsdr.lib to link the file, install
the zadig drivers to support the dongle, and locate libusb-1.0.dll,
msvcr100.dll, pthreadVC2.dll and rtlsdr.dll.
dump1090.exe will not run on any Windows version prior to XP SP2,
because msvcr100.dll imports several functions from the Windows kernel
that are not available on earlier versions. This means dump1090 won't
work on Win2K.
The major change to the code relates to file handles. The original code
assumes Linux behaviour in that handles are allocated from 0
sequentially upwards. However Windows handles are allocated pseudo
randomly, and handle numbers greater than 1024 would break the code. The
code has therefore been modified to use a linked list of connection
structures, rather than a static array limited to 1024 entries.
No changes to dump1090, (except the version number)
Include a sample Linux batch start file called dump1090.sh for use when
running dump1090 headless. This file needs to be copied to the
/etc/init.d/ subdirectory on your raspberry pi, and marked as
executable. Then when you re-start your RPi, dump1090 will start-up
auto-magically and run as a sort of server to allow both local and
remote connection to it's various internet ports.
Modified the Makefile to build a new headless helper application called
view1090
Added view1090. This is an executable that allows you to connect to
dump1090 when it is running and 'see' the interactive screen display.
The default is to try and connect to dump1090 on IP address 127.0.0.1
port 30005. This should work if you are running on the same RPi as
dump1090 and using the default dump1090 port settings. However, if
you're running on a different machine you will have to specify the IP
address of the RPi running dump1090 using the --net-bo-ipaddr switch.
Something like "view1090 --net-bo-ipaddr 192.168.2.65" . You may also
have to sudo it, depending on your privilige settings.
I've also compiled view1090 as a Wiin32 exe, so you should be able to
run it under any 32 bit version of Microsoft Windows - i.e. Win95, Win
2K, Win XP, Win 7 etc. It may work on Win 8 and 64 bit Windows, but I
haven't tried it. The Win32 version is compiled from the same source, so
takes all the same command line switches.