Poor performance using ethernet instead of Wifi

FlightAware ADS-B Flight Tracking
1

My hardware setup: Raspberry Pi2, RTL-SDR dongle (metal case), TP-Link wifi USB-module, ethernet connection over Devolo powerline adapters, standard whip antenna.
Software: ads-b script package from adsbreceiver.net, dump1090-mutability, MLAT active, feeding to FlightAware and Flightradar.

My setup was running without any problems on the Wifi connection (no ethernet cable connected), until some days ago. My Pi2 started crashing randomly. I suspected to much power drain with both the rtl-sdr and wifi module connected to the USB ports, so I decided to remove the Wifi module from the Pi2 and to connect the ethernet cable. My ethernet connection is running over 2 Devolo powerline adapters to my central internet router.

Since then I noticed that: the message rate went down by +/- 25%, the position reports went down by +/- 20%, the average and maximum range went down by +/- 20%.

I’m looking for an explanation for this performance degradation. I expected the opposite effect (worse reception with an active wifi connection). Do I have a grounding problem? Or do the powerline adapters provide to much RF disturbance?

Your help is appreciated.

2

Could be the powerline networking adapters. The power cables in the walls are unshielded and thus the signal can leak out - but at the same time, the frequency shouldn’t per se interfere with adsb

3

I would expect from the opposite too.
As Jon said, I would suspect the eop adapter.
They are horribly noisy.

Can you run a direct cable to test for a while?

Do the graphs indicate that the noise floor has increased?

If you have a decent power supply, try the adding usb_max_current=1 To /boot/config.txt
raspberrypi.org/forums/view … 9&t=100244

Normally, a sudden problem indicates that something broke or something has changed (The golden rule of fault finding)
Did you update any software just before the problem happened? Did you change any hardware? Any storms that could have caused power surges?

(edited to fix iphone submission issues, ie typos and not being able to see the original article while writing)

4

Ah, yes, I just noticed you’re running the setup-script package. Other Jon makes a good point: The signal-level chart should be a very helpful clue. If you look at the weekly charts and the noise floor spikes up after you’ve installed the powerline adapters, the noise from them is probably the culprit.

Remember, these things basically turn every copper wire in your house into a radiating element of a low-power antenna.

If the wifi module really was causing power-related reboots - another way around this would be to hook up the wifi adapter through a powered USB hub, or get a better power supply (at least 3a) for your pi.

5

Thanks all for the replies and the suggestions!

The crashing problems started after I modified the gain parameter from ‘max’ to ‘44.5’. This caused a huge improvement in the number of messages, position reports and a noticeable increase in the max range. My message rate went from +/- 200 to 400+. Then the random crashes started to happen. I suspected the USB ports to be overloaded and the RTL and Wifi dongle asking for to much current drain. A temporary replacement of the power adapter (iPad power adapter) made no difference.

I found similar issues and conclusions in this topic: ads-b-flight-tracking-f21/pi-keeps-crashing-t35564.html?hilit=dodgy%20connector

I decided to remove the Wifi dongle and to setup the ethernet connection using the power line adapters. The Pi seems stable in this configuration, but with a performance degradation as in the number of position reports and max range.

Today, I tried it again with the Wifi dongle and usb_max_current=1 in /boot/config.txt. It ran smoothly for some hours, but when the air traffic increased, the Pi crashed again. Now back on the ethernet connection with the same performance degradation. I don’t see any significant change in noise level in the signal level graph.

Summary / conclusions:

  1. Pi2 crashes when traffic increases on USB ports when RTLSDR and Wifi dongle are both in use. Probably caused by to much current drain on USB ports
  2. Ethernet power line adapters probably add RF disturbance, causing decrease in number of messages / position reports, and decrease in max range.

Regarding 1: Should try with powered USB hub. Need to buy this equipment.
Regarding 2: Should try with direct ethernet cable connection. Not easy to arrange, yet no ethernet cabling available in my attic.

