OK, I’m seeing those too when I look!! So perhaps I have pushed the “-e” option too far. Basically this:-
Apr 08 09:24:48 piaware airspy_adsb[357]: /!\ Lost 98304 samples /!\
However, I’m going to stick with the “-e” value I have. Instead I have removed the “-p” option and changed my sample rate to 12 MHz.
From what I recall I only needed the “-p” option for the extra USB bandwidth required for 20 MHz. I was never certain the 20 MHz made much difference and even on the Pi 4 it tended to run the CPU at or near 100% all the time. So I’ll try that and see…
From what I can see immediately it does seem to have increased my overall message rate so far (around 1600/s which is higher for this time of the morning). The errors from the journal command have also immediately dissapeared.
By the way, changing the “-w” value to 4 seems to have reduced the “others” number. So looks like wiedehopf was spot on there!
I suspect that would only be the case if the -e setting is limited by cpu, and that reduced -e setting is causing real preambles to be missed. If you have the cpu to run the preamble filter at a sufficiently high number that few real preambles are missed then I would expect the higher sample rate to improve performance.
So for example, an airspy on a pi 3 doesn’t have the cpu to have the preamble filter set permissively while also running 20 MHz, so it may get more messages from the lower sample rate, with a more permissive preamble filter. A pi 4 or PC has sufficient cpu to run the higher sample rate while also having a permissive preamble filter so should see more messages decoded. Might be an interesting experiment.
We’ll find out
I’ve dropped my sample rate to 12 MHz and increased -e to 10.0 but it won’t kick in until I reboot in the early hours. I don’t like rebooting or restarting the service during the day as it gives an artificial huge spike on the graphs so if I make changes like this, I generally schedule an overnight bounce. I’ll run it for a few days and see if there’s any noticeable difference or lost samples and if there aren’t any lost samples then I’ll go up a further step.
Be interesting to see how the cpu usage changes. I switched to a 64 bit kernel and the 64 bit airspy decoder and that made a noticeable difference to the airspy cpu usage - it’s 10-15% down compared to the 32 bit version. I’ve increased the -e setting to 10 from 9.7 which has put the cpu usage back to where it was. I haven’t seen any noticeable change in performance so far, but it’s hard to tell with the reduced traffic.
Given the current discussion re airspy_adsb parameters, I thought it might be worth reproducing your airspy_adsb.default file from your airspy.conf script. It provides an excellent summary of the parameters and recommended starting values, etc. for those who want to experiment:
Message rate seems about the same but I now have exactly the same number of aircraft as aircraft with positions which is unusual - Normally I’d expect a few without positions.
It suggests that -e can be between 0.1 and 10.0, does that mean that it’s effectively capped at 10.0 and going higher makes no difference or is that just because nobody was ever expected to run it at that level?
So there is an inconsistency - the airspy_adsb help is a bit lacking, which is why I thought it was worth quoting wiedehopf’s advice. Give >10 a try and see what happens!
It’s practically impossible to tell! Daily rates vary so much…
Here’s my map and here are my graphs. The overall message rate looks down a little today compared to yesterday but up over the previous few days. The number of aircraft seen/tracked today is higher than it’s been for a while though.
Thanks, that does indicate it can go higher.
/edit - Comparing my figures today to the MTG feeder, I’d say yes, it looks improved, there’s a larger gap than usual.
Tried this again.
Reducing to 12MHz reduces messages for me, however I’m not getting anywhere near as many messages as you and am not dropping samples.
I may try again if the travel industry ever recovers.
Edit:
I’m running R2s connected to a splitter system, however the split is not even, so the gain is set differently.
The Pi4s are running 64bit with compiled packages IIRC.
I’ll need to re-jig things for an exact comparison.
Both Keith and myself have busy sites. Both sites cover Heathrow and European traffic routes.
For me after a few days of running 12 MHz sampling rate I’ve only seen improvement. No lost samples and the CPU of the Raspberry Pi 4 isn’t maxed out most of the time.
I suspect Keith might do a little better with a higher “e” value- but again, it’s not clear how far you can (or should) push that.
I think a 64 bit build might perform better?
But what config would work best then? Higher sample rate? Lower “e” value?
But even then I’m not sure what is optimal for my site? Am I gathering all the messages my site is capable of collecting?
Possibly I don’t need to worry about that- I guess the joy of Flightware is that the network of receivers fills the holes?
But as an engineer I’d love know the optimal approach!
Sorry, not sure if that helps anyone- but certainly a really interesting discussion.
I wasn’t losing samples. At 20 MHz and an e of 9.9, I had no lost samples. It’s when I added the -p for a few minutes that I started getting them so I took that option straight back off.
Now with it set to 12 MHz, I’m gradually increasing the e value to see how far I can get it while still not losing samples.
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.
Agreed with this entirely. I want my receiver to perform the best it can which is why I’m always banging on about impedance matches, decent coax, etc.
This is the problem at the moment, traffic levels are very low compared to how we’ve seen them in the past so it’s difficult to know whether these changes are sustainable at full traffic.
Normally, I’d expect to be coming out of the winter doldrums now but it’s just totally unpredictable.
Before this lockdown, I was fed-up with my Pi3B performance bottleneck. Instead of going to buy a Pi4, I decided to use one of my older laptops (a Dell with i7-2640M) and install Ubuntu on it to run Piaware and Airspy.
Sure, it requires recompiling of the code, but with @abcd567 instructions that was easy.
Best decision that I made, since it costed me nothing.
I am running my Airspy R2 with 24MHz SR, -e 12.5 and my CPU usage is at 95.7-96.7%.
