Maximum TX bandwidth

General Discussion
#1

Hi fellow,
I use GNURadion (3.7) to generate signal and pass it to LimeSDR using regular block “LimeSuit Sink (TX)”.
So, everything is straight forward.
I observed next behavior:

  1. Transmission is fine up to 50MHz bandwidth (approximately).
  2. After 50MHz of bandwidth, transmission becomes unstable: board transmit approximately one minute then it stops for one minute. So, it is up and down. Absolutely NO diagnostics is coming from GNURadio.
  3. I try transmission with different transmission gain, different frequencies (200MHz, 900MHz), different calibration bandwidth (see GNURadio “LimeSuit Sink (TX)” block) – results are the same: Up and Down
  4. I used external power supply (12V 2A) – result is the same: transmission is Up and Down

After having this fun for couple of week I decided to ask for help:

  1. What is REAL max transmission bandwidth on LimeSDR-USB?

  2. How can I check whether or not external power supply is REALLY used by LimeSDR. Yes, I see light on board coming up when I connect external power supply. But I have an impression that board does not use it. I did not find any info how can I check what power source is used by board.

Thanks in advance.

#2

I did not play lot with GNURadio but I have a question: what is CPU usage when you transmit 50MS/s and what exactly GNURadio transmit? Sine wave or something more complex?

#3

First, keep your input voltage under 8VDC, as the voltage switching chip is at it’s failure limit with any transients on 12VDC.
Have you added heat sinks & good cooling (Fan)?
hHese are the basics.

Ed

#4

Hi yt7pwr,

CPU: I have AMD R3900x. It is pretty powerful.
When I set 60MHz (sixty MHz) bandwidth, CPU load does not exceed 30% (total). Single core load does not exceed 80%.

Signal: I try both sin wave and Gaussian noise. Results are pretty much identical.

#5

Hi AA7QQ,

When I was failed to transmit using just USB power, I connected my DC (12V,2A). I did not find any difference. That is why I am asking about ANY methods to control which power source is currently in use by board. I did not find any utilities yet.

I did install heat sinks. Temperature reported by LimeSuite GUI is about 60C (open stand) after long time under load.
But! I did not find any temperature dependence. When I start transmitting (and therefore board is cold 40C), and after long time load (when board is about 60C) - results is the same.

BTW, transmission is UP and DOWN with period 80sec (40sec is UP and 40sec is DOWN).

Any idea wold be high appreciated.

UPDATE: if I try to transmit Gausian noise transmission time becomes shorter. As much noise power as shorter transmission time.

#6

My CPU is R7 2700X (according to cpubenchmark twice slower than R3900X). I notice that GNURadio is not multithreaded optimise. One core is usually doing majority of DSP tasks. On 30MS/s data stream is arround 100MB/s, for 60MS/s twice that. CPU must to compute and prepare 200MB/s of I/Q data! Too much for single core! Maybe 24 threads, in your case (my CPU is 16 threads), can do the job but only in heavily optimised multithread C/C++ app.
And, as AA7QQ wrote, do not forget good cooling for board.

#7

As far as I know, each GNURadio block occupies one core. So, one block cannot be executed on two core.
That is why I mentioned that “Single core load does not exceed 80%”. It means that no cores reach its saturation hopefully :slight_smile:

#8

There is a catch: modulation/demodulation is real-time job! Even if transmit process occupies only 20-30% of one CPU core there are no guarantee for success. For TX is critical DSP process called interpolation and it is possible to make it multithreaded. Did you try to stop-start GNURadio when output is silenced? Also, on Windows problem can be some time USB power management and need to be turn off.

1 Like
#9

All my machines except for the Raspberry Pi, easily handle 40 MSPS (i.e. 320 MB/s) with a single thread receiving with a LimeSDR mini - so one would think that they could handle transmission at the same rate or greater on the LimeSDR.

SdrGlut Simultaneously Running Five SDRs
https://www.youtube.com/watch?v=BmUNrAn1Llk

1 Like
#10

Hi guys,

Thank you very much for your participation in this discussion. It seems I found problem.

The point is that, my GNUradio script originally used Osmocom sink (BladeRF micro). This board does not stop transmitting in the same environment. However, when I changes Osmocom sink to LimeSDR sink it start producing strange results. I’ve disabled one so-called “hier” block in GNURadio script (it is not needed under certain circumstance) and everything start working as expected :slight_smile:

Couple of words about multithreadeing and performance. GNURadio does have, for example, FFT filter. Regular GNURadio 3.7 distribution (Windows precompiled) contains this block. It is a single thread. Nevertheless, this block easily handles filters with several thousand coefficients (on R3900x). The hier block, mentioned above, costs absolutely nothing from computational point of view, but it caused me problem.

So, I do not care why “hier block “+Osmocom(bladeRF) and “hier block”+LimeSDR sink behave differently. I know that LimeSDR works as expected :slight_smile:

#11

Great news! Can you share GNURadio gr file?

#12

Is there a install instruction for Windows version? Downloaded release but after I try to run SdrGlut error message is shown about missing library.

#13

What library is it Complaining about ?

Near the Bottom of the Readme on -

are the instruction for a Windows install. The Latest version of the PothosSDR package no longer has the problem with the Device.h file and it is missing the install for RTAudio -

https://www.youtube.com/watch?v=DyYIKiu2zVI

I need to update the instructions - I did not realize that they were so out of date

#14

Hi!

I use windows distributions from here:
http://www.gcndevelopment.com/gnuradio/downloads.htm

In particular, I use v3.7.13.5/v1.6 with AVX2.

I did try many different versions from there. It looks like other ones are less stable.
I did not try 3.8.2 and up.

Sorry I am not an expert in GNURadio versions/distributions and glitches.