Gain Adjustment

FlightAware ADS-B Flight Tracking
41

Hate to be a parade pisser, but it’s nearly impossible to test within different time slices as there is no constant. You can see this by adding “max” to the gain array, which effectively sets 49.6 (max reported) - those results are always somewhat different than static 49.6 due to traffic flow - even though the settings are identical. Can help minimize things by creating many tests with shorter durations and changing the order of the gain array (remember it will run in reverse), but air traffic is still inconsistent to test this on a single rig. Ultimately would need two identical rigs running different gains albeit fired off at the same time (thru cron or however you choose) to go through the iterations for better comparison.

I’m not taking away from the script - it does a fine job and I thank those who shared the idea, but don’t take the output to the bank as gospel. This inconsistency is also a problem when it comes to testing antenna, LNA’s, filters etc. The best we could do is test two or more rigs as identical as can get for hardware when comparing gain.

That said, there should still be an easier method to change the gain on the driver level other than starting and stopping dump1090-mut with the configuration changes. Looking through the source, all it does is call a function from rtl_sdr on initialization after rounding the input value to the nearest firmware gain “step” then outputs the value to the dump1090-mut.log. Hoping Oliver or somebody that’s more familiar with the source can chime in on the subject? I haven’t had a chance to look much yet, but I assume there maybe some public functions that can be accessed through the driver API?

42

Does this work on a out-of-the-box Rpi / Prostick? Me thinks not…as I’ve tried.

Scott

43

There is a gain-scan branch (now quite out of date) on github which does this, it does multiple gain steps per second.

However stock librtlsdr will self-deadlock if you try to talk to the dongle to change gain from the receive thread, and it is also not very threadsafe so setting the gain in a separate thread doesn’t work reliably. I do have some fixes for librtlsdr that may help but that library is essentially unmaintained by osmocom and I don’t have the spare time to take it over so those patches are not going anywhere at the moment.

44

This is also the first time I’ve tried running a python script on my Piaware, and I’ve had an issue trying to get the script to run. I followed the instructions above, but keep getting this error.

test 1 of 10
Traceback (most recent call last):
File “./optimize-gain.py”, line 18, in
stdout=subprocess.PIPE, stderr=subprocess.PIPE)
File “/usr/lib/python2.7/subprocess.py”, line 679, in init
errread, errwrite)
File “/usr/lib/python2.7/subprocess.py”, line 1259, in _execute_child
raise child_exception
OSError: [Errno 2] No such file or directory

Anyone know if I am missing something that might be causing this issue? Trying to get the best gain for my ProStick.

Thanks,
Tom

45

Are you running the stock piaware image? The first snippet I posted is for dump1090-mutabililty, so with other versions of dump1090 you’ll have to change the dump1090 filename:


 p = subprocess.Popen(('/usr/bin/dump1090-mutability --net --gain '+g+' --oversample --fix --phase-enhance --quiet').split(),shell=False,
    stdout=subprocess.PIPE, stderr=subprocess.PIPE)

to something like:


 p = subprocess.Popen(('/usr/bin/dump1090 --net --gain '+g+' --quiet').split(),shell=False,
    stdout=subprocess.PIPE, stderr=subprocess.PIPE)

Don’t forget to stop any existing dump1090 process before attempting the gain sweep.

46

I am running dump1090-mutability on a basic Raspbian image rather then the Piaware image.
Using lignumaqua’s script i was getting output from the dump1090-mutability restart in amongst the expected results.
Like this:

test 5 of 10
ok ] Restarting dump1090-mutability (via systemctl): dump1090-mutability.service.
gain= 49.6 messages= 793 positions= 166 planes= 9
ok ] Restarting dump1090-mutability (via systemctl): dump1090-mutability.service.
gain= 48.0 messages= 835 positions= 165 planes= 10
ok ] Restarting dump1090-mutability (via systemctl): dump1090-mutability.service.
gain= 44.5 messages= 768 positions= 159 planes= 8
ok ] Restarting dump1090-mutability (via systemctl): dump1090-mutability.service.

So i modified the code a bit taking some lines from BartJr’s original script.
Basically removing the OS stuff and using subprocess.Popen instead.
This removed the echoed dump1090-mutability restart messages.

