Dump1090-fa Version 11.0

FlightAware ADS-B Flight Tracking
1

It seems like something has changed in dump1090-fa version 11 compared to dump1090-fa version 10. I use the adaptive gain function in dump1090-fa, where I set a minimum gain of 20 dB and no maximum gain. It looks like adaptive gain works differently in version 11 of dump1090-fa.

What used to happen is, during the day the gain would adjust down to 20 dB and stay there and at night the gain would go up to about 35 dB. With the new version of dump1090-fa, the gain barely budges up at night (maybe up 5 dB). It’s at night when you probably have the longest range, so longest range is down with version 11 of dump1090-fa. Also, during the day aircraft count is down with version 11.

The comparison I do is between version 10.0.1 and version 11 of dump1090-fa. This is all on Debian Bookworm Rpi 4b. I swap out Rpi’s with the different version on the micro SD cards. (It’s easier than swapping SD cards). All other hardware is the same for the comparisons. I guess the Rpi themselves could be the difference, however that seems unlikely.

Anyone else see a problem like this?
TIA

2

There weren’t any changes to the adaptive gain logic between 10.2 and 11.0

There were some changes to the DSP infrastructure that adaptive gain uses, but the implementations should be identical (and there is benchmark/test code that tests that it’s operating as expected)

so what you’re seeing is hard to explain from a software perspective

Swapping the sdcards on the same hardware would be a better comparison, but it still suffers from the problem that traffic can vary a lot from day to day. The “gold standard” would be to have two parallel systems feeding off the same antenna, compare them, then swap sdcards and see if the problem follows the sdcard.

3 Likes
3

Ok, the version I was using for comparison was older (10.0.1).
I used that because it was backup that I had from a year ago. However I think version 10,2 worked the same way as 10.0.1.
Will do comparisons swapping SD cards.
Thanks.

4

One thing I noticed between dump1090-fa version 10.0.1 and version 11.0 is the DSP implementations used:

pi@raspberrypi:~ $ dump1090-fa --version
-----------------------------------------------------------------------------
| dump1090 ModeS Receiver                                dump1090-fa 10.0.1 |
| build options: ENABLE_RTLSDR ENABLE_BLADERF ENABLE_HACKRF ENABLE_LIMESDR  |
-----------------------------------------------------------------------------
  detected runtime CPU features:
  selected DSP implementations:
    magnitude_uc8                            neon_vrsqrte_armv8_neon_simd
    magnitude_uc8_aligned                    neon_vrsqrte_armv8_neon_simd
    magnitude_power_uc8                      neon_vrsqrte_armv8_neon_simd
    magnitude_power_uc8_aligned              neon_vrsqrte_armv8_neon_simd
    magnitude_sc16                           neon_vrsqrte_armv8_neon_simd
    magnitude_sc16_aligned                   neon_vrsqrte_armv8_neon_simd
    magnitude_sc16q11                        neon_vrsqrte_armv8_neon_simd
    magnitude_sc16q11_aligned                neon_vrsqrte_armv8_neon_simd
    mean_power_u16                           u32_armv8_neon_simd
    mean_power_u16_aligned                   u32_armv8_neon_simd
    count_above_u16                          generic_armv8_neon_simd
    count_above_u16_aligned                  generic_armv8_neon_simd_aligned

pi@raspberrypi:~ $ dump1090-fa --version
-----------------------------------------------------------------------------
| dump1090 ModeS Receiver                          dump1090-fa 11.0~bpo12+1 |
| build options: ENABLE_RTLSDR ENABLE_BLADERF ENABLE_HACKRF ENABLE_LIMESDR  |
-----------------------------------------------------------------------------
  detected runtime CPU features:
  selected DSP implementations:
    magnitude_uc8                            neon_vrsqrte_armv8_neon_simd
    magnitude_power_uc8                      neon_vrsqrte_armv8_neon_simd
    magnitude_sc16                           neon_vrsqrte_armv8_neon_simd
    magnitude_sc16q11                        neon_vrsqrte_armv8_neon_simd
    mean_power_u16                           u32_armv8_neon_simd
    count_above_u16                          generic_armv8_neon_simd

Apparently, the _aligned versions are more efficient. Not sure how this affects performance, if it does.

