Combo Feeder Statistic Issue

[ca249]

Definition of the issue:

Given two identical feeders with common antennas, one feeder in the stand-alone
role receiving 1090MHz only and the other in the combo role receiving 1090MHz
and UAT signals, the combo feeder will produce about 8% fewer mode-s aircraft
count stats and 40% fewer MLAT aircraft count stats than the stand-alone feeder.
Included below are two test cases with data to support this finding.

Test feeder hardware:

I am using two RockPi4Bs 4GB for these tests. These are RPi alternatives.
They both run recent 64b Armbian desktop images. Both feeders are running
performance governor. Both feeders are running PiAware (Debian Package
Add-on)3.8.1 Many thanks to Nitr0, abcd567, and AD5MT for shortening my
learning curve with the builds.

Both feeders have an Airspy R2 and Orange dongle installed. The R2 receivers
use the following parameter string: -v -f 1 -e 9.4 -w 3 -t 600 -g 20 -m 24.
The gain on the Orange dongles is 25.4. While in the stand-alone role the
dump978-fa service is stopped and disabled.

The 1090MHz signal path is: rockpi4B>R2>3 way splitter>bias-t>
RTL-SDR Blog 1090MHz triple filtered LNA>50’ LMR400 coax>DPD 1090MHz antenna.

The 978MHz signal path is: rockpi4B>Orange>3 way splitter>Uptronics UAT SAW
filter LNA>FA 1090/978 round blue filter>50’ LMR400 coax>DPD 978MHz antenna.

At the bottom of the post are scroll blocks with the supporting data
for each test case presented here.

Test Case #1: Both feeders in the combo role
The scrolling block shows piaware messages counts of data being sent to the
Flightaware servers for which both feeders are in the combo role.
Also shown are the stats that were returned to the feeders’ stats pages at
the end of the 24 hour UTC day. Notice that the counts of the messages
sent to FA and the returned aircraft count stats are almost identical for
both feeders. For this test the UAT input for the rock1090 feeder was
aggragated from a remote feeder. That feeder’s Orange dongle gain was
set to 25.4. Whether the UAT data is produced locally on the feeder or
aggragated from a remote feeder has no effect on the test.

Test Case #2: One feeder in combo role, the other in stand-alone role
The hostname rockaware is in the combo role, receiving both 1090MHz signals
and UAT signals. The hostname rock1090 is in the stand-alone role.
The dump978-fa service is stopped and disabled. The counts of the
dump1090-fa messages sent to FA from the piaware service are almost
identical for both feeders. The mode-s stats returned to the combo
role feeder are about 8% less than the mode-s stats returned to the
stand-alone role server. Also MLAT stats returned to the combo role feeder
are about 40% less than those returned to the stand-alone feeder.

These resulting stats are not a fluke. These results are repeatable and
the roles of the feeders can be reversed with the same results.

I understand that message counts to FA may not directly correlate to
aircraft counts received on the feeder’s stat page.

Why are the aircraft counts to the combo feeder reduced compared to the
aircraft counts to the stand-alone server?

Anyone have thoughts as to why this is occuring?

Checks for the following items have been made with no issues found:

1. USB bandwidth
2. Power supply
3. RF interference between SBCs/dongles/receivers

Test Case #1 Results: Both feeders in the combo role

Linux rockaware 5.4.49-rockchip64 #20.05.7 SMP PREEMPT Sun Jun 28 18:17:52 UTC 2020 aarch64 GNU/Linux

Sep 30 17:00:05 rockaware piaware[8297]: 836063 msgs recv'd from dump1090-fa (5071 in last 5m); 833490 msgs sent to FlightAware
Sep 30 17:00:05 rockaware piaware[8297]: 101515 msgs recv'd from dump978-fa (702 in last 5m); 101258 msgs sent to FlightAware

Oct 01 17:00:05 rockaware piaware[8297]: 2098762 msgs recv'd from dump1090-fa (7063 in last 5m); 2096189 msgs sent to FlightAware
Oct 01 17:00:05 rockaware piaware[8297]: 248510 msgs recv'd from dump978-fa (812 in last 5m); 248253 msgs sent to FlightAware

Oct 1 msg totals:  dump1090-fa  1262699
                   dump978-fa    146995

  10/1/2020
Mode-S  2,465
UAT       255
MLAT       40
Other      50
Total   2,810


