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?