5

This is the DSP infrastructure change I mentioned. All the implementations are meant to provide identical results, just some will take less CPU doing it. They should not affect the receiver behaviour since they’re meant to produce identical results.

(The aligned versions were fractionally faster sometimes - single digit percent difference - but added a lot of complexity; the more recent infrastructure dropped support for them in favor of simpler code)

You can run the self-check for the DSP implementations by running:

/usr/lib/dump1090-fa/starch-benchmark -V

(it should say “validation OK” for all implementations)

1 Like
6

It does on version 11.0.

1 Like
7

Hi,

I think I may be seeing the same thing, I’ve just recently updated my receiver to Trixie and done a fresh install of everything and found the auto gain now hardly moves where as previously it was quite mobile.

I’m running a Pi2B with obviously 32bit Trixie.

I updated on the evening of the 18th, you can clearly see the difference here, my number of messages seems to have dropped off as well.

The hardware is totally unchanged, only the SD card has been swapped out.

I did create wisdom files, but they didn’t seem to make much difference…

Any ideas ? Thinking of going back to Bookworm for now…

dump1090-localhost-misc-7d
dump1090-localhost-misc-7d619Ă—324 13.5 KB

8

interesting, in your case the gain stays high all the time. Different than my case, where the gain would not adjust upwards much at night. Lets just say, for what ever reason, gain adjustment in version 11.0 of dump1090-fa is different than it was before. Whether there is more or less traffic detected is difficult to say,

I am now on Trixie with version 11.0 of dump1090-fa and traffic looks normal. Here is how gain adjustment looks now. It doesn’t adjust quite as high during the night as it used to on version 10 of dump1090-fa

Screenshot 2026-06-20 at 11.49.03 AM
Screenshot 2026-06-20 at 11.49.03 AM1238Ă—648 50.4 KB

9

@MartinColeman
@jimMerk2

Screenshot_20260620_153327_Termux
Screenshot_20260620_153327_Termux1029Ă—1012 218 KB

 


pi@rpios-trixie:~ $ apt-cache policy dump1090-fa | grep Installed
  Installed: 11.0
pi@rpios-trixie:~ $
pi@rpios-trixie:~ $ sudo journalctl -u dump1090-fa | grep "gain set to"
Jun 20 13:12:59 rpios-trixie dump1090-fa[191278]: rtlsdr: tuner gain set to about 58.6 dB (gain step 29) (tuner AGC enabled)
Jun 20 13:13:09 rpios-trixie dump1090-fa[191278]: rtlsdr: tuner gain set to 49.6 dB (gain step 28)
Jun 20 14:13:19 rpios-trixie dump1090-fa[191278]: rtlsdr: tuner gain set to about 58.6 dB (gain step 29) (tuner AGC enabled)
Jun 20 14:13:29 rpios-trixie dump1090-fa[191278]: rtlsdr: tuner gain set to 49.6 dB (gain step 28)
Jun 20 15:13:39 rpios-trixie dump1090-fa[191278]: rtlsdr: tuner gain set to about 58.6 dB (gain step 29) (tuner AGC enabled)
Jun 20 15:13:49 rpios-trixie dump1090-fa[191278]: rtlsdr: tuner gain set to 49.6 dB (gain step 28)
pi@rpios-trixie:~ $

 

dump1090-localhost-misc-24h
dump1090-localhost-misc-24h619Ă—324 11.6 KB

 

10

So, you don’t have an LNA in that setup?
Else gain would adjust down from 49.6 dB.

11

It is Flightaware ProStick (Orange), which has a built-in LNA.

 

Screenshot_20260620_171904_Samsung Browser
Screenshot_20260620_171904_Samsung Browser1080Ă—2108 438 KB

12

It might be worth building 10.2 against trixie and seeing if that changes anything. It’s possible there’s a change elsewhere in the system (e.g. in librtlsdr, or maybe a latent bug that gets tickled only with a particular compiler) that’s causing it

give me a few days and I can build a .deb for testing this

edit: rereading the original post, though, @jimMerk2 also saw this on 11.0 on bookworm? Was this specifically the 11.0~bpo12+1 package? (edit^2: I see the version in some output above, yes it was)

13