Linux rock1090 5.7.15-rockchip64 #20.08 SMP PREEMPT Mon Aug 17 00:26:28 CEST 2020 aarch64 GNU/Linux

Sep 30 17:00:04 rock1090 piaware[9106]: 219535 msgs recv'd from dump1090-fa (5034 in last 5m); 219535 msgs sent to FlightAware
Sep 30 17:00:04 rock1090 piaware[9106]: 17530 msgs recv'd from the ADS-B data program at 192.168.1.101/30978 (729 in last 5m); 17530 msgs sent to FlightAware
 
Oct 01 17:00:04 rock1090 piaware[9106]: 1485852 msgs recv'd from dump1090-fa (7125 in last 5m); 1485852 msgs sent to FlightAware
Oct 01 17:00:04 rock1090 piaware[9106]: 166673 msgs recv'd from the ADS-B data program at 192.168.1.101/30978 (825 in last 5m); 166673 msgs sent to FlightAware

Oct 1 msg totals:  dump1090-fa  1266317
                   dump978-fa    149143


  10/1/2020
Mode-S  2,462
UAT       258
MLAT       39
Other      49
Total   2,808

Test Case #2 Results: rockaware in the combo role, rock1090 in the stand-alone role

Linux rockaware 5.4.49-rockchip64 #20.05.7 SMP PREEMPT Sun Jun 28 18:17:52 UTC 2020 aarch64 GNU/Linux

Oct 06 17:00:05 rockaware piaware[8297]: 8274391 msgs recv'd from dump1090-fa (7394 in last 5m); 8268727 msgs sent to FlightAware
Oct 06 17:00:05 rockaware piaware[8297]: 910768 msgs recv'd from dump978-fa (1301 in last 5m); 909852 msgs sent to FlightAware

Oct 07 17:00:05 rockaware piaware[8297]: 9703728 msgs recv'd from dump1090-fa (7165 in last 5m); 9698064 msgs sent to FlightAware
Oct 07 17:00:05 rockaware piaware[8297]: 1103180 msgs recv'd from dump978-fa (1433 in last 5m); 1102264 msgs sent to FlightAware


Oct 7 msg totals:  dump1090-fa  1429337
                   dump978-fa    192412

  10/7/2020
Mode-S  2,381
UAT       270
MLAT       48
Other      42
Total   2,741



Linux rock1090 5.7.15-rockchip64 #20.08 SMP PREEMPT Mon Aug 17 00:26:28 CEST 2020 aarch64 GNU/Linux

Oct 06 17:00:03 rock1090 piaware[7020]: 1083781 msgs recv'd from dump1090-fa (7393 in last 5m); 1083777 msgs sent to FlightAware
Oct 06 17:00:03 rock1090 piaware[7020]: 92019 msgs recv'd from dump978-fa (0 in last 5m); 92019 msgs sent to FlightAware

Oct 07 17:00:03 rock1090 piaware[7020]: 2515108 msgs recv'd from dump1090-fa (7151 in last 5m); 2515104 msgs sent to FlightAware
Oct 07 17:00:03 rock1090 piaware[7020]: 92019 msgs recv'd from dump978-fa (0 in last 5m); 92019 msgs sent to FlightAware


Oct 7 msg totals:  dump1090-fa  1431327
                   dump978-fa         0

  10/7/2020
Mode-S  2,597
UAT         0
MLAT       79
Other      45
Total   2,721

[obj]

@ca249

piaware messages counts of data being sent to the
Flightaware servers

For the sort of comparisons you want to make, you need to measure raw message rates / aircraft counts directly on the receiver. The FlightAware stats include a lot of summarization which will have unpredictable effects.

@ca249

Checks for the following items have been made with no issues found:
[…]
3. RF interference between SBCs/dongles/receivers

Given that RF interference would be my first guess, I’m intrigued how you came to that conclusion.

[Nitr0]

@ca249

The 1090MHz signal path is: rockpi4B>R2>3 way splitter>bias-t>
RTL-SDR Blog 1090MHz triple filtered LNA>50’ LMR400 coax>DPD 1090MHz antenna.

The 978MHz signal path is: rockpi4B>Orange>3 way splitter>Uptronics UAT SAW
filter LNA>FA 1090/978 round blue filter>50’ LMR400 coax>DPD 978MHz antenna.

