LimeSDR Mini with FreeBSD

General Discussion
1

Dear all,

I wonder if there is any information on using the LimeSDR Mini with FreeBSD, or if anyone has made experiences with it. I wasn’t successful with searching the internet (or this site) for LimeSDR Mini and FreeBSD.

Under FreeBSD, the device is (generally) recognized and identifies as follows:

# usbconfig -u 2 -a 2
ugen2.2: <Lime Micro LimeSDR Mini> at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (388mA)

The FreeBSD pkg system provides a package SoapySDR-0.7.2 which I installed. I also downloaded LimeSuite-20.01.0.tar.gz to compile the SoapySDR driver as well as the LimeQuickTest.

Compiling the LimeQuickTest failes as follows:

% cd builddir
% make LimeQuickTest
[...]
[ 89%] Building CXX object QuickTest/CMakeFiles/LimeQuickTest.dir/TestGUI.cpp.o
In file included from /home/flocke/install/LimeSuite-20.01.0/QuickTest/TestGUI.cpp:7:
In file included from /usr/local/include/FL/fl_draw.H:27:
In file included from /usr/local/include/FL/x.H:37:
/usr/local/include/X11/Xlib.h:44:10: fatal error: 'X11/X.h' file not found
#include <X11/X.h>
         ^~~~~~~~~
1 error generated.
*** Error code 1

However, compiling SoapyLMS7 worked, and I could copy the builddir/SoapyLMS7/libLMS7Support.so file to the /usr/local/lib/SoapySDR/modules0.7/ directory.

SoapySDRUtil then gives me the following output:

% SoapySDRUtil --info
######################################################
##     Soapy SDR -- the SDR abstraction library     ##
######################################################

Lib Version: v0.7.2-unknown
API Version: v0.7.1
ABI Version: v0.7
Install root: /usr/local
Search path:  /usr/local/lib/SoapySDR/modules0.7
Module found: /usr/local/lib/SoapySDR/modules0.7/libLMS7Support.so   (20.01.0)
Module found: /usr/local/lib/SoapySDR/modules0.7/libremoteSupport.so (0.5.1)
Module found: /usr/local/lib/SoapySDR/modules0.7/librtlsdrSupport.so (0.3.0)
Available factories... lime, remote, rtlsdr
Available converters...
 -  CF32 -> [CF32, CS16, CS8, CU16, CU8]
 -  CS16 -> [CF32, CS16, CS8, CU16, CU8]
[...]

And trying to initialize the device causes:

% SoapySDRUtil --make="driver=lime"
######################################################
##     Soapy SDR -- the SDR abstraction library     ##
######################################################

