Before this if dump1090 restarted for some reason then faup1090 will sit
there indefinitely "looking" stupid and passing no data to piaware,
even after dump1090 comes back up.
Much gratitude to Oliver Jowett (github user mutability) for the fix.
For faup1090 only the FlightAware service is enabled and we were shortening
the services table by using our own define of FAUP_NET_SERVICES_NUM and
having it set to 1.
Apps need to stick with the same number of services as defined by
MODES_NET_SERVICES_NUM in dump1090 because dump1090 support routine
modesAcceptClients loops on this constant to walk the services table.
Likewise we now define all the service ports dump1090 defines even though we
are not using them. We have configured them as disabled.
Version bump to 1.14.
faup1090 was using the wrong constant, MODES_NET_SERVICES_NUM, rather than
FAUP_NET_SERVICES_NUM, so it ran off the end of an array binding random
ports until failing when it tried to bind the FlightAware port a second time.
Thanks to Oliver Jowett (github user "mutability") for the fix.
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.
When replaying recordings, the read files are binary, so the file open
needs to reflect this so that spurious end of file characters aren't
misinterpreted.
* Install dump1090 and faup1090 to /usr/bin (It's Linux-standard, not my
first choice.)
* Build dump1090 to expect HTML and Javascript files in
/usr/share/dump1090/public_html
* Make 'make -f makefaup1090 install' install the dump1090 HTML and Javscript
files in the above directory.
* With this build style dump1090 can be invoked from anywhere and it will
find its files.
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)
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.
If a CPR message with an undetected error is received this can produce out-of-range results for latitude.
e.g. even latitude of 78000, odd latitude of 0 produces a latitude index j=35 and rlat0 = 213.
* With --net-only switch dump1090 wouldn't look for an RTLSDR device
* Without --net-only switch dump1090 would abort if it couldn't find an RTLSDR
device.
* Now with --net --no-rtlsdr-ok dump1090 will try to find an RTLSDR device but
go ahead and start either way.
* It isn't needed.
* Also include /usr/share/dpkg/buildflags.mk in Makefile and makefaup1090
and add our compile-specific CFLAGS to the CFLAGS that sets up
so we compile with the preferred Debian build flags.
Karl Lehenbauer
MalcolmRobb
Oliver Jowett