Can't see my new LimeSDR

Projects LimeSDR
1

So I got my LimeSDR, one of the Aluminum kit builds with the HF mod.

I’ve plugged it into my Linux box and got nothing. In trying to look through the ventilation cutout on the enclosure it appears I’ve got a green LED on and an LED that is flashing red/green. And when it is plugged in the only device that appears on USB is 1d50:6108 OpenMoko, Inc which suggests to me that it is sitting in a DFU loader or something. What next? This isn’t included in the ‘getting started guides’ I have read.

–Chuck

2

Well I still don’t know what the issue is but I ran “LimeUtil --update” and it claims to have successfully updated. So that application can see it. My original task was to have it visible as a source in gnuradio companion, no luck there. And I’ve installed “SoapySDR” from the PPA and SoapySDRUtil --info does show ‘lime’ as an available factory. Still trying to figure out how to get GRC to see it.

3

And to follow up still further, the SoapySDR --find=“driver=lime” gives reasonable results. (it finds the SDR). So I am down to how to plumb it with GRC.

4

My osmosdr install (done with apt install) only knows about
file osmosdr fcd rtl rtl_tcp uhd miri hackrf bladerf rfspace airspy redpitaya
So no soapysdr and no limesdr to be sure.

5

And to finish out the tour of identifying what does and doesn’t work. So I went through the LimeSuite USB quickstart and all of that works. I can run the selftest script and use the example script to tune around and look at things.

So at this point all I really need ia either gr-osmosdr support for Gnu Radio or a module that I can add to grc that will talk to the LimeSDR board.

6

Build gqrx from source, or try sdrangel …

Gqrx worked for me … not angel

7

Hello Chuck,

From a previous attempt at using GNU radio with the LimeSDR, you use the “OSMOCOM” source or sink block to connect to the LimeSDR, in the driver section of those blocks I believe the string required is “soapy=0,driver=lime”.

Hope this helps,
Bevan

9

Hi Bevan,

That still fails with the packaged gr-osmo so I’m guessing I’ll have to build from source to get the latest. The challenge in such situations is always dependencies.

–Chuck

10

You either use packages and accept that you will be a tiny bit behind the cutting edge, or you use source code, it is extremely complicated to mix. Do one or the other but never both or you will always have weird dependencies issues.

1 Like
11

So LimeSuite works but gnuradio-companion does not. I rebuilt gr-osmosdr from source (since the one that came out of the PPA didn’t seem to support SoapySDR. Unfortunately per @mzs above mixing ‘from source’ and from ppa/packages is a world of hurt. Is there anyone online who is a gnuradio + limesdr experienced person, would prefer to get my existing design flow up and tested before I toss it for an entirely new and incompatible tool stack.

–Chuck

12

That should be:

“soapy=0,driver=lime”

Note the use of a comma and not colon.

13

Thanks Andrew,
I initially had it as a comma, then I was playing with GNU yesterday and put the colon in the Sink block and found it worked, therefore thought I was misleading other users so changed the post here, tonight I have tested both ways with out noticing any real difference, but I have put it back to a comma as that is the preferred method.
Regards,
Bevan

14

That’s good to know! Hadn’t tried colon, but we’ve been using comma and assumed just this worked as a delimiter.

15

Ok, so a bit closer on using gnuradio-companion. I’ve managed rebuild the gr-osmosdr stuff from source, and I’ve monkey patched them into the right places so that now when I add the osmocom source to my flow with the soapy=0:device=lime device name it finds the LimeSDR. Not getting any data though. This is what I do get:

linux; GNU C++ version 5.3.1 20151219; Boost_105800; UHD_003.009.002-0-unknown

Using Volk machine: avx2_64_mmx_orc
gr-osmosdr v0.1.4-98-gc653754d (0.1.5git) gnuradio 3.7.9
built-in source types: file osmosdr fcd uhd miri hackrf bladerf rfspace airspy soapy redpitaya freesrp 
-- Make connection: 'LimeSDR-USB [USB 3.0] 9062A00CE0F12'
-- Estimated reference clock 30.7196 MHz
-- Selected reference clock 30.720 MHz
-- Device name: LimeSDR-USB
-- Reference: 30.72 MHz
-- Init LMS7002M(0)
-- LMS7002M cache /home/cmcmanis/.limesuite/LMS7002M_cache_values.db
-- Ver=7, Rev=1, Mask=1
-- LMS7002M calibration values caching Enable
CGEN: Freq=80 MHz, VCO=2.56 GHz, INT=82, FRAC=349525, DIV_OUTCH_CGEN=15
M=156, N=3, Fvco=1040.000 MHz
16: FF AF AA
16: AA AA 3C
phase: min 26.0; max 197.3; selected 111.6)
M=156, N=3, Fvco=1040.000 MHz
M=182, N=7, Fvco=1040.000 MHz
16: AA 5A 75
16: AA 52 D5
phase: min 10.4; max 176.5; selected 93.5)
M=182, N=7, Fvco=1040.000 MHz
M=156, N=3, Fvco=1040.000 MHz
16: FF AF AA
16: A9 AA 7C
phase: min 26.0; max 197.3; selected 111.6)
M=156, N=3, Fvco=1040.000 MHz
M=156, N=3, Fvco=1040.000 MHz
16: 77 9D 3B
16: 2A DC 7D
16: AA 52 D5
phase: min 15.6; max 176.5; selected 96.1)
M=156, N=3, Fvco=1040.000 MHz
-- Rx Filter calibrated from cache
-- Tx Filter calibrated from cache
M=156, N=3, Fvco=1040.000 MHz
phase: min 5.2; max 360.0; selected 182.6)
M=156, N=3, Fvco=1040.000 MHz
M=182, N=7, Fvco=1040.000 MHz
phase: min 5.2; max 360.0; selected 182.6)
M=182, N=7, Fvco=1040.000 MHz
M=156, N=3, Fvco=1040.000 MHz
phase: min 5.2; max 360.0; selected 182.6)
M=156, N=3, Fvco=1040.000 MHz
M=156, N=3, Fvco=1040.000 MHz
phase: min 5.2; max 360.0; selected 182.6)
M=156, N=3, Fvco=1040.000 MHz
-- Rx Filter calibrated from cache
-- Tx Filter calibrated from cache

FATAL: std::bad_alloc

Trying to fill up 1 missing channel(s) with null source(s).
This is being done to prevent the application from crashing
due to gnuradio bug #528.
16

And if you’re wondering I am using the simplest of flowgraphs, the osmocom source with a sample rate of 20Mhz and a channel 0 frequency of 100Mhz feeding into an FFT widget. I’ve got an ANT500 attached to the HF input on the LimeSDR.

–Chuck

17

And per another conversation on the web it suggested I could put into the ANT0 string which antenna port to use. The note that came with my LimeSDR said that the HF mod was done on port LNAW_A

SoapySDRUtil --probe="device=lime" suggests that RX channel zero has antennae NONE, LNAH, LNAL, LNAW, LB1, LB2 (same as RX channel 1)

However using LNAW or LNAW_A has no effect on whether or not I get IQ data from the SDR. In all cases I’m still seeing that ‘trying to fill up 1 missing channel(s) with null source(s)’ error.

For now I’ve left the other settings for Channel 0 at their defaults, gains set at 10/20/20 offsets and balances all set to Automatic.

(Oh and its probably important to note that I’ve got the aluminum case version so I only have access to four SMA connectors (presumably 2x RX and 2x TX) all have antennas attached (the default wideband one the case of the other three ports)

What am I missing here?
–Chuck