Gr-limesdr - LimeSDR plugin for GNURadio

I am happy to share gr-limesdr plugin based on LimeSDR API for GNU Radio. This allows to communicate with LimeSDR boards from GNU Radio directly via LimeSDR API, without additional software layers (like UHD). Check the Wiki page for installation instructions, links and documentation:
https://wiki.myriadrf.org/Gr-limesdr_Plugin_for_GNURadio

LimeSDR-USB and LimeSDR-Mini boards supported under Linux OS for now.

Note please, that it is beta version for now, hence comments and notes are welcome. Thank you all for your support!

11 Likes

Great news! Definitely going to try that and report any issues. It’s great that we have three options to access LimeSDR hardware im GNU Radio now (osmocom blocks, UHD blocks and these native ones) :):smiley:

@Zack,

This IS great news…! For those installing it for the first time, provide some details of the software setup so the newbies can get this running right out of the chute. Great job on this…!

73 de Marty, KN0CK

1 Like

All my apps are hardware-agnostic, via gr-osmosdr and SoapySDR. MOST apps that I’ve seen that are hardware-specific really have no overwhelming reason for that. So, while this provides folks with “yet another option” for GR<---->Lime integration, hardware abstraction is still the right
approach, IMHO, for many classes of application.

Hardware abstraction is a laudable aim and great when it works to provide portability across different platforms. However, it does kind of assume one-size-fits-all, meaning that more advanced hardware-specific capabilities end up being buried. As the number of layers stack up it also complicates support and leads to greater uncertainty.

1 Like

Well, sure, one can see the benefits of having an API that can take advantage of all the hardware features.

But let me use a “proximate analogy”. Image that every computer application had to “understand” the disk hardware in order to write a file? Or that there was no generic way to paint a picture on a computer display?

Abstraction is the reason the world has such a rich array of applications–the developers don’t have to wire-in knowledge of every little detail of the hardware the application ends up “talking to”.

I do tech-support in the SDR universe, so I know what a PITA it is to peel-apart the abstraction onion when problems happen. But abstractions are a necessary part of our technological world…

I agree that SoapySDR/UHD abstraction layers are helpful when you want to develop hardware-independent application, but like @andrewback said, this plugin is rather for people who want to fine tune these specific boards (LimeSDR-USB and LimeSDR-Mini), as is gives you access to basically all relevant settings, which are often not accessible via SoapySDR/UHD APIs.

1 Like

Step 2.4.2 Building and installing gr-limesdr from source in wiki
Is missing the Line
mkdir build

so should look like this
cd gr-limesdr
mkdir build
cd build
cmake …
make
sudo make install
sudo ldconfig

oh2eko is correct above. guide assumes there was a directory already created in gr-limesdr/build
anyhow i loaded up the fm example and switched my source from lime-usb to lime-mini and hit generate button then run button and it worked
hopefully i can learn alot just from that example config as there is nothing in grc or pothos that is helping noobs to lime hardware

would appreciate you guys who know this stuff to make some more examples.
a “replay” example would be awesome
ex: my cars keyfob where i could capture and then replay and it would reproduce the same signal.
that would be awesome

1 Like

I cannot access my boards for now, but after reading the documentation I got two suggestions:

  1. Personally I would prefer determining particular board on the basis of its serial number rather than device number from LimeUtil --find. It will allow you to bind particular board to specific part of your flowgraph (say that for some reason you always want to use particular board X for TX and some other particular board Y for RX part of your flowgraph). Let’s not fall into device identification issues like the ones known from rtl-sdr dongles.
  2. So far it looks like simultaneous transmission/reception at different frequencies for both channels is impossible. I think that along with RF center frequency, you should also be able to set different digital (NCO) frequency offsets for both channels (in TX and RX directions). For now it looks like UHD blocks are the only way to go if you want to do that in GNU Radio.

Thanks, updated.

Thanks, noted. Will be implemented in the feature release.

Looks good! But I look forward to a version that works on macOS…!

@zack Can you please add the settings for LIMESDR-PCIe to the documentation :
https://wiki.myriadrf.org/Gr-limesdr_Plugin_for_GNURadio

gr-osmosdr is lacking many features that can be found in gr-uhd (like control through messages and stream tags), which is USRPs counterpart for gr-limesdr. Without these features something like GSM mobile station burst transceiver that we presented here: https://www.youtube.com/watch?v=0z08eL5BWJs
would be harder to do. I hope the new gr-limesdr block will support stream tags and message passing interfaces - perfectly in a way compatible with gr-uhd.

Regarding alleged rtl-sdr identification issues - I thought everyone knows that you can assign a serial number to it with:
rtl_eeprom -d 0 -s 00000002

where 00000002 is example of serial number.

Then you can use it to address the devices without having to worry that after reconnecting it will have different id. In gr-osmodr source you can select the device in args field with:
rtl=00000002

Sorry for offtopic but I wouldn’t like this incorrect conviction to be reiterated again in here.

Of course I am aware of that, but I am also quite sure that in some particular case it was still impossible to identify RTL-SDR device by serial number in GNU Radio, but I don’t remember details as it was long time ago. As far as I remember I was using RTL-SDR source block, not osmocom one. But it is possibile that it was fixed meantime, so I won’t argue :wink:

Anyway, I still think that using serial number to identify LimeSDR board is better idea than using number from LimeUtil list in case of this plugin.

Thank you for gr-limesdr.

I think that many people which are like me, with basic programming skill, would love to have pybombs support for gr-limesdr like for the LimeSuite. Is it planned ?

In a future release, it would be nice to be able to change Center frequency and Sample rate while executing the flow graph.

73 de Michel, HB9DUG

Hello, I keep getting this error when I run the FM receiver example:

File “gr-limesdr/examples/top_block.py”, line 148, in init
self.limesdr_source_0_0 = limesdr.source(0,
AttributeError: ‘module’ object has no attribute ‘source’

Does anybody have any idea how I should address this?
Thanks for the help!

1 Like

Loooks like argilo already added a new recipe to pybombs: gr-recipes/gr-limesdr.lwr at master · gnuradio/gr-recipes · GitHub
But it will not work until the gr-limesdr build process is tweaked: Use FindPkgConfig to find LimeSuite so PyBOMBS works. by argilo · Pull Request #8 · myriadrf/gr-limesdr · GitHub

As with everything new, it takes a little bit of time.

I would like to report that while playing with the LimeSuite Sink (TX) block, I have seen on spectrum analyzer a dangerous behavior of the block. When you start your graph, the LimeSDR Mini goes full output power and then settle to the gain fixed in the block. Same issue with the FM_transmitter example.