Make device driver=lime
LIBUSB_FUNCTION: libusb_handle_events_timeout_completed enter
LIBUSB_FUNCTION: libusb10_handle_events_sub enter
LIBUSB_FUNCTION: libusb_handle_events_timeout_completed enter
LIBUSB_FUNCTION: libusb10_handle_events_sub enter
LIBUSB_FUNCTION: libusb_handle_events_timeout_completed exit
LIBUSB_FUNCTION: libusb_handle_events_timeout_completed enter
LIBUSB_FUNCTION: libusb10_handle_events_sub enter
LIBUSB_FUNCTION: libusb_handle_events_timeout_completed exit
LIBUSB_FUNCTION: libusb_handle_events_timeout_completed enter
LIBUSB_FUNCTION: libusb10_handle_events_sub enter
LIBUSB_FUNCTION: libusb_handle_events_timeout_completed exit
LIBUSB_FUNCTION: libusb_handle_events_timeout_completed enter
LIBUSB_FUNCTION: libusb10_handle_events_sub enter
[INFO] Make connection: 'LimeSDR Mini [USB 2.0] 1D3AC7FE409032'
LIBUSB_FUNCTION: libusb_handle_events_timeout_completed exit
LIBUSB_FUNCTION: libusb_handle_events_timeout_completed enter
LIBUSB_FUNCTION: libusb10_handle_events_sub enter
LIBUSB_FUNCTION: libusb_handle_events_timeout_completed exit
LIBUSB_FUNCTION: libusb_handle_events_timeout_completed enter
LIBUSB_FUNCTION: libusb10_handle_events_sub enter
LIBUSB_FUNCTION: libusb_handle_events_timeout_completed exit
LIBUSB_FUNCTION: libusb_handle_events_timeout_completed enter
LIBUSB_FUNCTION: libusb10_handle_events_sub enter
LIBUSB_FUNCTION: libusb_handle_events_timeout_completed exit
LIBUSB_FUNCTION: libusb_handle_events_timeout_completed enter
LIBUSB_FUNCTION: libusb10_handle_events_sub enter
[ERROR] USB reset failed
[ERROR] Failed to open device
LIBUSB_FUNCTION: libusb_bulk_transfer enter
LIBUSB_FUNCTION: libusb_submit_transfer enter
LIBUSB_FUNCTION: libusb_submit_transfer leave 0
LIBUSB_TRANSFER: sync I/O done
LIBUSB_FUNCTION: libusb_handle_events_timeout_completed exit
LIBUSB_FUNCTION: libusb_handle_events_timeout_completed enter
LIBUSB_FUNCTION: libusb10_handle_events_sub enter
LIBUSB_FUNCTION: libusb_handle_events_timeout_completed enter
LIBUSB_FUNCTION: libusb_handle_events_timeout_completed exit
LIBUSB_FUNCTION: libusb_handle_events_timeout_completed enter
LIBUSB_FUNCTION: libusb10_handle_events_sub enter
LIBUSB_FUNCTION: libusb_handle_events_timeout_completed exit
LIBUSB_FUNCTION: libusb_handle_events_timeout_completed enter
LIBUSB_FUNCTION: libusb10_handle_events_sub enter
LIBUSB_FUNCTION: libusb_wait_for_event enter
LIBUSB_FUNCTION: libusb_handle_events_timeout_completed exit
LIBUSB_FUNCTION: libusb_handle_events_timeout_completed exit
LIBUSB_FUNCTION: libusb_handle_events_timeout_completed enter
LIBUSB_FUNCTION: libusb10_handle_events_sub enter
LIBUSB_FUNCTION: libusb_bulk_transfer leave
LIBUSB_FUNCTION: libusb_handle_events_timeout_completed exit
LIBUSB_FUNCTION: libusb_handle_events_timeout_completed enter
LIBUSB_FUNCTION: libusb10_handle_events_sub enter
LIBUSB_FUNCTION: libusb_bulk_transfer enter
LIBUSB_FUNCTION: libusb_submit_transfer enter
LIBUSB_FUNCTION: libusb_handle_events_timeout_completed exit
LIBUSB_FUNCTION: libusb_submit_transfer leave 0
LIBUSB_FUNCTION: libusb_handle_events_timeout_completed enter
LIBUSB_FUNCTION: libusb10_handle_events_sub enter
LIBUSB_FUNCTION: libusb_handle_events_timeout_completed enter
LIBUSB_TRANSFER: sync I/O done
LIBUSB_FUNCTION: libusb_wait_for_event enter
LIBUSB_FUNCTION: libusb_handle_events_timeout_completed exit
LIBUSB_FUNCTION: libusb_bulk_transfer leave
LIBUSB_FUNCTION: libusb_handle_events_timeout_completed exit
LIBUSB_FUNCTION: libusb_handle_events_timeout_completed enter
LIBUSB_FUNCTION: libusb10_handle_events_sub enter
LIBUSB_FUNCTION: libusb_handle_events_timeout_completed exit
LIBUSB_FUNCTION: libusb_handle_events_timeout_completed enter
LIBUSB_FUNCTION: libusb10_handle_events_sub enter
[ERROR] Failed to open. Device is busy.
Error making device: Failed to make connection with 'LimeSDR Mini, media=USB 2.0, module=FT601, addr=24607:1027, serial=1D3AC7FE409032'
LIBUSB_FUNCTION: libusb_handle_events_timeout_completed exit
LIBUSB_FUNCTION: libusb_handle_events_timeout_completed enter
LIBUSB_FUNCTION: libusb10_handle_events_sub enter
LIBUSB_FUNCTION: libusb_handle_events_timeout_completed exit
LIBUSB_FUNCTION: libusb_handle_events_timeout_completed exit

I get similar errors when I write a C program which attempts to make the device:

[...]
[ERROR] USB reset failed
[ERROR] Failed to open device
[...]
[ERROR] Failed to open. Device is busy.
Could not open device: Failed to make connection with 'LimeSDR Mini, media=USB 2.0, module=FT601, addr=24607:1027, serial=1D3AC7FE409032'
[...]

I made sure to have proper permissions on the /dev/usb/2.2.* files.

I have used the same software stack successfully with an RTLSDR, and the same LimeSDR Mini stick also works fine on a Linux system.

I also discovered that there have been issues with LimeSDR Mini and libusb:
LimeSDR-Mini doesn’t work with latest libusb on macOS #253

I’m not sure if I have encountered a similar problem or if my problems are something entirely different.

My libusb seems to be shipped with the FreeBSD operating system. My FreeBSD version is 12.1-RELEASE-p6.

Using Linux, the firmware of the LimeSDR Mini has been upgraded as well, but that didn’t help either.

Any help or references to further reading material would be appreciated!

1 Like
2

