When is STRETCH coming to PiAware SD card image version

[abcd567]

Flightradar24 feeder on Raspbian Stretch. Repeated Following 2 Tests Several Times, Same Results Every Time:

Test-1

With setting
receiver = “avr-tcp”
host = “127.0.0.1:30002”

pi@raspberrypi:~ $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
...........
...........
pi@raspberrypi:~ $ sudo /etc/init.d/fr24feed restart
[ ok ] Restarting fr24feed (via systemctl): fr24feed.service.

pi@raspberrypi:~ $ cat /var/log/fr24feed.log
2017-10-26 10:58:13 | [main][i]FR24 Feeder/Decoder
2017-10-26 10:58:13 | [main][i]Version: 1.0.18-9/generic
2017-10-26 10:58:13 | [main][i]Built on Apr 20 2017 09:25:30 (T201704200925/Linux/static_arm)
2017-10-26 10:58:13 | [main][i]Copyright 2012-2017 Flightradar24 AB
2017-10-26 10:58:13 | [main][i]http://flightradar24.com
2017-10-26 10:58:13 | [main][i]DNS mode: PING
2017-10-26 10:58:13 | [main][i]Automatic updates are DISABLED
2017-10-26 10:58:13 | [httpd][i]Server started, listening on 0.0.0.0:8754
..................
..................
.................
2017-10-26 10:58:49 | [reader][i]Connecting to DVBT-TCP-BEAST-RAW receiver via (tcp://localhost:30005)
2017-10-26 10:58:49 | [reader][e]Could not connect to tcp://localhost:30005
2017-10-26 10:58:54 | [reader][i]Connecting to DVBT-TCP-BEAST-RAW receiver via (tcp://localhost:30005)
2017-10-26 10:58:54 | [reader][e]Could not connect to tcp://localhost:30005
2017-10-26 10:58:59 | [reader][i]Connecting to DVBT-TCP-BEAST-RAW receiver via (tcp://localhost:30005)
2017-10-26 10:58:59 | [reader][e]Could not connect to tcp://localhost:30005
2017-10-26 10:59:04 | [reader][i]Connecting to DVBT-TCP-BEAST-RAW receiver via (tcp://localhost:30005)
2017-10-26 10:59:04 | [reader][e]Could not connect to tcp://localhost:30005
2017-10-26 10:59:09 | [reader][i]Connecting to DVBT-TCP-BEAST-RAW receiver via (tcp://localhost:30005)
2017-10-26 10:59:09 | [reader][e]Could not connect to tcp://localhost:30005

.

Test-2:

With setting
receiver=“beast-tcp”
host=“127.0.0.1:30005”

pi@raspberrypi:~ $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
...........
...........
pi@raspberrypi:~ $ sudo /etc/init.d/fr24feed restart
[ ok ] Restarting fr24feed (via systemctl): fr24feed.service.

pi@raspberrypi:~ $ cat /var/log/fr24feed.log
2017-10-26 11:18:11 | [main][i]FR24 Feeder/Decoder
2017-10-26 11:18:11 | [main][i]Version: 1.0.18-9/generic
2017-10-26 11:18:11 | [main][i]Built on Apr 20 2017 09:25:30 (T201704200925/Linux/static_arm)
2017-10-26 11:18:11 | [main][i]Copyright 2012-2017 Flightradar24 AB
2017-10-26 11:18:11 | [main][i]http://flightradar24.com
2017-10-26 11:18:11 | [main][i]DNS mode: PING
2017-10-26 11:18:11 | [main][i]Automatic updates are DISABLED
2017-10-26 11:18:11 | [httpd][i]Server started, listening on 0.0.0.0:8754
2017-10-26 11:18:11 | [main][i]Reader thread started
2017-10-26 11:18:11 | [master][i]Starting processing thread
2017-10-26 11:18:11 | [main][i]MLAT data feed started
2017-10-26 11:18:11 | [reader][i]Initializing reader
[COLOR="#00AA00"]2017-10-26 11:18:11 | [reader][i]Connecting to unknown receiver via (tcp://127.0.0.1:30005)
2017-10-26 11:18:11 | [reader][i]Connected to the receiver, configuring[/COLOR]
.................
.................
2017-10-26 11:18:42 | [mlat][i]Configuring UDP connection udp://usa-2.fr24.com:19788
2017-10-26 11:18:47 | [feed][i]sent 25,0 AC
2017-10-26 11:18:52 | [feed][i]sent 25,0 AC
2017-10-26 11:18:53 | [mlat][i]Registering MLAT station
2017-10-26 11:18:53 | [mlat][i]Registering MLAT station: SUCCESS
2017-10-26 11:18:55 | [mlat][i]Received ADS-B time references AC:
2017-10-26 11:18:55 | [mlat][i] A8E165
2017-10-26 11:18:55 | [mlat][i]Pinging the server
2017-10-26 11:18:55 | [mlat][i]Stats 19317436/19317436
2017-10-26 11:18:57 | [feed][i]sent 24,0 AC
2017-10-26 11:19:02 | [feed][i]sent 25,0 AC

.

STATUS AFTER ABOVE TWO TESTS:

.

[astrodeveloper]

I decided to dig into using Stretch and then installing ADSB-receiver on two microSD cards. One using Dump1090-mutability and the other with Dump1090-fa. The results were interesting. I looked at the percentage of messages processed by each system vs the number reported to FlightAware in the piaware.log files. Dump1090-fa was always slightly higher in report percentages over several time intervals. Dump1090-mutability was good, but had a few less percent of the messages sent to FlightAware.

I ran into the same problems as the above messages and by taking notes as I slogged through the installs and reboots was able to get both systems to play nicely.

My vote goes to Dump1090-fa as it consistently seemed to process messages more reliably and with a lower cpu loading.

This work was done in mid December. Flu and hospital time stopped the in depth analysis further. Just thought people might be interested in the results.