6

Try a third power supply. If it’s crashing the whole Pi, it is almost certainly a power problem; the increased message rate might trigger it simply because the CPU is busier (= higher power draw) when there are more messages to handle. The dongle isn’t really doing any more work when there’s more messages.

7

Thanks for your reply!

Mostly it is the RTL-SDR that gets disconnected, the Pi2 is still accessible. I tried a manual restart of dump1090-mutability today, and that gets the message decoding system running again.

8

Still probably power problems. There are differing opinions as to whether powered hub (for Wifi and SDR dongles) or better RPI power supply is the best course of action, but either will probably solve your problem. One way you’re relieving the pi of its need to send power out over usb, the other way you’re improving it’s ability to send power out.

Also note, if you’re using a USB extension cable, that may also be the culprit. There have been a couple people who have had issues with the dongle disconnecting like that where the problem turned out to be a dodgy USB extension cable.

9

Ok, so:

  • what does dmesg output look like;
  • what does dump1090 log;
  • is dump1090 still running but hung at the point you manually restart it or is it entirely dead?

Hard to diagnose without specific information.

10

Third party wifi adapters can use from 100mA to 1A of power. There is a RPi wiki that has a list of known problems with Wifi dongles. Definitely check if your dongle is in this list.
elinux.org/RPi_USB_Wi-Fi_Adapters

The RPi 3 has a better voltage regulator. You should be able to easily run 2 dongles on the same system as well as use the wifi built into the RPi3 (wifi adds about 100mA of power usage).

11

I left my setup running unattended today. The RTL-SDR got disconnected during that time, but apparently it also started itself again. Please see the following logfile extracts:

lusb output:


pi@raspberrypi:~ $ lsusb
Bus 001 Device 005: ID 0bda:8178 Realtek Semiconductor Corp. RTL8192CU 802.11n WLAN Adapter
Bus 001 Device 004: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 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. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

/var/log/dump1090-mutability.log:


Statistics: Tue Mar 29 11:10:50 2016 CEST - Tue Mar 29 12:10:50 2016 CEST
Local receiver:
  8640004096 samples processed
  0 samples dropped
  0 Mode A/C messages received
  27833634 Mode-S message preambles received
    15343095 with bad message format or invalid CRC
    11238321 with unrecognized ICAO address
    1163915 accepted with correct CRC
    88303 accepted with 1-bit error repaired
  -31.4 dBFS noise floor
  -18.6 dBFS mean signal power
  -1.7 dBFS peak signal power
  769 messages with signal power above -3dBFS
Messages from network clients:
  0 Mode A/C messages received
  25299 Mode S messages received
    0 with bad message format or invalid CRC
    0 with unrecognized ICAO address
    25299 accepted with correct CRC
    0 accepted with 1-bit error repaired
1277517 total usable messages
5 surface position messages received
90295 airborne position messages received
83898 global CPR attempts with valid positions
0 global CPR attempts with bad data
  0 global CPR attempts that failed the range check
  0 global CPR attempts that failed the speed check
98 global CPR attempts with insufficient data
5570 local CPR attempts with valid positions
  5442 aircraft-relative positions
  128 receiver-relative positions
832 local CPR attempts that did not produce useful positions
  827 local CPR attempts that failed the range check
  0 local CPR attempts that failed the speed check
0 CPR messages that look like transponder failures filtered
456395 non-ES altitude messages from ES-equipped aircraft ignored
298 unique aircraft tracks
59 aircraft tracks where only one message was seen
0 HTTP requests
CPU load: 22.3%
  483853 ms for demodulation
  284742 ms for reading from USB
  32845 ms for network input and background tasks
