Adaptive gain issues

As recommended by FA, I am creating this thread to tackle an issue whilst using adaptive gain. I have set up as per ABCD’s thread [Piaware ver 6 with Adaptive Gain Control - Install it on x86_64 Machines with Ubuntu 20, Debian 10 &11, and on RPi 2, 3, 4 with Raspbian Buster (32-bit and 64-bit)].

I am running this setup on a N2+, with Ubuntu armbian (bullseye centred) OS, using a FA Pro Stick, coming off a Uptronics LNA and cavity filter. Initially looking at the graphs for this unit, I noted there were a large amount of tracks with single message:

This morning, I think the gain got so low over night with no traffic, that when we started to get some flights, it may of not been able to set higher. I have got no data thought to check that theory but, the airspy unit was merrily showing planes but the FA pro stick was blank. I had to sudo re boot to get it going and then it was recording as per the airspy unit. Not showing that high rate of loud uudecoded message or low message rate and gain dynamic range limit yet. and gain has settled at 30.0 db so far. A short time after it started producing similar status messages as below.

From a status check, the following “error messages” are noted :astonished:
Sep 28 15:05:23 odroid dump1090-fa[2566]: adaptive: changing gain from 19.7dB (step 11) to 16.6dB (step 10) because: high rate of loud undecoded messages
Sep 28 15:05:23 odroid dump1090-fa[2566]: rtlsdr: tuner gain set to 16.6 dB (gain step 10)
Sep 28 15:06:51 odroid dump1090-fa[2566]: adaptive: changing gain from 16.6dB (step 10) to 15.7dB (step 9) because: high rate of loud undecoded messages
Sep 28 15:06:51 odroid dump1090-fa[2566]: rtlsdr: tuner gain set to 15.7 dB (gain step 9)
Sep 28 15:07:12 odroid dump1090-fa[2566]: adaptive: changing gain from 15.7dB (step 9) to 16.6dB (step 10) because: low loud message rate and gain below dynamic range limit
Sep 28 15:07:12 odroid dump1090-fa[2566]: rtlsdr: tuner gain set to 16.6 dB (gain step 10)
Sep 28 15:07:31 odroid dump1090-fa[2566]: adaptive: changing gain from 16.6dB (step 10) to 19.7dB (step 11) because: low loud message rate and gain below dynamic range limit
Sep 28 15:07:31 odroid dump1090-fa[2566]: rtlsdr: tuner gain set to 19.7 dB (gain step 11)
Sep 28 15:08:08 odroid dump1090-fa[2566]: adaptive: changing gain from 19.7dB (step 11) to 20.7dB (step 12) because: low loud message rate and gain below dynamic range limit
Sep 28 15:08:08 odroid dump1090-fa[2566]: rtlsdr: tuner gain set to 20.7 dB (gain step 12)

and:

odroid dump1090-fa[2566]: adaptive: changing gain from 15.7dB (step 9) to 16.6dB (step 10) because: low loud message rate and gain below dynamic range limit

I am sure the ADSB tracks data should not have that large amount of tracks with single message and not sure what the dynamic range limit is.

Any suggestions, I am about to go up to my enclosure and take off the Uptronic amp (previously noted that sometimes too much extra amplification with the FA Pro stick can cause some issues) and will advise that outcome.

Looks like you strongly need a filter.

Any other networks around you on a similar frequency? Typically it’s mobile phone networks (GSM)

Before spending money for the expensive Uputronics stuff, you can try it first with the dark blue Flightaware filter between antenna and stick.

I’ve used the Uputronics also in front of the FA pro plus stick and it does not cause trouble.

I do have a 4G mobile phone tower 160m’s away. Thus the cavity filter, when fitted, appeared to suppress a lot of that mobile phone tower issue. I have another N2+ running of an airspy with 2.2 RC24 installed with zero single message tracks. I have an FA filter, would you add that as well to the cavity filter??

I have removed the uptronics, same result:

Sep 28 15:45:51 odroid dump1090-fa[2558]: adaptive: changing gain from 33.8dB (step 18) to 36.4dB (step 19) because: low loud message rate and gain below dynamic range limit
Sep 28 15:45:51 odroid dump1090-fa[2558]: rtlsdr: tuner gain set to 36.4 dB (gain step 19)
Sep 28 15:56:11 odroid dump1090-fa[2558]: adaptive: changing gain from 36.4dB (step 19) to 33.8dB (step 18) because: high rate of loud undecoded messages
Sep 28 15:56:11 odroid dump1090-fa[2558]: rtlsdr: tuner gain set to 33.8 dB (gain step 18)
Sep 28 15:56:25 odroid dump1090-fa[2558]: adaptive: changing gain from 33.8dB (step 18) to 32.8dB (step 17) because: high rate of loud undecoded messages
Sep 28 15:56:25 odroid dump1090-fa[2558]: rtlsdr: tuner gain set to 32.8 dB (gain step 17)
Sep 28 15:56:41 odroid dump1090-fa[2558]: adaptive: changing gain from 32.8dB (step 17) to 33.8dB (step 18) because: low loud message rate and gain below dynamic range limit
Sep 28 15:56:41 odroid dump1090-fa[2558]: rtlsdr: tuner gain set to 33.8 dB (gain step 18)
Sep 28 15:57:01 odroid dump1090-fa[2558]: adaptive: changing gain from 33.8dB (step 18) to 36.4dB (step 19) because: low loud message rate and gain below dynamic range limit
Sep 28 15:57:01 odroid dump1090-fa[2558]: rtlsdr: tuner gain set to 36.4 dB (gain step 19)