I know this isn’t answering your direct question, but I think you could improve your signal paths and get dramatically better results: You have an already fantastic setup, but a few things I’d try if it were mine. (Very close to one of my rigs as a matter of fact)

1090 Path: You are catching approximately 2dB signal loss between antenna and the triple-filtered LNA. What’s the splitter for?
I’d try 1090: rockpi4B>R2>bias-t>50’ LMR400 coax>RTL-SDR Blog 1090MHz triple filtered LNA>DPD 1090MHz antenna.

978 Path: This time you are catching 2dB cable plus insertion losses of (2) filters (-4.5dB) prior to amplification - ~25% of the signal. You would more than likely be safe ditching the FA Blue filter from this path.
I’d try 978: rockpi4B>Orange>bias-t>50’ LMR400 coax>Uptronics UAT SAW filter LNA>DPD 978MHz antenna.

Perhaps you were clear about the splitter and I missed the entire thing, but I left it out in my examples (for now) since it chops your signal on each path in half. I suspect it’s inline just for the side-by-side tests.

More than curious what the results would look like then. When doing side-by-sides, you may also want to look into setting up Virtual Radar Server on another PC on the network and pipe both outputs to it - this way you can pull the real-time stat screen up for each unit and have them side-by-side as well. No need to rely on FA stat logs.

Not sure if this helps or hinders anything. i think I need to read the original post a few more times to digest, but the paths caught my eye right off the bat.

[ca249]

@obj

For the sort of comparisons you want to make, you need to measure raw message rates / aircraft counts directly on the receiver. The FlightAware stats include a lot of summarization which will have unpredictable effects.

That is good to know, thank you.

@obj

The FlightAware stats include a lot of summarization…

Are those summarizations done in piaware or on the FA servers?

@ca249

Checks for the following items have been made with no issues found:
[…]
3. RF interference between SBCs/dongles/receivers

@obj

Given that RF interference would be my first guess, I’m intrigued how you came to that conclusion.

I wrapped the R2 and Orange dongle in aluminum foil. Saw no change. Then, for the Orange dongle I replaced the 6 inch USB extension cable with one ferrite bead for a 20 inch extension cable with two ferrite beads. No change.

Today both of the feeders are in the combo role. On one of them I have moved the R2 20 inches to
the left and moved the Orange dongle 40 inches to the right. I will post up results after the close of
the UTC day tomorrow. Previously I had four feeders and six dongles/receivers in an 18 inch diameter
circle.

[obj]

@ca249

Are those summarizations done in piaware or on the FA servers?

They are done in piaware.

@ca249

I wrapped the R2 and Orange dongle in aluminum foil. Saw no change. Then, for the Orange dongle I replaced the 6 inch USB extension cable with one ferrite bead for a 20 inch extension cable with two ferrite beads. No change.

How did you rule out LO leakage via the antenna feed? What’s the isolation specs on your splitter?
You could try selectively replacing the SDR ↔ splitter paths with terminators on both sides while keeping the software setup unchanged.

@ca249

Checks for the following items have been made with no issues found:

1. USB bandwidth

This would be my next guess after RF problems. How did you verify no USB problems? (This is notoriously hard as the rtlsdrs can silently drop samples well before the bus is saturated, and I believe it’s possible for the airspy to silently drop samples in some cases)

[ca249]

@Nitr0

What’s the splitter for?

I only have enough real-estate for two antenna masts. I have four feeders and six
dongles/receivers to support. For troublshooting a problem like this I want as much as
possible to be constant so that the varibles are easier to spot. It is a lot easier
to compare apples to apples.

@Nitr0

I’d try 1090: rockpi4B>R2>bias-t>50’ LMR400 coax>RTL-SDR Blog 1090MHz triple filtered LNA>DPD 1090MHz antenna.

I’d try 978: rockpi4B>Orange>bias-t>50’ LMR400 coax>Uptronics UAT SAW filter LNA>DPD 978MHz antenna.

I understand. I know that placing the LNA nearer the attenna is ideal but there are many
practicalities to be considered.

Providing weatherproof enclosures.
Increased wind loading to already flimsy masts.
Signal losses and maintenance issues due to addition of cable adaptors to match remote LNAs.
Troubleshooting/maintenance/replacement requires a roof visit and mast pull-down.
Every trip to the roof risks damage to the roof and me.

I have a new Kuhne LNA sitting here on my desk. I am considering building a gound mounted
mast stuck in umbrella stand and testing the Kuhne in my shack and at the antenna. If the results
are worth the effort, I may replace the existing 1090MHz mast with something sturdier.

@Nitr0

Perhaps you were clear about the splitter and I missed the entire thing, but I left it out in my examples (for now) since it chops your signal on each path in half. I suspect it’s inline just for the side-by-side tests.

At this time, yes. I suspect that when this particular issue is resolved I could fall
back to fewer feeders. But what fun would that be? There will always be something new to try.

@Nitr0

More than curious what the results would look like then. When doing side-by-sides, you may also want to look into setting up Virtual Radar Server on another PC on the network and pipe both outputs to it - this way you can pull the real-time stat screen up for each unit and have them side-by-side as well. No need to rely on FA stat logs.

I plan to keep plugging along on this post until I either resolve this issue or give up in frustration.

VRS sounds very interesting. I will research it.

Thank you for your help.

[mikkyo]

You could put the waterproof box under the eave, with the kuhne in it (I have a similar set up).
If your eaves don’t, leak, you can probably just mount it underneath without the box, just make sure you have a drip loop from the mast cable before the LNA.

I added a T to my mast so I can mount 2 antennas on each end, in addition to where the T connects. That would give you more room for even more antennae!
I have both DPDs as well and a RockPi and RPI4b.
Good setup! How tall are your masts?

[Nitr0]

You have a killer setup, lots of money spent. I’d love to see you get the best performance out of it. As anyone here will tell you, it’s all about tradeoffs. If you can make it logically work, get the LNA as close to the antenna as possible. The paths you outlined are somewhat detrimental to overall performance in my opinion.

Taking your UAT path for instance (as described above), you are only seeing about 25% (being generous) of the antenna downlink (sorry, I’m an old sat guy). If you do the math, it’s probably worse (Antenna >-2dB cable, -2.5dB FA Filter, -2dB Uptronics filter, +~18dB Uptronics LNA, -half splitter) My rough calculations show -6.5dB before your signal even hits amplification, and then heading into the Orange radio that noise (what’s left of the original signal) gets “amplified”.

I love anything “Kuhne”, they make some of the best quality gear I know of. If you are willing to spend the money for that then I’m of the opinion that you may be able to rearrange a few things to make your cash output work better for you. (Nobody asked, apologies).

I’m super interested to see how things progress for you with some experimentation.

I realize I still haven’t answered your original questions and I apologize. Curious where this goes…

[wiedehopf]

@ca249

The R2 receivers
use the following parameter string: -v -f 1 -e 9.4 -w 3 -t 600 -g 20 -m 24.

24 MSPS will never work together with an rtl-sdr on the same USB 2.0 bus, which in 99% of hardware includes ALL USB ports.

-m 20 -p or -m 12 is what you can try when you want to run another SDR on the same hardware.
Depending on the hardware, it will only be stable with -m 12 as it depends a lot on the USB chipset and the drivers for it.

[Nitr0]

RockPi 4b has two USB controllers, works fine when plugged into each side. RPi cant handle it unfortunately.

[wiedehopf]

@Nitr0

RockPi 4b has two USB controllers, works fine when plugged into each side.

I really don’t care in this case.
-m 24 alone might be too much and actually require running -p … hmm maybe -m 24 automatically enables -p if i remember correctly.

The described sharp drop in MLAT suggests samples being lost.

The performance for 24 MSPS isn’t so much better, so the simplest thing to do is change it to -m 12 and check the stats.
If it changes, some kind of USB issue is more or less confirmed.

[Nitr0]

I think @wiedehopf may be on the right track, especially if both radios are plugged into the same controller (both plugged into the USB3 ports (or both in the USB2 ports) for example), even if not, I think he laid out the perfect test to perform by dropping the sample rate to see what comes out of it. Dropped samples could most definitely produce the results you are seeing.

[wiedehopf]

@Nitr0

RockPi 4b has two USB controllers, works fine when plugged into each side.

What exact configuration are you running?

[Nitr0]

@wiedehopf

What exact configuration are you running?

It depends what day you ask me on

While it’s an older thread, this system has been chugging away ever since I set it up initially:

RockPi 4B Experiments

I finally bit the bullet and bought one of these RockPi 4B boards for some experimentation: I’ve been holding off since distro support for most RK3399 boards has been sparse to say the least, but these guys have been gaining steam and their support forums are quite active now: https://wiki.radxa.com/Rockpi4/downloads After scouring through this board’s schematics, I noticed that it contains separate lanes for USB3.0 and USB 2.0 hubs unto the SOC. (Multiple hubs) - Which got me wondering if i…

[ca249]

@obj

How did you rule out LO leakage via the antenna feed?

I did not rule out LO leakage. I do recall reading somewhere about Airspys being leaky on the front end.

Assuming that that is what is contributing to this stat issue I see, I am considering removing the splitters entirely and start testing from scratch.

@obj

What’s the isolation specs on your splitter?

Around 22dB depending on the port.
The splitter datasheet is here.

@obj

How did you verify no USB problems?

Monitored for dropped samples in logs.
I ran usbtop with one or both dongle present.

[ca249]

@mikkyo

You could put the waterproof box under the eave…

That picture is a little deceiving. The eve you see is the second story eve. That would be way too
dangerous working on that high a ladder…

@mikkyo

I added a T to my mast so I can mount 2 antennas on each end, in addition to where the T connects. That would give you more room for even more antennae!

My masts are too flimsy to do that. Right now they are a 10 foot piece of 1" EMT rigid conduit with a 8 foot piece of 3/4" EMT conduit telescoped two feet inside and then bolted together for 16 feet total.
They were ok with FA antennas but the DPD antennas are longer, heavier and have much more wind loading.

[ca249]

@wiedehopf

@Nitr0

RockPi 4b has two USB controllers, works fine when plugged into each side.

What exact configuration are you running?

I changed rockaware to from -m 24 to -m 20 around 8:00 this evening. Both feeders are in the combo role. It have been about four hours since the change. The aircraft counts are still ± 1, so no change.

Here is a usbtop at -m 24 and -m20.
Further down are some lsusb listings.

Bus ID 0 (All USB buses)	To device	From device
  Device ID 1 :			0.00 kb/s	0.00 kb/s
  Device ID 2 :			16.24 kb/s	15641.38 kb/s
Bus ID 1 (USB bus number 1)	To device	From device
  Device ID 1 :			0.00 kb/s	0.00 kb/s
  Device ID 2 :			1.06 kb/s	1018.41 kb/s
Bus ID 2 (USB bus number 2)	To device	From device
  Device ID 1 :			0.00 kb/s	0.00 kb/s
Bus ID 3 (USB bus number 3)	To device	From device
  Device ID 1 :			0.00 kb/s	0.00 kb/s
Bus ID 4 (USB bus number 4)	To device	From device
  Device ID 1 :			0.00 kb/s	0.00 kb/s
Bus ID 5 (USB bus number 5)	To device	From device
  Device ID 1 :			0.00 kb/s	0.00 kb/s
Bus ID 6 (USB bus number 6)	To device	From device
  Device ID 1 :			0.00 kb/s	0.00 kb/s
Bus ID 7 (USB bus number 7)	To device	From device
  Device ID 1 :			0.00 kb/s	0.00 kb/s
  Device ID 2 :			15.38 kb/s	14779.22 kb/s
Bus ID 8 (USB bus number 8)	To device	From device
  Device ID 1 :			0.00 kb/s	0.00 kb/s

19:54:32 pi@rockaware:~$ 


Bus ID 0 (All USB buses)	To device	From device
  Device ID 1 :			0.00 kb/s	0.00 kb/s
  Device ID 2 :			10.61 kb/s	10200.81 kb/s
Bus ID 1 (USB bus number 1)	To device	From device
  Device ID 1 :			0.00 kb/s	0.00 kb/s
  Device ID 2 :			1.06 kb/s	1018.26 kb/s
Bus ID 2 (USB bus number 2)	To device	From device
  Device ID 1 :			0.00 kb/s	0.00 kb/s
Bus ID 3 (USB bus number 3)	To device	From device
  Device ID 1 :			0.00 kb/s	0.00 kb/s
Bus ID 4 (USB bus number 4)	To device	From device
  Device ID 1 :			0.00 kb/s	0.00 kb/s
Bus ID 5 (USB bus number 5)	To device	From device
  Device ID 1 :			0.00 kb/s	0.00 kb/s
Bus ID 6 (USB bus number 6)	To device	From device
  Device ID 1 :			0.00 kb/s	0.00 kb/s
Bus ID 7 (USB bus number 7)	To device	From device
  Device ID 1 :			0.00 kb/s	0.00 kb/s
  Device ID 2 :			9.61 kb/s	9236.95 kb/s
Bus ID 8 (USB bus number 8)	To device	From device
  Device ID 1 :			0.00 kb/s	0.00 kb/s
^C19:56:23 pi@rockaware:~$ date
Fri 09 Oct 2020 07:56:26 PM PDT
19:56:26 pi@rockaware:~$ 
00:03:56 pi@rockaware:~$ lsusb -t
/:  Bus 08.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
/:  Bus 07.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=usbfs, 480M
/:  Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
/:  Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Vendor Specific Class, Driver=usbfs, 480M
00:14:37 pi@rockaware:~$ lsusb
Bus 008 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 007 Device 002: ID 1d50:60a1 OpenMoko, Inc. Airspy
Bus 007 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 002: ID 0bda:2832 Realtek Semiconductor Corp. RTL2832U DVB-T
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
00:14:59 pi@rockaware:~$ 

[mikkyo]

That picture is a little deceiving. The eve you see is the second story eve. That would be way too
dangerous working on that high a ladder…

Okay, just musing…I would do the waterproof box mounted to the Chimney using the corner brackets. Maybe 1/2" steel bar between the two bottom brackets supported on each side with holes in the bar for the box to mount.
Get your LNAs in there and run external bias-t injector from inside.
You’d only have to go up if you have a problem with the LNAs.

Or put the box on the wall by the chimney down near the ground, so at least you can get the LNAs closer to the antenna.

They were ok with FA antennas but the DPD antennas are longer, heavier and have much more wind loading.

Yeah, if you are that high, I would add guy wires.
3 per mast should be good and you can even use the same three anchor points, since they are so close together.

I ended up adding guy wires to my mast (18ft above the roof line), even though it was very sturdy and didn’t move in high winds.
I figure prepping for apocalypse 2024 will make it worth it.

[mikkyo]

I have the same setup.
RockPi with airspy R2 running -m 24 and RTL-SDRv3 on the other bus for UAT, as well as a GPS puck.

[ca249]

Status update:
I am planning on testing LO leakage on the splitter as obj suggested earlier. To do this I will have to move my benchmark feeder off the splitter. This requires that I put up a temporary mast and antenna for the BM feeder. I have ordered coax for the BM feeder and 50 ohm SMA terminators for the LO leakage testing.

In the meantime I did some testing of the RockPi4B USB bandwidth.