test 5 of 5
gain= 49.6 messages= 360 positions= 71 planes= 13
gain= 48.0 messages= 391 positions= 80 planes= 11
gain= 44.5 messages= 398 positions= 81 planes= 12
gain= 43.9 messages= 431 positions= 95 planes= 12
gain= 43.4 messages= 390 positions= 96 planes= 11
gain= 42.1 messages= 424 positions= 104 planes= 11
gain= 40.2 messages= 459 positions= 110 planes= 11
gain= 38.6 messages= 426 positions= 99 planes= 11
gain= 37.2 messages= 434 positions= 105 planes= 12
gain= 36.4 messages= 501 positions= 117 planes= 13
gain= 33.8 messages= 474 positions= 119 planes= 12
gain= 32.8 messages= 452 positions= 108 planes= 13
gain= 29.7 messages= 426 positions= 104 planes= 13
gain= 28.0 messages= 417 positions= 100 planes= 13
gain= 25.4 messages= 454 positions= 122 planes= 13
gain= 22.9 messages= 536 positions= 115 planes= 13
gain= 20.7 messages= 469 positions= 106 planes= 13

I also shortened the amount of time each gain setting was tested. It seemed like a minute for each was too long as the number of planes and their locations changed too much between the first gain sampling and the last. Using 62 seconds meant there was 17 minutes between the first and last gain sample. So i shortened it to 10 seconds. That way the aircraft pattern wouldn’t have changed too much between the first and last gain test.
To get a better averaging just do more iterations of the entire gain set.

I have never done any Python programming so this may not be the right way to do it but it worked. :blush:
Code now looks like this:

Edit: Removed code as BartJr pointed out a flaw in the changes i made. Don’t want anybody running bad code. :blush:

47

Another thing i noticed was that there doesn’t appear to be any storing of the existing gain setting so that it can be put back the way it was before the script started changing it.

Doesn’t seem like it would be too difficult to store the current gain value as a variable.
Then do all the alterations and tests and then last thing before exiting setting the gain back to it’s initial value and restarting dump1090 one last time to make the initial value active.

But like i said, Python is new to me so hopefully somebody more experienced will be able to make the alteration.

48 

   for line in fileinput.input('/etc/default/dump1090-mutability', inplace=1):
      if line.startswith('GAIN'):
         print 'GAIN='+g
      else:
         print line,
   p = subprocess.Popen(('/usr/bin/dump1090-mutability --net --gain '+g+' --oversample --fix --phase-enhance --quiet').split(),shell=False,stdout=subprocess.PIPE,stderr=subprocess.PIPE)

The “subprocess.Popen…” line starts dump1090-mutability with the desired gain. (note the “–gain” option). So you don’t have to do any editing of /etc/default/dump1090-mutability. Just be sure to stop any existing dump1090 service before running the gain sweep script. (sudo service dump1090-mutability stop)

To clarify, there are two methods in this topic:

  1. my original: Stop dump1090 service before running the script. The script calls the dump1090 executable directly.
  2. lignumaqua method: The script edits /etc/default/dump1090 and runs the service instead of the executable.
49

I just added “max” and “agc” to the list of gain levels to be tested so i can see how they compare.


gains = "20.7 22.9 25.4 28.0 29.7 32.8 33.8 36.4 37.2 38.6 40.2 42.1 43.4 43.9 44.5 48.0 49.6 max agc".split()

Here is a quick test using 10 seconds per gain level and just one iteration of the series.
It is the middle of the night here so only a handful of planes in range.
“agc” is clearly a very good choice during quiet times.
It will be interesting to see how well “agc” fairs on a weekday in a peak time.

test 1 of 1
gain= agc messages= 131 positions= 29 planes= 7
gain= max messages= 109 positions= 25 planes= 7
gain= 49.6 messages= 71 positions= 13 planes= 6
gain= 48.0 messages= 96 positions= 18 planes= 7
gain= 44.5 messages= 77 positions= 18 planes= 7
gain= 43.9 messages= 104 positions= 26 planes= 6
gain= 43.4 messages= 95 positions= 21 planes= 7
gain= 42.1 messages= 67 positions= 12 planes= 6
gain= 40.2 messages= 85 positions= 17 planes= 7
gain= 38.6 messages= 71 positions= 13 planes= 7
gain= 37.2 messages= 72 positions= 14 planes= 7
gain= 36.4 messages= 59 positions= 9 planes= 7
gain= 33.8 messages= 79 positions= 17 planes= 6
gain= 32.8 messages= 53 positions= 8 planes= 7
gain= 29.7 messages= 67 positions= 13 planes= 7
gain= 28.0 messages= 71 positions= 14 planes= 6
gain= 25.4 messages= 66 positions= 10 planes= 6
gain= 22.9 messages= 38 positions= 5 planes= 5
gain= 20.7 messages= 58 positions= 10 planes= 5

Edit: Changed “max” and “agc” to lowercase, not sure if it matters but the comments in /etc/default/dump1090-mutability show them in lowercase.

50

Thank you for pointing out my mistake.
I will remove the “Code” section from my previous post so as not to confuse others and have them using broken code.

