FlightAware Discussions

Airspy Mini - M12 vs M20

I finally decided to abandon the Ethernet piping between the airspy_adsb and the dump1090-fa and I have installed Linux natively on my Dell Latitude E6420 (dual boot).
As a result I can now pus the -e all the way to 10.0 and MLAT stays connected. Hence the timing errors were due to the network (Pi3 Ethernet port?) and not the USB like I was told. CPU usage of one core is about 73% with m12 and about 81% with m20.

Finally I was able to run two tests, with the same gain and same -e parameter, at -m 12 and -m20. Well, on my system, the performance of the -m12 is not that much better (more or less equal) than the one of -m20.
I am sure that this in not due to my computer setup. Is this is because when pushed with m20, the Airspy Mini starts to have higher noise and cancels the 20MHz advantage?
12MHz - 85 aircraft and 721 msg/s:

20MHz - 88 aircraft and 734 msg/s:

Those are a few seconds apart (edit the config, restart the services, wait for stabilization) and are in the normal fluctuation of the numbers…

Ah watching this post
going to try same myself later on today
i have many pc/server /pi to keep me busy

Glad you got it. Ethernet traffic pipes through USB on Pi3 and below - IE shared traffic, so that explains why your setup was crapping out with anything > 12Mhz - is what @wiedehopf tried to explain a few times - so in the end, it does boil down to USB. :upside_down_face:

BTW, you won’t see an immediate day and night change between 12 and 20/24Mhz (airspy), but many more messages are being processed through preamble and whether most end up orphaned or not, valid messages add up during the day with higher position and plane counts. It can really be seen when running two identical setups side by side which takes the traffic, weather and other variations out of play. Glad to see Windows out of the way since their drivers are complete trash at the hardware level - simply too many layers to pound through to be worth a damn when pushing throughput limits.

Also, you can most likely eliminate -p (packing) on your setup - no use spending extra cpu on something you don’t need anymore.

Yeah, switching off packing is recommended unless it’s needed for 24 MHz with the R2.
It’s extra load on the Airspy Mini integrated processor.
While it shouldn’t affect performance, my experience has been that it’s more likely to be stable without packing.

The 12 to 20 MHz difference is bigger for people with large coverage in central Europe due to the high number of overlapping messages.
The rest of the world seems to have less of those, thus the difference between 12 and 20 MHz is smaller.

Congrats on getting it running! :slight_smile:

1 Like

This morning, with extra low traffic, I saw on my map 11 planes with positions and a lot of bogus “other” planes up to 45 “other”. One with an altitude of 105000 feet… yeah, sure.

I had reduced the “e” from 10.0 to 9.0 and lo and behold, the bogus aircraft were eliminated - now I see 10 planes with positions and 17 without. That’s more normal and cuts down the CPU usage to like 60% (from 80%).

I did also cut out the -p, makes sense to lessen the load on the Airspy. Seems that indeed didn’t affect anything for now.

PS: This is the laptop with the i7, quad core HT… see the eight cores above, seven idling. I might apply the same dual boot treatment to the other E6420, the one with i5 - dual core HT. Has slightly lower boost frequency, but I think will be fine for this.