开云体育

ctrl + shift + ? for shortcuts
© 2025 开云体育
  1. Airspy
  2. Topics

USB bandwidth measurement #hardware #sdrsharp

 

Greetings from Athens!
Are there any utilities for Windows 11 that can measure the actual bandwidth / USB connection utilization (in bps) that an AIRSPY R2 or HF+ SDR uses together with SDR# software?
?
73 de SV1CDN, Dennis!
?
 

the actual samples are streamed as int16 from airspyhf, i dont know what from r2, which means they take up two bytes each.
so it's 2 times the bandwidth in bytes. so its about 1.74 MB/s for the highest?speed setting from an airspyhf.




On Mon, Mar 31, 2025 at 5:19?AM Dionisis “Dennis” Drakopoulos - SV1CDN via <sv1cdn=[email protected]> wrote:

Greetings from Athens!
Are there any utilities for Windows 11 that can measure the actual bandwidth / USB connection utilization (in bps) that an AIRSPY R2 or HF+ SDR uses together with SDR# software?
?
73 de SV1CDN, Dennis!
?
 

开云体育

That's not a simple question. As Joshua mentioned each I or Q sample is 2 bytes. That means an I/Q pair is 4 bytes. 10 Msps means 40 Mbytes per second. That comes out to 320 Mbps. But USB has serious overhead. That 320 Mbps works out to pretty close to maximum theoretical bandwidth. Some USB implementations do this just fine, if there are no other things on the bus asking for attention. So some machines work and some do not. Oddly USB3 ports actually tend to do better than USB2 ports even when they are in the USB2 fallback mode.

However, the actual samples are 12 bits each. This begs for some compression to reduce the load on the bus. One I/Q pair is actually 3 bytes. That is the compression format which cuts bandwidth use. That can be expected to work on almost any (modern) USB2 port. I'd still recommend that it be the only thing on the USB2 controller behind the USB2 port used.

If you dig around on Wikipedia and search engines you can find the exact numbers for overhead and expected transfer rates. I suspect that's getting too into the weeds for this venue.

{^_^}?? Joanne

On 20250331 01:20:31, Dionisis “Dennis” Drakopoulos - SV1CDN via groups.io wrote:

Greetings from Athens!
Are there any utilities for Windows 11 that can measure the actual bandwidth / USB connection utilization (in bps) that an AIRSPY R2 or HF+ SDR uses together with SDR# software?
?
73 de SV1CDN, Dennis!
?
 

Overhead?? Take Fibre Channel.? It starts in the 1 GHz range.? Due to all the overhead, we're down well into the 100's of mbps.? Can't we do better???

I forget the basic "carrier" frequency (Idle Word) as I've been out of it for well over a decade, but I do remember it's a tad over 1 GHz.?

Dave - W?LEV


On Mon, Mar 31, 2025 at 8:18?PM jdow via <jdow=[email protected]> wrote:

That's not a simple question. As Joshua mentioned each I or Q sample is 2 bytes. That means an I/Q pair is 4 bytes. 10 Msps means 40 Mbytes per second. That comes out to 320 Mbps. But USB has serious overhead. That 320 Mbps works out to pretty close to maximum theoretical bandwidth. Some USB implementations do this just fine, if there are no other things on the bus asking for attention. So some machines work and some do not. Oddly USB3 ports actually tend to do better than USB2 ports even when they are in the USB2 fallback mode.

However, the actual samples are 12 bits each. This begs for some compression to reduce the load on the bus. One I/Q pair is actually 3 bytes. That is the compression format which cuts bandwidth use. That can be expected to work on almost any (modern) USB2 port. I'd still recommend that it be the only thing on the USB2 controller behind the USB2 port used.

If you dig around on Wikipedia and search engines you can find the exact numbers for overhead and expected transfer rates. I suspect that's getting too into the weeds for this venue.

{^_^}?? Joanne

On 20250331 01:20:31, Dionisis “Dennis” Drakopoulos - SV1CDN via wrote:
Greetings from Athens!
Are there any utilities for Windows 11 that can measure the actual bandwidth / USB connection utilization (in bps) that an AIRSPY R2 or HF+ SDR uses together with SDR# software?
?
73 de SV1CDN, Dennis!
?



--
Dave - W?LEV
 

> However, the actual samples are 12 bits each. This begs for some compression to reduce the load on the bus. One I/Q pair is actually 3 bytes. That is the compression format which cuts bandwidth use.
Generally known as "packing" in the airspy drivers and airspy_rx (and usually by Joanne too :-) )
Although it doesn't seem exposed in the SDR# GUI or the default spyserver config (anyone?)
?
For measuring actual bus utilization though, unsure whether such a tool is available in windows
?
Note that USB2 is polled by the host, and the airspy data is transferred as BULK data (thus in "best effort" mode), but the airspy R2 only has very limited RAM available for buffering, so even a very short bus contention can cause issues
AFAIK this generally causes only glitches & clicks, and possibly lost blocks of samples (causing only clicks in most use-cases, such as general listening)
?
BR,
J
 


just analyze this file with claude?

On Tue, Apr 1, 2025 at 1:20?PM Jonathan Winterflood via <jonathan.winterflood=[email protected]> wrote:

> However, the actual samples are 12 bits each. This begs for some compression to reduce the load on the bus. One I/Q pair is actually 3 bytes. That is the compression format which cuts bandwidth use.
Generally known as "packing" in the airspy drivers and airspy_rx (and usually by Joanne too :-) )
Although it doesn't seem exposed in the SDR# GUI or the default spyserver config (anyone?)
?
For measuring actual bus utilization though, unsure whether such a tool is available in windows
?
Note that USB2 is polled by the host, and the airspy data is transferred as BULK data (thus in "best effort" mode), but the airspy R2 only has very limited RAM available for buffering, so even a very short bus contention can cause issues
AFAIK this generally causes only glitches & clicks, and possibly lost blocks of samples (causing only clicks in most use-cases, such as general listening)
?
BR,
J
 

