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

[glen4cindy]

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?

[glen4cindy]

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

[wiedehopf]

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

[glen4cindy]

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.

[wiedehopf]

Maybe the SDR is broken, test it.

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

[glen4cindy]

Maybe the SDR is broken, test it.

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

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.

[wiedehopf]

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

[abcd567]

What is output of following command?

apt-cache policy dump1090-mutability

[glen4cindy]

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:~ $

[abcd567]

(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

 apt-cache policy dump1090-fa

Command #2
(for privacy reasons, in the post, replace fr24key's actual value by xxxx)

 cat /etc/fr24feed.ini

[glen4cindy]

(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

 apt-cache policy dump1090-fa

Command #2
(for privacy reasons, in the post, replace fr24key's actual value by xxxx)

 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.

[Oblivian]

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

[wiedehopf]

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.