Easiest way to add 978

I mentioned recommended values in my last post and linked an entire thread.

It should yes.

The only electronic device in the room is the PiAware device, so limited chance of other interference. I have also noticed that my 1090 numbers have gone down by more than 50% since I added UAT on the same Raspberry Pi. My plan was to have an incremental gain in overall receptions, but so far it has been quite disappointing. Also, my question about gain was not what it is, but how do I see what it is currently set to so I can go up and down the scale from it’s current setting.

piaware-config -show rtlsdr-gain
piaware-config -show uat-sdr-gain

max should be 49.6 for UAT/978.
not sure for 1090 max might be agc which can be equated to roughly 55 or so.

Both just show “max” (without the quotes), not very helpful, but I appreciate the commands though.

But i mentioned what max means in the very same post.

Anyhow just set 1090 to 43.9 and 978 to 36 and start from there.
Then increase / decrease the gain by maybe 3 or 6 points to move the weakest signal around.
For 978 a good place for the weakest signal is -33 or so and for 1090 it’s probaly -29.
(weakest signal in graphs1090)

I have all the software now setup and all but my UAT antenna operating. I have temporarily installed one of the cheapy antennas that come with generic RTL-SDR tuners to the UAT receiver until I get the 7 dBi 978 MHz antenna, which should be Tuesday. I just installed a PoE HAT on my Pi4, as I have it installed in an attic space where there is no power connection. To adjust the gain, I installed an automatic gain optimization script. It automatically changed the gain of the ES tuner to 49.6 last night. I do not believe that software works for doing the same on UAT. At the moment, my UAT receiver hasn’t picked anything up but then again, it is dark and nearly 9PM at night. I’ll be curious to see if the cheap little antenna picks up any UAT traffic.

No it’s 1090 only. .

I’ve been operating my UAT now for just under 24 hours. As I expected, there was not much traffic over night but it perked up as the day got brighter.
dump1090-localhost-aircraft_978-24h dump1090-localhost-signal_978-24h

As of this writing, that is tracking 72 aircraft with a piece-of-garbage antenna. The farthest away was 70 miles but the average distance was about 13 nautical miles away. I’m just curious if there is any need to adjust the gain of this or if I should just wait until I get my final and hopefully more capable antenna.

1 Like

[quote=“abcd567, post:1, topic:48262”]

Hi there. I am not able to get this to work. I get a connection refused error for http://local-ip-of-pi:8978/` and a 404 URL not found for http://local-ip-of-pi/skyview978/

Can someone help correct this please?

Thanks

What he is saying is that the Pi computer has an address on your network - called an “ip address”. If you have any kind of default configuration from your internet service provider, your addresses probably look like “192.168.1.123”, “192.168.0.123”, or “10.1.1.123”. (Or a variation of these).

In all cases, every computer on your network will share the first three numbers in the group (xxx.xxx.xxx.123). The last number (192.168.1.xxx) identifies a particular device.

For example, in my case, my internet modem is 192.168.0.1. My Pi is 192.168.0.8. My 978 flight feeder is 192.168.0.11. Your addresses will likely be similar, but different. If you don’t know your local ip address you can go to your FlightAware stats page. When you are logged in, you will see the local address here:

Where @abcd567 says “local-ip-of-pi”, you should replace that with the actual address of your pi. So, again, in my case, http://local-ip-of-pi/skyview978/ would translate to http://192.168.0.11/skyview978/

1 Like

hope it’s ok to piggyback into this, I got here from the same initial error, but have slightly different results.

● dump978-fa.service - dump978 ADS-B UAT receiver
     Loaded: loaded (/lib/systemd/system/dump978-fa.service; enabled; preset: enabled)
     Active: activating (auto-restart) (Result: exit-code) since Tue 2024-04-16 09:22:55 CDT; 18s ago
       Docs: https://flightaware.com/adsb/piaware/
    Process: 7062 ExecStart=/usr/share/dump978-fa/start-dump978-fa (code=exited, status=2)
   Main PID: 7062 (code=exited, status=2)
        CPU: 174ms

my two dongles are serialized, and each runs individually just fine, and they’re listening on their own default ports - but I think I’m getting a conflict and dunno how to resolve it.

in regards to this post: I revisited the installation instructions, and found an omitted step. Problem resolved.

