Another gain question

Just wondering as I have been running a feeder for 3 years (as of today actually) and never paid much attention as the stats on flightaware always seemed reasonable. Was having an issue with an older pi and swapped it for a 3B+ and changed from dump1090-mutability ‘MAX’ gain to dump1090-fa '48db gain - Nothing else changed (same dongle, filter and antenna) but seeing about 30% less distance and messages seem to be down as well - Ran the gain scripts and nothing conclusive about best settings found. I hope someone with the proper knowledge could look at this signal graph and let me know if it seems reasonable… Much appreciated. - Bob


MAX gain is actually 49.6 not 48.

Also looking at the signal -10 (AGC) will probably provide best results for you.

So set gain to -10 and after an hour or so post your
(replace ADDRESS with address of your raspi)

That file has more information than just the signal graph :wink:
Posting the last about 10 lines starting with “total” will be sufficient.

It would look like this:


1 Like

Thanks for the quick reply - made the change and will post as you suggest in about 40 minutes which will be an hour total - I should know better then make too many changes at once, as I even notice seemingly benign changes (neatening excess coax cable for instance) seems to have an impact!

Here is the output - I added the (1 hr) graph just for reference. I should mention that my physical location is equidistance between Philadelphia, PA and Newark, NJ and puts me close to flight paths (about 8k feet / 8 to 10 nautical miles) for flights landing at Newark, Kennedy and La Guardia so have quite a few heavy signals.



Let me know what you think and much appreciated. Bob

The signal in the graph is now a bit too strong for my taste but it will likely provide best reception at long distances.
The drawback is that you may lose some planes flying low and close to you.
If you notice that on the local map and don’t like it switch to 49.6

Let’s check messages stronger than -3dB (the graph logs them wrong so using the numbers from the stats.json is the only way to check that. or you can get my updated graph version but that’s not really necessary)


So that’s a whopping 13 percent. That’s quite a lot.

You probably want to set gain at 49.6.
But let it run like this for a while so you have a good reference for testing 49.6 tomorrow.

Also i think you have turned off error correction (CRC).
That can get you some extra messages.
In the config file /etc/default/dump1090-fa check if there is the option --fix or --no-fix present.
If you want the error correction it should read --fix somewhere among the other command line options listed there.

Can i also share mine to the thread im using old graphs @ 1 hr
gain set @ 36.4

Bit concerned about the Bad figure

regards john

Much appreciated - No --fix in my default file (latest v3.6.3) so added it under receiver options after doing a bit of googling it looks like it belongs there… It restarted OK without any errors in the piaware.log file. Here is the whole config file minus the remarks with the new addition…

RECEIVER_OPTIONS=“–device-index 0 --ppm 0 --fix --gain -10 --net-bo-port 30005 --net-sbs-port 30003”
DECODER_OPTIONS=“–max-range 360”
NET_OPTIONS=“–net --net-heartbeat 60 --net-ro-size 1000 --net-ro-interval 1 --net-ri-port 0 --net-ro-port 30002 --net-sbs-port 30003 --net-bi-port 30004,30104 --net-bo-port 3
JSON_OPTIONS=“–json-location-accuracy 1”

Thanks for pointing these things out as its helping me learn about the system. I’ll post an update later today or tomorrow now that I kind of know what to look for…