cb transfer status: 1, canceling...
Tue Mar 29 12:40:08 2016 CEST  Warning: lost the connection to the RTLSDR device.
Tue Mar 29 12:40:13 2016 CEST  Trying to reconnect to the RTLSDR device..
Found 1 device(s):
0: Realtek, RTL2838UHIDIR, SN: 00000001 (currently selected)
rtlsdr_demod_read_reg failed with -1
rtlsdr_demod_write_reg failed with -1
rtlsdr_read_reg failed with -1
rtlsdr_write_reg failed with -1
No supported tuner found
rtlsdr_demod_write_reg failed with -1
rtlsdr_demod_read_reg failed with -1
.... (redudant lines deleted)
rtlsdr_demod_write_reg failed with -1
rtlsdr_demod_read_reg failed with -1
rtlsdr_write_reg failed with -1
rtlsdr_write_reg failed with -1
Gain reported by device: 0.00 dB
weirdness: rtlsdr gave us a block with an unusual size (got 0 bytes, expected 262144 bytes)
weirdness: rtlsdr gave us a block with an unusual size (got 0 bytes, expected 262144 bytes)
.... (redundant lines deleted)
weirdness: rtlsdr gave us a block with an unusual size (got 0 bytes, expected 262144 bytes)

Statistics: Tue Mar 29 12:10:50 2016 CEST - Tue Mar 29 13:10:50 2016 CEST
Local receiver:
  4218552320 samples processed
  0 samples dropped
  0 Mode A/C messages received
  13086245 Mode-S message preambles received
    7233926 with bad message format or invalid CRC
    5322143 with unrecognized ICAO address
    494318 accepted with correct CRC
    35858 accepted with 1-bit error repaired
  -32.1 dBFS noise floor
  -19.3 dBFS mean signal power
  -3.2 dBFS peak signal power
  0 messages with signal power above -3dBFS
Messages from network clients:
  0 Mode A/C messages received
  17823 Mode S messages received
    0 with bad message format or invalid CRC
    0 with unrecognized ICAO address
    17823 accepted with correct CRC
    0 accepted with 1-bit error repaired
547999 total usable messages
4 surface position messages received
39167 airborne position messages received
36523 global CPR attempts with valid positions
0 global CPR attempts with bad data
  0 global CPR attempts that failed the range check
  0 global CPR attempts that failed the speed check
45 global CPR attempts with insufficient data
2298 local CPR attempts with valid positions
  2216 aircraft-relative positions
  82 receiver-relative positions
350 local CPR attempts that did not produce useful positions
  344 local CPR attempts that failed the range check
  2 local CPR attempts that failed the speed check
0 CPR messages that look like transponder failures filtered
168112 non-ES altitude messages from ES-equipped aircraft ignored
157 unique aircraft tracks
31 aircraft tracks where only one message was seen
0 HTTP requests
CPU load: 10.8%
  229533 ms for demodulation
  139254 ms for reading from USB
  20844 ms for network input and background tasks
Tue Mar 29 13:41:06 2016 CEST  Caught SIGTERM, shutting down..

Tue Mar 29 13:41:37 2016 CEST  dump1090-mutability v1.15~dev starting up.
Using sample converter: UC8, integer/table path, with power measurement
Found 1 device(s):
0: Realtek, RTL2838UHIDIR, SN: 00000001 (currently selected)
Found Rafael Micro R820T tuner
Setting gain to: 44.50 dB
Gain reported by device: 44.50 dB

dmesg (only relevant lines copied during crash):


   34.895423] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[59308.234272] usb 1-1.2: USB disconnect, device number 4
[59308.473891] usb 1-1.2: new high-speed USB device number 6 using dwc_otg
[59308.585720] usb 1-1.2: New USB device found, idVendor=0bda, idProduct=2838
[59308.585745] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[59308.585756] usb 1-1.2: Product: RTL2838UHIDIR
[59308.585766] usb 1-1.2: Manufacturer: Realtek
[59308.585776] usb 1-1.2: SerialNumber: 00000001
[59313.479651] usb 1-1.2: usbfs: usb_submit_urb returned -121
.... (redundant lines deleted)
[59313.501829] usb 1-1.2: usbfs: usb_submit_urb returned -121
[59313.610987] usb 1-1.2: USB disconnect, device number 6
[59313.843911] usb 1-1.2: new high-speed USB device number 7 using dwc_otg
[59313.955936] usb 1-1.2: New USB device found, idVendor=0bda, idProduct=2838
[59313.955966] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[59313.955983] usb 1-1.2: Product: RTL2838UHIDIR
[59313.955998] usb 1-1.2: Manufacturer: Realtek
[59313.956013] usb 1-1.2: SerialNumber: 00000001

