Thanks guys! I got the samples. Let’s see how things can improve.
Today is Friday which is more traffic.
You’d have to run both settings for a few days if not a whole week and then compare with the graphs.
Anyway the samples will show the way.
Can you please push another dump for 12MSPS as well?
I agree. There are way too many variables. Heck, even within a 5 minute interval the msgs/sec can drop off significantly, and legitimately. It’s annoying, but we can’t do anything about weather, interference, and those darned planes not staying in one place 
Mike
I find it is best to make a system “upgrade” change and then look at the trailing 30 day results after a month. The close-in graphs are beautiful but the data are quite noisy.
I don’t want to create an argument, but in my personal setup the Airspy Mini cannot push reliable data at 20MHz. Sooner or later will drop from MLAT. Maybe that’s why the firmware only show 6MSPS… Don’t know, I don’t have any “lost samples”.
Anyway, at 12 MHz or 20MHz sampling it doesn’t seem to decode more planes or report more samples per second to FA servers. In my case the stats actually can go down some when using 20MHz…
Probably the R2 can get cleaner 20MHz samples due to better hardware…
I ran the Mini @ 20Mhz for at least a month on a Pi4 without dropped samples or dropping from MLAT with timing issues. Are you plugged directly into the Pi, or are you running a USB extension between the radio and Pi? If so, plug her in directly and report back.
Of course you want to create an argument, otherwise you wouldn’t have made that post.
Not creating an argument would be asking how to make it work, to which the best answer would be: Get a Pi4 so you have a known setup.
USB is being pushed to the limits with 20 MHz, so the USB system needs to be working top notch.
If he were using a Pi4, i’m quite certain we wouldn’t having be this discussion.
Ohhhhh - didn’t realize it wasn’t on a Pi4. Yeah, I tried on a Pi3B overclocked to hell and it ran OK, but even I wasn’t comfortable with running it that way and I like keeping things running on the edge…lol
It’s too much USB bandwidth like @wiedehopf mentioned for a Pi3 or older to handle reliably. This is a Pi4 thread, so I did the bad thing and ASS-u-ME’d.
How much bandwidth are you using on Pi4? Saying that is to the limit… did you actually measure it?
Because mine does not lose ANY samples and still says “clock unstable”. I am curious how is this working on the Pi4.
PS - If questions about the hardware capabilities makes you uncomfortable, then you don’t have to answer 
Sounds that even “writing” on SD affects the rate?
You can calculate it. And it’s right at the limits for USB2.
The thing is, on the Pi3 even the Ethernet shares the USB bandwidth.
So using wirless instead of Ethernet is actually beneficial in that case.
If the data is lost on to the USB system, there is no message about lost samples, the software can’t determine if there is data lost on the USB system, only if it doesn’t have enough CPU to process those samples.
Well on a Pi4 running -e 8.95, evidently as much as she’ll handle because if I go above that, sooner or later it will crap out. (@24Mhz). I try to test limits during my peak traffic times, so that’s usually around 2400 msg/sec as graphed.
So far as measuring the actual USB bandwidth/throughput during those times - please advise how to do so and will gladly test and show results. That said, theoretics don’t interest me in the least - I’m all about real-world testing and results.
Remember that the USB hub shares bandwidth with ethernet (and sd?!) on Pi3-. That could be the determining factor.
Try this for example: Run and boot your Pi3 from a USB stick, no SD card at all and run a normal RTLSDR (no airspy) - see how long MLAT lasts… It’s a hardware roadblock unfortunately - no way around it besides coughing up dough for a Pi4 or other SBC with higher specs.
It’s not theoretical. I practically don’t get better results with 20MHz on Mini. I would say even worse than 12MHz.
So I am not sure if that is happening because of the Pi or actually the Airspy Mini, that’s all.
I don’t get why people get so upset about this…
PS: Sounds like Nitr0 has an R2. And that works well. Maybe that’s what I need to get.
With limited resources and -e now available to boost eh performance for 12 MHz, that’s actually expected.
There are enough people for whom the Airspy Mini works perfectly stable at 20 MHz with MLAT.
Most of those people have an RPi4.
You’ll need a more capable system for the R2 anyway, so better get an RPi4 first and check if that fixes your issue.
1 Like
I have a Mini as well as a couple R2’s now. I swapped the mini out recently to figure out where the edge lives with the Pi4. The Mini works fantastic in every way and I love the thing - highly recommended,
These last few posts should be moved to a Pi3 thread or something since this will end up very confusing to those reading…in a Pi4 thread. Pi4 works perfectly fine all the way up through an R2 and 24Mhz - With an Airspy (again not to confuse - nothing to do with Pi4 itself). 
Again, more than willing to test and post actual USB bandwidth use if can direct me how to do so. It may help clear some things up. I have every Pi revision to test and put it to bed.
1 Like
Looks like the command:
lsusb -v
Would show the USB details.
You could always try setting up Linux (no VM) on one of the laptops
Maybe the Linux drivers work better with the USB system.
Still, the RPi4 is probably the better way forward.
3 Likes
2 Likes