So I don’t think it is over amplification causing the problem??

There’s no “correct” value here. That data is thrown away anyway in later filtering stages. It’s mostly interesting as a proxy for undetected bit error rate.

This is the maximum gain previously determined by adaptive dynamic range mode. Burst mode will increase gain back to that point when the loud messages go away.

What’s the previous fixed gain that you found worked well with this setup?

Oooooh puts on thinking cap. I know the top gain for this is 60 db. When last used FA prostick’s, such gains were un thinkable. Was the highest gain in those days 49??

The previous default was effectively 60-ish (previously called “-10”). The maximum “regular” gain is 49.

But I’d be surprised if you were previously using a gain of 49 with a prostick and a pre-amp, usually that’s way too much amplification.

1 Like

No wasn’t using that much. Will have to look at some old files. Just found an error though:

Detected Kernel usbfs mmap() bug, falling back to buffers in userspace

Can you get a working install with a fixed gain on the same hardware & OS sorted out first, work out what the gain should be for your setup, and then we can revisit adaptive gain.

Like the FA sd card version or the PiAware repository package??

No, I mean, you have built for a N2+ on Ubuntu armbian bullseye, apparently. Get that build working with a fixed gain first, then we can talk about adaptive gain. There’s not much point in trying to diagnose anything until we know that the non-adaptive gain case works OK.

1 Like

Ok, I have done that already, just going through some different gains now

Just while I am checking gains, you might be able to look into this error that keeps on coming up:

Detected Kernel usbfs mmap() bug, falling back to buffers in userspace

It’s a workaround for an arm-specific kernel bug. The kernel bug was fixed long ago, though, so I don’t entirely trust your system, which is why I’d like to confirm it works with a fixed gain first.

Well working on a fixed gain, 15 with following status:

