LimeSDR mini and GNURadio

Projects LimeSDR
1

Hi,
I have troubles with a new LimeSDR mini and GNURadio. I am trying to transmit with a simple FM transmitter. It somewhat works, but definitely not smoothly. Wiht LimeSuite from Ubuntu ppa I was very often getting this error:

[INFO] Make connection: ‘LimeSDR Mini [USB 3.0] 1D3AC97E5FB9CA’
[INFO] Device name: LimeSDR-mini
[INFO] Reference: 40 MHz
[INFO] Init LMS7002M(0)
[INFO] Ver=7, Rev=1, Mask=1
[INFO] LMS7002M calibration values caching Disable
CGEN: Freq=80 MHz, VCO=2.56 GHz, INT=63, FRAC=0, DIV_OUTCH_CGEN=15
CGEN: Freq=61.44 MHz, VCO=2.4576 GHz, INT=60, FRAC=461373, DIV_OUTCH_CGEN=19
CGEN: Freq=61.44 MHz, VCO=2.4576 GHz, INT=60, FRAC=461373, DIV_OUTCH_CGEN=19
M=156, N=3, Fvco=1040.000 MHz
M=156, N=3, Fvco=1040.000 MHz
MCU programming : 16384/16384
MCU Programming finished, 3047 ms
[ERROR] MCU working too long 4
[ERROR] setBandwidth(Rx, 0, 30 MHz) Failed -

Sometimes disconnecting the device helped, but sometimes I had to wait and/or reboot the computer. I am not sure about it but it seems to me that the problem is getting worse with time - so could this be because of overheating (LimeSuite usually shows something above 50 C)? I tried to google some information, but usually I found advice to update the software.

So today I checked out the latest code from github and the simple TX failed with this message:

[INFO] Make connection: ‘LimeSDR Mini [USB 3.0] 1D3AC97E5FB9CA’
[INFO] Reference clock 40.00 MHz
[INFO] Device name: LimeSDR-Mini
[INFO] Reference: 4e+07 MHz
[INFO] LMS7002M calibration values caching Disable
[ERROR] Tune Tx Filter: MCU error 14 (Tx RCAL_LPF range limit reached,)
[ERROR] setBandwidth(Tx, 0, 5 MHz) Failed -

Googling did not help, but after several tries I found that if I set the bandwidth to 15MHz it works again (10MHz works as well). On the other hand I haven`t received the first error yet. But it has always been random.

I am receiving with rtl-sdr and here is the waterfall:

gqrx_wf_20180507_143026
gqrx_wf_20180507_143026.png1495×511 441 KB

You can see there the silence before transmitting, calibration, the actual transmitting and some more transmitting after I stopped the program - the top of the red line, then I disconnect the device and there is silence again. It seems to me, that the device is not properly stopped. Could this be related to the first described problem or is this correct?

Generally I`d like to know why is this happening? Software (driver) problem? Overheating (I plan to attach some fan on the case, but it will take some time)? Weak computer (usb port)? Defect on LimeSDR mini (The LimeQuickTest mostly passed)?

Is there some guide how to use LimeSDR mini with gnuradio?

Thank you for any advice.

Pavel

2

I’m unsing GnuRadio on OSX so my advice may be off the mark for Linux, but on my Mac I find that the driver can fail to exit clean and cause issues with what looks like a zombie connection. I find that killing a running GUI with the “X” in the top right of the active GUI window tends to increase the likelhood of issues. I find that using the “stop” button in the GRC windows to end a GUI process seems to be better behaved. Usual warning; I’m n=1 and I’ve not debugged the issue to root cause, different OS, etc.

3

Having exactly the same error in Gqrx. Barely any soft (osmocom, gnuradio) can not work with limesdr mini. The exception is - got working as signal source in gnuradio-companion, but it worked very slowly. Everything is the latest version, installed from source.

4

First results.

Managed to listen to FM radio.
1)I installed pure ubuntu from website, installed everything from apt like so:
sudo add-apt-repository -y ppa:myriadrf/drivers
sudo apt-get update
sudo apt-get install limesuite liblimesuite-dev limesuite-udev limesuite-images
sudo apt-get install soapysdr**-tools** soapysdr-module-lms7

also, I installed uhd-tools and uhd-soapysdr. To verify that uhd driver hooked up the device, run uhd_find_devices

