Also found this helpful
Please check version 1.43 of airspy_adsb with a new preamble detection. The CPU savings were used to get more decodes. Let me know how it goes.
3 Likes
I am running this on my Pi3 (non plus). Using the -m 20 still pegs one of the CPU cores at 106%. MLAT fails shortly.
With -m 12 the CPU utilization is about 65% (messg rate right now is about 700-730/sec).
It’s using more CPU than before 
I’ll probably continue running 1.40 on 20 MHz.
This is just too close to losing samples and it will happen every now and then.
But i understand that pretty much no one is managing 20 MHz on the Pi3 anyway, so might as well improve 12 MHz detection.
I decided to try the -r option (reduced IF bandwidth). I’ll let it run tomorrow all day.
I’ll try it out for a few days. in a “ps”, v 1.42 used about 61% whilst v 1.43 uses about 71% cpu on my PI4. I just checked msg/sec using v 1.42 sixty seconds before I switched to 1.43. I was getting about 360 msg/sec on v 1.42 and 60 seconds later I was getting 405 msg/sec on v 1.43. Graphs over time will tell us the difference. But I definitely notice that it’s (a) using more CPU and (b) generating more messages per second. I’m running @24 MHz. (it’s 9 pm in the evening, I live in a rural area, and it’s rain all over Ohio – so the plane count is way down as a consequence of those things)
Mike
I’m mixed on this revision Youssef: Airspy R2 @ 24Mhz, Pi4 @ 2Ghz: Swap @ 18:02 v1.42 → v1.43
Watermark RTL rig:
Back to the Pi4, lots of extra cycles for what appears to be little return.
Keep them coming, can test at any time and also have another R2 on the way so can get my rigs back to being fully mirrored again if needed.
Update: Change was 18:02 v1.42 → v1.43. # of tracks/hour seems to have increased quite a bit, not sure how to decipher exactly:
Airspy R2 @ 24Mhz (MLAT holding strong still)
Watermark RTL:
Thanks for the feedback. Let’s keep this running a few hours and compare.
2 Likes
OK. I think the CPU usage now increases too much with high traffic stations. It could saturate one core of a Pi4 at 24MHz. I will reconfigure and re-release.
Update: v1.44 is out. It reduces the preamble aggressiveness at 24MHz. The other MLAT modes are the same.
That includes “tracks with single message” which are mostly false decodes (noise).
Anyway i’ll continue running 1.40 with performance improvements as it doesn’t take my pi3 to the brim at 20 MHz.
@prog
Time to split up the preamble detection into its own thread?
I mean the current model where one thread hands the data to the next should be extendable?
Not yet. The new preamble routine needs some tweaking first.
This is what I think it is weird… nu matter of the traffic, the CPU load is constant.
The step-up in CPU usage is with 1.43 version. The short spike at 100% was with -m20 option on my Pi3.
Note how at night, with minimal traffic, the CPU load is quasi-constant (just a very small dip). This was happening with previous versions too.
It’s like 40-50% of the CPU load is not related to actual decoding of the signals. If so… can some pre-calculated tables filled with cached values apply to speed-up that process?
It’s preamble detection and conditioning of the samples so to say.
And no this can’t be optimized further.
dump1090-fa does preamble detection as well, but only at 2 MHz.
Now you see at 10x the samples to check the load will increase.
Oversampling costs CPU power, that’s just the way it is.
Correct. I added more optimizations elsewhere. Same decodes, lower CPU usage.
Please check v1.45.
2 Likes
Just saying that the preamble check uses CPU independent of the amount of ADS-B messages or airplanes 
high*=5 instead of 6 is around 5 percent less CPU usage
1.45 is a little less than 1.44
This is on the 3B+ on 20 MHz with networking improvements to reduce the fluctuations.
I don’t get it. What preamble checking happens when there are no samples received?
Samples are always being transferred. That is the raw data representing any signals or noise on 1090 MHz.
It’s a software defined radio, the software decoder basically gets the amplitude of signals 1090 MHz to simplify it massively.
The amplitude is a value or called a sample, now of those samples, 20 Million are processed each second.
That takes CPU.
Can it be done the sampling in that phase at 2…6 MHz and switch to 12 MHz when actually there is decoding to do?
The effect can be dramatic in sites like @navzptc’s 90885. I can see 100 fps more over 1900 fps. Check v1.46
This also depends on the traffic. More testing required.
Update: I merged @wiedehopf Network optimizations. This can help with high traffic sites as well.
2 Likes