SOLVED. UAT-only receiver not aquiring data

SoNic67 · January 5, 2021, 11:29am

I have installed on a dedicated Pi3 the piaware and dump978.
Setup with piaware-config:

pi@pi3:~ $ sudo piaware-config
allow-auto-updates yes # value set at /etc/piaware.conf:7
allow-manual-updates yes # value set at /etc/piaware.conf:8
receiver-type none # value set at /etc/piaware.conf:10
uat-receiver-type sdr # value set at /etc/piaware.conf:9

Well, I get no traffic from the SDR receiver. The antenna signal is splitted to a UAT flight-feeder and that one sees planes.
The flightaware website for that site has three green “flags”.
Any ideas?

LE: I have marked this thread as “Solved” because my issue was solved.

SoNic67 · January 4, 2021, 4:34pm

It seems that dump1090-fa is active… don’t know why.

pi@pi3:~ $ piaware-status
PiAware master process (piaware) is running with pid 542.
PiAware ADS-B client (faup1090) is not running.
PiAware ADS-B UAT client (faup978) is not running (disabled by configuration settings)
PiAware mlat client (fa-mlat-client) is not running.
Local ADS-B receiver (dump1090-fa) is running with pid 541.

dump1090-fa (pid 541) is listening for ES connections on port 30005.
faup1090 is NOT connected to the ADS-B receiver.
piaware is connected to FlightAware.

dump1090 is producing data on localhost:30005.

abcd567 · January 4, 2021, 4:44pm

Give command
sudo systemctl restart piaware

OR better
sudo reboot

Then check status.

SoNic67 · January 4, 2021, 4:45pm

It’s still running the dump1090-fa!

pi@pi3:~ sudo systemctl restart piaware pi@pi3:~ piaware-status
PiAware master process (piaware) is running with pid 1105.
PiAware ADS-B client (faup1090) is not running.
PiAware ADS-B UAT client (faup978) is not running (disabled by configuration settings)
PiAware mlat client (fa-mlat-client) is not running.
Local ADS-B receiver (dump1090-fa) is running with pid 801.

dump1090-fa (pid 801) is listening for ES connections on port 30005.
faup1090 is NOT connected to the ADS-B receiver.
piaware is connected to FlightAware.

dump1090 is producing data on localhost:30005.

wiedehopf · January 4, 2021, 4:48pm

piaware won’t control that unless it’s the piaware sd-card.

Disable the service or uninstall dump1090-fa.

SoNic67 · January 4, 2021, 4:52pm

I though that dump1090-fa is needed to “translate” the dump978-fa and bring in the lighttpd? On flightaware page is not clear.

Anyway, the dump978-fa is still disabled:

pi@pi3:~ $ piaware-status
PiAware master process (piaware) is running with pid 1424.
PiAware ADS-B client (faup1090) is not running.
PiAware ADS-B UAT client (faup978) is not running (disabled by configuration settings)
PiAware mlat client (fa-mlat-client) is not running.
Local ADS-B receiver (dump1090) is not running.

no program appears to be listening for ES connections on port 30005.
faup1090 is NOT connected to the ADS-B receiver.
piaware is connected to FlightAware.

got ‘couldn’t open socket: connection refused’
dump1090 is NOT producing data on localhost:30005.

abcd567 · January 4, 2021, 4:55pm

sudo systemctl enable dump978-fa  

sudo systemctl disable dump1090-fa  

sudo reboot

turbodogfl · January 4, 2021, 4:57pm

This seemed to temporarily fix a UAT-978 pi that was receiving 1090 instead of 978 but ended up reimaging it
sudo systemctl stop dump1090-fa
sudo systemctl restart dump978-fa

the presence of dump1090-fa running seemed to block dump978-fa from working

SoNic67 · January 4, 2021, 4:59pm

PiAware ADS-B UAT client (faup978) is not running (disabled by configuration settings)

Where are those “configuration settings”?

abcd567 · January 4, 2021, 5:04pm

stop and restart commands are temporary, and piaware will attempt and restart it. Further, it will be lost with reboot.

Use disable and enable followed by reboot. This will survive piaware’s attempt to restart, and survive subsequent reboots

turbodogfl · January 4, 2021, 5:07pm

piaware-config should list where the settings came from

turbodogfl · January 4, 2021, 5:08pm

stop and restart might be useful for troubleshooting without rebooting

SoNic67 · January 4, 2021, 5:21pm

I have unistalled dump1090-fa, rebooted and the piaware-status shows the same.
However, on the skyaware webpage now I see the UAT plane.

turbodogfl · January 4, 2021, 5:37pm

piaware-status from working uat receiver:
PiAware master process (piaware) is running with pid 20467.
PiAware ADS-B client (faup1090) is not running (disabled by configuration settings)
PiAware ADS-B UAT client (faup978) is running with pid 20508.
PiAware mlat client (fa-mlat-client) is not running.
Local ADS-B UAT receiver (dump978-fa) is running with pid 1663.

dump978-fa (pid 1663) is listening for UAT connections on port 30978.
faup978 is connected to the ADS-B UAT receiver.
piaware is connected to FlightAware.

dump978 is producing data on localhost:30978.

SoNic67 · January 4, 2021, 5:42pm

Somehow it started working here too:

pi@pi3:~ $ sudo piaware-status
PiAware master process (piaware) is running with pid 1424.
PiAware ADS-B client (faup1090) is not running (disabled by configuration settings)
PiAware ADS-B UAT client (faup978) is running with pid 1468.
PiAware mlat client (fa-mlat-client) is not running.
Local ADS-B UAT receiver (dump978-fa) is running with pid 1459.

dump978-fa (pid 1459) is listening for UAT connections on port 30978.
faup978 is connected to the ADS-B UAT receiver.
piaware is connected to FlightAware.

dump978 is producing data on localhost:30978.

jefforulez · January 4, 2021, 6:12pm

was there an an auto-update overnight? i started getting dump978-fa errors at 6:00 am ET.

restarting brings things back temporarily, but then dump978-fa starts failing again.

i didn’t make any changes leading up to the system failing.

obj · January 4, 2021, 6:20pm

No.

May be hardware failure then, power supplies are the usual culprit for gradual failures.

jefforulez · January 4, 2021, 7:00pm

huh. all the components are brand new. i just set them up ~48 hours ago and generally have clean power here.

i’ll keep debugging.

turbodogfl · January 4, 2021, 11:06pm

dmesg might list a power supply issue

obj · January 5, 2021, 3:42am

Well, wait, if it’s a brand new system then you don’t really have enough data to say that it was working “before”, because there wasn’t much “before”.