Trouble with PiAware 8.2 on Ubuntu 20.04 Installed on Odroid N2

Hello!

I am new to the forums here. I previously had Piaware 7.2 installed on my Odroid N2 with Ubuntu 20.04, which ran for a full year before I tried updating the software.

Upon updating, I was having OS issues with Ubuntu 20.04, so did a fresh install. However, I am now having trouble connecting the SDR to the system. I think it is something to do with the SDR. I tried blacklisting the SDR and the 978 side of things worked briefly before I tried a few things (blacklisting) and then it does not work, nor the 1090.

I am not sure if it is something to do with ports, or the dongles? One is the FlightAware blue SDR, the other is a NOOELEC NESDR SMArtee XTR. The latter I was able to get working briefly.

The 1090 SDR I get a claim_interface Error -6 error

The SN for each SDR is correct. I have been trying to figure this out for two weeks, and am a little disheartened. I am not very familiar with Ubuntu/Odroid N2 programming, but am trying.

Thank you!

-6 means that something else is already using that device.

For a dual-dongle system, you need to do two things:

  1. give each dongle a different serial number
  2. configure dump1090 and dump978 to each use a specific serial number

Based on the limited information you gave, I expect that the problem is (2). Check your dump1090 and dump978 configs to ensure that you have specified the right serial numbers there.

Please post output of following commands:

grep RECEIVER_SERIAL /etc/default/dump1090-fa   


grep RECEIVER_OPTIONS /etc/default/dump978-fa   


rtl_test -t    

 

Thank you both for the replies!

For the dongle with the -6, that was the dump1090 SDR previously used that I tried to wipe and reset, but it would appear was not the case.

For the following commands I get in order:

RECEIVER_SERIAL=00001090

root@odroid:~# grep RECEIVER_OPTIONS /etc/default/dump978-fa 
RECEIVER_OPTIONS="--sdr driver=rtlsdr,serial=00000978 --format CS8

root@odroid:~# rtl_test -t
Found 2 device(s):
  0:  Realtek, RTL2832U, SN: 00001090
  1:  Realtek, RTL2838UHIDIR, SN: 00000978

Using device 0: Generic RTL2832U
usb_claim_interface error -6
Failed to open rtlsdr device #0.```

Silly question, what is the best way to insert code? I am also new here.

METHOD-1:

[code]
Your code here
[/code]

METHOD-2:

```
Your code here
```

 

image

 

Thank you very much. I was half way there… I appreciate that.

As requested, the print outs are as follows:

root@odroid:~# grep RECEIVER_SERIAL /etc/default/dump1090-fa 
RECEIVER_SERIAL=00001090
root@odroid:~# grep RECEIVER_OPTIONS /etc/default/dump978-fa 
RECEIVER_OPTIONS="--sdr driver=rtlsdr,serial=00000978 --format CS8
root@odroid:~# rtl_test -t
Found 2 device(s):
  0:  Realtek, RTL2832U, SN: 00001090
  1:  Realtek, RTL2838UHIDIR, SN: 00000978

Using device 0: Generic RTL2832U
usb_claim_interface error -6
Failed to open rtlsdr device #0.

The serial number in the output of the grep commands match exactly with serial numbers in output of rtl_test command.

This proves that there is no problem of wrong or incomplete serialization.

Now let us test both dongles. Please issue following commands and post outout of last 2 commands.

sudo systemctl stop piaware dump1090-fa dump978-fa  

rtl_test -t -d 0  

rtl_test -t -d 1  

 

Excellent!

I appreciate the verification. The guides have been very useful on this site in general.

The two outputs are:

root@odroid:~# rtl_test -t -d 0  
Found 2 device(s):
  0:  Realtek, RTL2832U, SN: 00001090
  1:  Realtek, RTL2838UHIDIR, SN: 00000978

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.
root@odroid:~# rtl_test -t -d 1
Found 2 device(s):
  0:  Realtek, RTL2832U, SN: 00001090
  1:  Realtek, RTL2838UHIDIR, SN: 00000978