51

OK, i managed to get rid of the status message that was echoed to the terminal each time the dump1090-mutability service is restarted.
Not sure if this is because i am using the Raspbian image rather than the piaware one. Or maybe it is just a peculiarity of my system.
So i went back to using lignumaqua’s script and just modified the command that restarts the service.

Using
“sudo systemctl restart dump1090-mutability”
instead of
“sudo /etc/init.d/dump1090-mutability restart”
fixed the issue for me.

52

Hi all,

So, just ran LignumAqua’s script, 5 secs per gain setting, over 10 sweeps…

Just seems to show “higher the better” - what are we aiming for here; which is a “good” response?

Is it an outright comparison of the values shown here, are slightly more involved, say Messages divided by Aircraft - msgs per aircraft, positions per aircraft etc ?

Equally, I could suggest that as both 49.6 and 44.5 show 67 birds, with 44.5 being the lower SNR, that’s better - but then again positions is down vs the 49.6 max?

===Totals===
Gain, Messages, Positions, Aircraft
49.6 25016 1569 67
48.0 24233 1504 66
44.5 22992 1420 67
43.9 23384 1396 65
43.4 23146 1424 66
42.1 23570 1410 64
40.2 22655 1382 64
38.6 22400 1353 63
37.2 22266 1333 62
36.4 20774 1261 63
33.8 19645 1179 60
32.8 18333 1124 57
29.7 16540 951 54
28.0 15654 911 49
25.4 13018 706 45
22.9 11649 638 42
20.7 9391 525 39

53

For you, the top setting is probably the best.
Picking a higher gain, of two, allows you to get more aircraft in quieter times(like at night).

54

Thanks JohnHawkes2030…

Just so I know, what’s that based on - highest vals across the board?

I might run that entire report say 10 times, and take the average / confirm highest across the full data.

Also, is there any benefit to running it for a full 24hours, keep the dwell per setting at 5 seconds, but increase the sweep number to add up to 24 hours?

Also, with my rig working best at “full gain” - does that imply my reception is generally a bit weak?

NB - HabAMp into LR400, just that the ant (fA ant) is in the attic, rather than external roof line…

55

Does this method of evaluating gain bring “noise” into the mix?

Of course, by setting my gain to max as suggested by the data, this would increase noise also.

I assume it does, because that also shows the most aircraft / messages etc.

** With the highest gain looking to be most effective in my situation, is there any benefit to setting gain to “-10”, which AFAIR from reading on this forum, is even higher gain than max (aka 49.6) ?

56

Hi,

Thanks for the script(s). I have been running a Pi 3 setup with jprochazka scripts for just over a week. I am based in London and I was using it with a FlightAware aerial (outside on a roof terrace about 10m above ground level), FlightAware filter and a NooElec NESDR Mini 2 USB stick, but on Saturday I swapped this for the FlightAware stick and Reports Received went up from about 450000 to 650000 and Plane count from about 2300 to 2900. I was running gain at “max”, and wondered if tweaking it would see an improvement. I ran the 2nd script (which keeps dump1090 running so you can carry on feeding) for 15 secs per gain setting, for 10 iterations. I maybe didn’t run it at the best of times (between about 21:30 and 22:00) and my results showed little difference between the settings above a gain of about 30, however a setting of 48 showed slightly more than the rest. I set it up for that, and have been running with it for just over a day, but (hard to tell as every day is different) my graphs for yesterday look slightly down on what they were for Sunday / Monday when I was running at max, so wondering if I should set it back, and if I do should I try -10 (or would even agc have an effect).

1114×878 352 KB

1114×877 358 KB

I have attached my graphs for the last week, and the last 24 hours. How do they look, does anything stand out (as I am new at this and still learning). I see -3 dBFS on the chats a few times, what’s the significance of this figure, I assume it’s to do with the strength of some of the signals being received, but as I am under one of the flight approaches to Heathrow (planes about 4400 ft high when going over), and about 1 – 2 miles away from London City airport I would have thought I would be pulling in strong signals. My Messages > -3 dBFS increased quite a bit when I swapped to the FligthAware dongle (probably due to the amp) so do I need to be overly concerned, or due to my location is that to be expected.

Also, messages / sec, I seem to be maxing out at around 1100 – 1200, is this to be expected with my setup. I read another discussion and this figure got mentioned, but think it was stated that USB stick limits were higher than this. My CPU isn’t stressed, so not sure if I can do anything to increase. I notice a user near me is getting a similar plane count, but their Reports Received is almost 1000000 (so 350000 more than me), could it be that they are using a specific ADS-B receiver rather than a USB stick.

