The old logic had a number of problems, including:
* sending heartbeats on all service types if any type needed
a heartbeat
* sending a heartbeat multiple times a second if there was a
service type that was idle but didn't generate traffic when
an empty message was sent (e.g. FATSV)
Rewrite it all so that heartbeats are explicitly tracked and handled
per service type, rather than by sending a dummy message.
Also switch to mode A/C messages for the beast/raw heartbeat, as
it's a bit more compact and less likely to mess with Mode S state
(an all-zeros Mode S message actually looks valid)
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.
In particular, not guarding in flushWrites() meant that we
could end up trying to write to an uninitialized writer
(where writer->service == c->service == NULL) and crashing.
The DF17/18 values are generally more trustworthy as they have full
CRC coverage. Errors in the CRC bits of a DF0/4/16/20 message can
result in the contained altitude being attributed to the wrong aircraft.
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 affected Beast input/output, and AVR output in --mlat mode.
Works on a little-endian host, should work on a big-endian host but
I don't have one to test with.
Probably fixes#44.
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 would mangle messages if the first byte of a message ended up
as the last byte returned by a read() call - it would read beyond
the end of the buffer, decide the message was damaged, and then run
off into the message data looking for a new delimiter. Sometimes
that would work (only dropping one message), but sometimes it would
run into data that happened to look like a message start but
actually wasn't, and then try to interpret that, leading to completely
bogus message data being read.
Fixes#29.
Track NUCp when we compute positions.
Do speed checks when we have an updated position with the same or worse NUCp
before accepting the new position. Don't do speed checks on new postions if
they improve NUCp - assume that the new position is better.
Include NUCp in aircraft.json
Gather stats on reasons for rejecting CPR data due to range/speed check failures.
Expire old positions if we have had no updates for 60 seconds.
Closes#16, closes#17.
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.
This means the 1/5/15 min values may reflect a period that ended
up to 1 minute ago, but the length of the measured period is always
as expected i.e. 1/5/15 mins.
is what was previously done and it gives us better range for small signals.
Means a sqrt() call on beast output, but this shouldn't be too bad as
it's only done once per message.
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.
realpath() returns a heap-allocated buffer if given NULL for the destination buffer.
This must be freed by the caller; dump1090 does not do this.
Instead of worrying about freeing it, take the simpler approach of just providing a
stack-allocated destination buffer.
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.
Client disconnection appears as a read of 0 bytes.
Without a test for this, dump1090 continues to poll that client forever.
Also, read() may return EWOULDBLOCK as well as EAGAIN
for "no data right now", so handle that.
I don't know if there is an equivalent Win32 bug here as the Win32
interfaces seem subtly different to vanilla POSIX.
The following test/break can probably be removed if Win32 needs
the same fix.
For remotely received messages that have a mlat timestamp, we have no
useful way of turning that timestamp into a wallclock timestamp, so
don't try, or we'll just produce wildly wrong results (_days_ in error)
It seems server code should be compatible with HTTP 1.1; the features
unique to 1.1 mostly are upon the client to support, and some headers
used (for example Cache-Control) may need 1.1.
A few minor additions and bug fixes as detailed below
1) Additional command line option "--net-buffer <n>" to specify the TCP
output buffer size. Default is n=0, which is 64Kb. Specify a value of n
to increase the buffer size according to Size = 64Kb * 2^n, so an n of
1 = 128Kb, n=2 is 256Kb etc. n is limited to 7, so the max size is 8Mb.
This option may assist if you have a high number of aircraft being
received, and an unreliable network connection, or if the receiving end
can be busy for an extended time.
2) Bug fix in ppup1090 which prevented the uploading of valid
ModeA/Squawk codes
3) Bug fix per Markus Grab's commit.
