SDR(Software Defined Radio)

 

 

 

Adaptors/Connectors

An SDR is two machines rather than one. The first is a radio. The second is a computer. The adaptor is the link between them, and it decides more about the finished system than the RF specification does. For a long time I compared SDR boards by their front end alone. That was the wrong comparison. A board with a wide RF front end can still be limited by its host link; the practical limit depends on sample rate, sample format, channel count and transport overhead. Each connection method below has a section of its own. Every section gives the raw line rate, the rate you can actually stream, the latency behaviour, and the distance the link reaches.

Executive Summary

The table is a lookup. Practical throughput is one direction, after protocol overhead, on a host that has been tuned.

Adaptor

Useful strength

Main limit

USB 3.x / USB4

Simple external connection

Shared host controller, cable and packet overhead

PCI Express

High sustained host bandwidth and low latency

Usually needs an internal slot or specialised cable

Thunderbolt

External PCIe-class connection

Bandwidth is shared with display, USB and dock traffic

Ethernet

Long reach and easy physical separation

Packet jitter, MTU and host-network scheduling

CPRI / eCPRI

Radio fronthaul timing and multi-vendor transport

Strict timing and large aggregate rate

What does an SDR adaptor actually have to carry?

The adaptor moves much more than the nominal RF bandwidth. It carries I and Q samples, timestamps, channel markers, control messages and sometimes calibration data. The first calculation is therefore sample rate multiplied by bytes per sample, multiplied again by the number of channels and directions.

For example, one complex channel at 20 MS/s with signed 16-bit I and Q needs 20 million samples times 4 bytes, or 80 MB/s before transport headers. Two receive channels already need 160 MB/s. A transmitter adds another stream. If the device sends 32-bit I and Q instead, the payload doubles again. This is why a radio with a modest RF bandwidth can still overload a host link.

Transport overhead is not only the Ethernet or USB header. The host may copy buffers, wake the CPU for interrupts, convert sample formats and move data between user space and a driver queue. These operations consume memory bandwidth and CPU time. A link can show a high benchmark number and still fail during continuous SDR streaming.

There is another constraint: real-time behaviour. A short throughput test can hide a queue that fills slowly. Continuous RX needs enough buffering to absorb scheduling variation, but extra buffering increases latency. TX has the opposite failure mode: an empty queue produces an underflow and the radio has no sample to transmit.

So adaptor selection starts with a traffic budget. Count both directions, use the actual sample format, reserve protocol overhead and leave room for bursts. Then check latency, buffer depth and the operating system driver. A link that barely matches the arithmetic is already too small.

  • Count payload first: sample rate, bytes per complex sample, channels and directions.
  • Then check host behaviour: copies, interrupts, buffers and scheduling determine the usable rate.

How much can USB really carry, and where does it stop?

USB is attractive because it is external, inexpensive and common on laptops. The label on the connector is not enough, however. USB 3.2 defines 5, 10 and 20 Gbps signalling rates, but the SDR receives a smaller application payload after encoding, protocol packets, host-controller sharing and driver behaviour.

USB 3.2 Gen 1 is 5 Gbps, Gen 2 is 10 Gbps and Gen 2x2 is 20 Gbps. USB4 adds 20 and 40 Gbps modes, with newer systems supporting 80 Gbps operation. These are link rates, not guaranteed sample throughput. The USB-IF also permits a device to fall back to the lowest common capability.

Shared topology matters. A radio connected through a hub competes with storage, a camera or another radio for the same host-controller schedule. A front-panel connector may also use an internal hub or a longer cable. Test the exact port, cable and operating-system driver that the deployment will use.

USB packet transport normally gives good average throughput, but it does not give the same deterministic timing as a local PCIe endpoint. The queue absorbs short scheduling gaps until it does not. UHD reports an overflow when receive data cannot be consumed and an underflow when transmit data is not supplied in time. These are transport and host symptoms, not RF measurements.

USB is a good choice for a portable single-radio system when the sample budget leaves margin. It is a poor choice when several wideband channels share one controller, when the application needs tightly bounded latency, or when the cable path is part of a large instrument setup.

  • Use the speed name: USB 5, 10 and 20 Gbps are clearer than an unqualified “USB 3”.
  • Validate the complete path: port, hub, cable, controller, driver and sample format all affect the result.

Why is PCI Express still the fastest way to reach the host?

PCI Express is a point-to-point link into the host memory system. The radio card or capture card can use DMA, so samples do not need to pass through a general-purpose USB scheduling layer. This is the main reason PCIe remains the natural adaptor for high-channel-count SDR.

