That’s really what it comes down to. If the preamble filter is artificially filtering out real signals, then increasing it will yield improvements. If it isn’t, then making it more permissive won’t provide any gain as all real signals are being passed to the decoder.
With the whitelist filter set appropriately, there is no disadvantage running the preamble filter at the highest level the cpu will support, especially given the low power consumption of a pi. That means the decision comes down to using the 12Mhz or 20Mhz sample rate, with the preamble filter set to the highest level supported by the cpu.
I would anticipate that the higher sample rate should perform better in cases where cpu constraints are not an issue - eg. you can have e set high enough that there are no gains to be had from increasing it further. If increasing -e would result in gains, then it may be possible to realise them by dropping to the lower sample rate to give cpu headroom to do so.
I would also expect local conditions to have some impact. Somewhere busy with lots of overlapping signals would probably benefit more from the higher sample rate than somewhere less busy, and somewhere with a particularly noisy RF environment might see higher CPU usage than somewhere it’s quiet.
I’ll try running my receiver on 12Mhz with the preamble filter set as high as possible, but I’m only seeing about a third of the traffic I typically would so I don’t know whether it will be representative.
It does slightly. I switched to a 64 bit kernel and the airspy_adsb decoder and saw a 10-15% reduction in cpu usage for the same settings. I increased the preamble filter from 9.7 to 10 which put the cpu usage back to where it was and haven’t seen any noticeable change in performance. It’s difficult to compare though since the easing of lockdown has caused traffic changes over the same period.
