When is STRETCH coming to PiAware SD card image version


Hi I have an SD-card install of the latest PiAware 3.5 (upgraded to 3.5.1 with apt-get etc. etc.) which is based on old Debian Jessie. I tried to upgrade to Raspbian Stretch on the system but now it doesn’t boot… so don’t try this at home kids :slight_smile: I suspect the kernel upgrade didn’t go well given PiAware seems to have a custom setup for this.

Is there an ETA for a STRETCH-based PiAware SD card image?

Otherwise has anyone successfully upgraded their PiAware to stretch and has instructions?

Otherwise I will do a new Raspian Stretch Lite image and install Piaware over the top … however I like the custom things PiAware image install has like the config TXT file on the /boot drive for setting the gain easily etc.


I’ve upgraded my Raspberry to Debian Stretch without encountering any issues. The upgrade instructions from Debian worked fine.


No ETA but I do plan to look at it for the next version to see how much work it would be, at least.


Yes that’s the instructions I followed too, without success. All went fine until the reboot step. Maybe I will try again given you’ve had success.

I’ve had no problems with the Jessie image whatsoever so there’s no rush really.


I upgraded from Raspbian Jessie to Raspbian Stretch and there were no problems during installation or during normal operation.

However I did not upgrade by upgrade command from my stats page, or by “sudo apt-get dist-upgrade” or by “sudo apt-get upgrade”. Instead, I formatted microSD card and wrote Raspian Stretch Lite image. After booting, I installed Piaware 3.5.1 and dump1090-fa by package install.

While the microSD card was still in the card reader and plugged into Desktop, I very easily enabled SSH and configured WiFi as per instructions here:
Bake a Pi - Option-2, item 5(a) and (b)


Exactly what abcd567 said. No problems at all.

Didn’t get OpenVPN running but that is a different story. :wink:


Yes, but trying to install following leads to problem.:

  • dump1090-mutability v1.15~dev.
  • Flightradar24 feeder by bash script or JProchazka’s scripts.
  • Radarbox24 feeder by bash script.

I tried these on another microSD card after formatting & writing Raspbian Stretch image, and could succeed only after carrying out separate workarounds for each of these.


I run these feeders as well. Were the workarounds difficult? Or I might just wait a few weeks until it all get ironed out :wink:


All three workarounds are easy. I have posted all 3 in different threads. I will post these again here for your convinience:

(1) dump1090-mutability fails to open DVB-T.

Map does not show planws, and give following warning:

Reason: missing rtl-sdr.rules.

Workaround (AFTER installation of dump1090-mutability v1.15~dev):

sudo wget -O  /etc/udev/rules.d/rtl-sdr.rules "https://raw.githubusercontent.com/osmocom/rtl-sdr/master/rtl-sdr.rules"

sudo reboot


(2) FlightRadar24’s fr24feed fails to install by bash script.

Reason missing package “dirmngr”.


sudo apt-get update
sudo apt-get install dirmngr

sudo bash -c "$(wget -O - http://repo.feed.flightradar24.com/install_fr24_rpi.sh)"
#Enter details when prompted.


(3) RadarBox24’s rbfeeder fails to install by bash script

sudo bash -c "$(wget -O - http://apt.rb24.com/inst_rbfeeder.sh)"
W: GPG error: [url]http://apt.rb24.com[/url] jessie Release: The following signatures were invalid: A7E7D5E3786CA2212A3A5F4769D62C99357DF51A
W: The repository 'http://apt.rb24.com jessie Release' is not signed.
WARNING: The following packages cannot be authenticated!
Failed to start rbfeeder.service: Unit rbfeeder.service not found.


sudo apt-get update
sudo apt-get install rbfeeder

Ignore following warning during install and say y

WARNING: The following packages cannot be authenticated!
Install these packages without verification? [y/N]

Mutability... Still relevant?
Swapped my RPi3 for a pi0W and destroyed my range! [SOLVED]
Dump-1090 Mutability
Feeding data to FR24 using dump1090-fa
Webserver on Beaglebone Black Ted Sluis dump1090-mutability - no data on map

Thanks, started feeding to Radarbox24 (in addition to FlightAware, Flightradar24, Plane Finder and ADS-B Exchange) :slight_smile:


You can see my feed status here:

In above URL if you replace 000008 by your station number, you will see your feed status.


This seems to be the most appropriate thread for me to ask about my problems getting FlightReader24 to use my PiAware system.

When I upgraded my Raspbian ‘wheezy’ system (apt-get dist-upgrade), my system would no longer boot (!). So I opted to start over again with Debian ‘stretch’. My PiAware configuration seems to be working OK, but not my FlightReader24 addon. The log keeps repeating errors with port 30005:

