Announcement

Collapse
No announcement yet.

Archived: Feed issues with 19-2

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

  • JohnSunnyhills
    replied
    I assume that when you refer to updating to 19-5 you are actually saying to use the link provided by Khan earler today.

    I run this and get an error almost immediately saying "line 8: /dev/mmcblk0p7: Permission denied

    Is this my problem

    Leave a comment:


  • m33as
    replied
    Your help was genuinely appreciated! It turned out dump1090-mutability was already, independently running, prohibiting fr24feed to connect to the SDR properly. As mention in the bit-by-bit post! So stopping it, and letting fr24feed load it, did the trick!

    Leave a comment:


  • Oblivian
    replied
    Originally posted by m33as View Post
    Oblivian - thank you. The bit-by-bit post was what I needed, I honestly wasn't aware of it (I apologise). But, it clarified a lot for me, and helped go through the steps to make A working before trying B, getting B working, etc... Thank you a lot. It's running fine now.

    /Gunnar
    Good to hear. See my perceived attitude isnt always in vein

    Out of curiosity what was the cause/fix? Installed but not started or started but conflict

    Sent from my XT1092 using Tapatalk

    Leave a comment:


  • m33as
    replied
    Oblivian - thank you. The bit-by-bit post was what I needed, I honestly wasn't aware of it (I apologise). But, it clarified a lot for me, and helped go through the steps to make A working before trying B, getting B working, etc... Thank you a lot. It's running fine now.

    /Gunnar

    Leave a comment:


  • Oblivian
    replied
    Originally posted by m33as View Post
    Hi all, I must admit, (as a not very confident user) that I don't understand what they really did with 19-2... all I know, I re-downloaded/installed the fr24feed through repo.feed.flightradar24... So I see it installed dump1090-mutability in /usr/bin. But when I run fr24feed-status, I get:

    [ ok ] FR 24 Feeder/Decoder Process: running
    [ ok ] FR 24 Stats Timestamp...
    [ ok ] FR 24 Link: connected [TCP]
    [ ok ] FR 24 Radar: <ID>
    [ ok ] FR 24 Traced AC: .
    [FAIL] Receiver: down ... failed !
    [FAIL] FR24 MLAT: not running ... failed!

    And I don't quite know (nor understand) why the receiver is down, or fails? What could this be?

    Thanks for any hints! Sorry for yet posting again Oblivian - but I honestly don't get it.
    Out of the box, users who chose DVBT (or the Pi24 image )stick as a receiver previously set off 2 things in the software. Install, and then Start Dump1090 on-demand, and then connect to that dump1090 and send the data (as outlined in my FAQ)

    The 19-2 script Removed Dump1090-MR - Which was being used by anyone with 'DVBT Stick' set as receiver type in the config. = instant fail
    At the same time Added Dump1090-Mutability
    - Did not reconfigure itself to use it or set it to auto-start (the connector part of the decoding process to actually initialize the DVBT)

    So ABCDs methods, Depending on user requirements work well. But everyone has to do basic checks beforehand to see which of the causes is in effect

    There are so many combinations of setup, some users may find:
    2 copies of Dump1090 left behind/running and locking the USB stick (any attempt to start FR24feed again would fail unless changed to ARTCP receiver)
    DUmp1090-Mutability installed/running locking the USB stick (any attempt to start FR24feed again would fail unless changed to ARTCP receiver)
    NO dump1090 installed
    No Dump1090 auto starting

    WHich is where the bit by bit diagnostics comes in https://forum.flightradar24.com/thre...ll=1#post74851

    pgrep commands to look for running services and ensure they're all stopped or at a state that is expected
    Not running FR24feed as a service to see errors / what happens when it starts and get Dump1090s feedback after it tries to reload it

    It's the issue with automation and assuming everyone will follow the same procedure, when in reality we all like to have different feeders and setups to do other tasks on the device. So theres no 1-hit fix. But we've attempted to outline the most likely scenarios

    Just a matter of people getting to know the basic commands and the flow of how the data gets from the airwaves, to the stick, to the decoder, to the uploader and which apps in the chain
    Last edited by Oblivian; 2018-01-18, 21:19.

    Leave a comment:


  • m33as
    replied
    Hi all, I must admit, (as a not very confident user) that I don't understand what they really did with 19-2... all I know, I re-downloaded/installed the fr24feed through repo.feed.flightradar24... So I see it installed dump1090-mutability in /usr/bin. But when I run fr24feed-status, I get:

    [ ok ] FR 24 Feeder/Decoder Process: running
    [ ok ] FR 24 Stats Timestamp...
    [ ok ] FR 24 Link: connected [TCP]
    [ ok ] FR 24 Radar: <ID>
    [ ok ] FR 24 Traced AC: .
    [FAIL] Receiver: down ... failed !
    [FAIL] FR24 MLAT: not running ... failed!

    And I don't quite know (nor understand) why the receiver is down, or fails? What could this be?

    Thanks for any hints! Sorry for yet posting again Oblivian - but I honestly don't get it.
    Last edited by m33as; 2018-01-18, 20:51. Reason: added info

    Leave a comment:


  • elljay
    replied
    The file that runs the update cron job is in /etc/cron.d/fr24feed_updater

    Leave a comment:


  • Oblivian
    replied
    Originally posted by Locus_Coeruleus
    Thanks Oblivian. I had noticed one of my feeders was offline and followed the instructions in your post #11. I used my same .ini file when asked and no problem. This same feed to PiAware feed to FA never died. The whole deal was a bit of a hassle as this feeder is on the roof, mounted on a 15' aluminum pole with the antenna and Raspberry Pi stuffed in a 2' section of 4" ABS pipe as a radome/protection. I run 5V to the Pi up inside the ABS pipe using outdoor low voltage landscape wiring. The ABS pipe is connected to the aluminum pipe with a reducer coupling. The Pi connects to the internet via wifi. I hope this software glitch is fixed as I really do not want to have to take it down and mess with the Pi. It is just too much trouble. I suspect this was an auto-update feature. Is there a way to block updates (like in the .ini file)? I do not recall an option during installation of FR24 to disable updates. While I am good with computers, I have to cheat using the Linux command line. My other feeder has not missed a beat. I think part of that reason is that I intermittently power down the roof top Pi. My suspicion is that when I power it back up, the software looks for updates. The other Pi is virtually always on--hence the reason it never updated. Maybe I am mistaken, but this makes the most sense.
    There is a file you can edit somewhere and disable the updates. Not sure where exactly it was located. Another user posted some instructions if you have a hunt (but it will return after a manual update).

    Sent from my XT1092 using Tapatalk

    Leave a comment:


  • abcd567
    replied
    Wont re-imaging (format microSD card + Pi24 img), or (format microSD card + Raspbian img + feeder install by bash script) or (format microSD card + Piaware img + feeder install by bash script) easier and cleaner solution?

    Leave a comment:


  • Oblivian
    replied
    FR24feed Purge or Uninstall Commands

    AKA DVBT users Fresh install after broken upgrade if you are brave (non brave should just reimage the SD card..)

    *results may vary - those with other feeders using dump1090-mutability may be affected or have issues

    Note down feeder location and key settings beforehand. Or backup fr24feed.ini and re apply later.

    Confirm version via webpage or command - dpkg -s fr24feed | grep Version

    sudo apt-get update
    sudo apt-get remove -- purge fr24feed
    * remove dump1090 at bottom
    sudo apt-get clean

    Rerun install script

    ( - may ask if you wish to over-write fr24feed.ini, do so)

    Sudo fr24feed - confirm running and config by normal web page method.

    OK? - Close down and start as service

    sudo service fr24feed start
    (may require reboot before/after)

    Config not OK?

    sudo fr24feed --signup


    stop auto-update
    sudo rm /etc/cron.d/fr24feed_updater




    DVBT stick / Solo + Independent FR24feeders who have not performed dump1090 installs previously -
    (removal/stop of newly included dump1090-mutability may be also required as suggested elsewhere - this will most certainly effect units running FA or other feeders.. you have been warned)

    pgrep -l dump1090
    sudo kill -9 <id of dump1090>
    sudo killall dump1090-mutability
    sudo apt-get remove --purge dump1090-mutability


    Users of FR24feed prebuilt Image
    Repeat setup instructions to burn pi24 image
    https://www.flightradar24.com/build-your-own (hopefully is 18-9)

    Additional step-by-step check commands
    https://forum.flightradar24.com/thre...ll=1#post74851
    Last edited by Oblivian; 2018-01-28, 09:28.

    Leave a comment:


  • abcd567
    replied
    Originally posted by Oblivian
    I was going to ask if .14 had the web portal built in, assumming that is without the extra httpd install?

    As that would have sorted antonioag95s concerns by simply re-running the bash scripted install
    Yes, the web portal at :8080 came WITHOUT installing lighttpd

    And did you have to do the dirmgr install? (that was removed from the linked install guide page by FR24 staff)
    YES, both the dirmngr and librtlsdr0
    PLUS workaround for Stretch (rtlsdr rules)

    Code:
    STEP-1: UPDATE
    pi@raspberrypi:~ $ sudo apt-get update
    
    STEP-2: INSTALL 2 DEPENDENCIES
    pi@raspberrypi:~ $ sudo apt-get install dirmngr
    
    pi@raspberrypi:~ $ sudo apt-get install librtlsdr0
    
    STEP-3: INSTALL FR24FEED
    pi@raspberrypi:~ $ sudo bash -c "$(wget -O - http://repo.feed.flightradar24.com/install_fr24_rpi.sh)"
    
    #WORKAROUND (ONLY FOR RASPBIAN STRETCH)
    pi@raspberrypi:~ $ sudo wget -O  /etc/udev/rules.d/rtl-sdr.rules "https://raw.githubusercontent.com/osmocom/rtl-sdr/master/rtl-sdr.rules"
    Last edited by abcd567; 2018-01-16, 12:19.

    Leave a comment:


  • abcd567
    replied
    FRESH INSTALL OF fr24feed 1.0.19-2 ON RASPBIAN STRETCH (NOT UPDATE OF EXISTING FEEDER)

    FR24-1.0.19-2-map.png FR24-1.0.19-2-status.png FR24-1.0.19-2-settings.png

    Leave a comment:


  • mbirth
    replied
    Originally posted by abcd567 View Post
    sudo bash -c "$(wget -O - h**p://repo.feed.flightradar24.com/install_fr24_rpi.sh)"

    It installs dump1090-mutability_1.14, instead of dump1090-mr
    Please scroll-down and see code lines in red below

    Code:
    # Download and install dump1090-mr
    [COLOR="#FF0000"]wget -O /tmp/dump1090-mutability_1.14_armhf.deb h**ps://github.com/mutability/dump1090/releases/download/v1.14/dump1090-mutability_1.14_armhf.deb
    dpkg -i /tmp/dump1090-mutability_1.14_armhf.deb
    rm -f /tmp/dump1090-mutability_1.14_armhf.deb[/COLOR]
    But why can't that package be included in the repo and set as a dependency for fr24feed? Maybe even with a symlink from /usr/lib/fr24/dump1090 ... that way, a simple update of the (previous) default installation wouldn't break anything.

    Leave a comment:


  • abcd567
    replied
    SUCCESSFUL FRESH INSTALLATION OF fr24feed 1.0.19-2 ON RASPBIAN STRETCH

    SCROLL DOWN TO SEE ALL STEPS

    After installation, location of dump1090-mutability is /usr/bin/dump1090-mutability

    Code:
    [COLOR="#FF0000"]STEP-1: UPDATE[/COLOR]
    pi@raspberrypi:~ $ sudo apt-get update
    
    [B][COLOR="#FF0000"]STEP-2: INSTALL 2 DEPENDENCIES[/COLOR][/B]
    pi@raspberrypi:~ $ sudo apt-get install dirmngr
    
    pi@raspberrypi:~ $ sudo apt-get install librtlsdr0
    
    [B][COLOR="#FF0000"]STEP-3: INSTALL FR24FEED[/COLOR][/B]
    pi@raspberrypi:~ $ sudo bash -c "$(wget -O - http://repo.feed.flightradar24.com/install_fr24_rpi.sh)"
    
    [B][COLOR="#FF0000"]STEP-4: CHECK INSTALLED VERSIONS[/COLOR][/B]
    pi@raspberrypi:~ $ apt-cache policy fr24feed                                    
    fr24feed:
      Installed: 1.0.19-2
      Candidate: 1.0.19-2
      Version table:
     *** 1.0.19-2 500
            500 http://repo.feed.flightradar24.com flightradar24/raspberrypi-stable armhf Packages
            100 /var/lib/dpkg/status
    
    pi@raspberrypi:~ $ apt-cache policy dump1090-mutability
    dump1090-mutability:
      Installed: 1.14
      Candidate: 1.14
      Version table:
     *** 1.14 100
            100 /var/lib/dpkg/status
    
    [B][COLOR="#FF0000"]STEP-5: CHECK dump1090-mutability is working OK[/COLOR][/B]
    pi@raspberrypi:~ $ sudo systemctl stop dump1090-mutability
    
    pi@raspberrypi:~ $ /usr/bin/dump1090-mutability
    Tue Jan 16 04:59:20 2018 EST  dump1090-mutability v1.14 starting up.
    Found 1 device(s):
    0: , p▒▒v, SN:  (currently selected)
    usb_open error -3
    [COLOR="#FF0000"]Please fix the device permissions, e.g. by installing the udev rules file rtl-sdr.rules[/COLOR]
    Error opening the RTLSDR device: Permission denied
    
    [COLOR="#FF0000"]#Above Error is given in Raspbian STRETCH. In Raspbian JESSIE, this error is not there.[/COLOR]
    
    [COLOR="#FF0000"][B]#WORKAROUND (ONLY FOR RASPBIAN STRETCH)[/B][/COLOR]
    pi@raspberrypi:~ $ sudo wget -O  /etc/udev/rules.d/rtl-sdr.rules "https://raw.githubusercontent.com/osmocom/rtl-sdr/master/rtl-sdr.rules"
    
    --2018-01-16 05:00:59--  https://raw.githubusercontent.com/osmocom/rtl-sdr/master/rtl-sdr.rules
    Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 151.101.124.133
    Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|151.101.124.133|:443... connected.
    HTTP request sent, awaiting response... 200 OK
    Length: 5794 (5.7K) [text/plain]
    Saving to: ‘/etc/udev/rules.d/rtl-sdr.rules’
    
    /etc/udev/rules.d/r 100%[===================>]   5.66K  --.-KB/s    in 0.001s
    
    2018-01-16 05:00:59 (5.13 MB/s) - ‘/etc/udev/rules.d/rtl-sdr.rules’ saved [5794/5794]
    
    
    [COLOR="#FF0000"][B]REBOOT TO IMPLEMENT ABOVE WORKAROUND[/B][/COLOR]
    pi@raspberrypi:~ $ sudo reboot
    
    
    [COLOR="#FF0000"][B]STEP-6: CHECK dump1090-mutability is working OK[/B][/COLOR]
    pi@raspberrypi:~ $ sudo systemctl stop dump1090-mutability                      
    
    pi@raspberrypi:~ $ /usr/bin/dump1090-mutability
    Tue Jan 16 05:03:02 2018 EST  dump1090-mutability v1.14 starting up.
    Found 1 device(s):
    0: Realtek, RTL2832U, SN: 00001003 (currently selected)
    Detached kernel driver
    Found Rafael Micro R820T tuner
    Max available gain is: 49.60 dB
    Setting gain to: 49.60 dB
    Exact sample rate is: 2000000.052982 Hz
    Gain reported by device: 49.60 dB
    *5daaf183137271;
    CRC: 000000
    RSSI: -32.1 dBFS
    Time: 2447729.50us (phase: 0)
    DF 11: All Call Reply.
      Capability  : 5 (Level 2+, airborne)
      ICAO Address: aaf183
      IID         : II-00
    Last edited by abcd567; 2018-01-16, 10:34.

    Leave a comment:


  • Oblivian
    replied
    Please don't take offence chaps, need to remove some of those posts/suggestions we come up with prior to not cause confusion to anyone else finding it.

    It appears like the bash needs to be re-run for this release to do correctly and reconfigure the .ini to suit the new dependencies.

    I've updated a few key threads/posts to reflect

    A straight update may break if not a user of Dump1090-mutability or other feeder D1090 version already. But re running the bash looks the ticket.

    Leave a comment:

Working...
X