syslog:


Mar 29 12:39:01 raspberrypi rsyslogd-2007: action 'action 17' suspended, next retry is Tue Mar 29 12:40:31 2016 [try http://www.rsyslog.com/e/2007 ]
Mar 29 12:39:01 raspberrypi CRON[1773]: (root) CMD (   -x /usr/lib/php5/sessionclean ] && /usr/lib/php5/sessionclean)
Mar 29 12:40:01 raspberrypi CRON[1816]: (root) CMD (bash /home/pi/adsb-receiver/build/portal/graphs/make-collectd-graphs.sh 6h >/dev/null)
Mar 29 12:40:01 raspberrypi CRON[1817]: (root) CMD (bash /home/pi/adsb-receiver/build/portal/graphs/make-collectd-graphs.sh 1h >/dev/null)
Mar 29 12:40:08 raspberrypi kernel: [59308.234272] usb 1-1.2: USB disconnect, device number 4
Mar 29 12:40:08 raspberrypi kernel: [59308.473891] usb 1-1.2: new high-speed USB device number 6 using dwc_otg
Mar 29 12:40:08 raspberrypi kernel: [59308.585720] usb 1-1.2: New USB device found, idVendor=0bda, idProduct=2838
Mar 29 12:40:08 raspberrypi kernel: [59308.585745] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Mar 29 12:40:08 raspberrypi kernel: [59308.585756] usb 1-1.2: Product: RTL2838UHIDIR
Mar 29 12:40:08 raspberrypi kernel: [59308.585766] usb 1-1.2: Manufacturer: Realtek
Mar 29 12:40:08 raspberrypi kernel: [59308.585776] usb 1-1.2: SerialNumber: 00000001
Mar 29 12:40:13 raspberrypi kernel: [59313.479651] usb 1-1.2: usbfs: usb_submit_urb returned -121
Mar 29 12:40:13 raspberrypi kernel: [59313.479875] usb 1-1.2: usbfs: usb_submit_urb returned -121
Mar 29 12:40:13 raspberrypi kernel: [59313.480083] usb 1-1.2: usbfs: usb_submit_urb returned -121
Mar 29 12:40:13 raspberrypi kernel: [59313.480306] usb 1-1.2: usbfs: usb_submit_urb returned -121

....

