Edit: This was done with 10 second intervals for a total cycle of about 5 minutes each. I figure this gets a close snapshot of the sky rather than planes coming and going with 60 second intervals.
Traceback (most recent call last):
File "./gain2.py", line 23, in <module>
os.system("sudo /etc/init.d/dump1090-mutability restart")
NameError: name 'os' is not defined
Adding āosā to the list of imported modules fixed it.
This is after running the test script on my system (FlightAware antenna in the roof space with about 20ft of RG6 to a FA Filter and ProStick in a Pi2) for 24 hours. (It clobbered my stats for the day as expected, but kept feeding data)
This was 70 iterations of the test, running 62 seconds each per gain setting.
Messages and Positions peak at the highest gain. Aircraft peak at 44.5 dB. However, realistically, there is very little change in anything once above 33 dB.
I ran the script for 10 cycles of 1 minute earlier and was going to post graphs, but the results are very similar to yours. The number of messages and aircraft are both highest at maximum gain, though the difference between maximum gain and about 37dB is pretty small but below that get considerably worse. The only thing this doesnāt measure is the maximum range received during the period. The gain may affect that a bit, but because aircraft at maximum range tend to disappear quite suddenly it might not be easy to get a good indication with minute long changes.
obj made a gain scanning version of dump1090 which I think changed levels quite fast, thought Iāve not tried it out.
Iām using an LNA4ALL at the antenna for this, and not the Flightaware dongle.
Anyways, Iāve been off here about a year and keep looking back every now and again, got a pro-stick and already had a Piaware filter which I hadnāt used yet.
Iāve hooked them both together, ran the python script and hereās the results:
Seems like many people are seeing the same pattern with the Prostick and that script: gains above 35 or so all produce fairly similar results.
When I ran it I just stopped dump1090 service and let the script call the dump1090 executable directly.
If you wanted to keep piaware and mlat-client happier during a long testing process, one idea is to start the normal dump1090 service in net-only mode. Then have the gaintest script run a second instance of dump1090 (with all different ports) passing data to the original. This way piaware canāt see dump1090 is constantly being restarted. I havenāt tried it though.
Thanks for the script BartJr. It confirmed roughly where I thought my best gain setting was but its good to see some real data confirming it.
This is using a microstripline antenna directly connected to a PGA103 based LNA (both DIY) in a reasonably RF quiet area so no filter.
Presumably the PGA103ās gain here is higher than LNA in the Flightaware pros but maybe some of the difference is due to coax / filter attenuation, It would be interesting to see results from a pro connected directly to the antenna.
This is great. Thanks BartJr & lignumaqua for the script, makes life easy. It came a bit late after I have found best settings by painstaking trial & error method. However I will run this script to see how my manual results match with the automated script results.
My Settings Found by Trial & Error
Pro Stick, No Filter, best settig 30 to 35 dB.
Pro Stick + Fliter, best setting āmaxā.
Note: Gain setting will vary with each individual system. It depends on antenna location, antenna gain, and loss in coax cable. Below are details of my system.
Antenna: Cantenna, gain 2 dBi
Location: indoors, but at 60 ft above ground near large glass window.
Coax cable: 12 ft / 4 m RG6 coax.
Amplifier: No amplifier.
Have been following this thread for a bit, thanks for the script ideas
Is there a simple (or direct) way to access the rtl_sdr API without having to write something up behind the entire source tree to access: āint rtlsdr_set_tuner_gain(rtlsdr_dev_t *dev, int gain)ā ?
Iād like to be able to alter the gain without the cludge of rewriting the dump1090-mutability parm tree and restarting with every iteration. Any pointers to follow, or would the best course of action include writing up another tool and compiling in with dump1090-mutability?
This is how Iāve been making quick gain adjustments.
sudo nano /etc/default/dump1090-mutability
Find this section
# RTLSDR gain in dB.
# If set to "max" (the default) the maximum supported gain is used.
# If set to "agc", the tuner AGC is used to set the gain.
GAIN="49.6"
and make your change. Save the file with CTRL-X, Y(es), Enter.
Then restart dump1090 withā¦
Yessir, thatās basically what the script that was pasted above is doing as well. I was however looking to control via rtl_sdr (driver level) on the fly without requiring a dump1090 restart. For instance, SDR# can adjust using a slider - I realize completely different platformā¦
(1) Give following command to create a blank file āoptimize-gain.pyā
Note: it is not necessary to name the file optimize-gain.py. You can use any name of your choice, but it must have .py at the end
sudo nano optimize-gain.py
(2) Copy-paste the script code in the blank file created above, save the file (ctrl+o), and exit (ctrl+x)
(3) Make the file executable:
sudo chmod +x optimize-gain.py
(3) Run the script:
sudo ./optimize-gain.py
(4) Find the log file:
I dont think any log file is generated.
The results are displayed in the SSH terminal progressively as these are conducted.
The totals of the test are displayed in the terminal at the end of test.
You can copy everything from terminal and paste into a text file & save the text file.
The above test was done on a secondary unit+antenna, located in a room, at not-so-good-a-signal location. The results of best setting = mininum (20.7) by script test can be understood easily if the message rate graph is seen.
The last 2 hours on right of graph is the period when python sript was running to find the optimization of gain.
Now that I have a spare cpu and RF chain again (PI 3, FlightAware dongle and filter), Iām running gain sweeps, feeding that chain from a splitter on an operating ADS-B feeder.
Also looking at PPM correction ā how important is that, and is this something that could be done (optionally) on dump1090-mutability startup?
Iāve also altered process priorities on the key processed involved:
Obj does this starting up dump1090-mobility. Iāve extended it to the rest of the processing chain, so that when I do something that would otherwise suck up a lot of system resources, such as an update, or a compressed TAR backup, the ADS-B chain still has priority.