Flightradar24 decoder/feeder BETA testing (Win/RPi/Linux/OSX)

[Wolli]

Hej all, I am new to feeding (feeding for about one week now) and all is a little bit challenging to me, cos I find no user guide or similar, but I won't complain.

I'm using a Windows PC (Vista) with a jetvision dongle connected (DVBT stick RTL2832U). Feeding software is fr24feed_win32-1.0.9-3, using "mr-dump1090.exe" contained in the zipfile. Randomly I discovered today in the "FR24 Feeder Settings" the receiver-option "DVBT Stick (Malcomlm Robb)". This option seems to produce much better reception results (concerning data quality and resulting "sensitivity") than the standard option "DVBT Stick (default)". However, I'm not sure whether I was right to activate the "Malcolm-Robb-Option". Any comments to that?

Ahm, a second point: due to local circumstances the dongle is not directly connected to the PC, but with an USB extension cord with length of 3 meters. Might this be critical?

Regards, -Wolli-

[piopawlu]

The Malcolm Robb's build has more features, for example web interface, is updated more frequently and is said to receive more frames. This comes at a price of CPU usage of course and this is why we offer it as an option.

[Wolli]

Hej Piotr, many thanks for your quick reply. Fortunately the CPU usage using "Robb" is well below 10% on my PC (Notebook, more than 5 years old). Yesterday I could see on FR24 that "my radar" was here and there "used" several times. Today obviously not a single time, *disappointed*, although I feel that "my" data amount and quality is better than yesterday. BTW: Yesterday I saw a line in the console like "connecting to... as number@bla with option T" (not exactly so, you surely know what I mean). Today I did not see this line in the console. Hopefully my precious position feeds will join your main server, I'm not sure. Hej hej, and have nice Xmas days, -Wolli-

[awg]

You can ignore it for now.. I will try to investigate it further and get a new build after xmas.

I've checked my stats page: my feed is offline with last upload at 2am. So the feeder stopped working at that hour. After a reboot the feeder appears online again.

[jelmer]

On the OSX version (1.0.9-3) I'm getting:

26/12/14 05:15:05,860 FR24FeedOSX[61534]: Unable to load nib file: MainMenu, exiting
26/12/14 05:15:05,863 com.apple.launchd.peruser.501[297]: (com.fr24.FR24FeedOSX.264912[61534]) Exited with code: 1

Looks like something is missing?

[obj]

1.0.9-3 still fails when run as non-root:

