FlightAware Discussions

dump1090 is NOT producing data on localhost:30005

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

Post output of these 2 commands



lsusb
sudo systemctl status dump1090-fa -l


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?

Thank you for reading this.

David

Status is usually cuts the log short, use this:

sudo journalctl --no-pager -u dump1090-fa

The official power supply is always a good idea.

USB extensions are also often an issue.

Did you install FR24 by chance?

Sometimes it’s just the rtl-sdr device going bad.

No.

What is the rtl-sdr device?

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

What is the issue here?

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'.

This is fishy:

dump1090-fa 3.8.0~bpo9+1 starting up

Is there a way to uninstall and re-install?

DVB-T stick / dongle / rtl-sdr compatible receiver / SDR (software defined radio)

A pity that it doesn’t show any errors.

sudo apt purge dump1090-fa
sudo apt install dump1090-fa

You might want to run the undervoltage and receiver tests:
https://github.com/wiedehopf/adsb-wiki/wiki/Debug-commands#test-the-rtl-sdr-receiver

Alternatively let’s just see if it shows any errors on the console:

sudo systemctl stop piaware dump1090-fa
dump1090-fa

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!

:+1: :+1: :+1:

For information of others:
contents of file /boot/wpa_supplicant.conf

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1

country=CA

network={
    ssid="YOUR_SSID"
    psk="YOUR_PASSWORD"
}

NOTE:

Replace:

  1. 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)

  2. YOUR_SSID by your router’s wifi ssid

  3. YOUR_PASSWORD by your router’s wifi password.

It is recommended that the country matches to the country where the device is installed

Edited my post and added Note

1 Like

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)


Any help?

Not really made for the power requirements the ProStick+ has.

You can try a different OTG cable with less resistance.

Kits by some seller on the internet, doesn’t necessarily mean that it’s a good power supply.

Really only the official RPI power supplies are of known quality.

Pi0W is mentioned ok on the Flightaware site… And I’ve seen videos and threads about it on the net.

I am using the a Cana Kit “2.5Amp Power Supply for Raspberry PI”.

Again, my Nooelec works fine.

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.

It’s almost always a power issue …

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.

(I’m on a MAC.)

Well you do it on the RPi console :wink:
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.