Here is my FlightAware stats flightaware.com/adsb/stats/user/iandrews

Time line:

Tue 31st – Installed
Sat 4th about 10pm – Installed FlightAware Stick
Mon 5th about 9:30pm – Ran gain script, and then changed from max to 48
Tue 6th about midday – Was down for an hour as I moved some things around.

Thanks.

57

hello iandrews, I live the other side of London from you and am running a similar setup . I find the RTL sticks appear to max out around 1600/1700/1800 messages and for me, and typically runs in the high 1600’s. I tune my system for maximum positions as I suspect I see all the local planes, more distant ones squeeze thru the gaps. I would suggest you try “max” or “agc” and I find the best time to play is in the afternoon. I improved my counts by adding a HAB preamp/filter instead of the FA filter in front of the Pro Stick. In London, 2-300 planes most of the time, gain seems to help improve counts my noise level is permanently at -10. My location helps a lot I can see a distant horizon in most directions.

58

@ iandrews, setting Gain=“-10” sets it to automatic (as in Automatic Gain Control) - the same as enabling AGC:

–gain Set gain (default: max gain. Use -10 for auto-gain)
–enable-agc Enable the Automatic Gain Control (default: off)

Based on this, I believe enabling agc (with that second line) would disregard anything entered manually in the gain setting.

However, I dont believe AGC works well at these frequencies, and afair the recommendation is not to use AGC…

Shame, that would save all the tweaking with gain! :wink:

I’m sure one of the guys here will correct me if needed…

59

Thanks.

I re-ran the script this morning dropping of anything below 43.9 and adding -10 and agc and got the following (10 secs per gain, 5 cycles):

===Totals===
Gain, Messages, Positions, Aircraft
-10 33938 1560 148
agc 33498 1497 142
max 39393 1736 144
49.6 40512 1769 146
48.0 39318 1767 143
44.5 38901 1654 153
43.9 39418 1790 148

So that showed straight away that -10 and agc wasn’t very good (apart from Aircraft for -10 !!!???). This test showed that 49.6 to be the “best”.

At lunchtime I moved my aerial slightly, I moved it from a temporary pole it was on to a pole I have with a weather vane on the top, so it’s now about 6 feet higher, this brings it up above the roof line of some houses to the south-east of me, and almost to the top of my roofline which is to the north. Though it’s higher I can’t get it quite all the way to the top of the pole (aerial lead too short), so the bottom 1/2 of the aerial is “next to” the metal pole. I assume this isn’t the ideal solution as that part of the aerial will be shielded by and quite close to the metal pole which I assume will cause some blocking / interference of the signal. However this move increased aircraft count from about 150 to 170 and messages / sec from about 900 to 1100. So looks to have had a positive effect.

Anyway I decided to run the script again (10 secs per gain, 5 cycles), and this is what I got:

===Totals===
Gain, Messages, Positions, Aircraft
max 55883 2876 190
49.6 56230 2890 199
48.0 56245 2905 202 So best for messages
44.5 56142 2955 206 So best for positions
43.9 56073 2806 207 So best for Aircraft
42.1 56377 2791 195

So a bit of a spread on which is best for what (and probably due to second by second fluctuations in the signals being received), if you ignore 42.1 then Messages decreases with gain, but Aircraft count increases, with Positions topping out at 44.5 then decreasing. I then messed around with setting the gain in the dump1090 setting file and restarting it, and then looking at the dump1090 web page trying to note any difference in plane count and messages / sec and sort of saw the same.

So, for the moment I have set gain to 44.5 to see what I get. Though maybe broke the rule about not changing 2 things at once, so maybe should have left at 48 for a while.

60

I hadn’t been happy with the performance of my system since I last fiddled with it and lost a bit of performance. I hadn’t had the inclination to go up into the sweltering loft to fiddle with it more until the pi hard crashed (caused by a crappy usb hdd enclosure) and I had to go and reboot it.

I swapped the dongle out from the Cosycave TCXO one for one of the RTL-SDR.com dongles with the bias-t enabled. This enabled me to remove the external bias-t and psu, but I also had to replace the flightaware filter with the satellite diplexer I was using previously because it doesn’t pass DC (they both give equal performance for me). I think that psu was either noisy or not very well regulated since the signal strength increased considerably and I’m measuring a steady 4.5V at the lna4all where before it was a bit less than that.

The gain scan script was pretty useful - I left it running for a few hours and the results gave a clearly optimal level to use. I now have significantly higher range, and the highest message counts I’ve seen to date - seeing peaks just below 1800/s now with 1700/s being common at busy times. Aircraft count is also up to about 270 peak which is higher than I’ve seen it before.


1158×301 38.8 KB