PCIe 3.0 transfers at 8 GT/s per lane and uses 128b/130b coding. One lane provides roughly 985 MB/s of payload in one direction before other protocol effects. A x4 link therefore has roughly 3.9 GB/s at that layer. PCIe 4.0 doubles the transfer rate to 16 GT/s, but the usable value still depends on lane width, negotiated generation and the endpoint design.

Look at the negotiated link, not the connector shape. A card installed in a x8 slot may train as x4 or x1 because of the motherboard, bifurcation settings or signal quality. The device may also expose a narrower internal bus than its marketing label suggests. Check the operating-system link status while the SDR is running.

PCIe reduces transport latency, but it does not remove all real-time problems. DMA buffers, NUMA placement, interrupt affinity and cache pressure still matter. A radio attached to one CPU socket can perform poorly when the application and memory are on another socket. Driver queues also need enough depth to absorb short host delays.

Use PCIe when the sample budget is high, the processing host is fixed and latency matters. The cost is installation complexity. A local card is also less convenient when the RF unit must sit several metres away or when several hosts need access to the same front end.

  • Check lane width and generation: the negotiated link is the real interface.
  • Keep DMA local: CPU affinity and NUMA placement can decide whether the theoretical bandwidth is usable.

What does Thunderbolt add over USB and PCI Express?

Thunderbolt packages high-speed PCIe and display transport behind an external USB-C cable. It is useful when a laptop needs an external PCIe-class SDR connection without opening the chassis. The external convenience comes with a shared tunnel and a more complicated path than a card plugged directly into the motherboard.

Thunderbolt 4 provides a 40 Gbps connection and requires at least 32 Gbps of PCIe bandwidth for a certified host. Thunderbolt 5 raises the link to 80 Gbps and can use an asymmetric 120/40 Gbps mode for display-heavy traffic. Those figures describe the Thunderbolt link and minimum platform capabilities. They do not promise that an SDR application gets the whole link.

A dock may carry PCIe, USB and display traffic at the same time. The connection manager schedules those tunnels, and the host still has to service DMA buffers. An external enclosure can therefore have higher latency or less stable throughput than an equivalent internal PCIe card, even when both advertise a similar number.

Thunderbolt is a practical middle position. It can place the radio close to the antenna, and it is easier to move between laptops than a PCIe card. It is also a good bridge for an external PCIe chassis. Confirm PCIe tunnelling, cable certification, power delivery and the enclosure controller before relying on it for continuous full-rate streaming.

  • Thunderbolt exposes PCIe externally, but the tunnel shares the link with other traffic.
  • Measure the enclosure: host port capability and cable quality are part of the adaptor.

When is Ethernet the right adaptor for an SDR?

Ethernet becomes attractive when the radio and processing host should be separated by metres or kilometres. It uses standard switches, optical modules and network monitoring. The same packet structure that gives Ethernet reach also introduces queueing, interrupt scheduling and path-dependent latency.

1 GbE is often enough for narrowband control or low-rate IQ. 10 GbE is a common starting point for wider streams, but the sample budget still has to fit after packet and transport overhead. 25, 40 and 100 GbE are available when several radios or many channels share a host. The interface rate alone does not tell you whether the application can sustain it.

Packet size matters. Small packets increase per-packet overhead and interrupt work. Large packets reduce overhead but depend on a consistent MTU across the radio, host, NIC and every switch. Ettus documents that packets larger than the path MTU can fragment or drop, while packets that are too small reduce achievable throughput.

Use dedicated NIC queues, CPU affinity and a measured buffer policy when latency matters. A switched path may be excellent for distributed capture, but it is not automatically deterministic. PTP or another timing reference may be required when sample timestamps from multiple radios must line up.

Ethernet is the right adaptor when reach, serviceability and sharing matter more than the smallest possible latency. Use a direct fibre or a dedicated switch path when the application cannot tolerate unrelated traffic. For a local high-rate loop, PCIe usually gives a simpler timing problem.

  • Ethernet trades local latency for reach.
  • Check MTU and queueing: the smallest MTU and busiest queue limit the complete path.

What does CPRI carry, and why does it not scale to massive MIMO?

CPRI carries a constant-rate stream between a radio equipment control unit and a remote radio unit. It transports time-aligned digital baseband samples together with control, management and synchronisation information. The radio link is engineered as a fronthaul, so its timing behaviour is different from a best-effort host connection.