@abcd567
From the graph, it looks like gain never reduces below 49.6 dB.
Kinda suggests you don’t have enough available gain does it not?

@obj
Running on Trixie now with version 11.0 of dump1090-fa. It looks like there’s only a little difference in gain adjustment from what it previously did on version 10.0. I really can’t tell if received traffic is better or worse now than with version 10.0. So, may be a non issue.

Edit for @abcd567, I see now that gain does make excursions up to 58.6 dB. However, the excursions are so short in duration they don’t show up on the graph. Also apparently there is no difference between day and night as far as gain is concerned. Is that the way it has always worked? If so, why not just set a fixed gain of around 49 dB ?

14

Gain of dongle is not low because it is Flightaware Prostick (orange) with built-in LNA. However gain of antenna is low, about 2.5 ~ 3 dBi, but again there is negligible attenuation in coax between antenna and dongle due to it’s short length (1 meter), but there is about 2 dB insertion loss of SAW filter from Aliexpress ($9).

 

20260621_031653
20260621_0316531920Ă—2560 539 KB

 

15

Hi,

Thanks for looking into this…

Just in case its relevant, I have a Flightaware ProStick Plus, the blue one and a PCB Dipole mounted outside on a wall…

You can see the messages have dropped off a bit my number of aircraft tracked though seems to be holding it’s own.

If you need any other info just shout, being a noob I can only post 1 image at a time…

I’m going to drop back to the Bookworm SD for not but will keep the Trixie one hand for any testing..

Thanks again guys…

dump1090-localhost-aircraft_message_rate-7d
dump1090-localhost-aircraft_message_rate-7d619Ă—324 22.9 KB

16

Hi,

So just swapped over to the Bookworm SD, for some reason I thought I was running version 10.2 on that but I am on 11…

martin@dump1090:~ $ apt-cache policy dump1090-fa | grep Installed
  Installed: 11.0~bpo12+1

Straight away AG kicks in, I’ll keep an eye on what happens to the message rate when it gets busy.

dump1090-localhost-misc-2h
dump1090-localhost-misc-2h619Ă—324 10.9 KB

17

You mean this 2dBi one?

1090 mhz pcb dipole 2 dBi
1090 mhz pcb dipole 2 dBi117Ă—1000 19.6 KB

18

Hi,

Yea one of those, got some heat shrink over it and it’s stuck to the wall with some silicone next to a window. The lead comes in through window with the prostick mounted on the window frame…

Not ideal but the best I could do without going mad with cabling…

19

Hi,

Sorry for spamming the thread, however…

I was trying to create a wisdom file just now and found I was getting this error, could it be related to the DSP stuff being changed ?

martin@Dump-1090-T:~ $ /usr/share/dump1090-fa/generate-wisdom
Benchmarking .. this will take a while.
First pass: generating /tmp/wisdom.xaxrv7/wisdom.initial
==== magnitude_uc8 ===
  neon_vrsqrte_armv7a_neon_vfpv4            283910 ns/call
  lookup_unroll_4_generic                   706829 ns/call
  lookup_armv7a_neon_vfpv4                  1098968 ns/call
  lookup_unroll_4_armv7a_neon_vfpv4         895759 ns/call
  exact_armv7a_neon_vfpv4                   2565251 ns/call
  lookup_generic                            1097665 ns/call
  exact_generic                             3396469 ns/call
/usr/lib/dump1090-fa/starch-benchmark: unrecognized function name: magnitude_uc8_aligned

martin@Dump-1090-T:~ $ apt-cache policy dump1090-fa | grep Installed
  Installed: 11.0

This is on a fresh install of 32bit Trixie on a Pi 2B…

20

This has me scratching my head a bit. I did find some leftover alignment code in the repository, but (a) it’s never compiled AFAIK and (b) it would be 64-bit only.

Was this with the FlightAware-built dump1090-fa package?

edit: oh! this is a bug in generate-wisdom, not the actual benchmark binary. It’s “harmless” (in the sense that it doesn’t affect dump1090-fa itself, though obviously generate-wisdom itself is broken for the moment)

For now, if you want to generate a wisdom file, edit generate-wisdom and remove the references to magnitude_uc8_aligned and mean_power_u16_aligned