Run sudo apt update and say yes when it asks you to confirm the Suite change.
Then retry the piaware upgrade.
(This is not a problem specific to PiAware; it’s a problem caused by an upstream change in Raspbian/Debian that affects all buster installs that didn’t get an update done between April-August. We put a workaround in place for PiAware sdcard installs, but we can’t do the same for installs from other images)
wheezy!
Far too old Time to re-image with Buster
I upgraded to Piaware 6.1 and reverted my piaware_config.txt file with the PPM switch and restarted both services. It’s all working! Thanks!
pi@piaware:~$ sudo systemctl status dump1090-fa -l
● dump1090-fa.service - dump1090 ADS-B receiver (FlightAware customization)
Loaded: loaded (/lib/systemd/system/dump1090-fa.service; enabled)
Active: active (running) since Thu 2021-09-09 01:00:10 PDT; 2s ago
Docs: https://flightaware.com/adsb/piaware/
Main PID: 9393 (dump1090-fa)
CGroup: /system.slice/dump1090-fa.service
└─9393 /usr/bin/dump1090-fa --quiet --device-type rtlsdr --device-index 0 --gain 29.7 --fix --lat 47.60504 --lon -122.12409 --max-range 360 --net-ro-port 30002 --net-sbs-port 30003 --net-bi-port 30004,30104 --net-bo-port 30005 --json-location-accuracy 2 --ppm 15 --write-json /run/dump1090-fa
Sep 09 01:00:10 piaware systemd[1]: Started dump1090 ADS-B receiver (FlightAware customization).
Sep 09 01:00:10 piaware dump1090-fa[9393]: Thu Sep 9 01:00:10 2021 PDT dump1090-fa 6.1~bpo8+1 starting up.
Sep 09 01:00:10 piaware dump1090-fa[9393]: rtlsdr: using device #0: Generic RTL2832U (Realtek, RTL2832U, SN 00001000)
Sep 09 01:00:11 piaware dump1090-fa[9393]: Found Rafael Micro R820T tuner
Sep 09 01:00:11 piaware dump1090-fa[9393]: rtlsdr: tuner gain set to 29.7 dB (gain step 16)
What frequency is the gain checked and changed?
This is mine on my second receiver (indoor with 5dBi Antenna):
Sep 10 05:09:30 Raspi3 dump1090-fa[18826]: adaptive: changing gain from 58.6dB (step 29) to 49.6dB (step 28) because: probing dynamic range gain lower bound
Sep 10 05:09:30 Raspi3 dump1090-fa[18826]: rtlsdr: tuner gain set to 49.6 dB (gain step 28)
Sep 10 05:09:40 Raspi3 dump1090-fa[18826]: adaptive: available dynamic range (37.1dB) >= required dynamic range (30.0dB), stopping downwards scan here
Sep 10 06:09:40 Raspi3 dump1090-fa[18826]: adaptive: start periodic scan for acceptable dynamic range at increased gain
Sep 10 06:09:40 Raspi3 dump1090-fa[18826]: adaptive: changing gain from 49.6dB (step 28) to 58.6dB (step 29) because: periodic re-probing of dynamic range ga
Sep 10 06:09:40 Raspi3 dump1090-fa[18826]: rtlsdr: tuner gain set to about 58.6 dB (gain step 29) (tuner AGC enabled)
Sep 10 06:09:50 Raspi3 dump1090-fa[18826]: adaptive: available dynamic range (26.6dB) < required dynamic range (30.0dB), switching to downward scan
Sep 10 06:09:50 Raspi3 dump1090-fa[18826]: adaptive: changing gain from 58.6dB (step 29) to 49.6dB (step 28) because: probing dynamic range gain lower bound
Sep 10 06:09:50 Raspi3 dump1090-fa[18826]: rtlsdr: tuner gain set to 49.6 dB (gain step 28)
Sep 10 06:10:00 Raspi3 dump1090-fa[18826]: adaptive: available dynamic range (37.1dB) >= required dynamic range (30.0dB), stopping downwards scan here
Dynamic range will probe once on startup and then re-probe once an hour, or immediately if the noise floor increases substantially. While probing it changes gain around once every 10 seconds.
Thank You. That fits to what can be seen in the logs
My RF knowledge is fairly limited, and the adaptive gain feature got me curious. What is the reason an AGC isn’t used in the piaware systems (or are they in the blue/orange sticks)? Could an AGC provide better performance (in terms of number of signals received) than the software autogain?
The hardware AGC is designed to work with a constant signal source, as would be the case with a radio station or TV station where there is a single transmitter and constant signal strength.
ADS-B is quite different in that it is the reception of many very short signals from disparate transmitters all at different ranges with different signal strengths. The hardware AGC can’t cope with that, so a software solution is needed.
Upgrade failed. Log includes followin lines:
[2021-09-11 14:14 CEST] *** running command ‘/usr/lib/piaware/helpers/run-apt-get update’ and logging output
[2021-09-11 14:14 CEST] manual update (user-initiated via their flightaware control page) requested by adept server
[2021-09-11 14:14 CEST] performing manual update, action: piaware
[2021-09-11 14:14 CEST] run-apt-get(28520): Get:3 Index of /raspbian buster InRelease [15.0 kB]
[2021-09-11 14:14 CEST] run-apt-get(28520): Get:1 Index of /repos/code/ stable InRelease [10.4 kB]
[2021-09-11 14:14 CEST] run-apt-get(28520): Hit:4 http://flightaware.com/adsb/piaware/files/packages buster InRelease
[2021-09-11 14:14 CEST] run-apt-get(28520): Get:5 Index of /repos/code/ stable/main arm64 Packages [46.4 kB]
[2021-09-11 14:14 CEST] run-apt-get(28520): Get:8 Index of /debian buster/main armhf Packages [393 kB]
[2021-09-11 14:14 CEST] run-apt-get(28520): Get:7 Index of /repos/code/ stable/main amd64 Packages [45.3 kB]
[2021-09-11 14:14 CEST] run-apt-get(28520): Get:6 Index of /repos/code/ stable/main armhf Packages [46.1 kB]
[2021-09-11 14:14 CEST] run-apt-get(28520): E: Repository ‘Index of /raspbian buster InRelease’ changed its ‘Suite’ value from ‘stable’ to ‘oldstable’
[2021-09-11 14:14 CEST] update request complete
[2021-09-11 14:14 CEST] child process 28520 exited with status EXIT 100
Who can help me our ?
BR - Guus
run the following commands
sudo apt update
sudo apt upgrade
Run the update again from the flightfeeder page.
It’s looking to an old directory in the depository.
The commands will update your installation and point to the current directory
Hi Tom,
Thanks, no luck yet. Update request complete, but also " [2021-09-11 15:50 CEST] skipping action piaware " in the log. Maybe clean install,would do you think?
2021-09-11 15:50 CEST] performing manual update, action: piaware
[2021-09-11 15:50 CEST] *** running command ‘/usr/lib/piaware/helpers/run-apt-get update’ and logging output
[2021-09-11 15:50 CEST] run-apt-get(27167): Hit:1 Index of /debian buster InRelease
[2021-09-11 15:50 CEST] run-apt-get(27167): Get:3 Index of /raspbian buster InRelease [15.0 kB]
[2021-09-11 15:50 CEST] run-apt-get(27167): Hit:4 http://flightaware.com/adsb/piaware/files/packages buster InRelease
[2021-09-11 15:50 CEST] run-apt-get(27167): Reading package lists…
[2021-09-11 15:50 CEST] update request complete
[2021-09-11 15:50 CEST] child process 27167 exited with status EXIT 100
[2021-09-11 15:50 CEST] skipping action piaware
[2021-09-11 15:51 CEST] 1677827 msgs recv’d from dump1090-fa (1017 in last 5m); 1677545 msgs sent to FlightAware
[2021-09-11 16:05 CEST] mlat-client(5147): Receiver: 384.3 msg/s received 66.3 msg/s processed (17%)
[2021-09-11 16:05 CEST] mlat-client(5147): Receiver status: connected
[2021-09-11 16:05 CEST] mlat-client(5147): Server: 0.2 kB/s from server 0.0kB/s TCP to server 0.7kB/s UDP to server
[2021-09-11 16:06 CEST] 1681006 msgs recv’d from dump1090-fa (1104 in last 5m); 1680724 msgs sent to FlightAware
I just installed PiAware 6.0 (as packages) on Raspian last weekend. I believe I had everything stable and stuck it up the loft on Thursday. I’d a day and half with it working well until I updated the packages (apt upgrade) to 6.1. After a reboot (I’d noticed the web interface was still showing 6.0), I’m not getting any messages.
Did I miss something by doing the apt upgrade?
I’m wondering if “no supported tuner found” is a clue (and why it’s not found when it was working fine!). It won’t have been physically disturbed. It’s a FlightAware Pro USB … I’ll pull it apart and replug it when I get home.
root@piaware:/home/baz# rtl_test -t
Found 1 device(s):
0: Realtek, RTL2832U, SN: 00001000
Using device 0: Generic RTL2832U
No supported tuner found
Enabled direct sampling mode, input 1
Supported gain values (1): 0.0
Sampling at 2048000 S/s.
No E4000 tuner found, aborting.
Check also the status of dump1090-fa using
sudo systemctl status dump1090-fe
and
sudo systemctl status piaware
Both should run. If one shows an error you can dig deeper in the logs.
Hi Guus,
Are you using the Piaware SD card image or the packages on top of Raspbian
If you use the Piaware image I would recommend to create a new image on a SD card and import your settings over by one of teh steps below
4 - Configure Station ID
Alternative-1:
Get a brand new station number & feeder id
Log-in to your Flightaware account, go to this page and follow instructions to claim a new station https://flightaware.com/adsb/piaware/claimAlternative-2:
Configure an Existing Station(a) - Find existing station’s feeder-id (Unique Identifier)
Log-in to your Flightaware account, go to “My ADSB” / stats page
flightaware.com/adsb/stats/user/ ,
and look for 32-digit Unique Identifier: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx(b) - SSH and configure station id:
sudo piaware-config feeder-id xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
sudo systemctl restart piaware
If you use the package installation you can so some addtional steps.
Checkout this excellent post bij abcd567 in performing a manual update/upgrade.
execute step 1,2 and 3.
These will reinstall the packages without overwriting your existing settings.
In step 2 allow the update your dump1090-fa config file in order to get the new functionality in the config.
After reboot you can edit the config file to enable adaptive gain by setting the parameter dynamic active range from no to yes
After the modification you need to restart dump1090-fa to activate the dynamic gain
sudo systemctl restart dump1090-fa is the command to do this.
The you can proceed with step 3 if you want to have Piawareweb installed/updated as well.
Yeah, this looks like a hardware problem.
Please run sudo apt update from a shell (ssh, or keyboard/monitor directly connected) and confirm the suite change when prompted. Then re-run the piaware upgrade. This is a problem with the base OS packages, not with piaware; you need to fix the base packages before the piaware upgrade will work.
Just to circle back on my issues. I checked all the connections and tried physically rebooting by removing the power cable, and the device was no longer visible on my network at all, but it appears to be booting fine (LED flashes). I’ve put the sd card into a different Pi (and old Pi2) with a wired connection and it works fine and the rtlsdr stick is detected.
So either my Pi Zero W has an issue with the wireless, or something in the update has broken the wireless setup on it. I don’t have a mini HDMI connector so I can see what the display is outputting. Are there any logs I can look at if I boot and pull the card?
/var/log/syslog would be your first point of call
There weren’t any changes to piaware sdcard wifi handling between 5.0 and 6.0.
Given your previous problems where the dongle wouldn’t even enumerate on the USB bus (but the dongle hardware is apparently OK) it could be a power or hardware issue with the Zero W itself.
Purchasing Zero W gives a saving of $20 in initial investment, but leads to many shortcomings and limitations for ADSB use.
In my opinion this saving is not worth it. For ADSB use, it is better to go for a regular board like Pi 3 or Pi 4
Thanks, got a replacement and it’s working fine (a dodgy receiver might explain some of the unreliable behaviour which I’d assumed was just a placement issue when setting it up and playing with it)