root@odroid:~# sudo systemctl status dump1090-fa
● dump1090-fa.service - dump1090 ADS-B receiver (FlightAware customization)
** Loaded: loaded (/lib/systemd/system/dump1090-fa.service; enabled; vendor p>**
** Active: active (running) since Wed 2021-09-29 00:28:33 AEST; 1min 56s ago**
** Docs: PiAware - ADS-B and MLAT Receiver - FlightAware**
** Main PID: 2562 (dump1090-fa)**
** Tasks: 3 (limit: 3832)**
** Memory: 5.2M**
** CGroup: /system.slice/dump1090-fa.service**
** └─2562 /usr/bin/dump1090-fa --quiet --device-type rtlsdr --gain 15>**

Sep 29 00:28:33 odroid systemd[1]: Started dump1090 ADS-B receiver (FlightAware>
Sep 29 00:28:33 odroid dump1090-fa[2562]: Wed Sep 29 00:28:33 2021 AEST dump10>
Sep 29 00:28:33 odroid dump1090-fa[2562]: rtlsdr: using device #0: Generic RTL2>
Sep 29 00:28:33 odroid dump1090-fa[2562]: Detached kernel driver
Sep 29 00:28:33 odroid dump1090-fa[2562]: Found Rafael Micro R820T tuner
Sep 29 00:28:34 odroid dump1090-fa[2562]: rtlsdr: tuner gain set to 14.4 dB (ga>
Sep 29 00:28:34 odroid dump1090-fa[2562]: Allocating 4 zero-copy buffers
Sep 29 00:28:34 odroid dump1090-fa[2562]: Detected Kernel usbfs mmap() bug, fal>
lines 1-18/18 (END)
● dump1090-fa.service - dump1090 ADS-B receiver (FlightAware customization)
** Loaded: loaded (/lib/systemd/system/dump1090-fa.service; enabled; vendor preset: enabled)**
** Active: active (running) since Wed 2021-09-29 00:28:33 AEST; 1min 56s ago**
** Docs: PiAware - ADS-B and MLAT Receiver - FlightAware**
** Main PID: 2562 (dump1090-fa)**
** Tasks: 3 (limit: 3832)**
** Memory: 5.2M**
** CGroup: /system.slice/dump1090-fa.service**
** └─2562 /usr/bin/dump1090-fa --quiet --device-type rtlsdr --gain 15 --fix --lat -31.11002 --lon 150.89938 --max-ran>**

Sep 29 00:28:33 odroid systemd[1]: Started dump1090 ADS-B receiver (FlightAware customization).
Sep 29 00:28:33 odroid dump1090-fa[2562]: Wed Sep 29 00:28:33 2021 AEST dump1090-fa 6.1 starting up.
Sep 29 00:28:33 odroid dump1090-fa[2562]: rtlsdr: using device #0: Generic RTL2832U (Realtek, RTL2832U, SN 00001000)
Sep 29 00:28:33 odroid dump1090-fa[2562]: Detached kernel driver
Sep 29 00:28:33 odroid dump1090-fa[2562]: Found Rafael Micro R820T tuner
Sep 29 00:28:34 odroid dump1090-fa[2562]: rtlsdr: tuner gain set to 14.4 dB (gain step 8)
Sep 29 00:28:34 odroid dump1090-fa[2562]: Allocating 4 zero-copy buffers
Sep 29 00:28:34 odroid dump1090-fa[2562]: Detected Kernel usbfs mmap() bug, falling back to buffers in userspace

We are now in our curfew after 00:01, so no more RTP’s may be the odd freighter for a few hours.

Ok. As you think it might be a system problem, I have set up another N2+, using Armbian bullseye for odroid n2 and installed the ABCD’s adaptive gain script, graphs etc. So far, the status report looks better, that Detected Kernel usbfs mmap() bug, falling back to buffers in userspace has disappeared and the adaptive process seems to be working:

root@odroidn2:~# sudo systemctl status dump1090-fa
● dump1090-fa.service - dump1090 ADS-B receiver (FlightAware customization)
** Loaded: loaded (/lib/systemd/system/dump1090-fa.service; enabled; vendor preset: enabled)**
** Active: active (running) since Wed 2021-09-29 01:40:40 AEST; 7min ago**
** Docs: PiAware - ADS-B and MLAT Receiver - FlightAware**
** Main PID: 2592 (dump1090-fa)**
** Tasks: 3 (limit: 3340)**
** Memory: 7.6M**
** CPU: 56.843s**
** CGroup: /system.slice/dump1090-fa.service**
** └─2592 /usr/bin/dump1090-fa --quiet --device-type rtlsdr --gain 60 --adaptive-range --adaptive-burst --fix --lat -31.11002 --lon 150.89938 --max-range 360 --net-ro-port 30002 --net-sbs-port 30003 --net-bi-port>**

Sep 29 01:42:00 odroidn2 dump1090-fa[2592]: adaptive: available dynamic range (27.1dB) < required dynamic range (30.0dB), continuing downwards scan
Sep 29 01:42:00 odroidn2 dump1090-fa[2592]: adaptive: changing gain from 40.2dB (step 22) to 38.6dB (step 21) because: probing dynamic range gain lower bound
Sep 29 01:42:00 odroidn2 dump1090-fa[2592]: rtlsdr: tuner gain set to 38.6 dB (gain step 21)
Sep 29 01:42:10 odroidn2 dump1090-fa[2592]: adaptive: available dynamic range (28.5dB) < required dynamic range (30.0dB), continuing downwards scan
Sep 29 01:42:10 odroidn2 dump1090-fa[2592]: adaptive: changing gain from 38.6dB (step 21) to 37.2dB (step 20) because: probing dynamic range gain lower bound
Sep 29 01:42:10 odroidn2 dump1090-fa[2592]: rtlsdr: tuner gain set to 37.2 dB (gain step 20)
Sep 29 01:42:20 odroidn2 dump1090-fa[2592]: adaptive: available dynamic range (28.9dB) < required dynamic range (30.0dB), continuing downwards scan
Sep 29 01:42:20 odroidn2 dump1090-fa[2592]: adaptive: changing gain from 37.2dB (step 20) to 36.4dB (step 19) because: probing dynamic range gain lower bound
Sep 29 01:42:20 odroidn2 dump1090-fa[2592]: rtlsdr: tuner gain set to 36.4 dB (gain step 19)
Sep 29 01:42:30 odroidn2 dump1090-fa[2592]: adaptive: available dynamic range (30.6dB) >= required dynamic range (30.0dB), stopping downwards scan here

Morning time and that kernel error, as far as I can look back, still has not re appeared, so the OS switch has solved that I hope.

EDIT 9 hours later. Many thanks to wiedehopf for creating a gain graph for adaptive gain, an easier way tracking gain changes. The kernel issue has definitely not reappeared on 2 units now with Armbian Bullseye. And I believe my sweet spot is in the vicinity of 30db.

As mentioned above, yes working with fixed gain and makes the changes as you change that fixed gain level. So current problem is how to overcome this high rate of uncoded messages;

Sep 29 17:31:53 odroidn2 dump1090-fa[129632]: adaptive: changing gain from 33.8dB (step 18) to 32.8dB (step 17) because: high rate of loud un decoded messages

and:

An image for the adaptive gain at work. It is only a 30 minute take and I will post it later with a few hours in it.

So if any one has an idea of reducing these loud un decoded messages, put ion your 2c. Just thought of an interesting fact, I have 2 units running this adaptive gain, one up on the mast, with a cavity filter in front of it and one in my office just with the Uptronic amp, no filter. Both still have the similar amount of tracks with single message graphs in the ADS-B Tracks Seen (8 minute exp. moving avg.) graphs.

Are you complaining about the log messages?

Or do you think it’s actually chosing the wrong gain?

What do you think is the optimal gain?