Linux feeder software for Flightradar24 (Old software)

[jbntx]

It looks like there is a new version of the kernel being tested which will hopefully fix the USB issues, but until then, don't upgrade your kernel.
See: http://www.raspberrypi.org/phpBB3/vi...p?f=28&t=49223

A new version of the kernel is now out that reportedly solves the USB problems.

[LOWL1]

some month have gone until my last post and my question is now again:
is there any possibility to feed data to FR24 by using only SBS-3 and raspberry pi?
without a running basestation software? or is there no chance to decode it from sbs-3?
thanks in advance

[jbntx]

@thowe, I was having problems with the latest Raspian kernel (#494), couldn't even run "rtl_test -t" and get a good response, and dmesg had all kinds of errors. I downgraded to an earlier version of the kernel and everything went back to normal. You didn't be chance run rpi-update within the last 5 days or so, did you? If so, do this:

sudo rpi-update 5ea0f44b673eaa52c578fcd6480495f19cd53d97

This will take you back to the June 29th version of the kernel, #484.

You can check your kernel version by running:

uname -a

It looks like there is a new version of the kernel being tested which will hopefully fix the USB issues, but until then, don't upgrade your kernel.
See: http://www.raspberrypi.org/phpBB3/vi...p?f=28&t=49223

[roofer]

[QUOTEyour Premium account will show your feed status][/QUOTE]
Thanks for that. I see it now.

I could not filter on "Radar" when viewing www.flightradar24.com using FFox (22.0), but this works perfectly with Chromium ( 28.0.1500.52 ), and this is helpful to me.

Thanks to dtiller for the tcpdump command - I like it.

[FR24support]

As mentioned many times on other posts, your Premium account will show your feed status. Please see the screenshot, but ignore the actual status as this is a test account.

And do remember, as long as you're feeding your free Premium subscription is valid even if your data isn't displayed on Flightradar24.

01.jpg

[peterhr]

[ snip ]
So if I am using bandwidth to send you data that you'll just discard because I am in a well feeding, populated, metroploitan area, I can just stop. Other people perhaps have better coverage than I do.
This would be OK. Perhaps my RPi should be better employed.

I hope this doesn't sound nasty, I just wish to devote resources, and bandwidth, to projects that need them.

Best wishes,
R.

I admit, I feel much the same way - though it's not the fault of FR24

For those of us in Europe certainly where there seems to be 100% cover ... we certainly cannot see where there are holes from the present FR24 graphical data displays ... setting up new radars seems a bit pointless.

I do feel the PI + USB tuner + cheap co-linear is useful for a reasonable entry level system in areas where there is no cover or little redundancy in cover and for that I'd like to see very much simpler instructions for the setting up of this simple solution - from a recommended shopping list of what to buy, right down to the stage where a preconfigured SD card image for the PI was available for download ... and once installed, the user logs in and gets asked for a sharing key [with any present key being the default].

Of course this needs some method of feedback fro FR24 in the form of say an account query that returns T-xxxx02 has successfully uploaded nnnn data packets since 00:00 UTC [today]

but when it comes down to it where there is no cover
* are planes of any more interest than contrails in the sky?,
* do they have always on internet?
* and would they prefer to spend the money on a camel, cow, yak or goat?

[dtiller]

fr24feed_arm-le_233s is still running on my RPi.

wireshark tells me it is uploading data to your server.

But this is all a PITA to check up on, being that I have set up the hardware, constructed antennae, climbed about on the roof, fiddled with the software etc.

I would like you to offer me an easy way to check that "the FR24 feed is working".

R.

I feel your pain. I could not get the dynamically-linked version of the software to work at all. I saw data flowing but never saw my radar. I use version 225s of the software with my Pi and it works flawlessly (26 days since the last T-storm restarted the Pi). If you are interested I wrote and posted some startup/shutdown inet.d scripts for use with raspian, dump1090, and the FR24 feed software. They're a few posts up.

BTW, Wireshark over X11 is serious overkill - use tcpdump.

pi@adsb ~ $ sudo tcpdump udp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
20:03:41.063199 IP adsb.k4det.net.45753 > 83.140.247.21.8099: UDP, length 48
20:03:46.042515 IP adsb.k4det.net.45753 > 83.140.247.21.8099: UDP, length 80
20:03:51.028678 IP adsb.k4det.net.45753 > 83.140.247.21.8099: UDP, length 80
20:03:56.012256 IP adsb.k4det.net.45753 > 83.140.247.21.8099: UDP, length 80
20:03:56.012536 IP adsb.k4det.net.45753 > 83.140.247.21.8099: UDP, length 20
20:03:56.137660 IP 83.140.247.21.8099 > adsb.k4det.net.45753: UDP, length 20
20:04:01.047694 IP adsb.k4det.net.45753 > 83.140.247.21.8099: UDP, length 144
20:04:06.034383 IP adsb.k4det.net.45753 > 83.140.247.21.8099: UDP, length 80
20:04:11.012864 IP adsb.k4det.net.45753 > 83.140.247.21.8099: UDP, length 80
20:04:16.058756 IP adsb.k4det.net.45753 > 83.140.247.21.8099: UDP, length 112
20:04:21.034345 IP adsb.k4det.net.45753 > 83.140.247.21.8099: UDP, length 144
20:04:26.015677 IP adsb.k4det.net.45753 > 83.140.247.21.8099: UDP, length 80
20:04:31.062296 IP adsb.k4det.net.45753 > 83.140.247.21.8099: UDP, length 112

^C
pi@adsb ~ $

[roofer]

fr24feed_arm-le_233s is still running on my RPi.

wireshark tells me it is uploading data to your server.

But this is all a PITA to check up on, being that I have set up the hardware, constructed antennae, climbed about on the roof, fiddled with the software etc.

I would like you to offer me an easy way to check that "the FR24 feed is working".

I can use wireshark (painfully slow over ssh -Y pi@rpi on my network, but it still works) to check the data is being sent, but I wonder if this data being used by FR24?

I can go to http://www.flightradar24.com/planes but I cannot there set a filter there for my "radar" - no "radars" are listed for selection (Firefox 22.0)
So I have to <CTRL>-F and Find my radar in the long list, and keep reloading the pages...... and very sometimes I see data from my system. So, perhaps, it is working.

But it's boring.

So, if you'd like me to keep feeding you data, I ask you to devise a "Usefulness Factor" that you can return to me indicating my "usefulness" for my feed to FR24.

So if I am using bandwidth to send you data that you'll just discard because I am in a well feeding, populated, metroploitan area, I can just stop. Other people perhaps have better coverage than I do.
This would be OK. Perhaps my RPi should be better employed.

I hope this doesn't sound nasty, I just wish to devote resources, and bandwidth, to projects that need them.

Best wishes,
R.

[mindlesstux]

Like roofer,
Updated a little over 3 hr ago, appears that 233s is stable and good
232s, just did not work past 20 minutes or what ever the time was
been running 225s till this came out.

[roofer]

fr24feed_arm-le_233s is now running on my RPi, running raspian.

I did not start it with the --self-kill parameter (which isn't yet documented by fr24feed_arm-le_233s --help)

I'll keep an eye on it.

fr24feed_arm-le_225s was reliable, and what I was using until today, but fr24feed_arm-le_232s did not work for me.

Thanks for this update anyway.

[perefouras]

...I'd appreciate if some of you could give it a go.

the ARM LE, statically linked version has been running smoothly for the last 20 minutes or so on my raspberry pi !

[piopawlu]

There's now a new version of the Linux feeding software available for all currently supported platforms, v233 (links in the first post). It should help with locking out issues and introduces a --self-kill parameter that will terminate the app should there be no input data for 15 minutes. It defaults to "no" not to change the original behaviour.

I'd appreciate if some of you could give it a go.

[dtiller]

RPi /etc/init.d scripts for dump1090 and fr24feed

I took a moment and wrote /etc/init.d scripts for starting/stopping dump1090 and fr24feed on my RPi. Your paths may vary, so edit them appropriately. Create the attached files as /etc/init.d/dump1090 and /etc/init.d/fr24feed. Make sure to chmod +x them!


'Install' them using:
update-rc.d dump1090 start 80 2 3 4 5 . stop 20 0 1 6 .
update-rc.d fr24feed start 90 2 3 4 5 . stop 10 0 1 6 .

They will start when the RPi enters any of runlevel 2-5 and stop when entering any other runlevel.

[thowe]

In my case it could be a problem in the serial communication between the stick and the USB part of the Raspberry Pi. There have been many error reports in the past. The problems should have been solved, but maybe in combination with special hardware...?

Older: http://www.raspberrypi.org/phpBB3/viewtopic.php?t=12097
Newer: http://sijisunny.com/2013/02/06/rpi_bug/

Can i manually force the speed of the usb interface to a lower one?

I saw there are new OS images available. I will try the new one as well.

[peterhr]

Luckily using dump1090 I can point a web browser at the RPI on port 8080 and see if dump1090 is still doing stuff.