Page 23 of 71 FirstFirst ... 13212223242533 ... LastLast
Results 221 to 230 of 707

Thread: Linux feeder software for Flightradar24 (Old software)

  1. #221
    Passenger
    Join Date
    Mar 2013
    Posts
    8
    Quote 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 ~ $

  2. #222
    Captain
    Join Date
    Jan 2012
    Location
    Dudley area, UK
    Posts
    1,410
    Quote 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?

  3. #223
    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

  4. #224
    Passenger
    Join Date
    Feb 2013
    Location
    London, UK
    Posts
    43
    [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.

  5. #225
    Passenger
    Join Date
    May 2013
    Location
    McKinney, TX, USA
    Posts
    2
    @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

  6. #226
    Passenger
    Join Date
    Jan 2013
    Location
    next to Linz airport
    Posts
    43
    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

  7. #227
    Passenger
    Join Date
    May 2013
    Location
    McKinney, TX, USA
    Posts
    2
    Quote Originally Posted by jbntx View Post
    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.

  8. #228
    Passenger
    Join Date
    Jun 2013
    Location
    BEIJING
    Posts
    4
    When I use version 233 (fr24feed_x64_233), it always shows "Data feed time difference too big abs", like:
    ...
    [b]working
    [n]connected
    [n]switching to UDP
    [n]working
    [e]Data feed time difference too big abs( - 21:21:27.947)=1796900
    [e]Data feed time difference too big abs( - 21:21:28.047)=1796901
    [e]Data feed time difference too big abs( - 21:21:28.148)=1796901
    ...
    I have ntpd service to synchronize time for a long time, And the system time is correct.
    Time zone is "Asia/Shanghai".

    Version 225 "fr24feed_x64_225" dosen't have this problem.

    OS is CentOS 6.4 x64, decoder software is Malcolm Robb's dump1090. (https://github.com/MalcolmRobb/dump1090/)
    Last edited by youlun; 2013-07-19 at 13:45.

  9. #229
    Passenger
    Join Date
    Feb 2013
    Location
    London, UK
    Posts
    43
    When I use version 233 (fr24feed_x64_233), it always shows "Data feed time difference too big abs", like:
    I had to restart fr24feed_arm-le_233s yesterday, because it had stopped, maybe because the aerial was disconnected. It had been running well for about two weeks. Re-connecting the aerial did not restart the feed, so I killed and then restarted fr24feed_arm-le_233s.

    I saw exactly the same

    Code:
    [e]Data feed time difference too big abs( - )=232294
             .
         (repeat 20-30 times)
             .
    [e]Data feed time difference too big abs( - )=30537
    [i]Data feed time difference OK abs( - )=0
    [n]connected
    [n]switching to UDP
    [n]working
    [i]sent 27 planes in 1 packets
    [i]sent 31 planes in 1 packets
    [i]sent 29 planes in 1 packets
    [i]sent 26 planes in 1 packets
    So although it did not work immediately, it only took a few seconds to start. It has been fine since then.

    I also run ntpd (my RPi has GPS and supplies my network with a stratum 0 ntp time server, currently reporting an accuracy of 100nS, so my time is accurate.)
    Hardware: RTL2838 DVB-T, RPi,
    Linux: Raspian rpi 3.6.11+ #456 and using dump1090

  10. #230
    Passenger
    Join Date
    Aug 2013
    Location
    Saint-Chamond - 42 - FRANCE
    Posts
    7
    Hello,

    Is it possible to get fr24feed's sources (trunk with makefile) to crosscompile for openwrt.
    The goal is to build a standard ipk package for openwrt running on a NSLU2 box :

    Linux OpenWrt 2.6.32.27 #5 Wed Dec 21 05:58:17 CET 2011 armv5teb GNU/Linux

    dump1090 is operational on this box.

    Thank's.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •