PI24: Replace dump1090 v1.14 -> pre-build package of dump1090 v1.15

[IZ8292SWL]

Uhm.
I tried the procedure but my raspberry pi, after the reboot, had an issue with the wifi connection!
No wireless interface available!
I guess i have to reinstall the entire system now...

[IZ8292SWL]

@abcd567 Thank you!
I'll give it a try!

[abcd567]

Hi Guys!
I'm still using the 1.14 version of dump1090 installed automatically by the FR24 script.

Can i use the script:
sudo bash -c "$(wget -O - https://raw.githubusercontent.com/abcd567a/dump1090/master/PI24_replace_dump1090_v1.14_by_v1.15.sh)"

Even if i don't have the Pi24 OS version?

YES, you can, even if you dont have Pi24 OS, and have installed (fr24 feeder+dump1090 ver 1.14) by FR24 script.

[IZ8292SWL]

Hi Guys!
I'm still using the 1.14 version of dump1090 installed automatically by the FR24 script.
I used an API code from my google page to have full map features...
Can i use the script:

sudo bash -c "$(wget -O - https://raw.githubusercontent.com/abcd567a/dump1090/master/PI24_replace_dump1090_v1.14_by_v1.15.sh)"

Even if i don't have the Pi24 OS version?
I use http://raspberrypi.local/dump1090/gmap.html to show the map in my browser.
Cheers!

[msyounk]

Thanks for this guidance. It worked for me on RPi_4 running NOOBs shell with latest updates of OS as of 5 Aug 2019. Running FA USB stick.

[wiedehopf]

Hmm very curious.

--net should not be used with bs and raw i believe because they occupy the same ports.
but it's working now so it seems possible to run it like that.

abcd567:

this line

sudo service lighttpd force-reload

can fail to work if lighttpd is stopped for some reason as it won't start but only restart it.

systemctl restart lighttpd

this line on the other hand will always work and restart or start lighttpd as necessary.
Probably wasn't the issue in this case, i'm not sure what was.

Might also be a good idea to stop fr24feed before removing dump1090

The problem above sounds a bit like the run directory wasn't properly managed.
It's probably managed by fr24.

Oh well the reboot is included in the instructions.
Maybe print it on the screen as well at the end of the script.

[roofer]

The aircraft.json file was not updating.

pi@frrpi:~ $  cat /etc/fr24feed.ini
receiver="dvbt"
fr24key="something"
host="127.0.0.1:30002"
bs="yes"
raw="yes"
logmode="1"
procargs="--net"
windowmode="0"
logpath="/var/log/fr24feed"
mpx="no"
mlat="yes"
mlat-without-gps="yes"

pi@frrpi:~ $  cat /etc/os-release | grep -i pretty
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"

BUT .... A reboot fixed it. Not sure why or how. I am not used to rebooting my linux computers.
I am very happy, because the local map display has not been working for months.
My sincere thanks to you both.

[abcd567]

(1) Seems you did NOT reboot after the installation completed.
Reboot and then check the map.

(2) If rebooting does not fix the problem, then most likely the dump1090-mutability ver 1.15~dev did not get installed properly. You will have to fix it manually by following method:

2.1 - Purge existing broken install of dump1090-mutability ver 1.15 ~dev

sudo dpkg --purge dump1090-mutability
sudo rm -rf /usr/share/dump1090-mutability

2.2 - Reinstall ver 1.15

cd /usr/lib/fr24/

sudo ./install_dump1090.sh

sudo service lighttpd force-reload

sudo systemctl restart fr24feed

[wiedehopf]

Does refreshing the page display current planes or does the refreshed page still display old planes?

http://frpi/dump1090/data/aircraft.json

Does this file change when you refresh it when the map isn't working anymore?

Can you show your fr24feed.ini (remove key)

cat /etc/fr24feed.ini

Also let's check which Raspbian you are using:

cat /etc/os-release | grep -i pretty

If you don't mind some branding, you can also use dump1090-fa, installation is also done via install script.

https://github.com/wiedehopf/adsb-wiki#1-install-script-for-dump1090-fa

[roofer]

Thanks, but the dongle is fine, and I can see the raw ADSB data on port 30003 in real time, and this is being correctly fed to fr24.

But, I ran your script anyway:

Found 1 device(s):
  0:  Realtek, RTL2838UHIDIR, SN: 00000031

Using device 0: Generic RTL2832U OEM
Found Elonics E4000 tuner
Supported gain values (14): -1.0 1.5 4.0 6.5 9.0 11.5 14.0 16.5 19.0 21.5 24.0 29.0 34.0 42.0 
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.
-------

It is an original RPi PSU.

[wiedehopf]

Most likely an insufficient power supply.

dump1090-mutability 1.14 uses a lower sample rate, so the dongle is more likely to be affected by a not so good power supply.

Let's check the output of this:

sudo bash -c "$(wget -q -O - https://raw.githubusercontent.com/wiedehopf/adsb-wiki/master/rtl_test.sh)"

It checks the dongle for lost samples and for undervoltage.

[roofer]

Thank you for this!
I used your script (I was in a hurry!), and it seems to have done the trick, but although the OSM map is displayed, and there are planes displayed, they are not being updated, and after a few seconds a box displays

"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. "

The UTC clock shows the current time and is updating itself, the Last Update clock has the wrong time, and is not ticking.

Clearing the browser's cache has not helped.

I can see the raw data at http://frpi:30003/

pi@frrpi:~ $  fr24feed-status 
[ ok ] FR24 Feeder/Decoder Process: running.
[ ok ] FR24 Stats Timestamp: 2019-06-26 15:13:19.
[ ok ] FR24 Link: connected [UDP].
[ ok ] FR24 Radar: T-EGLC11.
[ ok ] FR24 Tracked AC: 51.
[ ok ] Receiver: connected (421391 MSGS/0 SYNC).
[ ok ] FR24 MLAT: ok [UDP].
[ ok ] FR24 MLAT AC seen: 48.
pi@frrpi:~ $  apt-cache 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@frrpi:~ $

Any suggestions?

[LN-MOW]

I overwrote the ‘old’ fr24image on my 2nd feed with your script and it worked like a charm. Changed to ‘beast tcp’ and it came right up.

Great job!

But I’m puzzled why FR24 themselves are so passive in this matter. You would have thought it was in their interest to have all this lined up when they shut down the windows feed ..


Sent from my iPad using Tapatalk Pro

[abcd567]

Skipper-Kolding:
ua459:
DarkBlue:

Thanks to all of you for your feedbacks.
Positive Feedbacks encourage.
Negetive feedbacks or posting issues helps to solve problem and improve.
No feedback is discouraging.

[DarkBlue]

Just worked perfect with my fresh install of the PI24 Image and your script.

Thank you sir!