FlightAware Discussions

cdemi · October 22, 2018, 8:45pm

Hi all,

I have setup my first piaware

Everything looks to be working fine, but I am noticing that after some time, I no longer get new messages from dump1090-fa

Logs from piaware:

Oct 22 18:25:34 raspberrypi piaware[496]: 676 msgs recv'd from dump1090-fa (0 in last 5m); 654 msgs sent to FlightAware
Oct 22 18:30:34 raspberrypi piaware[496]: 676 msgs recv'd from dump1090-fa (0 in last 5m); 654 msgs sent to FlightAware
Oct 22 18:35:34 raspberrypi piaware[496]: 676 msgs recv'd from dump1090-fa (0 in last 5m); 654 msgs sent to FlightAware
Oct 22 18:36:19 raspberrypi piaware[496]: mlat-client(684): Receiver status: connected
Oct 22 18:36:19 raspberrypi piaware[496]: mlat-client(684): Server status:   not synchronized with any nearby receivers
Oct 22 18:36:19 raspberrypi piaware[496]: mlat-client(684): Receiver:    0.0 msg/s received        0.0 msg/s processed (0%)
Oct 22 18:36:19 raspberrypi piaware[496]: mlat-client(684): Server:      0.0 kB/s from server    0.0kB/s TCP to server     0.0kB/s UDP to server
Oct 22 18:36:19 raspberrypi piaware[496]: mlat-client(684): Aircraft: 0 of 0 Mode S, 0 of 0 ADS-B used
Oct 22 18:40:34 raspberrypi piaware[496]: 676 msgs recv'd from dump1090-fa (0 in last 5m); 654 msgs sent to FlightAware
Oct 22 18:45:34 raspberrypi piaware[496]: 676 msgs recv'd from dump1090-fa (0 in last 5m); 654 msgs sent to FlightAware

If I reboot the raspberry pi, everything boots up correctly and I can get data again.

In addition to this, I am also running fr24feed, which is hooked to dump1090-fa on beast-tcp on 127.0.0.1:30005.

During that time, even fr24feed cannot receive data from dump1090-fa

