I had upgraded to Version 6.1 a week or so ago and things were going fine. However, I never saw any adaptive gain changes in my graphs. Mine is a Raspian installation so I know I had to edit the piaware.conf and/or the Dump1090-fa files manually. Well, I did and no change to the gain. The problem though was last night when I did a sudo apt update of the Pi. Everything went fine, except the range dropped enormously. Something happened to the signal level… is that part of the adaptive gain?
Any thoughts on what I can check or modify (or what was modified)?
Maybe post your piaware.conf config (without private key or lat/lon details) and dump1090-fa config in code quotes </>. See if anyone can spot anything.
Edit: Looking at your FA stats page, your UAT stats also look down. Is that just bad weather? Do you have the receiver serialization set correctly in piaware.conf? e.g. mixed 1090 and 978 receivers/antennas by accident? Or wet coax? The signal graph kinda looks like autogain could be trying to compensate for weak signa. Like when water gets in the connectors.
Should see in piaware.conf uat-sdr-device driver=rtlsdr,serial=00000978
# dump1090-fa configuration
# This is sourced by /usr/share/dump1090-fa/start-dump1090-fa as a
# shellscript fragment.
# dump1090-fa won't automatically start unless ENABLED=yes
ENABLED=yes
# SDR device type. Use "none" for a net-only configuration
RECEIVER=rtlsdr
# serial number or device index of device to use (only needed if there is more than one SDR connected)
RECEIVER_SERIAL=
# Initial receiver gain, in dB. If adaptive gain is enabled (see below) the actual gain
# may change over time
RECEIVER_GAIN=60
# Adjust gain to try to achieve optimal dynamic range / noise floor?
ADAPTIVE_DYNAMIC_RANGE=yes
# Target dynamic range in dB (leave blank to autoselect based on SDR type)
ADAPTIVE_DYNAMIC_RANGE_TARGET=
# Reduce gain when loud message bursts from nearby aircraft are seen?
ADAPTIVE_BURST=no
# Gain range to allow when changing gain, in dB (empty = no limit)
ADAPTIVE_MIN_GAIN=
ADAPTIVE_MAX_GAIN=
# Turn on options to reduce load on slower CPUs, at the expense of slightly worse decoder performance.
# Setting "auto" will enable these options only if the CPU appears to be a slow CPU (currently this
# means armv6 only, e.g. Pi Zero)
SLOW_CPU=auto
# Local wisdom file used to select DSP implementations; uses built-in ranking if the file is missing
WISDOM=/etc/dump1090-fa/wisdom.local
# Correct CRC errors where possible
ERROR_CORRECTION=yes
# Receiver location, used for some types of position decoding. Provide the location as
# signed decimal degrees. If not given here, dump1090 will also try to read a receiver
# location from /var/cache/piaware/location.env (written automatically by PiAware, if installed)
RECEIVER_LAT=
RECEIVER_LON=
# Maximum range, in NM. Positions more distant than this are ignored. No limit if not set.
MAX_RANGE=360
# Network ports to listen on for connections
NET_RAW_INPUT_PORTS=
NET_RAW_OUTPUT_PORTS=30002
NET_SBS_OUTPUT_PORTS=30003
NET_BEAST_INPUT_PORTS=30004,30104
NET_BEAST_OUTPUT_PORTS=30005
# Accuracy of location written to JSON output
JSON_LOCATION_ACCURACY=1
# Additional options can be added here:
EXTRA_OPTIONS=""
# If OVERRIDE_OPTIONS is set, only those options are used; all other options
# in this config file are ignored.
OVERRIDE_OPTIONS=""
# This is a marker to make it easier for scripts to identify a v6-style config file
CONFIG_STYLE=6```
Ok - thanks for mentioning the serials… I looked closer at dump1090 and I don’t know if this was overwritten in the update last night, but:
# serial number or device index of device to use (only needed if there is more than one SDR connected)
RECEIVER_SERIAL=
… must have been looking for a the dongle serial. I filled it in and my range is back. It must have been trying to use the wrong antenna…
Which brings up another issue now - you’re right. I haven’t had any 978 data since the update last night. I didn’t notice that. I usually only see 1 or 2 airplanes at a given time and it was crappy weather today, but the confidence of ZERO traffic is too much. Is there something in Dump978 that I can add? The file looks like this:
There was no serial number specified in dump1090-fa config file. Due to lack of any serial number, dump1090-fa by default grabbed dongle device index 0 which has serial 0000978. This brought down its performance due to wrong antenna. Also, due to dump1090 using dongle 00000978, the dump978 could not use dongle serial 0000978 specified in its config, so it failed.
You can confirm this by following command:
rtl_test -t
Check device 0 has what serial number. Most likely it will have 00000978.
I’ll look. I can say everything worked as it did pre 6.x until I did a sudo apt update yesterday. I’ve been running 6.x since it came out without problems.
It appears the serial was not incorporated in the file, but it WAS working fine for months.
# dump1090-fa configuration
# This is sourced by /usr/share/dump1090-fa/start-dump1090-fa as a
# shellscript fragment.
# dump1090-fa won't automatically start unless ENABLED=yes
ENABLED=yes
# SDR device type. Use "none" for a net-only configuration
RECEIVER=rtlsdr
# serial number or device index of device to use (only needed if there is more than one SDR connected)
RECEIVER_SERIAL=
# Initial receiver gain, in dB. If adaptive gain is enabled (see below) the actual gain
# may change over time
RECEIVER_GAIN=60
# Adjust gain to try to achieve optimal dynamic range / noise floor?
ADAPTIVE_DYNAMIC_RANGE=yes
# Target dynamic range in dB (leave blank to autoselect based on SDR type)
ADAPTIVE_DYNAMIC_RANGE_TARGET=
# Reduce gain when loud message bursts from nearby aircraft are seen?
ADAPTIVE_BURST=no
# Gain range to allow when changing gain, in dB (empty = no limit)
ADAPTIVE_MIN_GAIN=
ADAPTIVE_MAX_GAIN=
# Turn on options to reduce load on slower CPUs, at the expense of slightly worse decoder performance.
# Setting "auto" will enable these options only if the CPU appears to be a slow CPU (currently this
# means armv6 only, e.g. Pi Zero)
SLOW_CPU=auto
# Local wisdom file used to select DSP implementations; uses built-in ranking if the file is missing
WISDOM=/etc/dump1090-fa/wisdom.local
# Correct CRC errors where possible
ERROR_CORRECTION=yes
# Receiver location, used for some types of position decoding. Provide the location as
# signed decimal degrees. If not given here, dump1090 will also try to read a receiver
# location from /var/cache/piaware/location.env (written automatically by PiAware, if installed)
RECEIVER_LAT=
RECEIVER_LON=
# Maximum range, in NM. Positions more distant than this are ignored. No limit if not set.
MAX_RANGE=360
# Network ports to listen on for connections
NET_RAW_INPUT_PORTS=
NET_RAW_OUTPUT_PORTS=30002
NET_SBS_OUTPUT_PORTS=30003
NET_BEAST_INPUT_PORTS=30004,30104
NET_BEAST_OUTPUT_PORTS=30005
# Accuracy of location written to JSON output
JSON_LOCATION_ACCURACY=1
# Additional options can be added here:
EXTRA_OPTIONS=""
# If OVERRIDE_OPTIONS is set, only those options are used; all other options
# in this config file are ignored.
OVERRIDE_OPTIONS=""
# This is a marker to make it easier for scripts to identify a v6-style config file
CONFIG_STYLE=6
For package piware install, pretty sure serial is in /etc/piaware.conf. Here’s mine (1090 serial commented out because I’m using airspy, net only mode)
#rtlsdr-device-index 00001090 # updated by fa_piaware_config
uat-sdr-device driver=rtlsdr,serial=00000978 # updated by fa_piaware_config
Yup… the 978 dongle was device 0. That makes sense now. I AM getting 978 traffic again - there are just so few 978 aircraft out there, there were none in the hours since I made the dump1090-fa modifications with the correct serial number. I have a whopping THREE hits since I made the change - but this is normal as I usually don’t see more than 20-50 per day.
It is necessary to have serial in file /etc/default/dump1090-fa,
but it does not make any difference if serial is or isn’t in piaware.conf.
For piaware SDCard image:
It is necessary to have serial in piaware.conf,
but it does not matter whether or not you enter serial in file /etc/default/dump1090-fa as this file is overwritten at every boot / reboot by reading settings from piaware.conf.
It looks like you either had an unmodified-from-default config file before the upgrade, or you told apt to replace your config file with the default during the upgrade.
your old config file had the serial number correctly configured;
you upgraded from the command line;
apt asked whether you wanted to keep your old config file or install the package-provided new version, you said to use the new version. This overwrote your customized config and your serial number change was lost. (apt backs up the old config file to the dpkg-old file above before replacing it)
the config-file upgrade process ran, saw that the current config file was already in v6 format, and just changed adaptive gain to no, leaving the rest intact. (The config-upgrade process backs up the config file to the pre-v6-upgrade file before making changes)
FWIW if you had triggered the upgrade via piaware / the stats page, then it runs the upgrade with options that tell apt to keep the existing config file when that “which config file do you want?” question would usually be asked.
That sounds exactly right. I remember that prompt “yes/no” which I hadn’t encountered before. No doubt I answered “yes”. Historically, I’ve used the Pi for other projects and done the apt update/upgrade process so I didn’t think much of it. It’s dedicated to just flightaware now so I’ll stick to the stats page updates! Thanks.
From my outputs above, I assume Adaptive Gain is enabled. I’m not sure how much good it’ll do me since my install is in my attic, but in case I move the antenna outside I wanted to have it configured as such.
I think I have the similar problem after mixing upgrade paths from 5.0 to 6.0 then 6.1 while also trying to add a 978 radio and antenna and hitting a power problem with my Pi3B+ with active cooling heatsink. Not enough power at startup I think.
What’s the best way to create a new set of config files for SD card install then copy specific entries like network settings, feeder-id, etc?
