I have been experimenting with UAT (978 MHz) the last few days, and I seem to be receiving enough data I would like to try to get the data into PlanePlotter, but so far I haven’t been able to figure out how to do so. I know this isn’t a PlanePlotter forum, but I also don’t want to do anything that messes up the piaware stuff, so I thought some of the experts here might have an idea to try.
I am running dump1090-fa, dump978-fa, and piaware on a Rasberry Pi (along with the totally awesome tar1090). I currently get data into PlanePlotter simply by connecting to port 30005 on the Pi, which is served as a beast output by dump1090-fa.
I am aware of the mutability/dump978 repo on GitHub and I built that and I have used uat2esnt to generate messages that look like this…I believe this is “raw” input format.
I tried piping this to port 30001 (socat and nc), assuming dump1090-fa would receive it (since I have --net-ri-port 30001 configured) and then forward the data to PlanePlotter, but it doesn’t seem to work. Maybe this is disabled in the -fa version? I am not clear on whether dump1090-fa ever received anything or if the data just isn’t forwarded like I was hoping.
Nonetheless, since piaware is already concatenating the two streams for uploading to FlightAware, I suspect I don’t really want the data flowing into dump1090-fa at all and would rather have a way of getting the UAT stream into PlanePlotter directly along with the 1090ES data. Is there any way to do this? Do I need to figure out ppup1090 or run a separate dump1090 that pulls from both -fa sources?
So with some more futzing around, I have successfully pushed the stream from uat2esnt into port 30001 on dump1090-fa and I can now see the traffic in PlanePlotter, so my theory is correct.
My big question now, is whether that will cause any problems for piaware since it is now likely receiving two UAT streams (one directly, one via dump1090-fa port 30005).
Yes, it causes hassle; please don’t feed the output of uat2esnt back to piaware, if you can run a separate instance of dump1090 on different ports just for translation / planeplotter feeding that is better.
(the “right” solution is to encourage planeplotter to take a UAT data feed directly, but I wouldn’t hold my breath…)
Extracted from FOLLOWING FILE (Lines 23 to 143 of original file): https://github.com/abcd567a/two-receivers/blob/master/2-receivers-dump-fa.sh
In line 104 (NET-OPTIONS2):
(1) Added --net-only for use without a dongle, and feed from other source like uat2esnt.
(2) Ports are alredy set set as follows to avoid conflict with 1st instance: --net-ri-port 0 --net-ro-port 31002 --net-sbs-port 31003 --net-bi-port 31004,31104 --net-bo-port 31005
Changed --net-ri-port 0 to --net-ri-port 31001
#!/bin/bash
read -rsp $'Press any key to start creation of files for 2nd instance...\n' -n1 key
echo -e "\e[33m(1) Creating dump1090-fa2 service file......\e[39m"
SERVICE_FILE_dump=/lib/systemd/system/dump1090-fa2.service
sudo touch $SERVICE_FILE_dump
sudo chmod 666 $SERVICE_FILE_dump
sudo cat <<\EOT > $SERVICE_FILE_dump
# dump1090-fa2 service for systemd
[Unit]
Description=dump1090 ADS-B receiver (FlightAware customization)
Documentation=https://flightaware.com/adsb/piaware/
Wants=network.target
After=network.target
[Service]
User=dump1090
RuntimeDirectory=dump1090-fa2
RuntimeDirectoryMode=0755
ExecStart=/bin/bash /usr/share/dump1090-fa/start-dump1090-fa2 --write-json %t/dump1090-fa2 --quiet
SyslogIdentifier=dump1090-fa2
Type=simple
Restart=on-failure
RestartSec=30
RestartPreventExitStatus=64
Nice=-5
[Install]
WantedBy=default.target
EOT
sudo chmod 644 $SERVICE_FILE_dump
echo ""
echo -e "\e[33m(2) Creating dump1090-fa2 startup file......\e[39m"
STARTUP_FILE_dump=/usr/share/dump1090-fa/start-dump1090-fa2
sudo touch $STARTUP_FILE_dump
sudo chmod 766 $STARTUP_FILE_dump
sudo cat <<\EOT > $STARTUP_FILE_dump
#!/bin/sh
# Helper script that reads /etc/default/dump1090-fa2
# and either starts dump1090-fa2 with the configured
# arguments, or exits with status 64 to tell systemd
# not to auto-restart the service.
if [ -f /etc/default/dump1090-fa2 ]
then
. /etc/default/dump1090-fa2
fi
if [ -f /var/cache/piaware2/location.env ]
then
. /var/cache/piaware2/location.env
fi
if [ "x$ENABLED" != "xyes" ]
then
echo "dump1090-fa2 not enabled in /etc/default/dump1090-fa2" >&2
exit 64
fi
if [ -n "$PIAWARE_LAT" -a -n "$PIAWARE_LON" ]
then
POSITION="--lat $PIAWARE_LAT --lon $PIAWARE_LON"
fi
exec /usr/bin/dump1090-fa \
$RECEIVER_OPTIONS2 $DECODER_OPTIONS2 $NET_OPTIONS2 $JSON_OPTIONS2 $POSITION \
"$@"
# exec failed, do not restart
exit 64
EOT
sudo chmod 755 $STARTUP_FILE_dump
echo -e "\e[33mENABLING AUTO STARTUP....\e[39m"
sudo systemctl enable dump1090-fa2
echo ""
echo -e "\e[33m(3) Creating dump1090-fa2 Config file......\e[39m"
CONFIG_FILE_dump=/etc/default/dump1090-fa2
sudo touch $CONFIG_FILE_dump
sudo chmod 666 $CONFIG_FILE_dump
sudo cat <<\EOT > $CONFIG_FILE_dump
# dump1090-fa2 configuration
# This is sourced by /usr/share/dump1090-fa/start-dump1090-fa2 as a
# shellscript fragment.
# If you are using a PiAware sdcard image, this config file is regenerated
# on boot based on the contents of piaware-config.txt; any changes made to this
# file will be lost.
# dump1090-fa2 won't automatically start unless ENABLED=yes
ENABLED=yes
RECEIVER_OPTIONS2="--device-index 00000102 --gain -10 --ppm 0 --net-bo-port 31005"
DECODER_OPTIONS2="--max-range 360"
NET_OPTIONS2="--net --net-only --net-heartbeat 60 --net-ro-size 1000 --net-ro-interval 1 --net-ri-port 31001 --net-ro-port 31002 --net-sbs-port 31003 --net-bi-port 31004,31104 --net-bo-port 31005"
JSON_OPTIONS2="--json-location-accuracy 1"
EOT
sudo chmod 644 $CONFIG_FILE_dump
echo ""
echo -e "\e[33m(4) Creating lighttpd Config file......\e[39m"
CONFIG_FILE_lighttpd=/etc/lighttpd/conf-available/89-dump1090-fa2.conf
sudo touch $CONFIG_FILE_lighttpd
sudo chmod 666 $CONFIG_FILE_lighttpd
sudo cat <<\EOT > $CONFIG_FILE_lighttpd
# Allows access to the static files that provide the dump1090 map view,
# and also to the dynamically-generated json parts that contain aircraft
# data and are periodically written by the dump1090 daemon.
alias.url += (
"/dump1090-fa2/data/" => "/run/dump1090-fa2/",
"/dump1090-fa2/" => "/usr/share/dump1090-fa/html/"
)
# redirect the slash-less URL
url.redirect += (
"^/dump1090-fa2$" => "/dump1090-fa2/"
)
# Listen on port 8181 and serve the map there, too.
$SERVER["socket"] == ":8181" {
alias.url += (
"/data/" => "/run/dump1090-fa2/",
"/" => "/usr/share/dump1090-fa/html/"
)
}
# Add CORS header
$HTTP["url"] =~ "^/dump1090-fa2/data/.*\.json$" {
setenv.add-response-header = ( "Access-Control-Allow-Origin" => "*" )
}
EOT
sudo chmod 644 $CONFIG_FILE_lighttpd
sudo lighty-enable-mod dump1090-fa2
sudo service lighttpd force-reload
echo ""
I created two services to get the data into dump1090-fa2.
One gets the Beast output data from dump1090-fa and connects to the Beast input port on the -fa2 instance.
The other gets the raw UAT data, pushes it through uat2esnt, then transmits it to the raw input port on the -fa2. All seems to be working well.
Another (untested) option is to use ModeSMixer2 to combine ADS-B and UAT data from dump1090-fa and dump978-fa, then feed this combined data to Planeplotter:
(1) Install ModeSMixer2 on RPi (mm2/README.md at master · abcd567a/mm2 · GitHub)
(2) Configure ModeSMixer2 to receive beast data from dump1090-fa (127.0.0.1:30005) AND raw data from dump978-fa (127.0.0.1:30978)
(3) Configure ModeSMixer2 to output combined data in beast format at port 31005.
(4) Configure Planeplotter to receive beast data from ModeSmixer2 at 127.0.0.1:31005
Just now finished the combiner-1090-978 (based on ModeSMixer2), but cannot test right now as I am away from RPi. Will test tonight when back home.
The combiner is configured to Serve combined feed in Beast format at port 32005. It takes input from dump1090-fa (beast 30005) and from dump978 (raw 30978).
Bash script which installs and configures ModeSMixer2 as combiner:
