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

[toString]

You can change the global timeout parameter in your /etc/fr24feed.ini config file or stop/start service night time if your range is reduced to local traffic. But a fix should be available tomorrow.

2015-01-26 02:43:30 | [feed][n]ping 12
2015-01-26 02:43:36 | [reader][w][0]Global timeout exceeded, 0 msgs, 0 resyncs, reconnecting
2015-01-26 02:43:36 | [reader][i][0]Connection terminated
2015-01-26 02:43:36 | [main][i]Terminating child process 3089 with SIGETERM
2015-01-26 02:43:42 | [reader][i][0]Connecting to Generic receiver via (exe:///usr/lib/fr24/dump1090  --raw)
2015-01-26 02:43:42 | [reader][i][0]Connected to the receiver, authenticating
2015-01-26 02:43:42 | [reader][i][0]Authenticated, processing messages
2015-01-26 02:43:42 | [reader][i][0]Connection terminated
2015-01-26 02:43:42 | [main][i]Terminating child process 3104 with SIGETERM
2015-01-26 02:43:47 | [reader][i][0]Connecting to Generic receiver via (exe:///usr/lib/fr24/dump1090  --raw)
2015-01-26 02:43:47 | [reader][i][0]Connected to the receiver, authenticating
2015-01-26 02:43:47 | [reader][i][0]Authenticated, processing messages
2015-01-26 02:43:47 | [reader][i][0]Connection terminated
2015-01-26 02:43:47 | [main][i]Terminating child process 3105 with SIGETERM
2015-01-26 02:43:53 | [reader][i][0]Connecting to Generic receiver via (exe:///usr/lib/fr24/dump1090  --raw)
2015-01-26 02:43:53 | [reader][i][0]Connected to the receiver, authenticating
2015-01-26 02:43:53 | [reader][i][0]Authenticated, processing messages
2015-01-26 02:43:53 | [reader][i][0]Connection terminated
2015-01-26 02:43:53 | [main][i]Terminating child process 3106 with SIGETERM
2015-01-26 02:43:58 | [reader][i][0]Connecting to Generic receiver via (exe:///usr/lib/fr24/dump1090  --raw)
2015-01-26 02:43:58 | [reader][i][0]Connected to the receiver, authenticating
2015-01-26 02:43:58 | [reader][i][0]Authenticated, processing messages
2015-01-26 02:43:59 | [reader][i][0]Connection terminated
2015-01-26 02:43:59 | [main][i]Terminating child process 3107 with SIGETERM 

This is still happening to me some nights around 2am. But other nights it's fine... What do you think I should change the timeout parameter to?

[piopawlu]

Thanks, this bug is confirmed on Windows platform. A fix will be issued most likely tomorrow morning.

[eshabi]

@eshabi, will test that scenario,, even if it seems unlikely

When I tried to use the feeder to run dump1090 (external or included) using the configuration "path=" option and connect to its avr-tcp data on port 30002, it crashed.
Tried to run them sequentially using a batch file - crashed.
Added a delay in the batch file between running dump1090 and the feeder using "timeout /T 3" command - runs okay. This is my current configuration.
Tried now to run the feeder with no dump1090 running - crashed.

this is my config file:

receiver="avr-tcp"
fr24key=""
host="localhost:30002"
bs="no"
raw="no"
logmode="2"

[piopawlu]

Thanks for all the feedback!

@eshabi, will test that scenario,, even if it seems unlikely
@blort, seems like DNS resolves to incorrect server to get the feeder config,, can you ping feed.flightradar24.com?
@StDt, was that the last message in the log? No termination information or anything?

[StDt]

Mac OSX feeder with DVB-T Stick

Hi there,

I startet feeding a few days ago with an USB DVB-T Stick and the Software for OSX running on OSX 10.10.1 Yosemite (now on Yosemite Server). No other Apps installed.
Energy saving options are turned off.
The feeding stops/breaks after a few hours, the log shows nothing special:

Last login: Sun Jan 25 23:05:59 on ttys000
Tests-MBP:~ test$ tail -f /var/tmp/fr24feed.log
2015-01-26 05:36:08 | [feed][i]sent 1 AC in 1 packet
2015-01-26 05:36:19 | [feed][i]sent 1 AC in 1 packet
2015-01-26 05:36:24 | [feed][i]sent 1 AC in 1 packet
2015-01-26 05:36:30 | [feed][i]sent 1 AC in 1 packet
2015-01-26 05:36:35 | [feed][i]sent 1 AC in 1 packet
2015-01-26 05:36:40 | [feed][i]sent 1 AC in 1 packet
2015-01-26 05:36:47 | [feed][i]sent 1 AC in 1 packet
2015-01-26 05:36:52 | [feed][i]sent 1 AC in 1 packet
2015-01-26 05:36:59 | [feed][i]sent 1 AC in 1 packet
2015-01-26 05:37:04 | [feed][i]sent 1 AC in 1 packet

The Options "Reconfigure Software" "Stop Feeding" and "Show Web Status" are greyed out, flightradar24.com shows the feeder offline.

I have to restart the software, the log shows the following:

2015-01-26 09:52:16 | [main][i]FR24 Feeder/Decoder [0x02117000]
2015-01-26 09:52:16 | [main][i]Version: 1.0.10-5/generic
2015-01-26 09:52:16 | [main][i]Built on Jan 12 2015 16:03:50 (r:???/MacOSX/Universal)
2015-01-26 09:52:16 | [main][i]Copyright 2008-2015 (c) Piotr Pawluczuk
2015-01-26 09:52:16 | [main][i]Flightradar24 AB(http://flightradar24.com)
2015-01-26 09:52:16 | [httpd][i]Server started, listening on 0.0.0.0:8754
2015-01-26 09:52:16 | [master][i]Starting processing thread
2015-01-26 09:52:16 | [main][i]Reader 0 started
2015-01-26 09:52:16 | [reader][i][0]Initializing reader
2015-01-26 09:52:16 | [main][i]Socket server started
2015-01-26 09:52:16 | [reader][i][0]Connecting to Generic receiver via (exe:///Applications/FR24FeedOSX.app/Contents/Resources/dump1090  --raw)
2015-01-26 09:52:16 | [time][i]Synchronizing time via NTP
2015-01-26 09:52:16 | [bs][i]Initializing server
2015-01-26 09:52:16 | [bs][i]Starting server on 0.0.0.0:30003
2015-01-26 09:52:16 | [reader][i][0]Connected to the receiver, authenticating
2015-01-26 09:52:16 | [reader][i][0]Authenticated, processing messages
2015-01-26 09:52:19 | [time][i]Time synchronized correctly, offset -0.0008 seconds
2015-01-26 09:52:19 | [main][i]Feed Network client started
2015-01-26 09:52:19 | [feed][i]Downloading configuration
2015-01-26 09:52:19 | [main][i]RAW data server started
2015-01-26 09:52:19 | [raw][i]Initializing server
2015-01-26 09:52:19 | [raw][i]Starting server on 0.0.0.0:30002
2015-01-26 09:52:19 | [feed][c]Interval: 5s
2015-01-26 09:52:19 | [feed][c]Latitude: 49.XXXX                           (XX out, StDt)
2015-01-26 09:52:19 | [feed][c]Longitude: 11.XXXX                        (XX out, StDt)
2015-01-26 09:52:19 | [feed][c]GND: YES
2015-01-26 09:52:19 | [feed][c]NonADSB: YES
2015-01-26 09:52:19 | [feed][c]Timestamps: optional
2015-01-26 09:52:19 | [feed][c]Max range AIR: 350.0nm
2015-01-26 09:52:19 | [feed][c]Max range GND: 100.0nm
2015-01-26 09:52:19 | [feed][i]defined 1 server
2015-01-26 09:52:19 | [feed][n]EDDN41@83.140.21.XXX:8099/UDP    (XX out, StDt)
2015-01-26 09:52:19 | [stats][i]Stats thread started
2015-01-26 09:52:19 | [feed][n]connecting
2015-01-26 09:52:19 | [feed][n]connected
2015-01-26 09:52:19 | [feed][n]switching to UDP
2015-01-26 09:52:19 | [feed][n]working
2015-01-26 09:52:24 | [feed][i]sent 5 AC in 1 packet
2015-01-26 09:52:29 | [feed][i]sent 5 AC in 1 packet
2015-01-26 09:52:34 | [feed][i]sent 5 AC in 1 packet
2015-01-26 09:52:39 | [feed][i]sent 7 AC in 1 packet
2... (and so on)

Seems to be looking good.

So what am I doing wrong? Help is appreciated.

Best regards,
StDt

[blort]

I switched to the ARM6 version which does not request GPS.

I am continuing to have the same problem as before - but I'm not certain it is a time-sync problem as it says in the log (see below):

Time synchronized correctly, offset +0.0078 seconds

I'm wondering if the key I'm using is still valid.

Is there anyway to determine if the key I have is valid or not?

Blort

cat fr24feed.log
2015-01-24 08:41:58 | [main][i]FR24 Feeder/Decoder [0x02117000]
2015-01-24 08:41:58 | [main][i]Version: 1.0.11-3/generic
2015-01-24 08:41:58 | [main][i]Built on 20150120-1045 (r:master-5bbce8d.git/Linux/armv6l)
2015-01-24 08:41:58 | [main][i]Copyright 2008-2015 (c) Piotr Pawluczuk
2015-01-24 08:41:58 | [main][i]Flightradar24 AB(http://flightradar24.com)
2015-01-24 08:41:58 | [httpd][i]Server started, listening on 0.0.0.0:8754
2015-01-24 08:41:58 | [main][i]Reader 0 started
2015-01-24 08:41:58 | [master][i]Starting processing thread
2015-01-24 08:41:58 | [time][i]Synchronizing time via NTP
2015-01-24 08:41:58 | [reader][i][0]Initializing reader
2015-01-24 08:41:58 | [reader][i][0]Connecting to Generic receiver via (tcp://127.0.0.1:45105)
2015-01-24 08:41:58 | [reader][i][0]Connected to the receiver, authenticating
2015-01-24 08:41:58 | [reader][i][0]Authenticated, processing messages
2015-01-24 08:42:02 | [time][i]Time synchronized correctly, offset +0.0078 seconds
2015-01-24 08:42:02 | [main][i]Feed Network client started
2015-01-24 08:42:02 | [feed][i]Downloading configuration
2015-01-24 08:42:02 | [e]HTTP Response: [HTTP/1.1 404 Not Found]
2015-01-24 08:42:02 | [feed][i]Failed on start, Sleeping 120 seconds
2015-01-24 08:44:02 | [feed][i]Downloading configuration
2015-01-24 08:44:03 | [e]HTTP Response: [HTTP/1.1 404 Not Found]
2015-01-24 08:44:03 | [feed][i]Failed on start, Sleeping 120 seconds
2015-01-24 08:46:03 | [feed][i]Downloading configuration
2015-01-24 08:46:03 | [e]HTTP Response: [HTTP/1.1 404 Not Found]
2015-01-24 08:46:03 | [feed][i]Failed on start, Sleeping 120 seconds
2015-01-24 08:48:03 | [feed][i]Downloading configuration
2015-01-24 08:48:04 | [e]HTTP Response: [HTTP/1.1 404 Not Found]
2015-01-24 08:48:04 | [feed][i]Failed on start, Sleeping 120 seconds
2015-01-24 08:50:04 | [feed][i]Downloading configuration
2015-01-24 08:50:04 | [e]HTTP Response: [HTTP/1.1 404 Not Found]
2015-01-24 08:50:04 | [feed][i]Failed on start, Sleeping 120 seconds
2015-01-24 08:52:02 | [time][i]Synchronizing time via NTP
2015-01-24 08:52:05 | [feed][i]Downloading configuration
2015-01-24 08:52:05 | [e]HTTP Response: [HTTP/1.1 404 Not Found]
2015-01-24 08:52:05 | [feed][i]Failed on start, Sleeping 120 seconds
2015-01-24 08:52:07 | [time][i]Time synchronized correctly, offset +0.0089 seconds
2015-01-24 08:54:05 | [feed][i]Downloading configuration
2015-01-24 08:54:06 | [e]HTTP Response: [HTTP/1.1 404 Not Found]
2015-01-24 08:54:06 | [feed][i]Failed on start, Sleeping 120 seconds
2015-01-24 08:56:06 | [feed][i]Downloading configuration
2015-01-24 08:56:06 | [e]HTTP Response: [HTTP/1.1 404 Not Found]
2015-01-24 08:56:06 | [feed][i]Failed on start, Sleeping 120 seconds

[eshabi]

It seems like when fr24feed is configured to use "avr-tcp" as the source of data but this source is not already listening and waiting for connections when starting the feeder, fr24feed crashes.

[piopawlu]

You can change the global timeout parameter in your /etc/fr24feed.ini config file or stop/start service night time if your range is reduced to local traffic. But a fix should be available tomorrow.

[toString]

Ok thank you for the response. Is there anything I can change in the mean time to stop it from happening?

[piopawlu]

The cause is a dump1090 process that's stuck in background,, and therefore a new app dies instantly (can't open USB). I will try to make a fix and kill solution for that when using dump1090 directly from fr24feed.

[toString]

I'm on day 2 now of using RPi with my usb tuner..
It's very very quiet around here at Heathrow at night (as it closes!) and my range is extremely limited, so I basically assume I won't receive any aircraft between 00:00 and 05:00.

So at around 01:00 my logs show:

2015-01-22 01:44:33 | [feed][n]ping 161
2015-01-22 01:44:55 | [reader][w][0]Global timeout exceeded, 0 msgs, 0 resyncs, reconnecting
2015-01-22 01:44:55 | [reader][i][0]Connection terminated
2015-01-22 01:44:55 | [main][i]Terminating child process 3642 with SIGETERM
2015-01-22 01:45:00 | [reader][i][0]Connecting to Generic receiver via (exe:///usr/lib/fr24/dump1090  --raw)
2015-01-22 01:45:00 | [reader][i][0]Connected to the receiver, authenticating
2015-01-22 01:45:00 | [reader][i][0]Authenticated, processing messages
2015-01-22 01:45:03 | [feed][n]ping 162
2015-01-22 01:45:33 | [feed][n]ping 163
2015-01-22 01:46:03 | [feed][n]ping 164
2015-01-22 01:46:33 | [feed][n]ping 165
2015-01-22 01:47:00 | [stats][i]sent 16 bytes
2015-01-22 01:47:03 | [feed][n]ping 166
2015-01-22 01:47:33 | [feed][n]ping 167
2015-01-22 01:48:03 | [feed][n]ping 168
2015-01-22 01:48:33 | [feed][n]ping 169
2015-01-22 01:49:04 | [feed][n]ping 170
2015-01-22 01:49:34 | [feed][n]ping 171
2015-01-22 01:50:04 | [feed][n]ping 172
2015-01-22 01:50:34 | [feed][n]ping 173
2015-01-22 01:51:04 | [feed][n]ping 174
2015-01-22 01:51:06 | [time][i]Synchronizing time via NTP
2015-01-22 01:51:08 | [time][i]Time synchronized correctly, offset -0.0016 seconds, drift 0.0000 seconds/minute
2015-01-22 01:51:34 | [feed][n]ping 175
2015-01-22 01:52:04 | [feed][n]ping 176
2015-01-22 01:52:34 | [feed][n]ping 177
2015-01-22 01:53:04 | [feed][n]ping 178
2015-01-22 01:53:34 | [feed][n]ping 179
2015-01-22 01:54:04 | [feed][n]ping 180
2015-01-22 01:54:34 | [feed][n]ping 181
2015-01-22 01:55:04 | [feed][n]ping 182
2015-01-22 01:55:16 | [reader][w][0]Global timeout exceeded, 0 msgs, 0 resyncs, reconnecting
2015-01-22 01:55:16 | [reader][i][0]Connection terminated
2015-01-22 01:55:16 | [main][i]Terminating child process 3644 with SIGETERM
2015-01-22 01:55:21 | [reader][i][0]Connecting to Generic receiver via (exe:///usr/lib/fr24/dump1090  --raw)
2015-01-22 01:55:21 | [reader][i][0]Connected to the receiver, authenticating
2015-01-22 01:55:21 | [reader][i][0]Authenticated, processing messages
2015-01-22 01:55:34 | [feed][n]ping 183 

And I can interpret that every 10mins the process reconnects to my dvbt stick. (The 600 secs for global timeout (--gt=600). This continues to happen between 01:00 and 02:00. This appears normal to me.

However at 02:05 it starts doing this continuously (maybe 6 times in 1 minute):

2015-01-22 02:05:35 | [feed][n]ping 203
2015-01-22 02:05:37 | [reader][w][0]Global timeout exceeded, 0 msgs, 0 resyncs, reconnecting
2015-01-22 02:05:37 | [reader][i][0]Connection terminated
2015-01-22 02:05:37 | [main][i]Terminating child process 3647 with SIGETERM
2015-01-22 02:05:42 | [reader][i][0]Connecting to Generic receiver via (exe:///usr/lib/fr24/dump1090  --raw)
2015-01-22 02:05:42 | [reader][i][0]Connected to the receiver, authenticating
2015-01-22 02:05:42 | [reader][i][0]Authenticated, processing messages
2015-01-22 02:05:42 | [reader][i][0]Connection terminated
2015-01-22 02:05:42 | [main][i]Terminating child process 3662 with SIGETERM
2015-01-22 02:05:48 | [reader][i][0]Connecting to Generic receiver via (exe:///usr/lib/fr24/dump1090  --raw)
2015-01-22 02:05:48 | [reader][i][0]Connected to the receiver, authenticating
2015-01-22 02:05:48 | [reader][i][0]Authenticated, processing messages
2015-01-22 02:05:48 | [reader][i][0]Connection terminated
2015-01-22 02:05:48 | [main][i]Terminating child process 3663 with SIGETERM
2015-01-22 02:05:54 | [reader][i][0]Connecting to Generic receiver via (exe:///usr/lib/fr24/dump1090  --raw)
2015-01-22 02:05:54 | [reader][i][0]Connected to the receiver, authenticating
2015-01-22 02:05:54 | [reader][i][0]Authenticated, processing messages
2015-01-22 02:05:54 | [reader][i][0]Connection terminated
2015-01-22 02:05:54 | [main][i]Terminating child process 3664 with SIGETERM
2015-01-22 02:05:59 | [reader][i][0]Connecting to Generic receiver via (exe:///usr/lib/fr24/dump1090  --raw)
2015-01-22 02:05:59 | [reader][i][0]Connected to the receiver, authenticating
2015-01-22 02:05:59 | [reader][i][0]Authenticated, processing messages
2015-01-22 02:05:59 | [reader][i][0]Connection terminated
2015-01-22 02:05:59 | [main][i]Terminating child process 3665 with SIGETERM
2015-01-22 02:06:05 | [reader][i][0]Connecting to Generic receiver via (exe:///usr/lib/fr24/dump1090  --raw)
2015-01-22 02:06:05 | [reader][i][0]Connected to the receiver, authenticating
2015-01-22 02:06:05 | [reader][i][0]Authenticated, processing messages
2015-01-22 02:06:05 | [reader][i][0]Connection terminated
2015-01-22 02:06:05 | [main][i]Terminating child process 3666 with SIGETERM
2015-01-22 02:06:05 | [feed][n]ping 204
2015-01-22 02:06:10 | [reader][i][0]Connecting to Generic receiver via (exe:///usr/lib/fr24/dump1090  --raw)
2015-01-22 02:06:10 | [reader][i][0]Connected to the receiver, authenticating
2015-01-22 02:06:10 | [reader][i][0]Authenticated, processing messages
2015-01-22 02:06:10 | [reader][i][0]Connection terminated
2015-01-22 02:06:10 | [main][i]Terminating child process 3667 with SIGETERM
2015-01-22 02:06:16 | [reader][i][0]Connecting to Generic receiver via (exe:///usr/lib/fr24/dump1090  --raw)
2015-01-22 02:06:16 | [reader][i][0]Connected to the receiver, authenticating
2015-01-22 02:06:16 | [reader][i][0]Authenticated, processing messages
2015-01-22 02:06:16 | [reader][i][0]Connection terminated
2015-01-22 02:06:16 | [main][i]Terminating child process 3668 with SIGETERM
2015-01-22 02:06:21 | [reader][i][0]Connecting to Generic receiver via (exe:///usr/lib/fr24/dump1090  --raw)
2015-01-22 02:06:21 | [reader][i][0]Connected to the receiver, authenticating
2015-01-22 02:06:21 | [reader][i][0]Authenticated, processing messages
2015-01-22 02:06:21 | [reader][i][0]Connection terminated
2015-01-22 02:06:21 | [main][i]Terminating child process 3669 with SIGETERM
2015-01-22 02:06:27 | [reader][i][0]Connecting to Generic receiver via (exe:///usr/lib/fr24/dump1090  --raw)
2015-01-22 02:06:27 | [reader][i][0]Connected to the receiver, authenticating
2015-01-22 02:06:27 | [reader][i][0]Authenticated, processing messages
2015-01-22 02:06:27 | [reader][i][0]Connection terminated
2015-01-22 02:06:27 | [main][i]Terminating child process 3670 with SIGETERM
2015-01-22 02:06:33 | [reader][i][0]Connecting to Generic receiver via (exe:///usr/lib/fr24/dump1090  --raw)
2015-01-22 02:06:33 | [reader][i][0]Connected to the receiver, authenticating
2015-01-22 02:06:33 | [reader][i][0]Authenticated, processing messages
2015-01-22 02:06:33 | [reader][i][0]Connection terminated
2015-01-22 02:06:33 | [main][i]Terminating child process 3671 with SIGETERM
2015-01-22 02:06:35 | [feed][n]ping 205 

It then goes on to do this constantly for the next 6 or so hours (you can imagine how much log space that took up!) Until I wake up and noticed it reporting offline to FR24 website. I had to restart the service manually and then everything was back to normal...


What could be the cause of this?

[piopawlu]

All good now,, the next build will detect PiAware and try to prevent conflicts automatically.

[abcd567]

I asked for your config and didn't get it yet. Red colour is not necessary to get attention here either and if it shows it as down it means the connection to it is down. Decoder works with multiple receivers and in most cases it's connected directly to the device.

If you are running it together with PiAware you need to set the receiver type to avr-tcp and set the host to localhost:30002. You cannot have two decoders attaching to one USB device. It is mentioned in the FAQ section of the PDF file.

Thanks for advising to see FAQ section of PDF Guide.
Followed instructions in FAQ, and problem was solved. Please see three screenshots below. All action was taken from my Windows Desktop using SSH through PuTTY.

FR24 setup on PiAware-1.PNG . FR24 setup on PiAware-2.PNG . FR24 setup on PiAware-3.PNG

[piopawlu]

I checked Dump1090's display on my Desktop's web browser by typing "http://<IP address of RPI on LAN DHCP/NAT>:8080", and it started displaying Google Map & Planes. The receiver is NOT down but FR24 feeder is showing it down!!!

I asked for your config and didn't get it yet. Red colour is not necessary to get attention here either and if it shows it as down it means the connection to it is down. Decoder works with multiple receivers and in most cases it's connected directly to the device.

If you are running it together with PiAware you need to set the receiver type to avr-tcp and set the host to localhost:30002. You cannot have two decoders attaching to one USB device. It is mentioned in the FAQ section of the PDF file.

[abcd567]

I have been feeding data to FR24 since 2013, using my Windows Desktop & DVB-T Receiver.

Couple of days ago I purchased Raspberry Pi B+, and installed on it PiAware img, a package consisting of Raspbian OS+Dump1090 (or some other decoder)+Flightaware Data feeder.

Today I installed FR24 Data feeder software fr24feed_1.0.11-3_armhf.deb on my RPi B+.
After completing the installations as per FR24 instruction manual, I gave command "service fr24feed status". Following is displayed

pi@piaware ~ $ service fr24feed status
[ ok ] FR24 Feeder/Decoder Process: running.
[ ok ] FR24 Stats Timestamp: 2015-01-21 17:46:02.
[ ok ] FR24 Link: connected [UDP].
[ ok ] FR24 Radar: T-CYYZ9.
[ ok ] FR24 Tracked AC:.
[[COLOR="#FF0000"][B]FAIL[/B][/COLOR]] Receiver: down ... [COLOR="#FF0000"][B]failed[/B][/COLOR]!

I checked Dump1090's display on my Desktop's web browser by typing "http://<IP address of RPI on LAN DHCP/NAT>:8080", and it started displaying Google Map & Planes. The receiver is NOT down but FR24 feeder is showing it down!!!

Piaware Dump1090.PNG