then, gqrx from apt too.
2)Gqrx works only if you use UHD (ettus) driver for limesdr mini.
3)If you managed to get a little spectrum, you should also select antenna (LNAL or LNAH, the difference is inobvious in case of limesdr mini)

5

Update:
Got working osmo-trx.
You just need to install only osmo-trx and libosmocore from github. To build them you need a bunch of dependencies, but all of them may be installed via apt.

Launch as following:
osmo-trx-uhd -a ‘driver=lime’

cfg file is taken from osmo-trx git repo, they have an example file for Limesdr

1 Like
6

I did not have any issues using Gqrx with SoapySDR (but that was on a Gqrx git build from last December, I don’t stay very up to date with it). Nor with other GNU radio applications using Osmosdr sources/sinks with SoapySDR.

Regarding the “setBandwidth() failed” message, I think that could be handled a bit more gracefully if it’s possible. I did get some seemingly random failures in QRadioLink with it for some values, and no failures for other values (2 MHz comes in mind). I dropped the setting eventually and just left the driver to do its own automatic thing which seemed to work.

7

I can run cubicsdr 0.23 and 0.24 . I never be able to run qgrx . GQRX is recognize my limesdr mini but no signal is detected.I tried to change settings and other . My limesdr suite was working and can’t work now
I m using xubuntu 16.04

8

I received following error while compling osmo-trx on rasbian, i have already build libosmocore-0-11-0 from source and installed but despite this unable to complie, any one can help to resolve the issue!

configure: error: Package requirements (libosmocore >= 0.11.0) were not met:

Requested ‘libosmocore >= 0.11.0’ but version of Osmocom Core Library is UNKNOWN

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

I have already build following components on Rasbian from source successfully

LimeSuite
SoapySDR
SoapyUHD
Libosmocore-0.11.0/libosmocore-0.96.0

9

@aligrt This is related to the Osmocom stack and has nothing to do with this thread or GNU Radio. Would suggest posting details to the appropriate Osmocom mailing list.

10

Try
sudo apt remove *libosmocore* and fully rebuild (autoreconf, make. make install, ldconfig) it from source

11

This is actually an issue with SDRs in general.

The question of “which errors should be fatal”.

For example, you ask to tune to frequency X, but the hardware cannot get closer than 1kHz to “X”.
Should it raise an exception, or carry on?

Similarly for other operating parameters of a piece of hardware like this.

If I ask for (let’s say) an RF gain of 30dB, but it can only provide 29.5dB, should that be a fatal error?

What about sample rates? Antenna settings? Synchronization settings?

In the context of a lot of applications the “let’s just struggle on anyway” might be the correct answer.
But there are situations where it isn’t. This isn’t a new class of problem in this industry…

12

Hi Marcus,
Yes you’re absolutely right, and it was probably my fault for not programatically querying the list of supported bandwidths before trying to set it. What puzzled me however was using the same number and sometimes getting the failure, sometimes not. Obviously, the use of so many abstraction layers (Osmocom - SoapySDR - Lime driver) meant something got lost on the way, just hope it’s not my sanity :slight_smile:

Regards,
Adrian

13

Hi,
after some coding and studying I have partial answers to some of my original questions.

  1. the residual transmission, which is visible on the waterfall I posted, is caused by not disabling the TX channel (by calling LMS_EnableChannel(device, LMS_CH_TX, channel_index, false)). I guess that this is related to the fact that in a gui app created in gnuradio are not called the destructors for the blocks at the end. The same reason is probably for the messages about usb device not being closed. So this is more a gnuradio problem, although it may be solved by putting the turnoff routines into gr block stop method.

  2. the bandwidth problem - the failing call is LMS_SetLPFBW. With LimeSuite commit a2d7d6ac547eb0500a7de8d5e0030a6892789951 5 MHz bandwidth works. With 52d61291f789c7bba070da2642be93aa9dcd6621 (and later - e.g. 618fbb9c3188b36d75ad5785a97b8887dcc468f6) it has to be 10 MHz or higher. Lower values fail with this message:

Tune Tx Filter: MCU error 14 (Tx RCAL_LPF range limit reached,)

This happens even though LMS_GetLPFBWRange returns range from 5000000 to 130000000 Hz (so 5Mhz should be fine). This is at least inconsistent. Strange is, that the error looks like some failure in the MCU, but changing libLimeSuite.so changes the behaviour. So this one looks to me like a bug in LimeSuite, but I am no expert on it.

Thanks for any information.

Pavel