My subject is a reference to the question I asked more than two years ago.
My Pro Stick (Orange) again appears to be dead, after working okay for more than two years. I think the cause of death was operating it in my attic, where, over the summer, the temperatures probably reached more than 120℉.
Here’s the output of my diagnostics:
pi@piaware:~ $ sudo piaware-status
PiAware master process (piaware) is running with pid 446.
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.
Your feeder ID is 85745c9f-cda6-4160-84aa-24b1a432d619 (configured at /boot/piaware-config.txt:84)
pi@piaware:~ $ systemctl status piaware >t
pi@piaware:~ $ cat t
● piaware.service - FlightAware ADS-B uploader
Loaded: loaded (/lib/systemd/system/piaware.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2022-10-11 09:17:33 EDT; 20min ago
Docs: https://flightaware.com/adsb/piaware/
Main PID: 446 (piaware)
CGroup: /system.slice/piaware.service
└─446 /usr/bin/piaware -p /run/piaware/piaware.pid -plainlog -statusfile /run/piaware/status.json
Oct 11 09:36:36 piaware sudo[3120]: pam_unix(sudo:session): session closed for user root
Oct 11 09:36:36 piaware piaware[446]: dump1090 start appears to have been successful
Oct 11 09:36:46 piaware sudo[3150]: piaware : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/bin/netstat --program --tcp --wide --all --numeric
Oct 11 09:36:47 piaware sudo[3150]: pam_unix(sudo:session): session opened for user root by (uid=0)
Oct 11 09:36:47 piaware sudo[3150]: pam_unix(sudo:session): session closed for user root
Oct 11 09:36:47 piaware piaware[446]: no ADS-B data program seen listening on port 30005 for 11 seconds, next check in 60s
Oct 11 09:37:22 piaware sudo[3230]: piaware : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/bin/netstat --program --tcp --wide --all --numeric
Oct 11 09:37:22 piaware sudo[3230]: pam_unix(sudo:session): session opened for user root by (uid=0)
Oct 11 09:37:23 piaware sudo[3230]: pam_unix(sudo:session): session closed for user root
Oct 11 09:37:23 piaware piaware[446]: no ADS-B data program is serving on port 30005, not starting multilateration client yet
pi@piaware:~ $
This is WITH a powered USB hub between the Pro Stick and the Pi Zero W.
I’ll probably just go ahead and buy a new Pro Stick, but I’d like to know if I should just throw out the Orange one, or keep it for some purpose.
Thanks for all your advice and suggestions.
-Kevin
1 Like
you could check if the USB stick is still detected, , try the command lsusb on the rpi command prompt.
If it isn’t showing a R820T tuner or something similar then you might have confirmation you flightstick is broken.
1 Like
Man, this is so frustrating!
I think I was able to solve this original problem by switching to a different powered USB hub. Whatever I did, my FlightAware system worked fine for more than 30 days. Then, two days ago, it failed.
When I rebooted and tested it today, it didn’t have a connection to the USB device. After powering the USB hub off then on, the connection was reestablished:
pi@piaware:~ $ lsusb
Bus 001 Device 003: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 001 Device 002: ID 2109:2812 VIA Labs, Inc. VL812 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
## Powered USB hub off and on here
pi@piaware:~ $ lsusb
Bus 001 Device 010: ID 0bda:2832 Realtek Semiconductor Corp. RTL2832U DVB-T
Bus 001 Device 009: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 001 Device 008: ID 2109:2812 VIA Labs, Inc. VL812 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
pi@piaware:~ $
This caused it to return to working status.
Is the problem in my USB hub? I noticed that my blue FlightAware USB stick was noticably warm to the touch, not hot, but warm. Is this a sign of problems?
Can anyone recomment the powered USB hub that they use, that seems to provide a long uninterruped service?
Thanks, again, for any advice or suggestions.
-Kevin
1 Like
I have the Flighwaware prostick connected without a power USB hub. It depends on your setup. I have Pi2/Pi3/Orange Pi 2E’s as systems. Due to the lack of connection possibilites I stayed away from Pi Zero’s.
1 Like
The receiver sticks/dongles (both names are accurate) will get warm. If you want, you can remove the plastic covers over the dongles to let more air cool the devices. On one out in my garage, I removed the cover, and drilled some cooling holes on the front and back covers to let air circulate. Mounting the pi and dongles vertically help keep them cooler too.
My Airspy dongles will get warmer and I use heat sinks on them. RF noise increases with higher temps, so keeping the hardware cooler helps the systems operate better and last longer. Have fun.
1 Like
I’d been experiencing this same issue with my Orange FA radio. FA replaced one, and it was less than 60 days before the replacement started acting buggy.
I had been having problems since September, and had just resigned myself to having to just do without 978 for now and would try to work it out later.
Then, about two weeks ago, out of the blue, an FA engineer emailed me (and I’m sure many others) curious why my 978 wasn’t sending data to FA.
I explained myself as clearly as possible, and after 2 days, some head scratching and swapping parts around, the engineer discovered that the USB/USB Micro jumper had failed, or was of such poor quality that it couldn’t do it’s job any longer.
Since you’re using a powered USB hub, you might try a USB cable you have confidence in.
Good luck!
@Jsbird69, thanks for your reply and the suggestion to use another USB micro cable.
My Raspberry Pi is powered by a dedicated Raspberry Pi-branded wall-plug power supply. It is then connected to the powered hub by the molded-in USB-A cable that is a part of the powered hub itself. I then use a short USB-A to USB-micro converter. The powered hub is powered by its own wall-outlet power supply. I will try replacing these cables to see if that makes a difference.
I still continue to experience outages intermittantly. I can run for 30 days or less than 36 hours before my system fails. Here are the diagnostic outputs from the lastest failure:
$ systemctl -l --no-pager status piaware
● piaware.service - FlightAware ADS-B uploader
Loaded: loaded (/lib/systemd/system/piaware.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2023-07-16 20:17:45 UTC; 3 days ago
Docs: https://flightaware.com/adsb/piaware/
Main PID: 379 (piaware)
Tasks: 3 (limit: 876)
CPU: 2h 3min 5.231s
CGroup: /system.slice/piaware.service
├─ 379 /usr/bin/piaware -p /run/piaware/piaware.pid -plainlog -statusfile /run/piaware/status.json
└─4997 /usr/lib/piaware/helpers/fa-mlat-client --input-connect localhost:30005 --input-type dump1090 --results beast,connect,localhost:30104 --results beast,listen,30105 --results ext_basestation,listen,30106 --udp-transport 2620:13d:c000:11::201:11831:2527735723
Jul 20 15:38:46 piaware piaware[379]: mlat-client(4997): Beast-format results connection with 127.0.0.1:30104: [Errno 111] Connection refused
Jul 20 15:39:16 piaware piaware[379]: mlat-client(4997): Connection to localhost:30005 lost: [Errno 111] Connection refused
Jul 20 15:39:16 piaware piaware[379]: mlat-client(4997): Reconnecting in 0.5 seconds
Jul 20 15:39:16 piaware piaware[379]: mlat-client(4997): Beast-format results connection with ::1:30104: [Errno 111] Connection refused
Jul 20 15:39:17 piaware piaware[379]: mlat-client(4997): Connection to localhost:30005 lost: [Errno 111] Connection refused
Jul 20 15:39:17 piaware piaware[379]: mlat-client(4997): Reconnecting in 30.0 seconds
Jul 20 15:39:20 piaware sudo[9483]: piaware : PWD=/ ; USER=root ; COMMAND=/bin/netstat --program --tcp --wide --all --numeric
Jul 20 15:39:20 piaware sudo[9483]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=999)
Jul 20 15:39:20 piaware sudo[9483]: pam_unix(sudo:session): session closed for user root
Jul 20 15:39:20 piaware piaware[379]: no ADS-B data program seen listening on port 30005 for 311 seconds, next check in 60s
$ sudo piaware-status
PiAware master process (piaware) is running with pid 379.
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 running with pid 4997.
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.
Your feeder ID is xxxxx (configured at /boot/piaware-config.txt:84)
$
Thanks, again, for your suggestion, and for any other advice or guidance from anyone else.
-Kevin
1 Like
The SDR’s are quite voltage sensitive. If you can get a USB voltmeter and plug it into an unused port on your hub, it will tell you what voltage the SDR is seeing.
2 Likes
