2013-08-19 16:55:17 +02:00
|
|
|
// dump1090, a Mode S messages decoder for RTLSDR devices.
|
|
|
|
//
|
|
|
|
// Copyright (C) 2012 by Salvatore Sanfilippo <antirez@gmail.com>
|
|
|
|
//
|
|
|
|
// All rights reserved.
|
|
|
|
//
|
|
|
|
// Redistribution and use in source and binary forms, with or without
|
|
|
|
// modification, are permitted provided that the following conditions are
|
|
|
|
// met:
|
|
|
|
//
|
|
|
|
// * 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.
|
|
|
|
//
|
2013-09-30 12:46:36 +02:00
|
|
|
#include "coaa.h"
|
2013-05-25 00:32:12 +02:00
|
|
|
#include "dump1090.h"
|
2013-08-19 16:55:17 +02:00
|
|
|
//
|
|
|
|
// ============================= Utility functions ==========================
|
|
|
|
//
|
2013-04-29 23:14:06 +02:00
|
|
|
void sigintHandler(int dummy) {
|
|
|
|
MODES_NOTUSED(dummy);
|
2013-05-21 13:08:35 +02:00
|
|
|
signal(SIGINT, SIG_DFL); // reset signal handler - bit extra safety
|
|
|
|
Modes.exit = 1; // Signal to threads that we are done
|
2013-04-29 23:14:06 +02:00
|
|
|
}
|
2013-08-19 16:55:17 +02:00
|
|
|
//
|
2014-02-22 23:11:11 +01:00
|
|
|
// =============================== Terminal handling ========================
|
|
|
|
//
|
|
|
|
#ifndef _WIN32
|
|
|
|
// Get the number of rows after the terminal changes size.
|
|
|
|
int getTermRows() {
|
|
|
|
struct winsize w;
|
|
|
|
ioctl(STDOUT_FILENO, TIOCGWINSZ, &w);
|
|
|
|
return (w.ws_row);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Handle resizing terminal
|
|
|
|
void sigWinchCallback() {
|
|
|
|
signal(SIGWINCH, SIG_IGN);
|
|
|
|
Modes.interactive_rows = getTermRows();
|
|
|
|
interactiveShowData();
|
|
|
|
signal(SIGWINCH, sigWinchCallback);
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
int getTermRows() { return MODES_INTERACTIVE_ROWS;}
|
|
|
|
#endif
|
|
|
|
//
|
2013-08-19 16:55:17 +02:00
|
|
|
// =============================== Initialization ===========================
|
|
|
|
//
|
2013-01-05 13:52:25 +01:00
|
|
|
void modesInitConfig(void) {
|
2013-05-02 14:05:25 +02:00
|
|
|
// Default everything to zero/NULL
|
|
|
|
memset(&Modes, 0, sizeof(Modes));
|
|
|
|
|
|
|
|
// Now initialise things that should not be 0/NULL to their defaults
|
2013-08-19 16:55:17 +02:00
|
|
|
Modes.gain = MODES_MAX_GAIN;
|
|
|
|
Modes.freq = MODES_DEFAULT_FREQ;
|
2014-07-10 19:11:13 +02:00
|
|
|
Modes.ppm_error = MODES_DEFAULT_PPM;
|
2013-08-19 16:55:17 +02:00
|
|
|
Modes.check_crc = 1;
|
2014-10-03 23:55:21 +02:00
|
|
|
Modes.net_heartbeat_interval = MODES_NET_HEARTBEAT_INTERVAL;
|
2013-08-19 16:55:17 +02:00
|
|
|
Modes.net_output_sbs_port = MODES_NET_OUTPUT_SBS_PORT;
|
|
|
|
Modes.net_output_raw_port = MODES_NET_OUTPUT_RAW_PORT;
|
|
|
|
Modes.net_input_raw_port = MODES_NET_INPUT_RAW_PORT;
|
|
|
|
Modes.net_output_beast_port = MODES_NET_OUTPUT_BEAST_PORT;
|
|
|
|
Modes.net_input_beast_port = MODES_NET_INPUT_BEAST_PORT;
|
|
|
|
Modes.net_http_port = MODES_NET_HTTP_PORT;
|
2014-02-22 23:11:11 +01:00
|
|
|
Modes.interactive_rows = getTermRows();
|
2013-08-19 16:55:17 +02:00
|
|
|
Modes.interactive_delete_ttl = MODES_INTERACTIVE_DELETE_TTL;
|
|
|
|
Modes.interactive_display_ttl = MODES_INTERACTIVE_DISPLAY_TTL;
|
|
|
|
Modes.fUserLat = MODES_USER_LATITUDE_DFLT;
|
|
|
|
Modes.fUserLon = MODES_USER_LONGITUDE_DFLT;
|
2013-01-05 13:52:25 +01: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 19:57:03 +02:00
|
|
|
//
|
|
|
|
//=========================================================================
|
|
|
|
//
|
2013-01-05 13:52:25 +01:00
|
|
|
void modesInit(void) {
|
|
|
|
int i, q;
|
|
|
|
|
2014-07-10 19:11:13 +02:00
|
|
|
pthread_mutex_init(&Modes.pDF_mutex,NULL);
|
2013-01-05 13:52:25 +01:00
|
|
|
pthread_mutex_init(&Modes.data_mutex,NULL);
|
|
|
|
pthread_cond_init(&Modes.data_cond,NULL);
|
2013-04-10 13:16:25 +02:00
|
|
|
|
|
|
|
// Allocate the various buffers used by Modes
|
|
|
|
if ( ((Modes.icao_cache = (uint32_t *) malloc(sizeof(uint32_t) * MODES_ICAO_CACHE_LEN * 2) ) == NULL) ||
|
BUGFIX : Missed data causes timestamp slip
The Mutex on the RTL data reader thread does not "force" the data
processing thread to execute. Therefore, if the processor is busy, it is
possible for a second RTL callback to occur before the data from the
first has been processed. This will cause the loss of the first data,
but worse, it will cause a slip in the timestamp. This upsets Beamfinder
and MLAT operation in PlanePlotter.
To solve this, keep a Fifo buffer which is filled by the callback
thread, and emptied by the data processing thread. The fifo is the same
size as the number of buffers requested in the call to
rtlsdr_read_async().
Note - we only put the value of the pointer supplied in the callback
into the fifo. We do not attempt to cache the data in the buffer pointed
to by the pointer. This would require us to memcopy() 2Mbytes per
second, which we don't want to do if we don't have to because it will
only make the processor loading worse. Instead, we assume that the data
in the buffer will remain valid after the callback returns, at least
until it is overwritten by new data.
It is still possible for us to lose data if we can't process it quickly
enough. However, we can now detect this loss of data when the fifo is
almost full, and correct the timestamp for the lost block/blocks.
2014-02-23 00:11:13 +01:00
|
|
|
((Modes.pFileData = (uint16_t *) malloc(MODES_ASYNC_BUF_SIZE) ) == NULL) ||
|
2013-04-10 13:16:25 +02:00
|
|
|
((Modes.magnitude = (uint16_t *) malloc(MODES_ASYNC_BUF_SIZE+MODES_PREAMBLE_SIZE+MODES_LONG_MSG_SIZE) ) == NULL) ||
|
2014-10-03 23:55:21 +02:00
|
|
|
((Modes.maglut = (uint16_t *) malloc(sizeof(uint16_t) * 256 * 256) ) == NULL) )
|
2013-04-10 13:16:25 +02:00
|
|
|
{
|
2013-01-05 13:52:25 +01:00
|
|
|
fprintf(stderr, "Out of memory allocating data buffer.\n");
|
|
|
|
exit(1);
|
|
|
|
}
|
2013-04-10 13:16:25 +02:00
|
|
|
|
2013-05-02 14:05:25 +02:00
|
|
|
// Clear the buffers that have just been allocated, just in-case
|
|
|
|
memset(Modes.icao_cache, 0, sizeof(uint32_t) * MODES_ICAO_CACHE_LEN * 2);
|
BUGFIX : Missed data causes timestamp slip
The Mutex on the RTL data reader thread does not "force" the data
processing thread to execute. Therefore, if the processor is busy, it is
possible for a second RTL callback to occur before the data from the
first has been processed. This will cause the loss of the first data,
but worse, it will cause a slip in the timestamp. This upsets Beamfinder
and MLAT operation in PlanePlotter.
To solve this, keep a Fifo buffer which is filled by the callback
thread, and emptied by the data processing thread. The fifo is the same
size as the number of buffers requested in the call to
rtlsdr_read_async().
Note - we only put the value of the pointer supplied in the callback
into the fifo. We do not attempt to cache the data in the buffer pointed
to by the pointer. This would require us to memcopy() 2Mbytes per
second, which we don't want to do if we don't have to because it will
only make the processor loading worse. Instead, we assume that the data
in the buffer will remain valid after the callback returns, at least
until it is overwritten by new data.
It is still possible for us to lose data if we can't process it quickly
enough. However, we can now detect this loss of data when the fifo is
almost full, and correct the timestamp for the lost block/blocks.
2014-02-23 00:11:13 +01:00
|
|
|
memset(Modes.pFileData,127, MODES_ASYNC_BUF_SIZE);
|
2013-05-02 14:05:25 +02:00
|
|
|
memset(Modes.magnitude, 0, MODES_ASYNC_BUF_SIZE+MODES_PREAMBLE_SIZE+MODES_LONG_MSG_SIZE);
|
|
|
|
|
2013-05-09 12:29:18 +02:00
|
|
|
// Validate the users Lat/Lon home location inputs
|
|
|
|
if ( (Modes.fUserLat > 90.0) // Latitude must be -90 to +90
|
|
|
|
|| (Modes.fUserLat < -90.0) // and
|
|
|
|
|| (Modes.fUserLon > 360.0) // Longitude must be -180 to +360
|
|
|
|
|| (Modes.fUserLon < -180.0) ) {
|
|
|
|
Modes.fUserLat = Modes.fUserLon = 0.0;
|
|
|
|
} else if (Modes.fUserLon > 180.0) { // If Longitude is +180 to +360, make it -180 to 0
|
|
|
|
Modes.fUserLon -= 360.0;
|
|
|
|
}
|
|
|
|
// If both Lat and Lon are 0.0 then the users location is either invalid/not-set, or (s)he's in the
|
|
|
|
// Atlantic ocean off the west coast of Africa. This is unlikely to be correct.
|
|
|
|
// Set the user LatLon valid flag only if either Lat or Lon are non zero. Note the Greenwich meridian
|
|
|
|
// is at 0.0 Lon,so we must check for either fLat or fLon being non zero not both.
|
|
|
|
// Testing the flag at runtime will be much quicker than ((fLon != 0.0) || (fLat != 0.0))
|
|
|
|
Modes.bUserFlags &= ~MODES_USER_LATLON_VALID;
|
|
|
|
if ((Modes.fUserLat != 0.0) || (Modes.fUserLon != 0.0)) {
|
|
|
|
Modes.bUserFlags |= MODES_USER_LATLON_VALID;
|
|
|
|
}
|
|
|
|
|
2013-04-14 23:51:50 +02:00
|
|
|
// Limit the maximum requested raw output size to less than one Ethernet Block
|
2014-10-03 23:55:21 +02:00
|
|
|
if (Modes.net_output_flush_size > (MODES_OUT_FLUSH_SIZE))
|
|
|
|
{Modes.net_output_flush_size = MODES_OUT_FLUSH_SIZE;}
|
|
|
|
if (Modes.net_output_flush_interval > (MODES_OUT_FLUSH_INTERVAL))
|
|
|
|
{Modes.net_output_flush_interval = MODES_OUT_FLUSH_INTERVAL;}
|
2014-05-27 14:16:57 +02:00
|
|
|
if (Modes.net_sndbuf_size > (MODES_NET_SNDBUF_MAX))
|
|
|
|
{Modes.net_sndbuf_size = MODES_NET_SNDBUF_MAX;}
|
2013-04-14 23:51:50 +02:00
|
|
|
|
2013-05-02 14:05:25 +02:00
|
|
|
// Initialise the Block Timers to something half sensible
|
BUGFIX : Missed data causes timestamp slip
The Mutex on the RTL data reader thread does not "force" the data
processing thread to execute. Therefore, if the processor is busy, it is
possible for a second RTL callback to occur before the data from the
first has been processed. This will cause the loss of the first data,
but worse, it will cause a slip in the timestamp. This upsets Beamfinder
and MLAT operation in PlanePlotter.
To solve this, keep a Fifo buffer which is filled by the callback
thread, and emptied by the data processing thread. The fifo is the same
size as the number of buffers requested in the call to
rtlsdr_read_async().
Note - we only put the value of the pointer supplied in the callback
into the fifo. We do not attempt to cache the data in the buffer pointed
to by the pointer. This would require us to memcopy() 2Mbytes per
second, which we don't want to do if we don't have to because it will
only make the processor loading worse. Instead, we assume that the data
in the buffer will remain valid after the callback returns, at least
until it is overwritten by new data.
It is still possible for us to lose data if we can't process it quickly
enough. However, we can now detect this loss of data when the fifo is
almost full, and correct the timestamp for the lost block/blocks.
2014-02-23 00:11:13 +01:00
|
|
|
ftime(&Modes.stSystemTimeBlk);
|
|
|
|
for (i = 0; i < MODES_ASYNC_BUF_NUMBER; i++)
|
|
|
|
{Modes.stSystemTimeRTL[i] = Modes.stSystemTimeBlk;}
|
2013-01-05 13:52:25 +01:00
|
|
|
|
2013-04-10 21:57:09 +02:00
|
|
|
// Each I and Q value varies from 0 to 255, which represents a range from -1 to +1. To get from the
|
|
|
|
// unsigned (0-255) range you therefore subtract 127 (or 128 or 127.5) from each I and Q, giving you
|
|
|
|
// a range from -127 to +128 (or -128 to +127, or -127.5 to +127.5)..
|
|
|
|
//
|
|
|
|
// To decode the AM signal, you need the magnitude of the waveform, which is given by sqrt((I^2)+(Q^2))
|
|
|
|
// The most this could be is if I&Q are both 128 (or 127 or 127.5), so you could end up with a magnitude
|
|
|
|
// of 181.019 (or 179.605, or 180.312)
|
|
|
|
//
|
2013-04-15 22:55:46 +02:00
|
|
|
// However, in reality the magnitude of the signal should never exceed the range -1 to +1, because the
|
2013-04-10 21:57:09 +02:00
|
|
|
// values are I = rCos(w) and Q = rSin(w). Therefore the integer computed magnitude should (can?) never
|
|
|
|
// exceed 128 (or 127, or 127.5 or whatever)
|
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 19:57:03 +02:00
|
|
|
//
|
|
|
|
// If we scale up the results so that they range from 0 to 65535 (16 bits) then we need to multiply
|
|
|
|
// by 511.99, (or 516.02 or 514). antirez's original code multiplies by 360, presumably because he's
|
|
|
|
// assuming the maximim calculated amplitude is 181.019, and (181.019 * 360) = 65166.
|
|
|
|
//
|
|
|
|
// So lets see if we can improve things by subtracting 127.5, Well in integer arithmatic we can't
|
|
|
|
// subtract half, so, we'll double everything up and subtract one, and then compensate for the doubling
|
|
|
|
// in the multiplier at the end.
|
|
|
|
//
|
|
|
|
// If we do this we can never have I or Q equal to 0 - they can only be as small as +/- 1.
|
|
|
|
// This gives us a minimum magnitude of root 2 (0.707), so the dynamic range becomes (1.414-255). This
|
|
|
|
// also affects our scaling value, which is now 65535/(255 - 1.414), or 258.433254
|
|
|
|
//
|
|
|
|
// The sums then become mag = 258.433254 * (sqrt((I*2-255)^2 + (Q*2-255)^2) - 1.414)
|
|
|
|
// or mag = (258.433254 * sqrt((I*2-255)^2 + (Q*2-255)^2)) - 365.4798
|
|
|
|
//
|
|
|
|
// We also need to clip mag just incaes any rogue I/Q values somehow do have a magnitude greater than 255.
|
|
|
|
//
|
2013-04-19 16:29:39 +02: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 19:57:03 +02:00
|
|
|
for (i = 0; i <= 255; i++) {
|
|
|
|
for (q = 0; q <= 255; q++) {
|
|
|
|
int mag, mag_i, mag_q;
|
2013-04-12 23:39:33 +02: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 19:57:03 +02:00
|
|
|
mag_i = (i * 2) - 255;
|
|
|
|
mag_q = (q * 2) - 255;
|
2013-04-07 17:22:02 +02: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 19:57:03 +02:00
|
|
|
mag = (int) round((sqrt((mag_i*mag_i)+(mag_q*mag_q)) * 258.433254) - 365.4798);
|
2013-04-12 12:15:52 +02: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 19:57:03 +02:00
|
|
|
Modes.maglut[(i*256)+q] = (uint16_t) ((mag < 65535) ? mag : 65535);
|
2013-04-13 02:37:02 +02:00
|
|
|
}
|
2013-01-10 20:58:13 +01:00
|
|
|
}
|
2013-04-12 12:15:52 +02: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 19:57:03 +02:00
|
|
|
// Prepare error correction tables
|
|
|
|
modesInitErrorInfo();
|
2013-01-10 20:58:13 +01:00
|
|
|
}
|
2013-05-10 18:27:34 +02: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 19:57:03 +02:00
|
|
|
// =============================== RTLSDR handling ==========================
|
2013-05-10 18:27:34 +02: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 19:57:03 +02:00
|
|
|
void modesInitRTLSDR(void) {
|
|
|
|
int j;
|
|
|
|
int device_count;
|
|
|
|
char vendor[256], product[256], serial[256];
|
2013-05-10 18:27:34 +02: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 19:57:03 +02:00
|
|
|
device_count = rtlsdr_get_device_count();
|
|
|
|
if (!device_count) {
|
|
|
|
fprintf(stderr, "No supported RTLSDR devices found.\n");
|
|
|
|
exit(1);
|
2013-05-10 18:27:34 +02:00
|
|
|
}
|
2013-04-12 23:03:04 +02: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 19:57:03 +02:00
|
|
|
fprintf(stderr, "Found %d device(s):\n", device_count);
|
|
|
|
for (j = 0; j < device_count; j++) {
|
|
|
|
rtlsdr_get_device_usb_strings(j, vendor, product, serial);
|
|
|
|
fprintf(stderr, "%d: %s, %s, SN: %s %s\n", j, vendor, product, serial,
|
|
|
|
(j == Modes.dev_index) ? "(currently selected)" : "");
|
2013-05-10 18:27:34 +02:00
|
|
|
}
|
2013-01-20 00:13:01 +01: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 19:57:03 +02:00
|
|
|
if (rtlsdr_open(&Modes.dev, Modes.dev_index) < 0) {
|
|
|
|
fprintf(stderr, "Error opening the RTLSDR device: %s\n",
|
|
|
|
strerror(errno));
|
|
|
|
exit(1);
|
2013-05-10 18:27:34 +02:00
|
|
|
}
|
2013-04-12 23:03:04 +02: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 19:57:03 +02:00
|
|
|
// Set gain, frequency, sample rate, and reset the device
|
|
|
|
rtlsdr_set_tuner_gain_mode(Modes.dev,
|
|
|
|
(Modes.gain == MODES_AUTO_GAIN) ? 0 : 1);
|
|
|
|
if (Modes.gain != MODES_AUTO_GAIN) {
|
|
|
|
if (Modes.gain == MODES_MAX_GAIN) {
|
|
|
|
// Find the maximum gain available
|
|
|
|
int numgains;
|
|
|
|
int gains[100];
|
2013-04-12 23:03:04 +02: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 19:57:03 +02:00
|
|
|
numgains = rtlsdr_get_tuner_gains(Modes.dev, gains);
|
|
|
|
Modes.gain = gains[numgains-1];
|
|
|
|
fprintf(stderr, "Max available gain is: %.2f\n", Modes.gain/10.0);
|
2013-05-10 18:27:34 +02: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 19:57:03 +02:00
|
|
|
rtlsdr_set_tuner_gain(Modes.dev, Modes.gain);
|
|
|
|
fprintf(stderr, "Setting gain to: %.2f\n", Modes.gain/10.0);
|
2013-01-20 00:13:01 +01:00
|
|
|
} else {
|
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 19:57:03 +02:00
|
|
|
fprintf(stderr, "Using automatic gain control.\n");
|
2013-01-17 19:12:23 +01: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 19:57:03 +02:00
|
|
|
rtlsdr_set_freq_correction(Modes.dev, Modes.ppm_error);
|
|
|
|
if (Modes.enable_agc) rtlsdr_set_agc_mode(Modes.dev, 1);
|
|
|
|
rtlsdr_set_center_freq(Modes.dev, Modes.freq);
|
|
|
|
rtlsdr_set_sample_rate(Modes.dev, MODES_DEFAULT_RATE);
|
|
|
|
rtlsdr_reset_buffer(Modes.dev);
|
|
|
|
fprintf(stderr, "Gain reported by device: %.2f\n",
|
|
|
|
rtlsdr_get_tuner_gain(Modes.dev)/10.0);
|
2013-01-17 19:12:23 +01:00
|
|
|
}
|
2013-05-24 23:29:00 +02: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 19:57:03 +02:00
|
|
|
//=========================================================================
|
2013-05-24 23:29:00 +02: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 19:57:03 +02:00
|
|
|
// We use a thread reading data in background, while the main thread
|
|
|
|
// handles decoding and visualization of data to the user.
|
2013-05-24 23:29:00 +02: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 19:57:03 +02:00
|
|
|
// The reading thread calls the RTLSDR API to read data asynchronously, and
|
|
|
|
// uses a callback to populate the data buffer.
|
2013-05-24 23:29:00 +02: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 19:57:03 +02:00
|
|
|
// A Mutex is used to avoid races with the decoding thread.
|
2013-05-24 23:29:00 +02: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 19:57:03 +02:00
|
|
|
void rtlsdrCallback(unsigned char *buf, uint32_t len, void *ctx) {
|
2013-04-24 21:46:59 +02: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 19:57:03 +02:00
|
|
|
MODES_NOTUSED(ctx);
|
2013-04-24 21:46:59 +02:00
|
|
|
|
BUGFIX : Missed data causes timestamp slip
The Mutex on the RTL data reader thread does not "force" the data
processing thread to execute. Therefore, if the processor is busy, it is
possible for a second RTL callback to occur before the data from the
first has been processed. This will cause the loss of the first data,
but worse, it will cause a slip in the timestamp. This upsets Beamfinder
and MLAT operation in PlanePlotter.
To solve this, keep a Fifo buffer which is filled by the callback
thread, and emptied by the data processing thread. The fifo is the same
size as the number of buffers requested in the call to
rtlsdr_read_async().
Note - we only put the value of the pointer supplied in the callback
into the fifo. We do not attempt to cache the data in the buffer pointed
to by the pointer. This would require us to memcopy() 2Mbytes per
second, which we don't want to do if we don't have to because it will
only make the processor loading worse. Instead, we assume that the data
in the buffer will remain valid after the callback returns, at least
until it is overwritten by new data.
It is still possible for us to lose data if we can't process it quickly
enough. However, we can now detect this loss of data when the fifo is
almost full, and correct the timestamp for the lost block/blocks.
2014-02-23 00:11:13 +01:00
|
|
|
// Lock the data buffer variables before accessing them
|
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 19:57:03 +02:00
|
|
|
pthread_mutex_lock(&Modes.data_mutex);
|
BUGFIX : Missed data causes timestamp slip
The Mutex on the RTL data reader thread does not "force" the data
processing thread to execute. Therefore, if the processor is busy, it is
possible for a second RTL callback to occur before the data from the
first has been processed. This will cause the loss of the first data,
but worse, it will cause a slip in the timestamp. This upsets Beamfinder
and MLAT operation in PlanePlotter.
To solve this, keep a Fifo buffer which is filled by the callback
thread, and emptied by the data processing thread. The fifo is the same
size as the number of buffers requested in the call to
rtlsdr_read_async().
Note - we only put the value of the pointer supplied in the callback
into the fifo. We do not attempt to cache the data in the buffer pointed
to by the pointer. This would require us to memcopy() 2Mbytes per
second, which we don't want to do if we don't have to because it will
only make the processor loading worse. Instead, we assume that the data
in the buffer will remain valid after the callback returns, at least
until it is overwritten by new data.
It is still possible for us to lose data if we can't process it quickly
enough. However, we can now detect this loss of data when the fifo is
almost full, and correct the timestamp for the lost block/blocks.
2014-02-23 00:11:13 +01:00
|
|
|
|
|
|
|
Modes.iDataIn &= (MODES_ASYNC_BUF_NUMBER-1); // Just incase!!!
|
|
|
|
|
|
|
|
// Get the system time for this block
|
|
|
|
ftime(&Modes.stSystemTimeRTL[Modes.iDataIn]);
|
|
|
|
|
|
|
|
if (len > MODES_ASYNC_BUF_SIZE) {len = MODES_ASYNC_BUF_SIZE;}
|
|
|
|
|
|
|
|
// Queue the new data
|
|
|
|
Modes.pData[Modes.iDataIn] = (uint16_t *) buf;
|
|
|
|
Modes.iDataIn = (MODES_ASYNC_BUF_NUMBER-1) & (Modes.iDataIn + 1);
|
|
|
|
Modes.iDataReady = (MODES_ASYNC_BUF_NUMBER-1) & (Modes.iDataIn - Modes.iDataOut);
|
|
|
|
|
|
|
|
if (Modes.iDataReady == 0) {
|
|
|
|
// Ooooops. We've just received the MODES_ASYNC_BUF_NUMBER'th outstanding buffer
|
|
|
|
// This means that RTLSDR is currently overwriting the MODES_ASYNC_BUF_NUMBER+1
|
|
|
|
// buffer, but we havent yet processed it, so we're going to lose it. There
|
|
|
|
// isn't much we can do to recover the lost data, but we can correct things to
|
|
|
|
// avoid any additional problems.
|
|
|
|
Modes.iDataOut = (MODES_ASYNC_BUF_NUMBER-1) & (Modes.iDataOut+1);
|
|
|
|
Modes.iDataReady = (MODES_ASYNC_BUF_NUMBER-1);
|
|
|
|
Modes.iDataLost++;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Signal to the other thread that new data is ready, and unlock
|
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 19:57:03 +02:00
|
|
|
pthread_cond_signal(&Modes.data_cond);
|
|
|
|
pthread_mutex_unlock(&Modes.data_mutex);
|
2013-01-12 11:46:32 +01: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 19:57:03 +02:00
|
|
|
//
|
|
|
|
//=========================================================================
|
|
|
|
//
|
|
|
|
// This is used when --ifile is specified in order to read data from file
|
|
|
|
// instead of using an RTLSDR device
|
|
|
|
//
|
|
|
|
void readDataFromFile(void) {
|
|
|
|
pthread_mutex_lock(&Modes.data_mutex);
|
BUGFIX : Missed data causes timestamp slip
The Mutex on the RTL data reader thread does not "force" the data
processing thread to execute. Therefore, if the processor is busy, it is
possible for a second RTL callback to occur before the data from the
first has been processed. This will cause the loss of the first data,
but worse, it will cause a slip in the timestamp. This upsets Beamfinder
and MLAT operation in PlanePlotter.
To solve this, keep a Fifo buffer which is filled by the callback
thread, and emptied by the data processing thread. The fifo is the same
size as the number of buffers requested in the call to
rtlsdr_read_async().
Note - we only put the value of the pointer supplied in the callback
into the fifo. We do not attempt to cache the data in the buffer pointed
to by the pointer. This would require us to memcopy() 2Mbytes per
second, which we don't want to do if we don't have to because it will
only make the processor loading worse. Instead, we assume that the data
in the buffer will remain valid after the callback returns, at least
until it is overwritten by new data.
It is still possible for us to lose data if we can't process it quickly
enough. However, we can now detect this loss of data when the fifo is
almost full, and correct the timestamp for the lost block/blocks.
2014-02-23 00:11:13 +01:00
|
|
|
while(Modes.exit == 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 19:57:03 +02:00
|
|
|
ssize_t nread, toread;
|
|
|
|
unsigned char *p;
|
2013-01-12 11:46:32 +01:00
|
|
|
|
BUGFIX : Missed data causes timestamp slip
The Mutex on the RTL data reader thread does not "force" the data
processing thread to execute. Therefore, if the processor is busy, it is
possible for a second RTL callback to occur before the data from the
first has been processed. This will cause the loss of the first data,
but worse, it will cause a slip in the timestamp. This upsets Beamfinder
and MLAT operation in PlanePlotter.
To solve this, keep a Fifo buffer which is filled by the callback
thread, and emptied by the data processing thread. The fifo is the same
size as the number of buffers requested in the call to
rtlsdr_read_async().
Note - we only put the value of the pointer supplied in the callback
into the fifo. We do not attempt to cache the data in the buffer pointed
to by the pointer. This would require us to memcopy() 2Mbytes per
second, which we don't want to do if we don't have to because it will
only make the processor loading worse. Instead, we assume that the data
in the buffer will remain valid after the callback returns, at least
until it is overwritten by new data.
It is still possible for us to lose data if we can't process it quickly
enough. However, we can now detect this loss of data when the fifo is
almost full, and correct the timestamp for the lost block/blocks.
2014-02-23 00:11:13 +01:00
|
|
|
if (Modes.iDataReady) {
|
|
|
|
pthread_cond_wait(&Modes.data_cond, &Modes.data_mutex);
|
2013-05-24 23:29:00 +02:00
|
|
|
continue;
|
|
|
|
}
|
2013-01-13 01:39:29 +01: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 19:57:03 +02:00
|
|
|
if (Modes.interactive) {
|
|
|
|
// When --ifile and --interactive are used together, slow down
|
|
|
|
// playing at the natural rate of the RTLSDR received.
|
|
|
|
pthread_mutex_unlock(&Modes.data_mutex);
|
|
|
|
usleep(64000);
|
|
|
|
pthread_mutex_lock(&Modes.data_mutex);
|
|
|
|
}
|
2013-01-13 01:39:29 +01: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 19:57:03 +02:00
|
|
|
toread = MODES_ASYNC_BUF_SIZE;
|
BUGFIX : Missed data causes timestamp slip
The Mutex on the RTL data reader thread does not "force" the data
processing thread to execute. Therefore, if the processor is busy, it is
possible for a second RTL callback to occur before the data from the
first has been processed. This will cause the loss of the first data,
but worse, it will cause a slip in the timestamp. This upsets Beamfinder
and MLAT operation in PlanePlotter.
To solve this, keep a Fifo buffer which is filled by the callback
thread, and emptied by the data processing thread. The fifo is the same
size as the number of buffers requested in the call to
rtlsdr_read_async().
Note - we only put the value of the pointer supplied in the callback
into the fifo. We do not attempt to cache the data in the buffer pointed
to by the pointer. This would require us to memcopy() 2Mbytes per
second, which we don't want to do if we don't have to because it will
only make the processor loading worse. Instead, we assume that the data
in the buffer will remain valid after the callback returns, at least
until it is overwritten by new data.
It is still possible for us to lose data if we can't process it quickly
enough. However, we can now detect this loss of data when the fifo is
almost full, and correct the timestamp for the lost block/blocks.
2014-02-23 00:11:13 +01:00
|
|
|
p = (unsigned char *) Modes.pFileData;
|
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 19:57:03 +02:00
|
|
|
while(toread) {
|
|
|
|
nread = read(Modes.fd, p, toread);
|
|
|
|
if (nread <= 0) {
|
|
|
|
Modes.exit = 1; // Signal the other threads to exit.
|
|
|
|
break;
|
2013-01-15 00:35:21 +01: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 19:57:03 +02:00
|
|
|
p += nread;
|
|
|
|
toread -= nread;
|
2013-05-09 16:59:26 +02: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 19:57:03 +02:00
|
|
|
if (toread) {
|
|
|
|
// Not enough data on file to fill the buffer? Pad with no signal.
|
|
|
|
memset(p,127,toread);
|
2013-05-09 16:59:26 +02:00
|
|
|
}
|
BUGFIX : Missed data causes timestamp slip
The Mutex on the RTL data reader thread does not "force" the data
processing thread to execute. Therefore, if the processor is busy, it is
possible for a second RTL callback to occur before the data from the
first has been processed. This will cause the loss of the first data,
but worse, it will cause a slip in the timestamp. This upsets Beamfinder
and MLAT operation in PlanePlotter.
To solve this, keep a Fifo buffer which is filled by the callback
thread, and emptied by the data processing thread. The fifo is the same
size as the number of buffers requested in the call to
rtlsdr_read_async().
Note - we only put the value of the pointer supplied in the callback
into the fifo. We do not attempt to cache the data in the buffer pointed
to by the pointer. This would require us to memcopy() 2Mbytes per
second, which we don't want to do if we don't have to because it will
only make the processor loading worse. Instead, we assume that the data
in the buffer will remain valid after the callback returns, at least
until it is overwritten by new data.
It is still possible for us to lose data if we can't process it quickly
enough. However, we can now detect this loss of data when the fifo is
almost full, and correct the timestamp for the lost block/blocks.
2014-02-23 00:11:13 +01:00
|
|
|
|
|
|
|
Modes.iDataIn &= (MODES_ASYNC_BUF_NUMBER-1); // Just incase!!!
|
|
|
|
|
|
|
|
// Get the system time for this block
|
|
|
|
ftime(&Modes.stSystemTimeRTL[Modes.iDataIn]);
|
|
|
|
|
|
|
|
// Queue the new data
|
|
|
|
Modes.pData[Modes.iDataIn] = Modes.pFileData;
|
|
|
|
Modes.iDataIn = (MODES_ASYNC_BUF_NUMBER-1) & (Modes.iDataIn + 1);
|
|
|
|
Modes.iDataReady = (MODES_ASYNC_BUF_NUMBER-1) & (Modes.iDataIn - Modes.iDataOut);
|
|
|
|
|
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 19:57:03 +02:00
|
|
|
// Signal to the other thread that new data is ready
|
|
|
|
pthread_cond_signal(&Modes.data_cond);
|
2013-01-13 01:39:29 +01: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 19:57:03 +02:00
|
|
|
}
|
|
|
|
//
|
|
|
|
//=========================================================================
|
|
|
|
//
|
|
|
|
// We read data using a thread, so the main thread only handles decoding
|
|
|
|
// without caring about data acquisition
|
|
|
|
//
|
|
|
|
void *readerThreadEntryPoint(void *arg) {
|
|
|
|
MODES_NOTUSED(arg);
|
2013-01-13 01:39:29 +01: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 19:57:03 +02:00
|
|
|
if (Modes.filename == NULL) {
|
|
|
|
rtlsdr_read_async(Modes.dev, rtlsdrCallback, NULL,
|
|
|
|
MODES_ASYNC_BUF_NUMBER,
|
|
|
|
MODES_ASYNC_BUF_SIZE);
|
|
|
|
} else {
|
|
|
|
readDataFromFile();
|
2013-01-15 00:35:21 +01: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 19:57:03 +02:00
|
|
|
// Signal to the other thread that new data is ready - dummy really so threads don't mutually lock
|
|
|
|
pthread_cond_signal(&Modes.data_cond);
|
|
|
|
pthread_mutex_unlock(&Modes.data_mutex);
|
|
|
|
#ifndef _WIN32
|
|
|
|
pthread_exit(NULL);
|
|
|
|
#else
|
|
|
|
return NULL;
|
|
|
|
#endif
|
2013-01-13 01:39:29 +01:00
|
|
|
}
|
2013-05-24 23:29:00 +02: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 19:57:03 +02:00
|
|
|
// ============================== Snip mode =================================
|
2013-05-24 23:29:00 +02: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 19:57:03 +02:00
|
|
|
// Get raw IQ samples and filter everything is < than the specified level
|
|
|
|
// for more than 256 samples in order to reduce example file size
|
2013-05-24 23:29:00 +02: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 19:57:03 +02:00
|
|
|
void snipMode(int level) {
|
|
|
|
int i, q;
|
|
|
|
uint64_t c = 0;
|
2013-05-24 23:29:00 +02: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 19:57:03 +02:00
|
|
|
while ((i = getchar()) != EOF && (q = getchar()) != EOF) {
|
|
|
|
if (abs(i-127) < level && abs(q-127) < level) {
|
|
|
|
c++;
|
|
|
|
if (c > MODES_PREAMBLE_SIZE) continue;
|
2013-05-24 23:29:00 +02:00
|
|
|
} else {
|
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 19:57:03 +02:00
|
|
|
c = 0;
|
2013-01-13 01:39:29 +01: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 19:57:03 +02:00
|
|
|
putchar(i);
|
|
|
|
putchar(q);
|
2013-01-13 01:39:29 +01:00
|
|
|
}
|
|
|
|
}
|
2013-05-24 23:29:00 +02: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 19:57:03 +02:00
|
|
|
// ================================ Main ====================================
|
|
|
|
//
|
2013-01-05 13:52:25 +01:00
|
|
|
void showHelp(void) {
|
|
|
|
printf(
|
2013-04-14 23:03:19 +02:00
|
|
|
"-----------------------------------------------------------------------------\n"
|
|
|
|
"| dump1090 ModeS Receiver Ver : " MODES_DUMP1090_VERSION " |\n"
|
|
|
|
"-----------------------------------------------------------------------------\n"
|
|
|
|
"--device-index <index> Select RTL device (default: 0)\n"
|
2014-06-01 02:14:40 +02:00
|
|
|
"--gain <db> Set gain (default: max gain. Use -10 for auto-gain)\n"
|
2013-04-14 23:03:19 +02:00
|
|
|
"--enable-agc Enable the Automatic Gain Control (default: off)\n"
|
|
|
|
"--freq <hz> Set frequency (default: 1090 Mhz)\n"
|
|
|
|
"--ifile <filename> Read data from file (use '-' for stdin)\n"
|
|
|
|
"--interactive Interactive mode refreshing data on screen\n"
|
|
|
|
"--interactive-rows <num> Max number of rows in interactive mode (default: 15)\n"
|
|
|
|
"--interactive-ttl <sec> Remove from list if idle for <sec> (default: 60)\n"
|
|
|
|
"--interactive-rtl1090 Display flight table in RTL1090 format\n"
|
|
|
|
"--raw Show only messages hex values\n"
|
|
|
|
"--net Enable networking\n"
|
2013-04-23 00:31:59 +02:00
|
|
|
"--modeac Enable decoding of SSR Modes 3/A & 3/C\n"
|
2013-04-14 23:03:19 +02:00
|
|
|
"--net-only Enable just networking, no RTL device or file used\n"
|
2014-10-30 13:06:03 +01:00
|
|
|
"--net-bind-address <ip> IP address to bind to (default: Any; Use 127.0.0.1 for private)\n"
|
2013-04-14 23:03:19 +02:00
|
|
|
"--net-http-port <port> HTTP server port (default: 8080)\n"
|
2013-05-24 23:29:00 +02:00
|
|
|
"--net-ri-port <port> TCP raw input listen port (default: 30001)\n"
|
|
|
|
"--net-ro-port <port> TCP raw output listen port (default: 30002)\n"
|
2013-04-14 23:03:19 +02:00
|
|
|
"--net-sbs-port <port> TCP BaseStation output listen port (default: 30003)\n"
|
2013-05-24 23:29:00 +02:00
|
|
|
"--net-bi-port <port> TCP Beast input listen port (default: 30004)\n"
|
|
|
|
"--net-bo-port <port> TCP Beast output listen port (default: 30005)\n"
|
2014-10-03 23:55:21 +02:00
|
|
|
"--net-ro-size <size> TCP output minimum size (default: 0)\n"
|
|
|
|
"--net-ro-interval <rate> TCP output memory flush rate in seconds (default: 0)\n"
|
2014-06-25 05:58:46 +02:00
|
|
|
"--net-heartbeat <rate> TCP heartbeat rate in seconds (default: 60 sec; 0 to disable)\n"
|
2014-05-27 14:16:57 +02:00
|
|
|
"--net-buffer <n> TCP buffer size 64Kb * (2^n) (default: n=0, 64Kb)\n"
|
2013-10-10 00:44:58 +02:00
|
|
|
"--lat <latitude> Reference/receiver latitude for surface posn (opt)\n"
|
2013-05-09 12:29:18 +02:00
|
|
|
"--lon <longitude> Reference/receiver longitude for surface posn (opt)\n"
|
2013-04-26 11:12:47 +02:00
|
|
|
"--fix Enable single-bits error correction using CRC\n"
|
2013-04-14 23:03:19 +02:00
|
|
|
"--no-fix Disable single-bits error correction using CRC\n"
|
|
|
|
"--no-crc-check Disable messages with broken CRC (discouraged)\n"
|
2013-05-22 14:23:54 +02:00
|
|
|
"--phase-enhance Enable phase enhancement\n"
|
2013-04-14 23:03:19 +02:00
|
|
|
"--aggressive More CPU for more messages (two bits fixes, ...)\n"
|
|
|
|
"--mlat display raw messages in Beast ascii mode\n"
|
|
|
|
"--stats With --ifile print stats at exit. No other output\n"
|
2014-09-25 21:33:50 +02:00
|
|
|
"--stats-every <seconds> Show and reset stats every <seconds> seconds\n"
|
2013-04-14 23:03:19 +02:00
|
|
|
"--onlyaddr Show only ICAO addresses (testing purposes)\n"
|
|
|
|
"--metric Use metric units (meters, km/h, ...)\n"
|
|
|
|
"--snip <level> Strip IQ file removing samples < level\n"
|
|
|
|
"--debug <flags> Debug mode (verbose), see README for details\n"
|
|
|
|
"--quiet Disable output to stdout. Use for daemon applications\n"
|
|
|
|
"--ppm <error> Set receiver error in parts per million (default 0)\n"
|
|
|
|
"--help Show this help\n"
|
2013-01-26 01:07:43 +01:00
|
|
|
"\n"
|
|
|
|
"Debug mode flags: d = Log frames decoded with errors\n"
|
|
|
|
" D = Log frames decoded with zero errors\n"
|
|
|
|
" c = Log frames with bad CRC\n"
|
|
|
|
" C = Log frames with good CRC\n"
|
|
|
|
" p = Log frames with bad preamble\n"
|
|
|
|
" n = Log network debugging info\n"
|
2013-04-14 23:03:19 +02:00
|
|
|
" j = Log frames to frames.js, loadable by debug.html\n"
|
2013-01-05 13:52:25 +01:00
|
|
|
);
|
|
|
|
}
|
2014-04-25 15:48:14 +02:00
|
|
|
|
|
|
|
#ifdef _WIN32
|
|
|
|
void showCopyright(void) {
|
|
|
|
uint64_t llTime = time(NULL) + 1;
|
|
|
|
|
|
|
|
printf(
|
|
|
|
"-----------------------------------------------------------------------------\n"
|
|
|
|
"| dump1090 ModeS Receiver Ver : " MODES_DUMP1090_VERSION " |\n"
|
|
|
|
"-----------------------------------------------------------------------------\n"
|
|
|
|
"\n"
|
|
|
|
" Copyright (C) 2012 by Salvatore Sanfilippo <antirez@gmail.com>\n"
|
|
|
|
" Copyright (C) 2014 by Malcolm Robb <support@attavionics.com>\n"
|
|
|
|
"\n"
|
|
|
|
" All rights reserved.\n"
|
|
|
|
"\n"
|
|
|
|
" THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS\n"
|
|
|
|
" ""AS IS"" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT\n"
|
|
|
|
" LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR\n"
|
|
|
|
" A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT\n"
|
|
|
|
" HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,\n"
|
|
|
|
" SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT\n"
|
|
|
|
" LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,\n"
|
|
|
|
" DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY\n"
|
|
|
|
" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT\n"
|
|
|
|
" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE\n"
|
|
|
|
" OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.\n"
|
|
|
|
"\n"
|
|
|
|
" For further details refer to <https://github.com/MalcolmRobb/dump1090>\n"
|
|
|
|
"\n"
|
|
|
|
);
|
|
|
|
|
|
|
|
// delay for 1 second to give the user a chance to read the copyright
|
|
|
|
while (llTime >= time(NULL)) {}
|
|
|
|
}
|
|
|
|
#endif
|
2014-09-25 21:33:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
static void display_stats(void) {
|
|
|
|
int j;
|
|
|
|
time_t now = time(NULL);
|
|
|
|
|
|
|
|
printf("\n\n");
|
|
|
|
if (Modes.interactive)
|
|
|
|
interactiveShowData();
|
|
|
|
|
|
|
|
printf("Statistics as at %s", ctime(&now));
|
2014-09-25 23:02:52 +02:00
|
|
|
|
2014-09-25 21:35:54 +02:00
|
|
|
printf("%d sample blocks processed\n", Modes.stat_blocks_processed);
|
|
|
|
printf("%d sample blocks dropped\n", Modes.stat_blocks_dropped);
|
2014-09-25 21:33:50 +02:00
|
|
|
|
|
|
|
printf("%d ModeA/C detected\n", Modes.stat_ModeAC);
|
|
|
|
printf("%d valid Mode-S preambles\n", Modes.stat_valid_preamble);
|
|
|
|
printf("%d DF-?? fields corrected for length\n", Modes.stat_DF_Len_Corrected);
|
|
|
|
printf("%d DF-?? fields corrected for type\n", Modes.stat_DF_Type_Corrected);
|
|
|
|
printf("%d demodulated with 0 errors\n", Modes.stat_demodulated0);
|
|
|
|
printf("%d demodulated with 1 error\n", Modes.stat_demodulated1);
|
|
|
|
printf("%d demodulated with 2 errors\n", Modes.stat_demodulated2);
|
|
|
|
printf("%d demodulated with > 2 errors\n", Modes.stat_demodulated3);
|
|
|
|
printf("%d with good crc\n", Modes.stat_goodcrc);
|
|
|
|
printf("%d with bad crc\n", Modes.stat_badcrc);
|
|
|
|
printf("%d errors corrected\n", Modes.stat_fixed);
|
|
|
|
|
|
|
|
for (j = 0; j < MODES_MAX_BITERRORS; j++) {
|
|
|
|
printf(" %d with %d bit %s\n", Modes.stat_bit_fix[j], j+1, (j==0)?"error":"errors");
|
|
|
|
}
|
|
|
|
|
|
|
|
if (Modes.phase_enhance) {
|
|
|
|
printf("%d phase enhancement attempts\n", Modes.stat_out_of_phase);
|
|
|
|
printf("%d phase enhanced demodulated with 0 errors\n", Modes.stat_ph_demodulated0);
|
|
|
|
printf("%d phase enhanced demodulated with 1 error\n", Modes.stat_ph_demodulated1);
|
|
|
|
printf("%d phase enhanced demodulated with 2 errors\n", Modes.stat_ph_demodulated2);
|
|
|
|
printf("%d phase enhanced demodulated with > 2 errors\n", Modes.stat_ph_demodulated3);
|
|
|
|
printf("%d phase enhanced with good crc\n", Modes.stat_ph_goodcrc);
|
|
|
|
printf("%d phase enhanced with bad crc\n", Modes.stat_ph_badcrc);
|
|
|
|
printf("%d phase enhanced errors corrected\n", Modes.stat_ph_fixed);
|
|
|
|
|
|
|
|
for (j = 0; j < MODES_MAX_BITERRORS; j++) {
|
|
|
|
printf(" %d with %d bit %s\n", Modes.stat_ph_bit_fix[j], j+1, (j==0)?"error":"errors");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
printf("%d total usable messages\n", Modes.stat_goodcrc + Modes.stat_ph_goodcrc + Modes.stat_fixed + Modes.stat_ph_fixed);
|
|
|
|
fflush(stdout);
|
2014-09-25 23:02:52 +02:00
|
|
|
|
|
|
|
Modes.stat_blocks_processed =
|
|
|
|
Modes.stat_blocks_dropped = 0;
|
|
|
|
|
|
|
|
Modes.stat_ModeAC =
|
|
|
|
Modes.stat_valid_preamble =
|
|
|
|
Modes.stat_DF_Len_Corrected =
|
|
|
|
Modes.stat_DF_Type_Corrected =
|
|
|
|
Modes.stat_demodulated0 =
|
|
|
|
Modes.stat_demodulated1 =
|
|
|
|
Modes.stat_demodulated2 =
|
|
|
|
Modes.stat_demodulated3 =
|
|
|
|
Modes.stat_goodcrc =
|
|
|
|
Modes.stat_badcrc =
|
|
|
|
Modes.stat_fixed = 0;
|
|
|
|
|
|
|
|
Modes.stat_out_of_phase =
|
|
|
|
Modes.stat_ph_demodulated0 =
|
|
|
|
Modes.stat_ph_demodulated1 =
|
|
|
|
Modes.stat_ph_demodulated2 =
|
|
|
|
Modes.stat_ph_demodulated3 =
|
|
|
|
Modes.stat_ph_goodcrc =
|
|
|
|
Modes.stat_ph_badcrc =
|
|
|
|
Modes.stat_ph_fixed = 0;
|
|
|
|
|
|
|
|
for (j = 0; j < MODES_MAX_BITERRORS; j++) {
|
|
|
|
Modes.stat_ph_bit_fix[j] = 0;
|
|
|
|
Modes.stat_bit_fix[j] = 0;
|
|
|
|
}
|
2014-09-25 21:33:50 +02: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 19:57:03 +02:00
|
|
|
//
|
|
|
|
//=========================================================================
|
|
|
|
//
|
|
|
|
// This function is called a few times every second by main in order to
|
|
|
|
// perform tasks we need to do continuously, like accepting new clients
|
|
|
|
// from the net, refreshing the screen in interactive mode, and so forth
|
|
|
|
//
|
2013-01-13 01:39:29 +01:00
|
|
|
void backgroundTasks(void) {
|
2014-09-25 21:33:50 +02:00
|
|
|
static time_t next_stats;
|
|
|
|
|
2013-01-13 01:39:29 +01:00
|
|
|
if (Modes.net) {
|
2014-10-03 23:55:21 +02:00
|
|
|
modesNetPeriodicWork();
|
2013-04-25 00:47:08 +02:00
|
|
|
}
|
|
|
|
|
2013-05-08 20:48:08 +02:00
|
|
|
// If Modes.aircrafts is not NULL, remove any stale aircraft
|
2013-08-19 16:55:17 +02:00
|
|
|
if (Modes.aircrafts) {
|
|
|
|
interactiveRemoveStaleAircrafts();
|
|
|
|
}
|
2013-04-25 00:47:08 +02:00
|
|
|
|
|
|
|
// Refresh screen when in interactive mode
|
2013-08-19 16:55:17 +02:00
|
|
|
if (Modes.interactive) {
|
2013-04-25 00:47:08 +02:00
|
|
|
interactiveShowData();
|
2013-01-13 01:39:29 +01:00
|
|
|
}
|
2014-09-25 21:33:50 +02:00
|
|
|
|
|
|
|
if (Modes.stats > 0) {
|
|
|
|
time_t now = time(NULL);
|
|
|
|
if (now > next_stats) {
|
|
|
|
if (next_stats != 0)
|
|
|
|
display_stats();
|
|
|
|
next_stats = now + Modes.stats;
|
|
|
|
}
|
|
|
|
}
|
2013-01-13 01:39:29 +01: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 19:57:03 +02:00
|
|
|
//
|
|
|
|
//=========================================================================
|
|
|
|
//
|
2014-07-09 00:34:43 +02:00
|
|
|
int verbose_device_search(char *s)
|
|
|
|
{
|
|
|
|
int i, device_count, device, offset;
|
|
|
|
char *s2;
|
|
|
|
char vendor[256], product[256], serial[256];
|
|
|
|
device_count = rtlsdr_get_device_count();
|
|
|
|
if (!device_count) {
|
|
|
|
fprintf(stderr, "No supported devices found.\n");
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
fprintf(stderr, "Found %d device(s):\n", device_count);
|
|
|
|
for (i = 0; i < device_count; i++) {
|
|
|
|
rtlsdr_get_device_usb_strings(i, vendor, product, serial);
|
|
|
|
fprintf(stderr, " %d: %s, %s, SN: %s\n", i, vendor, product, serial);
|
|
|
|
}
|
|
|
|
fprintf(stderr, "\n");
|
|
|
|
/* does string look like raw id number */
|
|
|
|
device = (int)strtol(s, &s2, 0);
|
|
|
|
if (s2[0] == '\0' && device >= 0 && device < device_count) {
|
|
|
|
fprintf(stderr, "Using device %d: %s\n",
|
|
|
|
device, rtlsdr_get_device_name((uint32_t)device));
|
|
|
|
return device;
|
|
|
|
}
|
|
|
|
/* does string exact match a serial */
|
|
|
|
for (i = 0; i < device_count; i++) {
|
|
|
|
rtlsdr_get_device_usb_strings(i, vendor, product, serial);
|
|
|
|
if (strcmp(s, serial) != 0) {
|
|
|
|
continue;}
|
|
|
|
device = i;
|
|
|
|
fprintf(stderr, "Using device %d: %s\n",
|
|
|
|
device, rtlsdr_get_device_name((uint32_t)device));
|
|
|
|
return device;
|
|
|
|
}
|
|
|
|
/* does string prefix match a serial */
|
|
|
|
for (i = 0; i < device_count; i++) {
|
|
|
|
rtlsdr_get_device_usb_strings(i, vendor, product, serial);
|
|
|
|
if (strncmp(s, serial, strlen(s)) != 0) {
|
|
|
|
continue;}
|
|
|
|
device = i;
|
|
|
|
fprintf(stderr, "Using device %d: %s\n",
|
|
|
|
device, rtlsdr_get_device_name((uint32_t)device));
|
|
|
|
return device;
|
|
|
|
}
|
|
|
|
/* does string suffix match a serial */
|
|
|
|
for (i = 0; i < device_count; i++) {
|
|
|
|
rtlsdr_get_device_usb_strings(i, vendor, product, serial);
|
|
|
|
offset = strlen(serial) - strlen(s);
|
|
|
|
if (offset < 0) {
|
|
|
|
continue;}
|
|
|
|
if (strncmp(s, serial+offset, strlen(s)) != 0) {
|
|
|
|
continue;}
|
|
|
|
device = i;
|
|
|
|
fprintf(stderr, "Using device %d: %s\n",
|
|
|
|
device, rtlsdr_get_device_name((uint32_t)device));
|
|
|
|
return device;
|
|
|
|
}
|
|
|
|
fprintf(stderr, "No matching devices found.\n");
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
//
|
|
|
|
//=========================================================================
|
|
|
|
//
|
2013-01-05 13:52:25 +01:00
|
|
|
int main(int argc, char **argv) {
|
|
|
|
int j;
|
|
|
|
|
2013-04-29 23:14:06 +02:00
|
|
|
// Set sane defaults
|
2013-01-05 13:52:25 +01:00
|
|
|
modesInitConfig();
|
2013-04-29 23:14:06 +02:00
|
|
|
signal(SIGINT, sigintHandler); // Define Ctrl/C handler (exit program)
|
2013-01-05 13:52:25 +01: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 19:57:03 +02:00
|
|
|
// Parse the command line options
|
2013-01-05 13:52:25 +01:00
|
|
|
for (j = 1; j < argc; j++) {
|
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 19:57:03 +02:00
|
|
|
int more = j+1 < argc; // There are more arguments
|
2013-01-05 13:52:25 +01:00
|
|
|
|
|
|
|
if (!strcmp(argv[j],"--device-index") && more) {
|
2014-07-08 22:12:46 +02:00
|
|
|
Modes.dev_index = verbose_device_search(argv[++j]);
|
2013-01-05 13:52:25 +01:00
|
|
|
} else if (!strcmp(argv[j],"--gain") && more) {
|
2014-09-24 21:01:06 +02:00
|
|
|
Modes.gain = (int) (atof(argv[++j])*10); // Gain is in tens of DBs
|
2013-01-05 13:52:25 +01:00
|
|
|
} else if (!strcmp(argv[j],"--enable-agc")) {
|
|
|
|
Modes.enable_agc++;
|
|
|
|
} else if (!strcmp(argv[j],"--freq") && more) {
|
2013-04-10 00:56:20 +02:00
|
|
|
Modes.freq = (int) strtoll(argv[++j],NULL,10);
|
2013-01-05 13:52:25 +01:00
|
|
|
} else if (!strcmp(argv[j],"--ifile") && more) {
|
|
|
|
Modes.filename = strdup(argv[++j]);
|
2013-04-26 11:12:47 +02:00
|
|
|
} else if (!strcmp(argv[j],"--fix")) {
|
2013-05-24 22:51:44 +02:00
|
|
|
Modes.nfix_crc = 1;
|
2013-01-05 13:52:25 +01:00
|
|
|
} else if (!strcmp(argv[j],"--no-fix")) {
|
2013-05-24 22:51:44 +02:00
|
|
|
Modes.nfix_crc = 0;
|
2013-01-05 13:52:25 +01:00
|
|
|
} else if (!strcmp(argv[j],"--no-crc-check")) {
|
|
|
|
Modes.check_crc = 0;
|
2013-05-22 14:23:54 +02:00
|
|
|
} else if (!strcmp(argv[j],"--phase-enhance")) {
|
|
|
|
Modes.phase_enhance = 1;
|
2013-01-05 13:52:25 +01:00
|
|
|
} else if (!strcmp(argv[j],"--raw")) {
|
|
|
|
Modes.raw = 1;
|
2013-01-10 20:58:13 +01:00
|
|
|
} else if (!strcmp(argv[j],"--net")) {
|
|
|
|
Modes.net = 1;
|
2013-04-23 00:31:59 +02:00
|
|
|
} else if (!strcmp(argv[j],"--modeac")) {
|
|
|
|
Modes.mode_ac = 1;
|
2013-04-07 17:22:02 +02:00
|
|
|
} else if (!strcmp(argv[j],"--net-beast")) {
|
|
|
|
Modes.beast = 1;
|
2013-01-13 01:39:29 +01:00
|
|
|
} else if (!strcmp(argv[j],"--net-only")) {
|
|
|
|
Modes.net = 1;
|
|
|
|
Modes.net_only = 1;
|
2014-03-11 02:09:49 +01:00
|
|
|
} else if (!strcmp(argv[j],"--net-heartbeat") && more) {
|
2014-10-03 23:55:21 +02:00
|
|
|
Modes.net_heartbeat_interval = atoi(argv[++j]);
|
2014-03-11 02:09:49 +01:00
|
|
|
} else if (!strcmp(argv[j],"--net-ro-size") && more) {
|
2014-10-03 23:55:21 +02:00
|
|
|
Modes.net_output_flush_size = atoi(argv[++j]);
|
2013-04-16 00:17:08 +02:00
|
|
|
} else if (!strcmp(argv[j],"--net-ro-rate") && more) {
|
2014-10-03 23:55:21 +02:00
|
|
|
Modes.net_output_flush_interval = atoi(argv[++j]) / 15; // backwards compatibility
|
|
|
|
} else if (!strcmp(argv[j],"--net-ro-interval") && more) {
|
|
|
|
Modes.net_output_flush_interval = atoi(argv[++j]);
|
2013-01-10 20:58:13 +01:00
|
|
|
} else if (!strcmp(argv[j],"--net-ro-port") && more) {
|
2013-05-24 23:29:00 +02:00
|
|
|
if (Modes.beast) // Required for legacy backward compatibility
|
2013-05-25 00:32:12 +02:00
|
|
|
{Modes.net_output_beast_port = atoi(argv[++j]);;}
|
|
|
|
else
|
|
|
|
{Modes.net_output_raw_port = atoi(argv[++j]);}
|
2013-01-12 11:46:32 +01:00
|
|
|
} else if (!strcmp(argv[j],"--net-ri-port") && more) {
|
|
|
|
Modes.net_input_raw_port = atoi(argv[++j]);
|
2013-05-24 23:29:00 +02:00
|
|
|
} else if (!strcmp(argv[j],"--net-bo-port") && more) {
|
|
|
|
Modes.net_output_beast_port = atoi(argv[++j]);
|
|
|
|
} else if (!strcmp(argv[j],"--net-bi-port") && more) {
|
|
|
|
Modes.net_input_beast_port = atoi(argv[++j]);
|
2014-10-25 21:33:45 +02:00
|
|
|
} else if (!strcmp(argv[j],"--net-bind-address") && more) {
|
2014-10-30 13:06:03 +01:00
|
|
|
Modes.net_bind_address = strdup(argv[++j]);
|
2013-01-13 01:39:29 +01:00
|
|
|
} else if (!strcmp(argv[j],"--net-http-port") && more) {
|
|
|
|
Modes.net_http_port = atoi(argv[++j]);
|
2013-01-17 19:12:23 +01:00
|
|
|
} else if (!strcmp(argv[j],"--net-sbs-port") && more) {
|
|
|
|
Modes.net_output_sbs_port = atoi(argv[++j]);
|
2014-05-27 14:16:57 +02:00
|
|
|
} else if (!strcmp(argv[j],"--net-buffer") && more) {
|
|
|
|
Modes.net_sndbuf_size = atoi(argv[++j]);
|
2013-01-06 17:09:31 +01:00
|
|
|
} else if (!strcmp(argv[j],"--onlyaddr")) {
|
|
|
|
Modes.onlyaddr = 1;
|
2013-01-08 19:46:50 +01:00
|
|
|
} else if (!strcmp(argv[j],"--metric")) {
|
|
|
|
Modes.metric = 1;
|
2013-01-15 01:41:10 +01:00
|
|
|
} else if (!strcmp(argv[j],"--aggressive")) {
|
2013-05-24 22:51:44 +02:00
|
|
|
Modes.nfix_crc = MODES_MAX_BITERRORS;
|
2013-01-05 13:52:25 +01:00
|
|
|
} else if (!strcmp(argv[j],"--interactive")) {
|
|
|
|
Modes.interactive = 1;
|
2013-05-09 12:29:18 +02:00
|
|
|
} else if (!strcmp(argv[j],"--interactive-rows") && more) {
|
2013-01-05 21:41:09 +01:00
|
|
|
Modes.interactive_rows = atoi(argv[++j]);
|
2013-05-09 12:29:18 +02:00
|
|
|
} else if (!strcmp(argv[j],"--interactive-ttl") && more) {
|
2013-08-19 16:55:17 +02:00
|
|
|
Modes.interactive_display_ttl = atoi(argv[++j]);
|
2013-05-09 12:29:18 +02:00
|
|
|
} else if (!strcmp(argv[j],"--lat") && more) {
|
|
|
|
Modes.fUserLat = atof(argv[++j]);
|
|
|
|
} else if (!strcmp(argv[j],"--lon") && more) {
|
|
|
|
Modes.fUserLon = atof(argv[++j]);
|
2013-01-05 13:52:25 +01:00
|
|
|
} else if (!strcmp(argv[j],"--debug") && more) {
|
2013-01-26 01:07:43 +01:00
|
|
|
char *f = argv[++j];
|
|
|
|
while(*f) {
|
|
|
|
switch(*f) {
|
|
|
|
case 'D': Modes.debug |= MODES_DEBUG_DEMOD; break;
|
|
|
|
case 'd': Modes.debug |= MODES_DEBUG_DEMODERR; break;
|
|
|
|
case 'C': Modes.debug |= MODES_DEBUG_GOODCRC; break;
|
|
|
|
case 'c': Modes.debug |= MODES_DEBUG_BADCRC; break;
|
|
|
|
case 'p': Modes.debug |= MODES_DEBUG_NOPREAMBLE; break;
|
|
|
|
case 'n': Modes.debug |= MODES_DEBUG_NET; break;
|
|
|
|
case 'j': Modes.debug |= MODES_DEBUG_JS; break;
|
|
|
|
default:
|
|
|
|
fprintf(stderr, "Unknown debugging flag: %c\n", *f);
|
|
|
|
exit(1);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
f++;
|
|
|
|
}
|
2013-01-06 15:13:40 +01:00
|
|
|
} else if (!strcmp(argv[j],"--stats")) {
|
2014-09-25 21:33:50 +02:00
|
|
|
Modes.stats = -1;
|
|
|
|
} else if (!strcmp(argv[j],"--stats-every") && more) {
|
|
|
|
Modes.stats = atoi(argv[++j]);
|
2013-01-05 13:52:25 +01:00
|
|
|
} else if (!strcmp(argv[j],"--snip") && more) {
|
|
|
|
snipMode(atoi(argv[++j]));
|
|
|
|
exit(0);
|
|
|
|
} else if (!strcmp(argv[j],"--help")) {
|
|
|
|
showHelp();
|
|
|
|
exit(0);
|
2013-04-08 17:42:27 +02:00
|
|
|
} else if (!strcmp(argv[j],"--ppm") && more) {
|
2013-04-09 01:58:32 +02:00
|
|
|
Modes.ppm_error = atoi(argv[++j]);
|
|
|
|
} else if (!strcmp(argv[j],"--quiet")) {
|
|
|
|
Modes.quiet = 1;
|
2013-04-12 12:15:52 +02:00
|
|
|
} else if (!strcmp(argv[j],"--mlat")) {
|
2013-04-13 02:37:02 +02:00
|
|
|
Modes.mlat = 1;
|
2013-04-12 12:30:18 +02:00
|
|
|
} else if (!strcmp(argv[j],"--interactive-rtl1090")) {
|
2013-04-13 02:37:02 +02:00
|
|
|
Modes.interactive = 1;
|
|
|
|
Modes.interactive_rtl1090 = 1;
|
2013-04-09 01:58:32 +02:00
|
|
|
} else {
|
2013-01-05 13:52:25 +01:00
|
|
|
fprintf(stderr,
|
|
|
|
"Unknown or not enough arguments for option '%s'.\n\n",
|
|
|
|
argv[j]);
|
|
|
|
showHelp();
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-04-25 15:48:14 +02:00
|
|
|
#ifdef _WIN32
|
|
|
|
// Try to comply with the Copyright license conditions for binary distribution
|
|
|
|
if (!Modes.quiet) {showCopyright();}
|
|
|
|
#endif
|
|
|
|
|
2014-02-22 23:11:11 +01:00
|
|
|
#ifndef _WIN32
|
|
|
|
// Setup for SIGWINCH for handling lines
|
|
|
|
if (Modes.interactive) {signal(SIGWINCH, sigWinchCallback);}
|
|
|
|
#endif
|
|
|
|
|
2013-04-29 23:14:06 +02:00
|
|
|
// Initialization
|
2013-01-05 13:52:25 +01:00
|
|
|
modesInit();
|
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 19:57:03 +02:00
|
|
|
|
2013-01-13 01:39:29 +01:00
|
|
|
if (Modes.net_only) {
|
|
|
|
fprintf(stderr,"Net-only mode, no RTL device or file open.\n");
|
|
|
|
} else if (Modes.filename == NULL) {
|
2013-01-05 13:52:25 +01:00
|
|
|
modesInitRTLSDR();
|
|
|
|
} else {
|
|
|
|
if (Modes.filename[0] == '-' && Modes.filename[1] == '\0') {
|
|
|
|
Modes.fd = STDIN_FILENO;
|
2014-10-01 13:17:51 +02:00
|
|
|
} else if ((Modes.fd = open(Modes.filename,
|
|
|
|
#ifdef _WIN32
|
|
|
|
(O_RDONLY | O_BINARY)
|
|
|
|
#else
|
|
|
|
(O_RDONLY)
|
|
|
|
#endif
|
|
|
|
)) == -1) {
|
2013-01-05 13:52:25 +01:00
|
|
|
perror("Opening data file");
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
}
|
2013-01-10 20:58:13 +01:00
|
|
|
if (Modes.net) modesInitNet();
|
2013-01-05 13:52:25 +01: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 19:57:03 +02:00
|
|
|
// If the user specifies --net-only, just run in order to serve network
|
|
|
|
// clients without reading data from the RTL device
|
2013-01-13 01:39:29 +01:00
|
|
|
while (Modes.net_only) {
|
2013-04-29 23:14:06 +02:00
|
|
|
if (Modes.exit) exit(0); // If we exit net_only nothing further in main()
|
2013-01-13 01:39:29 +01:00
|
|
|
backgroundTasks();
|
|
|
|
usleep(100000);
|
|
|
|
}
|
|
|
|
|
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 19:57:03 +02:00
|
|
|
// Create the thread that will read the data from the device.
|
2013-01-05 13:52:25 +01:00
|
|
|
pthread_create(&Modes.reader_thread, NULL, readerThreadEntryPoint, NULL);
|
|
|
|
pthread_mutex_lock(&Modes.data_mutex);
|
BUGFIX : Missed data causes timestamp slip
The Mutex on the RTL data reader thread does not "force" the data
processing thread to execute. Therefore, if the processor is busy, it is
possible for a second RTL callback to occur before the data from the
first has been processed. This will cause the loss of the first data,
but worse, it will cause a slip in the timestamp. This upsets Beamfinder
and MLAT operation in PlanePlotter.
To solve this, keep a Fifo buffer which is filled by the callback
thread, and emptied by the data processing thread. The fifo is the same
size as the number of buffers requested in the call to
rtlsdr_read_async().
Note - we only put the value of the pointer supplied in the callback
into the fifo. We do not attempt to cache the data in the buffer pointed
to by the pointer. This would require us to memcopy() 2Mbytes per
second, which we don't want to do if we don't have to because it will
only make the processor loading worse. Instead, we assume that the data
in the buffer will remain valid after the callback returns, at least
until it is overwritten by new data.
It is still possible for us to lose data if we can't process it quickly
enough. However, we can now detect this loss of data when the fifo is
almost full, and correct the timestamp for the lost block/blocks.
2014-02-23 00:11:13 +01:00
|
|
|
|
|
|
|
while (Modes.exit == 0) {
|
|
|
|
|
|
|
|
if (Modes.iDataReady == 0) {
|
|
|
|
pthread_cond_wait(&Modes.data_cond,&Modes.data_mutex); // This unlocks Modes.data_mutex, and waits for Modes.data_cond
|
|
|
|
continue; // Once (Modes.data_cond) occurs, it locks Modes.data_mutex
|
2013-01-05 13:52:25 +01:00
|
|
|
}
|
|
|
|
|
BUGFIX : Missed data causes timestamp slip
The Mutex on the RTL data reader thread does not "force" the data
processing thread to execute. Therefore, if the processor is busy, it is
possible for a second RTL callback to occur before the data from the
first has been processed. This will cause the loss of the first data,
but worse, it will cause a slip in the timestamp. This upsets Beamfinder
and MLAT operation in PlanePlotter.
To solve this, keep a Fifo buffer which is filled by the callback
thread, and emptied by the data processing thread. The fifo is the same
size as the number of buffers requested in the call to
rtlsdr_read_async().
Note - we only put the value of the pointer supplied in the callback
into the fifo. We do not attempt to cache the data in the buffer pointed
to by the pointer. This would require us to memcopy() 2Mbytes per
second, which we don't want to do if we don't have to because it will
only make the processor loading worse. Instead, we assume that the data
in the buffer will remain valid after the callback returns, at least
until it is overwritten by new data.
It is still possible for us to lose data if we can't process it quickly
enough. However, we can now detect this loss of data when the fifo is
almost full, and correct the timestamp for the lost block/blocks.
2014-02-23 00:11:13 +01:00
|
|
|
// Modes.data_mutex is Locked, and (Modes.iDataReady != 0)
|
|
|
|
if (Modes.iDataReady) { // Check we have new data, just in case!!
|
|
|
|
|
|
|
|
Modes.iDataOut &= (MODES_ASYNC_BUF_NUMBER-1); // Just incase
|
|
|
|
|
|
|
|
// Translate the next lot of I/Q samples into Modes.magnitude
|
|
|
|
computeMagnitudeVector(Modes.pData[Modes.iDataOut]);
|
|
|
|
|
|
|
|
Modes.stSystemTimeBlk = Modes.stSystemTimeRTL[Modes.iDataOut];
|
|
|
|
|
|
|
|
// Update the input buffer pointer queue
|
|
|
|
Modes.iDataOut = (MODES_ASYNC_BUF_NUMBER-1) & (Modes.iDataOut + 1);
|
|
|
|
Modes.iDataReady = (MODES_ASYNC_BUF_NUMBER-1) & (Modes.iDataIn - Modes.iDataOut);
|
|
|
|
|
|
|
|
// If we lost some blocks, correct the timestamp
|
|
|
|
if (Modes.iDataLost) {
|
|
|
|
Modes.timestampBlk += (MODES_ASYNC_BUF_SAMPLES * 6 * Modes.iDataLost);
|
2014-09-25 21:35:54 +02:00
|
|
|
Modes.stat_blocks_dropped += Modes.iDataLost;
|
BUGFIX : Missed data causes timestamp slip
The Mutex on the RTL data reader thread does not "force" the data
processing thread to execute. Therefore, if the processor is busy, it is
possible for a second RTL callback to occur before the data from the
first has been processed. This will cause the loss of the first data,
but worse, it will cause a slip in the timestamp. This upsets Beamfinder
and MLAT operation in PlanePlotter.
To solve this, keep a Fifo buffer which is filled by the callback
thread, and emptied by the data processing thread. The fifo is the same
size as the number of buffers requested in the call to
rtlsdr_read_async().
Note - we only put the value of the pointer supplied in the callback
into the fifo. We do not attempt to cache the data in the buffer pointed
to by the pointer. This would require us to memcopy() 2Mbytes per
second, which we don't want to do if we don't have to because it will
only make the processor loading worse. Instead, we assume that the data
in the buffer will remain valid after the callback returns, at least
until it is overwritten by new data.
It is still possible for us to lose data if we can't process it quickly
enough. However, we can now detect this loss of data when the fifo is
almost full, and correct the timestamp for the lost block/blocks.
2014-02-23 00:11:13 +01:00
|
|
|
Modes.iDataLost = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
// It's safe to release the lock now
|
|
|
|
pthread_cond_signal (&Modes.data_cond);
|
|
|
|
pthread_mutex_unlock(&Modes.data_mutex);
|
|
|
|
|
|
|
|
// Process data after releasing the lock, so that the capturing
|
|
|
|
// thread can read data while we perform computationally expensive
|
|
|
|
// stuff at the same time.
|
|
|
|
detectModeS(Modes.magnitude, MODES_ASYNC_BUF_SAMPLES);
|
|
|
|
|
|
|
|
// Update the timestamp ready for the next block
|
|
|
|
Modes.timestampBlk += (MODES_ASYNC_BUF_SAMPLES*6);
|
2014-09-25 21:35:54 +02:00
|
|
|
Modes.stat_blocks_processed++;
|
BUGFIX : Missed data causes timestamp slip
The Mutex on the RTL data reader thread does not "force" the data
processing thread to execute. Therefore, if the processor is busy, it is
possible for a second RTL callback to occur before the data from the
first has been processed. This will cause the loss of the first data,
but worse, it will cause a slip in the timestamp. This upsets Beamfinder
and MLAT operation in PlanePlotter.
To solve this, keep a Fifo buffer which is filled by the callback
thread, and emptied by the data processing thread. The fifo is the same
size as the number of buffers requested in the call to
rtlsdr_read_async().
Note - we only put the value of the pointer supplied in the callback
into the fifo. We do not attempt to cache the data in the buffer pointed
to by the pointer. This would require us to memcopy() 2Mbytes per
second, which we don't want to do if we don't have to because it will
only make the processor loading worse. Instead, we assume that the data
in the buffer will remain valid after the callback returns, at least
until it is overwritten by new data.
It is still possible for us to lose data if we can't process it quickly
enough. However, we can now detect this loss of data when the fifo is
almost full, and correct the timestamp for the lost block/blocks.
2014-02-23 00:11:13 +01:00
|
|
|
} else {
|
|
|
|
pthread_cond_signal (&Modes.data_cond);
|
|
|
|
pthread_mutex_unlock(&Modes.data_mutex);
|
|
|
|
}
|
2013-01-05 13:52:25 +01:00
|
|
|
|
2013-01-13 01:39:29 +01:00
|
|
|
backgroundTasks();
|
2013-01-06 22:56:32 +01:00
|
|
|
pthread_mutex_lock(&Modes.data_mutex);
|
2013-01-05 13:52:25 +01:00
|
|
|
}
|
|
|
|
|
2013-04-29 23:14:06 +02:00
|
|
|
// If --stats were given, print statistics
|
|
|
|
if (Modes.stats) {
|
2014-09-25 21:33:50 +02:00
|
|
|
display_stats();
|
2013-01-06 15:13:40 +01:00
|
|
|
}
|
|
|
|
|
2013-05-21 13:08:35 +02:00
|
|
|
if (Modes.filename == NULL) {
|
|
|
|
rtlsdr_cancel_async(Modes.dev); // Cancel rtlsdr_read_async will cause data input thread to terminate cleanly
|
|
|
|
rtlsdr_close(Modes.dev);
|
|
|
|
}
|
|
|
|
pthread_cond_destroy(&Modes.data_cond); // Thread cleanup
|
|
|
|
pthread_mutex_destroy(&Modes.data_mutex);
|
|
|
|
pthread_join(Modes.reader_thread,NULL); // Wait on reader thread exit
|
BUGFIX : Missed data causes timestamp slip
The Mutex on the RTL data reader thread does not "force" the data
processing thread to execute. Therefore, if the processor is busy, it is
possible for a second RTL callback to occur before the data from the
first has been processed. This will cause the loss of the first data,
but worse, it will cause a slip in the timestamp. This upsets Beamfinder
and MLAT operation in PlanePlotter.
To solve this, keep a Fifo buffer which is filled by the callback
thread, and emptied by the data processing thread. The fifo is the same
size as the number of buffers requested in the call to
rtlsdr_read_async().
Note - we only put the value of the pointer supplied in the callback
into the fifo. We do not attempt to cache the data in the buffer pointed
to by the pointer. This would require us to memcopy() 2Mbytes per
second, which we don't want to do if we don't have to because it will
only make the processor loading worse. Instead, we assume that the data
in the buffer will remain valid after the callback returns, at least
until it is overwritten by new data.
It is still possible for us to lose data if we can't process it quickly
enough. However, we can now detect this loss of data when the fifo is
almost full, and correct the timestamp for the lost block/blocks.
2014-02-23 00:11:13 +01:00
|
|
|
#ifndef _WIN32
|
2013-05-21 13:08:35 +02:00
|
|
|
pthread_exit(0);
|
BUGFIX : Missed data causes timestamp slip
The Mutex on the RTL data reader thread does not "force" the data
processing thread to execute. Therefore, if the processor is busy, it is
possible for a second RTL callback to occur before the data from the
first has been processed. This will cause the loss of the first data,
but worse, it will cause a slip in the timestamp. This upsets Beamfinder
and MLAT operation in PlanePlotter.
To solve this, keep a Fifo buffer which is filled by the callback
thread, and emptied by the data processing thread. The fifo is the same
size as the number of buffers requested in the call to
rtlsdr_read_async().
Note - we only put the value of the pointer supplied in the callback
into the fifo. We do not attempt to cache the data in the buffer pointed
to by the pointer. This would require us to memcopy() 2Mbytes per
second, which we don't want to do if we don't have to because it will
only make the processor loading worse. Instead, we assume that the data
in the buffer will remain valid after the callback returns, at least
until it is overwritten by new data.
It is still possible for us to lose data if we can't process it quickly
enough. However, we can now detect this loss of data when the fifo is
almost full, and correct the timestamp for the lost block/blocks.
2014-02-23 00:11:13 +01:00
|
|
|
#else
|
|
|
|
return (0);
|
|
|
|
#endif
|
2013-01-05 13:52:25 +01: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 19:57:03 +02:00
|
|
|
//
|
|
|
|
//=========================================================================
|
|
|
|
//
|