[main][i]FR24 Feeder/Decoder [0x02117000]
[main][i]Version: 1.0.9-3/generic
[main][i]Built on 20141222-1532 (r:master-17bc89d.git/Linux/armv6l)
[main][i]Copyright 2008-2014 (c) Piotr Pawluczuk
[main][i]Flightradar24 AB(http://flightradar24.com)
[main][w]Config file /etc/fr24feed.ini does not exist or cannot be written!
[main][w]Please make sure you run the fr24feed as root!

[obj]

How can I disable or restrict (e.g. bind to loopback) the webserver that listens on port 8754?

[loplo]

run as nonroot issue is known.

[obj]

run as nonroot issue is known.

No kidding! I was the one that reported it earlier. It was meant to be fixed in this release; it's not.

[obj]

I'm seeing regular "global timeout exceeded" errors every approx 10 mins with 1.0.9-3; these did not happen with 1.0.8-1:

2014-12-28 06:33:07 | [feed][i]sent 42 planes in 2 packets
2014-12-28 06:33:10 | [i]Removed 0 of 60 AC
2014-12-28 06:33:11 | [reader][w][0]Global timeout exceeded, 898090 msgs, 0 resyncs, reconnecting
2014-12-28 06:33:11 | [reader][i][0]Connection terminated
2014-12-28 06:33:11 | [feed][i]sent 45 planes in 2 packets
2014-12-28 06:33:12 | [time][i]Synchronizing time via NTP
2014-12-28 06:33:14 | [time][i]Time synchronized correctly, offset -0.0001 seconds, drift +0.0000 seconds
2014-12-28 06:33:16 | [reader][i][0]Connecting to Generic receiver via (tcp://127.0.0.1:30005)
2014-12-28 06:33:16 | [reader][i][0]Connected to the receiver, authenticating
2014-12-28 06:33:16 | [reader][i][0]Authenticated, processing messages
2014-12-28 06:33:17 | [i]Removed 0 of 61 AC
2014-12-28 06:33:17 | [feed][i]sent 1 planes in 1 packets

2014-12-28 06:44:32 | [feed][i]sent 58 planes in 2 packets
2014-12-28 06:44:33 | [i]Removed 0 of 76 AC
2014-12-28 06:44:35 | [reader][w][0]Global timeout exceeded, 550035 msgs, 0 resyncs, reconnecting
2014-12-28 06:44:35 | [reader][i][0]Connection terminated
2014-12-28 06:44:40 | [reader][i][0]Connecting to Generic receiver via (tcp://127.0.0.1:30005)
2014-12-28 06:44:40 | [reader][i][0]Connected to the receiver, authenticating
2014-12-28 06:44:40 | [reader][i][0]Authenticated, processing messages
2014-12-28 06:44:40 | [i]Removed 0 of 76 AC
2014-12-28 06:44:40 | [feed][i]sent 59 planes in 2 packets

2014-12-28 06:56:24 | [i]Removed 0 of 80 AC
2014-12-28 06:56:25 | [feed][i]sent 56 planes in 2 packets
2014-12-28 06:56:27 | [reader][w][0]Global timeout exceeded, 737894 msgs, 0 resyncs, reconnecting
2014-12-28 06:56:27 | [reader][i][0]Connection terminated
2014-12-28 06:56:32 | [reader][i][0]Connecting to Generic receiver via (tcp://127.0.0.1:30005)
2014-12-28 06:56:32 | [reader][i][0]Connected to the receiver, authenticating
2014-12-28 06:56:32 | [reader][i][0]Authenticated, processing messages
2014-12-28 06:56:32 | [feed][i]sent 56 planes in 2 packets
2014-12-28 06:56:32 | [i]Removed 0 of 80 AC

etc.

[obj]

The time-skew logic in 1.0.9-3 is too picky:

2014-12-28 10:17:18 | [time][i]Synchronizing time via NTP
2014-12-28 10:17:20 | [time][i]Time synchronized correctly, offset +0.0003 seconds, drift +0.0000 seconds
2014-12-28 10:19:51 | [time][i]Synchronizing time via NTP
2014-12-28 10:19:54 | [time][i]Time synchronized correctly, offset +0.0040 seconds, drift +0.0000 seconds
2014-12-28 10:22:25 | [time][i]Synchronizing time via NTP
2014-12-28 10:22:28 | [time][e]Time synchronized, offset -0.0004 seconds, drift +0.0000 seconds
2014-12-28 10:22:28 | [time][w]Clock drift -0.0044 is too high, suspending data feed
2014-12-28 10:24:59 | [time][i]Synchronizing time via NTP
2014-12-28 10:25:02 | [time][i]Time synchronized correctly, offset +0.0021 seconds, drift +0.0000 seconds
2014-12-28 10:27:32 | [time][i]Synchronizing time via NTP
2014-12-28 10:27:35 | [time][i]Time synchronized correctly, offset +0.0000 seconds, drift +0.0000 seconds

The system clock is being managed by a separate ntpd (fr24feed is not running as root, so anything it's trying to do to change the clock parameters will actually have no effect)
Notice that the clock isn't actually drifting; the 4ms spike is probably just a one-off random scheduling delay more than anything.

fr24feed shouldn't suspend the feed in response to such small errors - there can be 1000-2000ms latency between the RF signal arriving over the air and the demodulated message reaching fr24feed in my setup, 4ms is nothing.

$ ntpdc
ntpdc> peers
     remote           local      st poll reach  delay   offset    disp
=======================================================================
=fr1.tomhek.net  192.168.1.4      3 1024  377 0.02344 -0.002042 0.13747
=ntp.ngi.it      2001:470:6b39:1  2 1024  377 0.04140 -0.004126 0.13989
=server4.fidesz. 192.168.1.4      3 1024  377 0.04999  0.000313 0.13937
*195.3.254.167   192.168.1.4      1 1024  377 0.08725  0.003932 0.13899
ntpdc> sysinfo
system peer:          195.3.254.167
system peer mode:     client
leap indicator:       00
stratum:              2
precision:            -20
root distance:        0.08725 s
root dispersion:      0.08580 s
reference ID:         [195.3.254.167]
reference time:       d84ad462.e68ba403  Sun, Dec 28 2014 19:11:30.900
system flags:         auth monitor ntp kernel stats 
jitter:               0.005096 s
stability:            0.000 ppm
broadcastdelay:       0.000000 s
authdelay:            0.000000 s
ntpdc> kerninfo
pll offset:           0.00029631 s
pll frequency:        -27.223 ppm
maximum error:        0.371011 s
estimated error:      0.000849 s
status:               2001  pll nano
pll time constant:    10
precision:            1e-09 s
frequency tolerance:  500 ppm

[piopawlu]

Thank you for your latest feedback.. We will relax the timing logic in the release I will prepare later today.

It does work as non-root, but /etc/fr24feed.ini must be writable by the user running the app.
It's required for the WWW settings page. I will, however, make it work without that and show a warning message when settings are being accessed.

The clock sync, or to be precise offset calculation is internal for the fr24feed application, system clock is not affected.

@jelmer: what OSX version do you have?

[obj]

It does work as non-root, but /etc/fr24feed.ini must be writable by the user running the app.
It's required for the WWW settings page. I will, however, make it work without that and show a warning message when settings are being accessed.

Thanks. It's not normal for a daemon to have write access to its configuration, so if you can make fr24feed tolerate this, then that would be useful. For now I'm running under fakeroot again to fool it.

Any thoughts on disabling the webserver entirely, or on the global timeout errors I'm seeing?

[piopawlu]

You can add httpd="no" to the config file or the command line if run from outside the init script.

Global timeout usually means not a single valid frame was received within predefined time limit, you can override it by adding "gt=NNNN" into your config file where "NNNN" is the timeout in seconds. If used with tcp receiver connection setting it too high will cause problems when the tcp connection is not closed, but delivers no data.

[obj]

You can add httpd="no" to the config file or the command line if run from outside the init script.

Perfect, thanks!

Global timeout usually means not a single valid frame was received within predefined time limit, you can override it by adding "gt=NNNN" into your config file where "NNNN" is the timeout in seconds. If used with tcp receiver connection setting it too high will cause problems when the tcp connection is not closed, but delivers no data.

I think there must be a bug here as this TCP connection typically delivers 1000+ messages/second, and the feeder is actively forwarding aircraft updates to FR24 when the timeout error occurs - so there are plenty of valid frames available:

2014-12-29 12:57:40 | [feed][i]sent 85 planes in 3 packets
2014-12-29 12:57:43 | [i]Removed 1 of 114 AC
2014-12-29 12:57:45 | [feed][i]sent 90 planes in 3 packets
2014-12-29 12:57:47 | [i]Removed 1 of 115 AC
2014-12-29 12:57:49 | [reader][w][0]Global timeout exceeded, 940688 msgs, 0 resyncs, reconnecting
2014-12-29 12:57:49 | [reader][i][0]Connection terminated
2014-12-29 12:57:54 | [reader][i][0]Connecting to Generic receiver via (tcp://127.0.0.1:30005)
2014-12-29 12:57:54 | [reader][i][0]Connected to the receiver, authenticating
2014-12-29 12:57:54 | [reader][i][0]Authenticated, processing messages
2014-12-29 12:57:54 | [feed][i]sent 92 planes in 3 packets
2014-12-29 12:57:54 | [feed][n]pinging the server
2014-12-29 12:57:54 | [i]Removed 0 of 116 AC
2014-12-29 12:57:58 | [i]Removed 0 of 117 AC
2014-12-29 12:57:59 | [feed][i]sent 84 planes in 3 packets
...
2014-12-29 13:08:54 | [feed][i]sent 91 planes in 3 packets
2014-12-29 13:08:54 | [i]Removed 0 of 125 AC
2014-12-29 13:08:56 | [reader][w][0]Global timeout exceeded, 825240 msgs, 0 resyncs, reconnecting
2014-12-29 13:08:56 | [reader][i][0]Connection terminated
2014-12-29 13:08:58 | [time][i]Synchronizing time via NTP
2014-12-29 13:09:01 | [reader][i][0]Connecting to Generic receiver via (tcp://127.0.0.1:30005)
2014-12-29 13:09:01 | [reader][i][0]Connected to the receiver, authenticating
2014-12-29 13:09:01 | [reader][i][0]Authenticated, processing messages
2014-12-29 13:09:01 | [i]Removed 2 of 126 AC
2014-12-29 13:09:01 | [feed][i]sent 88 planes in 3 packets
2014-12-29 13:09:01 | [time][i]Time synchronized correctly, offset +0.0009 seconds, drift +0.0000 seconds
2014-12-29 13:09:05 | [i]Removed 1 of 126 AC
2014-12-29 13:09:06 | [feed][i]sent 95 planes in 3 packets

note 825k messages in approx 11 minutes - 1250 messages/sec - and active updates going out to FR24 immediately before the timeout error.