2017-10-25 12:53:29 | [feed][n]ping 1047
2017-10-25 12:53:29 | [reader][i]Connecting to DVBT-TCP-BEAST-RAW receiver via (tcp://localhost:30005)
2017-10-25 12:53:29 | [reader][e]Could not connect to tcp://localhost:30005
2017-10-25 12:53:30 | [feed][n]syncing stream result: 1
2017-10-25 12:53:34 | [reader][i]Connecting to DVBT-TCP-BEAST-RAW receiver via (tcp://localhost:30005)
2017-10-25 12:53:34 | [reader][e]Could not connect to tcp://localhost:30005
2017-10-25 12:53:39 | [reader][i]Connecting to DVBT-TCP-BEAST-RAW receiver via (tcp://localhost:30005)
2017-10-25 12:53:39 | [reader][e]Could not connect to tcp://localhost:30005

This is what my FlightReader24 config looks like:


Can anyone point me in the right direction? Thanks!



Delete following entry from your file /etc/fr24feed.ini


Save the file /etc/fr24feed.ini, and then reboot
sudo reboot,

Few minutes After reboot, check log file
cat /var/log/fr24feed.log



You have set /etc/fr24feed.ini file to receiver="avr-tcp" and host="". Then why it tries to connect to DVBT-TCP-BEAST-RAW receiver via (tcp://localhost:30005)?

When I compare my and your files /etc/fr24feed.ini, I found in your file thereis an extra entry, which I have made bold above.

Here is output from my Installation

pi@raspberrypi:~ $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
pi@raspberrypi:~ $ cat /etc/fr24feed.ini

To simulate your situation, I added entry path="/usr/bin/dump1090-fa" in my file /etc/fr24feed.ini
and then rebooted sudo reboot

After reboot, checked file /var/log/fr24feed.log, and got exactly your problem:

I then deleted the entry path="/usr/bin/dump1090-fa", saved fr24feed.ini file and then rebooted sudo reboot.
After reboot, checked /var/log/fr24feed.log. The problem is gone, and output became normal as shown below:




Further investigation after my last post. I found the bug (I think so).

This problem occurs when the fr24feed is restarted by commands like sudo service fr24feed restart or sudo systemctl restart fr24feed,
This problem goes away when Pi is rebooted,

fr24feed is stopped by some internal process due to very low traffic during night, then restarted when traffic picks up. Because of this, the problem appears again. It goes away if Pi is rebooted, to appear again when system again restarts it in next24 hours.

I have further found that this bug is related only to following setting


When I changed the settings to following, then restarting manually by sudo systemctl restart fr24feed worked well and fr24feed worked ok. However I have still to observe over few days to see what happens when the system shuts down the fr24feed due to very low traffic in night and then restarts when traffic picks up,



abcd567: Thanks for your careful investigation of this problem! Your first response made sense, but strangely I found my server was already running fine with the most recent changes to ‘/etc/fr24feed.ini’ (similar to what you had mentioned). I was happy – but puzzled. I then made a small change and restarted ‘fr24feed’ – only to find that it was broken again!

I then took more careful note of your suggestion to ‘reboot’ (rather than restart the daemons as I had been doing), and it worked fine again. I came back here to mention this to you, but noticed your 2nd response confirming the same thing :slight_smile:

Yes, I agree with you that some sort of bug is present! Are we the first ones to discover this? Did this not occur in Debian Wheezy or Jessie? If it did, I cannot imagine that no one noticed it before. Hmmm…


It occurs only in Stretch, which is proving itself a pain in meck with so many feeder decoder software.

Yes, it has been reported recently at least by one more user. Immediately after posting here, I have posted contents of my last post there also (about an hour ago).


Did you change settings to


and then tried sudo systemctl restart fr4feed?

If not, please try it and after restart, check fr24feed log (cat /var/log/fr24feed.log) and post the outcome.


I was going to wait to see if your prediction re: failing during low activity would occur, but I have now modified my ini file:

…and restarted the feed this way:


sudo /etc/init.d/fr24feed restart

…and the log looks OK:

2017-10-25 17:10:20 | [main][i]FR24 Feeder/Decoder
2017-10-25 17:10:20 | [main][i]Version: 1.0.18-9/generic
2017-10-25 17:10:20 | [main][i]Built on Apr 20 2017 09:25:30 (T201704200925/Linux/static_arm)
2017-10-25 17:10:20 | [main][i]Copyright 2012-2017 Flightradar24 AB
2017-10-25 17:10:20 | [main][i]http://flightradar24.com
2017-10-25 17:10:20 | [main][i]DNS mode: PING
2017-10-25 17:10:20 | [main][i]Automatic updates are DISABLED
2017-10-25 17:10:20 | [httpd][i]Server started, listening on
2017-10-25 17:10:20 | [main][i]Reader thread started
2017-10-25 17:10:20 | [master][i]Starting processing thread
2017-10-25 17:10:20 | [main][i]MLAT data feed started
2017-10-25 17:10:20 | [reader][i]Initializing reader
2017-10-25 17:10:20 | [mlat][i]Waiting for MLAT configuration
2017-10-25 17:10:20 | [reader][i]Connecting to unknown receiver via (tcp://
2017-10-25 17:10:20 | [reader][i]Connected to the receiver, configuring
2017-10-25 17:10:20 | [reader][i]Configured, processing messages
2017-10-25 17:10:20 | [reader][w]Setting new UTC offset: 0!
2017-10-25 17:10:21 | [time][i]Synchronizing time via NTP
2017-10-25 17:10:38 | [time][i]Time synchronized correctly, offset +0.0014 seconds
2017-10-25 17:10:38 | [main][i]Feed Network client started
2017-10-25 17:10:38 | [feed][i]Downloading configuration
2017-10-25 17:10:39 | [feed][c]Interval: 5s
2017-10-25 17:10:39 | [feed][c]Latitude: 49.1830
2017-10-25 17:10:39 | [feed][c]Longitude: -98.1000
2017-10-25 17:10:39 | [feed][c]GND: YES
2017-10-25 17:10:39 | [feed][c]NonADSB: YES
2017-10-25 17:10:39 | [feed][c]Timestamps: optional
2017-10-25 17:10:39 | [feed][c]Max range AIR: 350.0nm
2017-10-25 17:10:39 | [feed][c]Max range GND: 100.0nm
2017-10-25 17:10:39 | [feed][i]defined 5 servers
2017-10-25 17:10:39 | [stats][i]Stats thread started
2017-10-25 17:10:39 | [feed][n]CYWG2@
2017-10-25 17:10:39 | [feed][n]connecting
2017-10-25 17:10:39 | [mlat][i]MLAT configuration received, service ENABLED
2017-10-25 17:10:39 | [mlat][i]Starting MLAT with preconfigured position: 49.18,-98.10, 0.0
2017-10-25 17:10:39 | [mlat][i]MLAT bandwidth reduction active, level 1
2017-10-25 17:10:39 | [mlat][i]Configuring UDP connection udp://usa-2.fr24.com:19788
2017-10-25 17:10:39 | [feed][n]connected via UDP (fd 10)
2017-10-25 17:10:39 | [feed][n]working
2017-10-25 17:10:39 | [feed][i]sent 1,0 AC
2017-10-25 17:10:44 | [feed][i]sent 12,0 AC
2017-10-25 17:10:49 | [mlat][i]Registering MLAT station
2017-10-25 17:10:49 | [mlat][i]Registering MLAT station: SUCCESS
2017-10-25 17:10:49 | [feed][i]sent 8,0 AC
2017-10-25 17:10:51 | [mlat][i]Received ADS-B time references AC:
2017-10-25 17:10:51 | [mlat][i] AA9CDB
2017-10-25 17:10:51 | [mlat][i] C022A8
2017-10-25 17:10:51 | [mlat][i] C040E8
2017-10-25 17:10:51 | [mlat][i] C0737C
2017-10-25 17:10:51 | [mlat][i]Pinging the server
2017-10-25 17:10:51 | [mlat][i]Stats 15775/15775

What is (perhaps) odd is that the stats page for my FlightRadar24 page is not (yet) showing any change in ‘Aircraft Seen/Positions Reported’. I did not take notice before I made this change, but I would have expected these numbers to change every time I refresh the page (?). EDIT: The numbers finally increased – I guess they are not ‘real time’ stats.

P.S. I guess we don’t need to specify ‘raw’ somewhere for the port 30005 stream?


Since you have now tested that with setting beast-tcp, 30005, restarting fr24feed does not create problem, you can again modify fr24feed.ini to avr-tcp, 30002 and watch overnight for few days.


The updating of data on feeder stats page is NOT instantaneous. Sometimes it lags by hours.


I think the software understands that beast is same as raw. It is not necessary to specify raw once beast is specified. Also in FR24 config page, setting ModeS Beast (TCP) and beast-tcp are mentioed for receiver. However for output data, they have mentioned Raw data 30002/30334

< IP of Pi >:8754/settings.html


As the stats page at https://www.flightradar24.com/account/data-sharing lags in updating, it is frustrating to use it to view affect of changes made in configuration.

A better method is to see the status locally on your desktop/laptop/phone’s browser by typing the sddress ip-of-pi:8754 which gives instantenoous status, and automatically updated every few minutes, or by refreshing the browser.

Note: After restart of fr24feed, it takes few minutes to update this page. During this period it will show Not configured, go to settings, not connected, and N/A for most items.

< IP of Pi >:8754