the last one piaware2 | grep logged = logged in to FlightAware as user guest.
they both have feeder IDs.
the grep site for piaware is under /stats/user but the piaware2 is under /stats/site
If piaware2 has a feeder-id and is logged in as user guest, then you should be able to claim it by visiting piaware claim page while logged-in to your flightaware account.
Am I not seeing the 2nd feeder to claim because the Raspi only has one IP address for both feeders so the FlightAware site only links the first one?
I was successful with manually claiming the feeder id by appending it after the /piaware/claim/(feeder id) - found the tip in an old post from Oct2020 …
This may be possible.
To solve this, stop & disable piaware, then reboot pi. Now only piaware2 will run, and you will most likely be able to claim it & link to your account. After caiming, yo can reenable and restart piaware, so both piaware and piaware2 will work OK from same Pi/IP
sudo systemctl disable piaware
sudo reboot
Wait for say 5 minutes, then go to claims page. Most likely you will now piaware2 will appear and you can claim it.
After claiming, enable piaware, and reboot PI. Now both piaware & piaware2 will be running and logged to your account.
sudo systemctl enable piaware
sudo reboot
Thanks for all the help today. I’ll try your solution on my next setup if I run into the same problem again.
@abcd567 regarding your set-gain script, for two 1090 feeders, should I use the script with the master link or this temp one? I tried the master link but the gain values stayed the same for both feeders regardless of which one I change. I need to run your temp link below, correct?
Yes, use the new set-gain script “set-gain-2-receivers.sh”
That worked but I had two gain buttons due to the 2nd install but your uninstall notes below helped me delete the duplicate set of the 3 lines …
1 Like
The Skyaware2 gain button wasn’t updating the /etc/default/dump-fa2 gain values so I uninstalled both buttons and the associated other files per the uninstall steps. Might have been caused by the double gain + gain2 installs. I’ll try again later on a different clean install.
1 Like
@abcd567 when I check the status of dump1090-fa2 I get “Main PID: 1699557 (code=exited, status=1/FAILURE)”. I tried to restart dump1090-fa2 but nothing changes. Any ideas how to get dump1090-fa2 running again?
Both dongles show up when I run rtl_test -t .
Oct 29 22:22:29 raspberrypi systemd[1]: dump1090-fa2.service: Failed with result ‘exit-code’.
Oct 29 22:22:59 raspberrypi systemd[1]: dump1090-fa2.service: Scheduled restart job, restart counter is at 7081.
Oct 29 22:22:59 raspberrypi systemd[1]: Stopped dump1090-fa2.service - dump1090 ADS-B receiver (FlightAware cust>
Oct 29 22:22:59 raspberrypi systemd[1]: Started dump1090-fa2.service - dump1090 ADS-B receiver (FlightAware cust>
Oct 29 22:22:59 raspberrypi dump1090-fa2[1749108]: Wed Oct 29 22:22:59 2025 CDT dump1090-fa 10.2 starting up.
Oct 29 22:22:59 raspberrypi dump1090-fa2[1749108]: rtlsdr: using device #1: Generic RTL2832U OEM (Nooelec, NESDR>
Oct 29 22:22:59 raspberrypi dump1090-fa2[1749108]: Found Rafael Micro R820T tuner
Oct 29 22:22:59 raspberrypi dump1090-fa2[1749108]: rtlsdr: tuner gain set to 7.7 dB (gain step 5)
Oct 29 22:23:00 raspberrypi dump1090-fa2[1749108]: Allocating 4 zero-copy buffers
Oct 29 22:23:00 raspberrypi dump1090-fa2[1749108]: cb transfer status: 1, canceling…
Oct 29 22:23:00 raspberrypi dump1090-fa2[1749108]: rtlsdr: rtlsdr_read_async returned unexpectedly, probably los>
Oct 29 22:23:00 raspberrypi dump1090-fa2[1749108]: Wed Oct 29 22:23:00 2025 CDT Waiting for receive thread term>
Oct 29 22:23:00 raspberrypi dump1090-fa2[1749108]: Wed Oct 29 22:23:00 2025 CDT Abnormal exit.
Oct 29 22:23:00 raspberrypi systemd[1]: dump1090-fa2.service: Main process exited, code=exited, status=1/FAILURE
Oct 29 22:23:00 raspberrypi systemd[1]: dump1090-fa2.service: Failed with result ‘exit-code’.
lines 1-15/15 (END)
It seems you have a problem with hardware used by dump1090-fa2.
It could be either dongle, or usb port or the usb cable between Pi and dongle or power supply unit (low voltage).
AI Overview
The “cb transfer status: 1” error on an RTL-SDR dongle is a generic USB error indicating a failure in data transfer, most often caused by insufficient power or a poor USB connection. Common solutions include plugging the dongle into a different USB port, using a powered USB hub, checking for corrosion on the dongle or port, and ensuring the device is receiving enough voltage from the host.
Thanks for the debug feedback. I have noticed intermittent results with rtl_test -t so I’ll need to replace the USB extension cable between the raspi and dongle.