Airspy mini VS FA prostick : TL;DR not worth the extra money

FlightAware ADS-B Flight Tracking
81

As for Airspy performance, compared to the FA stick … my message rate as measured by msgs per second on 30003/tcp, did go up significantly when I moved from the FA Pro stick with built-in LNA and separate FA filter to an Airspy Mini with LNA4ALL + FA filter (the yellow graph is the important one, I’m graphing two sites on one page):

1721×789 196 KB

Number of planes not as much, but it did also go up.

Anyway, since then I’ve also changed the FA antenna for a DPD one which was another pretty good boost (but I’m still bitter about the steep shipping and especially customs charges to Europe :frowning:( ). And I’m starting to wonder … what’s the max number of messages per second that an Airspy/SDR setups in general can pick up?

Reason I’m asking, I feel like my message count is capped at 1500-1600 or so, giving very flat graphs. I hit that in the morning when plane count is only 150, plane count keeps climbing for a little longer yet the message count stays where it is.

1716×521 81.6 KB

So I wonder, am I not going to get much higher because of the antenna picking up a wide area, and messages from different planes cross-talking getting corrupted often, etc?

Oh yes, for completeness, my cmdline: /home/adsb/airspy/airspy_adsb -v -l 33333:avr -c localhost:30004:beast -w 2 -p -d 2 -f 1 -g 21 -b

So 2 workers, on a RasPi 3. Neither of the threads is maxing out a CPU so no capacity issues in that way.

82

You are comparing 2 completely different systems.

As has been said before, a true comparison is made with a symmetric splitter. A Mini-circuits ZFSC (for the correct frequency band) is a suitable hybrid splitter/combiner with good port isolation. Use your external Amp and filter before the splitter if you like.

/M

83

Oh, obviously. Wanted to add a datapoint, but I knew it wasn’t terribly scientific. :slight_smile:

My question was more about the max message rate which seems so much capped. I wonder what rate others are getting…

84

There is something of a negative feedback loop on message rate as

(a) as you see more messages, there are more collisions causing garbled messages;
(b) some systems like ACAS will throttle back message power/rate in response to a busy environment;
(c) (hypothetical) SSRs typically have a fixed interrogation rate budget, so interrogation rate per aircraft drops off when there are more aircraft

In my experience it is uncommon to see >1500 mode S messages/second

85

Thank you, this is what I was starting to suspect indeed. I read reports of much higher message rates here and there, but didn’t seem that plausible.

It sounds like if I want to increase my rate any further I’ll have to work with two or more directed antennas for example?

86

Yep, sectorized antennas each with their own receiver is probably the way to go there.

87

I’ve been wondering about four cubical quads pointing to the cardinal points. A bit of reading suggests they offer good gain for not many elements, easy to make, not much wind resistance.

I’ll make a separate thread if I get anywhere.

88

Might be something for ABCD567 to have a go at too - might be ideal to poit at the window in his 8th floor toronto condo - where he can’t see to the west due to the building being in the way.

89

I had a quick play with 4NEC2 this afternoon and came up with this :open_mouth: If I get the approval of abcd567 then I’ll make another thread.

https://img2.brain4.photobox.com/792230221188a9f75582a695f1dba265256d17bd53945da394b084142c79b683977dfd2d.jpghttps://img2.brain4.photobox.com/27463123a16ad64e8ebf6f1a10fb322ecf7db24001c09c3b764169294b544ab723056cd3.jpghttps://img2.brain4.photobox.com/46555633b7a942b74f0216cdf2acc1b3a9d5fef9b8587c5dffd5788913acb261e2827cd8.jpg

https://img2.brain4.photobox.com/00205122b073df1a2019f818541a59d51383ea51b9f010bc3e1255b81562902eaa8b1137.jpghttps://img2.brain4.photobox.com/91964987c38a2a577837f08d8f4f913a070b9010f320471da8e2d463d93339284347265a.jpghttps://img2.brain4.photobox.com/3511983430bcd10c0947a40ec5fa181ad943efdf81addb1c0c05d4bc2e6b9375f22b4a57.jpg

https://img2.brain4.photobox.com/255331324a6141d578abd6043a1ef09f0c0ac7b5113a4eff90417099bf7471e28e22107e.jpg

https://img2.brain4.photobox.com/85866433805c052a5ad359931bd933f2d0af1f16771c091af4b004189c98b927ca7dcacc.jpg

{Edit} added last image

90

@triggers
Your suggestion to start a new thread dedicated to directional antennas is a very good idea.
The antenna simulation posted by you shows a very promising antenna. Looks easy to build, hope it is easy to get right as well.
Did you fabricate and try it?

@PeterHR
Great idea to try a high gain directional antenna where omani-directional view is not available.
I will make a simple one as a trial to see how it goes.
I think I will start with the one shown in photo below after stealing my wife’s kitchen strainer. :unamused: :wink:

800×450 52.4 KB

91

Thank you and others, this is getting interesting. :slight_smile:

(But my apologies for taking this current topic off-track a tad bit!)

92

I’ve started a new thread called “Directional antennas”

93

Wanted to check in after a couple months of toying around - mainly wanted to post some side-by-side results between RTL based units and the Airspy Mini to see if processing power makes any difference. We already observed that there is not much difference between the two while running on a Pi3, or minor at most.

Have been dabbling around and got the latest PiAware to run perfectly on a VMWare Debian8 install with RTL based dongles. MLAT and everything is working perfect through VM. There is no overall performance difference between a system running on a Pi3, or through an i7-driven VMWare setup. Stability and performance tested for at least a week of non-stop uptime through a good splitter with one side going to the Pi and the other to the virtual machine.

Figured this would be a perfect time to test whether or not processor power was holding the AirSpy back while running on a Pi3, so I compiled and and installed the lastest airspy tools on the VM but always get the “airspy_open() board 1 failed: AIRSPY_ERROR_NOT_FOUND (-5)”, no matter what I do. Have tried the latest Ubuntu and Debian builds, even went up to Debian SID and still couldn’t see the airspy. Now before anyone lets loose with the “VMWare is not the best idea to run SDR through” bit, I realize this, but I have proven that RTL based dongles work just fine through VM - right along with full working MLAT. I’ve also compiled the latest GrOsmoSDR with noted patches that show on the airspy wiki to no effect. Get the same error on older <3.17 kernels as well as with latest. Blacklisting, etc - same error.

I figure since RTL based dongles have no issue with VM, then airspy should be fine as well, but I was wrong. Guess will need to try a Metal install to give it another whirl.

If anyone has a method to install the proper airspy drivers on a Debian or Ubuntu setup, please feel free to chime in. Have been up and down the airspy wiki to no avail.

EDIT: Here is what shows in dmesg, so kernel is seeing the thing:



   25.082236] usb 1-1: new high-speed USB device number 2 using ehci-pci
   25.342447] usb 1-1: New USB device found, idVendor=1d50, idProduct=60a1
   25.342448] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
   25.342449] usb 1-1: Product: AIRSPY
   25.342450] usb 1-1: Manufacturer: www.airspy.com
   25.342450] usb 1-1: SerialNumber: AIRSPY SN:04A464C8371B2D0B

Here is airspy_info output on same setup:



gori@ubuntu:~$ airspy_info
airspy_lib_version: 1.0.9
airspy_open() board 1 failed: AIRSPY_ERROR_NOT_FOUND (-5)

^^^ That was with the latest Ubuntu, but same error through Debian Jessie through SID:

Linux ubuntu 4.8.0-34-generic #36-Ubuntu SMP Wed Dec 21 17:24:18 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

94

Different setup, but I’ve used the Airspy with the Windows-based adsb receiver, on Windows 10 inside a VM on my Linux always-on machine, no problems. Getting the host OS to pass through a device to VMs can be a pain but judging from your commands, that bit’s taken care of as well. Do you also see the device in “lsusb” output? It should look like this more or less:


Bus 001 Device 005: ID 1d50:60a1 OpenMoko, Inc.

(Bus and device number will be different.)

If the airspy tool isn’t working, likely it’s either because a kernel driver claimed it (but not very likely) or a permission issue. Take the bus and device number from the output above and check the device owner, like this:


root@radar:~# ls -l /dev/bus/usb/001/005
crw------- 1 adsb root 189, 4 jan 28 20:38 /dev/bus/usb/001/005

Likely that’s rw for just root in your case? You’ll need an udev rule similar to the rtlsdr one to fix it. This is mine:


root@radar:~# cat /etc/udev/rules.d/51-airspy.rules 
SUBSYSTEM=="usb", ATTRS{idVendor}=="1d50", ATTRS{idProduct}=="60a1", MODE="0600", OWNER="adsb"
95

from above
“We already observed that there is not much difference between the two while running on a Pi3, or minor at most.”

I am not sure why you see this. I have an Airspy running on an Odroid XU4 and it takes 100% of 4-8 CPUs all day.
I moved it from an RPI3 to an Odroid XU4 because the RPI3, running nothing else, ran at 100% CPU from about 6AM to 12AM local time.
Mine takes way more CPU than a STD RTL-SDR or FA dongle.

I am in Busy NYC, however, my airspy antenna (FA antenna) is not that high(inside my attic 20m AMSL) so I only see 100-150 aircraft at a time.
My airspy site
flightaware.com/adsb/stats/user/ … tats-20037