I’m not aware of anyone else having used LimeSDR hardware with *BSD and on doing a quick search, it looks as though FreeBSD has a re-implementation of libusb.

So it could be that there are some API and/or behaviour differences. Unless someone else comments here with suggestions, may be worth asking in the FreeBSD community, as it’s possible that there are certain considerations when building apps that use libusb.

Sure, it’s unlikely to be SoapySDR specific and instead to be an issue in Lime Suite<>FreeBSD libusb.

3

I’m not aware of anyone else having used LimeSDR hardware with *BSD

At least, nobody seems to talk about their experiences with LimeSDR and FreeBSD on the internet. Not sure if that means there have been no attempts. I did some attempts about 2 years ago (when my knowledge about HF was much more limited) but I had to give up after some frustration.

Now that I have a bit more knowledge and managed to get the LimeSDR Mini work properly with SoapySDR on a Linux system using my own C program, I would like to revisit trying getting it to run on FreeBSD, and I think there would be a benefit for others as well.

The FreeBSD package system comes with a current release of SoapySDR and it wasn’t too difficult to build the SoapyLMS7 driver for the LimeSDR (Mini). (Despite the fact that it doesn’t work yet and fails with the USB error.)

However, other parts of the LimeSuite do not compile on my FreeBSD system. These errors (fatal error: ‘X11/X.h’ file not found) do not seem to be related to the libusb issues and could be fixed independently (assuming one has enough knowledge on the Lime Suite’s build system, which I don’t have).

[…] on doing a quick search, it looks as though FreeBSD has a re-implementation of libusb. […] So it could be that there are some API and/or behaviour differences. Unless someone else comments here with suggestions, may be worth asking in the FreeBSD community, as it’s possible that there are certain considerations when building apps that use libusb.

I am happy to ask on the FreeBSD USB mailinglist, but if possible, I would like to gather some more verbose error description first. Does anyone know of any way to get a more verbose output than “[ERROR] USB reset failed”?

Sure, it’s unlikely to be SoapySDR specific and instead to be an issue in Lime Suite<>FreeBSD libusb.

Yes, it seems to be an issue with Lime Suite and FreeBSD, as initializing an RTLSDR with SoapySDR with the same C program works fine.

4

Absolutely, would be great to see people using LimeSDR with BSD systems.

That’s X11, the windowing system. Assuming the system is not headless and has X installed (including dev packages), this is probably just installed to a different place and Cmake config might need updating.

Worth looking at the FreeBSD docs to see if you can build with increased debugging.

5

I tried to see if I can increase libusb’s verbosity level. In lines 41 and 43 of LimeSuite-20.01.0/src/ConnectionFTDI/ConnectionFT601Entry.cpp the verbosity level gets set to 3.

This seems to be the maximum value, as increasing or lowering it only gets me less verbosity. I’m not sure if there’s any way to increase debugging output at compile time, but I doubt it.

Further searching in Lime Suite’s code brought me to the function that supposedly throws the error: ConnectionFT601::Open in file LimeSuite-20.01.0/src/ConnectionFTDI/ConnectionFT601.cpp

6

I just asked for help on the FreeBSD-USB mailinglist.

7

I might have a partial solution now. Simply commenting out the following two lines helped:

if (libusb_reset_device(dev_handle)!=0)
    return ReportError(-1, "USB reset failed", libusb_strerror(libusb_error(r)));

I recompiled the library and was able to successfully record an I/Q stream.

As this is just a quick-and-dirty hack (and I’m not sure if there are any bad side effects), I’d still like to see the problem solved more cleanly.

1 Like
8

I have some good news in regard to figuring out what’s the problem.