The difficulty is the sample volume. A rough CPRI rate grows with antenna count, sample rate, sample width and line coding overhead. It does not fall simply because a particular PRB is empty. An eight-antenna carrier can therefore consume a large fixed line rate even when user traffic is light.

That fixed-rate behaviour becomes expensive with massive MIMO. More antenna ports multiply the stream, and the radio must carry the transport even when scheduling leaves many resource elements unused. Fibre can provide the reach, but each additional sector or carrier needs more fronthaul capacity and optics.

CPRI still makes sense when a vendor controls both ends and the constant-rate design fits the site. The eCPRI direction moves toward packet Ethernet and permits more flexible functional splits. The two names should not be treated as interchangeable: CPRI is a specific legacy serial/fronthaul specification, while eCPRI defines packet-based message transport and relies on an Ethernet network.

  • CPRI rate follows radio sampling, not only scheduled user data.
  • Massive MIMO multiplies transport demand, which is why newer splits move more processing toward the radio or DU.

What changes when the adaptor is an Open RAN 7.2 fronthaul?

Open RAN 7.2x places the split inside the physical layer. The O-DU keeps higher-PHY processing, while the O-RU performs lower-PHY and radio functions. The adaptor is therefore a fronthaul interface between two network functions, not simply a USB cable between a radio and a program.

The O-RAN CUS-Plane specification defines control, user and synchronisation planes for the O-DU to O-RU link. User-plane packets carry sectioned IQ data. Control-plane messages describe how that data maps to time, frequency, antenna and beam resources. Synchronisation keeps the two ends aligned. A packet can be delivered successfully and still be unusable if its timing or section information is wrong.

Bandwidth depends on the split, compression, number of antenna carriers and the resources sent. Selective transmission and compression can reduce the rate compared with a raw constant-rate sample stream. The saving is workload-dependent; it is not a universal percentage. The O-RU category and supported compression method must be part of the design.

Timing is the hard constraint. The fronthaul has to meet transport delay and time-alignment requirements while the O-RU and O-DU process the same radio slot. Switches, optics, packet size and synchronisation support all contribute. This is why a normal Ethernet throughput test does not qualify an Open RAN fronthaul by itself.

Use 7.2x when multi-vendor radio and DU interoperability, flexible placement or lower O-RU processing is the goal. Read the exact O-RAN profile and category before selecting an adaptor. “Ethernet capable” is not enough evidence that a device supports the required CUS-plane timing and message semantics.

  • 7.2x is a functional split, not a connector type.
  • Validate all three planes: user data, control sections and synchronisation must work together.

How do you choose an adaptor for a given job?

The right choice follows from the traffic and timing requirement, then from the physical installation. Start with the stream calculation and write down the required rate in each direction. Add headroom for protocol overhead, burst traffic and future channels before comparing interface names.

Requirement

Usually suitable

Questions to verify

Portable single radio

USB 3.x

Actual port speed, controller sharing, cable and overflow margin

High-rate local capture

PCI Express

Negotiated lanes, DMA, NUMA and driver queueing

External laptop expansion

Thunderbolt PCIe enclosure

PCIe tunnel, cable, display sharing and enclosure limits

Separated radio and host

Dedicated 10/25 GbE or fibre

MTU, switch queueing, timestamping and path latency

RU-DU fronthaul

CPRI/eCPRI or O-RAN 7.2x

Exact split, synchronisation, compression and interoperability profile

Then measure the complete system. Generate the intended number of channels at the intended sample format. Run receive and transmit together if the deployment is duplex. Watch for overflow, underflow, dropped packets, timestamp discontinuities and queue growth. A speed test that sends synthetic bytes for ten seconds is useful, but it is not a radio validation.

Keep the interface failure separate from RF failure. If samples arrive with gaps, first check the transport counters and host scheduling. If the sample stream is continuous but the signal is wrong, inspect clocks, gain, calibration and the RF chain. This separation saves time because a wider link will not repair a bad reference clock.

Finally, write down the assumptions. State channel count, complex sample width, sample rate, packet size, MTU, cable type, distance, expected latency and whether the link is shared. Another engineer can reproduce the choice only when those values are visible.

  • Choose from a measured traffic budget, not the interface label.
  • Test the complete chain, including host queues, clocking and the physical path.

Reference

The list below is where the numbers on this page come from, and where a reader should go for the authoritative wording. The specifications are the primary sources for the interface rates, and the ShareTechnote pages give the surrounding context for the fronthaul sections.