Announcement

Collapse
No announcement yet.

AJAX call failed - Dump1090 not running - Feeders still active and feeding

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

  • AJAX call failed - Dump1090 not running - Feeders still active and feeding

    This has just started happening.

    All the settings appear to be correct and unchanged. The feeders still appear to be feeding data and online and current.

    I can pull up other feeder pages on my network successfully.

    http://192.168.x.x:30053/map.html


    pi@raspberrypi:~ $ sudo systemctl status dump1090-mutability -l
    ● dump1090-mutability.service - LSB: dump1090 daemon (mutability variant)
    Loaded: loaded (/etc/init.d/dump1090-mutability; generated; vendor preset: enabled)
    Active: active (exited) since Sun 2020-04-26 13:55:05 CDT; 23s ago
    Docs: man:systemd-sysv-generator(8)
    Process: 5393 ExecStop=/etc/init.d/dump1090-mutability stop (code=exited, status=0/SUCCESS)
    Process: 5405 ExecStart=/etc/init.d/dump1090-mutability start (code=exited, status=0/SUCCESS)

    sudo reboot and manually restarting dump1090-mut several times by command “sudo systemctl restart dump1090-mutability”, but it did not help.

    What could be wrong?

  • #2
    I did not intend on double posting. This was done in error.

    Comment


    • #3
      Configured as dvb-t, then FR24 will start its own dump1090 instance.
      Only one dump1090 instance can use the SDR.

      Comment


      • #4
        Originally posted by wiedehopf View Post
        Configured as dvb-t, then FR24 will start its own dump1090 instance.
        Only one dump1090 instance can use the SDR.
        I'm not understanding.

        This has been working fine for around a year now.

        I can no longer load the http://192.168.86.49/dump1090/gmap.html as I always have.

        Now, when I load that page, a box appears at the bottom of the page:

        Problem fetching data from dump1090.
        AJAX call failed (error: Not Found). Maybe dump1090 is no longer running?
        The displayed map data will be out of date

        That's never happened before. I've never tried to run multiple instances of dump1090.

        Comment


        • #5
          Maybe the SDR is broken, test it.

          https://github.com/wiedehopf/adsb-wi...l-sdr-receiver

          Comment


          • #6
            Originally posted by wiedehopf View Post
            Thanks for the reply.

            This is the output I received:

            sudo bash -c "$(wget -nv -O - https://raw.githubusercontent.c om/wiedehopf/adsb-scripts/master/rtl_test.sh)"
            2020-04-28 08:30:41 URL:https://raw.githubusercontent.com/wi...f/adsb-scripts /master/rtl_test.sh [2136/2136] -> "-" [1]
            456 /usr/bin/dump1090-fa --device-index 0 --gain -10 --ppm 0 --max-range 360 --f ix --net --net-heartbeat 60 --net-ro-size 1300 --net-ro-interval 0.2 --net-ri-po rt 0 --net-ro-port 30002 --net-sbs-port 30003 --net-bi-port 30004,30104 --net-bo -port 30005 --json-location-accuracy 1 --lat 38.71912 --lon -90.10626 --write-js on /run/dump1090-fa --quiet
            -----
            Lost samples in the first 2 seconds after starting the test are common and not a problem!
            Starting 30 second rtl_test, standby!
            -----
            Found 1 device(s):
            0: Realtek, RTL2832U, SN: 00001000

            Using device 0: Generic RTL2832U
            Found Rafael Micro R820T tuner
            Supported gain values (29): 0.0 0.9 1.4 2.7 3.7 7.7 8.7 12.5 14.4 15.7 16.6 19.7 20.7 22.9 25.4 28.0 29.7 32.8 33.8 36.4 37.2 38.6 40.2 42.1 43.4 43.9 44.5 48.0 49.6
            [R82XX] PLL not locked!
            Sampling at 2400000 S/s.

            Info: This tool will continuously read from the device, and report if
            samples get lost. If you observe no further output, everything is fine.

            Reading samples in async mode...
            Signal caught, exiting!

            User cancel, exiting...
            Samples per million lost (minimum): 0
            -------
            Test finished!
            More than 2 lost samples per million or other errors probably mean the receiver isn't working correctly.
            Try another power supply before condemning the receiver though!
            -------
            -------
            No undervoltage detected, looking fine!
            If the dongle is not directly plugged into the Raspberry Pi, lack of power/voltage could still be an issue.
            Even without detected undervoltage a better power supply can often improve reception!
            For optimum performance i would recommend the Official Raspberry Pi power supply.

            I let the test run, I did not exit.

            This is the blue FlightAware stick and I'm using an official Raspberry Pi power supply that is brand new.

            Comment


            • #7
              I don't find debugging these issues productive, i'd just recommend not using dump1090-mutability started by FR24 or not.
              It's annoying to debug.

              I'd recommend just using dump1090-fa
              https://github.com/wiedehopf/adsb-sc...or-dump1090-fa
              https://github.com/wiedehopf/adsb-sc...for-dump1090fa

              or readsb plus tar1090
              https://github.com/wiedehopf/adsb-sc...ion-for-readsb
              https://github.com/wiedehopf/tar1090#tar1090

              Comment


              • #8
                What is output of following command?

                apt-cache policy dump1090-mutability

                Comment


                • #9
                  Originally posted by abcd567 View Post
                  What is output of following command?

                  apt policy dump1090-mutability
                  See below:


                  pi@raspberrypi:~ $ lsb_release -sc
                  stretch
                  pi@raspberrypi:~ $ apt policy dump1090-mutability
                  dump1090-mutability:
                  Installed: 1.15~dev
                  Candidate: 1.15~dev
                  Version table:
                  *** 1.15~dev 100
                  100 /var/lib/dpkg/status
                  pi@raspberrypi:~ $

                  Comment


                  • #10
                    (1) Dump1090-mutability 1.15 is installed, but not working.

                    (2) All feeders are feeding data, so some version of dump1090 is running. It may either be dump1090-mutability ver 1.14 (installed by fr24feed during automatic upgrade) OR dump1090-fa which got installed (without you knowing it) during automatic upgrading of piaware.

                    To determine which version of dump1090 is active, please post output of following commands:

                    Command #1
                    Code:
                     apt-cache policy dump1090-fa

                    Command #2
                    (for privacy reasons, in the post, replace fr24key's actual value by xxxx)
                    Code:
                     cat /etc/fr24feed.ini

                    Comment


                    • #11
                      Originally posted by abcd567 View Post
                      (1) Dump1090-mutability 1.15 is installed, but not working.

                      (2) All feeders are feeding data, so some version of dump1090 is running. It may either be dump1090-mutability ver 1.14 (installed by fr24feed during automatic upgrade) OR dump1090-fa which got installed (without you knowing it) during automatic upgrading of piaware.

                      To determine which version of dump1090 is active, please post output of following commands:

                      Command #1
                      Code:
                       apt-cache policy dump1090-fa

                      Command #2
                      (for privacy reasons, in the post, replace fr24key's actual value by xxxx)
                      Code:
                       cat /etc/fr24feed.ini

                      apt-cache policy dump1090-fa
                      dump1090-fa:
                      Installed: 3.8.1~bpo9+1
                      Candidate: 3.8.1~bpo9+1
                      Version table:
                      *** 3.8.1~bpo9+1 500
                      500 http://flightaware.com/adsb/piaware/files/packages stretch/piaware armhf Packages
                      100 /var/lib/dpkg/status

                      cat /etc/fr24feed.ini
                      receiver="avr-tcp"
                      fr24key="xxxxx"
                      host="127.0.0.1:30002"
                      bs="no"
                      raw="no"
                      logmode="0"
                      logpath="/var/log/fr24feed"
                      mlat="yes"
                      mlat-without-gps="yes"

                      Please find my output above. Based on your reply and the output of the commands you provided, I think the answer must be the version of dump1090 that is running right now is dump1090-fa.

                      I would have to guess this is because of an automatic upgrade or something because this setup has been running for a long time. It looks like the base is stretch which is older.

                      Since this seems to be the case, I tested and now http://192.168.86.49/dump1090-fa/ works instead of http://192.168.86.49/dump1090/gmap.html which really isn't an issue unless there some other reason to disturb things further.

                      Comment


                      • #12
                        Nope. Pick one and roll with it. But you may need to check their startup capabilities as both may be and prior to your reboot probably started -mutability first (or stopped fa at some point and it couldnt restart)
                        And adjust so one is on-demand only

                        sudo systemctl --type=service | grep 1090

                        sudo systemctl disable <oneyoudontwant>

                        And try adjusting to beast-tcp (port:30005)
                        instead of avr-tcp 30002
                        Posts not to be taken as official support representation - Just a helpful uploader who tinkers

                        Comment


                        • #13
                          If you just want to fix your setup, run this script: https://github.com/wiedehopf/adsb-sc...or-dump1090-fa

                          It will remove the other dump1090 variations and configure FR24 correctly.

                          Comment

                          Working...
                          X