I use the LNA PGA-103+ with a cavity filter. Rock solid
That PGA LNA looks interesting. Looks like a home brew out of Greece.
First, don’t confuse USB-C and USB 3.x. These are related, but completely different things.
Then consider that the R2 is currently the best ADSB/Mode-S option for the price. A new receiver will be more expensive without necessarily improving the reception by much as it is implementd in airspy_adsb utility.
On the other hand, the Ranger is a high-end SIGINT receiver with loads of dynamic range (20-bit) and sensitivity (-143 dBm MDS) from DC to UHF and an aggressively filtered narrow-band IF. A total waste for ADSB.
The proof is in the pudding. Many people compared the R2 and Mini to the top end receivers. The Airspies seem to perform the same or better, and most of the time, the limitations are physical (mountains, etc.) The main reason the R2/Mini - airspy_adsb combo works is related to the algorithms and the RX architecture, not the silicon per se. The airspy_adsb utility applies some corrections to the signal before the detection to fix the imperfections of the hardware. Improving the ADC/Tuner won’t change things by much, if at all.
If you want to improve over the existing, invest in everything else: Antenna, Cables, Filters, Amps and, of course, the Location.
Finally, I’d add that if I was totally invested in the flight tracking business, I would do many things differently to achieve low-cost and high-performance at the same time using COTS parts. Whatever happened to the new FlightAware hardware project?
1 Like
Good question. I suspect it isn’t a high priority because, from a business perspective, there would be very little benefit to the company. Improvement to overall network coverage would likely be very small, and with tendency of the feeders likely to buy it to feed multiple aggregators, that improvement would not be exclusive.
Thanks for your answers.
(I wasn’t confused about USB-C connector and the transfer rates of the various USB specifications. It was just that I didn’t see any references to what flavour of USB the Ranger plans to use in the (limited) material I’ve read about it.)
Just in the FWIW bucket, I picked one of these up to toy around with (as I dread the day my RTL-SDR finally dies, as it’s been fantastic for me). Anyways, I haven’t tested out this new unit out yet but plan on giving it a try this week. Looks like there has been a significant redesign on the product, when compared to the image on the site.
Edit: Now that I look into it, it appears I was shipped a different product than ordered. 
https://janilab.hu/index.php?route=product/product&language=en-gb&product_id=51&search=Wideband+vox
Too bad there was a longer outage because I stopped a process for troubleshooting and forgot to start it. But without looking to the gap, left Pi4 and right Pi5.
There are 3 receivers connected 2x RTL-SDR and 1x AirSpy. I my conclusion based right that the higher tracks are not increased via CPU but via the better USB chip/throughput on the Pi5?
SAMPLE_RATE= 12
OPTIONS= -v -t 90 -f 1 -w 5 -P 8 -C 90 -E 20
CPU governor Pi4 was performance and with Pi5 schedutil.
Remains the same
The ADS-B Tracks Seen chart isn’t the best choice for assessing performance. Its title is a bit misleading as it is actually displaying NEW tracks seen over the last one-minute period. I’ve had some perplexing results on this chart recently so I’ve read up on what it actually displays.
An aircraft is assigned a new track if it no messages have been received from it for more than 5 minutes. So if all of the aircraft within range of your receiver stay there for an hour and you receive messages from all of them at anything less than 5 minute intervals, this chart will show zero tracks per hour for the entire period.
The 8 minute exponential moving average also makes interpretation a challenge. The chart below is my interpretation of what the chart will display for a single new track being counted in a 1 minute interval (time zero):
The other thing to note is that the data is expressed in Tracks per Hour, so (without the exponential moving) 1 new track per minute would display as 60 Tracks/Hour on the graph.
Despite all that, the graph is still useful for telling you if you have a high proportion of new tracks with a single message (only one message received from an aircraft in the last 5 minutes) - that can be indicative of problems with your setup.
2 Likes
I’m using ADSBExchange Blue and ShipXplorer SDR dongles running readsb / tar1090 and AIS-catcher plus a few feed utilities on a RPi5. I tried on an RPi3 but had power supply issues as well as maybe not enough CPU grunt.
Is a RPi5 overkill? Sure! But for the price it’s still a bargain. Isn’t anything worth doing worth overdoing?
Over the past 48 hours it isn’t working up a sweat - that’s a good thing.
I just upgraded one of my feeders. I was running a Pi4 and Airspy Mini, and also a Pi3 with Blue Pro Stick (feed of same areal with a Mini Circuits splitter). For reference the areal is a FlightAware one, and the LNA is a SAWbird+ dual (though only using the 1090 feed).
The Pro Stick was about 230,000 positions and 300 planes per day lower than the Airspy Mini.
Got a Pi5 and Airspy R2, and replaced the Pi3 & Prostick. This combo is now (after 2 weeks) running (on average) about 62,000 (4.5%) positions and 30 (0.85%) planes a day more than the Pi4 & Airspy Mini. The R2 running at 20MSPS and the Mini 12MSPS.
Pi5 running at about 25% cpu.
So, the Pi5 / Airspy R2 is an improvement on the Pi4 / Airspy Mini, but (with maybe receiving so many planes in the first place already) not that much.
The improvement is probably down to the R2 / 20 MSPS and not the Pi5, but saying that the Pi4 system does loose MLAT every so often (I am using a external SSD, so USB bus is probably getting overwhelmed), while the Pi5 (also with a external SSD) has not.
If you are using the SDR into a USB-2 port and the SSD (or the other way around) into a USB-3 port, there should be no contention.
That’s not correct.
The SDR can’t use USB3 and the USB2 in the USB 2 + 3 ports are served by the same controller.
On the pi5 there are 2 USB controllers, each provides a USB2 + 3 port.
On a pi4 it’s only one USB controller and everything using USB2 will contend.
The USB3 uses separate data wires, one might expect that the whole USB3 port is connected to a different controller than the USB2 port but that’s not the case.
If it’s a USB3 SSD it’s possible that you don’t get USB contention but i wouldn’t even be certain of that. (on a pi4)
I’d just not use a USB SSD … but that’s just me.
2 Likes
Yes, the Airspy Mini is plugged into the USB3 port, and the SSD in the USB2 port. However because they are both USB2 devices I think they “plug” into the same USB2 bus.
As per Here
On the Pi4 the lsusb -t command shows:
pi@airspy:~ $ lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=usbfs, 480M
|__ Port 4: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 480M
pi@airspy:~ $
For a real comparison, you would need to run both in parallel side by side.
Even testing on a different day within the same timeframe can give a difference in results.
In my region the day with the lowest traffic is usually the Tuesday while highest traffic days are friday and saturday.
That said the blue FA stick can outperform on a Friday an Airspy running on Tuesday
And when you test it on a week, it can also change. I have a significant increase of traffic now per week after the easter holidays. So not comparable to the weeks before.
I would rate your results as “the same”. The only real difference can be the switch from 12 to 20 MSPS. But you can run also for testing the Airspy mini on 20 to see what will change.
They are running side by side. I have a splitter in the setup.
Think I have tried the Mini on 20 before, but noticed a drop in stats straight away and / or MLAT totally didn’t work.
Yes, that’s the disadvantage it may or may not work. I had it running for several days on 20 and not single problem during that time.
Appolologies - I was getting my models mixed up
Raspberry Pi 4
Raspberry Pi 4 offers two USB 3.0 ports and two USB 2.0 ports which are connected to a VL805 USB controller. The USB 2.0 lines on all four ports are connected to a single USB 2.0 hub within the VL805. This limits the total available bandwidth for USB 1.1 and USB 2.0 devices to that of a single USB 2.0 port.
On Raspberry Pi 4, the USB controller used on previous models is located on the USB type C port and is disabled by default.
Interestingly, the VL805 controller is a 4-port USB-3 device.
Did a test last year, and the Airspy devices, both R2 and Mini work better when connected to USB2 connections. Kinda feels like the USB3 connection on the Pi4 is a bit of a bandaid hardware/software implementation. It works, but not as well as the Pi4 USB2 configuration. There was a 2-3% improvement during high message rate conditions. Just thought I would mention my testing. Have fun out there.
Testing in the real world. Thank you.
1 Like