Seems you omitted 2nd or 3rd (or both) commands in following step:

 

1 Like

Hello. I realize the latest entry in this thread is over a year old, but hopefully I can still jump on.

I recently replaced my two fully functional Pi3 receivers (one for 1090, the other for 978) with a single Pi4 where I installed both dongles, hoping to have everything running on one piece of hardware. 1090 seems to be working fine and feeding all but 1 service successfully. The 978 is not working correctly, despite dump978-fa running.

I am running a generic debian install where I have installed feeders from the various services from the net. I got PiAware running first but it’s still not a PiAware image. In the “Configure UAT 978” post above, the last 2 lines fail with:
“warning: cannot set option , option only supported on PiAware or FlightFeeder SD card images”.
Is there any chance I can work around this without creating an entirely new image and starting from scratch?
Also, after running the “journalctl dump978-fa” command, I get this:
Jun 17 21:37:03 pi4-adsb systemd[1]: dump978-fa.service: Scheduled restart job, restart counter is at 9989.
Jun 17 21:37:03 pi4-adsb systemd[1]: Stopped dump978-fa.service - dump978 ADS-B UAT receiver.
Jun 17 21:37:04 pi4-adsb systemd[1]: Started dump978-fa.service - dump978 ADS-B UAT receiver.
Jun 17 21:37:04 pi4-adsb dump978-fa[232693]: raw-port: listening for connections on 0.0.0.0:30978
Jun 17 21:37:04 pi4-adsb dump978-fa[232693]: raw-port: listening for connections on [::]:30978
Jun 17 21:37:04 pi4-adsb dump978-fa[232693]: json-port: listening for connections on 0.0.0.0:30979
Jun 17 21:37:04 pi4-adsb dump978-fa[232693]: json-port: listening for connections on [::]:30979
Jun 17 21:37:04 pi4-adsb dump978-fa[232693]: usb_claim_interface error -6
Jun 17 21:37:04 pi4-adsb dump978-fa[232693]: Found Rafael Micro R820T tuner
Jun 17 21:37:04 pi4-adsb dump978-fa[232693]: usb_claim_interface error -6
Jun 17 21:37:04 pi4-adsb dump978-fa[232693]: Configuration error: No matching SoapySDR device found (cause: Unable to open RTL-SDR device)
Jun 17 21:37:04 pi4-adsb systemd[1]: dump978-fa.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
Jun 17 21:37:04 pi4-adsb systemd[1]: dump978-fa.service: Failed with result ‘exit-code’.
I think at least one problem is that the port listening for connections should be either 127.0.0.1 or the local IP address of the Pi. I can probably fix that if I know what config file to edit. There may be more issues, but getting that IP corrected first can’t hurt.

I think I’m close to having this thing going. If anyone has suggestions on how to proceed, I would love to hear them. Thanks.

What is output of following command?

sudo journalctl -u piaware -n15

 

Here’s the output:
Jun 18 00:12:27 pi4-adsb piaware[214497]: mlat-client(377559): Accepted Beast-format results connec>
Jun 18 00:12:30 pi4-adsb piaware[214497]: mlat-client(377559): Accepted Beast-format results connec>
Jun 18 00:12:33 pi4-adsb piaware[214497]: mlat-client(377559): Accepted Beast-format results connec>
Jun 18 00:12:36 pi4-adsb piaware[214497]: mlat-client(377559): Accepted Beast-format results connec>
Jun 18 00:12:39 pi4-adsb piaware[214497]: mlat-client(377559): Accepted Beast-format results connec>
Jun 18 00:12:42 pi4-adsb piaware[214497]: mlat-client(377559): Accepted Beast-format results connec>
Jun 18 00:12:45 pi4-adsb piaware[214497]: mlat-client(377559): Accepted Beast-format results connec>
Jun 18 00:12:49 pi4-adsb piaware[214497]: mlat-client(377559): Accepted Beast-format results connec>
Jun 18 00:12:50 pi4-adsb piaware[214497]: 19470 msgs recv’d from dump1090-fa (190 in last 5m); 1944>
Jun 18 00:12:50 pi4-adsb piaware[214497]: 0 msgs recv’d from dump978 (0 in last 5m); 0 msgs sent to>
Jun 18 00:12:52 pi4-adsb piaware[214497]: mlat-client(377559): Accepted Beast-format results connec>
Jun 18 00:12:55 pi4-adsb piaware[214497]: mlat-client(377559): Accepted Beast-format results connec>
Jun 18 00:12:58 pi4-adsb piaware[214497]: mlat-client(377559): Accepted Beast-format results connec>
Jun 18 00:13:01 pi4-adsb piaware[214497]: mlat-client(377559): Accepted Beast-format results connec>
Jun 18 00:13:04 pi4-adsb piaware[214497]: mlat-client(377559): Accepted Beast-format results connec>

