2015-01-20 16:49:01 +00:00
|
|
|
// Part of dump1090, a Mode S message decoder for RTLSDR devices.
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
//
|
2015-01-20 16:49:01 +00:00
|
|
|
// mode_s.c: Mode S message decoding.
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
//
|
2016-08-27 13:34:14 +00:00
|
|
|
// Copyright (c) 2014-2016 Oliver Jowett <oliver@mutability.co.uk>
|
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 11:43:38 +00:00
|
|
|
// Copyright (c) 2021 FlightAware LLC
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
//
|
2017-06-15 17:16:51 +00:00
|
|
|
// This file is free software: you may copy, redistribute and/or modify it
|
2015-01-20 16:49:01 +00:00
|
|
|
// under the terms of the GNU General Public License as published by the
|
2017-06-15 17:16:51 +00:00
|
|
|
// Free Software Foundation, either version 2 of the License, or (at your
|
|
|
|
|
// option) any later version.
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
//
|
2017-06-15 17:16:51 +00:00
|
|
|
// This file is distributed in the hope that it will be useful, but
|
|
|
|
|
// WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
2015-01-20 16:49:01 +00:00
|
|
|
// General Public License for more details.
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
//
|
2017-06-15 17:16:51 +00:00
|
|
|
// You should have received a copy of the GNU General Public License
|
2015-01-20 16:49:01 +00:00
|
|
|
// along with this program. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
|
|
2017-06-15 17:16:51 +00:00
|
|
|
// This file incorporates work covered by the following copyright and
|
2015-01-20 16:49:01 +00:00
|
|
|
// permission notice:
|
|
|
|
|
//
|
|
|
|
|
// Copyright (C) 2012 by Salvatore Sanfilippo <antirez@gmail.com>
|
|
|
|
|
//
|
|
|
|
|
// All rights reserved.
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
//
|
2015-01-20 16:49:01 +00:00
|
|
|
// Redistribution and use in source and binary forms, with or without
|
|
|
|
|
// modification, are permitted provided that the following conditions are
|
|
|
|
|
// met:
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
//
|
2015-01-20 16:49:01 +00:00
|
|
|
// * Redistributions of source code must retain the above copyright
|
|
|
|
|
// notice, this list of conditions and the following disclaimer.
|
|
|
|
|
//
|
|
|
|
|
// * Redistributions in binary form must reproduce the above copyright
|
|
|
|
|
// notice, this list of conditions and the following disclaimer in the
|
|
|
|
|
// documentation and/or other materials provided with the distribution.
|
|
|
|
|
//
|
|
|
|
|
// THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
|
|
|
|
|
// "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
|
|
|
|
|
// LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
|
|
|
|
|
// A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
|
|
|
|
|
// HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
|
|
|
|
|
// SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
|
|
|
|
|
// LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
|
|
|
|
|
// DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
|
|
|
|
|
// THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
|
|
|
|
|
// (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
|
|
|
|
|
// OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
|
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
|
|
|
|
|
#include "dump1090.h"
|
2019-05-02 09:24:26 +00:00
|
|
|
#include "ais_charset.h"
|
2015-04-18 23:57:24 +00:00
|
|
|
|
|
|
|
|
/* for PRIX64 */
|
|
|
|
|
#include <inttypes.h>
|
|
|
|
|
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
//
|
|
|
|
|
// ===================== Mode S detection and decoding ===================
|
|
|
|
|
//
|
|
|
|
|
//
|
|
|
|
|
//
|
|
|
|
|
|
2015-06-28 19:04:09 +00:00
|
|
|
/* A timestamp that indicates the data is synthetic, created from a
|
|
|
|
|
* multilateration result
|
|
|
|
|
*/
|
2015-06-28 23:31:42 +00:00
|
|
|
#define MAGIC_MLAT_TIMESTAMP 0xFF004D4C4154ULL
|
2015-06-28 19:04:09 +00:00
|
|
|
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
//=========================================================================
|
|
|
|
|
//
|
|
|
|
|
// Given the Downlink Format (DF) of the message, return the message length in bits.
|
|
|
|
|
//
|
2017-06-15 17:16:51 +00:00
|
|
|
// All known DF's 16 or greater are long. All known DF's 15 or less are short.
|
|
|
|
|
// There are lots of unused codes in both category, so we can assume ICAO will stick to
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
// these rules, meaning that the most significant bit of the DF indicates the length.
|
|
|
|
|
//
|
|
|
|
|
int modesMessageLenByType(int type) {
|
|
|
|
|
return (type & 0x10) ? MODES_LONG_MSG_BITS : MODES_SHORT_MSG_BITS ;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
//
|
|
|
|
|
//=========================================================================
|
|
|
|
|
//
|
|
|
|
|
// In the squawk (identity) field bits are interleaved as follows in
|
|
|
|
|
// (message bit 20 to bit 32):
|
|
|
|
|
//
|
|
|
|
|
// C1-A1-C2-A2-C4-A4-ZERO-B1-D1-B2-D2-B4-D4
|
|
|
|
|
//
|
|
|
|
|
// So every group of three bits A, B, C, D represent an integer from 0 to 7.
|
|
|
|
|
//
|
2017-06-15 17:16:51 +00:00
|
|
|
// The actual meaning is just 4 octal numbers, but we convert it into a hex
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
// number tha happens to represent the four octal numbers.
|
|
|
|
|
//
|
|
|
|
|
// For more info: http://en.wikipedia.org/wiki/Gillham_code
|
|
|
|
|
//
|
2015-01-21 00:23:48 +00:00
|
|
|
static int decodeID13Field(int ID13Field) {
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
int hexGillham = 0;
|
|
|
|
|
|
|
|
|
|
if (ID13Field & 0x1000) {hexGillham |= 0x0010;} // Bit 12 = C1
|
|
|
|
|
if (ID13Field & 0x0800) {hexGillham |= 0x1000;} // Bit 11 = A1
|
|
|
|
|
if (ID13Field & 0x0400) {hexGillham |= 0x0020;} // Bit 10 = C2
|
|
|
|
|
if (ID13Field & 0x0200) {hexGillham |= 0x2000;} // Bit 9 = A2
|
|
|
|
|
if (ID13Field & 0x0100) {hexGillham |= 0x0040;} // Bit 8 = C4
|
|
|
|
|
if (ID13Field & 0x0080) {hexGillham |= 0x4000;} // Bit 7 = A4
|
2017-06-15 17:16:51 +00:00
|
|
|
//if (ID13Field & 0x0040) {hexGillham |= 0x0800;} // Bit 6 = X or M
|
|
|
|
|
if (ID13Field & 0x0020) {hexGillham |= 0x0100;} // Bit 5 = B1
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
if (ID13Field & 0x0010) {hexGillham |= 0x0001;} // Bit 4 = D1 or Q
|
|
|
|
|
if (ID13Field & 0x0008) {hexGillham |= 0x0200;} // Bit 3 = B2
|
|
|
|
|
if (ID13Field & 0x0004) {hexGillham |= 0x0002;} // Bit 2 = D2
|
|
|
|
|
if (ID13Field & 0x0002) {hexGillham |= 0x0400;} // Bit 1 = B4
|
|
|
|
|
if (ID13Field & 0x0001) {hexGillham |= 0x0004;} // Bit 0 = D4
|
|
|
|
|
|
|
|
|
|
return (hexGillham);
|
2015-02-09 22:53:18 +00:00
|
|
|
}
|
|
|
|
|
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
//
|
|
|
|
|
//=========================================================================
|
|
|
|
|
//
|
|
|
|
|
// Decode the 13 bit AC altitude field (in DF 20 and others).
|
2016-08-27 13:34:14 +00:00
|
|
|
// Returns the altitude, and set 'unit' to either UNIT_METERS or UNIT_FEET.
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
//
|
2016-08-27 13:34:14 +00:00
|
|
|
static int decodeAC13Field(int AC13Field, altitude_unit_t *unit) {
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
int m_bit = AC13Field & 0x0040; // set = meters, clear = feet
|
|
|
|
|
int q_bit = AC13Field & 0x0010; // set = 25 ft encoding, clear = Gillham Mode C encoding
|
|
|
|
|
|
|
|
|
|
if (!m_bit) {
|
2016-08-27 13:34:14 +00:00
|
|
|
*unit = UNIT_FEET;
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
if (q_bit) {
|
|
|
|
|
// N is the 11 bit integer resulting from the removal of bit Q and M
|
|
|
|
|
int n = ((AC13Field & 0x1F80) >> 2) |
|
|
|
|
|
((AC13Field & 0x0020) >> 1) |
|
|
|
|
|
(AC13Field & 0x000F);
|
|
|
|
|
// The final altitude is resulting number multiplied by 25, minus 1000.
|
|
|
|
|
return ((n * 25) - 1000);
|
|
|
|
|
} else {
|
|
|
|
|
// N is an 11 bit Gillham coded altitude
|
2016-10-11 16:57:25 +00:00
|
|
|
int n = modeAToModeC(decodeID13Field(AC13Field));
|
2015-02-09 22:53:18 +00:00
|
|
|
if (n < -12) {
|
|
|
|
|
return INVALID_ALTITUDE;
|
|
|
|
|
}
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
|
|
|
|
|
return (100 * n);
|
|
|
|
|
}
|
|
|
|
|
} else {
|
2016-08-27 13:34:14 +00:00
|
|
|
*unit = UNIT_METERS;
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
// TODO: Implement altitude when meter unit is selected
|
2015-02-09 22:53:18 +00:00
|
|
|
return INVALID_ALTITUDE;
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
}
|
|
|
|
|
}
|
2016-08-27 13:34:14 +00:00
|
|
|
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
//
|
|
|
|
|
//=========================================================================
|
|
|
|
|
//
|
|
|
|
|
// Decode the 12 bit AC altitude field (in DF 17 and others).
|
|
|
|
|
//
|
2016-08-27 13:34:14 +00:00
|
|
|
static int decodeAC12Field(int AC12Field, altitude_unit_t *unit) {
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
int q_bit = AC12Field & 0x10; // Bit 48 = Q
|
|
|
|
|
|
2016-08-27 13:34:14 +00:00
|
|
|
*unit = UNIT_FEET;
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
if (q_bit) {
|
|
|
|
|
/// N is the 11 bit integer resulting from the removal of bit Q at bit 4
|
2017-06-15 17:16:51 +00:00
|
|
|
int n = ((AC12Field & 0x0FE0) >> 1) |
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
(AC12Field & 0x000F);
|
|
|
|
|
// The final altitude is the resulting number multiplied by 25, minus 1000.
|
|
|
|
|
return ((n * 25) - 1000);
|
|
|
|
|
} else {
|
|
|
|
|
// Make N a 13 bit Gillham coded altitude by inserting M=0 at bit 6
|
2017-06-15 17:16:51 +00:00
|
|
|
int n = ((AC12Field & 0x0FC0) << 1) |
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
(AC12Field & 0x003F);
|
2016-10-11 16:57:25 +00:00
|
|
|
n = modeAToModeC(decodeID13Field(n));
|
2015-02-09 22:53:18 +00:00
|
|
|
if (n < -12) {
|
|
|
|
|
return INVALID_ALTITUDE;
|
|
|
|
|
}
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
|
|
|
|
|
return (100 * n);
|
|
|
|
|
}
|
|
|
|
|
}
|
2016-08-27 13:34:14 +00:00
|
|
|
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
//
|
|
|
|
|
//=========================================================================
|
|
|
|
|
//
|
2017-12-07 16:34:08 +00:00
|
|
|
// Decode the 7 bit ground movement field PWL exponential style scale (ADS-B v2)
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
//
|
2017-12-07 16:34:08 +00:00
|
|
|
static float decodeMovementFieldV2(unsigned movement) {
|
2017-06-15 17:16:51 +00:00
|
|
|
// Note : movement codes 0,125,126,127 are all invalid, but they are
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
// trapped for before this function is called.
|
|
|
|
|
|
2017-12-07 16:34:08 +00:00
|
|
|
// Each movement value is a range of speeds;
|
|
|
|
|
// we return the midpoint of the range (rounded to the nearest integer)
|
|
|
|
|
if (movement >= 125) return 0; // invalid
|
|
|
|
|
else if (movement == 124) return 180; // gs > 175kt, pick a value..
|
|
|
|
|
else if (movement >= 109) return 100 + (movement - 109 + 0.5) * 5; // 100 < gs <= 175 in 5kt steps
|
|
|
|
|
else if (movement >= 94) return 70 + (movement - 94 + 0.5) * 2; // 70 < gs <= 100 in 2kt steps
|
|
|
|
|
else if (movement >= 39) return 15 + (movement - 39 + 0.5) * 1; // 15 < gs <= 70 in 1kt steps
|
|
|
|
|
else if (movement >= 13) return 2 + (movement - 13 + 0.5) * 0.50; // 2 < gs <= 15 in 0.5kt steps
|
|
|
|
|
else if (movement >= 9) return 1 + (movement - 9 + 0.5) * 0.25; // 1 < gs <= 2 in 0.25kt steps
|
|
|
|
|
else if (movement >= 3) return 0.125 + (movement - 3 + 0.5) * 0.875 / 6; // 0.125 < gs <= 1 in 0.875/6 kt step
|
|
|
|
|
else if (movement >= 2) return 0.125 / 2; // 0 < gs <= 0.125
|
|
|
|
|
// 1: stopped, gs = 0
|
|
|
|
|
// 0: no data
|
|
|
|
|
else return 0;
|
|
|
|
|
}
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
|
2017-12-07 16:34:08 +00:00
|
|
|
//
|
|
|
|
|
//=========================================================================
|
|
|
|
|
//
|
|
|
|
|
// Decode the 7 bit ground movement field PWL exponential style scale (ADS-B v0)
|
|
|
|
|
//
|
|
|
|
|
static float decodeMovementFieldV0(unsigned movement) {
|
|
|
|
|
// Note : movement codes 0,125,126,127 are all invalid, but they are
|
|
|
|
|
// trapped for before this function is called.
|
|
|
|
|
|
|
|
|
|
// Each movement value is a range of speeds;
|
|
|
|
|
// we return the midpoint of the range
|
|
|
|
|
if (movement >= 125) return 0; // invalid
|
|
|
|
|
else if (movement == 124) return 180; // gs >= 175kt, pick a value..
|
|
|
|
|
else if (movement >= 109) return 100 + (movement - 109 + 0.5) * 5; // 100 < gs <= 175 in 5kt steps
|
|
|
|
|
else if (movement >= 94) return 70 + (movement - 94 + 0.5) * 2; // 70 < gs <= 100 in 2kt steps
|
|
|
|
|
else if (movement >= 39) return 15 + (movement - 39 + 0.5) * 1; // 15 < gs <= 70 in 1kt steps
|
|
|
|
|
else if (movement >= 13) return 2 + (movement - 13 + 0.5) * 0.50; // 2 < gs <= 15 in 0.5kt steps
|
|
|
|
|
else if (movement >= 9) return 1 + (movement - 9 + 0.5) * 0.25; // 1 < gs <= 2 in 0.25kt steps
|
2018-01-09 14:44:20 +00:00
|
|
|
else if (movement >= 2) return 0.125 + (movement - 2 + 0.5) * 0.125; // 0.125 < gs <= 1 in 0.125kt step
|
2017-12-07 16:34:08 +00:00
|
|
|
// 1: stopped, gs < 0.125kt
|
|
|
|
|
// 0: no data
|
|
|
|
|
else return 0;
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
}
|
2015-01-21 00:23:48 +00:00
|
|
|
|
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 11:43:38 +00:00
|
|
|
// Apply possible corrections to the 14-byte message in "in", storing the result in "out"
|
|
|
|
|
//
|
|
|
|
|
// If the message has a correct CRC, copies in to out unchanged and returns 0
|
|
|
|
|
// If the message has correctable errors, applies the corrections to out and returns the number of corrected errors
|
|
|
|
|
// If the message is uncorrectable (this may mean the message type does not have CRC coverage), returns -1
|
2015-01-21 12:55:24 +00:00
|
|
|
|
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 11:43:38 +00:00
|
|
|
// is this message a long-form message with a DF that uses Parity/Interrogator?
|
|
|
|
|
static bool isLongPIMessage(const unsigned char *msg)
|
|
|
|
|
{
|
|
|
|
|
const unsigned df = getbits(msg, 1, 5);
|
|
|
|
|
if (df == 17 || df == 18)
|
|
|
|
|
return true;
|
|
|
|
|
return false;
|
|
|
|
|
}
|
2015-01-21 12:55:24 +00:00
|
|
|
|
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 11:43:38 +00:00
|
|
|
// is this message a short-form message with a DF that uses Parity/Interrogator?
|
|
|
|
|
static bool isShortPIMessage(const unsigned char *msg)
|
|
|
|
|
{
|
|
|
|
|
const unsigned df = getbits(msg, 1, 5);
|
|
|
|
|
return (df == 11); // assume IID==0
|
2015-01-21 12:55:24 +00:00
|
|
|
}
|
|
|
|
|
|
Reduce CPU further in --no-fix-df mode. Add --enable-df24 option.
This reinstates the fastpath in the 2.4MHz demodulator that
aborts message demodulation early if the DF bits don't match a message
type that we know how to decode, or stops early if the DF bits can
only correspond to a short 56-bit message.
Do this in a more general form where we test against a set of valid
DF values, rather than a switch/case. Then populate the sets based on
the current error-correction settings (e.g. if we are allowed to repair
DF damage with 1 bit error correction, then a DF17 message could appear
with any of DF=17, DF=16, DF=19, DF=21, DF=25, or DF=1 and still be
correctable to a valid DF17 message)
In the default case this produces a small CPU improvement as short
messages might be able to stop earlier and a few DF values can be ignored
early. With --no-fix-df it produces a larger improvement as relatively few
DF values are valid in that mode.
To further reduce CPU, the default behaviour has changed to _not_
decode DF24 messages (Comm-D ELM messages). These are rarely seen in
the wild and dump1090 can't do anything useful with them. Disabling
them allows us to further reduce the set of valid DF values as they
effectively use all DF values from 24..31, 25% of all possible values.
To re-enable DF24 decoding, use the new `--enable-df24` option.
Finally, avoid doing some CRC calculations twice. This was only happening
once per valid decoded message, not per demodulation attempt, so it's not
such a large win.
2021-03-19 08:52:42 +00:00
|
|
|
#define UNCHECKED_SYNDROME 0xFFFFFFFFU
|
|
|
|
|
|
|
|
|
|
static int correctMessage(const unsigned char *in, unsigned char *out, uint32_t *short_syndrome, uint32_t *long_syndrome)
|
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 11:43:38 +00:00
|
|
|
{
|
|
|
|
|
// Possible DF values of the first byte of a message that could be a valid DF11/17/18
|
|
|
|
|
// message after correction. See tools/df-correction-arrays.py for generator code.
|
|
|
|
|
// This is used to shortcut message correction so that we don't bother computing a CRC over
|
|
|
|
|
// messages that couldn't possibly become one of those message types.
|
|
|
|
|
|
|
|
|
|
// These are bitsets, where the bit with value 1<<N represents a match for DF N
|
|
|
|
|
static const uint32_t df_correctable_short[MODES_MAX_BITERRORS + 1] = {
|
|
|
|
|
0x00000800, 0x08008e08, 0x08008e08
|
|
|
|
|
};
|
|
|
|
|
static const uint32_t df_correctable_long[MODES_MAX_BITERRORS + 1] = {
|
|
|
|
|
0x00060000, 0x066f0006, 0x6fff066f
|
|
|
|
|
};
|
|
|
|
|
|
Reduce CPU further in --no-fix-df mode. Add --enable-df24 option.
This reinstates the fastpath in the 2.4MHz demodulator that
aborts message demodulation early if the DF bits don't match a message
type that we know how to decode, or stops early if the DF bits can
only correspond to a short 56-bit message.
Do this in a more general form where we test against a set of valid
DF values, rather than a switch/case. Then populate the sets based on
the current error-correction settings (e.g. if we are allowed to repair
DF damage with 1 bit error correction, then a DF17 message could appear
with any of DF=17, DF=16, DF=19, DF=21, DF=25, or DF=1 and still be
correctable to a valid DF17 message)
In the default case this produces a small CPU improvement as short
messages might be able to stop earlier and a few DF values can be ignored
early. With --no-fix-df it produces a larger improvement as relatively few
DF values are valid in that mode.
To further reduce CPU, the default behaviour has changed to _not_
decode DF24 messages (Comm-D ELM messages). These are rarely seen in
the wild and dump1090 can't do anything useful with them. Disabling
them allows us to further reduce the set of valid DF values as they
effectively use all DF values from 24..31, 25% of all possible values.
To re-enable DF24 decoding, use the new `--enable-df24` option.
Finally, avoid doing some CRC calculations twice. This was only happening
once per valid decoded message, not per demodulation attempt, so it's not
such a large win.
2021-03-19 08:52:42 +00:00
|
|
|
*short_syndrome = UNCHECKED_SYNDROME;
|
|
|
|
|
*long_syndrome = UNCHECKED_SYNDROME;
|
|
|
|
|
|
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 11:43:38 +00:00
|
|
|
// Try to correct, including corrections to the initial 5 bit DF field
|
|
|
|
|
// that determines message format
|
|
|
|
|
|
|
|
|
|
const unsigned uncorrected_df = getbits(in, 1, 5);
|
|
|
|
|
const uint32_t df_bit = 1 << uncorrected_df;
|
|
|
|
|
|
2021-03-08 06:23:35 +00:00
|
|
|
// Select the right bitset based on the maximum number of bit errors in the DF field that we could correct.
|
|
|
|
|
// nb: strictly speaking, --no-fix-df doesn't _entirely_ disable correction of the DF field when nfix_crc == 2
|
|
|
|
|
// (DF17 could be corrected to DF18 or vice versa), but it does disable the CPU hungry part of it.
|
|
|
|
|
const unsigned fix_df_bits = (Modes.fix_df ? Modes.nfix_crc : 0);
|
|
|
|
|
|
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 11:43:38 +00:00
|
|
|
struct errorinfo *long_ei = NULL;
|
2021-03-08 06:23:35 +00:00
|
|
|
if (df_correctable_long[fix_df_bits] & df_bit) {
|
Reduce CPU further in --no-fix-df mode. Add --enable-df24 option.
This reinstates the fastpath in the 2.4MHz demodulator that
aborts message demodulation early if the DF bits don't match a message
type that we know how to decode, or stops early if the DF bits can
only correspond to a short 56-bit message.
Do this in a more general form where we test against a set of valid
DF values, rather than a switch/case. Then populate the sets based on
the current error-correction settings (e.g. if we are allowed to repair
DF damage with 1 bit error correction, then a DF17 message could appear
with any of DF=17, DF=16, DF=19, DF=21, DF=25, or DF=1 and still be
correctable to a valid DF17 message)
In the default case this produces a small CPU improvement as short
messages might be able to stop earlier and a few DF values can be ignored
early. With --no-fix-df it produces a larger improvement as relatively few
DF values are valid in that mode.
To further reduce CPU, the default behaviour has changed to _not_
decode DF24 messages (Comm-D ELM messages). These are rarely seen in
the wild and dump1090 can't do anything useful with them. Disabling
them allows us to further reduce the set of valid DF values as they
effectively use all DF values from 24..31, 25% of all possible values.
To re-enable DF24 decoding, use the new `--enable-df24` option.
Finally, avoid doing some CRC calculations twice. This was only happening
once per valid decoded message, not per demodulation attempt, so it's not
such a large win.
2021-03-19 08:52:42 +00:00
|
|
|
*long_syndrome = modesChecksum(in, MODES_LONG_MSG_BITS);
|
|
|
|
|
if (isLongPIMessage(in) && *long_syndrome == 0) {
|
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 11:43:38 +00:00
|
|
|
// DF17/18 message with correct checksum
|
|
|
|
|
memcpy(out, in, MODES_LONG_MSG_BYTES);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2015-01-21 12:55:24 +00:00
|
|
|
|
Reduce CPU further in --no-fix-df mode. Add --enable-df24 option.
This reinstates the fastpath in the 2.4MHz demodulator that
aborts message demodulation early if the DF bits don't match a message
type that we know how to decode, or stops early if the DF bits can
only correspond to a short 56-bit message.
Do this in a more general form where we test against a set of valid
DF values, rather than a switch/case. Then populate the sets based on
the current error-correction settings (e.g. if we are allowed to repair
DF damage with 1 bit error correction, then a DF17 message could appear
with any of DF=17, DF=16, DF=19, DF=21, DF=25, or DF=1 and still be
correctable to a valid DF17 message)
In the default case this produces a small CPU improvement as short
messages might be able to stop earlier and a few DF values can be ignored
early. With --no-fix-df it produces a larger improvement as relatively few
DF values are valid in that mode.
To further reduce CPU, the default behaviour has changed to _not_
decode DF24 messages (Comm-D ELM messages). These are rarely seen in
the wild and dump1090 can't do anything useful with them. Disabling
them allows us to further reduce the set of valid DF values as they
effectively use all DF values from 24..31, 25% of all possible values.
To re-enable DF24 decoding, use the new `--enable-df24` option.
Finally, avoid doing some CRC calculations twice. This was only happening
once per valid decoded message, not per demodulation attempt, so it's not
such a large win.
2021-03-19 08:52:42 +00:00
|
|
|
long_ei = modesChecksumDiagnose(*long_syndrome, MODES_LONG_MSG_BITS);
|
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 11:43:38 +00:00
|
|
|
}
|
2015-01-21 12:55:24 +00:00
|
|
|
|
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 11:43:38 +00:00
|
|
|
struct errorinfo *short_ei = NULL;
|
2021-03-08 06:23:35 +00:00
|
|
|
if (df_correctable_short[fix_df_bits] & df_bit) {
|
Reduce CPU further in --no-fix-df mode. Add --enable-df24 option.
This reinstates the fastpath in the 2.4MHz demodulator that
aborts message demodulation early if the DF bits don't match a message
type that we know how to decode, or stops early if the DF bits can
only correspond to a short 56-bit message.
Do this in a more general form where we test against a set of valid
DF values, rather than a switch/case. Then populate the sets based on
the current error-correction settings (e.g. if we are allowed to repair
DF damage with 1 bit error correction, then a DF17 message could appear
with any of DF=17, DF=16, DF=19, DF=21, DF=25, or DF=1 and still be
correctable to a valid DF17 message)
In the default case this produces a small CPU improvement as short
messages might be able to stop earlier and a few DF values can be ignored
early. With --no-fix-df it produces a larger improvement as relatively few
DF values are valid in that mode.
To further reduce CPU, the default behaviour has changed to _not_
decode DF24 messages (Comm-D ELM messages). These are rarely seen in
the wild and dump1090 can't do anything useful with them. Disabling
them allows us to further reduce the set of valid DF values as they
effectively use all DF values from 24..31, 25% of all possible values.
To re-enable DF24 decoding, use the new `--enable-df24` option.
Finally, avoid doing some CRC calculations twice. This was only happening
once per valid decoded message, not per demodulation attempt, so it's not
such a large win.
2021-03-19 08:52:42 +00:00
|
|
|
*short_syndrome = modesChecksum(in, MODES_SHORT_MSG_BITS);
|
|
|
|
|
if (isShortPIMessage(in) && (*short_syndrome & 0xFFFF80) == 0) {
|
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 11:43:38 +00:00
|
|
|
// DF11 message with correct checksum
|
|
|
|
|
// (low 7 bits may be IID)
|
|
|
|
|
memcpy(out, in, MODES_SHORT_MSG_BYTES);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2015-01-21 12:55:24 +00:00
|
|
|
|
Reduce CPU further in --no-fix-df mode. Add --enable-df24 option.
This reinstates the fastpath in the 2.4MHz demodulator that
aborts message demodulation early if the DF bits don't match a message
type that we know how to decode, or stops early if the DF bits can
only correspond to a short 56-bit message.
Do this in a more general form where we test against a set of valid
DF values, rather than a switch/case. Then populate the sets based on
the current error-correction settings (e.g. if we are allowed to repair
DF damage with 1 bit error correction, then a DF17 message could appear
with any of DF=17, DF=16, DF=19, DF=21, DF=25, or DF=1 and still be
correctable to a valid DF17 message)
In the default case this produces a small CPU improvement as short
messages might be able to stop earlier and a few DF values can be ignored
early. With --no-fix-df it produces a larger improvement as relatively few
DF values are valid in that mode.
To further reduce CPU, the default behaviour has changed to _not_
decode DF24 messages (Comm-D ELM messages). These are rarely seen in
the wild and dump1090 can't do anything useful with them. Disabling
them allows us to further reduce the set of valid DF values as they
effectively use all DF values from 24..31, 25% of all possible values.
To re-enable DF24 decoding, use the new `--enable-df24` option.
Finally, avoid doing some CRC calculations twice. This was only happening
once per valid decoded message, not per demodulation attempt, so it's not
such a large win.
2021-03-19 08:52:42 +00:00
|
|
|
short_ei = modesChecksumDiagnose(*short_syndrome, MODES_SHORT_MSG_BITS); // assume IID == 0
|
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 11:43:38 +00:00
|
|
|
}
|
2015-01-21 12:55:24 +00:00
|
|
|
|
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 11:43:38 +00:00
|
|
|
// Might be a damaged DF11/17/18, or might be another message type that doesn't have a full CRC
|
2015-01-21 12:55:24 +00:00
|
|
|
|
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 11:43:38 +00:00
|
|
|
unsigned long_errors = (long_ei ? long_ei->errors : 999);
|
|
|
|
|
unsigned short_errors = (short_ei ? short_ei->errors : 999);
|
2015-01-21 12:55:24 +00:00
|
|
|
|
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 11:43:38 +00:00
|
|
|
// If both 56-bit and 112-bit corrections are possible:
|
|
|
|
|
// try the correction with fewer error bits first
|
|
|
|
|
// if there's a tie, try the 112-bit version first
|
2015-01-21 12:55:24 +00:00
|
|
|
|
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 11:43:38 +00:00
|
|
|
if (long_ei && long_errors <= short_errors) {
|
|
|
|
|
memcpy(out, in, MODES_LONG_MSG_BYTES);
|
|
|
|
|
modesChecksumFix(out, long_ei);
|
|
|
|
|
if (isLongPIMessage(out)) {
|
|
|
|
|
// valid DF17/18 message after corrections
|
|
|
|
|
return long_errors;
|
|
|
|
|
}
|
|
|
|
|
}
|
2015-01-21 12:55:24 +00:00
|
|
|
|
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 11:43:38 +00:00
|
|
|
// Don't try to correct >1 error in DF11 (see crc.c)
|
|
|
|
|
if (short_ei && short_errors == 1) {
|
|
|
|
|
memcpy(out, in, MODES_SHORT_MSG_BYTES);
|
|
|
|
|
modesChecksumFix(out, short_ei);
|
|
|
|
|
if (isShortPIMessage(out)) {
|
|
|
|
|
// valid DF11 message after corrections
|
|
|
|
|
return short_errors;
|
|
|
|
|
}
|
|
|
|
|
}
|
2015-01-21 12:55:24 +00:00
|
|
|
|
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 11:43:38 +00:00
|
|
|
if (long_ei && long_errors > short_errors) {
|
|
|
|
|
memcpy(out, in, MODES_LONG_MSG_BYTES);
|
|
|
|
|
modesChecksumFix(out, long_ei);
|
|
|
|
|
if (isLongPIMessage(out)) {
|
|
|
|
|
// valid DF17/18 message after corrections
|
|
|
|
|
return long_errors;
|
|
|
|
|
}
|
|
|
|
|
}
|
2015-01-21 12:55:24 +00:00
|
|
|
|
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 11:43:38 +00:00
|
|
|
// Nothing more to try, we can't correct this one further
|
|
|
|
|
memcpy(out, in, MODES_LONG_MSG_BYTES);
|
|
|
|
|
return -1;
|
|
|
|
|
}
|
2015-06-28 23:45:33 +00:00
|
|
|
|
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 11:43:38 +00:00
|
|
|
// Score how plausible this ModeS message looks.
|
|
|
|
|
// The more positive, the more reliable the message is.
|
|
|
|
|
score_rank scoreModesMessage(const unsigned char *uncorrected)
|
|
|
|
|
{
|
|
|
|
|
// This is a "valid" DF0 message, but it's not useful; we discard these messages
|
|
|
|
|
static const unsigned char all_zeros[MODES_SHORT_MSG_BYTES] = { 0, 0, 0, 0, 0, 0, 0 };
|
Reduce CPU further in --no-fix-df mode. Add --enable-df24 option.
This reinstates the fastpath in the 2.4MHz demodulator that
aborts message demodulation early if the DF bits don't match a message
type that we know how to decode, or stops early if the DF bits can
only correspond to a short 56-bit message.
Do this in a more general form where we test against a set of valid
DF values, rather than a switch/case. Then populate the sets based on
the current error-correction settings (e.g. if we are allowed to repair
DF damage with 1 bit error correction, then a DF17 message could appear
with any of DF=17, DF=16, DF=19, DF=21, DF=25, or DF=1 and still be
correctable to a valid DF17 message)
In the default case this produces a small CPU improvement as short
messages might be able to stop earlier and a few DF values can be ignored
early. With --no-fix-df it produces a larger improvement as relatively few
DF values are valid in that mode.
To further reduce CPU, the default behaviour has changed to _not_
decode DF24 messages (Comm-D ELM messages). These are rarely seen in
the wild and dump1090 can't do anything useful with them. Disabling
them allows us to further reduce the set of valid DF values as they
effectively use all DF values from 24..31, 25% of all possible values.
To re-enable DF24 decoding, use the new `--enable-df24` option.
Finally, avoid doing some CRC calculations twice. This was only happening
once per valid decoded message, not per demodulation attempt, so it's not
such a large win.
2021-03-19 08:52:42 +00:00
|
|
|
if (!memcmp(all_zeros, uncorrected, sizeof(all_zeros)))
|
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 11:43:38 +00:00
|
|
|
return SR_ALL_ZEROS;
|
|
|
|
|
|
Reduce CPU further in --no-fix-df mode. Add --enable-df24 option.
This reinstates the fastpath in the 2.4MHz demodulator that
aborts message demodulation early if the DF bits don't match a message
type that we know how to decode, or stops early if the DF bits can
only correspond to a short 56-bit message.
Do this in a more general form where we test against a set of valid
DF values, rather than a switch/case. Then populate the sets based on
the current error-correction settings (e.g. if we are allowed to repair
DF damage with 1 bit error correction, then a DF17 message could appear
with any of DF=17, DF=16, DF=19, DF=21, DF=25, or DF=1 and still be
correctable to a valid DF17 message)
In the default case this produces a small CPU improvement as short
messages might be able to stop earlier and a few DF values can be ignored
early. With --no-fix-df it produces a larger improvement as relatively few
DF values are valid in that mode.
To further reduce CPU, the default behaviour has changed to _not_
decode DF24 messages (Comm-D ELM messages). These are rarely seen in
the wild and dump1090 can't do anything useful with them. Disabling
them allows us to further reduce the set of valid DF values as they
effectively use all DF values from 24..31, 25% of all possible values.
To re-enable DF24 decoding, use the new `--enable-df24` option.
Finally, avoid doing some CRC calculations twice. This was only happening
once per valid decoded message, not per demodulation attempt, so it's not
such a large win.
2021-03-19 08:52:42 +00:00
|
|
|
// try to produce a corrected DF11/17/18, including correcting the DF bits
|
|
|
|
|
unsigned char corrected[14];
|
|
|
|
|
uint32_t short_syndrome, long_syndrome;
|
|
|
|
|
int corrections = correctMessage(uncorrected, corrected, &short_syndrome, &long_syndrome);
|
|
|
|
|
|
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 11:43:38 +00:00
|
|
|
unsigned df = getbits(corrected, 1, 5); // Downlink Format
|
|
|
|
|
switch (df) {
|
|
|
|
|
case 0: // short air-air surveillance
|
|
|
|
|
case 4: // surveillance, altitude reply
|
|
|
|
|
case 5: // surveillance, altitude reply
|
|
|
|
|
{
|
Reduce CPU further in --no-fix-df mode. Add --enable-df24 option.
This reinstates the fastpath in the 2.4MHz demodulator that
aborts message demodulation early if the DF bits don't match a message
type that we know how to decode, or stops early if the DF bits can
only correspond to a short 56-bit message.
Do this in a more general form where we test against a set of valid
DF values, rather than a switch/case. Then populate the sets based on
the current error-correction settings (e.g. if we are allowed to repair
DF damage with 1 bit error correction, then a DF17 message could appear
with any of DF=17, DF=16, DF=19, DF=21, DF=25, or DF=1 and still be
correctable to a valid DF17 message)
In the default case this produces a small CPU improvement as short
messages might be able to stop earlier and a few DF values can be ignored
early. With --no-fix-df it produces a larger improvement as relatively few
DF values are valid in that mode.
To further reduce CPU, the default behaviour has changed to _not_
decode DF24 messages (Comm-D ELM messages). These are rarely seen in
the wild and dump1090 can't do anything useful with them. Disabling
them allows us to further reduce the set of valid DF values as they
effectively use all DF values from 24..31, 25% of all possible values.
To re-enable DF24 decoding, use the new `--enable-df24` option.
Finally, avoid doing some CRC calculations twice. This was only happening
once per valid decoded message, not per demodulation attempt, so it's not
such a large win.
2021-03-19 08:52:42 +00:00
|
|
|
if (short_syndrome == UNCHECKED_SYNDROME)
|
|
|
|
|
short_syndrome = modesChecksum(corrected, MODES_SHORT_MSG_BITS);
|
|
|
|
|
bool recent = icaoFilterTest(short_syndrome);
|
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 11:43:38 +00:00
|
|
|
return recent ? SR_UNRELIABLE_KNOWN : SR_UNRELIABLE_UNKNOWN;
|
|
|
|
|
}
|
2015-01-21 12:55:24 +00:00
|
|
|
|
|
|
|
|
case 16: // long air-air surveillance
|
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 11:43:38 +00:00
|
|
|
case 20: // Comm-B, altitude reply
|
|
|
|
|
case 21: // Comm-B, identity reply
|
Reduce CPU further in --no-fix-df mode. Add --enable-df24 option.
This reinstates the fastpath in the 2.4MHz demodulator that
aborts message demodulation early if the DF bits don't match a message
type that we know how to decode, or stops early if the DF bits can
only correspond to a short 56-bit message.
Do this in a more general form where we test against a set of valid
DF values, rather than a switch/case. Then populate the sets based on
the current error-correction settings (e.g. if we are allowed to repair
DF damage with 1 bit error correction, then a DF17 message could appear
with any of DF=17, DF=16, DF=19, DF=21, DF=25, or DF=1 and still be
correctable to a valid DF17 message)
In the default case this produces a small CPU improvement as short
messages might be able to stop earlier and a few DF values can be ignored
early. With --no-fix-df it produces a larger improvement as relatively few
DF values are valid in that mode.
To further reduce CPU, the default behaviour has changed to _not_
decode DF24 messages (Comm-D ELM messages). These are rarely seen in
the wild and dump1090 can't do anything useful with them. Disabling
them allows us to further reduce the set of valid DF values as they
effectively use all DF values from 24..31, 25% of all possible values.
To re-enable DF24 decoding, use the new `--enable-df24` option.
Finally, avoid doing some CRC calculations twice. This was only happening
once per valid decoded message, not per demodulation attempt, so it's not
such a large win.
2021-03-19 08:52:42 +00:00
|
|
|
{
|
|
|
|
|
if (long_syndrome == UNCHECKED_SYNDROME)
|
|
|
|
|
long_syndrome = modesChecksum(corrected, MODES_LONG_MSG_BITS);
|
|
|
|
|
bool recent = icaoFilterTest(long_syndrome);
|
|
|
|
|
return recent ? SR_UNRELIABLE_KNOWN : SR_UNRELIABLE_UNKNOWN;
|
|
|
|
|
}
|
|
|
|
|
|
2015-01-21 12:55:24 +00:00
|
|
|
case 24: // Comm-D (ELM)
|
2016-08-26 10:33:36 +00:00
|
|
|
case 25: // Comm-D (ELM)
|
|
|
|
|
case 26: // Comm-D (ELM)
|
|
|
|
|
case 27: // Comm-D (ELM)
|
|
|
|
|
case 28: // Comm-D (ELM)
|
|
|
|
|
case 29: // Comm-D (ELM)
|
|
|
|
|
case 30: // Comm-D (ELM)
|
|
|
|
|
case 31: // Comm-D (ELM)
|
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 11:43:38 +00:00
|
|
|
{
|
Reduce CPU further in --no-fix-df mode. Add --enable-df24 option.
This reinstates the fastpath in the 2.4MHz demodulator that
aborts message demodulation early if the DF bits don't match a message
type that we know how to decode, or stops early if the DF bits can
only correspond to a short 56-bit message.
Do this in a more general form where we test against a set of valid
DF values, rather than a switch/case. Then populate the sets based on
the current error-correction settings (e.g. if we are allowed to repair
DF damage with 1 bit error correction, then a DF17 message could appear
with any of DF=17, DF=16, DF=19, DF=21, DF=25, or DF=1 and still be
correctable to a valid DF17 message)
In the default case this produces a small CPU improvement as short
messages might be able to stop earlier and a few DF values can be ignored
early. With --no-fix-df it produces a larger improvement as relatively few
DF values are valid in that mode.
To further reduce CPU, the default behaviour has changed to _not_
decode DF24 messages (Comm-D ELM messages). These are rarely seen in
the wild and dump1090 can't do anything useful with them. Disabling
them allows us to further reduce the set of valid DF values as they
effectively use all DF values from 24..31, 25% of all possible values.
To re-enable DF24 decoding, use the new `--enable-df24` option.
Finally, avoid doing some CRC calculations twice. This was only happening
once per valid decoded message, not per demodulation attempt, so it's not
such a large win.
2021-03-19 08:52:42 +00:00
|
|
|
if (!Modes.enable_df24)
|
|
|
|
|
return SR_UNCORRECTABLE;
|
|
|
|
|
if (long_syndrome == UNCHECKED_SYNDROME)
|
|
|
|
|
long_syndrome = modesChecksum(corrected, MODES_LONG_MSG_BITS);
|
|
|
|
|
bool recent = icaoFilterTest(long_syndrome);
|
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 11:43:38 +00:00
|
|
|
return recent ? SR_UNRELIABLE_KNOWN : SR_UNRELIABLE_UNKNOWN;
|
2019-12-02 13:27:18 +00:00
|
|
|
}
|
|
|
|
|
|
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 11:43:38 +00:00
|
|
|
case 11:
|
|
|
|
|
{
|
|
|
|
|
// DF11 All-call reply
|
|
|
|
|
uint32_t addr = getbits(corrected, 9, 32);
|
Reduce CPU further in --no-fix-df mode. Add --enable-df24 option.
This reinstates the fastpath in the 2.4MHz demodulator that
aborts message demodulation early if the DF bits don't match a message
type that we know how to decode, or stops early if the DF bits can
only correspond to a short 56-bit message.
Do this in a more general form where we test against a set of valid
DF values, rather than a switch/case. Then populate the sets based on
the current error-correction settings (e.g. if we are allowed to repair
DF damage with 1 bit error correction, then a DF17 message could appear
with any of DF=17, DF=16, DF=19, DF=21, DF=25, or DF=1 and still be
correctable to a valid DF17 message)
In the default case this produces a small CPU improvement as short
messages might be able to stop earlier and a few DF values can be ignored
early. With --no-fix-df it produces a larger improvement as relatively few
DF values are valid in that mode.
To further reduce CPU, the default behaviour has changed to _not_
decode DF24 messages (Comm-D ELM messages). These are rarely seen in
the wild and dump1090 can't do anything useful with them. Disabling
them allows us to further reduce the set of valid DF values as they
effectively use all DF values from 24..31, 25% of all possible values.
To re-enable DF24 decoding, use the new `--enable-df24` option.
Finally, avoid doing some CRC calculations twice. This was only happening
once per valid decoded message, not per demodulation attempt, so it's not
such a large win.
2021-03-19 08:52:42 +00:00
|
|
|
if (short_syndrome == UNCHECKED_SYNDROME)
|
|
|
|
|
short_syndrome = modesChecksum(corrected, MODES_SHORT_MSG_BITS);
|
|
|
|
|
uint32_t iid = short_syndrome & 0x7F;
|
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 11:43:38 +00:00
|
|
|
bool recent = icaoFilterTest(addr);
|
|
|
|
|
|
|
|
|
|
switch (corrections) {
|
|
|
|
|
case 0:
|
|
|
|
|
if (iid == 0)
|
|
|
|
|
return recent ? SR_DF11_ACQ_KNOWN : SR_DF11_ACQ_UNKNOWN;
|
|
|
|
|
else
|
|
|
|
|
return recent ? SR_DF11_IID_KNOWN : SR_DF11_IID_UNKNOWN;
|
|
|
|
|
case 1:
|
|
|
|
|
if (iid == 0)
|
|
|
|
|
return recent ? SR_DF11_ACQ_1ERROR_KNOWN : SR_DF11_ACQ_1ERROR_UNKNOWN;
|
|
|
|
|
else
|
|
|
|
|
return recent ? SR_DF11_IID_1ERROR_KNOWN : SR_DF11_IID_1ERROR_UNKNOWN;
|
|
|
|
|
default:
|
|
|
|
|
return SR_UNCORRECTABLE;
|
|
|
|
|
}
|
2015-01-21 12:55:24 +00:00
|
|
|
}
|
2017-06-15 17:16:51 +00:00
|
|
|
|
2015-01-21 12:55:24 +00:00
|
|
|
case 17: // Extended squitter
|
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 11:43:38 +00:00
|
|
|
{
|
|
|
|
|
uint32_t addr = getbits(corrected, 9, 32);
|
|
|
|
|
bool recent = icaoFilterTest(addr);
|
|
|
|
|
|
|
|
|
|
switch (corrections) {
|
|
|
|
|
case 0:
|
|
|
|
|
return recent ? SR_DF17_KNOWN : SR_DF17_UNKNOWN;
|
|
|
|
|
case 1:
|
|
|
|
|
return recent ? SR_DF17_1ERROR_KNOWN : SR_DF17_1ERROR_UNKNOWN;
|
|
|
|
|
case 2:
|
|
|
|
|
return recent ? SR_DF17_2ERROR_KNOWN : SR_DF17_2ERROR_UNKNOWN;
|
|
|
|
|
default:
|
|
|
|
|
return SR_UNCORRECTABLE;
|
|
|
|
|
}
|
|
|
|
|
}
|
2015-01-21 12:55:24 +00:00
|
|
|
|
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 11:43:38 +00:00
|
|
|
case 18: // Extended squitter/non-transponder
|
|
|
|
|
{
|
|
|
|
|
uint32_t addr = getbits(corrected, 9, 32);
|
|
|
|
|
bool recent = icaoFilterTest(addr | ICAO_FILTER_ADSB_NT); // only look for previous DF18 activity
|
|
|
|
|
|
|
|
|
|
switch (corrections) {
|
|
|
|
|
case 0:
|
|
|
|
|
return recent ? SR_DF18_KNOWN : SR_DF18_UNKNOWN;
|
|
|
|
|
case 1:
|
|
|
|
|
return recent ? SR_DF18_1ERROR_KNOWN : SR_DF18_1ERROR_UNKNOWN;
|
|
|
|
|
case 2:
|
|
|
|
|
return recent ? SR_DF18_2ERROR_KNOWN : SR_DF18_2ERROR_UNKNOWN;
|
|
|
|
|
default:
|
|
|
|
|
return SR_UNCORRECTABLE;
|
|
|
|
|
}
|
|
|
|
|
}
|
2015-01-21 12:55:24 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
default:
|
|
|
|
|
// unknown message type
|
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 11:43:38 +00:00
|
|
|
return SR_UNKNOWN_DF;
|
2015-01-21 12:55:24 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
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 11:43:38 +00:00
|
|
|
static const char *score_to_string(score_rank score)
|
|
|
|
|
{
|
|
|
|
|
switch (score) {
|
|
|
|
|
case SR_NOT_SET: return "NOT_SET";
|
|
|
|
|
case SR_UNKNOWN_THRESHOLD: return "UNKNOWN_THRESHOLD";
|
|
|
|
|
case SR_ACCEPT_THRESHOLD: return "ACCEPT_THRESHOLD";
|
|
|
|
|
|
|
|
|
|
case SR_ALL_ZEROS: return "ALL_ZEROS";
|
|
|
|
|
case SR_UNKNOWN_DF: return "UNKNOWN_DF";
|
|
|
|
|
case SR_UNCORRECTABLE: return "UNCORRECTABLE";
|
|
|
|
|
|
|
|
|
|
case SR_UNRELIABLE_UNKNOWN: return "UNRELIABLE_UNKNOWN";
|
|
|
|
|
case SR_UNRELIABLE_KNOWN: return "UNRELIABLE_KNOWN";
|
|
|
|
|
|
|
|
|
|
case SR_DF11_IID_1ERROR_UNKNOWN: return "DF11_IID_1ERROR_UNKNOWN";
|
|
|
|
|
case SR_DF11_ACQ_1ERROR_UNKNOWN: return "DF11_ACQ_1ERROR_UNKNOWN";
|
|
|
|
|
case SR_DF11_IID_UNKNOWN: return "DF11_IID_UNKNOWN";
|
|
|
|
|
case SR_DF11_ACQ_UNKNOWN: return "DF11_ACQ_UNKNOWN";
|
|
|
|
|
case SR_DF11_IID_1ERROR_KNOWN: return "DF11_IID_1ERROR_KNOWN";
|
|
|
|
|
case SR_DF11_ACQ_1ERROR_KNOWN: return "DF11_ACQ_1ERROR_KNOWN";
|
|
|
|
|
case SR_DF11_IID_KNOWN: return "DF11_IID_KNOWN";
|
|
|
|
|
case SR_DF11_ACQ_KNOWN: return "DF11_ACQ_KNOWN";
|
|
|
|
|
|
|
|
|
|
case SR_DF17_2ERROR_UNKNOWN: return "DF17_2ERROR_UNKNOWN";
|
|
|
|
|
case SR_DF17_2ERROR_KNOWN: return "DF17_2ERROR_KNOWN";
|
|
|
|
|
case SR_DF17_1ERROR_UNKNOWN: return "DF17_1ERROR_UNKNOWN";
|
|
|
|
|
case SR_DF17_1ERROR_KNOWN: return "DF17_1ERROR_KNOWN";
|
|
|
|
|
case SR_DF17_UNKNOWN: return "DF17_UNKNOWN";
|
|
|
|
|
case SR_DF17_KNOWN: return "DF17_KNOWN";
|
|
|
|
|
|
|
|
|
|
case SR_DF18_2ERROR_UNKNOWN: return "DF18_2ERROR_UNKNOWN";
|
|
|
|
|
case SR_DF18_2ERROR_KNOWN: return "DF18_2ERROR_KNOWN";
|
|
|
|
|
case SR_DF18_1ERROR_UNKNOWN: return "DF18_1ERROR_UNKNOWN";
|
|
|
|
|
case SR_DF18_1ERROR_KNOWN: return "DF18_1ERROR_KNOWN";
|
|
|
|
|
case SR_DF18_UNKNOWN: return "DF18_UNKNOWN";
|
|
|
|
|
case SR_DF18_KNOWN: return "DF18_KNOWN";
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return "<bad value>";
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void decodeExtendedSquitter(struct modesMessage *mm);
|
|
|
|
|
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
//
|
|
|
|
|
//=========================================================================
|
|
|
|
|
//
|
2017-06-15 17:16:51 +00:00
|
|
|
// Decode a raw Mode S message demodulated as a stream of bytes by detectModeS(),
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
// and split it into fields populating a modesMessage structure.
|
|
|
|
|
//
|
2015-01-22 19:49:19 +00:00
|
|
|
// return 0 if all OK
|
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 11:43:38 +00:00
|
|
|
// <0 if it's a bad message
|
|
|
|
|
//
|
|
|
|
|
int decodeModesMessage(struct modesMessage *mm, const unsigned char *in)
|
2015-01-21 00:23:48 +00:00
|
|
|
{
|
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 11:43:38 +00:00
|
|
|
// score the message if needed (it might be coming off the network)
|
|
|
|
|
if (mm->score == SR_NOT_SET)
|
|
|
|
|
mm->score = scoreModesMessage(in);
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
|
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 11:43:38 +00:00
|
|
|
if (mm->score < SR_UNKNOWN_THRESHOLD)
|
|
|
|
|
return -1;
|
|
|
|
|
if (mm->score < SR_ACCEPT_THRESHOLD)
|
2016-09-14 15:11:31 +00:00
|
|
|
return -2;
|
|
|
|
|
|
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 11:43:38 +00:00
|
|
|
// Preserve the original uncorrected copy for later forwarding
|
|
|
|
|
memcpy(mm->verbatim, in, MODES_LONG_MSG_BYTES);
|
|
|
|
|
|
|
|
|
|
// Apply corrections to our local copy
|
Reduce CPU further in --no-fix-df mode. Add --enable-df24 option.
This reinstates the fastpath in the 2.4MHz demodulator that
aborts message demodulation early if the DF bits don't match a message
type that we know how to decode, or stops early if the DF bits can
only correspond to a short 56-bit message.
Do this in a more general form where we test against a set of valid
DF values, rather than a switch/case. Then populate the sets based on
the current error-correction settings (e.g. if we are allowed to repair
DF damage with 1 bit error correction, then a DF17 message could appear
with any of DF=17, DF=16, DF=19, DF=21, DF=25, or DF=1 and still be
correctable to a valid DF17 message)
In the default case this produces a small CPU improvement as short
messages might be able to stop earlier and a few DF values can be ignored
early. With --no-fix-df it produces a larger improvement as relatively few
DF values are valid in that mode.
To further reduce CPU, the default behaviour has changed to _not_
decode DF24 messages (Comm-D ELM messages). These are rarely seen in
the wild and dump1090 can't do anything useful with them. Disabling
them allows us to further reduce the set of valid DF values as they
effectively use all DF values from 24..31, 25% of all possible values.
To re-enable DF24 decoding, use the new `--enable-df24` option.
Finally, avoid doing some CRC calculations twice. This was only happening
once per valid decoded message, not per demodulation attempt, so it's not
such a large win.
2021-03-19 08:52:42 +00:00
|
|
|
uint32_t short_syndrome, long_syndrome;
|
|
|
|
|
int corrections = correctMessage(in, mm->msg, &short_syndrome, &long_syndrome);
|
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 11:43:38 +00:00
|
|
|
const unsigned char *msg = mm->msg;
|
|
|
|
|
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
// Get the message type ASAP as other operations depend on this
|
2016-09-01 21:10:17 +00:00
|
|
|
mm->msgtype = getbits(msg, 1, 5); // Downlink Format
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
mm->msgbits = modesMessageLenByType(mm->msgtype);
|
Reduce CPU further in --no-fix-df mode. Add --enable-df24 option.
This reinstates the fastpath in the 2.4MHz demodulator that
aborts message demodulation early if the DF bits don't match a message
type that we know how to decode, or stops early if the DF bits can
only correspond to a short 56-bit message.
Do this in a more general form where we test against a set of valid
DF values, rather than a switch/case. Then populate the sets based on
the current error-correction settings (e.g. if we are allowed to repair
DF damage with 1 bit error correction, then a DF17 message could appear
with any of DF=17, DF=16, DF=19, DF=21, DF=25, or DF=1 and still be
correctable to a valid DF17 message)
In the default case this produces a small CPU improvement as short
messages might be able to stop earlier and a few DF values can be ignored
early. With --no-fix-df it produces a larger improvement as relatively few
DF values are valid in that mode.
To further reduce CPU, the default behaviour has changed to _not_
decode DF24 messages (Comm-D ELM messages). These are rarely seen in
the wild and dump1090 can't do anything useful with them. Disabling
them allows us to further reduce the set of valid DF values as they
effectively use all DF values from 24..31, 25% of all possible values.
To re-enable DF24 decoding, use the new `--enable-df24` option.
Finally, avoid doing some CRC calculations twice. This was only happening
once per valid decoded message, not per demodulation attempt, so it's not
such a large win.
2021-03-19 08:52:42 +00:00
|
|
|
if (mm->msgtype & 16) {
|
|
|
|
|
if (long_syndrome == UNCHECKED_SYNDROME)
|
|
|
|
|
long_syndrome = modesChecksum(mm->msg, MODES_LONG_MSG_BITS);
|
|
|
|
|
mm->crc = long_syndrome;
|
|
|
|
|
} else {
|
|
|
|
|
if (short_syndrome == UNCHECKED_SYNDROME)
|
|
|
|
|
short_syndrome = modesChecksum(mm->msg, MODES_SHORT_MSG_BITS);
|
|
|
|
|
mm->crc = short_syndrome;
|
|
|
|
|
}
|
|
|
|
|
|
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 11:43:38 +00:00
|
|
|
mm->correctedbits = corrections > 0 ? corrections : 0;
|
2015-01-22 11:13:54 +00:00
|
|
|
mm->addr = 0;
|
2015-01-21 00:23:48 +00:00
|
|
|
|
|
|
|
|
// Do checksum work and set fields that depend on the CRC
|
|
|
|
|
switch (mm->msgtype) {
|
|
|
|
|
case 0: // short air-air surveillance
|
|
|
|
|
case 4: // surveillance, altitude reply
|
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 11:43:38 +00:00
|
|
|
case 5: // surveillance, identity reply
|
2015-01-21 00:23:48 +00:00
|
|
|
case 16: // long air-air surveillance
|
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 11:43:38 +00:00
|
|
|
// These message types use Address/Parity
|
|
|
|
|
// so we can't check the CRC and must infer the transmitter's address
|
2016-08-27 13:34:14 +00:00
|
|
|
mm->source = SOURCE_MODE_S;
|
2015-01-21 00:23:48 +00:00
|
|
|
mm->addr = mm->crc;
|
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 11:43:38 +00:00
|
|
|
mm->reliable = 0;
|
2015-01-21 00:23:48 +00:00
|
|
|
break;
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
|
2015-01-21 00:23:48 +00:00
|
|
|
case 11: // All-call reply
|
|
|
|
|
// This message type uses Parity/Interrogator, i.e. our CRC syndrome is CL + IC from the uplink message
|
|
|
|
|
// which we can't see. So we don't know if the CRC is correct or not.
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
//
|
2015-01-21 00:23:48 +00:00
|
|
|
// however! CL + IC only occupy the lower 7 bits of the CRC. So if we ignore those bits when testing
|
|
|
|
|
// the CRC we can still try to detect/correct errors.
|
2016-08-27 13:34:14 +00:00
|
|
|
mm->IID = mm->crc & 0x7f;
|
|
|
|
|
mm->source = SOURCE_MODE_S_CHECKED;
|
2019-11-27 12:30:41 +00:00
|
|
|
mm->reliable = (mm->IID == 0 && mm->correctedbits == 0);
|
2015-01-21 00:23:48 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case 17: // Extended squitter
|
|
|
|
|
case 18: { // Extended squitter/non-transponder
|
|
|
|
|
// These message types use Parity/Interrogator, but are specified to set II=0
|
2016-08-27 13:34:14 +00:00
|
|
|
mm->source = SOURCE_ADSB; // TIS-B decoding will override this if needed
|
2019-11-27 12:30:41 +00:00
|
|
|
mm->reliable = (mm->correctedbits == 0);
|
2015-01-21 00:23:48 +00:00
|
|
|
break;
|
|
|
|
|
}
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
|
2015-01-21 00:23:48 +00:00
|
|
|
case 20: // Comm-B, altitude reply
|
|
|
|
|
case 21: // Comm-B, identity reply
|
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 11:43:38 +00:00
|
|
|
// These message types either use Address/Parity
|
2015-01-21 00:23:48 +00:00
|
|
|
// or Data Parity where the requested BDS is also xored into the top byte.
|
|
|
|
|
// So not only do we not know whether the CRC is right, we also don't know if
|
|
|
|
|
// the ICAO is right! Ow.
|
|
|
|
|
|
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 11:43:38 +00:00
|
|
|
mm->source = SOURCE_MODE_S;
|
|
|
|
|
mm->addr = mm->crc;
|
|
|
|
|
mm->reliable = 0;
|
|
|
|
|
break;
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
|
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 11:43:38 +00:00
|
|
|
case 24: // Comm-D (ELM)
|
|
|
|
|
case 25: // Comm-D (ELM)
|
|
|
|
|
case 26: // Comm-D (ELM)
|
|
|
|
|
case 27: // Comm-D (ELM)
|
|
|
|
|
case 28: // Comm-D (ELM)
|
|
|
|
|
case 29: // Comm-D (ELM)
|
|
|
|
|
case 30: // Comm-D (ELM)
|
|
|
|
|
case 31: // Comm-D (ELM)
|
|
|
|
|
// These messages use Address/Parity,
|
|
|
|
|
// and also use some of the DF bits to carry data. Remap them all to a single
|
|
|
|
|
// DF for simplicity.
|
|
|
|
|
mm->msgtype = 24;
|
|
|
|
|
mm->source = SOURCE_MODE_S;
|
|
|
|
|
mm->addr = mm->crc;
|
|
|
|
|
mm->reliable = 0;
|
|
|
|
|
break;
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
|
2015-01-21 00:23:48 +00:00
|
|
|
default:
|
|
|
|
|
// All other message types, we don't know how to handle their CRCs, give up
|
2015-01-22 19:49:19 +00:00
|
|
|
return -2;
|
2017-06-15 17:16:51 +00:00
|
|
|
}
|
2015-01-21 00:23:48 +00:00
|
|
|
|
|
|
|
|
// decode the bulk of the message
|
|
|
|
|
|
|
|
|
|
// AA (Address announced)
|
|
|
|
|
if (mm->msgtype == 11 || mm->msgtype == 17 || mm->msgtype == 18) {
|
2016-09-01 21:10:17 +00:00
|
|
|
mm->AA = mm->addr = getbits(msg, 9, 32);
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
}
|
|
|
|
|
|
2015-01-21 00:23:48 +00:00
|
|
|
// AC (Altitude Code)
|
|
|
|
|
if (mm->msgtype == 0 || mm->msgtype == 4 || mm->msgtype == 16 || mm->msgtype == 20) {
|
2016-09-01 21:10:17 +00:00
|
|
|
mm->AC = getbits(msg, 20, 32);
|
2016-08-27 13:34:14 +00:00
|
|
|
if (mm->AC) { // Only attempt to decode if a valid (non zero) altitude is present
|
2017-12-07 16:34:08 +00:00
|
|
|
mm->altitude_baro = decodeAC13Field(mm->AC, &mm->altitude_baro_unit);
|
|
|
|
|
if (mm->altitude_baro != INVALID_ALTITUDE)
|
|
|
|
|
mm->altitude_baro_valid = 1;
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2015-01-21 00:23:48 +00:00
|
|
|
// AF (DF19 Application Field) not decoded
|
|
|
|
|
|
|
|
|
|
// CA (Capability)
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
if (mm->msgtype == 11 || mm->msgtype == 17) {
|
2016-09-01 21:10:17 +00:00
|
|
|
mm->CA = getbits(msg, 6, 8);
|
2016-08-27 13:34:14 +00:00
|
|
|
|
|
|
|
|
switch (mm->CA) {
|
|
|
|
|
case 0:
|
|
|
|
|
mm->airground = AG_UNCERTAIN;
|
|
|
|
|
break;
|
|
|
|
|
case 4:
|
|
|
|
|
mm->airground = AG_GROUND;
|
|
|
|
|
break;
|
|
|
|
|
case 5:
|
|
|
|
|
mm->airground = AG_AIRBORNE;
|
|
|
|
|
break;
|
|
|
|
|
case 6:
|
|
|
|
|
mm->airground = AG_UNCERTAIN;
|
|
|
|
|
break;
|
|
|
|
|
case 7:
|
|
|
|
|
mm->airground = AG_UNCERTAIN;
|
|
|
|
|
break;
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
}
|
|
|
|
|
}
|
2015-01-21 00:23:48 +00:00
|
|
|
|
2016-08-27 13:34:14 +00:00
|
|
|
// CC (Cross-link capability)
|
|
|
|
|
if (mm->msgtype == 0) {
|
2016-09-01 21:10:17 +00:00
|
|
|
mm->CC = getbit(msg, 7);
|
2016-08-27 13:34:14 +00:00
|
|
|
}
|
2015-01-21 00:23:48 +00:00
|
|
|
|
2019-04-11 17:01:07 +00:00
|
|
|
// CF (Control field, see Figure 2-2 ADS-B Message BaselineFormat Structure)
|
2015-01-29 23:08:33 +00:00
|
|
|
if (mm->msgtype == 18) {
|
2019-04-11 17:01:07 +00:00
|
|
|
mm->CF = getbits(msg, 6, 8);
|
2015-01-29 23:08:33 +00:00
|
|
|
}
|
|
|
|
|
|
2016-08-27 13:34:14 +00:00
|
|
|
// DR (Downlink Request)
|
|
|
|
|
if (mm->msgtype == 4 || mm->msgtype == 5 || mm->msgtype == 20 || mm->msgtype == 21) {
|
2016-09-01 21:10:17 +00:00
|
|
|
mm->DR = getbits(msg, 9, 13);
|
2016-08-27 13:34:14 +00:00
|
|
|
}
|
2015-01-21 00:23:48 +00:00
|
|
|
|
|
|
|
|
// FS (Flight Status)
|
|
|
|
|
if (mm->msgtype == 4 || mm->msgtype == 5 || mm->msgtype == 20 || mm->msgtype == 21) {
|
2016-09-01 21:10:17 +00:00
|
|
|
mm->FS = getbits(msg, 6, 8);
|
2016-08-27 13:34:14 +00:00
|
|
|
mm->alert_valid = 1;
|
|
|
|
|
mm->spi_valid = 1;
|
|
|
|
|
|
|
|
|
|
switch (mm->FS) {
|
|
|
|
|
case 0:
|
|
|
|
|
mm->airground = AG_UNCERTAIN;
|
|
|
|
|
break;
|
|
|
|
|
case 1:
|
|
|
|
|
mm->airground = AG_GROUND;
|
|
|
|
|
break;
|
|
|
|
|
case 2:
|
|
|
|
|
mm->airground = AG_UNCERTAIN;
|
|
|
|
|
mm->alert = 1;
|
|
|
|
|
break;
|
|
|
|
|
case 3:
|
|
|
|
|
mm->airground = AG_GROUND;
|
|
|
|
|
mm->alert = 1;
|
|
|
|
|
break;
|
|
|
|
|
case 4:
|
|
|
|
|
mm->airground = AG_UNCERTAIN;
|
|
|
|
|
mm->alert = 1;
|
|
|
|
|
mm->spi = 1;
|
|
|
|
|
break;
|
|
|
|
|
case 5:
|
|
|
|
|
mm->airground = AG_UNCERTAIN;
|
|
|
|
|
mm->spi = 1;
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
mm->spi_valid = 0;
|
|
|
|
|
mm->alert_valid = 0;
|
|
|
|
|
break;
|
2015-01-21 00:23:48 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// ID (Identity)
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
if (mm->msgtype == 5 || mm->msgtype == 21) {
|
2015-01-21 00:23:48 +00:00
|
|
|
// Gillham encoded Squawk
|
2016-09-01 21:10:17 +00:00
|
|
|
mm->ID = getbits(msg, 20, 32);
|
2016-08-27 13:34:14 +00:00
|
|
|
if (mm->ID) {
|
|
|
|
|
mm->squawk = decodeID13Field(mm->ID);
|
|
|
|
|
mm->squawk_valid = 1;
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-08-27 13:34:14 +00:00
|
|
|
// KE (Control, ELM)
|
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 11:43:38 +00:00
|
|
|
if (mm->msgtype == 24) {
|
2016-09-01 21:10:17 +00:00
|
|
|
mm->KE = getbit(msg, 4);
|
2016-08-27 13:34:14 +00:00
|
|
|
}
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
|
2015-01-21 00:23:48 +00:00
|
|
|
// MB (messsage, Comm-B)
|
|
|
|
|
if (mm->msgtype == 20 || mm->msgtype == 21) {
|
2016-08-27 13:34:14 +00:00
|
|
|
memcpy(mm->MB, &msg[4], 7);
|
2015-01-21 00:23:48 +00:00
|
|
|
decodeCommB(mm);
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
}
|
|
|
|
|
|
2016-08-27 13:34:14 +00:00
|
|
|
// MD (message, Comm-D)
|
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 11:43:38 +00:00
|
|
|
if (mm->msgtype == 24) {
|
2016-08-27 13:34:14 +00:00
|
|
|
memcpy(mm->MD, &msg[1], 10);
|
|
|
|
|
}
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
|
2015-01-21 00:23:48 +00:00
|
|
|
// ME (message, extended squitter)
|
2016-08-27 13:34:14 +00:00
|
|
|
if (mm->msgtype == 17 || mm->msgtype == 18) {
|
|
|
|
|
memcpy(mm->ME, &msg[4], 7);
|
2015-01-29 23:08:33 +00:00
|
|
|
decodeExtendedSquitter(mm);
|
2015-01-21 00:23:48 +00:00
|
|
|
}
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
|
2016-08-27 13:34:14 +00:00
|
|
|
// MV (message, ACAS)
|
|
|
|
|
if (mm->msgtype == 16) {
|
|
|
|
|
memcpy(mm->MV, &msg[4], 7);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// ND (number of D-segment, Comm-D)
|
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 11:43:38 +00:00
|
|
|
if (mm->msgtype == 24) {
|
2016-09-01 21:10:17 +00:00
|
|
|
mm->ND = getbits(msg, 5, 8);
|
2016-08-27 13:34:14 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// RI (Reply information, ACAS)
|
|
|
|
|
if (mm->msgtype == 0 || mm->msgtype == 16) {
|
2016-09-01 21:10:17 +00:00
|
|
|
mm->RI = getbits(msg, 14, 17);
|
2016-08-27 13:34:14 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// SL (Sensitivity level, ACAS)
|
|
|
|
|
if (mm->msgtype == 0 || mm->msgtype == 16) {
|
2016-09-01 21:10:17 +00:00
|
|
|
mm->SL = getbits(msg, 9, 11);
|
2016-08-27 13:34:14 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// UM (Utility Message)
|
|
|
|
|
if (mm->msgtype == 4 || mm->msgtype == 5 || mm->msgtype == 20 || mm->msgtype == 21) {
|
2016-09-01 21:10:17 +00:00
|
|
|
mm->UM = getbits(msg, 14, 19);
|
2016-08-27 13:34:14 +00:00
|
|
|
}
|
2015-01-21 00:23:48 +00:00
|
|
|
|
|
|
|
|
// VS (Vertical Status)
|
|
|
|
|
if (mm->msgtype == 0 || mm->msgtype == 16) {
|
2016-09-01 21:10:17 +00:00
|
|
|
mm->VS = getbit(msg, 6);
|
2016-08-27 13:34:14 +00:00
|
|
|
if (mm->VS)
|
|
|
|
|
mm->airground = AG_GROUND;
|
|
|
|
|
else
|
|
|
|
|
mm->airground = AG_UNCERTAIN;
|
2015-01-21 00:23:48 +00:00
|
|
|
}
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
|
2019-01-21 20:11:12 +00:00
|
|
|
if (!mm->correctedbits && (mm->msgtype == 17 || (mm->msgtype == 11 && mm->IID == 0))) {
|
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 11:43:38 +00:00
|
|
|
// DF17 ADS-B or DF11 acquisition squitter. Mark as known Mode-S source
|
2015-01-29 23:08:33 +00:00
|
|
|
icaoFilterAdd(mm->addr);
|
|
|
|
|
}
|
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 11:43:38 +00:00
|
|
|
if (!mm->correctedbits && mm->msgtype == 18) {
|
|
|
|
|
// Mark as known ADS-B (NT) source
|
|
|
|
|
icaoFilterAdd(mm->addr | ICAO_FILTER_ADSB_NT);
|
|
|
|
|
}
|
2015-01-29 23:08:33 +00:00
|
|
|
|
2016-08-27 13:34:14 +00:00
|
|
|
// MLAT overrides all other sources
|
|
|
|
|
if (mm->remote && mm->timestampMsg == MAGIC_MLAT_TIMESTAMP)
|
|
|
|
|
mm->source = SOURCE_MLAT;
|
|
|
|
|
|
2015-01-21 00:23:48 +00:00
|
|
|
// all done
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
|
2016-09-01 22:13:31 +00:00
|
|
|
static void decodeESIdentAndCategory(struct modesMessage *mm)
|
|
|
|
|
{
|
|
|
|
|
// Aircraft Identification and Category
|
2016-08-29 10:11:04 +00:00
|
|
|
unsigned char *me = mm->ME;
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
|
2016-09-01 22:13:31 +00:00
|
|
|
mm->mesub = getbits(me, 6, 8);
|
2015-01-29 23:08:33 +00:00
|
|
|
|
2016-09-14 14:58:29 +00:00
|
|
|
mm->callsign[0] = ais_charset[getbits(me, 9, 14)];
|
|
|
|
|
mm->callsign[1] = ais_charset[getbits(me, 15, 20)];
|
|
|
|
|
mm->callsign[2] = ais_charset[getbits(me, 21, 26)];
|
|
|
|
|
mm->callsign[3] = ais_charset[getbits(me, 27, 32)];
|
|
|
|
|
mm->callsign[4] = ais_charset[getbits(me, 33, 38)];
|
|
|
|
|
mm->callsign[5] = ais_charset[getbits(me, 39, 44)];
|
|
|
|
|
mm->callsign[6] = ais_charset[getbits(me, 45, 50)];
|
|
|
|
|
mm->callsign[7] = ais_charset[getbits(me, 51, 56)];
|
2017-12-02 17:38:33 +00:00
|
|
|
mm->callsign[8] = 0;
|
2018-07-20 19:56:28 +00:00
|
|
|
mm->callsign_valid = 1;
|
|
|
|
|
|
|
|
|
|
// actually valid?
|
|
|
|
|
for (unsigned i = 0; i < 8; ++i) {
|
|
|
|
|
if (!(mm->callsign[i] >= 'A' && mm->callsign[i] <= 'Z') &&
|
|
|
|
|
!(mm->callsign[i] >= '0' && mm->callsign[i] <= '9') &&
|
|
|
|
|
mm->callsign[i] != ' ') {
|
|
|
|
|
// Bad callsign, ignore it
|
|
|
|
|
mm->callsign_valid = 0;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
2016-01-24 19:09:30 +00:00
|
|
|
|
2016-09-01 22:13:31 +00:00
|
|
|
mm->category = ((0x0E - mm->metype) << 4) | mm->mesub;
|
|
|
|
|
mm->category_valid = 1;
|
|
|
|
|
}
|
2016-01-24 19:09:30 +00:00
|
|
|
|
2016-09-14 15:37:07 +00:00
|
|
|
// Handle setting a non-ICAO address
|
|
|
|
|
static void setIMF(struct modesMessage *mm)
|
|
|
|
|
{
|
|
|
|
|
mm->addr |= MODES_NON_ICAO_ADDRESS;
|
|
|
|
|
switch (mm->addrtype) {
|
|
|
|
|
case ADDR_ADSB_ICAO:
|
|
|
|
|
case ADDR_ADSB_ICAO_NT:
|
2016-09-15 14:30:34 +00:00
|
|
|
// Shouldn't happen, but let's try to handle it
|
2016-09-14 15:37:07 +00:00
|
|
|
mm->addrtype = ADDR_ADSB_OTHER;
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case ADDR_TISB_ICAO:
|
2016-09-15 14:30:34 +00:00
|
|
|
mm->addrtype = ADDR_TISB_TRACKFILE;
|
2016-09-14 15:37:07 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case ADDR_ADSR_ICAO:
|
|
|
|
|
mm->addrtype = ADDR_ADSR_OTHER;
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
default:
|
|
|
|
|
// Nothing.
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-09-01 22:13:31 +00:00
|
|
|
static void decodeESAirborneVelocity(struct modesMessage *mm, int check_imf)
|
|
|
|
|
{
|
|
|
|
|
// Airborne Velocity Message
|
|
|
|
|
unsigned char *me = mm->ME;
|
2015-01-29 23:08:33 +00:00
|
|
|
|
2017-12-07 16:34:08 +00:00
|
|
|
// 1-5: ME type
|
|
|
|
|
// 6-8: ME subtype
|
2016-09-01 22:13:31 +00:00
|
|
|
mm->mesub = getbits(me, 6, 8);
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
|
2017-12-07 16:34:08 +00:00
|
|
|
if (mm->mesub < 1 || mm->mesub > 4)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
// 9: IMF or Intent Change
|
2016-09-01 22:13:31 +00:00
|
|
|
if (check_imf && getbit(me, 9))
|
2016-09-14 15:37:07 +00:00
|
|
|
setIMF(mm);
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
|
2017-12-07 16:34:08 +00:00
|
|
|
// 10: reserved
|
2015-01-29 23:08:33 +00:00
|
|
|
|
2017-12-07 16:34:08 +00:00
|
|
|
// 11-13: NACv (NUCr in v0, maps directly to NACv in v2)
|
|
|
|
|
mm->accuracy.nac_v_valid = 1;
|
|
|
|
|
mm->accuracy.nac_v = getbits(me, 11, 13);
|
2016-08-27 13:34:14 +00:00
|
|
|
|
2017-12-07 16:34:08 +00:00
|
|
|
// 14-35: speed/velocity depending on subtype
|
2016-09-01 22:13:31 +00:00
|
|
|
switch (mm->mesub) {
|
|
|
|
|
case 1: case 2:
|
|
|
|
|
{
|
2017-12-07 16:34:08 +00:00
|
|
|
// 14: E/W direction
|
|
|
|
|
// 15-24: E/W speed
|
|
|
|
|
// 25: N/S direction
|
|
|
|
|
// 26-35: N/S speed
|
2016-09-01 21:10:17 +00:00
|
|
|
unsigned ew_raw = getbits(me, 15, 24);
|
|
|
|
|
unsigned ns_raw = getbits(me, 26, 35);
|
2016-09-01 22:13:31 +00:00
|
|
|
|
2015-01-21 00:23:48 +00:00
|
|
|
if (ew_raw && ns_raw) {
|
2016-09-01 22:13:31 +00:00
|
|
|
int ew_vel = (ew_raw - 1) * (getbit(me, 14) ? -1 : 1) * ((mm->mesub == 2) ? 4 : 1);
|
|
|
|
|
int ns_vel = (ns_raw - 1) * (getbit(me, 25) ? -1 : 1) * ((mm->mesub == 2) ? 4 : 1);
|
2016-08-27 13:34:14 +00:00
|
|
|
|
2015-01-21 00:23:48 +00:00
|
|
|
// Compute velocity and angle from the two speed components
|
2017-12-07 16:34:08 +00:00
|
|
|
mm->gs.v0 = mm->gs.v2 = mm->gs.selected = sqrtf((ns_vel * ns_vel) + (ew_vel * ew_vel) + 0.5);
|
2017-06-15 17:07:40 +00:00
|
|
|
mm->gs_valid = 1;
|
2016-09-01 22:13:31 +00:00
|
|
|
|
2017-12-07 16:34:08 +00:00
|
|
|
if (mm->gs.selected > 0) {
|
2017-06-15 20:07:53 +00:00
|
|
|
float ground_track = atan2(ew_vel, ns_vel) * 180.0 / M_PI;
|
2015-01-21 00:23:48 +00:00
|
|
|
// We don't want negative values but a 0-360 scale
|
2017-06-15 20:07:53 +00:00
|
|
|
if (ground_track < 0)
|
|
|
|
|
ground_track += 360;
|
|
|
|
|
mm->heading = ground_track;
|
|
|
|
|
mm->heading_type = HEADING_GROUND_TRACK;
|
|
|
|
|
mm->heading_valid = 1;
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
}
|
2015-01-21 00:23:48 +00:00
|
|
|
}
|
2016-09-01 22:13:31 +00:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
case 3: case 4:
|
|
|
|
|
{
|
2017-12-07 16:34:08 +00:00
|
|
|
// 14: heading status
|
|
|
|
|
// 15-24: heading
|
|
|
|
|
if (getbit(me, 14)) {
|
|
|
|
|
mm->heading_valid = 1;
|
|
|
|
|
mm->heading = getbits(me, 15, 24) * 360.0 / 1024.0;
|
|
|
|
|
mm->heading_type = HEADING_MAGNETIC_OR_TRUE;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// 25: airspeed type
|
|
|
|
|
// 26-35: airspeed
|
2016-09-01 21:10:17 +00:00
|
|
|
unsigned airspeed = getbits(me, 26, 35);
|
2015-01-21 00:23:48 +00:00
|
|
|
if (airspeed) {
|
2017-06-15 17:07:40 +00:00
|
|
|
unsigned speed = (airspeed - 1) * (mm->mesub == 4 ? 4 : 1);
|
|
|
|
|
if (getbit(me, 25)) {
|
|
|
|
|
mm->tas_valid = 1;
|
|
|
|
|
mm->tas = speed;
|
|
|
|
|
} else {
|
|
|
|
|
mm->ias_valid = 1;
|
|
|
|
|
mm->ias = speed;
|
|
|
|
|
}
|
2015-01-21 00:23:48 +00:00
|
|
|
}
|
2016-08-27 13:34:14 +00:00
|
|
|
|
2016-09-01 22:13:31 +00:00
|
|
|
break;
|
2015-01-21 00:23:48 +00:00
|
|
|
}
|
2016-09-01 22:13:31 +00:00
|
|
|
}
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
|
2017-12-07 16:34:08 +00:00
|
|
|
// 36: vert rate source
|
|
|
|
|
// 37: vert rate sign
|
|
|
|
|
// 38-46: vert rate magnitude
|
|
|
|
|
unsigned vert_rate = getbits(me, 38, 46);
|
2018-02-19 11:08:26 +00:00
|
|
|
unsigned vert_rate_is_baro = getbit(me, 36);
|
2017-12-07 16:34:08 +00:00
|
|
|
if (vert_rate) {
|
|
|
|
|
int rate = (vert_rate - 1) * (getbit(me, 37) ? -64 : 64);
|
2018-02-19 11:08:26 +00:00
|
|
|
if (vert_rate_is_baro) {
|
2017-12-07 16:34:08 +00:00
|
|
|
mm->baro_rate = rate;
|
|
|
|
|
mm->baro_rate_valid = 1;
|
2018-02-19 11:08:26 +00:00
|
|
|
} else {
|
|
|
|
|
mm->geom_rate = rate;
|
|
|
|
|
mm->geom_rate_valid = 1;
|
2017-12-07 16:34:08 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// 47-48: reserved
|
|
|
|
|
|
|
|
|
|
// 49: baro/geom delta sign
|
|
|
|
|
// 50-56: baro/geom delta magnitude
|
2016-09-01 22:13:31 +00:00
|
|
|
unsigned raw_delta = getbits(me, 50, 56);
|
|
|
|
|
if (raw_delta) {
|
2017-06-15 17:07:40 +00:00
|
|
|
mm->geom_delta_valid = 1;
|
|
|
|
|
mm->geom_delta = (raw_delta - 1) * (getbit(me, 49) ? -25 : 25);
|
2016-09-01 22:13:31 +00:00
|
|
|
}
|
|
|
|
|
}
|
2016-01-01 13:42:30 +00:00
|
|
|
|
2016-09-01 22:13:31 +00:00
|
|
|
static void decodeESSurfacePosition(struct modesMessage *mm, int check_imf)
|
|
|
|
|
{
|
|
|
|
|
// Surface position and movement
|
|
|
|
|
unsigned char *me = mm->ME;
|
|
|
|
|
|
|
|
|
|
mm->airground = AG_GROUND; // definitely.
|
|
|
|
|
mm->cpr_valid = 1;
|
2016-10-01 23:16:29 +00:00
|
|
|
mm->cpr_type = CPR_SURFACE;
|
2016-09-01 22:13:31 +00:00
|
|
|
|
2017-12-07 16:34:08 +00:00
|
|
|
// 6-12: Movement
|
2016-09-01 22:13:31 +00:00
|
|
|
unsigned movement = getbits(me, 6, 12);
|
|
|
|
|
if (movement > 0 && movement < 125) {
|
2017-06-15 17:07:40 +00:00
|
|
|
mm->gs_valid = 1;
|
2017-12-07 16:34:08 +00:00
|
|
|
mm->gs.selected = mm->gs.v0 = decodeMovementFieldV0(movement); // assumed v0 until told otherwise
|
|
|
|
|
mm->gs.v2 = decodeMovementFieldV2(movement);
|
2015-01-21 00:23:48 +00:00
|
|
|
}
|
|
|
|
|
|
2017-12-07 16:34:08 +00:00
|
|
|
// 13: Heading/track status
|
|
|
|
|
// 14-20: Heading/track
|
2016-09-01 22:13:31 +00:00
|
|
|
if (getbit(me, 13)) {
|
2017-06-15 20:07:53 +00:00
|
|
|
mm->heading_valid = 1;
|
|
|
|
|
mm->heading = getbits(me, 14, 20) * 360.0 / 128.0;
|
|
|
|
|
mm->heading_type = HEADING_TRACK_OR_HEADING;
|
2016-09-01 22:13:31 +00:00
|
|
|
}
|
2017-12-07 16:34:08 +00:00
|
|
|
|
|
|
|
|
// 21: IMF or T flag
|
|
|
|
|
if (check_imf && getbit(me, 21))
|
|
|
|
|
setIMF(mm);
|
|
|
|
|
|
|
|
|
|
// 22: F flag (odd/even)
|
|
|
|
|
mm->cpr_odd = getbit(me, 22);
|
|
|
|
|
|
|
|
|
|
// 23-39: CPR encoded latitude
|
|
|
|
|
mm->cpr_lat = getbits(me, 23, 39);
|
|
|
|
|
// 40-56: CPR encoded longitude
|
|
|
|
|
mm->cpr_lon = getbits(me, 40, 56);
|
2016-09-01 22:13:31 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void decodeESAirbornePosition(struct modesMessage *mm, int check_imf)
|
|
|
|
|
{
|
|
|
|
|
// Airborne position and altitude
|
|
|
|
|
unsigned char *me = mm->ME;
|
|
|
|
|
|
2017-12-07 16:34:08 +00:00
|
|
|
// 6-7: surveillance status
|
2018-02-23 19:02:02 +00:00
|
|
|
switch (getbits(me, 6, 7)) {
|
|
|
|
|
case 0:
|
|
|
|
|
// no status
|
|
|
|
|
mm->alert_valid = mm->spi_valid = 1;
|
|
|
|
|
mm->alert = mm->spi = 0;
|
|
|
|
|
break;
|
|
|
|
|
case 1: // permanent alert
|
|
|
|
|
case 2: // temporary alert
|
|
|
|
|
mm->alert_valid = 1;
|
|
|
|
|
mm->alert = 1;
|
|
|
|
|
// states 1/2 override state 3, so we don't know SPI status here.
|
|
|
|
|
break;
|
|
|
|
|
case 3: // SPI
|
|
|
|
|
// we know there's no alert in this case
|
|
|
|
|
mm->alert_valid = mm->spi_valid = 1;
|
|
|
|
|
mm->alert = 0;
|
|
|
|
|
mm->spi = 1;
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
2017-12-07 16:34:08 +00:00
|
|
|
// 8: IMF or NIC supplement-B
|
|
|
|
|
|
|
|
|
|
if (check_imf) {
|
|
|
|
|
if (getbit(me, 8))
|
|
|
|
|
setIMF(mm);
|
|
|
|
|
} else {
|
|
|
|
|
// NIC-B (v2) or SAF (v0/v1)
|
|
|
|
|
mm->accuracy.nic_b_valid = 1;
|
|
|
|
|
mm->accuracy.nic_b = getbit(me, 8);
|
|
|
|
|
}
|
2016-09-01 22:13:31 +00:00
|
|
|
|
2017-12-07 16:34:08 +00:00
|
|
|
// 9-20: altitude
|
2016-09-01 22:13:31 +00:00
|
|
|
unsigned AC12Field = getbits(me, 9, 20);
|
|
|
|
|
|
|
|
|
|
if (mm->metype == 0) {
|
2017-12-07 16:34:08 +00:00
|
|
|
// no position information
|
2016-09-01 22:13:31 +00:00
|
|
|
} else {
|
2017-12-07 16:34:08 +00:00
|
|
|
// 21: T flag (UTC sync or not)
|
|
|
|
|
// 22: F flag (odd or even)
|
|
|
|
|
// 23-39: CPR encoded latitude
|
|
|
|
|
// 40-56: CPR encoded longitude
|
2015-01-29 23:08:33 +00:00
|
|
|
|
2016-09-01 21:10:17 +00:00
|
|
|
mm->cpr_lat = getbits(me, 23, 39);
|
|
|
|
|
mm->cpr_lon = getbits(me, 40, 56);
|
2016-09-01 22:13:31 +00:00
|
|
|
|
2017-12-07 16:34:08 +00:00
|
|
|
// Catch some common failure modes and don't mark them as valid
|
|
|
|
|
// (so they won't be used for positioning)
|
2016-09-01 22:13:31 +00:00
|
|
|
if (AC12Field == 0 && mm->cpr_lon == 0 && (mm->cpr_lat & 0x0fff) == 0 && mm->metype == 15) {
|
|
|
|
|
// Seen from at least:
|
|
|
|
|
// 400F3F (Eurocopter ECC155 B1) - Bristow Helicopters
|
|
|
|
|
// 4008F3 (BAE ATP) - Atlantic Airlines
|
|
|
|
|
// 400648 (BAE ATP) - Atlantic Airlines
|
|
|
|
|
// altitude == 0, longitude == 0, type == 15 and zeros in latitude LSB.
|
|
|
|
|
// Can alternate with valid reports having type == 14
|
|
|
|
|
Modes.stats_current.cpr_filtered++;
|
|
|
|
|
} else {
|
|
|
|
|
// Otherwise, assume it's valid.
|
|
|
|
|
mm->cpr_valid = 1;
|
2016-10-01 23:16:29 +00:00
|
|
|
mm->cpr_type = CPR_AIRBORNE;
|
2016-09-01 22:13:31 +00:00
|
|
|
mm->cpr_odd = getbit(me, 22);
|
2015-01-21 00:23:48 +00:00
|
|
|
}
|
2016-09-01 22:13:31 +00:00
|
|
|
}
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
|
2018-08-28 17:08:14 +00:00
|
|
|
if (AC12Field && mm->airground != AG_GROUND) {// Only attempt to decode if a valid (non zero) altitude is present and not on ground
|
2017-12-07 16:34:08 +00:00
|
|
|
altitude_unit_t unit;
|
|
|
|
|
int alt = decodeAC12Field(AC12Field, &unit);
|
|
|
|
|
if (alt != INVALID_ALTITUDE) {
|
2021-02-18 05:53:01 +00:00
|
|
|
// If we haven't set airground yet (e.g. DF18)
|
|
|
|
|
// then we can at least set it to UNCERTAIN here
|
|
|
|
|
if (mm->airground == AG_INVALID)
|
|
|
|
|
mm->airground = AG_UNCERTAIN;
|
|
|
|
|
|
2017-12-07 16:34:08 +00:00
|
|
|
if (mm->metype == 20 || mm->metype == 21 || mm->metype == 22) {
|
|
|
|
|
mm->altitude_geom = alt;
|
|
|
|
|
mm->altitude_geom_unit = unit;
|
|
|
|
|
mm->altitude_geom_valid = 1;
|
|
|
|
|
} else {
|
|
|
|
|
mm->altitude_baro = alt;
|
|
|
|
|
mm->altitude_baro_unit = unit;
|
|
|
|
|
mm->altitude_baro_valid = 1;
|
|
|
|
|
}
|
2015-01-21 00:23:48 +00:00
|
|
|
}
|
|
|
|
|
}
|
2016-09-01 22:13:31 +00:00
|
|
|
}
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
|
2016-09-01 22:13:31 +00:00
|
|
|
static void decodeESTestMessage(struct modesMessage *mm)
|
|
|
|
|
{
|
|
|
|
|
unsigned char *me = mm->ME;
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
|
2016-09-01 22:13:31 +00:00
|
|
|
mm->mesub = getbits(me, 6, 8);
|
2015-01-29 23:08:33 +00:00
|
|
|
|
2016-09-01 22:13:31 +00:00
|
|
|
if (mm->mesub == 7) { // (see 1090-WP-15-20)
|
|
|
|
|
int ID13Field = getbits(me, 9, 21);
|
|
|
|
|
if (ID13Field) {
|
|
|
|
|
mm->squawk_valid = 1;
|
|
|
|
|
mm->squawk = decodeID13Field(ID13Field);
|
2015-01-21 00:23:48 +00:00
|
|
|
}
|
2016-09-01 22:13:31 +00:00
|
|
|
}
|
|
|
|
|
}
|
2014-07-10 17:11:13 +00:00
|
|
|
|
2016-09-01 22:13:31 +00:00
|
|
|
static void decodeESAircraftStatus(struct modesMessage *mm, int check_imf)
|
|
|
|
|
{
|
|
|
|
|
// Extended Squitter Aircraft Status
|
|
|
|
|
unsigned char *me = mm->ME;
|
|
|
|
|
|
|
|
|
|
mm->mesub = getbits(me, 6, 8);
|
2016-08-27 13:34:14 +00:00
|
|
|
|
2016-09-01 22:13:31 +00:00
|
|
|
if (mm->mesub == 1) { // Emergency status squawk field
|
2018-01-09 14:43:58 +00:00
|
|
|
mm->emergency_valid = 1;
|
|
|
|
|
mm->emergency = (emergency_t) getbits(me, 9, 11);
|
|
|
|
|
|
|
|
|
|
unsigned ID13Field = getbits(me, 12, 24);
|
2016-09-01 22:13:31 +00:00
|
|
|
if (ID13Field) {
|
|
|
|
|
mm->squawk_valid = 1;
|
|
|
|
|
mm->squawk = decodeID13Field(ID13Field);
|
2015-01-21 00:23:48 +00:00
|
|
|
}
|
2015-02-09 14:14:12 +00:00
|
|
|
|
2016-09-01 22:13:31 +00:00
|
|
|
if (check_imf && getbit(me, 56))
|
2016-09-14 15:37:07 +00:00
|
|
|
setIMF(mm);
|
2015-01-21 00:23:48 +00:00
|
|
|
}
|
2016-09-01 22:13:31 +00:00
|
|
|
}
|
2014-07-10 17:11:13 +00:00
|
|
|
|
2016-09-01 22:13:31 +00:00
|
|
|
static void decodeESTargetStatus(struct modesMessage *mm, int check_imf)
|
|
|
|
|
{
|
|
|
|
|
unsigned char *me = mm->ME;
|
|
|
|
|
|
|
|
|
|
mm->mesub = getbits(me, 6, 7); // an unusual message: only 2 bits of subtype
|
|
|
|
|
|
|
|
|
|
if (check_imf && getbit(me, 51))
|
2016-09-14 15:37:07 +00:00
|
|
|
setIMF(mm);
|
2016-09-01 22:13:31 +00:00
|
|
|
|
2017-12-07 16:34:08 +00:00
|
|
|
if (mm->mesub == 0 && getbit(me, 11) == 0) { // Target state and status, V1
|
|
|
|
|
// 8-9: vertical source
|
|
|
|
|
switch (getbits(me, 8, 9)) {
|
|
|
|
|
case 1:
|
|
|
|
|
mm->nav.altitude_source = NAV_ALT_MCP;
|
|
|
|
|
break;
|
|
|
|
|
case 2:
|
|
|
|
|
mm->nav.altitude_source = NAV_ALT_AIRCRAFT;
|
|
|
|
|
break;
|
|
|
|
|
case 3:
|
|
|
|
|
mm->nav.altitude_source = NAV_ALT_FMS;
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
// nothing
|
|
|
|
|
break;
|
|
|
|
|
}
|
2019-03-19 18:23:49 +00:00
|
|
|
// 10: target altitude type (MSL or Baro, ignored)
|
2017-12-07 16:34:08 +00:00
|
|
|
// 11: backward compatibility bit, always 0
|
|
|
|
|
// 12-13: target alt capabilities (ignored)
|
|
|
|
|
// 14-15: vertical mode
|
|
|
|
|
switch (getbits(me, 14, 15)) {
|
|
|
|
|
case 1: // "acquiring"
|
|
|
|
|
mm->nav.modes_valid = 1;
|
|
|
|
|
if (mm->nav.altitude_source == NAV_ALT_FMS) {
|
|
|
|
|
mm->nav.modes |= NAV_MODE_VNAV;
|
|
|
|
|
} else {
|
|
|
|
|
mm->nav.modes |= NAV_MODE_AUTOPILOT;
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
case 2: // "maintaining"
|
|
|
|
|
mm->nav.modes_valid = 1;
|
|
|
|
|
if (mm->nav.altitude_source == NAV_ALT_FMS) {
|
|
|
|
|
mm->nav.modes |= NAV_MODE_VNAV;
|
|
|
|
|
} else if (mm->nav.altitude_source == NAV_ALT_AIRCRAFT) {
|
|
|
|
|
mm->nav.modes |= NAV_MODE_ALT_HOLD;
|
|
|
|
|
} else {
|
|
|
|
|
mm->nav.modes |= NAV_MODE_AUTOPILOT;
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
// nothing
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
2019-03-19 18:23:49 +00:00
|
|
|
// 16-25: target altitude
|
2017-12-07 16:34:08 +00:00
|
|
|
int alt = -1000 + 100 * getbits(me, 16, 25);
|
|
|
|
|
switch (mm->nav.altitude_source) {
|
|
|
|
|
case NAV_ALT_MCP:
|
|
|
|
|
mm->nav.mcp_altitude_valid = 1;
|
|
|
|
|
mm->nav.mcp_altitude = alt;
|
|
|
|
|
break;
|
|
|
|
|
case NAV_ALT_FMS:
|
|
|
|
|
mm->nav.fms_altitude_valid = 1;
|
|
|
|
|
mm->nav.fms_altitude = alt;
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
// nothing
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
// 26-27: horizontal data source
|
|
|
|
|
unsigned h_source = getbits(me, 26, 27);
|
|
|
|
|
if (h_source != 0) {
|
|
|
|
|
// 28-36: target heading/track
|
|
|
|
|
mm->nav.heading_valid = 1;
|
|
|
|
|
mm->nav.heading = getbits(me, 28, 36);
|
|
|
|
|
// 37: track vs heading
|
|
|
|
|
if (getbit(me, 37)) {
|
|
|
|
|
mm->nav.heading_type = HEADING_GROUND_TRACK;
|
|
|
|
|
} else {
|
|
|
|
|
mm->nav.heading_type = HEADING_MAGNETIC_OR_TRUE;
|
|
|
|
|
}
|
|
|
|
|
}
|
2019-03-19 18:23:49 +00:00
|
|
|
// 38-39: horizontal mode
|
2017-12-07 16:34:08 +00:00
|
|
|
switch (getbits(me, 38, 39)) {
|
|
|
|
|
case 1: // acquiring
|
|
|
|
|
case 2: // maintaining
|
|
|
|
|
mm->nav.modes_valid = 1;
|
|
|
|
|
if (h_source == 3) { // FMS
|
|
|
|
|
mm->nav.modes |= NAV_MODE_LNAV;
|
|
|
|
|
} else {
|
|
|
|
|
mm->nav.modes |= NAV_MODE_AUTOPILOT;
|
|
|
|
|
}
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
// nothing
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// 40-43: NACp
|
|
|
|
|
mm->accuracy.nac_p_valid = 1;
|
|
|
|
|
mm->accuracy.nac_p = getbits(me, 40, 43);
|
|
|
|
|
|
|
|
|
|
// 44: NICbaro
|
|
|
|
|
mm->accuracy.nic_baro_valid = 1;
|
|
|
|
|
mm->accuracy.nic_baro = getbit(me, 44);
|
|
|
|
|
|
|
|
|
|
// 45-46: SIL
|
|
|
|
|
mm->accuracy.sil = getbits(me, 45, 46);
|
2017-12-07 19:36:07 +00:00
|
|
|
mm->accuracy.sil_type = SIL_UNKNOWN;
|
2017-12-07 16:34:08 +00:00
|
|
|
|
|
|
|
|
// 47-51: reserved
|
|
|
|
|
|
|
|
|
|
// 52-53: TCAS status
|
|
|
|
|
switch (getbits(me, 52, 53)) {
|
|
|
|
|
case 1:
|
|
|
|
|
mm->nav.modes_valid = 1;
|
|
|
|
|
// no tcas
|
|
|
|
|
break;
|
|
|
|
|
case 2:
|
|
|
|
|
case 3:
|
|
|
|
|
mm->nav.modes_valid = 1;
|
|
|
|
|
mm->nav.modes |= NAV_MODE_TCAS;
|
|
|
|
|
break;
|
|
|
|
|
case 0:
|
|
|
|
|
// assume TCAS if we had any other modes
|
|
|
|
|
// but don't enable modes just for this
|
|
|
|
|
mm->nav.modes |= NAV_MODE_TCAS;
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
// nothing
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
2017-06-15 17:07:40 +00:00
|
|
|
|
2018-01-09 14:43:58 +00:00
|
|
|
// 54-56: emergency/priority
|
|
|
|
|
mm->emergency_valid = 1;
|
|
|
|
|
mm->emergency = (emergency_t) getbits(me, 54, 56);
|
2017-12-07 16:34:08 +00:00
|
|
|
} else if (mm->mesub == 1) { // Target state and status, V2
|
2017-06-15 17:07:40 +00:00
|
|
|
// 8: SIL
|
|
|
|
|
unsigned is_fms = getbit(me, 9);
|
2016-09-01 22:13:31 +00:00
|
|
|
|
|
|
|
|
unsigned alt_bits = getbits(me, 10, 20);
|
2017-06-15 17:07:40 +00:00
|
|
|
if (alt_bits != 0) {
|
|
|
|
|
if (is_fms) {
|
2017-12-07 16:34:08 +00:00
|
|
|
mm->nav.fms_altitude_valid = 1;
|
|
|
|
|
mm->nav.fms_altitude = (alt_bits - 1) * 32;
|
2017-06-15 17:07:40 +00:00
|
|
|
} else {
|
2017-12-07 16:34:08 +00:00
|
|
|
mm->nav.mcp_altitude_valid = 1;
|
|
|
|
|
mm->nav.mcp_altitude = (alt_bits - 1) * 32;
|
2017-06-15 17:07:40 +00:00
|
|
|
}
|
2015-01-21 00:23:48 +00:00
|
|
|
}
|
2014-07-10 17:11:13 +00:00
|
|
|
|
2016-09-01 22:13:31 +00:00
|
|
|
unsigned baro_bits = getbits(me, 21, 29);
|
2017-06-15 17:07:40 +00:00
|
|
|
if (baro_bits != 0) {
|
2017-12-07 16:34:08 +00:00
|
|
|
mm->nav.qnh_valid = 1;
|
|
|
|
|
mm->nav.qnh = 800.0 + (baro_bits - 1) * 0.8;
|
2016-09-01 22:13:31 +00:00
|
|
|
}
|
2014-07-10 17:11:13 +00:00
|
|
|
|
2017-06-15 17:07:40 +00:00
|
|
|
if (getbit(me, 30)) {
|
2017-12-07 16:34:08 +00:00
|
|
|
mm->nav.heading_valid = 1;
|
2016-09-01 22:13:31 +00:00
|
|
|
// two's complement -180..+180, which is conveniently
|
|
|
|
|
// also the same as unsigned 0..360
|
2017-12-07 16:34:08 +00:00
|
|
|
mm->nav.heading = getbits(me, 31, 39) * 180.0 / 256.0;
|
|
|
|
|
mm->nav.heading_type = HEADING_MAGNETIC_OR_TRUE;
|
2016-09-01 22:13:31 +00:00
|
|
|
}
|
2015-01-29 23:08:33 +00:00
|
|
|
|
2017-06-15 17:07:40 +00:00
|
|
|
// 40-43: NACp
|
2017-12-07 16:34:08 +00:00
|
|
|
mm->accuracy.nac_p_valid = 1;
|
|
|
|
|
mm->accuracy.nac_p = getbits(me, 40, 43);
|
|
|
|
|
|
2017-06-15 17:07:40 +00:00
|
|
|
// 44: NICbaro
|
2017-12-07 16:34:08 +00:00
|
|
|
mm->accuracy.nic_baro_valid = 1;
|
|
|
|
|
mm->accuracy.nic_baro = getbit(me, 44);
|
|
|
|
|
|
2017-06-15 17:07:40 +00:00
|
|
|
// 45-46: SIL
|
2017-12-07 16:34:08 +00:00
|
|
|
mm->accuracy.sil = getbits(me, 45, 46);
|
2017-12-07 19:36:07 +00:00
|
|
|
mm->accuracy.sil_type = SIL_UNKNOWN;
|
2017-06-15 17:07:40 +00:00
|
|
|
|
2017-12-07 16:34:08 +00:00
|
|
|
// 47: mode bits validity
|
2017-06-15 17:07:40 +00:00
|
|
|
if (getbit(me, 47)) {
|
2017-12-07 16:34:08 +00:00
|
|
|
// 48-54: mode bits
|
|
|
|
|
mm->nav.modes_valid = 1;
|
|
|
|
|
mm->nav.modes =
|
|
|
|
|
(getbit(me, 48) ? NAV_MODE_AUTOPILOT : 0) |
|
|
|
|
|
(getbit(me, 49) ? NAV_MODE_VNAV : 0) |
|
|
|
|
|
(getbit(me, 50) ? NAV_MODE_ALT_HOLD : 0) |
|
2017-06-16 09:39:01 +00:00
|
|
|
// 51: IMF
|
2017-12-07 16:34:08 +00:00
|
|
|
(getbit(me, 52) ? NAV_MODE_APPROACH : 0) |
|
|
|
|
|
(getbit(me, 53) ? NAV_MODE_TCAS : 0) |
|
|
|
|
|
(getbit(me, 54) ? NAV_MODE_LNAV : 0);
|
2014-07-10 17:11:13 +00:00
|
|
|
}
|
2016-09-01 22:13:31 +00:00
|
|
|
|
2017-06-15 17:07:40 +00:00
|
|
|
// 55-56 reserved
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
}
|
2016-09-01 22:13:31 +00:00
|
|
|
}
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
|
2016-09-01 22:13:31 +00:00
|
|
|
static void decodeESOperationalStatus(struct modesMessage *mm, int check_imf)
|
|
|
|
|
{
|
|
|
|
|
unsigned char *me = mm->ME;
|
2016-09-01 21:10:17 +00:00
|
|
|
|
2016-09-01 22:13:31 +00:00
|
|
|
mm->mesub = getbits(me, 6, 8);
|
2016-08-29 10:11:04 +00:00
|
|
|
|
2016-09-01 22:13:31 +00:00
|
|
|
// Aircraft Operational Status
|
|
|
|
|
if (check_imf && getbit(me, 56))
|
2016-09-14 15:37:07 +00:00
|
|
|
setIMF(mm);
|
2016-09-01 22:13:31 +00:00
|
|
|
|
|
|
|
|
if (mm->mesub == 0 || mm->mesub == 1) {
|
|
|
|
|
mm->opstatus.valid = 1;
|
|
|
|
|
mm->opstatus.version = getbits(me, 41, 43);
|
|
|
|
|
|
|
|
|
|
switch (mm->opstatus.version) {
|
|
|
|
|
case 0:
|
2017-12-07 16:34:08 +00:00
|
|
|
if (mm->mesub == 0 && getbits(me, 9, 10) == 0) {
|
|
|
|
|
mm->opstatus.cc_acas = !getbit(me, 12);
|
|
|
|
|
mm->opstatus.cc_cdti = getbit(me, 13);
|
|
|
|
|
}
|
2016-09-01 22:13:31 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case 1:
|
|
|
|
|
if (getbits(me, 25, 26) == 0) {
|
|
|
|
|
mm->opstatus.om_acas_ra = getbit(me, 27);
|
|
|
|
|
mm->opstatus.om_ident = getbit(me, 28);
|
|
|
|
|
mm->opstatus.om_atc = getbit(me, 29);
|
2016-08-29 10:11:04 +00:00
|
|
|
}
|
|
|
|
|
|
2016-09-01 22:13:31 +00:00
|
|
|
if (mm->mesub == 0 && getbits(me, 9, 10) == 0 && getbits(me, 13, 14) == 0) {
|
|
|
|
|
// airborne
|
|
|
|
|
mm->opstatus.cc_acas = !getbit(me, 11);
|
|
|
|
|
mm->opstatus.cc_cdti = getbit(me, 12);
|
|
|
|
|
mm->opstatus.cc_arv = getbit(me, 15);
|
|
|
|
|
mm->opstatus.cc_ts = getbit(me, 16);
|
|
|
|
|
mm->opstatus.cc_tc = getbits(me, 17, 18);
|
|
|
|
|
} else if (mm->mesub == 1 && getbits(me, 9, 10) == 0 && getbits(me, 13, 14) == 0) {
|
|
|
|
|
// surface
|
|
|
|
|
mm->opstatus.cc_poa = getbit(me, 11);
|
|
|
|
|
mm->opstatus.cc_cdti = getbit(me, 12);
|
|
|
|
|
mm->opstatus.cc_b2_low = getbit(me, 15);
|
|
|
|
|
mm->opstatus.cc_lw_valid = 1;
|
|
|
|
|
mm->opstatus.cc_lw = getbits(me, 21, 24);
|
|
|
|
|
}
|
|
|
|
|
|
2017-12-07 16:34:08 +00:00
|
|
|
mm->accuracy.nic_a_valid = 1;
|
|
|
|
|
mm->accuracy.nic_a = getbit(me, 44);
|
|
|
|
|
mm->accuracy.nac_p_valid = 1;
|
|
|
|
|
mm->accuracy.nac_p = getbits(me, 45, 48);
|
2017-12-07 19:36:07 +00:00
|
|
|
mm->accuracy.sil_type = SIL_UNKNOWN;
|
2017-12-07 16:34:08 +00:00
|
|
|
mm->accuracy.sil = getbits(me, 51, 52);
|
|
|
|
|
|
2017-06-15 20:07:53 +00:00
|
|
|
mm->opstatus.hrd = getbit(me, 54) ? HEADING_MAGNETIC : HEADING_TRUE;
|
2017-12-07 16:34:08 +00:00
|
|
|
|
2016-09-01 22:13:31 +00:00
|
|
|
if (mm->mesub == 0) {
|
2017-12-07 16:34:08 +00:00
|
|
|
mm->accuracy.nic_baro_valid = 1;
|
|
|
|
|
mm->accuracy.nic_baro = getbit(me, 53);
|
2016-08-29 10:11:04 +00:00
|
|
|
} else {
|
2019-06-06 06:14:46 +00:00
|
|
|
// see DO=260B §2.2.3.2.7.2.12
|
|
|
|
|
// TAH=0 : surface movement reports ground track
|
|
|
|
|
// TAH=1 : surface movement reports aircraft heading
|
|
|
|
|
mm->opstatus.tah = getbit(me, 53) ? mm->opstatus.hrd : HEADING_GROUND_TRACK;
|
2016-08-29 10:11:04 +00:00
|
|
|
}
|
2016-09-01 22:13:31 +00:00
|
|
|
break;
|
2016-08-29 10:11:04 +00:00
|
|
|
|
2016-09-01 22:13:31 +00:00
|
|
|
case 2:
|
|
|
|
|
if (getbits(me, 25, 26) == 0) {
|
|
|
|
|
mm->opstatus.om_acas_ra = getbit(me, 27);
|
|
|
|
|
mm->opstatus.om_ident = getbit(me, 28);
|
|
|
|
|
mm->opstatus.om_atc = getbit(me, 29);
|
|
|
|
|
mm->opstatus.om_saf = getbit(me, 30);
|
2017-12-07 16:34:08 +00:00
|
|
|
mm->accuracy.sda_valid = 1;
|
|
|
|
|
mm->accuracy.sda = getbits(me, 31, 32);
|
2016-08-29 10:11:04 +00:00
|
|
|
}
|
|
|
|
|
|
2017-12-07 16:34:08 +00:00
|
|
|
if (mm->mesub == 0 && getbits(me, 9, 10) == 0) {
|
2016-09-01 22:13:31 +00:00
|
|
|
// airborne
|
2017-12-07 16:34:08 +00:00
|
|
|
mm->opstatus.cc_acas = getbit(me, 11); // nb inverted sense versus v0/v1
|
2016-09-01 22:13:31 +00:00
|
|
|
mm->opstatus.cc_1090_in = getbit(me, 12);
|
|
|
|
|
mm->opstatus.cc_arv = getbit(me, 15);
|
|
|
|
|
mm->opstatus.cc_ts = getbit(me, 16);
|
|
|
|
|
mm->opstatus.cc_tc = getbits(me, 17, 18);
|
|
|
|
|
mm->opstatus.cc_uat_in = getbit(me, 19);
|
2017-12-07 16:34:08 +00:00
|
|
|
} else if (mm->mesub == 1 && getbits(me, 9, 10) == 0) {
|
2016-09-01 22:13:31 +00:00
|
|
|
// surface
|
|
|
|
|
mm->opstatus.cc_poa = getbit(me, 11);
|
|
|
|
|
mm->opstatus.cc_1090_in = getbit(me, 12);
|
|
|
|
|
mm->opstatus.cc_b2_low = getbit(me, 15);
|
|
|
|
|
mm->opstatus.cc_uat_in = getbit(me, 16);
|
2017-12-07 16:34:08 +00:00
|
|
|
mm->accuracy.nac_v_valid = 1;
|
|
|
|
|
mm->accuracy.nac_v = getbits(me, 17, 19);
|
|
|
|
|
mm->accuracy.nic_c_valid = 1;
|
|
|
|
|
mm->accuracy.nic_c = getbit(me, 20);
|
2016-09-01 22:13:31 +00:00
|
|
|
mm->opstatus.cc_lw_valid = 1;
|
|
|
|
|
mm->opstatus.cc_lw = getbits(me, 21, 24);
|
|
|
|
|
mm->opstatus.cc_antenna_offset = getbits(me, 33, 40);
|
2016-08-29 10:11:04 +00:00
|
|
|
}
|
|
|
|
|
|
2017-12-07 16:34:08 +00:00
|
|
|
mm->accuracy.nic_a_valid = 1;
|
|
|
|
|
mm->accuracy.nic_a = getbit(me, 44);
|
|
|
|
|
mm->accuracy.nac_p_valid = 1;
|
|
|
|
|
mm->accuracy.nac_p = getbits(me, 45, 48);
|
|
|
|
|
mm->accuracy.sil = getbits(me, 51, 52);
|
|
|
|
|
mm->accuracy.sil_type = getbit(me, 55) ? SIL_PER_SAMPLE : SIL_PER_HOUR;
|
2017-06-15 20:07:53 +00:00
|
|
|
mm->opstatus.hrd = getbit(me, 54) ? HEADING_MAGNETIC : HEADING_TRUE;
|
2016-09-01 22:13:31 +00:00
|
|
|
if (mm->mesub == 0) {
|
2017-12-07 16:34:08 +00:00
|
|
|
mm->accuracy.gva_valid = 1;
|
|
|
|
|
mm->accuracy.gva = getbits(me, 49, 50);
|
|
|
|
|
mm->accuracy.nic_baro_valid = 1;
|
|
|
|
|
mm->accuracy.nic_baro = getbit(me, 53);
|
2016-09-01 22:13:31 +00:00
|
|
|
} else {
|
2019-06-06 06:14:46 +00:00
|
|
|
// see DO=260B §2.2.3.2.7.2.12
|
|
|
|
|
// TAH=0 : surface movement reports ground track
|
|
|
|
|
// TAH=1 : surface movement reports aircraft heading
|
|
|
|
|
mm->opstatus.tah = getbit(me, 53) ? mm->opstatus.hrd : HEADING_GROUND_TRACK;
|
2016-09-01 22:13:31 +00:00
|
|
|
}
|
|
|
|
|
break;
|
2016-08-29 10:11:04 +00:00
|
|
|
}
|
2016-09-01 22:13:31 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void decodeExtendedSquitter(struct modesMessage *mm)
|
|
|
|
|
{
|
|
|
|
|
unsigned char *me = mm->ME;
|
|
|
|
|
unsigned metype = mm->metype = getbits(me, 1, 5);
|
|
|
|
|
unsigned check_imf = 0;
|
|
|
|
|
|
|
|
|
|
// Check CF on DF18 to work out the format of the ES and whether we need to look for an IMF bit
|
|
|
|
|
if (mm->msgtype == 18) {
|
|
|
|
|
switch (mm->CF) {
|
2016-09-15 14:30:34 +00:00
|
|
|
case 0: // ADS-B Message from a non-transponder device, AA field holds 24-bit ICAO aircraft address
|
2016-09-14 15:37:07 +00:00
|
|
|
mm->addrtype = ADDR_ADSB_ICAO_NT;
|
2016-09-01 22:13:31 +00:00
|
|
|
break;
|
|
|
|
|
|
2016-09-15 14:30:34 +00:00
|
|
|
case 1: // Reserved for ADS-B Message in which the AA field holds anonymous address or ground vehicle address or fixed obstruction address
|
2016-09-14 15:37:07 +00:00
|
|
|
mm->addrtype = ADDR_ADSB_OTHER;
|
2016-09-01 22:13:31 +00:00
|
|
|
mm->addr |= MODES_NON_ICAO_ADDRESS;
|
|
|
|
|
break;
|
|
|
|
|
|
2016-09-15 14:30:34 +00:00
|
|
|
case 2: // Fine TIS-B Message
|
|
|
|
|
// IMF=0: AA field contains the 24-bit ICAO aircraft address
|
|
|
|
|
// IMF=1: AA field contains the 12-bit Mode A code followed by a 12-bit track file number
|
2016-09-01 22:13:31 +00:00
|
|
|
mm->source = SOURCE_TISB;
|
2016-09-14 15:37:07 +00:00
|
|
|
mm->addrtype = ADDR_TISB_ICAO;
|
2016-09-01 22:13:31 +00:00
|
|
|
check_imf = 1;
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case 3: // Coarse TIS-B airborne position and velocity.
|
2016-09-15 14:30:34 +00:00
|
|
|
// IMF=0: AA field contains the 24-bit ICAO aircraft address
|
|
|
|
|
// IMF=1: AA field contains the 12-bit Mode A code followed by a 12-bit track file number
|
|
|
|
|
|
2016-09-01 22:13:31 +00:00
|
|
|
// For now we only look at the IMF bit.
|
|
|
|
|
mm->source = SOURCE_TISB;
|
2016-09-14 15:37:07 +00:00
|
|
|
mm->addrtype = ADDR_TISB_ICAO;
|
2016-09-15 14:30:34 +00:00
|
|
|
if (getbit(me, 1))
|
|
|
|
|
setIMF(mm);
|
2016-09-01 22:13:31 +00:00
|
|
|
return;
|
|
|
|
|
|
2016-09-15 14:30:34 +00:00
|
|
|
case 5: // Fine TIS-B Message, AA field contains a non-ICAO 24-bit address
|
|
|
|
|
mm->addrtype = ADDR_TISB_OTHER;
|
2016-09-01 22:13:31 +00:00
|
|
|
mm->source = SOURCE_TISB;
|
|
|
|
|
mm->addr |= MODES_NON_ICAO_ADDRESS;
|
|
|
|
|
break;
|
|
|
|
|
|
2016-09-15 14:30:34 +00:00
|
|
|
case 6: // Rebroadcast of ADS-B Message from an alternate data link
|
|
|
|
|
// IMF=0: AA field holds 24-bit ICAO aircraft address
|
|
|
|
|
// IMF=1: AA field holds anonymous address or ground vehicle address or fixed obstruction address
|
2016-09-14 15:37:07 +00:00
|
|
|
mm->addrtype = ADDR_ADSR_ICAO;
|
2019-12-11 18:43:19 +00:00
|
|
|
mm->source = SOURCE_ADSR;
|
2016-09-01 22:13:31 +00:00
|
|
|
check_imf = 1;
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
default: // All others, we don't know the format.
|
2016-09-14 15:37:07 +00:00
|
|
|
mm->addrtype = ADDR_UNKNOWN;
|
2016-09-01 22:13:31 +00:00
|
|
|
mm->addr |= MODES_NON_ICAO_ADDRESS; // assume non-ICAO
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
switch (metype) {
|
|
|
|
|
case 1: case 2: case 3: case 4:
|
|
|
|
|
decodeESIdentAndCategory(mm);
|
2015-01-21 00:23:48 +00:00
|
|
|
break;
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
|
2016-09-01 22:13:31 +00:00
|
|
|
case 19:
|
|
|
|
|
decodeESAirborneVelocity(mm, check_imf);
|
2015-01-21 00:23:48 +00:00
|
|
|
break;
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
|
2016-09-01 22:13:31 +00:00
|
|
|
case 5: case 6: case 7: case 8:
|
|
|
|
|
decodeESSurfacePosition(mm, check_imf);
|
|
|
|
|
break;
|
2016-08-29 10:11:04 +00:00
|
|
|
|
2016-09-01 22:13:31 +00:00
|
|
|
case 0: // Airborne position, baro altitude only
|
|
|
|
|
case 9: case 10: case 11: case 12: case 13: case 14: case 15: case 16: case 17: case 18: // Airborne position, baro
|
2017-06-15 17:07:40 +00:00
|
|
|
case 20: case 21: case 22: // Airborne position, geometric altitude (HAE or MSL)
|
2016-09-01 22:13:31 +00:00
|
|
|
decodeESAirbornePosition(mm, check_imf);
|
|
|
|
|
break;
|
2016-08-29 10:11:04 +00:00
|
|
|
|
2016-09-01 22:13:31 +00:00
|
|
|
case 23:
|
|
|
|
|
decodeESTestMessage(mm);
|
|
|
|
|
break;
|
2016-08-29 10:11:04 +00:00
|
|
|
|
2016-09-01 22:13:31 +00:00
|
|
|
case 24: // Reserved for Surface System Status
|
|
|
|
|
break;
|
2016-08-29 10:11:04 +00:00
|
|
|
|
2016-09-01 22:13:31 +00:00
|
|
|
case 28:
|
|
|
|
|
decodeESAircraftStatus(mm, check_imf);
|
|
|
|
|
break;
|
2016-08-29 10:11:04 +00:00
|
|
|
|
2016-09-01 22:13:31 +00:00
|
|
|
case 29:
|
|
|
|
|
decodeESTargetStatus(mm, check_imf);
|
|
|
|
|
break;
|
2016-08-29 10:11:04 +00:00
|
|
|
|
2016-09-01 22:13:31 +00:00
|
|
|
case 30: // Aircraft Operational Coordination
|
|
|
|
|
break;
|
2016-08-29 10:11:04 +00:00
|
|
|
|
2016-09-01 22:13:31 +00:00
|
|
|
case 31:
|
|
|
|
|
decodeESOperationalStatus(mm, check_imf);
|
2015-01-21 00:23:48 +00:00
|
|
|
break;
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
|
2017-06-15 17:16:51 +00:00
|
|
|
default:
|
2019-11-27 12:30:41 +00:00
|
|
|
// Dubious.
|
|
|
|
|
mm->reliable = 0;
|
2015-01-21 00:23:48 +00:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
|
2016-08-27 13:34:14 +00:00
|
|
|
static const char *df_names[33] = {
|
|
|
|
|
/* 0 */ "Short Air-Air Surveillance",
|
|
|
|
|
/* 1 */ NULL,
|
|
|
|
|
/* 2 */ NULL,
|
|
|
|
|
/* 3 */ NULL,
|
|
|
|
|
/* 4 */ "Survelliance, Altitude Reply",
|
|
|
|
|
/* 5 */ "Survelliance, Identity Reply",
|
|
|
|
|
/* 6 */ NULL,
|
|
|
|
|
/* 7 */ NULL,
|
|
|
|
|
/* 8 */ NULL,
|
|
|
|
|
/* 9 */ NULL,
|
|
|
|
|
/* 10 */ NULL,
|
|
|
|
|
/* 11 */ "All Call Reply",
|
|
|
|
|
/* 12 */ NULL,
|
|
|
|
|
/* 13 */ NULL,
|
|
|
|
|
/* 14 */ NULL,
|
|
|
|
|
/* 15 */ NULL,
|
|
|
|
|
/* 16 */ "Long Air-Air ACAS",
|
|
|
|
|
/* 17 */ "Extended Squitter",
|
|
|
|
|
/* 18 */ "Extended Squitter (Non-Transponder)",
|
|
|
|
|
/* 19 */ "Extended Squitter (Military)",
|
|
|
|
|
/* 20 */ "Comm-B, Altitude Reply",
|
|
|
|
|
/* 21 */ "Comm-B, Identity Reply",
|
|
|
|
|
/* 22 */ "Military Use",
|
|
|
|
|
/* 23 */ NULL,
|
|
|
|
|
/* 24 */ "Comm-D Extended Length Message",
|
|
|
|
|
/* 25 */ "Comm-D Extended Length Message",
|
|
|
|
|
/* 26 */ "Comm-D Extended Length Message",
|
|
|
|
|
/* 27 */ "Comm-D Extended Length Message",
|
|
|
|
|
/* 28 */ "Comm-D Extended Length Message",
|
|
|
|
|
/* 29 */ "Comm-D Extended Length Message",
|
|
|
|
|
/* 30 */ "Comm-D Extended Length Message",
|
|
|
|
|
/* 31 */ "Comm-D Extended Length Message",
|
|
|
|
|
/* 32 */ "Mode A/C Reply",
|
|
|
|
|
};
|
2016-01-01 13:42:30 +00:00
|
|
|
|
2016-08-27 13:34:14 +00:00
|
|
|
static const char *df_to_string(unsigned df) {
|
|
|
|
|
if (df > 32)
|
|
|
|
|
return "out of range";
|
|
|
|
|
if (!df_names[df])
|
|
|
|
|
return "reserved";
|
|
|
|
|
return df_names[df];
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static const char *altitude_unit_to_string(altitude_unit_t unit) {
|
|
|
|
|
switch (unit) {
|
|
|
|
|
case UNIT_FEET:
|
|
|
|
|
return "ft";
|
|
|
|
|
case UNIT_METERS:
|
|
|
|
|
return "m";
|
|
|
|
|
default:
|
|
|
|
|
return "(unknown altitude unit)";
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static const char *airground_to_string(airground_t airground) {
|
|
|
|
|
switch (airground) {
|
|
|
|
|
case AG_GROUND:
|
|
|
|
|
return "ground";
|
|
|
|
|
case AG_AIRBORNE:
|
|
|
|
|
return "airborne";
|
|
|
|
|
case AG_INVALID:
|
|
|
|
|
return "invalid";
|
|
|
|
|
case AG_UNCERTAIN:
|
|
|
|
|
return "airborne?";
|
|
|
|
|
default:
|
|
|
|
|
return "(unknown airground state)";
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-09-14 15:37:07 +00:00
|
|
|
static const char *addrtype_to_string(addrtype_t type) {
|
|
|
|
|
switch (type) {
|
|
|
|
|
case ADDR_ADSB_ICAO:
|
2016-09-14 16:19:49 +00:00
|
|
|
return "Mode S / ADS-B";
|
2016-09-14 15:37:07 +00:00
|
|
|
case ADDR_ADSB_ICAO_NT:
|
|
|
|
|
return "ADS-B, non-transponder";
|
|
|
|
|
case ADDR_ADSB_OTHER:
|
|
|
|
|
return "ADS-B, other addressing scheme";
|
|
|
|
|
case ADDR_TISB_ICAO:
|
|
|
|
|
return "TIS-B";
|
|
|
|
|
case ADDR_TISB_OTHER:
|
|
|
|
|
return "TIS-B, other addressing scheme";
|
2016-09-15 14:30:34 +00:00
|
|
|
case ADDR_TISB_TRACKFILE:
|
|
|
|
|
return "TIS-B, Mode A code and track file number";
|
2016-09-14 15:37:07 +00:00
|
|
|
case ADDR_ADSR_ICAO:
|
|
|
|
|
return "ADS-R";
|
|
|
|
|
case ADDR_ADSR_OTHER:
|
|
|
|
|
return "ADS-R, other addressing scheme";
|
2016-10-11 16:55:02 +00:00
|
|
|
case ADDR_MODE_A:
|
|
|
|
|
return "Mode A";
|
2016-09-14 15:37:07 +00:00
|
|
|
default:
|
|
|
|
|
return "unknown addressing scheme";
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-10-01 23:16:29 +00:00
|
|
|
static const char *cpr_type_to_string(cpr_type_t type) {
|
|
|
|
|
switch (type) {
|
|
|
|
|
case CPR_SURFACE:
|
|
|
|
|
return "Surface";
|
|
|
|
|
case CPR_AIRBORNE:
|
|
|
|
|
return "Airborne";
|
|
|
|
|
case CPR_COARSE:
|
|
|
|
|
return "TIS-B Coarse";
|
|
|
|
|
default:
|
|
|
|
|
return "unknown CPR type";
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2017-06-15 20:07:53 +00:00
|
|
|
static const char *heading_type_to_string(heading_type_t type) {
|
|
|
|
|
switch (type) {
|
|
|
|
|
case HEADING_GROUND_TRACK:
|
|
|
|
|
return "Ground track";
|
|
|
|
|
case HEADING_MAGNETIC:
|
|
|
|
|
return "Mag heading";
|
|
|
|
|
case HEADING_TRUE:
|
|
|
|
|
return "True heading";
|
|
|
|
|
case HEADING_MAGNETIC_OR_TRUE:
|
|
|
|
|
return "Heading";
|
|
|
|
|
case HEADING_TRACK_OR_HEADING:
|
|
|
|
|
return "Track/Heading";
|
|
|
|
|
default:
|
|
|
|
|
return "unknown heading type";
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2017-06-15 17:07:40 +00:00
|
|
|
static const char *commb_format_to_string(commb_format_t format) {
|
|
|
|
|
switch (format) {
|
|
|
|
|
case COMMB_EMPTY_RESPONSE:
|
|
|
|
|
return "empty response";
|
2019-05-02 09:29:04 +00:00
|
|
|
case COMMB_AMBIGUOUS:
|
|
|
|
|
return "ambiguous format";
|
2021-07-29 11:04:51 +00:00
|
|
|
case COMMB_NOT_DECODED:
|
|
|
|
|
return "not decoded";
|
2017-06-15 17:07:40 +00:00
|
|
|
case COMMB_DATALINK_CAPS:
|
|
|
|
|
return "BDS1,0 Datalink capabilities";
|
|
|
|
|
case COMMB_GICB_CAPS:
|
|
|
|
|
return "BDS1,7 Common usage GICB capabilities";
|
|
|
|
|
case COMMB_AIRCRAFT_IDENT:
|
|
|
|
|
return "BDS2,0 Aircraft identification";
|
|
|
|
|
case COMMB_ACAS_RA:
|
|
|
|
|
return "BDS3,0 ACAS resolution advisory";
|
|
|
|
|
case COMMB_VERTICAL_INTENT:
|
|
|
|
|
return "BDS4,0 Selected vertical intention";
|
|
|
|
|
case COMMB_TRACK_TURN:
|
|
|
|
|
return "BDS5,0 Track and turn report";
|
|
|
|
|
case COMMB_HEADING_SPEED:
|
|
|
|
|
return "BDS6,0 Heading and speed report";
|
2021-07-29 11:04:49 +00:00
|
|
|
case COMMB_MRAR:
|
|
|
|
|
return "BDS4,4 Meterological routine air report";
|
2021-07-29 11:04:52 +00:00
|
|
|
case COMMB_AIRBORNE_POSITION:
|
|
|
|
|
return "BDS0,5 Extended squitter airborne position";
|
2017-06-15 17:07:40 +00:00
|
|
|
default:
|
|
|
|
|
return "unknown format";
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2017-12-07 16:34:08 +00:00
|
|
|
static const char *nav_modes_to_string(nav_modes_t flags)
|
2017-06-16 09:39:01 +00:00
|
|
|
{
|
|
|
|
|
static char buf[128];
|
|
|
|
|
|
|
|
|
|
buf[0] = 0;
|
2017-12-07 16:34:08 +00:00
|
|
|
if (flags & NAV_MODE_AUTOPILOT)
|
2017-06-16 09:39:01 +00:00
|
|
|
strcat(buf, "autopilot ");
|
2017-12-07 16:34:08 +00:00
|
|
|
if (flags & NAV_MODE_VNAV)
|
2017-06-16 09:39:01 +00:00
|
|
|
strcat(buf, "vnav ");
|
2017-12-07 16:34:08 +00:00
|
|
|
if (flags & NAV_MODE_ALT_HOLD)
|
2017-06-16 09:39:01 +00:00
|
|
|
strcat(buf, "althold ");
|
2017-12-07 16:34:08 +00:00
|
|
|
if (flags & NAV_MODE_APPROACH)
|
2017-06-16 09:39:01 +00:00
|
|
|
strcat(buf, "approach ");
|
2017-12-07 16:34:08 +00:00
|
|
|
if (flags & NAV_MODE_LNAV)
|
2017-06-16 09:39:01 +00:00
|
|
|
strcat(buf, "lnav ");
|
2017-12-07 16:34:08 +00:00
|
|
|
if (flags & NAV_MODE_TCAS)
|
|
|
|
|
strcat(buf, "tcas ");
|
2017-06-16 09:39:01 +00:00
|
|
|
|
|
|
|
|
if (buf[0] != 0)
|
|
|
|
|
buf[strlen(buf)-1] = 0;
|
|
|
|
|
|
|
|
|
|
return buf;
|
|
|
|
|
}
|
|
|
|
|
|
2017-12-07 19:36:07 +00:00
|
|
|
static const char *sil_type_to_string(sil_type_t type)
|
|
|
|
|
{
|
|
|
|
|
switch (type) {
|
|
|
|
|
case SIL_UNKNOWN: return "unknown type";
|
|
|
|
|
case SIL_PER_HOUR: return "per flight hour";
|
|
|
|
|
case SIL_PER_SAMPLE: return "per sample";
|
|
|
|
|
default: return "invalid type";
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2018-01-09 14:43:58 +00:00
|
|
|
static const char *emergency_to_string(emergency_t emergency)
|
|
|
|
|
{
|
|
|
|
|
switch (emergency) {
|
|
|
|
|
case EMERGENCY_NONE: return "no emergency";
|
|
|
|
|
case EMERGENCY_GENERAL: return "general emergency (7700)";
|
|
|
|
|
case EMERGENCY_LIFEGUARD: return "lifeguard / medical emergency";
|
|
|
|
|
case EMERGENCY_MINFUEL: return "minimum fuel";
|
|
|
|
|
case EMERGENCY_NORDO: return "no communications (7600)";
|
|
|
|
|
case EMERGENCY_UNLAWFUL: return "unlawful interference (7500)";
|
|
|
|
|
case EMERGENCY_DOWNED: return "downed aircraft";
|
|
|
|
|
default: return "reserved";
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2021-07-29 11:04:49 +00:00
|
|
|
static const char *mrar_source_to_string(mrar_source_t source)
|
|
|
|
|
{
|
|
|
|
|
switch (source) {
|
|
|
|
|
case MRAR_SOURCE_INVALID: return "invalid";
|
|
|
|
|
case MRAR_SOURCE_INS: return "INS";
|
|
|
|
|
case MRAR_SOURCE_GNSS: return "GNSS";
|
|
|
|
|
case MRAR_SOURCE_DMEDME: return "DME/DME";
|
|
|
|
|
case MRAR_SOURCE_VORDME: return "VOR/DME";
|
|
|
|
|
default: return "reserved";
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static const char *hazard_to_string(hazard_t hazard)
|
|
|
|
|
{
|
|
|
|
|
switch (hazard) {
|
|
|
|
|
case HAZARD_NIL: return "nil";
|
|
|
|
|
case HAZARD_LIGHT: return "light";
|
|
|
|
|
case HAZARD_MODERATE: return "moderate";
|
|
|
|
|
case HAZARD_SEVERE: return "severe";
|
|
|
|
|
default: return "invalid hazard severity";
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-08-27 13:34:14 +00:00
|
|
|
static void print_hex_bytes(unsigned char *data, size_t len) {
|
|
|
|
|
size_t i;
|
|
|
|
|
for (i = 0; i < len; ++i) {
|
|
|
|
|
printf("%02X", (unsigned)data[i]);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int esTypeHasSubtype(unsigned metype)
|
|
|
|
|
{
|
|
|
|
|
if (metype <= 18) {
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (metype >= 20 && metype <= 22) {
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static const char *esTypeName(unsigned metype, unsigned mesub)
|
|
|
|
|
{
|
|
|
|
|
switch (metype) {
|
|
|
|
|
case 0:
|
|
|
|
|
return "No position information (airborne or surface)";
|
|
|
|
|
|
|
|
|
|
case 1: case 2: case 3: case 4:
|
|
|
|
|
return "Aircraft identification and category";
|
|
|
|
|
|
|
|
|
|
case 5: case 6: case 7: case 8:
|
|
|
|
|
return "Surface position";
|
|
|
|
|
|
|
|
|
|
case 9: case 10: case 11: case 12:
|
|
|
|
|
case 13: case 14: case 15: case 16:
|
|
|
|
|
case 17: case 18:
|
|
|
|
|
return "Airborne position (barometric altitude)";
|
|
|
|
|
|
|
|
|
|
case 19:
|
|
|
|
|
switch (mesub) {
|
|
|
|
|
case 1:
|
|
|
|
|
return "Airborne velocity over ground, subsonic";
|
|
|
|
|
case 2:
|
|
|
|
|
return "Airborne velocity over ground, supersonic";
|
|
|
|
|
case 3:
|
|
|
|
|
return "Airspeed and heading, subsonic";
|
|
|
|
|
case 4:
|
|
|
|
|
return "Airspeed and heading, supersonic";
|
|
|
|
|
default:
|
|
|
|
|
return "Unknown";
|
2016-01-01 13:42:30 +00:00
|
|
|
}
|
2016-08-27 13:34:14 +00:00
|
|
|
|
|
|
|
|
case 20: case 21: case 22:
|
2017-06-15 17:07:40 +00:00
|
|
|
return "Airborne position (geometric altitude)";
|
2016-08-27 13:34:14 +00:00
|
|
|
|
|
|
|
|
case 23:
|
|
|
|
|
switch (mesub) {
|
|
|
|
|
case 0:
|
|
|
|
|
return "Test message";
|
|
|
|
|
case 7:
|
|
|
|
|
return "National use / 1090-WP-15-20 Mode A squawk";
|
|
|
|
|
default:
|
|
|
|
|
return "Unknown";
|
2015-01-21 00:23:48 +00:00
|
|
|
}
|
2016-08-27 13:34:14 +00:00
|
|
|
|
|
|
|
|
case 24:
|
|
|
|
|
return "Reserved for surface system status";
|
|
|
|
|
|
|
|
|
|
case 27:
|
|
|
|
|
return "Reserved for trajectory change";
|
|
|
|
|
|
|
|
|
|
case 28:
|
|
|
|
|
switch (mesub) {
|
|
|
|
|
case 1:
|
|
|
|
|
return "Emergency/priority status";
|
|
|
|
|
case 2:
|
|
|
|
|
return "ACAS RA broadcast";
|
|
|
|
|
default:
|
|
|
|
|
return "Unknown";
|
2015-01-21 00:23:48 +00:00
|
|
|
}
|
2016-08-27 13:34:14 +00:00
|
|
|
|
|
|
|
|
case 29:
|
|
|
|
|
switch (mesub) {
|
2016-09-14 15:12:08 +00:00
|
|
|
case 0:
|
|
|
|
|
return "Target state and status (V1)";
|
2016-08-27 13:34:14 +00:00
|
|
|
case 1:
|
2016-09-14 15:12:08 +00:00
|
|
|
return "Target state and status (V2)";
|
2016-08-27 13:34:14 +00:00
|
|
|
default:
|
|
|
|
|
return "Unknown";
|
2015-01-21 00:23:48 +00:00
|
|
|
}
|
|
|
|
|
|
2016-09-14 15:12:08 +00:00
|
|
|
case 30:
|
|
|
|
|
return "Aircraft Operational Coordination";
|
|
|
|
|
|
2016-08-27 13:34:14 +00:00
|
|
|
case 31: // Aircraft Operational Status
|
|
|
|
|
switch (mesub) {
|
|
|
|
|
case 0:
|
|
|
|
|
return "Aircraft operational status (airborne)";
|
|
|
|
|
case 1:
|
|
|
|
|
return "Aircraft operational status (surface)";
|
|
|
|
|
default:
|
|
|
|
|
return "Unknown";
|
|
|
|
|
}
|
2015-01-21 00:23:48 +00:00
|
|
|
|
2016-08-27 13:34:14 +00:00
|
|
|
default:
|
|
|
|
|
return "Unknown";
|
|
|
|
|
}
|
2015-01-21 00:23:48 +00:00
|
|
|
}
|
|
|
|
|
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
void displayModesMessage(struct modesMessage *mm) {
|
|
|
|
|
int j;
|
|
|
|
|
|
|
|
|
|
// Handle only addresses mode first.
|
|
|
|
|
if (Modes.onlyaddr) {
|
|
|
|
|
printf("%06x\n", mm->addr);
|
|
|
|
|
return; // Enough for --onlyaddr mode
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Show the raw message.
|
|
|
|
|
if (Modes.mlat && mm->timestampMsg) {
|
2015-04-18 23:57:24 +00:00
|
|
|
printf("@%012" PRIX64, mm->timestampMsg);
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
} else
|
|
|
|
|
printf("*");
|
|
|
|
|
|
|
|
|
|
for (j = 0; j < mm->msgbits/8; j++) printf("%02x", mm->msg[j]);
|
|
|
|
|
printf(";\n");
|
|
|
|
|
|
|
|
|
|
if (Modes.raw) {
|
|
|
|
|
fflush(stdout); // Provide data to the reader ASAP
|
|
|
|
|
return; // Enough for --raw mode
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (mm->msgtype < 32)
|
2015-01-21 00:23:48 +00:00
|
|
|
printf("CRC: %06x\n", mm->crc);
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
|
|
|
|
|
if (mm->correctedbits != 0)
|
|
|
|
|
printf("No. of bit errors fixed: %d\n", mm->correctedbits);
|
|
|
|
|
|
2015-01-22 01:01:39 +00:00
|
|
|
if (mm->signalLevel > 0)
|
|
|
|
|
printf("RSSI: %.1f dBFS\n", 10 * log10(mm->signalLevel));
|
2014-09-15 01:49:11 +00:00
|
|
|
|
2015-01-21 13:32:17 +00:00
|
|
|
if (mm->score)
|
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 11:43:38 +00:00
|
|
|
printf("Score: %d (%s)\n", mm->score, score_to_string(mm->score));
|
2015-01-21 13:32:17 +00:00
|
|
|
|
2015-06-29 11:42:50 +00:00
|
|
|
if (mm->timestampMsg) {
|
|
|
|
|
if (mm->timestampMsg == MAGIC_MLAT_TIMESTAMP)
|
|
|
|
|
printf("This is a synthetic MLAT message.\n");
|
|
|
|
|
else
|
2016-08-27 13:34:14 +00:00
|
|
|
printf("Time: %.2fus\n", mm->timestampMsg / 12.0);
|
2015-06-29 11:42:50 +00:00
|
|
|
}
|
2014-09-27 15:45:39 +00:00
|
|
|
|
2016-08-27 13:34:14 +00:00
|
|
|
switch (mm->msgtype) {
|
|
|
|
|
case 0:
|
|
|
|
|
printf("DF:0 addr:%06X VS:%u CC:%u SL:%u RI:%u AC:%u\n",
|
|
|
|
|
mm->addr, mm->VS, mm->CC, mm->SL, mm->RI, mm->AC);
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case 4:
|
|
|
|
|
printf("DF:4 addr:%06X FS:%u DR:%u UM:%u AC:%u\n",
|
|
|
|
|
mm->addr, mm->FS, mm->DR, mm->UM, mm->AC);
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case 5:
|
|
|
|
|
printf("DF:5 addr:%06X FS:%u DR:%u UM:%u ID:%u\n",
|
|
|
|
|
mm->addr, mm->FS, mm->DR, mm->UM, mm->ID);
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case 11:
|
|
|
|
|
printf("DF:11 AA:%06X IID:%u CA:%u\n",
|
|
|
|
|
mm->AA, mm->IID, mm->CA);
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case 16:
|
|
|
|
|
printf("DF:16 addr:%06x VS:%u SL:%u RI:%u AC:%u MV:",
|
|
|
|
|
mm->addr, mm->VS, mm->SL, mm->RI, mm->AC);
|
|
|
|
|
print_hex_bytes(mm->MV, sizeof(mm->MV));
|
|
|
|
|
printf("\n");
|
|
|
|
|
break;
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
|
2016-08-27 13:34:14 +00:00
|
|
|
case 17:
|
|
|
|
|
printf("DF:17 AA:%06X CA:%u ME:",
|
|
|
|
|
mm->AA, mm->CA);
|
|
|
|
|
print_hex_bytes(mm->ME, sizeof(mm->ME));
|
|
|
|
|
printf("\n");
|
|
|
|
|
break;
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
|
2016-08-27 13:34:14 +00:00
|
|
|
case 18:
|
|
|
|
|
printf("DF:18 AA:%06X CF:%u ME:",
|
|
|
|
|
mm->AA, mm->CF);
|
|
|
|
|
print_hex_bytes(mm->ME, sizeof(mm->ME));
|
|
|
|
|
printf("\n");
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case 20:
|
|
|
|
|
printf("DF:20 addr:%06X FS:%u DR:%u UM:%u AC:%u MB:",
|
|
|
|
|
mm->addr, mm->FS, mm->DR, mm->UM, mm->AC);
|
|
|
|
|
print_hex_bytes(mm->MB, sizeof(mm->MB));
|
|
|
|
|
printf("\n");
|
|
|
|
|
break;
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
|
2016-08-27 13:34:14 +00:00
|
|
|
case 21:
|
|
|
|
|
printf("DF:21 addr:%06x FS:%u DR:%u UM:%u ID:%u MB:",
|
|
|
|
|
mm->addr, mm->FS, mm->DR, mm->UM, mm->ID);
|
|
|
|
|
print_hex_bytes(mm->MB, sizeof(mm->MB));
|
|
|
|
|
printf("\n");
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
case 24:
|
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 11:43:38 +00:00
|
|
|
/* 25 .. 31 also remapped to 24 during decoding */
|
2016-08-27 13:34:14 +00:00
|
|
|
printf("DF:24 addr:%06x KE:%u ND:%u MD:",
|
|
|
|
|
mm->addr, mm->KE, mm->ND);
|
|
|
|
|
print_hex_bytes(mm->MD, sizeof(mm->MD));
|
|
|
|
|
printf("\n");
|
|
|
|
|
break;
|
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 11:43:38 +00:00
|
|
|
|
|
|
|
|
default:
|
|
|
|
|
printf("DF:%u", mm->msgtype);
|
|
|
|
|
break;
|
2016-08-27 13:34:14 +00:00
|
|
|
}
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
|
2016-08-27 13:34:14 +00:00
|
|
|
printf(" %s", df_to_string(mm->msgtype));
|
|
|
|
|
if (mm->msgtype == 17 || mm->msgtype == 18) {
|
|
|
|
|
if (esTypeHasSubtype(mm->metype)) {
|
|
|
|
|
printf(" %s (%u/%u)",
|
|
|
|
|
esTypeName(mm->metype, mm->mesub),
|
|
|
|
|
mm->metype,
|
|
|
|
|
mm->mesub);
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
} else {
|
2016-08-27 13:34:14 +00:00
|
|
|
printf(" %s (%u)",
|
|
|
|
|
esTypeName(mm->metype, mm->mesub),
|
|
|
|
|
mm->metype);
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
}
|
2016-08-27 13:34:14 +00:00
|
|
|
}
|
2019-11-27 12:30:41 +00:00
|
|
|
if (mm->reliable) {
|
|
|
|
|
printf(" (reliable)");
|
|
|
|
|
}
|
2016-08-27 13:34:14 +00:00
|
|
|
printf("\n");
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
|
2017-06-15 17:07:40 +00:00
|
|
|
if (mm->msgtype == 20 || mm->msgtype == 21) {
|
|
|
|
|
printf(" Comm-B format: %s\n", commb_format_to_string(mm->commb_format));
|
|
|
|
|
}
|
|
|
|
|
|
2016-08-27 13:34:14 +00:00
|
|
|
if (mm->addr & MODES_NON_ICAO_ADDRESS) {
|
2016-09-14 15:37:07 +00:00
|
|
|
printf(" Other Address: %06X (%s)\n", mm->addr & 0xFFFFFF, addrtype_to_string(mm->addrtype));
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
} else {
|
2016-09-14 15:37:07 +00:00
|
|
|
printf(" ICAO Address: %06X (%s)\n", mm->addr, addrtype_to_string(mm->addrtype));
|
2016-08-27 13:34:14 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (mm->airground != AG_INVALID) {
|
|
|
|
|
printf(" Air/Ground: %s\n",
|
|
|
|
|
airground_to_string(mm->airground));
|
|
|
|
|
}
|
|
|
|
|
|
2017-12-07 16:34:08 +00:00
|
|
|
if (mm->altitude_baro_valid) {
|
|
|
|
|
printf(" Baro altitude: %d %s\n",
|
|
|
|
|
mm->altitude_baro,
|
|
|
|
|
altitude_unit_to_string(mm->altitude_baro_unit));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (mm->altitude_geom_valid) {
|
|
|
|
|
printf(" Geom altitude: %d %s\n",
|
|
|
|
|
mm->altitude_geom,
|
|
|
|
|
altitude_unit_to_string(mm->altitude_geom_unit));
|
2016-08-27 13:34:14 +00:00
|
|
|
}
|
|
|
|
|
|
2017-06-15 17:07:40 +00:00
|
|
|
if (mm->geom_delta_valid) {
|
|
|
|
|
printf(" Geom - baro: %d ft\n",
|
|
|
|
|
mm->geom_delta);
|
|
|
|
|
}
|
|
|
|
|
|
2017-06-15 20:07:53 +00:00
|
|
|
if (mm->heading_valid) {
|
|
|
|
|
printf(" %-13s %.1f\n", heading_type_to_string(mm->heading_type), mm->heading);
|
2016-08-27 13:34:14 +00:00
|
|
|
}
|
|
|
|
|
|
2017-06-15 17:07:40 +00:00
|
|
|
if (mm->track_rate_valid) {
|
|
|
|
|
printf(" Track rate: %.2f deg/sec %s\n", mm->track_rate, mm->track_rate < 0 ? "left" : mm->track_rate > 0 ? "right" : "");
|
2016-08-27 13:34:14 +00:00
|
|
|
}
|
|
|
|
|
|
2017-06-15 17:07:40 +00:00
|
|
|
if (mm->roll_valid) {
|
|
|
|
|
printf(" Roll: %.1f degrees %s\n", mm->roll, mm->roll < -0.05 ? "left" : mm->roll > 0.05 ? "right" : "");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (mm->gs_valid) {
|
2017-12-07 16:34:08 +00:00
|
|
|
printf(" Groundspeed: %.1f kt", mm->gs.selected);
|
|
|
|
|
if (mm->gs.v0 != mm->gs.selected) {
|
|
|
|
|
printf(" (v0: %.1f kt)", mm->gs.v0);
|
|
|
|
|
}
|
|
|
|
|
if (mm->gs.v2 != mm->gs.selected) {
|
|
|
|
|
printf(" (v2: %.1f kt)", mm->gs.v2);
|
|
|
|
|
}
|
|
|
|
|
printf("\n");
|
2017-06-15 17:07:40 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (mm->ias_valid) {
|
|
|
|
|
printf(" IAS: %u kt\n", mm->ias);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (mm->tas_valid) {
|
|
|
|
|
printf(" TAS: %u kt\n", mm->tas);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (mm->mach_valid) {
|
|
|
|
|
printf(" Mach number: %.3f\n", mm->mach);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (mm->baro_rate_valid) {
|
|
|
|
|
printf(" Baro rate: %d ft/min\n", mm->baro_rate);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (mm->geom_rate_valid) {
|
|
|
|
|
printf(" Geom rate: %d ft/min\n", mm->geom_rate);
|
2016-08-27 13:34:14 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (mm->squawk_valid) {
|
|
|
|
|
printf(" Squawk: %04x\n",
|
|
|
|
|
mm->squawk);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (mm->callsign_valid) {
|
|
|
|
|
printf(" Ident: %s\n",
|
|
|
|
|
mm->callsign);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (mm->category_valid) {
|
|
|
|
|
printf(" Category: %02X\n",
|
|
|
|
|
mm->category);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (mm->cpr_valid) {
|
2016-10-01 23:16:29 +00:00
|
|
|
printf(" CPR type: %s\n"
|
2017-12-07 16:34:08 +00:00
|
|
|
" CPR odd flag: %s\n",
|
2016-10-01 23:16:29 +00:00
|
|
|
cpr_type_to_string(mm->cpr_type),
|
2017-12-07 16:34:08 +00:00
|
|
|
mm->cpr_odd ? "odd" : "even");
|
2016-08-27 13:34:14 +00:00
|
|
|
|
|
|
|
|
if (mm->cpr_decoded) {
|
|
|
|
|
printf(" CPR latitude: %.5f (%u)\n"
|
|
|
|
|
" CPR longitude: %.5f (%u)\n"
|
2017-12-07 16:34:08 +00:00
|
|
|
" CPR decoding: %s\n"
|
|
|
|
|
" NIC: %u\n"
|
|
|
|
|
" Rc: %.3f km / %.1f NM\n",
|
2016-08-27 13:34:14 +00:00
|
|
|
mm->decoded_lat,
|
|
|
|
|
mm->cpr_lat,
|
|
|
|
|
mm->decoded_lon,
|
|
|
|
|
mm->cpr_lon,
|
2017-12-07 16:34:08 +00:00
|
|
|
mm->cpr_relative ? "local" : "global",
|
|
|
|
|
mm->decoded_nic,
|
|
|
|
|
mm->decoded_rc / 1000.0,
|
|
|
|
|
mm->decoded_rc / 1852.0);
|
2016-08-27 13:34:14 +00:00
|
|
|
} else {
|
|
|
|
|
printf(" CPR latitude: (%u)\n"
|
|
|
|
|
" CPR longitude: (%u)\n"
|
|
|
|
|
" CPR decoding: none\n",
|
|
|
|
|
mm->cpr_lat,
|
|
|
|
|
mm->cpr_lon);
|
|
|
|
|
}
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
}
|
|
|
|
|
|
2017-12-07 16:34:08 +00:00
|
|
|
if (mm->accuracy.nic_a_valid) {
|
|
|
|
|
printf(" NIC-A: %d\n", mm->accuracy.nic_a);
|
|
|
|
|
}
|
|
|
|
|
if (mm->accuracy.nic_b_valid) {
|
|
|
|
|
printf(" NIC-B: %d\n", mm->accuracy.nic_b);
|
|
|
|
|
}
|
|
|
|
|
if (mm->accuracy.nic_c_valid) {
|
|
|
|
|
printf(" NIC-C: %d\n", mm->accuracy.nic_c);
|
|
|
|
|
}
|
|
|
|
|
if (mm->accuracy.nic_baro_valid) {
|
|
|
|
|
printf(" NIC-baro: %d\n", mm->accuracy.nic_baro);
|
|
|
|
|
}
|
|
|
|
|
if (mm->accuracy.nac_p_valid) {
|
|
|
|
|
printf(" NACp: %d\n", mm->accuracy.nac_p);
|
|
|
|
|
}
|
|
|
|
|
if (mm->accuracy.nac_v_valid) {
|
|
|
|
|
printf(" NACv: %d\n", mm->accuracy.nac_v);
|
|
|
|
|
}
|
|
|
|
|
if (mm->accuracy.gva_valid) {
|
|
|
|
|
printf(" GVA: %d\n", mm->accuracy.gva);
|
|
|
|
|
}
|
2017-12-07 19:36:07 +00:00
|
|
|
if (mm->accuracy.sil_type != SIL_INVALID) {
|
|
|
|
|
const char *sil_description;
|
|
|
|
|
switch (mm->accuracy.sil) {
|
|
|
|
|
case 1:
|
|
|
|
|
sil_description = "p <= 0.1%";
|
|
|
|
|
break;
|
|
|
|
|
case 2:
|
|
|
|
|
sil_description = "p <= 0.001%";
|
|
|
|
|
break;
|
|
|
|
|
case 3:
|
|
|
|
|
sil_description = "p <= 0.00001%";
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
sil_description = "p > 0.1%";
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
printf(" SIL: %d (%s, %s)\n",
|
2017-12-07 16:34:08 +00:00
|
|
|
mm->accuracy.sil,
|
2017-12-07 19:36:07 +00:00
|
|
|
sil_description,
|
|
|
|
|
sil_type_to_string(mm->accuracy.sil_type));
|
2017-12-07 16:34:08 +00:00
|
|
|
}
|
|
|
|
|
if (mm->accuracy.sda_valid) {
|
|
|
|
|
printf(" SDA: %d\n", mm->accuracy.sda);
|
|
|
|
|
}
|
|
|
|
|
|
2016-08-29 10:11:04 +00:00
|
|
|
if (mm->opstatus.valid) {
|
|
|
|
|
printf(" Aircraft Operational Status:\n");
|
|
|
|
|
printf(" Version: %d\n", mm->opstatus.version);
|
|
|
|
|
|
|
|
|
|
printf(" Capability classes: ");
|
|
|
|
|
if (mm->opstatus.cc_acas) printf("ACAS ");
|
|
|
|
|
if (mm->opstatus.cc_cdti) printf("CDTI ");
|
|
|
|
|
if (mm->opstatus.cc_1090_in) printf("1090IN ");
|
|
|
|
|
if (mm->opstatus.cc_arv) printf("ARV ");
|
|
|
|
|
if (mm->opstatus.cc_ts) printf("TS ");
|
|
|
|
|
if (mm->opstatus.cc_tc) printf("TC=%d ", mm->opstatus.cc_tc);
|
|
|
|
|
if (mm->opstatus.cc_uat_in) printf("UATIN ");
|
|
|
|
|
if (mm->opstatus.cc_poa) printf("POA ");
|
|
|
|
|
if (mm->opstatus.cc_b2_low) printf("B2-LOW ");
|
|
|
|
|
if (mm->opstatus.cc_lw_valid) printf("L/W=%d ", mm->opstatus.cc_lw);
|
|
|
|
|
if (mm->opstatus.cc_antenna_offset) printf("GPS-OFFSET=%d ", mm->opstatus.cc_antenna_offset);
|
|
|
|
|
printf("\n");
|
|
|
|
|
|
|
|
|
|
printf(" Operational modes: ");
|
|
|
|
|
if (mm->opstatus.om_acas_ra) printf("ACASRA ");
|
|
|
|
|
if (mm->opstatus.om_ident) printf("IDENT ");
|
|
|
|
|
if (mm->opstatus.om_atc) printf("ATC ");
|
|
|
|
|
if (mm->opstatus.om_saf) printf("SAF ");
|
|
|
|
|
printf("\n");
|
|
|
|
|
|
|
|
|
|
if (mm->mesub == 1)
|
2017-06-15 20:07:53 +00:00
|
|
|
printf(" Track/heading: %s\n", heading_type_to_string(mm->opstatus.tah));
|
|
|
|
|
printf(" Heading ref dir: %s\n", heading_type_to_string(mm->opstatus.hrd));
|
2016-08-29 10:11:04 +00:00
|
|
|
}
|
|
|
|
|
|
2017-12-07 16:34:08 +00:00
|
|
|
if (mm->nav.heading_valid)
|
|
|
|
|
printf(" Selected heading: %.1f\n", mm->nav.heading);
|
|
|
|
|
if (mm->nav.fms_altitude_valid)
|
|
|
|
|
printf(" FMS selected altitude: %u ft\n", mm->nav.fms_altitude);
|
|
|
|
|
if (mm->nav.mcp_altitude_valid)
|
|
|
|
|
printf(" MCP selected altitude: %u ft\n", mm->nav.mcp_altitude);
|
|
|
|
|
if (mm->nav.qnh_valid)
|
|
|
|
|
printf(" QNH: %.1f millibars\n", mm->nav.qnh);
|
|
|
|
|
if (mm->nav.altitude_source != NAV_ALT_INVALID) {
|
|
|
|
|
printf(" Target altitude source: ");
|
|
|
|
|
switch (mm->nav.altitude_source) {
|
|
|
|
|
case NAV_ALT_AIRCRAFT:
|
|
|
|
|
printf("aircraft altitude\n");
|
|
|
|
|
break;
|
|
|
|
|
case NAV_ALT_MCP:
|
|
|
|
|
printf("MCP selected altitude\n");
|
|
|
|
|
break;
|
|
|
|
|
case NAV_ALT_FMS:
|
|
|
|
|
printf("FMS selected altitude\n");
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
printf("unknown\n");
|
2017-06-15 17:07:40 +00:00
|
|
|
}
|
2017-12-07 16:34:08 +00:00
|
|
|
}
|
2017-06-15 17:07:40 +00:00
|
|
|
|
2017-12-07 16:34:08 +00:00
|
|
|
if (mm->nav.modes_valid) {
|
|
|
|
|
printf(" Nav modes: %s\n", nav_modes_to_string(mm->nav.modes));
|
2016-08-29 10:11:04 +00:00
|
|
|
}
|
|
|
|
|
|
2018-01-09 14:43:58 +00:00
|
|
|
if (mm->emergency_valid) {
|
|
|
|
|
printf(" Emergency/priority: %s\n", emergency_to_string(mm->emergency));
|
|
|
|
|
}
|
2017-12-07 16:34:08 +00:00
|
|
|
|
2021-07-29 11:04:49 +00:00
|
|
|
if (mm->mrar_source_valid)
|
|
|
|
|
printf(" MRAR FOM/Source: %s\n", mrar_source_to_string(mm->mrar_source));
|
|
|
|
|
if (mm->wind_valid) {
|
|
|
|
|
printf(" Wind speed: %.0f kt\n", mm->wind_speed);
|
|
|
|
|
printf(" Wind direction: %.1f degrees\n", mm->wind_dir);
|
|
|
|
|
}
|
|
|
|
|
if (mm->temperature_valid)
|
|
|
|
|
printf(" Air temperature: %.1f degrees C\n", mm->temperature);
|
|
|
|
|
if (mm->pressure_valid)
|
|
|
|
|
printf(" Static pressure: %.0f hPa\n", mm->pressure);
|
|
|
|
|
if (mm->turbulence_valid)
|
|
|
|
|
printf(" Turbulence: %s\n", hazard_to_string(mm->turbulence));
|
|
|
|
|
if (mm->humidity_valid)
|
|
|
|
|
printf(" Humidity: %.0f%%\n", mm->humidity);
|
|
|
|
|
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
printf("\n");
|
2016-02-05 15:41:10 +00:00
|
|
|
fflush(stdout);
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
}
|
2014-09-26 21:42:38 +00:00
|
|
|
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
//
|
|
|
|
|
//=========================================================================
|
|
|
|
|
//
|
2017-06-15 17:16:51 +00:00
|
|
|
// When a new message is available, because it was decoded from the RTL device,
|
|
|
|
|
// file, or received in the TCP input port, or any other way we can receive a
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
// decoded message, we call this function in order to use the message.
|
|
|
|
|
//
|
|
|
|
|
// Basically this function passes a raw message to the upper layers for further
|
|
|
|
|
// processing and visualization
|
|
|
|
|
//
|
|
|
|
|
void useModesMessage(struct modesMessage *mm) {
|
2015-02-08 14:27:03 +00:00
|
|
|
struct aircraft *a;
|
|
|
|
|
|
2015-01-21 00:23:48 +00:00
|
|
|
++Modes.stats_current.messages_total;
|
2021-02-04 08:33:26 +00:00
|
|
|
if (mm->msgtype >= 0 && mm->msgtype < 32) {
|
|
|
|
|
++Modes.stats_current.messages_by_df[mm->msgtype];
|
|
|
|
|
}
|
2015-01-13 19:10:55 +00:00
|
|
|
|
2015-02-08 14:27:03 +00:00
|
|
|
// Track aircraft state
|
|
|
|
|
a = trackUpdateFromMessage(mm);
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
|
2015-01-21 00:23:48 +00:00
|
|
|
// In non-interactive non-quiet mode, display messages on standard output
|
2015-02-22 23:01:54 +00:00
|
|
|
if (!Modes.interactive && !Modes.quiet && (!Modes.show_only || mm->addr == Modes.show_only)) {
|
2015-01-21 00:23:48 +00:00
|
|
|
displayModesMessage(mm);
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
}
|
2015-01-21 00:23:48 +00:00
|
|
|
|
2019-11-27 12:57:01 +00:00
|
|
|
// Feed output clients; modesQueueOutput appropriately filters messages to the different outputs.
|
2015-02-08 14:27:03 +00:00
|
|
|
if (Modes.net) {
|
2019-11-27 12:57:01 +00:00
|
|
|
modesQueueOutput(mm, a);
|
2015-02-08 14:27:03 +00:00
|
|
|
}
|
Split into separate module files
Ok - this is likely to upset some people. Up until now, the vast
majority of the code has been in just one file - dump1090.c. This file
has grown so that it was approaching of 5000 lines long, and it was
becoming unmanagable. So I've split the file into several modules,
hopefully along fairly logical boundaries. The files are :
1) dump1090.c : Basically just the main() entry function, the help
function, the RTL dongle hardware interface, and a few orphan functions
that don't really fit anywhere else.
2) mode_s.c : This contains all the mode S / ADSB decoding functions.
3) mode_ac.c : This contains all the mode A & C decoding functions
4) interactive.c : This contains all the functions to maintain an
internal list of aircraft seen over the last period, and functions to
print them out to the local console.
5) net_io.c : This contains all the network input/output functions
allowing data to be passed in/out to/from other receivers, in formats
such as SBS-1/3, Beast, AVR and JavaScript.
Hopefully this should provide an easier way forward if/when more
functions are added.
2013-08-19 17:57:03 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
//
|
|
|
|
|
// ===================== Mode S detection and decoding ===================
|
2014-05-14 17:36:36 +00:00
|
|
|
//
|