Mar 29 13:40:01 raspberrypi CRON[3634]: (root) CMD (bash /home/pi/adsb-receiver/build/portal/graphs/make-collectd-graphs.sh 1h >/dev/null)
Mar 29 13:40:01 raspberrypi CRON[3635]: (root) CMD (bash /home/pi/adsb-receiver/build/portal/graphs/make-collectd-graphs.sh 6h >/dev/null)
Mar 29 13:41:06 raspberrypi systemd[1]: Stopping LSB: dump1090 daemon (mutability variant)...
Mar 29 13:41:06 raspberrypi rsyslogd-2007: action 'action 17' suspended, next retry is Tue Mar 29 13:42:36 2016 [try http://www.rsyslog.com/e/2007 ]
Mar 29 13:41:37 raspberrypi systemd[1]: Starting LSB: dump1090 daemon (mutability variant)...
Mar 29 13:41:38 raspberrypi systemd[1]: Started LSB: dump1090 daemon (mutability variant).
Mar 29 13:42:01 raspberrypi CRON[3800]: (root) CMD (bash /home/pi/adsb-receiver/build/portal/graphs/make-collectd-graphs.sh 24h >/dev/null)
Mar 29 13:44:01 raspberrypi rsyslogd-2007: action 'action 17' suspended, next retry is Tue Mar 29 13:45:31 2016 [try http://www.rsyslog.com/e/2007 ]
Mar 29 13:44:01 raspberrypi CRON[3876]: (root) CMD (bash /home/pi/adsb-receiver/build/portal/graphs/make-collectd-graphs.sh 7d >/dev/null)
Mar 29 13:45:01 raspberrypi CRON[3926]: (root) CMD (bash /home/pi/adsb-receiver/build/portal/graphs/make-collectd-graphs.sh 1h >/dev/null)

piaware.out:


03/29/2016 11:26:35 127442 msgs recv'd from dump1090-mutabi (0 in last 5m); 127305 msgs sent to FlightAware
03/29/2016 11:27:59 mlat(2036): Receiver status: connected
03/29/2016 11:27:59 mlat(2036): Server status:   not synchronized with any nearby receivers
03/29/2016 11:27:59 mlat(2036): Receiver:    0.0 msg/s received      0.0kB/s from receiver
03/29/2016 11:27:59 mlat(2036): Server:      0.0 kB/s from server    0.0kB/s TCP to server   0.0kB/s UDP to server
03/29/2016 11:27:59 mlat(2036): Aircraft: 0 of 0 Mode S, 0 of 0 ADS-B used
03/29/2016 11:31:35 127442 msgs recv'd from dump1090-mutabi (0 in last 5m); 127305 msgs sent to FlightAware
03/29/2016 11:36:35 127442 msgs recv'd from dump1090-mutabi (0 in last 5m); 127305 msgs sent to FlightAware
03/29/2016 11:41:05 no new messages received in 3630 seconds, it might just be that there haven't been any aircraft nearby but I'm going to try to restart dump1090, just in case...
03/29/2016 11:41:05 attempting to restart dump1090-mutability using 'invoke-rc.d dump1090-mutability restart'...
03/29/2016 11:41:38 dump1090 restart appears to have been successful
03/29/2016 11:41:38 mlat(2036): Lost connection to localhost:30005
03/29/2016 11:41:38 mlat(2036): Reconnecting in 30.0 seconds
03/29/2016 11:41:38 mlat(2036): Beast-format results connection with localhost:30104: connection lost
03/29/2016 11:41:48 ADS-B data program 'dump1090-mutab' is listening on port 30005, so far so good
03/29/2016 11:41:48 Starting faup1090: /usr/lib/piaware/helpers/faup1090 --net-bo-ipaddr localhost --net-bo-port 30005 --stdout --lat xx.yyy --lon x.yyy
03/29/2016 11:41:48 Started faup1090 (pid 3790) to connect to dump1090-mutab
03/29/2016 11:42:06 mlat(2036): Input connected to localhost:30005
03/29/2016 11:42:06 mlat(2036): Beast-format results connection with localhost:30104: connection established
03/29/2016 11:42:08 127528 msgs recv'd from dump1090-mutab (86 in last 6m); 127391 msgs sent to FlightAware
03/29/2016 11:42:59 mlat(2036): Receiver status: connected
03/29/2016 11:42:59 mlat(2036): Server status:   synchronized with 67 nearby receivers
03/29/2016 11:42:59 mlat(2036): Receiver:   16.1 msg/s received      0.3kB/s from receiver
03/29/2016 11:42:59 mlat(2036): Server:      0.0 kB/s from server    0.0kB/s TCP to server   0.0kB/s UDP to server
03/29/2016 11:42:59 mlat(2036): Results:  0.3 positions/minute
03/29/2016 11:42:59 mlat(2036): Aircraft: 2 of 17 Mode S, 31 of 42 ADS-B used
03/29/2016 11:46:35 128391 msgs recv'd from dump1090-mutab (863 in last 4m); 128254 msgs sent to FlightAware
03/29/2016 11:51:35 129246 msgs recv'd from dump1090-mutab (855 in last 5m); 129109 msgs sent to FlightAware
03/29/2016 11:56:35 130127 msgs recv'd from dump1090-mutab (881 in last 5m); 129990 msgs sent to FlightAware
03/29/2016 11:57:59 mlat(2036): Receiver status: connected
03/29/2016 11:57:59 mlat(2036): Server status:   synchronized with 134 nearby receivers
03/29/2016 11:57:59 mlat(2036): Receiver:  243.2 msg/s received      4.5kB/s from receiver
03/29/2016 11:57:59 mlat(2036): Server:      0.3 kB/s from server    0.0kB/s TCP to server   0.6kB/s UDP to server
03/29/2016 11:57:59 mlat(2036): Results:  133.2 positions/minute

Lots of log informations. Somebody any clues?

12

Ok, so:

  • the dongle disconnected and reconnected;
  • dump1090 tried to handle this but it did not go cleanly and something made it get stuck (librtlsdr is not very tolerant of USB errors)
  • eventually piaware noticed that there was no data arriving and restarted dump1090 which seemed to fix it.

The underlying cause is the USB disconnect / reconnect and USB errors; the rest is just symptoms.
This could be power problems making the dongle reset, bad USB cabling/contacts, or a bad dongle.

13

One additional remark: I moved to the adsbreceiver.net image about a week ago. That is also when instability issues began. Before that, I ran the PiAware SD card image without any problem…

14

**I’m operating under a lot of assumptions here, but here’s my GUESS about what’s happening.
**

  • The SDR dongle was getting just barely enough power initially

  • the increased load of the adsbreciever image’s better but more power hungry signal processing caused processor load to increase and bus voltage to slightly decrease

  • when message rate was particularly high, processor load was also highest, and the increased power load on the bus caused the voltage reaching the dongle to drop below its minimum threshold subsequently causing it to disconnect

The underlying problem there is power. It could be that the power supply you are using doesn’t have a quite high enough amperage rating and the load you are putting it under is causing a voltage drop.

It also could be that your power supply is fine, but you are using a faulty or low quality USB extension cable. If the wires in the extension cable have high resistance, the voltage reaching the dongle could be lower than what the USB port is putting out. In this scenario Under low system load, the dongle still may be within tolerances, but a small voltage drop under high load is exacerbated by the cable, and the dongle disconnects.

**I stand by the advice I gave earlier.
**I advise a good quality powered usb hub. This would solve either or both issues. A good powered hub can run the dongle and the wifi adapter with power to spare. I was having an issue with usb disconnects and reconnects and this solved the issue.
A better RPI power supply would likely also solve the problem as long as you aren’t using a USB extension cable. If you are, and opt for the power supply route, I would replace the USB extension as well or connect the dongle directly to the pi.

If you are using a USB extension cable, something you could try without replacing anything is to simply plug the dongle directly into the RPI with no extension, though this may be difficult to do and also plug in a wifi adapter.

15

Hi Jon,

Thanks again for your reply. I fully agree with your conclusions and guess about what is happening. I’m not using an extension cable, both the wifi adapter and the RTL dongle are directly plugged into the Rpi. The power supply I use is a 2A model. I guess my next try should indeed be to connect the RTL and wifi dongle through a powered hub. Or to go back to the wired ethernet connection and accept the performance degradation…

16

There is one more thing to check in /boot/config.txt. I believe the FlightAware image sets max_usb_current=1. If you have your old image, check to see if it was set on that image but is missing on your new image.

Cheers!
LitterBug

PS: I have 1 RPi2 that has a flaky power regulator. It would do similar to what you are seeing unless I had the dongles plugged into a powered USB hub. The other symptoms I was seeing was the red power indicator light would flicker, and the “rainbow square” would pop up on the upper right corner of the display.