LimeSDR USB works fine but LimeSDR-mini will not work

Oh, so the route it’s taking is UHD (Ettus) -> SoapySDR w/UHD module -> Lime Suite. That’s a long way round, but I guess if it works… Whenever I used Gqrx I just enter a device string of “driver=lime,soapy=0”.

1 Like

@andrewback,

I noticed that, too, but that was a default setting by GQRX and it seemed to work fine. I’ve also had luck using:

driver=lime,soapy=2

…as the means to get the Lime-Mini to play with GQRX. I may have to try going back to ‘soapy=0’ to see if that works with the Mini, too.

73 de Marty, KN0CK

@mcarr and @iracigt: Are there any updates on the libusb errors under macOS? Because I seem to have the exact same issue (solid red LED and blinking green LED and same warning/errors from libusb when using LimeSuiteGUI).

No updates on my side. I tried older and newer libusb issue is still there on the mac osx. Now my VM of Ubuntu 17.10 under fusion works fine on the mac osx system its just the mac osx. I was hoping some one would have a fix. The limesdr USB works great on the mac its just the limesdr mini and how ever the driver is needed is the issue for me

Mike
N4PON

Same here. OSX/High Sierra, everything works fine with my older limeSDR, but not with the new limeSDRMinis that arrived today. Same errors with libusb that others report, and cannot get through the LimeSDR-USB quick test…
I used brew to install limesuite - it looks like this:

Version information:
Library version: v17.12.0-release
Build timestamp: 2018-03-23
Interface version: v2017.12.0
Binary interface: 17.12-1

Any updates yet?
CHeers Hugh (ZL2ASB)

I think I finally have receive working. As I should have mentioned before, I am also running macOS (Sierra 10.12.6) I cloned the master branch of the LimeSuite repository and built LimeSuite from source. Now I can probe the device with SoapySDRUtil. I’m currently trying to get it to work with GNU Radio.

My suggestion to anyone with this (seemingly macOS specific) issue is to try building LimeSuite from source.

Thanks for your feedback everybody. Today I was able to get it somewhat working with LimeSuiteGUI and SDRangel (but not Gqrx) under my Gentoo Linux installation (with much effort). These steps from another thread (including loading the default LDO settings and updating the gateware firmware from 1.22 to 1.24) helped fixing some issues with Linux. At least I now know that the board is not totally broken.

Under macOS I still can’t get it working. This is the output from SoapySDRUtil --probe (running on macOS) as suggested by the previous poster:

######################################################
## Soapy SDR -- the SDR abstraction library
######################################################

Probe device 
[INFO] Make connection: 'LimeSDR Mini [USB 3.0] 1D3A0A1D3E0CAE'
libusb: warning [ep_to_pipeRef] no pipeRef found with endpoint address 0x01.
libusb: error [submit_bulk_transfer] endpoint not found on any open interface
libusb: warning [ep_to_pipeRef] no pipeRef found with endpoint address 0x01.
libusb: error [submit_bulk_transfer] endpoint not found on any open interface
libusb: warning [ep_to_pipeRef] no pipeRef found with endpoint address 0x01.
libusb: error [submit_bulk_transfer] endpoint not found on any open interface
libusb: warning [darwin_transfer_status] transfer error: timed out
libusb: warning [darwin_transfer_status] transfer error: timed out
libusb: warning [darwin_transfer_status] transfer error: timed out
libusb: warning [darwin_transfer_status] transfer error: timed out
libusb: warning [darwin_transfer_status] transfer error: timed out
libusb: warning [darwin_transfer_status] transfer error: timed out
[INFO] Device name: UNKNOWN
[INFO] Reference: 40 MHz
[INFO] Init LMS7002M(0)
libusb: warning [darwin_transfer_status] transfer error: timed out
libusb: warning [darwin_transfer_status] transfer error: timed out
libusb: warning [darwin_transfer_status] transfer error: timed out
libusb: warning [darwin_transfer_status] transfer error: timed out
[INFO] Ver=0, Rev=0, Mask=0
libusb: warning [darwin_transfer_status] transfer error: timed out
Error probing device: ResetChip() failed
libusb: warning [libusb_exit] application left some devices open

Not sure if the LimeSDR Mini on Mac OS issue might be related to this PR:

Asked @IgnasJ to review.

Hm, the issue with libusb on macOS seems to be gone when I use LimeSuite built from source whereas the version in the Pothos Homebrew tap (brew install pothosware/pothos/limesuite) produces the libusb errors.

I also noticed that installing Gqrx via Homebrew-Cask (brew install gqrx) creates symlinks for SoapySDRUtil pointing into the Gqrx application:

/usr/local/bin/SoapySDRUtil -> /Applications/Gqrx.app/Contents/MacOS/SoapySDRUtil

This means Gqrx ships its own SoapySDRUtil. This version did not include the lime driver (SoapySDRUtil --check=lime returned Checking driver 'lime'... MISSING!), so Gqrx also did not provide the LimeSDR in the device dropdown. I then reinstalled SoapySDR via Homebrew (brew install pothosware/pothos/soapysdr && brew link --overwrite soapysdr to overwrite the exisiting symlink) which at least made SoapySDR find the LimeSDR Mini.

Unfortunately Gqrx still does not work with the LimeSDR Mini: When I start it from the command line via /Applications/Gqrx.app/Contents/MacOS/gqrx I see a line with following error:

FATAL: SoapySDR::Device::make() no match

This seems to be a bug in Gqrx or SoapySDR, as I get the same error on my Gentoo Linux installation. Also see Gqrx for limeSDR on RPI3 where the maintainer of Gqrx addresses this error.

Edit: There is this Gqrx GitHub issue which might help fixing the SoapySDR shipped with it: https://github.com/csete/gqrx/issues/556

This doesn’t seem to be a reliable way of using Gqrx anyway. Try instead device string “soapy=0,driver=lime”.

Homebrew probably needs updating.

It’s definitively not reliable as the device sometimes is listed, but mostly not. With the manually installed LimeSuite and SoapySDR from Pothos’ Homebrew tap I mostly automatically get the Device String field filled automatically which seems to be a good sign. But I also tried soapy=0,driver=lime with the same result: The FFT window and waterfall keep staying black when I start DSP processing. For my HackRF One this works like a charm, so Gqrx works partially.

I solved my mac os x issue where libusb produced and error when using the LimeSDR Mini. Another user had recomended doing this. Had to compile LimeSuiteGUI from source. It installed version 18.03.0-ge37677bb. Brew for os x install will not install it correctly.

This was the mac os x error
libusb: warning [ep_to_pipeRef] no pipeRef found with endpoint address 0x01.
libusb: error [submit_bulk_transfer] endpoint not found on any open interface


Soapy find info below

Found device 2
addr = 24607:1027
driver = lime
label = LimeSDR Mini [USB 3.0] 1D3A0A6A68B1F5
media = USB 3.0
module = FT601
name = LimeSDR Mini
serial = 1D3A0A6A68B1F5

Before is start gnuradio-companion I set the new paths for python and soapy example below in terminal window that I am going to use for gnuradio-companion

PYTHONPATH=$PYTHONPATH:/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages

export PYTHONPATH

export SOAPY_SDR_PLUGIN_PATH=/usr/local/lib/SoapySDR/modules0.6

Then run
gnuradio-companion


GNURADIO-COMPANION loger window below

Generating: ‘/Users/Mr_X/Documents/top_block.py’

Executing: /opt/local/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python -u /Users/Mr_X/Documents/top_block.py

Mac OS; Clang version 9.0.0 (clang-900.0.39.2); Boost_106501; UHD_003.010.002.000-MacPorts-Release

gr-osmosdr v0.1.x-xxx-xunknown (0.1.5git) gnuradio 3.7.11
built-in source types: file fcd rtl rtl_tcp uhd sdrplay hackrf bladerf rfspace airspy soapy
[INFO] Make connection: ‘LimeSDR Mini [USB 2.0] 1D3A0A6A68B1F5’
[INFO] Reference clock 40.00 MHz
[INFO] Device name: LimeSDR-Mini
[INFO] Reference: 4e+07 MHz
[INFO] LMS7002M calibration values caching Disable
[INFO] RX LPF configured
[INFO] Rx calibration finished


If I try and configure an Antenna port I get a TX error un know antenna port so I just leave blank in the osmo source on gnuradio.

