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!
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) :)
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âŚ!
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.
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.
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
I cannot access my boards for now, but after reading the documentation I got two suggestions:
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.
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.
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
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.
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.
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!
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.