Apparently, libusb_reset_device() sometimes executes certain operations which require privileges beyond having access to the /dev/usb/* device node entries. Running every program as root seems to “fix” the problem (granting access to the device nodes does not), but isn’t a practical solution.

I wonder if FreeBSD’s libusb should (and/or could) be fixed to ensure libusb_reset_device() can be run as non-root user, or if the Lime Suite should be fixed to not call libusb_reset_device() at all because it might be an administrative call that should never be used by a user of a USB device. I’m not sure what’s right to do. Particularly, I don’t know why the Lime Suite developers included that call, and I don’t even fully understand (yet) what it does.

The discussion with the FreeBSD community is going on on the freebsd-usb mailinglist, in case you want to follow up on our discussion there. Some helpful hints from the Lime Suite developers would be appreciated on the list (or on this forum, as I can also forward hints posted here).

In addition to the problem with access rights as non-root users (despite having access to the particular device), there seem to be some timing errors (see my original post on top of this thread). I wonder if it’s possible to provide the FreeBSD USB community with a free sample in order to figure out what’s wrong. I think it would also be in the best interest of the manufacturer to get FreeBSD support this device properly (as well as it’s a gain for the FreeBSD community to be able to support such an amazing device!).

9

I suspect that the second option might not be viable and seems to me that if you have access to a device, you should be able to reset it. Under Linux such access is managed via udev rules, which say which users/groups have access to which devices and to what level. No idea if FreeBSD has something similar…

Hence I think this is a question of how FreeBSD manages device access and given there is a working model on Linux, with libusb and udev, it’s for them to decide if they want to replicate this approach or do something different.

Tagging @Garmus in case he has anything to add.

Sure, if one of their developers is willing to take a look I am sure this could be arrange. Just PM me if someone volunteers.

10

This particular build error has been fixed after installing the most recent FreeBSD package of xorgproto (xorgproto-2020.1).

There are some more build issues, but those can be fixed by modifying a couple of CMakeLists.txt files. I am working on figuring out how to do it in a clean way. Also wxWidgets is not found by cmake, but a possible workaround is to link /usr/local/bin/wxgtk3u-3.1-config to ~/bin/wx-config if the user’s bin-directory is in the search path.

I was able to compile both the SoapyLMS7 module as well as the LimeUtil and LimeSuiteGUI binaries for FreeBSD (and the example programs provided with Lime Suite).

I still don’t understand the GUI well enough to figure out if it’s working properly. I got several errors, but at least I could read the device’s temperature.

11

A few months ago, I got cubicSDR to running on FreeBSD. I have two pages of very complex hand written notes - some of which I no longer read, but I can get you started.

1). install xorg the x-windows stuff - “pks install xorg” (not sure about the case)

2). In the “modules” section of the x-windows configuration-
add (load “freetype”) (not sure about the exact form, copy the way the other entries were done)

3). In the “Files” section of the x-windows configuration-
add (Fontpath /usr/local/share/fonts/dejavu) (not sure about the exact form, copy the way the other entries were done)

The x-windows configuration files are (not sure about the case but you should find the file in the directory)
/etc/x11/XF86Config for Xfree86
/etc/x11/Xorg.conf for X.org

4). install cubic - “pks install cubicsdr”

5). Check Soapy - “pks info SoapySDR”

6). I then installed the hackrf package with “pkg install soapyhackrf”

7). I assume that the lime modules have a similar install.

The rest of what I did was working to get the audio to work and that would be different for you anyway. I could only run cubicSRD as superuser with the sequence -

sudo pulseaudio --start
sudo CubicSDR

I lost FreeBSD in a disk crash. I would have to rebuild everything to check the exact details.

12

Thank you for sharing your experiences with that particular program. I’m not yet at the point where I try to get graphical software running (except for the bits in the Lime Suite), but I’ll likely get to that point eventually, so any help and hints regarding FreeBSD and SDRs are appreciated.

The comilation errors of Lime Suite regarding the non-graphical components can be fixed by modifying the src/CMakeLists.txt file as follows:

  • add find_package(Threads) on top of the file
  • replace target_link_libraries(LimeSuite ${LIME_SUITE_LIBRARIES}) with target_link_libraries(LimeSuite ${LIME_SUITE_LIBRARIES} ${CMAKE_THREAD_LIBS_INIT})

No guarrantee that this is the cleanest way to fix the issue (I’m a newbie with cmake). Maybe the second step is a generalization of what’s attempted here, as FreeBSD also requries the -lpthread option but doesn’t use the GNU compiler usually:

if(CMAKE_COMPILER_IS_GNUCXX)
    list(APPEND LIME_SUITE_LIBRARIES -pthread)
endif(CMAKE_COMPILER_IS_GNUCXX)

Maybe this info is also helpful for the upcoming release of Lime Suite, as it would improve portability.

13

@Garmus, if you could review and consider, please.

14

Hello,

Regarding CMake changes, they will not make it into the coming release, maybe one after that.
Since one system can have multiple thread libraries, can you try to see if it still works when going by the CMake documentation? As in:

set(CMAKE_THREAD_PREFER_PTHREAD TRUE)
set(THREADS_PREFER_PTHREAD_FLAG TRUE)
find_package(Threads REQUIRED)
....
target_link_libraries(LimeSuite ${LIME_SUITE_LIBRARIES} Threads::Threads)
15

No problem, there are a couple of other things regarding FreeBSD anyway. I’d like to see them fixed in the long run, no time to rush or break other things by accident.

Applying your patch against LimeSuite-20.01.0 works and I can successfully compile the non-graphical components, at least.

There are still issues with the USB reset and non-root users, but that’s something I will discuss with the FreeBSD USB developers.

1 Like
16

Hey there :slight_smile:
As the LimeSuite release 22.09.0 is out the updated port is already out there ready for testing for some time :slight_smile:
Tomek SQ7MHZ

3 Likes