That’s 10.5% messages stronger than -3dB
(If you are running the adsb-receiver project graphs the display of those messages is bugged, for correct logging see (Optimize Gain - which would you chose - #174 by wiedehopf))

If you are concerned about close in traffic lower the gain to 33.8, otherwise it’s probably best to leave it.
Same as above if you have low flying planes disappear when they get too close to your receiver then you can decrease gain.
You might lose range but that depends on your setup.

@makeitwrite if you want to fix up your graphs/logs as well see the following post in another thread:
(Optimize Gain - which would you chose - #174 by wiedehopf)

Here is my stats.json. I seem to have a load of “samples dropped”. Gain set to 49.6. Piaware 3.6.3, Raspbian Stretch. I have the orange FlightAware dongle attached to a homemade CoCo antenna. Any thoughts?



  1. wiedehopf and abcd567 should be getting monthly checks from flightaware for the services they render.

  2. these json stats are great, but most of us have no idea what all this data means. (ie global bad, global skipped, modes bad, samples dropped, strong signals (and, like a broken record, if FA can decode up to -1dB FSSI then what is the “threshold” for “strong signals” etc). can someone give us a tutorial so we don’t drive wiedehopf and abcd567 nuts?

1 Like

Well as i’ve written before if you can’t detect signals > -1dB FSSI you can’t count them can you?
So you need to count how many messages you get which are within 2dBFS of that threshold and you can extrapolate that you will probably have lost some messages.

But the question is do you even care? First i wasn’t comfortable having 4% strong signal messages.
But now and then i checked if i lost in close by flying planes and sure when they are low and come within 3 km i might lose them due a signal being too strong.
That’s just a tradeoff you have to make with the dynamic range you have.

strong_signals are around 2.6%
Setting to -10 / AGC might give you some extra range but not very good for the planes close in.
While it has a slim change of getting you some range the position count would probably drop.
I would leave the gain as it is.

The dropped samples are not good though. I’m not sure what exactly it means but probably a power or USB issue.
Try another USB port on the pi.
Also try another USB power supply.

To test if your USB is the probelm run:

sudo service dump1090-fa stop
rtl_test -s 2400000

Dropping a few samples on startup is not unheard of and not a problem but you shouldn’t lose any more in the next 10 minutes.
Maybe run it before you change anything so you have a baseline of the problem.

Which Raspberry Pi do you have?


rtl_test showed a few bytes when it first started but none after another 10 minutes.

Pi is a B+ Revision code 0010

Today’s numbers “samples_processed”:654573568,“samples_dropped”:24772608
Yesterday’s numbers “samples_processed”:1106806702080,“samples_dropped”:24508366848

I rebooted the Pi about an hour ago but have made no changes to the setup. Is there a way to zero these stats?

Restarting dump1090-fa will zero the stats, so a reboot does as well.

That is a Pi3 or a Pi1?
You might be just limited on CPU.

sudo apt-get install htop

htop has a better display compared to top :slight_smile:

Edit: seems from your stats.json your dump1090-fa is using 37% of one cpu on average.
Now that should be enough depending on what else you run on that raspberry pi.
Maybe something else is using too much CPU?

To be honest i’m not even sure that that is the problem. There seem to be cases where rtl_test runs fine but dump1090 will drop samples anyway.
Did you run it with the 24000000 argument?
Higher frequencies are more data to transfer over USB so easier to drop samples.

Pi 1 single core processor.

The power is from a Plugable 4 port hub

HTOP occasionally shows the processor at 100%. As this is my test setup, I won’t bother upgrading it.

Many thanks for your help.

Wondering what is using all the cpu though.
dump1090 should be the prime cpu user, i guess you are running multiple feeders?
If it’s just piaware i would be surprised if it was cpu limited but i guess it’s possible with a good antenna and low horizon :slight_smile:

Only running dump1090/piaware into Flightaware. BUT I have rrdtools running so I can see stats. Every hour, on the hour and every 10 minutes something runs which causes the cpu to go to 100%. Plane count drops as does the messages /sec. This must be where I’m getting the dropped samples.

Interesting :slight_smile:

If you want to try and improve it you can change the following file:


In the following line

*/10 * * * * root bash /home/pi/adsb-receiver/build/portal/graphs/ 6h >/dev/null 2>&1

Replace “*/10” with “1,11,21,31,41,51”
So it looks like

1,11,21,31,41,51 * * * * root bash /home/pi/adsb-receiver/build/portal/graphs/ 6h >/dev/null 2>&1

The reason for this change is to make this line and the line above not run at the same time.
Before it would run every 10 minutes starting the full hour now it runs 1 minute later each time.

Apart from that i see you are displaying the percent number for the red messages but is suspect the logging is still off. (or did you reduce gain?) :slight_smile:
(Graph is showing 0.5% while the overall number i got was 2.6% from the stats.json)

1 Like

Looking much better.

I’ve reduced the gain to 37.2 and I’ll increase over the next few days back to 49.6

I’ll keep an eye on the samples dropped too.


I found this very human readable explanation for stats.json -