2018-10-22 20:35:36 | [reader][w]Global timeout exceeded, 0 msgs, 0 resyncs, reconnecting
2018-10-22 20:35:36 | [reader][i]Connection terminated
2018-10-22 20:35:37 | [mlat][i]No ADS-B time reference available (0/0)
2018-10-22 20:35:37 | [mlat][i]Pinging the server
2018-10-22 20:35:37 | [mlat][i]Stats 4810/0
2018-10-22 20:35:41 | [reader][i]Connecting to unknown receiver via (tcp://127.0.0.1:30005)
2018-10-22 20:35:41 | [reader][i]Connected to the receiver, configuring
2018-10-22 20:35:41 | [reader][i]Configured, processing messages
2018-10-22 20:35:43 | [feed][n]ping 102
2018-10-22 20:35:44 | [feed][n]syncing stream result: 1
2018-10-22 20:35:48 | [mlat][i]No ADS-B time reference available (0/0)
2018-10-22 20:35:57 | [mlat][i]No ADS-B time reference available (0/0)
2018-10-22 20:35:57 | [mlat][i]Pinging the server
2018-10-22 20:35:57 | [mlat][i]Stats 4810/0
2018-10-22 20:36:07 | [mlat][i]No ADS-B time reference available (0/0)
2018-10-22 20:36:13 | [feed][n]ping 103
2018-10-22 20:36:14 | [feed][n]syncing stream result: 1
2018-10-22 20:36:17 | [mlat][i]No ADS-B time reference available (0/0)
2018-10-22 20:36:17 | [mlat][i]Pinging the server
2018-10-22 20:36:17 | [mlat][i]Stats 4810/0
2018-10-22 20:36:28 | [mlat][i]No ADS-B time reference available (0/0)
2018-10-22 20:36:37 | [mlat][i]No ADS-B time reference available (0/0)
2018-10-22 20:36:37 | [mlat][i]Pinging the server
2018-10-22 20:36:37 | [mlat][i]Stats 4810/0
2018-10-22 20:36:43 | [feed][n]ping 104
2018-10-22 20:36:44 | [feed][n]syncing stream result: 1
2018-10-22 20:36:47 | [mlat][i]No ADS-B time reference available (0/0)

I can see that the process is still running and listening on those ports. I can even telnet to it and it accepts my connection.

How can I figure out what’s causing this?

abcd567 · October 22, 2018, 9:00pm

@cdemi

Test if your dongle is available for use by dump1090-fa

#First install test tool package 
sudo apt-get update
sudo apt-get install rtl-sdr

#STOP dump1090-fa before test 
sudo systemctl stop dump1090-fa

#Now conduct test
rtl_test -t

.

If dongle is available, the above test should give following output:

Found 1 device(s):
  0:  Realtek, RTL2832U, SN: 00000000

Using device 0: Generic RTL2832U
Found Rafael Micro R820T tuner
Supported gain values (29): 0.0 0.9 1.4 2.7 3.7 7.7 8.7 12.5 14.4 15.7 16.6 19.7 20.7 22.9 25.4 28.0 29.7 32.8 33.8 36.4 37.2 38.6 40.2 42.1 43.4 43.9 44.5 48.0 49.6
[R82XX] PLL not locked!
Sampling at 2048000 S/s.
No E4000 tuner found, aborting.

.

What output do you get from `rtl_test -t` command?

cdemi · October 22, 2018, 9:00pm

Thanks I will test this on the next occurrence and revert back

wiedehopf · October 22, 2018, 9:12pm

Such intermittent issues are most often the dongle not getting enough power throught the pi.

The RPi power supply or the micro usb cable connecting it might be at fault.

You can check the dump1090-fa logs if you want.
journalctl -t dump1090-fa
or
journalctl -u dump1090-fa

check which command works

cdemi · October 22, 2018, 10:19pm

Hi all,

Thanks for all the help.

I am using an official RPi power supply & micro-sd cable.

When I run journalctl -t dump1090-fa I get:


Oct 22 22:09:21 raspberrypi dump1090-fa[502]: Mon Oct 22 22:09:21 2018 UTC  No data received from the SDR for a long time, it may have wedged
Oct 22 22:10:21 raspberrypi dump1090-fa[502]: Mon Oct 22 22:10:21 2018 UTC  No data received from the SDR for a long time, it may have wedged
Oct 22 22:11:21 raspberrypi dump1090-fa[502]: Mon Oct 22 22:11:21 2018 UTC  No data received from the SDR for a long time, it may have wedged
Oct 22 22:12:21 raspberrypi dump1090-fa[502]: Mon Oct 22 22:12:21 2018 UTC  No data received from the SDR for a long time, it may have wedged
Oct 22 22:13:22 raspberrypi dump1090-fa[502]: Mon Oct 22 22:13:22 2018 UTC  No data received from the SDR for a long time, it may have wedged

When I turn off dump1090-fa and run rtl_test -t I get:

pi@raspberrypi:~/adsb-exchange $ rtl_test -t
Found 1 device(s):
  0:  Realtek, RTL2832U, SN: 00001000

Using device 0: Generic RTL2832U
Found Rafael Micro R820T tuner
Supported gain values (29): 0.0 0.9 1.4 2.7 3.7 7.7 8.7 12.5 14.4 15.7 16.6 19.7 20.7 22.9 25.4 28.0 29.7 32.8 33.8 36.4 37.2 38.6 40.2 42.1 43.4 43.9 44.5 48.0 49.6
[R82XX] PLL not locked!
Sampling at 2048000 S/s.
No E4000 tuner found, aborting.

Another thing that I noticed is that when I try to turn off dump1090-fa with sudo systemctl stop dump1090-fa it never goes down gracefully. I have to kill -9 it

Strangely enough, when I turn on sudo systemctl start dump1090-fa again it starts working

abcd567 · October 22, 2018, 10:29pm

If the dongle is plugged to RPi through a USB extender cable,
- Remove the cable and plug the dongle directly into RPi.
  OR
- Try another USB cable.
Try another powersupply adapter

cdemi · October 22, 2018, 10:29pm

It’s plugged in directly. USB to USB

abcd567 · October 22, 2018, 10:30pm

Try another DC 5v power supply adaptor

cdemi · October 22, 2018, 10:30pm

Will do. I will report with my updates. Thanks!

wiedehopf · October 22, 2018, 10:33pm

It’s still the most likely reason.
Otherwise the dongle might be the reason. Which model is it?

How often did this happen?
Also try a different USB port on the RPi.

cdemi · October 22, 2018, 10:36pm

It’s the FlightAware Pro Stick Plus with the FlightAware ADS-B 1090MHz Band-pass SMA Filter.

I just setup this the first time a few hours ago and it has been happening about every 1 hour give or take.

I will try new power adapter tomorrow and see if it happens again.

Thanks for your help

wiedehopf · October 22, 2018, 10:44pm

If you want a bandaid that will automatically restart dump1090-fa you can try the following script:

#!/bin/bash
exec &>>/tmp/wedge                                                                                                                     
sleep 20

journalctl -b -0 -f -n0 | grep 'No data received from the SDR for a long time' --line-buffered | { 
        while read line
        do
                date
                systemctl kill -s 9 dump1090-fa
                sleep .3
                systemctl restart dump1090-fa
        done
}

First you open a new textfile with an editor, paste the above script, save and exit

nano /home/pi/wedge.sh
COPY/PASTE
CTRL-O
CTRL-X
sudo crontab -e

Add the following line

@reboot              /bin/bash /home/pi/wedge.sh

save and exit.

After the next reboot dump1090-fa will be automatically killed and restarted after wedging.

cdemi · October 22, 2018, 10:42pm

This is awesome! Thanks

wiedehopf · October 22, 2018, 10:45pm

Note that i just fixed the file name in the crontab entry. There was a bogus z in there

abcd567 · October 22, 2018, 10:52pm

The band-aid is only an interim measure. The permanent solution is to find and replace the defective component (power supply or dongle).

cdemi · October 22, 2018, 10:53pm

Agreed. Tomorrow I will try to get a new power supply and I will check

Dump1090-fa stops sending messages after some time

What output do you get from rtl_test -t command?

What output do you get from `rtl_test -t` command?