Max Bandwidth of Dual RX

Is there a maximum bandwidth with the two Receivers ie 2x 20mhz or 2x 10mhz ??


LMS7002M RF bandwidth is 120MHz, but USB 3.0 interface limits throughput to 61.44MSPS.

Is the 61.44MSPS 12-bit samples transferred across the USB 3.0 bus as 16-bit words (i.e. are 4 bits always zero of every sample) ? That would be the easiest way with the least memory and CPU overheads for the board and PC.

Other SDR devices have squeezed more out of available USB limitations ( ) at the cost of double the RAM bandwidth on the host and extra CPU processing, which in reality at these data rates may not be feasible at least not in real time.

The firmware sources are on GitHub:

perhaps I worded it wrong, can we have a RX on HF and RX on VHF, and what would the bandwidth of both Rx’s be?

My guess, depending on how the data transfer is done under the hood, I only skimmed what is being done. My speed read through the source code suggests to me that two DMA transfers can be enabled, one to the device (TX) and a second one from the device (RX). So at the lowest level of the data transfer 8 bit words are transferred at a maximum speed of 245.76MB/second [234.375 MiB/sec] across the USB 3.0 bus. So if you disabled TX and only used the two RX channels then in theory one, or both combined, could look at a maximum of 61.44MHz of spectrum. But like I have said I have only skimmed through how everything works, there may be some overhead that I have totally overlooked that knocks 20% off this. But if my current understanding of how everything is being done is right then it is pretty damn efficient. And if you wanted two RX channels of 30.72MHz each that should work (provided TX is disabled, and it has filters for 30.72MHz - I haven’t looked into that).

I assume you are interesting in RX data only. Then there are a few things to consider:

  1. Maximum USB3 data throughput from LimeSDR-USB to PC. Maximum theoretical data throughput in this case is 400MB/s (32 bit interface between USB MCU (FX3) and FPGA running @ 100MHz). Real number we were to achieve with LimeSDR-USB is 387MB/s.
  2. Maximum RF bandwidth of LMS7002M analog frontend. Theoretically it is limited by ADC sample rate (while filters in the analogue frontend may be bypassed) which is 160MHz. Hence theoretical RF bandwidth is 160MHz. Although in a real life application I would expect RF bandwidth to be 120MHz (as mentioned by Andrew) @ 160MHz sample rate.
  3. If we are using MIMO, then RX will produce 4 * 160 = 640MS/s which is 640 * 1.5 = 960MB/s, while one sample is 12 bit. As you can see from item (1) above there is no way to transfer such an amount of data to the PC.
  4. If we set ADC sample rate to 61.44MHz, then data throughput (using the math from item (3)) will be 368.64MB/s, which is doable. Hence you have 61.44MHz RF bandwidth per each MIMO channel transferred to the PC.

Well…let me ask you this then. How about the LimeSDR with PCIe? Do you experience same “bandwidth” limitations or can you utilize full 120 MHz bandwidth? I would expect the PCIe flavor to overcome this “restriction” assuming you always refer to USB3.0 limits.

@maedula If you read through the gateware source code for the PCIe ( ), PCIe is achieved by using xillybus cores.

xillybus using “Altera Cyclone IV with 4x lanes” has a maximum RX+TX bandwidth of 400 MiB/sec which is explicitly allocated as 195MiB/s 32bit RX, 180MiB/s 32 bit TX and the rest looks like it is used for control communications.

So although PCIe(v1) x4 lanes has a theoretical maximum throughput of 1GiB/sec, only 400MiB/sec is possible using the xillybus cores. That is my reading of it, but I could be wrong.

But in future it could be faster - “higher-bandwidth revisions of Xillybus’ IP core will be rolling out during 2016”

@mzs Thanks for your feedback on this. I see. PCIe v1 is used. What a bummer. I would have expected at least v2.0. It actually would have been lovely that the LimeSDR PCIe variant would really distinguish itself from USB3 variant und unlocks full bandwidth capabs of the LMS7002M. No clue on how you would manage to process the >61MSPS in realtime using GPP but people are attracted to higher performance stats in general. That would at least have attracted more people to buy the PCIe variant in case of full BW exposure and explains why there is not much interest in the PCIe variant.

The PCIe is provided by a softcore than can be upgraded (and a new higher performing one will be available this year), so faster at a later date is not impossible. but processing that much data would require some ridiculous processing power.

You would need CUDA for the FFT but otherwise a bandwidth of up to 400MHz is very doable if you’re careful with the code.

I would think that with the right FPGA programming that the processing can be offloaded HPSDR style onto the FPGA and the presented back to the PC within the bandwidth limits allowing for simultaneous HF and VHF use.

Is it possible to achieve RF bandwidth to be 160MHz in real life using LimeSDR-QPCIe?

I don’t know, but FYI some of the information above is out of date. This thread has more current information:

Does it apply for 2xTX + 2xRX configuration? If so, did anyone actually manage to get reliable transmission of that order with any host machine? I am asking, because max I could get from my very powerful computer was about 27 MHz for 2xTX + 2xRX configuration.

Maximum that you can get on USB version when running Tx and RX at the same time is around 180-190 MB/s per direction. So its 30-31 MS/s for 2xTX + 2xRX configuration.

1 Like

I thought so. But thank you for quick clarification :slight_smile:

I understand this thread is 2 years old, in fact the LimeSDR PCIe bandwidth limitation is due to the Cyclone IV GX “PCIe transceiver” which supports only Gen1. So it is a FPGA hardware limitation:

Need 10Gb interfaces.