I have replaced everything, I’m thinking maybe an update broke the app.
runs for a few min then stops.
root@piaware:/var/run/piaware# piaware-status
PiAware master process (piaware) is running with pid 2327.
PiAware master process (piaware) is running with pid 2577.
PiAware ADS-B client (faup1090) is running with pid 2480.
PiAware ADS-B client (faup1090) is running with pid 2590.
PiAware mlat client (fa-mlat-client) is not running.
Local ADS-B receiver (dump1090-fa) is running with pid 2446.
dump1090-fa (pid 2446) is listening for connections on port 30005.
faup1090 is connected to the ADS-B receiver.
piaware is connected to FlightAware.
dump1090 is NOT producing data on localhost:30005.
06/25/2017 00:47:20 piaware (process 2151) is exiting…
06/25/2017 00:47:23 creating pidfile /run/piaware/piaware.pid
06/25/2017 00:47:23 ****************************************************
06/25/2017 00:47:23 piaware version 3.5.0 is running, process ID 2577
06/25/2017 00:47:23 your system info is: Linux piaware 4.1.19+ #858 Tue Mar 15 15:52:03 GMT 2016 armv6l GNU/Linux
06/25/2017 00:47:25 Connecting to FlightAware adept server at piaware.flightaware.com/1200
06/25/2017 00:47:25 Connection with adept server at piaware.flightaware.com/1200 established
06/25/2017 00:47:25 TLS handshake with adept server at piaware.flightaware.com/1200 completed
06/25/2017 00:47:25 FlightAware server certificate validated
06/25/2017 00:47:25 encrypted session established with FlightAware
06/25/2017 00:47:26 ADS-B data program ‘dump1090-fa’ is listening on port 30005, so far so good
06/25/2017 00:47:26 Starting faup1090: /usr/lib/piaware/helpers/faup1090 --net-bo-ipaddr localhost --net-bo-port 30005 --stdout
06/25/2017 00:47:26 Started faup1090 (pid 2590) to connect to dump1090-fa
06/25/2017 00:47:27 logged in to FlightAware as user JOEBLOW
06/25/2017 00:47:27 my feeder ID is 163646da-c0c8-4c50-b667-004f758b0487
06/25/2017 00:47:27 site statistics URL: flightaware.com/adsb/stats/user … tats-57402
06/25/2017 00:47:58 0 msgs recv’d from dump1090-fa; 0 msgs sent to FlightAware
06/25/2017 00:52:58 0 msgs recv’d from dump1090-fa (0 in last 5m); 0 msgs sent to FlightAware
06/25/2017 00:57:58 0 msgs recv’d from dump1090-fa (0 in last 5m); 0 msgs sent to FlightAware
06/25/2017 01:02:58 0 msgs recv’d from dump1090-fa (0 in last 5m); 0 msgs sent to FlightAware
06/25/2017 01:07:58 0 msgs recv’d from dump1090-fa (0 in last 5m); 0 msgs sent to FlightAware
06/25/2017 01:12:58 0 msgs recv’d from dump1090-fa (0 in last 5m); 0 msgs sent to FlightAware
06/25/2017 01:17:58 0 msgs recv’d from dump1090-fa (0 in last 5m); 0 msgs sent to FlightAware
06/25/2017 01:22:58 0 msgs recv’d from dump1090-fa (0 in last 5m); 0 msgs sent to FlightAware
I have the same issue as the thread topic, with increasing frequency.
$ piaware-status
PiAware master process (piaware) is running with pid 466.
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 912.
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 c294da24-....10ecc5cc1 (from /var/cache/piaware/feeder_id)
$ lsusb
Bus 001 Device 008: ID 0bda:2832 Realtek Semiconductor Corp. RTL2832U DVB-T
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
$ sudo systemctl status dump1090-fa -l
● dump1090-fa.service - dump1090 ADS-B receiver (FlightAware customization)
Loaded: loaded (/lib/systemd/system/dump1090-fa.service; enabled; vendor preset: enabled)
Active: activating (auto-restart) (Result: exit-code) since Fri 2020-02-07 09:34:06 EST; 23s ago
Docs: https://flightaware.com/adsb/piaware/
Process: 8694 ExecStart=/usr/share/dump1090-fa/start-dump1090-fa --write-json /run/dump1090-fa --quiet (code=exited, status=1/FAILURE)
Main PID: 8694 (code=exited, status=1/FAILURE)
Feb 07 09:34:06 raspberrypi systemd[1]: dump1090-fa.service: Unit entered failed state.
Feb 07 09:34:06 raspberrypi systemd[1]: dump1090-fa.service: Failed with result 'exit-code'.
The time between failures is becoming shorter. The temperature, when checked just now, after a reboot was 44-46. Shortly after reboot and checking temps, the dump1090 service stopped running again.
I’ve ordered a new power supply, just in case that is the issue.
What does the output above tell? What are possible solutions?
At this point, a reboot does NOT bring back dump1090! Immediately after reboot, the logs show:
[2020-02-07 10:05 EST] no ADS-B data program is serving on port 30005, not starting multilateration client yet
[2020-02-07 10:06 EST] no ADS-B data program seen listening on port 30005 for 183 seconds, next check in 60s
These message are repeated every 30 seconds or so:
Feb 07 10:15:09 raspberrypi systemd[1]: dump1090-fa.service: Service hold-off time over, scheduling restart.
Feb 07 10:15:09 raspberrypi systemd[1]: Stopped dump1090 ADS-B receiver (FlightAware customization).
Feb 07 10:15:09 raspberrypi systemd[1]: Started dump1090 ADS-B receiver (FlightAware customization).
Feb 07 10:15:09 raspberrypi dump1090-fa[2884]: Fri Feb 7 10:15:09 2020 EST dump1090-fa 3.8.0~bpo9+1 starting up.
Feb 07 10:15:09 raspberrypi systemd[1]: dump1090-fa.service: Main process exited, code=exited, status=1/FAILURE
Feb 07 10:15:09 raspberrypi systemd[1]: dump1090-fa.service: Unit entered failed state.
Feb 07 10:15:09 raspberrypi systemd[1]: dump1090-fa.service: Failed with result 'exit-code'.
Thank you wiedehopf for your help and suggestions.
I think this issue began a few weeks ago, after I ran an extra apt-get command (found in a topic - I forget which). My conclusion was a corrupted system. And, maybe too many incorrect shutdown/restart cycles.
I made a decision to clean up! This included downloading and installing a new Buster img on the SD card. This pi runs headless, so I added 2 files to the /boot directory - ssh (empty) and wpa_supplicant.conf (wi-fi config). After booting up and connecting via SSH, I was able to install piaware and dump1090 and follow abcd567’s instructions on how to restore a feeder-id
The pi & piaware/dump1090 have been humming smoothly since then. Hooray!
CA by two letter code for your country e.g. GB for UK, US for USA, DE for Germany, FR for France, SE for Sweden, CH for Switzerland, NL for Netherland, AU for Australia, NZ for New Zealand, etc etc. (click here for complete list)
I am having problems with a Pi0w and Flightaware Pros stick +. When I connect my Nooelec, I get data. When I switch to the stick, nothing. I use the proper power supply that came with the pi0 kit. Here are the dumps of piaware-status:
Nooelec:
PiAware master process (piaware) is running with pid 401.
PiAware ADS-B client (faup1090) is running with pid 482.
PiAware ADS-B UAT client (faup978) is not running (disabled by configuration settings)
PiAware mlat client (fa-mlat-client) is running with pid 525.
Local ADS-B receiver (dump1090-fa) is running with pid 399.
dump1090-fa (pid 399) is listening for ES connections on port 30005.
faup1090 is connected to the ADS-B receiver.
piaware is connected to FlightAware.
dump1090 is producing data on localhost:30005.
Your feeder ID is … (from /var/cache/piaware/feeder_id)
Flightaware:
PiAware master process (piaware) is running with pid 412.
PiAware ADS-B client (faup1090) is running with pid 488.
PiAware ADS-B UAT client (faup978) is not running (disabled by configuration settings)
PiAware mlat client (fa-mlat-client) is running with pid 498.
Local ADS-B receiver (dump1090-fa) is running with pid 410.
dump1090-fa (pid 410) is listening for ES connections on port 30005.
faup1090 is connected to the ADS-B receiver.
piaware is connected to FlightAware.
dump1090 is NOT producing data on localhost:30005.
Your feeder ID is … (from /var/cache/piaware/feeder_id)
What are you running for antenna (and any adapters), given that the 2 dongles are likely different connectors.
MCX for the Nooelect, SMA for FA.
Many new folks have tried to use “SMA-RP” adapters rather than SMA adapters - which are missing the centre pin.
Several helpful threads on the forum on that issue.
Saying something offhand like that can send someone down an expensive and wrong path. Do you have a reference for this claim? It contradicts FlightAware’s own info which states the Pi Zero W can be used.
I have the proper adapters which I purchased with the kit, MCX to SMA for Nooelec and strictly SMA for the stick.
In Foreflight, the stick shows it is connected to Foreflight and running, ready to send data (which it does not). Power off, swap for the Nooelec, it does all of it. Power off, swap the stick back in, same behaviour.
Latest version of 3.8.0 of piware.
The reason I have both a stick and a Nooelec is becasue I built a Stratux kit for my aircraft (with the Nooelec) and figured I would build a Flightaware box for home.
With the extra OTG cable, the extra resistance can easily lead to a voltage drop that creates an issue.
On the other hand maybe you swapped USB ports when changing the SDRs? @bernardgervais
(i’m not completely familiar with the pi zero, but … one port is for power input the other one for the OTG device?)
I suppose it could also be that the ProStick+ is bad?
Checking for undervoltage can’t hurt just in case:
sudo dmesg --ctime | grep voltage
(wouldn’t necessarily reveal a resistance issue with the OTG cable)
I suppose you could check the FA prostick+ on another computer, but doing this on Windows is really annoying.
The swap I make is at the receiving end of the the OTG connector. This is my second stick, I had the same problem with a first one and retuned it to Amazon. The problem is most likely on my end. I tried another power supply (USB from my iPad’s charging block) - same issue.
Anything I need to write to the SD card that is particular to the FA stick? Port, etc. I have limited knowledge of SSH and terminal stuff.
sudo dmesg --ctime | grep voltage just returns to the prompt.
Well you do it on the RPi console
If you did, that means there is at least no obvious under-voltage condition.
If you have another OTG adapter, you could try one.
The resistance in the adapter could well be the issue.
The Nooelec uses less power so it’s less of an issue.
If you have a powered USB hub, hang that on the OTG and connect the ProStick+ to the powered hub.
That would eliminate a power issue.
To the Pi the rtl-sdr compatible SDRs (which both of your sticks are) look pretty much the same.
No need to change anything.