Looks like you have the Lime-Mini working on Linux and that’s GREAT…! For Windows, please see the post right above this one to @hagster - that will make your Lime-Mini run on GQRX in Windows. I am using the latest Gateware and the version of LimeSuite makes no difference if you’re using the latest Pothos installation from MyriadRF. Try it again and use the settings that I mentioned to @hagster and then let me know your progress.
73 de Marty, KN0CK
only works with 250.000ksps thou
Looking at this again, it appears that it’s just the frequency plot and decoder not working. The waterfall does appear to respond when I tune to 433 and set off a tx. My issue with GQRX appears to be that not all it’s libraries are fully working. I will look into this more this week.
Issues remain on SDR v3 and CubicSDR.
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”.
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.
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
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
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
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