Using device 1: Generic RTL2832U OEM
Found Elonics E4000 tuner
Supported gain values (14): -1.0 1.5 4.0 6.5 9.0 11.5 14.0 16.5 19.0 21.5 24.0 29.0 34.0 42.0 
Sampling at 2048000 S/s.
Benchmarking E4000 PLL...
[E4K] PLL not locked for 50000000 Hz!
[E4K] PLL not locked for 2204000000 Hz!
[E4K] PLL not locked for 1102000000 Hz!
[E4K] PLL not locked for 1221000000 Hz!
E4K range: 51 to 2203 MHz
E4K L-band gap: 1102 to 1221 MHz

Elonics E4000 tuner… hmmm

What is make/model of 978 dongle?

@obj
Any comments?
I am not sure if Elconics E4000 tuner can work OK with dump978-fa / dump1090-fa.

The 1090 dongle is the FlightAware Pro Stick Plus, with the 978 dongle being the Nooelec NESDR SMArtee XTR.

They tend to be deaf / untuneable at 1090MHz, but they’re probably OK at 978.

1 Like

No trailing quote on that line?

1 Like

**Edit
After doing some reading, I tried upgrading the OS from Ubuntu 20.04 to 22.04, which corrupted my SD card used to hold the OS. I have to order a new SSD for the Odroid N2, and see if that was my issue all along.

Double checked and there is a trailing quote as below:

root@odroid:~# grep RECEIVER_OPTIONS /etc/default/dump978-fa 
RECEIVER_OPTIONS="--sdr driver=rtlsdr,serial=00000978 --format CS8"

I am wondering if maybe there is something not being allowed via the ports? The only thing I changed on the computer was setting a static IP that matched what I had before.

For what it is worth, I ran the following as well:

systemctl status piaware

which output:

root@odroid:~# systemctl status piaware
â—Ź piaware.service - FlightAware ADS-B uploader
     Loaded: loaded (/lib/systemd/system/piaware.service; enabled; vendor prese>
     Active: active (running) since Tue 2023-07-18 12:10:32 CDT; 3min 22s ago
       Docs: https://flightaware.com/adsb/piaware/
   Main PID: 4083 (piaware)
      Tasks: 6 (limit: 3832)
     Memory: 28.5M
     CGroup: /system.slice/piaware.service
             ├─4083 /usr/bin/piaware -p /run/piaware/piaware.pid -plainlog -sta>
             ├─4133 /usr/lib/piaware/helpers/faup1090 --net-bo-ipaddr localhost>
             ├─4137 /usr/lib/piaware/helpers/faup978 --connect localhost:30978
             └─4775 /usr/lib/piaware/helpers/fa-mlat-client --input-connect loc>

Jul 18 12:12:01 odroid sudo[4773]: pam_unix(sudo:session): session closed for u>
Jul 18 12:12:01 odroid piaware[4083]: Starting multilateration client: /usr/lib>
Jul 18 12:12:01 odroid piaware[4083]: mlat-client(4775): fa-mlat-client 0.2.12 >
Jul 18 12:12:01 odroid piaware[4083]: mlat-client(4775): Using UDP transport to>
Jul 18 12:12:01 odroid piaware[4083]: mlat-client(4775): Listening for Beast-fo>
Jul 18 12:12:01 odroid piaware[4083]: mlat-client(4775): Listening for Extended>
Jul 18 12:12:01 odroid piaware[4083]: mlat-client(4775): Route MTU changed to 1>
Jul 18 12:12:01 odroid piaware[4083]: mlat-client(4775): Input connected to loc>
Jul 18 12:12:01 odroid piaware[4083]: mlat-client(4775): Input format changed t>
Jul 18 12:12:01 odroid piaware[4083]: mlat-client(4775): Beast-format results c>
lines 1-23

Upon startup, I show the 978 system running, then within a few minutes it shows offline (below is how it starts)

Figured I would post an update incase someone else stumbles across similar issues. While not determined to be the final solution (I will edit this post if it is), it appears to be a multifaceted problem.

Problem 1:
The Odroid N2+ computer I was using in place of a raspberry Pi got quite hot, and was causing stability issues, which likely lead to the SD card used to hold the Ubuntu 20.04 OS to fail prematurely.

Solution 1:
Ordered a fan to cool the Odroid N2+, along with a more responsive and stable 32GB eMMC SSD with Linux preloaded. Finally I ordered vents from Digikey to go on my enclosure to allow better air flow. (I can post part numbers if anyone is interested).

Problem 2:
Nooelec NESDR SMArtee XTR was not connecting to PiAware. Plugging the SDR into another computer, it appears the SDR may be bad. Further investigation needed.

Solution 2:
Ordered an orange FlightAware Pro Stick, I already have a 1090/978 filter so didnt need another Pro Stick Plus (out of stock at the time of this write up).

With any luck, these fixes should create a more robust and resilient system that will be easier to maintain and provide longer intervals between servicing.

Parts came in!

However the problem persists… I started with a fresh Ubuntu 22.04 install, got a new orange dongle, installed it, and when the USB starts first it shows green below, but after a few minutes goes orange again. The 1090 radio never goes green, and just stays orange (same with MLAT).

I went through and redid the above steps. Additional troubleshooting steps was trying to isolate the home network, but that seemed to have no effect either.

Definitely open to further suggestions.

root@odroid:~# rtl_test -t
Found 2 device(s):
  0:  Generic, RTL2832U DVB-T, SN: 00000978
  1:  Generic, RTL2832U DVB-T, SN: 00001090

Using device 0: Generic RTL2832U
usb_claim_interface error -6
Failed to open rtlsdr device #0.
root@odroid:~# rtl_test -t -d 0 
Found 2 device(s):
  0:  Generic, RTL2832U DVB-T, SN: 00000978
  1:  Generic, RTL2832U DVB-T, SN: 00001090

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.

root@odroid:~# rtl_test -t -d 1 
Found 2 device(s):
  0:  Generic, RTL2832U DVB-T, SN: 00000978
  1:  Generic, RTL2832U DVB-T, SN: 00001090

Using device 1: 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.


Please post output of last 2 commands

sudo reboot

## After reboot, wait for 5 minutes,
## then issue following commands

sudo journalctl -u dump1090-fa -b    

sudo journalctl -u dump978-fa -b     

 

@abcd567 Thank you for your assistance on this, it is greatly appreciated. The forums here have a ton of great information, I just seem to be coming up short (or not looking for the right items!)

Below I have the requested journal outputs, when I run the status, everything appears to be running except the localhost:30005. I believe I have allowed that port on initial setup?

root@odroid:~# sudo piaware-status
PiAware master process (piaware) is running with pid 4143.
PiAware ADS-B client (faup1090) is running with pid 4223.
PiAware ADS-B UAT client (faup978) is running with pid 4226.
PiAware mlat client (fa-mlat-client) is running with pid 4240.
Local ADS-B receiver (dump1090-fa) is running with pid 3464.
Local ADS-B UAT receiver (dump978-fa) is running with pid 3473.

dump1090-fa (pid 3464) is listening for ES connections on port 30005.
dump978-fa (pid 3473) is listening for UAT connections on port 30978.
faup1090 is connected to the ADS-B receiver.
faup978 is connected to the ADS-B UAT receiver.
piaware is connected to FlightAware.

dump978 is producing data on localhost:30978.
dump1090 is NOT producing data on localhost:30005.

First Request:

root@odroid:~# sudo journalctl -u dump1090-fa -b
Aug 02 07:25:16 odroid systemd[1]: Started dump1090 ADS-B receiver (FlightAware>
Aug 02 07:25:17 odroid dump1090-fa[3464]: Wed Aug  2 07:25:17 2023 CDT  dump109>
Aug 02 07:25:17 odroid dump1090-fa[3464]: rtlsdr: using device #1: Generic RTL2>
Aug 02 07:25:17 odroid dump1090-fa[3464]: Found Rafael Micro R820T tuner
Aug 02 07:25:17 odroid dump1090-fa[3464]: rtlsdr: tuner gain set to about 58.6 >
Aug 02 07:25:18 odroid dump1090-fa[3464]: adaptive: using 50% duty cycle
Aug 02 07:25:18 odroid dump1090-fa[3464]: adaptive: enabled adaptive gain contr>
Aug 02 07:25:18 odroid dump1090-fa[3464]: adaptive: enabled dynamic range contr>
Aug 02 07:25:18 odroid dump1090-fa[3464]: Allocating 4 zero-copy buffers
Aug 02 07:25:28 odroid dump1090-fa[3464]: adaptive: available dynamic range (0.>
Aug 02 07:25:28 odroid dump1090-fa[3464]: adaptive: changing gain from 58.6dB (>
Aug 02 07:25:28 odroid dump1090-fa[3464]: rtlsdr: tuner gain set to 49.6 dB (ga>
Aug 02 07:25:38 odroid dump1090-fa[3464]: adaptive: available dynamic range (0.>
Aug 02 07:25:38 odroid dump1090-fa[3464]: adaptive: changing gain from 49.6dB (>
Aug 02 07:25:38 odroid dump1090-fa[3464]: rtlsdr: tuner gain set to 48.0 dB (ga>
Aug 02 07:26:13 odroid dump1090-fa[3464]: adaptive: available dynamic range (0.>
Aug 02 07:26:13 odroid dump1090-fa[3464]: adaptive: changing gain from 48.0dB (>
Aug 02 07:26:13 odroid dump1090-fa[3464]: rtlsdr: tuner gain set to 44.5 dB (ga>
Aug 02 07:26:23 odroid dump1090-fa[3464]: adaptive: available dynamic range (0.>
Aug 02 07:26:23 odroid dump1090-fa[3464]: adaptive: changing gain from 44.5dB (>
Aug 02 07:26:23 odroid dump1090-fa[3464]: rtlsdr: tuner gain set to 43.9 dB (ga>
Aug 02 07:26:33 odroid dump1090-fa[3464]: adaptive: available dynamic range (0.>
Aug 02 07:26:33 odroid dump1090-fa[3464]: adaptive: changing gain from 43.9dB (>

Second request:

root@odroid:~# sudo journalctl -u dump978-fa -b 
Aug 02 07:25:16 odroid systemd[1]: Started dump978 ADS-B UAT receiver.
Aug 02 07:25:17 odroid dump978-fa[3473]: raw-port: listening for connections on>
Aug 02 07:25:17 odroid dump978-fa[3473]: raw-port: listening for connections on>
Aug 02 07:25:17 odroid dump978-fa[3473]: json-port: listening for connections o>
Aug 02 07:25:17 odroid dump978-fa[3473]: json-port: listening for connections o>
Aug 02 07:25:18 odroid dump978-fa[3473]: Found Rafael Micro R820T tuner
Aug 02 07:25:18 odroid dump978-fa[3473]: usb_claim_interface error -6
Aug 02 07:25:18 odroid dump978-fa[3473]: Found Rafael Micro R820T tuner
Aug 02 07:25:18 odroid dump978-fa[3473]: Exact sample rate is: 2083333.135571 Hz
Aug 02 07:25:18 odroid dump978-fa[3473]: [R82XX] PLL not locked!
Aug 02 07:25:18 odroid dump978-fa[3473]: SoapySDR: using maximum manual gain 49>
Aug 02 07:25:18 odroid dump978-fa[3473]: SoapySDR: using stream setting buffsiz>
Aug 02 07:25:18 odroid dump978-fa[3473]: [::]:30978: accepted a connection from>
Aug 02 07:25:18 odroid dump978-fa[3473]: Allocating 15 zero-copy buffers
Aug 02 07:25:19 odroid dump978-fa[3473]: Failed to allocate zero-copy buffer fo>
Aug 02 07:25:19 odroid dump978-fa[3473]: Falling back to buffers in userspace
Aug 02 07:25:31 odroid dump978-fa[3473]: [::]:30978: accepted a connection from>
lines 1-17/17 (END)

Truncated line so I can’t see the exact value, but a dynamic range of <1 dB implies that dump1090-fa is seeing a ridiculously high noise floor.

I wonder if this is another variant of the old zero-copy arm cache kernel bug reappearing and dump1090 is just getting garbage data. (from the logs, dump978-fa disables zero-copy – probably because it’s hitting a size limit – and seems to work fine)

Re-ran the command for dump1090-fa, and get the below result:

Aug 02 12:46:31 odroid dump1090-fa[3463]: Wed Aug  2 12:46:31 2023 CDT  dump1090-fa 8.2 starting up.
Aug 02 12:46:31 odroid dump1090-fa[3463]: rtlsdr: using device #1: Generic RTL2832U (Generic, RTL2832U DVB->
Aug 02 12:46:31 odroid dump1090-fa[3463]: Found Rafael Micro R820T tuner
Aug 02 12:46:32 odroid dump1090-fa[3463]: rtlsdr: tuner gain set to about 58.6 dB (gain step 29) (tuner AGC>
Aug 02 12:46:32 odroid dump1090-fa[3463]: adaptive: using 50% duty cycle
Aug 02 12:46:32 odroid dump1090-fa[3463]: adaptive: enabled adaptive gain control with gain limits 0.0dB (s>
Aug 02 12:46:32 odroid dump1090-fa[3463]: adaptive: enabled dynamic range control, target dynamic range 30.>
Aug 02 12:46:32 odroid dump1090-fa[3463]: Allocating 4 zero-copy buffers
Aug 02 12:46:42 odroid dump1090-fa[3463]: adaptive: available dynamic range (0.2dB) < required dynamic rang>
Aug 02 12:46:42 odroid dump1090-fa[3463]: adaptive: changing gain from 58.6dB (step 29) to 49.6dB (step 28)>
Aug 02 12:46:42 odroid dump1090-fa[3463]: rtlsdr: tuner gain set to 49.6 dB (gain step 28)
Aug 02 12:46:52 odroid dump1090-fa[3463]: adaptive: available dynamic range (0.0dB) < required dynamic rang>
Aug 02 12:46:52 odroid dump1090-fa[3463]: adaptive: changing gain from 49.6dB (step 28) to 48.0dB (step 27)>
Aug 02 12:46:52 odroid dump1090-fa[3463]: rtlsdr: tuner gain set to 48.0 dB (gain step 27)
Aug 02 13:13:00 odroid dump1090-fa[3463]: adaptive: available dynamic range (0.0dB) < required dynamic rang>
Aug 02 13:13:00 odroid dump1090-fa[3463]: adaptive: changing gain from 48.0dB (step 27) to 44.5dB (step 26)>
Aug 02 13:13:00 odroid dump1090-fa[3463]: rtlsdr: tuner gain set to 44.5 dB (gain step 26)
Aug 02 13:13:10 odroid dump1090-fa[3463]: adaptive: available dynamic range (0.0dB) < required dynamic rang>
Aug 02 13:13:10 odroid dump1090-fa[3463]: adaptive: changing gain from 44.5dB (step 26) to 43.9dB (step 25)>
Aug 02 13:13:10 odroid dump1090-fa[3463]: rtlsdr: tuner gain set to 43.9 dB (gain step 25)
Aug 02 13:13:20 odroid dump1090-fa[3463]: adaptive: available dynamic range (0.0dB) < required dynamic rang>
Aug 02 13:13:20 odroid dump1090-fa[3463]: adaptive: changing gain from 43.9dB (step 25) to 43.4dB (step 24)>
Aug 02 13:13:20 odroid dump1090-fa[3463]: rtlsdr: tuner gain set to 43.4 dB (gain step 24)

A high noise floor would not surprise me… The noise floor here is a major hurdle for my ham equipment (regularly above -70dBm), and the SNR is rough (but good experience in learning about and applying filters and chokes). A lot of it is in the GHz frequencies (over 300 Wifi AP SSID’s are detectable), some in the HF region as well. The FlightAware Pro Plus should have a 1090 MHz bandpass filter if I recall, but I am not sure what the stop bands are, but I would imagine they are well below 2.4 GHz.

From what I have read, it could be related to the bug? The eMMC storage device is brand new, with a fresh install of Ubuntu 22.04. I was having the same issue with Ubuntu 20.04 prior to getting a new storage card.

The odd thing is the dump978-fa will randomly output data for a short time, then stop.

Is the dump1090 is NOT producing data on localhost:30005. related to the cache kernel bug, or related to the port being open/closed? I will have to check to see if I can have my network firewall allow port 30005.

Again, I greatly appreciate the help and suggestions!