Mike
N4PON

Mike, the mini has the following TX ports:
BAND1
BAND2

And the following RX ports:
LNAL
LNAH
LNAW

I mostly use BAND1 and LNAW for sub 2 GHz work.
Hope this helps.

Limesdr Mini

Thanks for the reply @adim if I put LNAW in the CH0 :Antenna: field on the OSMOCOM source block it throws the following error below. But looking at GQRX it uses LNA_W. GQRX is working so I tried the LNA_W and it seems to work. I can cycle through the ports if I use the under score LNA_W or LNA_H. I thought for sure it would be the LNAW like the limesdr USB but something changed when I reinstalled the LimeSuiteGUI

This is what happens if I use LNAW


Generating: ‘/Users/Mr_X/Documents/top_block.py’

Executing: /opt/local/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python -u /Users/Mr_X/Documents/top_block.py

Mac OS; Clang version 9.0.0 (clang-900.0.39.2); Boost_106501; UHD_003.010.002.000-MacPorts-Release

gr-osmosdr v0.1.x-xxx-xunknown (0.1.5git) gnuradio 3.7.11
built-in source types: file fcd rtl rtl_tcp uhd sdrplay hackrf bladerf rfspace airspy soapy
[INFO] Make connection: ‘LimeSDR Mini [USB 3.0] 1D3A0A6A68B1F5’
[INFO] Reference clock 40.00 MHz
[INFO] Device name: LimeSDR-Mini
[INFO] Reference: 4e+07 MHz
[INFO] LMS7002M calibration values caching Disable
Traceback (most recent call last):
File “/Users/Mr_X/Documents/top_block.py”, line 232, in
main()
File “/Users/Mr_X/Documents/top_block.py”, line 226, in main
tb = top_block_cls()
File “/Users/Mr_X/Documents/top_block.py”, line 169, in init
self.osmosdr_source_1.set_antenna(‘LNAW’, 0)
File “/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/osmosdr/osmosdr_swig.py”, line 1759, in set_antenna
return _osmosdr_swig.source_sptr_set_antenna(self, antenna, chan)
RuntimeError: SoapyLMS7::setAntenna(TX, LNAW) - unknown antenna name



But if I use LNA_W in the CH0:Antenna: field it shows no errors

Generating: ‘/Users/Mr_X/top_block.py’

Executing: /opt/local/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python -u /Users/Mr_X/top_block.py

Mac OS; Clang version 9.0.0 (clang-900.0.39.2); Boost_106501; UHD_003.010.002.000-MacPorts-Release

gr-osmosdr v0.1.x-xxx-xunknown (0.1.5git) gnuradio 3.7.11
built-in source types: file fcd rtl rtl_tcp uhd sdrplay hackrf bladerf rfspace airspy soapy
[INFO] Make connection: ‘LimeSDR Mini [USB 3.0] 1D3A0A6A68B1F5’
[INFO] Reference clock 40.00 MHz
[INFO] Device name: LimeSDR-Mini
[INFO] Reference: 4e+07 MHz
[INFO] LMS7002M calibration values caching Disable
[INFO] RX LPF configured
[INFO] Rx calibration finished

That’s because LNAW is RX and you’re trying to set the TX antenna. Try BAND1 or BAND2 depending on your operating frequency. At least that’s what the pre-production boards accept.

Under the Osmocom source block how can I only set the receive antenna as I am using the Limesdr mini as a receive source. I have not configured a TX block source. It wants to set the TX for some reason on a receive only block in Gnuradio.

You obviously have an Osmocom sink somewhere in that flowgraph. I can tell by this line:
RuntimeError: SoapyLMS7::setAntenna(TX, LNAW) - unknown antenna name

I deleted the project and created a new one. Same issue it thinks I am using a sink but I am only using a source. Here is a screen shot. I will mostly need to rebuild gnuradio and osmocom back into the it. It has to be corrupt

.

This looks more like a bug in the Osmocom <-> SoapySDR connection. That should not happen.
FWIW I tested locally that I can use an Osmocom source with antenna set to LNAW and RX BW set to 2 MHz and it works. Either different software version or exposed issue somewhere.

Hopefully Brew install should work now: