Short version: Adding UAT Orange Flightaware dongle stopped MLAT positions/planes and reduced Dump1090-fa received positions/planes.
I have two near identical Pi4/4gb with Airspy receivers. Both using Flightaware SD card images. One has an R2 and the other a Mini receiver. Software configurations and settings are identical. Operating off the same antenna, the R2 provides bias-T power to the RTL-SDR Low Noise Amplifier (LNA) near the antenna in the attic at 24 ft above local ground level. Daily reception is around 2400 planes with about 500,000 to 600,000 messages with the attic antenna (moved up there recently).
Both systems collect messages and planes with near identical results, usually different by less than 7 on messages and planes.
When I began experimenting with UAT reception, I did see local traffic, usually around 40 planes / 8000 messages. I did not dive into MLAT impacts at the time, but I could see a drop in ADS-B reception. When I had UAT connected from the restart count time, currently at 7pm CDT time in the USA, MLAT positions and planes were at zero the next morning at 10 am. No synchronization with other nearby receivers.
15 hours and MLAT with nothing, I removed the orange dongle and antenna and immediately I had MLAT positions and one plane showing up on my Flightaware page. I suspect the extra dongle affected the USB interface timing and thus the MLAT and Airspy USB timing.
The Orange dongle and antenna are now on a shelf. Not a good upgrade for my systems.
I had the same issue a few years ago. The airspy needs a lot of USB bandwidth for MLAT to work well. Adding a second dongle on the same device does not work well. You could add it to a second device and send the UAT data to the first device. Two rtl-sdr dongles on the same device should work.
UAT on orange stick and Airspy, MLAT and everything works fine with SAMPLE_RATE= 12 and option -p for bit packing. Tested with and without the UAT dongle on an RPI 4. Using for 2+ years.
I get 500,000 to 600,000 messages p/day. I think only stations with much higher traffic than this can get the 1 or 2% msgs benefit of using sample rate 20 vs 12. So try again with 12 and the -p option. Lots of success reported in the airspy threads in this forum.
If you’re interested in the underlying reason it’s probably a USB bandwidth/scheduling issue. (you’d need a hardware USB analyzer to be sure)
Both the rtlsdr and (AFAIK) the airspy are using USB bulk endpoints for data transfer. These endpoints work essentially by the USB host polling each device for data periodically; if the device has some data waiting to transfer, it’ll respond with a short packet of data. It’s up to the host to work out how to schedule this polling between all the different devices on the bus, there’s no dedicated bandwidth per endpoint and the devices don’t proactively push data to the host.
The practical limit for bulk transfer endpoints on a USB2 bus is somewhere around 300Mbps (see communication - Why are USB devices slower than 480 MBit/s - Electrical Engineering Stack Exchange for some of the gory details). The airspy in 20MSPS+packing mode wants to push around 240Mbps (20M real samples * 12 bits/sample). The rtlsdr wants to push around 38Mbps (2.4M complex samples * 16 bits/sample). That’s getting very close to the limit. Even if there is enough total bandwidth, the rtlsdr send-side buffer is pretty small and if there’s any imperfections in the host-side scheduling (and there will be!) then it may get starved (i.e. not polled for data) for long enough that the buffer fills and you drop data - and that means no more mlat sync …
In theory isochronous endpoints (which reserve bandwidth on the bus ahead of time) would help here but (a) the rtlsdr chip doesn’t/can’t do that and (b) isochronous endpoints are rarely used so hardware/software support is not so good.
