Reattach the licenses for the compat stuff to the source.
Only build/link the compat stuff when it's needed.
Rename compat/util.h so it's not confused with util.h.
Move all the platform specific defines inside compat/compat.h.
Notice synthetic mlat messages by looking for messages with a magic
timestamp value. If they arrive, tag the derived data as mlat-derived.
Don't include mlat-derived output in FATSV output to avoid loops.
This lets different things dynamically create the services they need,
and sorts out the horrible hacks that view1090 used to make outgoing
connections. Now you can explicitly create a service and tell it to make
an outgoing connection.
This means that view1090 can now just set all the ports to zero (to disable
the listeners), do a normal net init, then explicitly construct the beast
input service without a listener and tell it to make a connection as needed.
This gives access to the existing throttling behaviour when reading
from a file with --interactive, without needing to actually have
--interactive.
This is useful when testing, as without --throttle samples will be
processsed much faster than real-time, which can produce different
results with e.g. aircraft/filter expiry times and position/speed checks.
This currently understands:
UC8 (original rtl_sdr format, 8-bit unsigned complex);
SC16 (16-bit signed complex, full width);
SC16Q11 (bladeRF native format: 16-bit signed complex with 11 bits of magnitude)
Magnitude conversion now happens immediately when sample data is
received, so there is no risk of newly received data clobbering old
data under CPU overload.
This is possible now that the SBS output doesn't rely on the global block timestamp;
the output will look like this:
MSG,8,111,11111,4AC954,111111,2015/02/08,17:57:53.917,2015/02/08,17:57:53.936,,,,,,,,,,,,0
MSG,7,111,11111,392AEB,111111,2015/02/08,17:57:53.744,2015/02/08,17:57:53.936,,15375,,,,,,,,,,0
MSG,8,111,11111,392AEB,111111,2015/02/08,17:57:53.917,2015/02/08,17:57:53.936,,,,,,,,,,,,0
MSG,6,111,11111,800387,111111,2015/02/08,17:57:53.919,2015/02/08,17:57:53.936,,,,,,,,4745,0,0,0,0
where the "receive timestamp" (first time column) goes backwards to reflect the original reception
time of the delayed message, but the "forwarded timestamp" (second time column) reflects the actual
forwarding time.
the message being emitted immediately.
Fix computation of reception time so it's more sensible (the block timestamp
is some time after reception of the _end_ of the block, not the start) - this
means that message-emission times are always later than message-reception
times in SBS output, which is a bit more sensible.
Use clock_gettime in preference to ftime.
(except in --net-verbatim mode, where we emit them all)
Move aircraft tracking into track.[ch].
Clean up references to "interactive mode" when tracking
aircraft - we always track aircraft, even in non-interactive
mode.
since we have 8 bits spare, so there's no chance of confusing it
with an ICAO address, and we can safely use the filter table to match
future messages without also matching equivalent ICAO addresses.
Switch signalLevel back to a power measurement, don't put SNR in there.
But make it a 0.0 - 1.0 double so we're not scaling everywhere.
Adjust for the amplitude offset when calculating power.
Adapt everything else to the new scheme.
This is adapted from the FlightAware fork, with some cleanup and
modifications needed to work with the net-cleanup changes.
Inclusion of "verbatim" TSV data read from an AVR-format input
connection is not supported.
Pull #54 breaks the Windows version of dump1090 due to a bug in the
inet_aton() windows function.
1) Fix the bug in the windows inet_aton()
2) Modify the command line code to strdup() the command line string.
3) Leave the Modes.net_bind_address pointer NULL if no command line
specified
Pull #54 permits changing the default bind address. The default was
127.0.0.1. This prevents external access unless a command line switch is
used. Since many users of dump1090 are using dump1090 as remote receiver
heads for programs such as plane plotter, this is undesirable. If you
want to lock down your RPi for local use only then use the command line
switch. If not, retain legacy open mode by binding to 0.0.0.0 by
default.
Mostly refactoring the common code that was duplicated
between the different output types so that there aren't
many copies floating around.
This introduces "struct net_writer" to store the state of a
particular type of output service - buffers, time of last write,
connection count etc. prepareWrite() / completeWrite() give access
to the buffer and handle the actual writes and flushing when needed.
Heartbeat and time-based flushing move into a generic periodic-work
function.
Update the SBS output code to use the new infrastructure. This makes
a big different to CPU use when under load.
When we read from some client A, we may end up forwarding a message to other
clients. If we forward to some client B and there is a write error, then
we close B and remove it from the client list. However, if before this happened
A->next == B, then the read loop will still be holding on to a pointer to B,
and we crash.
As it's unpredictable what clients could be closed at what point, the simplest
approach is to retain closed clients in the list until we are at a point where
we know there are no stray pointers on stack, and only then modify the list.
This also simplifies anything that has to loop over clients, as it doesn't need
to worry about the current client being freed under it.
If we demodulate a message in 2.4MHz mode and it has a bad, uncorrectable CRC,
and --phase-enhance is on, then retry with the other possible phases until
we get a good CRC or run out of phases to try.
This is very expensive in AGC mode (lots of candidates that are not real
messages) but relatively cheap otherwise. It yields another 10% messages.
Also factor out some common stats code to avoid lots more copy/paste.
There is a danger in always using relative decoding where possible.
If there is an undetected error in the first pair of messages received,
then global CPR decoding will give a bad position, and subsequent
relative decoding will just walk around near that bad position even
though many error-free pairs of odd/even messages may have been received.
The first pair of position messages also tends to be the most error-prone, as
they are usually received at the extreme edge of receiver range.
(I see this happen at least once a day in practice)
So, instead, prefer to use global decoding when we have sufficiently recent data.
With recent data this should always be as good as relative decoding, and it
avoids getting stuck with bad data for long periods of time. If we don't have
enough recent data for a global solution, fall back to relative decoding.
This disables most decoding of the contents of Mode S messages, aircraft tracking, and some output modes that depend on them.
It's intended for edge receivers that just forward to a central hub rather than processing data locally.
Release of COAA PlanePlotter MLAT and SMU support for RPi
ppup1090 now supports Ground Stations functions required for MLAT and
SMU operation. This is *ONLY* available for RPi and similar linux
hardware.
Also included are sample startup scripts for dump1090 only and
dump1090+ppup1090 together.