LimeSDR Mini + Macbook Pro (A1398) + High Sierra 10.13.6 + USB Hub = Success

For anyone who has a problem with the LimeSDR Mini not working with OS-X, perhaps this might help:

  1. When connecting my LimeSDR Mini to my mac, the FTDI controller on the LimeSDR was not registering at all - literally. The device was getting power, but the LEDs denoted a problem.

  2. Running the command: ioreg -p IOUSB, showed the following:

±o Root <class IORegistryEntry, id 0x100000100, retain 15>
±o AppleUSBXHCI Root Hub Simulation@14000000 <class AppleUSBRootHubDevice, id 0x10000030d, registered, matched, active, busy 0 (9 ms), retain 10>
±o Bluetooth USB Host Controller@14300000 <class AppleUSBDevice, id 0x1000034a3, registered, matched, active, busy 0 (1 ms), retain 21>
±o Apple Internal Keyboard / Trackpad@14400000 <class AppleUSBDevice, id 0x1000034a7, registered, matched, active, busy 0 (6 ms), retain 19>

This meant that the FTDI controller wasn’t even being recognized as a USB device on the Mac’s Root Hub. Clearly then, no software will work to connect to the LimeSDR Mini (it simply doesn’t exist to the OS)

  1. I then connect the LimeSDR Mini to a USB 3 or 2.0 Hub, then connect the Hub to my mac.
  2. The LimeSDR Mini got power.
  3. I run: ioreg -p IOUSB and get the following:

±o Root <class IORegistryEntry, id 0x100000100, retain 15>
±o AppleUSBXHCI Root Hub Simulation@14000000 <class AppleUSBRootHubDevice, id 0x10000030d, registered, matched, active, busy 0 (9 ms), retain 12>
±o Bluetooth USB Host Controller@14300000 <class AppleUSBDevice, id 0x1000034a3, registered, matched, active, busy 0 (1 ms), retain 21>
±o Apple Internal Keyboard / Trackpad@14400000 <class AppleUSBDevice, id 0x1000034a7, registered, matched, active, busy 0 (6 ms), retain 19>
±o USB3.0 Hub @14500000 <class AppleUSBDevice, id 0x100003cc3, registered, matched, active, busy 0 (1 ms), retain 11>
±o USB2.0 Hub @14100000 <class AppleUSBDevice, id 0x100003ccc, registered, matched, active, busy 0 (1 ms), retain 12>
±o LimeSDR Mini@14130000 <class AppleUSBDevice, id 0x100003d1a, registered, matched, active, busy 0 (5 ms), retain 24>

  1. The SDR software now works - I can even run HDSDR in a Parallels Windows VM and use the LimeSDR Mini.

So if you have the same problem that I did with your mac - that the device isn’t even being recognized by the machine, then please give the USB Hub trick a try…

1 Like

It seems us Mac OSX users are in the distinct minority here. I received my LimeSDR Mini back in July and while it appears to function pretty well, it has this problem where on the first run (osmocom_fft -s 10e6 -a driver=“driver=lime,soapy=0”) everything works as expected but on the second run the Mini is still detected but receives no samples. This essentially forces me to continually unplug and plug each time I run a program. I’ve also had an issue where usb 3.0 operation is very noisy until I wrap my hand the board (shielding, grounding?). Oddly, USB 2.0 mode seems to not have this problem.

Have you had any of these problems?

I have the same problem on OSX (on High Sierra and on Mojave after upgrade).
Tried install ubuntu on parallels - got the same trouble: usb 2.0 - ok, usb 3.0 - first run ok, second gives no samples. On VMware - working ok, but all limiting in samplerate (on >5M sound choppy).

Tried different versions on libusb (brew have specs only for 1.0.22, compiled 1.0.21 manually - all the same, tried HEAD - not working at all).
P.S. it happens everywhere including LimeSuiteGUI FFT…

I have an Ubuntu 16.04 VM (VMWare) running on high-sierra and strangely this eliminates the ‘no samples on 2nd run’ problem for me.

Another anomaly is that if I run GnuRadio Companion outside of the VM I can avoid this problem by using the stop button instead of just closing the window.

I’m assuming this confirms the problem to be software, not hardware fault.

To be honest, I’m afraid to upgrade to Mohave. I have enough difficulty maintaining the delicate balance of functional SDR software.

I tried on Ubuntu 18.04, maybe this is the reason