It also deals with distorted, disrupted, reflected and inconsistently attenuated signals better than RTL dongles (by a lot). It allows you to put an antenna in a location where no normal or sane person ever would, and still achieve reasonable results. You just need to enjoy technical challenges to appreciate it!
2 Likes
Latest fine tuning in RC26 made the system more prepared to the next hot season. In average, cpu temp is lowered by 2.5 °C.
Airspy looks more and more shiny, even if it is a black cube, as for othersâ eyes.
I donât think so but stop trying to protect your baby. I am just putting up an example that one type of gain adjustment might be better than another but also asking if airspy could run under adaptive gain, as well as your project
it does. No need to confuse the blue FA stick with an Airspy. Both have adaptive gain. Full stop.
Dump1090-fa is just a pass-through point of the system here. âNET ONLYâ
Delegating an already integrated part of the control system would not be a wise choice.
As a function, autogain works in both mechanisms but deals with different circumstances.
Adaptive gain in dump1090 and rtl dongle based stations is NOT an universal tool. It is for those dongles only.
I donât think dump1090-fa adaptive gain would do anything just getting data from airspy_adsb.
We program this stuff, yes we could add some interface to change gain while airspy_adsb is running.
Does it make sense?
Well not really, at least not in conjunction with dump1090-fa.
dump1090-fa knows which gain is best for its rtl-sdr decoder, airspy_adsb knows which gain is best for the airspy.
The only other reason to have such an interface, change gain while airspy_adsb is running due to user input.
Thatâs somewhat of a funny idea ⌠but same as before i donât see the appeal.
Restarting airspy_adsb is super quick after modifying the configuration.
By the way, during this conversation i have never said that airspy_adsb has a better autogain algorithm. Actually i havenât much looked at the one in dump1090-fa.
But thatâs completely besides the point and not the reason for our reaction.
Youâre trying to do something thatâs just completely unnecessary and in general we donât endulge that as weâd rather put the time in something else.
5 Likes
We already have a better AGC.
2 Likes
Are you seeing actual better receiver performance versus your airspy, or just a more interesting line on the chart?
1 Like
I mentioned earlier that I was running a test on gain settings and how it affected reception. Thatâs now finished and Iâve got some results:
I ran a script which cycled through 6 gain settings - 11, 13, 15, 17, 19 and 21. I chose those values to get a spread that was definitely too high and definitely too low for my receiver (autogain was typically staying around 17 when busy and 18 at night). The gain was changed every 10 minutes, so each cycle lasted an hour. The order was shuffled each time so that same gain was not used at the same time each hour. The script ran for a total of 48 hours to fill the graphs1090 1 minute resolution database. This test was run with 2.2-RC24.
Setting the gain to a known value allows comparisons which canât be made with auto gain, since then the gain is dependent on the conditions. By using a known value, we can see the effect on reception.
Here is the signal to noise ratio:
The results are reasonably consistent from 13 through 19, with only small changes within those values. At 19 there is a slight decrease in the average SNR, but the change is small. 11 and 21 are definite outliers with noticeably worse performance.
Plotting the density of values for median SNR also shows clearly what is happening:
11 and 21 are clearly much worse, but it can also be seen that the middle values 15 and 17 provide the best performance.
Here is the range between the highest and lowest SNR - higher is better in this case:
How does this translate into what we are really interested in, successfully decoded messages?
Firstly range:
There are two noticeable effects - firstly that gain as low as 11 has a definite effect on maximum received range. Second, that once the gain is at 13 or above there is minimal change. The maximum reception range is limited by terrain only, not signal strength.
Messages:
The result here follows a similar pattern. A gain of 11 has a measurable effect on the number of messages received, with an average across the sample period nearly 9% worse than the best figure. The peak message rate was with gain at 17.
Looking more closely at the distribution:
From gain 15 and above, the average message rates are very similar. Gain 13 definitely produces slightly lower message rates than the higher values.
Aircraft seen:
Again the effect of lower gain is clear - fewer aircraft are detect with gains 11 and 13. The highest average was actually with the gain at 21, but the variation between 15 and 21 is really quite small.
Summary data:
Conclusions:
The most obvious conclusion is that having the gain set too low has a definite and obvious detrimental effect on the maximum range and number of aircraft seen, and consequently the number of messages received.
Second, that too much gain has a measurable negative effect on RF performance, but the impact on the ability to successfully decode messages appears to be minimal if any. Iâd want to repeat this over a longer period to average out variability due to traffic conditions before saying that definitively, but it doesnât really seem to be a problem. This test doesnât look at data quality however, so itâs possible that at higher gains some close range messages are lost that otherwise wouldnât be.
I think this shows that the current autogain is doing a nice job of selecting an appropriate value - For my receiver, it is generally at 17 or 18, which puts it near the highest SNR range. Itâs high enough to be getting the maximum possible range, while giving some headroom for very strong close range signals.
14 Likes
I agree. And well done!
For those who havenât run this test and and created plots yet, see this post and the gain script updates below it.
3 Likes
Too early for that decision, would like at least a weekâs data to compare first. Real basic live comparison, one tar 1090 map running off the airspy and one running of the FA dongle, so far in observation, each have detected the same amount of aircraft, with a very similar area of coming in and leaving coverage range.
1 Like
Iâve been using @wiedehopfâs testing tool to look at the impact of different -e and -P values on the number of DF17 decodes on a range of samples Iâve collected. I know that you and others have done this before, but my traffic numbers have improved and the RCs have moved on since the last time I did the exercise and the sweet spot for my system may have changed.
It occurred to me that if all of the DF17s could be written to a file during each test, it should be possible a to apply a sort of DF17 XOR on those files to just be left with those messages that are decoded at one setting but not the other.
It would be interesting to look at them to see if they are worth all the extra CPU cycles needed to extract them.
Do you think this is an idea worth pursuing?
-P has no influence on DF17 whatsoever.
Any message output for file inputs is disabled on purpose.
I think caius approach using live data but using different -e settings instead of different gain settings might give you the data you want?
Then you can see if the higher -e adds range?
Listen to minute 1:20
Now apply what you learned to the AC count.
4 Likes
I just like watching Willow 
3 Likes
7:25 âHow kind of you to notice, I guessâ 
1 Like
Yes - sloppy language on my part. Only relevant to other non-CRC message total.
Apologies for posting a half-formed idea. I suppose what Iâm really asking is would it be be much work for you add an option to write the beast output from a test file input to a seperate file?
My coding skills are probably up to pursuing my curiosity from there.
I donât need this to work out the sweet spot - that comes down to personal preference in terms of how hard you want to push your cpu.
An example from one of my 90 second samples:
-e 10 9159 DF17 23.9 processing seconds
-e 60 9167 DF17. 71.3 processing seconds
I would like to look at those 8 extra DF17 messages to make a judgement about whether they were worth the nearly six processing seconds each that it took to find them.
I was going to say it has something to do with @progâs survivorship bias discussion of some weeks ago, but thatâs probably a bad analogy.
Iâm very happy with things as they are right now. Great job @prog and @wiedehopf. This RC could be a real final version 
4 Likes
You only need one or two frames to declare a new track. Getting more frames does not make any difference with this way of measuring the performance.
1 Like
Still one RC left and we are good.
2 Likes