96

Thanks for the reply mate.

http://puush.hopto.me/VAx0

I added the udev rule to this Ubuntu build after your reply. Tried that road on Debian prior - still nothing under user or root.

Slightly perplexed, but it’s gotta be user error…

97

Hi Jon, are you still running “ondemand”? If so, whack it and set to “performance” to get rid of the extra cpu interrupts generated by the throttle.

When running RTL based, with no other changes other than throttle, overall CPU use goes from ~24% to ~11% on my site(s)

Here is my site: flightaware.com/adsb/stats/user … tats-24259
It appears you have more aircraft than I do, but we’re pretty busy on this side as well

Can see here where/when I swapped in the airspy from the silver v3 dongle (Pi3):
http://puush.hopto.me/PMZN

Here is a better (in my opinion) reflection of CPU use while running the Airspy on Pi3 (currently 162 Aircraft being tracked):
http://puush.hopto.me/AITy

Plenty of room to spare so far as I can see. Every setup/site will be different of course.

EDIT: Here is how I invoke the airspy:
_sudo airspy_adsb -c localhost:30104:beast -d 2 -p -n -w 4 -g 18 -f 0 &

Here are (2) identical Pi3 (RTL)setups, one using the stock ‘ondemand’, the other using ‘performance’ - no other changes. The second one is where I swapped in the airspy just recently - very easy to tell when that took place:

http://puush.hopto.me/lofG
http://puush.hopto.me/0cjl

98

I agree that you seem to have plenty of head room.

My setup this afternoon
pi@odroidxu4:~$ top
top - 17:36:36 up 7 days, 7:55, 1 user, load average: 3.49, 3.30, 3.15
Tasks: 150 total, 2 running, 148 sleeping, 0 stopped, 0 zombie
%Cpu(s): 20.1 us, 8.0 sy, 0.0 ni, 69.0 id, 0.0 wa, 0.1 hi, 2.9 si, 0.0 st
KiB Mem: 2038108 total, 647248 used, 1390860 free, 26576 buffers
KiB Swap: 131068 total, 0 used, 131068 free. 326304 cached Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
665 root 20 0 70432 5528 672 S 118.8 0.3 12316:11 airspy_adsb
10908 piaware 20 0 11780 6680 3124 S 41.7 0.3 740:59.75 fa-mlat-client

I am not familiar with “Ondemand” and “Performance”. What do they refer to?

99

Ondemand and performance are frequency scaling governors. By default, most linux OS’s use ondemand, which (keeping it simple here) is a dynamic scaling feature that basically increases the cpu frequency to it’s max and then takes samples of the idle load for a nominal period of time and steps the frequency down based on some preset thresholds - read dynamic here. Note that Rasbian simply flips MAX and MIN (BAD). It does this on a per-core basis and is meant to be a power saving feature. After all, there is no reason to keep your CPU cores scaled up to max frequency when you have a “bored” system. This is great except it’s quite expensive for lower MIPs processors and basically useless for our SBC’s which suck ~3 watts to begin with with. Ondemand is one of the worst for “overhead” due to the various factor algo’s, thresholds, and interval parameters it uses. The big-core Intel and AMD guys will disagree with me, but the overhead is next to nothing on those processors, so it is worth while in that scenario. Changing to performance simply pegs your cores to their max working frequency.

Sorry for pasting a picture of how to change, but this forum is setup too tightly to post cmdline arg’s without getting punted:
http://puush.hopto.me/ZcCT

Here is a nice link to learn a little more about what’s under the hood with various scaling governors:
https://www.kernel.org/doc/Documentation/cpu-freq/governors.txt

EDIT: All this said - this doesn’t mean that the Airspy isn’t being held back by the Pi3 - have to remember that it chews up a lot of the USB bus which is also attached to the LAN, and the regular Airspy may also require more overhead than an AirSpy Mini being it has a higher sample rate. If can get the sucker up and running through the VM, it may shine a light on some answers, but it’s looking like the test will need to be made on a metal install so the multiple VM layers are not part of the equation. To be continued I guess…

100

Note that the increased CPU usage as a percentage is entirely expected with “ondemand” and doesn’t mean that the “extra” CPU is the overhead of the governor.
It just reflects that the CPU is running slower, so the same load will take more time to execute (and so the CPU is busy - at the lower clock rate - for longer)

If you wanted to measure the overhead of ondemand, you could

a) run with the ondemand governor, see what clock rate it settles at (see e.g. “cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq”), do your measurements; then
b) use the performance governor and limit it to the same frequency, do your measurements.



  echo "performance" >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
  echo "700000" >/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq

If you’re doing performance comparisons of userspace stuff it does make sense to fix the governor at a single frequency so you’re comparing apples with apples.