I used the live rockaware feeder (site #108954) that is in the combo role with an R2 and
orange dongle. I added an airspy mini and ran airspy_rx to load the USB bus.

Below are the following listings:

The output of usbtop showing the bit rate for each device.
The output of the airspy_rx command.
The output of systemctl status airspy_adsb

It appears that the load on the USB bus of the airspy_rx command is equivalent to
the R2 running at -m 20. You can compare it to the output of usbtop in post #17 above.

After terminating airspy_rx, the status of the airspy_adsb service shows that there
were no lost samples.

Bus ID 0 (All USB buses)	To device	From device
  Device ID 0 :			0.00 kb/s	0.00 kb/s
  Device ID 1 :			0.00 kb/s	0.00 kb/s
  Device ID 2 :			26.04 kb/s	25025.31 kb/s
Bus ID 1 (USB bus number 1)	To device	From device
  Device ID 1 :			0.00 kb/s	0.00 kb/s
  Device ID 2 :			1.06 kb/s	1018.26 kb/s          # orange dongle receiving UAT
Bus ID 2 (USB bus number 2)	To device	From device
  Device ID 1 :			0.00 kb/s	0.00 kb/s
Bus ID 3 (USB bus number 3)	To device	From device
  Device ID 1 :			0.00 kb/s	0.00 kb/s
Bus ID 4 (USB bus number 4)	To device	From device
  Device ID 1 :			0.00 kb/s	0.00 kb/s
Bus ID 5 (USB bus number 5)	To device	From device
  Device ID 0 :			0.00 kb/s	0.00 kb/s
  Device ID 1 :			0.00 kb/s	0.00 kb/s
  Device ID 2 :			9.61 kb/s	9237.07 kb/s           # Airspy mini running sudo airspy_rx -r /dev/null -t 2 -a 10000000 -s 0x26A464DC28341B93
Bus ID 6 (USB bus number 6)	To device	From device
  Device ID 1 :			0.00 kb/s	0.00 kb/s
Bus ID 7 (USB bus number 7)	To device	From device
  Device ID 1 :			0.00 kb/s	0.00 kb/s
  Device ID 2 :			15.38 kb/s	14778.82 kb/s          # R2 -m 24
Bus ID 8 (USB bus number 8)	To device	From device
  Device ID 1 :			0.00 kb/s	0.00 kb/s
^C19:24:15 pi@rockaware:~$ date
Fri 16 Oct 2020 07:24:43 PM PDT
19:24:43 pi@rockaware:~$ 


19:23:24 pi@rockaware:~$ sudo airspy_rx -r /dev/null -t 2 -a 10000000 -s 0x26A464DC28341B93
Device Serial Number: 0x26A464DC28341B93
Stop with Ctrl-C
Streaming at 10.013 MSPS
Streaming at 10.009 MSPS
Streaming at 10.005 MSPS
Streaming at 10.004 MSPS
Streaming at 10.006 MSPS
Streaming at 9.984 MSPS
Streaming at 10.004 MSPS
Streaming at 10.002 MSPS
Streaming at 10.001 MSPS
Streaming at 10.001 MSPS
Streaming at 9.984 MSPS
Streaming at 10.001 MSPS
Streaming at 10.004 MSPS
Streaming at 10.001 MSPS
Streaming at 9.985 MSPS
Streaming at 10.003 MSPS
Streaming at 10.001 MSPS
Streaming at 10.001 MSPS
Streaming at 10.000 MSPS
Streaming at 9.977 MSPS
Streaming at 9.985 MSPS
Streaming at 10.008 MSPS
Streaming at 10.005 MSPS
Streaming at 10.003 MSPS
Streaming at 10.001 MSPS
Streaming at 10.000 MSPS
Streaming at 9.997 MSPS
Streaming at 9.975 MSPS
Streaming at 10.005 MSPS
Streaming at 9.990 MSPS
Streaming at 10.008 MSPS
Streaming at 10.005 MSPS
Streaming at 9.985 MSPS
Streaming at 10.004 MSPS
Streaming at 10.002 MSPS
Streaming at 9.969 MSPS
Streaming at 10.005 MSPS
Streaming at 10.003 MSPS
Streaming at 10.002 MSPS
Streaming at 10.001 MSPS
Streaming at 10.001 MSPS
Streaming at 9.999 MSPS
Streaming at 10.000 MSPS
^CCaught signal 2

User cancel, exiting...
Total time: 43.4107 s
Average speed 10.0012 MSPS IQ
done
19:24:17 pi@rockaware:~$ date
Fri 16 Oct 2020 07:25:10 PM PDT
19:25:10 pi@rockaware:~$ 

19:26:23 pi@rockaware:~$ date
Fri 16 Oct 2020 07:26:32 PM PDT
19:26:32 pi@rockaware:~$ sudo systemctl status airspy_adsb
● airspy_adsb.service - Airspy ADS-B receiver
   Loaded: loaded (/lib/systemd/system/airspy_adsb.service; enabled; vendor preset: enabled)
   Active: active (running) since Sat 2020-10-10 17:00:36 PDT; 6 days ago
     Docs: https://discussions.flightaware.com/t/howto-airspy-mini-piaware-dump1090-fa-configuration
 Main PID: 18380 (airspy_adsb)
    Tasks: 4 (limit: 4470)
   Memory: 8.3M
   CGroup: /system.slice/airspy_adsb.service
           └─18380 /usr/local/bin/airspy_adsb -v -f 1 -e 9.4 -w 3 -t 600 -g 20 -m 24 -l 29999:beast 

Oct 10 17:00:36 rockaware systemd[1]: Started Airspy ADS-B receiver.
Oct 10 17:00:36 rockaware airspy_adsb[18380]: airspy_adsb v1.85
Oct 10 17:00:36 rockaware airspy_adsb[18380]: Listening for beast clients on port 29999
Oct 10 17:00:36 rockaware airspy_adsb[18380]: Listening for asavr clients on port 47806
Oct 10 17:00:36 rockaware airspy_adsb[18380]: Acquired Airspy device with serial 62CC68FF21955E17
Oct 10 17:00:36 rockaware airspy_adsb[18380]: Decoding started at 24 MSPS
Oct 10 17:00:40 rockaware airspy_adsb[18380]: Push client connected to localhost:30004 (beast)
19:27:20 pi@rockaware:~$