开云体育

I believe SDRSharp uses it automatically now that the technique has proven itself so useful.

{^_^}

On 20250401 11:20:27, Jonathan Winterflood via groups.io wrote:

> However, the actual samples are 12 bits each. This begs for some compression to reduce the load on the bus. One I/Q pair is actually 3 bytes. That is the compression format which cuts bandwidth use.
Generally known as "packing" in the airspy drivers and airspy_rx (and usually by Joanne too :-) )
Although it doesn't seem exposed in the SDR# GUI or the default spyserver config (anyone?)
?
For measuring actual bus utilization though, unsure whether such a tool is available in windows
?
Note that USB2 is polled by the host, and the airspy data is transferred as BULK data (thus in "best effort" mode), but the airspy R2 only has very limited RAM available for buffering, so even a very short bus contention can cause issues
AFAIK this generally causes only glitches & clicks, and possibly lost blocks of samples (causing only clicks in most use-cases, such as general listening)
?
BR,
J
 

Use this config key in SDR#: <add key="airspy.usePacking" value="True" />
 

> prog
> Use this config key in SDR#: <add key="airspy.usePacking" value="True" />
:thumbsup:
 

>
> just analyze this file with claude?
?
with or without,?and the firmware too :)
?
Either way in ideal conditions the required "useful" bandwidth is well known, as you & joanne have noted :-)
?
If there are retransmissions though, they're invisible to libairspy, and possibly even to libusb.? there might be some debug counters available though.
Trying to find out the actual "bus time usage" of a particular device could be harder, unless it's also in debug info
?
That said I'm not sure what Dennis really needs/wants.
?
I'm more "concerned" about the firmware side:
If there are too many retransmissions, or bus contention, the ADC/DMA and USB can start using the same buffer
Besides corruption if the ADC catches up with the USB transfer, the ADC FIFO can drop samples (Real, not I/Q) due to memory bus speed limitations - seen in LPC_ADCHS->STATUS0 & STAT0_FIFO_OVERFLOW
The LTC usb stack might eventually complain if the USB link is chronically slower than the ADC, or maybe it'll just drop buffers (blocks)
?
Of course these are firmly in the "fix your setup" realm
A way of checking for overflows could be nice - but not a hard abort of course.
A missed sample here or there is not catastrophic in most applications though
?
Have a great weekend :)
J
 

to measure realtime bandwidth on linux just use usbtop
some fiddling will let usbmon measure retransmission rates

On Fri, Apr 4, 2025 at 1:15?PM Jonathan Winterflood via <jonathan.winterflood=[email protected]> wrote:

>
> just analyze this file with claude?
?
with or without,?and the firmware too :)
?
Either way in ideal conditions the required "useful" bandwidth is well known, as you & joanne have noted :-)
?
If there are retransmissions though, they're invisible to libairspy, and possibly even to libusb.? there might be some debug counters available though.
Trying to find out the actual "bus time usage" of a particular device could be harder, unless it's also in debug info
?
That said I'm not sure what Dennis really needs/wants.
?
I'm more "concerned" about the firmware side:
If there are too many retransmissions, or bus contention, the ADC/DMA and USB can start using the same buffer
Besides corruption if the ADC catches up with the USB transfer, the ADC FIFO can drop samples (Real, not I/Q) due to memory bus speed limitations - seen in LPC_ADCHS->STATUS0 & STAT0_FIFO_OVERFLOW
The LTC usb stack might eventually complain if the USB link is chronically slower than the ADC, or maybe it'll just drop buffers (blocks)
?
Of course these are firmly in the "fix your setup" realm
A way of checking for overflows could be nice - but not a hard abort of course.
A missed sample here or there is not catastrophic in most applications though
?
Have a great weekend :)
J
 

开云体育

TL:DR

Place the R2 on its own USB controller if you need best performance with no dropped packets. At high usage packets may not arrive in real-time due to competition for time resources. The mini works nicely at 6 Msps with limited other use. Don't try to back up a file to a memory stick on the same controller. 10 Msps is OK probably with things like a keyboard and mouse.

Consult your motherboard manual for which ports go directly to the CPU and which go through internal hubs.

{^_^}

On 20250404 10:15:55, Jonathan Winterflood via groups.io wrote:

>
> just analyze this file with claude?
?
with or without,?and the firmware too :)
?
Either way in ideal conditions the required "useful" bandwidth is well known, as you & joanne have noted :-)
?
If there are retransmissions though, they're invisible to libairspy, and possibly even to libusb.? there might be some debug counters available though.
Trying to find out the actual "bus time usage" of a particular device could be harder, unless it's also in debug info
?
That said I'm not sure what Dennis really needs/wants.
?
I'm more "concerned" about the firmware side:
If there are too many retransmissions, or bus contention, the ADC/DMA and USB can start using the same buffer
Besides corruption if the ADC catches up with the USB transfer, the ADC FIFO can drop samples (Real, not I/Q) due to memory bus speed limitations - seen in LPC_ADCHS->STATUS0 & STAT0_FIFO_OVERFLOW
The LTC usb stack might eventually complain if the USB link is chronically slower than the ADC, or maybe it'll just drop buffers (blocks)
?
Of course these are firmly in the "fix your setup" realm
A way of checking for overflows could be nice - but not a hard abort of course.
A missed sample here or there is not catastrophic in most applications though
?
Have a great weekend :)
J

1 - 12 of 12