Announcement

Collapse
No announcement yet.

Replace dump1090-fa with FR24 dump1090-mutability

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Replace dump1090-fa with FR24 dump1090-mutability

    Dear FR24 staff... Following the discovery that MLAT data is ignored unless you run a clean DVBT-stick install of the FR24 software, I ventured into removing my base dump1090-fa and replacing it with your software package. This I have now tried to do on 2 RBPi with Raspberrys latest version of OS based on Buster.

    I first stop the dump1090-fa services, and remove them using apt remove followed by apt purge. I then stop the piaware service and remove it too. Then autoremove to clean out any garbage left behind. Then a reboot, not because it is necessary but because I am born and raised with Windows and thats what you do then. I also check that there is no old skyaware or dump1090-fa config enabled in lighttpd.

    Now, figuring I have cleansed my system I go about installing FR24 version of Dump1090. This first by going to 8754 and choose DVBT-stick as option, since this will install dump1090-mutability. This does not work. Instead fr24feed stops working.
    After a bit of trials I choose to also remove and purge fr24feeder.
    Then I do a clean install of FR24feed from the link provided on the FR24 website. I use my old sharing key. This installs both fr24feeder AND dump1090-mutability. But it does not work.
    Code:
    [FAIL] FR24 Feeder/Decoder Process ... failed!
    How do I do to do what you need me to do to MLAT a little better? Khan Gaelan

  • #2
    Dude... I took a blank sd-card and flashed it with the latest Raspberry pi OS Lite (32 bit) for a headless setup. Updated all packages. Installed Fr24feeder first of all, clean & fresh. Works. Setup to match my feederid. So far so good!

    Then add Piaware (only), RBfeeder + mlatclient, opensky and ADSBx, in that order. Last adds graphs1090. Then tar1090. Reboot. Then...

    Code:
    [FAIL] FR24 Feeder/Decoder Process ... failed!
    So I remove tar1090 and reboot again. Still nothing. What is going on?!

    Code:
    ● fr24feed.service - Flightradar24 Decoder & Feeder
    Loaded: loaded (/etc/systemd/system/fr24feed.service; enabled; vendor preset: enabled)
    Active: failed (Result: signal) since Mon 2021-05-17 21:21:22 CEST; 1min 1s ago
    Process: 4220 ExecStartPre=/usr/lib/fr24/install_dump1090.sh (code=exited, status=0/SUCCESS)
    Process: 4224 ExecStartPre=/usr/lib/fr24/unregister_kernel_modules.sh (code=exited, status=0/SUCCESS)
    Process: 4228 ExecStartPre=/usr/lib/fr24/create_missing_directories.sh (code=exited, status=0/SUCCESS)
    Process: 4231 ExecStart=/usr/bin/fr24feed (code=killed, signal=SEGV)
    Main PID: 4231 (code=killed, signal=SEGV)
    
    May 17 21:21:22 MooPII systemd[1]: fr24feed.service: Service RestartSec=100ms expired, scheduling restart.
    May 17 21:21:22 MooPII systemd[1]: fr24feed.service: Scheduled restart job, restart counter is at 5.
    May 17 21:21:22 MooPII systemd[1]: Stopped Flightradar24 Decoder & Feeder.
    May 17 21:21:22 MooPII systemd[1]: fr24feed.service: Start request repeated too quickly.
    May 17 21:21:22 MooPII systemd[1]: fr24feed.service: Failed with result 'signal'.
    May 17 21:21:22 MooPII systemd[1]: Failed to start Flightradar24 Decoder & Feeder.

    Comment


    • #3
      Code:
      Segmentation fault
      ... I have recieved that error on actually 3 different recievers now. That all have been working perfectly fine. And work perfectly fine once I revert back to a setup based on (another instance of dump1090 that is also available).

      ...ok the other instance is dump1090-fa. There. Said it.
      Last edited by hansp; 2021-05-17, 20:52.

      Comment


      • #4
        Ok, so setting dump1090-mutability to start at boot at least starts dump1090 and there are aircraft recieved. So that is not the problem. FR24feeder still won't start though.

        Comment


        • #5
          Support ticket sent.

          Comment


          • #6
            you should show the fr24feed.ini for those segfaults ;P

            Comment


            • #7
              You are essentially highlighting the world of Linux and scripted package installs.

              Unless the user has the ability to gain a strong grasp on what each different persons script does.
              And that provider have equally tried to account for the opposition providers installs to account for any overlaps that could cause the other to stop working (as Wiedehopf grows his scripts looking for others and tries to)

              Then there can be issues met along the way if installing a lot at once and not checking between to reverse or remedy any adverse changes.

              I expect, a support request will likely focus on instruction to scale back to a standard FR24 alone install again. As adding others, can basically modify and change the expected outcome and effect the install they provide out-of-box

              All the guides and how-tos you see provided around the place are tricky as a result of this. Written to try massage and add enablement to use more than the out-of-box FR24 install (that only really comes with a 'is there a dump1090 present' and 'did they chose DVBT' logic check on initial install).

              Anything that modifies aspects of the default install after this. Can break it.
              Posts not to be taken as official support representation - Just a helpful uploader who tinkers

              Comment


              • #8
                What basically makes me behave like a kid that has lost his marbles is that I can do all this if I use the dump1090-fa as base. No problem messing about quite a lot. But apparently the fr24feeder is more fragile. And since I still have not given up on that MLAT I figured I'd go the distance and re-do all feeders. But I will not settle for only feeding 1 service.

                Comment


                • #9
                  Originally posted by wiedehopf View Post
                  you should show the fr24feed.ini for those segfaults ;P
                  I put the old sd back in but it was unedited, out of the box. No custom arguments.

                  Comment


                  • #10
                    May or may not be related. But it always use to crash all the time on me with more than 3 simultaneously connected tcp open streams on client.

                    (When I'm not even using dump1090!)

                    And building on it as the base didn't work.

                    It had a limit.
                    It wouldn't decrease or release disconnected ones It wouldn't allow any short outtage re-establishment
                    I raised it. The simultaneous limit was raised

                    A few versions later it was back to same. And realtime sql logging from the output was no longer possible as it would always kill tcps and auto restart while denying them.

                    Was at that point it got the shove. Was no longer primary And moved to single tcp feed to beast splitter, and everything behind that.

                    Posts not to be taken as official support representation - Just a helpful uploader who tinkers

                    Comment


                    • #11
                      Originally posted by hansp View Post
                      Ok, so setting dump1090-mutability to start at boot at least starts dump1090 and there are aircraft recieved. So that is not the problem. FR24feeder still won't start though.
                      With receiver="dvbt" setting, even if fr24feed starts OK, setting dump1090-mutability to start at boot will lead to problem.
                      One copy of dump1090-mutability will be started at boot by system control
                      Second copy will be started by fr24feed.

                      This will cause conflict and failure.

                      Please issue following command, and when asked "Start dump1090-mutability automatically?", select NO.


                      Originally posted by hansp View Post

                      I put the old sd back in but it was unedited, out of the box. No custom arguments.
                      By default, the copy of dump1090-mutability started by fr24feed does NOT provide Best data on port 30005. As a result you cannot feed Flightaware, Planefinder and Adsbexchange from it.

                      To open dump1090-mutability's Beast port 30005, the FR24 feeder has to pass argument "--net" to it. So you have to add following line in file /etc/fr24feed.ini:

                      procargs="--net"

                      This will however open ports 30002 and 30003 of dump1090-mutability which will conflict as these ports on which fr24feed also outputs data. To avoid this conflict, you have to block fr24feed from outputing data on these ports by following changes in file fr24feed.ini

                      bs="yes" to bs="no"
                      raw="yes" to raw="no"

                      To summarize,
                      (1) Change "Start dump1090-mutabilty automatically?" back to its default NO
                      (2) Your file /etc/fr24feed.ini should be modified like this:
                      (modifications in red)


                      receiver="dvbt"
                      fr24key="xxxxxxxxxxxxxxxx"
                      bs="no"
                      raw="no"
                      procargs="--net --gain -10"
                      logmode="1"
                      logpath="/var/log/fr24feed"
                      mlat="yes"
                      mlat-without-gps="yes"




                      .
                      Last edited by abcd567; 2021-05-18, 07:44.

                      Comment


                      • #12
                        If you re-read first post. I think hansp is driving a point to support. To show how unfriendly it is under standard conditions, vs actually solving.
                        Posts not to be taken as official support representation - Just a helpful uploader who tinkers

                        Comment


                        • #13
                          Indeed, but I am also grateful for any support recieved. This is a follow up to the previous post where FR24 confirmed that no data was used for MLAT if not FR24 software package was used as base, a surprise to many of us because during all these years we have been looking at that big green YES on MLAT status on the settings page. Really when setting up the fr24feeder and selecting anything else but DVBT-stick it should be a big red NO on :8754.

                          My fr24feed.ini conformes with the suggestions above but still fr24feed will not start. I will re-do installation but first "reverse-engineer" by removing installed packages one by one and hopefully find which one collides with fr24feed. It is not dump1090-mut that is the problem because it does not start upon boot. Something else is causing fr24feed to not start on boot.

                          Like I wrote earlier I have so far had no issues what so ever adding all kinds of feeders when using -fa and piaware as base. I do not like that fr24feeder seemingly needs exclusive access to my equipment, and then is bundled with an interface which is old and featureless.

                          Comment


                          • #14
                            Originally posted by Oblivian View Post
                            If you re-read first post. I think hansp is driving a point to support. To show how unfriendly it is under standard conditions, vs actually solving.
                            You are right Oblivian, but do the Support care for this?

                            Actually it is not Support, it is Developers. If the Developers change default fr24feed.ini settings as I have shown, it will make fr24feed compatible with other feeders out of the box... no need to do any modifications by the user, while still fulfilling FR24's mlat requirement (i.e. receiver="dvbt")

                            Comment


                            • #15
                              (1) I have just now burned Raspberry Pi OS "2021-03-04-raspios-buster-armhf-lite.img" on microSD card, slipped the microSD card in RPi Model 4, powered up.
                              (2) Next installed fr24feed by following bash script, and during configuration selected receiver="dvbt".
                              All is well, no segmentation fault.
                              Code:
                              sudo bash -c "$(wget -O - http://repo.feed.flightradar24.com/install_fr24_rpi.sh)"
                              (3) Edited /etc/fr24feed.ini, and amended as shown in screenshot below (please refer my last post above for details of amendments).
                              Beast data is now available at port 30005 for data feeders Piaware, Pfclient, and Adsbexchange
                              Station marker and range Circles appeared on dump1090 map due to addition of --lat xx.x and --lon yy.y in procargs line of fr24feed.ini

                              fr24feed version & status
                              fr24feed.png


                              /etc/fr24feed.ini
                              fr24feed.ini.png


                              Beast Output at port 30005 (required to feed Flightaware, Planefinder, Adsbexchange etc)
                              fr24feed-30005.png



                              Installed Flightaware's Data Feeder Piaware. It grabs data from port 30005 of dump1090-mutability
                              piaware.png
                              Last edited by abcd567; 2021-05-18, 11:54.

                              Comment

                              Working...
                              X