FlightAware Discussions

Piaware 5 installed (twice), no longer receiving messages

Hello,

I’ve had piaware running fine for quite a long time, but it has recently stopped picking up anything at all. Strangely, it tapered off before it cut out, as opposed to dropping all at once.

I originally did the update process, for packages on Raspbian, and then went and uninstalled, reinstalled the works. (Note, did not purge all config files).

Current log looks like this:

Mar 22 13:32:24 rpi3 piaware[975]: multilateration data requested
Mar 22 13:32:24 rpi3 piaware[975]: Starting multilateration client: /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 70.42.6.156:13495:1532163660
Mar 22 13:32:24 rpi3 piaware[975]: mlat-client(1747): fa-mlat-client 0.2.11 starting up
Mar 22 13:32:24 rpi3 piaware[975]: mlat-client(1747): Using UDP transport to 70.42.6.156 port 13495
Mar 22 13:32:24 rpi3 piaware[975]: mlat-client(1747): Listening for Beast-format results connection on port 30105
Mar 22 13:32:24 rpi3 piaware[975]: mlat-client(1747): Listening for Extended Basestation-format results connection on port 30106
Mar 22 13:32:24 rpi3 piaware[975]: mlat-client(1747): Route MTU changed to 1500
Mar 22 13:32:24 rpi3 piaware[975]: mlat-client(1747): Input connected to localhost:30005
Mar 22 13:32:24 rpi3 piaware[975]: mlat-client(1747): Input format changed to BEAST, 12MHz clock
Mar 22 13:32:25 rpi3 piaware[975]: mlat-client(1747): Beast-format results connection with ::1:30104: connection established
Mar 22 13:36:36 rpi3 piaware[975]: 0 msgs recv’d from dump1090-fa (0 in last 5m); 0 msgs sent to FlightAware
Mar 22 13:41:36 rpi3 piaware[975]: 0 msgs recv’d from dump1090-fa (0 in last 5m); 0 msgs sent to FlightAware

Any suggestions?

Attaching a screen shot of recent stats to illustrate. MLAT went away first.

First check your dongle

sudo apt-get install rtl-sdr 

sudo systemctl stop piaware dump1090-fa dump978-fa

rtl_test -t 

dump1090-fa 

If test shows your dongle is OK, and dump1090-fa is picking aircrafts (last command), then easiest way is to download and write latest image on a spare microSD card. You may use one of the two options:

(1) Raspberry Pi OS image + Package install of piaware, dump1090-fa and dump978-fa (if required)

(2) Piaware SD Card image which has piaware, dump1090-fa and dump978-fa pre-installed.

Thanks, looks like the dongle’s dodgy:

tim@rpi3:~ $ sudo rtl_test -t
Found 1 device(s):
0: Generic, RTL2832U, SN: 77771111153705700

Using device 0: Generic RTL2832U
rtlsdr_demod_write_reg failed with -9
rtlsdr_demod_read_reg failed with -9
rtlsdr_demod_write_reg failed with -9
rtlsdr_demod_read_reg failed with -9

(continues forever)

Shutdown Pi
Unplug and replug the dongle
If dongle is plugged using a USB cable, plug it directly or use another USB cable
Reboot Pi, then check again.

Thanks, mostly the same. Just that the error codes vary slightly:
Using device 0: Generic RTL2832U
rtlsdr_demod_write_reg failed with -7
rtlsdr_demod_read_reg failed with -7
rtlsdr_demod_write_reg failed with -9
rtlsdr_demod_read_reg failed with -9
rtlsdr_demod_write_reg failed with -7
rtlsdr_demod_read_reg failed with -7
rtlsdr_demod_write_reg failed with -9
rtlsdr_demod_read_reg failed with -9

I had had to unplug, replug the dongle a while back to resolve an outage, and had already done so earlier today to try that. Did it all again now just to see if it made a difference.

Looks like a corruption in the dongle eeprom.
That serial number doesn’t look right.

Good catch @LawrenceHill

Try to re-serialize the dongle (8-digit) and test again

sudo systemctl stop piaware dump1090-fa dump978-fa  

rtl_eeprom -s 00001090  

## Unplug and re-plug the dongle, then test again

rtl_test -t  

Trying just the first command, skipping a bunch at the start:

rtlsdr_demod_read_reg failed with -7
rtlsdr_demod_write_reg failed with -7
rtlsdr_demod_read_reg failed with -7
rtlsdr_demod_write_reg failed with -7
rtlsdr_demod_read_reg failed with -7
rtlsdr_demod_write_reg failed with -7
rtlsdr_demod_read_reg failed with -7
rtlsdr_read_reg failed with -7
rtlsdr_write_reg failed with -7
rtlsdr_read_reg failed with -7
rtlsdr_write_reg failed with -7
rtlsdr_read_reg failed with -7
rtlsdr_write_reg failed with -7
rtlsdr_read_reg failed with -7
rtlsdr_write_reg failed with -7
No supported tuner found
rtlsdr_demod_write_reg failed with -7
rtlsdr_demod_read_reg failed with -7
rtlsdr_demod_write_reg failed with -7
rtlsdr_demod_read_reg failed with -7
rtlsdr_demod_write_reg failed with -7
rtlsdr_demod_read_reg failed with -7
rtlsdr_demod_write_reg failed with -7
rtlsdr_demod_read_reg failed with -7
Enabled direct sampling mode, input 1
rtlsdr_demod_write_reg failed with -7
rtlsdr_demod_read_reg failed with -7
rtlsdr_demod_write_reg failed with -7
rtlsdr_demod_read_reg failed with -7
rtlsdr_demod_write_reg failed with -7
rtlsdr_demod_read_reg failed with -7
rtlsdr_demod_write_reg failed with -7
rtlsdr_demod_read_reg failed with -7

No EEPROM has been found.
rtlsdr_write_reg failed with -7

Order another dongle :sob:

Sounds like it, doesn’t it? Damn.
Well, thanks for the insights!

Though it is unlikely that low dc voltage will cause this problem, no harm in checking the voltage.

sudo dmesg --ctime | grep voltage

If there is no output, it means voltage is OK and your ac to dc adaptor is OK.

Yeah, that wasn’t complaining thanks. Have ordered another dongle.

What dongle do you have?

It’s the FlightAware pro plus, RTL-SDR with filter.

Ok, definitely looks like time for a new dongle then.

-7 is LIBUSB_ERROR_TIMEOUT (dongle did not respond to the control transfer in a reasonable time)
-9 is LIBUSB_ERROR_PIPE (dongle responded to a control transfer with an endpoint stall)

Both are definitely signs of hardware trouble.

1 Like

Thanks, have another on order.

Tim

obj via FlightAware Discussions flightaware@discoursemail.com writes: