Announcement

Collapse
No announcement yet.

Linux feeder software for Flightradar24 (Old software)

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • My setup is similar except I'm using the RTL tuner stick.

    I noticed it had stopped working after a while - which I put down to the dump1090 program hanging.

    I set up services to run a script dump1090.sh and a separate script 'fr24' to run fr24feed_arm-le_225s

    all i did was create a cron job
    0 * * * * sudo service dump1090.sh restart
    1 * * * * sudu service fr24 restart

    on every hour at minute 0 restart dump1090
    at 1 minute past the hour restart FR24

    FR24 does seem to carry on working if dump1090 has been restarted, but just in case it did get a little upset I restarted that too.

    your single script could be run from a cron job too - just remember to enter the full path to the script as the thing the cron runs.

    oh. the services are set to start as the PI is started.

    Next job is to make a co-linear antenna from some co-ax cable as specified here http://www.balarad.net/ (presently I have a dipole made by splitting the about 10cm core out of a length of coax, as per the cork antenna - that's giving me about 200km radius)
    Last edited by peterhr; 2013-06-01, 15:04.

    Comment


    • Thanks! Actually I wrote the script with your strategy in mind: killing everything and start everything new. Currently my script runs every 10 minutes:


      Code:
      crontab -e:
      */10 * * * * /home/pi/adsb/start-fr24-feeding.sh
      Unfortunately it seems that the receiver-stick, adsbox or the serial communication between the two hangs very frequently under traffic load. With the antenna placed on the outside, receiving quite a lot of emissions, the system sometimes runs for 5 seconds only, sometimes for a few minutes.

      Does anybody know what the following init sequence does configure on the stick?
      Code:
      echo '#43.02' > /dev/ttyACM0
      I'm still hoping to get the system more stable soon: If it is running, several of my planes appear on fr24. And I like that.

      Comment


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

        Comment


        • 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.

          Comment


          • 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.
            Attached Files
            Last edited by dtiller; 2013-06-10, 21:01. Reason: Changed runlevel - default is 2, not 5.

            Comment


            • 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.

              Comment


              • Originally posted by piopawlu View Post
                ...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 !

                Comment


                • 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.

                  Comment


                  • 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.
                    T-KCLT1, Also the man behind the curtain working on the dump1090 webgui and the dump1090-helper project.

                    Comment


                    • 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.

                      Comment


                      • Originally posted by roofer View Post
                        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.

                        Code:
                        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 ~ $

                        Comment


                        • Originally posted by roofer View Post
                          [ 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?

                          Comment


                          • 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

                            Comment


                            • [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.

                              Comment


                              • @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

                                Comment

                                Working...
                                X