If there is more info off to the right, I don’t know how to get it. Changing n to 1 didn’t let me see the rest of the line. Is the above sufficient? Thanks for taking a look.

The commands given in that post are for Piaware SD card imnage.
You have Raspberry Pi OS image with package install. For this case do following:

Step 1 of 4: Serialize 1090 MHz and 978 MHz dongles (CLICK HERE).

In my installation I have used 8-digit serial numbers 00001090 (for 1090 MHz dongle) and 00000978 for 978 MHz dongle.

Step 2 of 4 Configure dump1090-fa

sudo nano /etc/default/dump1090-fa

in this file add 1090 dongle serial as shown in screenshot below

Step 3 of 4: Configure dump978-fa

sudo nano /etc/default/dump978-fa

in this file add 978 dongle serial as shown in screenshot below

Step 4 of 4: Restart dump1090-fa, dump978-fa and piaware (or Reboot Pi)

sudo systemctl restart dump1090-fa

sudo systemctl restart dump978-fa

sudo systemctl restart piaware
 

 

My dongles were already serialized from some time in the past I guess. The files in /etc/default had the correct serial numbers in them. I was missing a comma in the 978 file so I corrected that then ran the sytemctl commands. There was no change :(.

I don’t see it in this thread, but I got an email asking for output of rtl_test -t -d x. Here is that output:
scott@pi4-adsb:~ $ rtl_test -t -d 0
Found 2 device(s):
0: Realtek, RTL2832U, SN: 00001000
1: Realtek, UAT_978, SN: 00000401

Using device 0: Generic RTL2832U
usb_claim_interface error -6
Failed to open rtlsdr device #0.
scott@pi4-adsb:~ $ rtl_test -t -d 1
Found 2 device(s):
0: Realtek, RTL2832U, SN: 00001000
1: Realtek, UAT_978, SN: 00000401

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

Is there a problem with device 1 not using the 978 dongle? If so, what is the fix? Thanks for your continued support. I really appreciate it.

This was posted by me in my last post above, but later I replaced it by the two screenshots and 4 steps. It seems forum sent you my original message by email before I modified it.

 

Let us first see if dongle is healthy or defective. If found healthy, then most likely cause is (1) either dump978-fa is not installed correctly. In this case it will be necessary to re-install dump978-fa or (2) another software is using dongle 1. This can happen if FR24 feeder is misconfigured, and silently installs dump1090-mutability. This can also happen if dump978-rb is installed during installation of RB24 feeder

Step 1 of 4:
Stop both dump1090 and dump978

sudo systemctl stop dump1090-fa  

sudo systemctl stop dump978-fa

Step 2 of 4:
conduct test given below, and post output of both tests.

rtl_test -t -d 0

rtl_test -t -d 1  

Step 3 of 4:
After test is completed, restart both dump1090 and dump978

sudo systemctl restart dump1090-fa  

sudo systemctl restart dump978-fa

Step 4 of 4:
Issue following command which will list all versions of dump running, including dump1090-mutability and dump978-rb if installed and running.

pgrep -l dump

 

Here’s the output of step 2:
scott@pi4-adsb:~ $ rtl_test -t -d 0
Found 2 device(s):
0: Realtek, RTL2832U, SN: 00001000
1: Realtek, UAT_978, SN: 00000401

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.
scott@pi4-adsb:~ $ rtl_test -t -d 1
Found 2 device(s):
0: Realtek, RTL2832U, SN: 00001000
1: Realtek, UAT_978, SN: 00000401

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

And here’s the pgrep output:
734 openskyd-dump10
1517143 dump1090-fa

What is next? Thanks for your continued help.