History

Oliver Jowett c421c31152 Overhaul of message scoring & error correction. Major changes: Try to error-correct all messages that potentially could be DF11/17/18 even if the original DF value is different. This allows messages with correctable damage in the first 5 bits to be correctable. Track recently-seen DF18 addresses separately to DF17 addresses. DF18 does not imply Mode S support, so we don't want to treat it like a known Mode S emitter, but once we've heard some DF18 for an aircraft we can be more confident about future DF18 messages for the same address. Rework the scoring system so it's just a big enum that lists all the possible outcomes in the order that we want. This makes the relative ordering of different messages clearer, and makes it easier to move messages above/below the accept thresholds as needed. Don't accept 2-bit-error-corrected messages that are from aircraft we have not previously seen. This greatly reduces the number of garbage messages when using 2-bit error correction. Overall results are: * more CPU required for decoding (approx 30% increase in my tests) as we're doing a lot more speculative CRC-checking work * no significant change to message rates with error correction off * about 5% more 1-bit-corrected DF17 decodes, with a disproportionate increase in those messages contributing to successful position decodes / unique aircraft counts * _fewer_ decodes with 2-bit correction (versus old code with 2-bit correction), but the message quality is substantially improved, the rate of garbage decodes / phantom aircraft is greatly reduced sample stats: 1-bit correction, old code: 141158 total usable messages 137852 accepted with correct CRC 3306 accepted with 1-bit error repaired 27446 DF17 messages 51 unique aircraft tracks 1-bit correction, new code: 141296 total usable messages 137854 accepted with correct CRC 3442 accepted with 1-bit error repaired 27528 DF17 messages 55 unique aircraft tracks 2-bit correction, old code: 142656 total usable messages 137809 accepted with correct CRC 3283 accepted with 1-bit error repaired 1564 accepted with 2-bit error repaired 28803 DF17 messages 349 unique aircraft tracks (<- note that most of these are garbage) 2-bit correction, new code: 142426 total usable messages 137822 accepted with correct CRC 3420 accepted with 1-bit error repaired 1184 accepted with 2-bit error repaired 28666 DF17 messages 55 unique aircraft tracks		2021-02-09 20:10:55 +08:00
..
README.aircraft-db.md	Update README with current compressed csv file	2020-09-24 06:10:58 +00:00
csv-to-json.py	Have filter-regs emit a special value "-COMPUTED-" for filtered data values,	2019-08-16 15:16:55 +08:00
debug.html	A few bugs fixed in debug.html.	2013-01-27 21:42:40 +01:00
df-correction-arrays.py	Overhaul of message scoring & error correction.	2021-02-09 20:10:55 +08:00
extract-icao-ranges.py	Regenerate the ICAO ranges table based on data extracted from Annex 10.	2015-09-01 14:21:25 +01:00
filter-regs.js	Have filter-regs emit a special value "-COMPUTED-" for filtered data values,	2019-08-16 15:16:55 +08:00
flightaware-20200924.csv.xz	Update aircraft db to 20200924	2020-09-24 06:01:36 +00:00
fuzzy-30003-matcher.py	Add a port-30003 regression diff script.	2016-10-02 13:27:13 +01:00
replay-beast.py	Tool to replay beast captures with the right inter-message timing.	2016-10-01 15:06:02 +01:00
vrs-to-csv.py	Rearrange json DB stuff so it can work with CSV input.	2016-08-27 16:13:10 +01:00
vrs.csv.xz	Compress vrs.csv since it's basically readonly.	2016-09-10 17:43:10 +01:00

README.aircraft-db.md

dump1090 aircraft database

The dump1090 webmap uses a static database of json files to provide aircraft information.

This directory has some tools to turn a CSV file with aircraft data into the json format that the dump1090 map expects.

Data sources

The default data comes from a combination of:

some historical data kindly provided by VRS (unfortunately no longer updated) - this data is in vrs.csv.xz; and
a data export provided by FlightAware that is updated periodically - this data is in flightaware-*.csv.xz

The VRS data was extracted by:

$ wget http://www.virtualradarserver.co.uk/Files/BasicAircraftLookup.sqb.gz
$ gunzip BasicAircraftLookup.sqb.gz
$ tools/vrs-to-csv.py BasicAircraftLookup.sqb >tools/vrs.csv

The FlightAware data is a subset of the registry information that FlightAware uses internally. It contains only the data that FlightAware can redistribute to the public; some data sources that FlightAware uses do not allow this and are excluded from the export.

Regenerating the json database

To regenerate the json database from these input files:

$ rm ../public_html/db/*.json
$ xzcat vrs.csv.xz | nodejs ./filter-regs.js >vrs-filtered.csv
$ xzcat flightaware-20200924.csv.xz | nodejs ./filter-regs.js >fa-filtered.csv
$ ./csv-to-json.py vrs-filtered.csv fa-filtered.csv ../public_html/db

Additional CSV files can be given to csv-to-json.py if desired.

The contents of public_html/db should be installed where the webmap can find them; the Debian packaging puts these in /usr/share/dump1090-fa/html/db

The CSV format is very simple. The first line must be a header line that names the columns. These columns are understood:

icao24: the 6-digit hex address of the aircraft
r: the registration / tail number of the aircraft
t: the ICAO aircraft type of the aircraft, e.g. B773

Any other columns are put into the json DB under the name you give them, but the standard map code won't do anything special with them. You can pick these columns up in the PlaneObject constructor (see planeObject.js where it calls getAircraftData()) for later use.