Announcement

Collapse
No announcement yet.

Can't get the receiver to send data to the feeder [Ubuntu20.04]

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

  • Can't get the receiver to send data to the feeder [Ubuntu20.04]

    I am trying to get fr24 running on ubuntu20.04. Right now I have tried on a physical machine and also a few virtual machines, however it should eventually run in a virtual machine (I use a Nooelec NESDR Mini).
    For the last three days I have tried everything, including guides from erpomik from 2019 and the excellent guides and scripts from abcd567. However all the installs have failed at one step or another, being the nonexistent libbladerf1-library in ubuntu20.04 or the installer not finding the file. I am now at a point where (on the physical machine) the fr24 feeder is running and showing up on the fr24 page, however if I do fr24feed-status, it shows
    Code:
    * FR24 Feeder/Decoder Process: running
    * FR24 Stats Timestamp: 2021-01-10 15:59:14
    * FR24 Link: connected [UDP]
    * FR24 Radar: T-Lxxxxxx
    * FR24 Tracked AC: 0
    * Receiver: connected (0 MSGS/0 SYNC)
    * FR24 MLAT: not running
    It isn't showing any planes either on the localhost:8754 page or the fr24 site, despite there being traffic.
    Additionally (although not my main goal) when I open the website localhost:dump1090/ it shows a map and the message:
    Problem fetching data from dump1090.
    The data from dump1090 hasn't been updated in a while. Maybe dump1090 is no longer running?
    The displayed map data will be out of date.
    I appreciate any help to get me out of my problems.
    TL;DR It doesn't work on my ubuntu machine

  • #2
    Use the readsb decoder install linked here: https://github.com/wiedehopf/adsb-wi...ADS-B-receiver
    (it's compiled on your machine / architecture and doesn't require as many dependencies)

    Then set up fr24 to use that data (the instructions for fr24 only work on a pi)
    But seems you have fr24 already running the script will even reconfigure it to use 30005 and beast as a data source.

    Comment


    • #3
      I "factory reset" my machine and started to install everything as mentioned in your link. The readsb install works just fine and the ip/radar site comes up (doesn't show anything, no planes in the area), but when I do the tar1090 install it comes up with this:
      Code:
      FATAL: could not find aircraft.json in any of the usual places!
      checked these: /run/readsb /run/dump1090-fa /run/dump1090 /run/dump1090-mutability /run/adsbexchange-feed /run/skyaware978
      Any ideas?

      Edit: I installed dump1090-fa and fr24-feeder from the automated scripts from github/abcd567a/fr24feed-debian-ubuntu-amd64, however when doing the setup and choosing receiver type 1 it says:
      Code:
      Enter your receiver type (1-7)$:1
      Checking for dump1090...NOT FOUND
      Now when doing fr24feed-status it says feeder/decoder process is down.
      Last edited by fhoertnagl; 2021-01-11, 02:09.

      Comment


      • #4
        If you choose receiver type 1 (DVBT), then you have to first uninstall the dump1090-fa (or readsb) which you have installed using the Github scripts, as with setting "1 - DVBT", the fr24feed will install dump1090-mutability (EB_VER). Having two versions of dump1090 will cause conflict and failure.

        If you choose "4 - ModeSBeast (TCP)", then fr24feed will not try to install dump1090-mutability, and would try to get data from dump1090-fa or readsb), which ever you have installed and is working OK.
        Last edited by abcd567; 2021-01-11, 09:21.

        Comment


        • #5
          If tar1090 didn't want to install then readsb wasn't running correctly.
          The /radar page should have shown an error as well ... not sure why it wouldn't.

          And yes dump1090 and dump1090-fa and readsb are all decoders that require to use the SDR.
          If you install more than one that's no good.


          Anyhow .. if readsb didn't run means your SDR isn't working right probably.
          The following command shows the readsb log
          sudo journalctl -u readsb | tail -n30

          But running rtl_test will probably be required.
          My suspicion is that you aren't able to access the SDR.
          For some more log checking ... and a script to test the SDR see: https://github.com/wiedehopf/adsb-wi...Debug-commands

          Comment


          • #6
            I have now uninstalled both readsb and fr24feeder, in which order should I reinstall them? And when setting up the receiver on fr24, what should I type in when the setup asks me about the receiver ip/port?

            Comment


            • #7
              If you install readsb with the script it will remove dump1090-fa (if it's installed).

              ip is 127.0.0.1 and port is 30005

              Doesn't matter much what you install first.
              After installing readsb, show the output from this command:

              sudo journalctl -u readsb | tail -n30

              Comment


              • #8
                I installed readsb first, then fr24feed and set it up on 127.0.0.1 and port 30005. Running fr24feed-status it showed this:
                Code:
                 * FR24 Feeder/Decoder Process
                Running sudo journalctl -u readsb | tail -n30 showed this:

                Code:
                Jšn 11 17:33:05 fr24ubuntu systemd[1]: readsb.service: Scheduled restart job, restart counter is at 1.
                Jšn 11 17:33:05 fr24ubuntu systemd[1]: Stopped readsb ADS-B receiver.
                Jšn 11 17:33:05 fr24ubuntu systemd[1]: Started readsb ADS-B receiver.
                Jšn 11 17:33:05 fr24ubuntu readsb[3606]: Mon Jan 11 17:33:05 2021 CET readsb starting up.
                Jšn 11 17:33:05 fr24ubuntu readsb[3606]: readsb version: wiedehopf git: af51c4e (get rid of some compile errors, Sun Jan 10 20:28:06 2021 0100)
                Jšn 11 17:33:05 fr24ubuntu readsb[3606]: struct sizes: 1608, 24, 64, 108
                Jšn 11 17:33:05 fr24ubuntu readsb[3606]: Using lat: 47.6694, lon: 12.1839
                Jšn 11 17:33:05 fr24ubuntu readsb[3606]: rtlsdr: using device #0: Generic RTL2832U OEM (Realtek, RTL2838UHIDIR, SN 00000001)
                Jšn 11 17:33:05 fr24ubuntu readsb[3606]: Detached kernel driver
                Jšn 11 17:33:05 fr24ubuntu readsb[3606]: Found Rafael Micro R820T tuner
                Jšn 11 17:33:05 fr24ubuntu readsb[3606]: rtlsdr: enabling tuner AGC
                Jšn 11 17:33:06 fr24ubuntu readsb[3606]: db update done!
                Jšn 11 17:33:06 fr24ubuntu readsb[3606]: Raw TCP output: Listening on port 30002
                Jšn 11 17:33:06 fr24ubuntu readsb[3606]: Beast TCP output: Listening on port 30005
                Jšn 11 17:33:06 fr24ubuntu readsb[3606]: SBS TCP output: Listening on port 30003
                Jšn 11 17:33:06 fr24ubuntu readsb[3606]: Beast TCP input: Listening on port 30004
                Jšn 11 17:33:06 fr24ubuntu readsb[3606]: Beast TCP input: Listening on port 30104
                Jšn 11 17:33:06 fr24ubuntu readsb[3606]: startup complete after 0.838 seconds.
                Jšn 11 17:33:06 fr24ubuntu readsb[3606]: Allocating 16 zero-copy buffers
                Jšn 11 17:33:10 fr24ubuntu readsb[3606]: Mon Jan 11 17:33:10 2021 CET No data received from the SDR for a long time, it may have wedged, exiting!
                Jšn 11 17:33:10 fr24ubuntu readsb[3606]: Mon Jan 11 17:33:10 2021 CET Waiting for receive thread termination
                Jšn 11 17:33:10 fr24ubuntu readsb[3606]: rtlsdr_demod_write_reg failed with -4
                Jšn 11 17:33:10 fr24ubuntu readsb[3606]: rtlsdr_demod_read_reg failed with -4
                Jšn 11 17:33:10 fr24ubuntu readsb[3606]: r82xx_write: i2c wr failed=-4 reg=06 len=1
                Jšn 11 17:33:10 fr24ubuntu readsb[3606]: rtlsdr_demod_write_reg failed with -4
                Jšn 11 17:33:10 fr24ubuntu readsb[3606]: rtlsdr_demod_read_reg failed with -4
                Jšn 11 17:33:10 fr24ubuntu readsb[3606]: rtlsdr_write_reg failed with -4
                Jšn 11 17:33:10 fr24ubuntu readsb[3606]: Reattaching kernel driver failed!
                Jšn 11 17:33:10 fr24ubuntu readsb[3606]: Mon Jan 11 17:33:10 2021 CET Normal exit.
                Jšn 11 17:33:10 fr24ubuntu systemd[1]: readsb.service: Succeeded.
                Also, ip/radar doesn't work, only shows 404 not found.

                Am I too stupid to follow instructions or isn't it working on my machine?
                Last edited by fhoertnagl; 2021-01-11, 16:55.

                Comment


                • #9
                  Your SDR isn't working properly, that's usually due to insufficient voltage or sometimes the SDR is simply broken.
                  These lines are showing the issue:

                  Jšn 11 17:33:06 fr24ubuntu readsb[3606]: Allocating 16 zero-copy buffers
                  Jšn 11 17:33:10 fr24ubuntu readsb[3606]: Mon Jan 11 17:33:10 2021 CET No data received from the SDR for a long time, it may have wedged, exiting!
                  Jšn 11 17:33:10 fr24ubuntu readsb[3606]: Mon Jan 11 17:33:10 2021 CET Waiting for receive thread termination
                  Jšn 11 17:33:10 fr24ubuntu readsb[3606]: rtlsdr_demod_write_reg failed with -4
                  Jšn 11 17:33:10 fr24ubuntu readsb[3606]: rtlsdr_demod_read_reg failed with -4
                  Jšn 11 17:33:10 fr24ubuntu readsb[3606]: r82xx_write: i2c wr failed=-4 reg=06 len=1
                  Jšn 11 17:33:10 fr24ubuntu readsb[3606]: rtlsdr_demod_write_reg failed with -4
                  Jšn 11 17:33:10 fr24ubuntu readsb[3606]: rtlsdr_demod_read_reg failed with -4
                  Jšn 11 17:33:10 fr24ubuntu readsb[3606]: rtlsdr_write_reg failed with -4
                  Jšn 11 17:33:10 fr24ubuntu readsb[3606]: Reattaching kernel driver failed!

                  Typical issues are USB extension cables dropping the voltage .... or your system just doesn't supply sufficient USB power.

                  Comment


                  • #10
                    oh boy... I am using a usb-over-ethernet-cable-extension, that is the problem then. I guess I have to use a raspberrypi after all...
                    I'll try a powered USB hub, hopefully this will help!

                    Comment


                    • #11
                      Readsb on Ubuntu 20.04 in Virtual Machine

                      Readsb on Ubuntu20.04.png

                      Comment


                      • #12
                        well on first impression it still doesn't work (with the powered usb hub)
                        I will try with a raspberry pi to see if the cable or the receiver or my pc is the problem...

                        Comment


                        • #13
                          I have now installed readsb and fr24 on my raspberrypi and put the dvbt stick directly into the pi. sudo journalctl -u readsb | tail -n30 brings this:
                          Code:
                          Jšn 11 20:35:35 FR24pi systemd[1]: Started readsb ADS-B receiver.
                          Jšn 11 20:35:35 FR24pi readsb[448]: Mon Jan 11 20:35:35 2021 GMT readsb startin g up.
                          Jšn 11 20:35:35 FR24pi readsb[448]: readsb version: wiedehopf git: 065a8c3 (fix stats json for phase prephase stuff, Mon Jan 11 19:49:45 2021 0100)
                          Jšn 11 20:35:35 FR24pi readsb[448]: struct sizes: 1600, 24, 64, 108
                          Jšn 11 20:35:35 FR24pi readsb[448]: rtlsdr: using device #0: Generic RTL2832U OE M (Realtek, RTL2838UHIDIR, SN 00000001)
                          Jšn 11 20:35:36 FR24pi readsb[448]: Found Rafael Micro R820T tuner
                          Jšn 11 20:35:36 FR24pi readsb[448]: rtlsdr: enabling tuner AGC
                          Jšn 11 20:35:36 FR24pi readsb[448]: Raw TCP output: Listening on port 30002
                          Jšn 11 20:35:36 FR24pi readsb[448]: Beast TCP output: Listening on port 30005
                          Jšn 11 20:35:36 FR24pi readsb[448]: SBS TCP output: Listening on port 30003
                          Jšn 11 20:35:36 FR24pi readsb[448]: Beast TCP input: Listening on port 30004
                          Jšn 11 20:35:36 FR24pi readsb[448]: Beast TCP input: Listening on port 30104
                          Jšn 11 20:35:36 FR24pi readsb[448]: startup complete after 1.187 seconds.
                          Jšn 11 20:35:36 FR24pi readsb[448]: Allocating 16 zero-copy buffers
                          Jšn 11 20:41:15 FR24pi readsb[448]: thread 1: removeStale interval too long: 310 .9 seconds
                          Jšn 11 20:41:15 FR24pi readsb[448]: thread 2: removeStale interval too long: 310 .9 seconds
                          Jšn 11 20:41:15 FR24pi readsb[448]: thread 3: removeStale interval too long: 310 .9 seconds
                          Jšn 11 20:41:15 FR24pi readsb[448]: thread 0: removeStale interval too long: 310 .9 seconds
                          Jšn 11 20:41:15 FR24pi readsb[448]: removeStale delayed by 309.9 seconds
                          What does this mean?

                          Edit: it works now directly plugged into the pi... So I guess my extension is the cause of my problems... I ordered a new cable and will try again when it arrives.

                          I just had an idea: Can I use the pi to decode the signal and send it to my server, wherer fr24 would run?
                          Last edited by fhoertnagl; 2021-01-11, 22:03.

                          Comment


                          • #14
                            Yes.

                            Specify the source feed type as beast-tcp
                            Point to Pi IP addr. And port 30005


                            Beast TCP output: Listening on port 30005

                            But a little overkill. When you can load most Pis up with all the feed SW at same time with little resource eating.
                            Posts not to be taken as official support representation - Just a helpful uploader who tinkers

                            Comment


                            • #15
                              Originally posted by fhoertnagl View Post
                              Jšn 11 20:41:15 FR24pi readsb[448]: thread 3: removeStale interval too long: 310 .9 seconds
                              Jšn 11 20:41:15 FR24pi readsb[448]: thread 0: removeStale interval too long: 310 .9 seconds
                              Jšn 11 20:41:15 FR24pi readsb[448]: removeStale delayed by 309.9 seconds[/CODE]

                              What does this mean?

                              Edit: it works now directly plugged into the pi... So I guess my extension is the cause of my problems... I ordered a new cable and will try again when it arrives.

                              I just had an idea: Can I use the pi to decode the signal and send it to my server, wherer fr24 would run?

                              My guess would be the clock was automatically adjusted and that confused the readsb code a bit.
                              You could check the log later ... if the message appears again then there's something up otherwise it's working.

                              FR24 binaries for amd64 aren't getting updated.
                              I'd highly recommend running the fr24feed on the pi.

                              But yes you can transfer the data to the server or a VM and do whatever with the data.

                              On the VM or server install readsb and follow these instructions:
                              https://github.com/wiedehopf/adsb-sc...-a-data-source

                              Instead of the sed you can edit /etc/default/readsb by hand .. try and understand the configuration changes
                              (RECEIVER_OPTIONS="--net-only --net-connector 192.168.2.7,20005,beast_in")
                              Instead of using an rtl-sdr it's now network only mode and connecting to that IP ... (which you want to be the pi ... beast data is by default available on port 30005 so change that as well as the IP)

                              If it's a pi 2/3/4 you can run all kinds of stuff on the pi ... no need to put the data on the server.
                              Anyhow ... see the above option, if you have the data replicated to the server you can access localhost 30005 there for the beast data.

                              Comment

                              Working...
                              X