[documentation] How to install python support for SoapySDR ?

[eabase]

From this page you say that Lime

Installing Lime Suite enables many SDR applications to be used with supported hardware, through both the native APIs and provided plug-ins, such as for SoapySDR and GNU Radio.
...
The Lime Suite codebase has grown over the years to incorporate many improvements and become the foundation for various SDR boards and modules that utilise Lime chipsets. The software collection has also grown to include numerous examples, utilities — such as for testing and programming firmware/gateware — and plug-ins for applications such as the SoapySDR framework and GNU Octave.

However, this is unclear and I don't see any support after compile.

How can I get a SoapySDR - or Python compatible Python API with this device?
Or is it PothosSDR?

• https://github.com/pothosware/SoapySDR
• https://github.com/pothosware/SoapySDR/wiki/BuildGuide

When running install (Windows powershell), I get this:

# cmake -B mybuild

-- Building for: Visual Studio 17 2022
CMake Deprecation Warning at CMakeLists.txt:4 (cmake_minimum_required):
  Compatibility with CMake < 3.5 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.


-- Selecting Windows SDK version 10.0.22621.0 to target Windows 10.0.26100.
-- The C compiler identification is MSVC 19.42.34435.0
-- The CXX compiler identification is MSVC 19.42.34435.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.42.34433/bin/Hostx64/x64/cl.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files/Microsoft Visual Studio/2022/Community/VC/Tools/MSVC/14.42.34433/bin/Hostx64/x64/cl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Build type not specified: defaulting to release.
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
--
-- #############################################
-- ## Begin configuration for C# support...
-- #############################################
-- Enabling optional C# bindings if possible...
-- Looking for a CSharp compiler
-- Looking for a CSharp compiler - C:/Program Files/Microsoft Visual Studio/2022/Community/MSBuild/Current/Bin/Roslyn/csc.exe
-- Could NOT find SWIG (missing: SWIG_EXECUTABLE SWIG_DIR)
-- SWIG_FOUND: FALSE -
CMake Deprecation Warning at swig/python/CMakeLists.txt:4 (cmake_minimum_required):
  Compatibility with CMake < 3.5 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.



-- Could NOT find SWIG (missing: SWIG_EXECUTABLE SWIG_DIR)
-- SWIG_FOUND: FALSE -
-- Performing Test SIZE_T_IS_UNSIGNED_INT
-- Performing Test SIZE_T_IS_UNSIGNED_INT - Failed
--
-- #############################################
-- ## Begin configuration for Python 2 support...
-- #############################################
-- Enabling optional Python 2 bindings if possible...
-- Could NOT find Python2 (missing: Python2_EXECUTABLE Python2_LIBRARIES Python2_INCLUDE_DIRS Interpreter Development)
--
-- #############################################
-- ## Begin configuration for Python 3 support...
-- #############################################
-- Enabling optional Python 3 bindings if possible...
-- Found Python3: C:/lang/Python312/python.exe (found version "3.12.9") found components: Interpreter Development
--  * Interpreter: C:/lang/Python312/python.exe (Python)
--  * Include: C:/lang/Python312/include
--  * Library: C:/lang/Python312/libs/python312.lib
--
-- #############################################
-- ## Begin configuration for LuaJIT support...
-- #############################################
-- Enabling optional LuaJIT bindings if possible...
CMake Deprecation Warning at luajit/CMakeLists.txt:4 (cmake_minimum_required):
  Compatibility with CMake < 3.5 will be removed from a future version of
  CMake.


  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.


-- Could NOT find LuaJIT (missing: LUAJIT_INTERPRETER)
--
-- ######################################################
-- ## SoapySDR enabled features
-- ######################################################
--
 * Library, runtime library v0.8.1-g309335ec
 * Apps, command line applications
 * Tests, library unit tests

-- ######################################################
-- ## SoapySDR disabled features
-- ######################################################
--
 * Docs, doxygen documentation
 * CSharp, C# bindings v4.7.2                                    <----- WHY IS THIS DISABLED?
 * Python2, Python2 bindings v
 * Python3, Python3 bindings v3.12.9                             <----- WHY IS THIS DISABLED?
 * LuaJIT, LuaJIT bindings

-- SoapySDR version: v0.8.1-g309335ec
-- ABI/so version: v0.8-3
-- Install prefix: C:/Program Files (x86)/SoapySDR               <----- WRONG Location for x64
-- Configuring done (12.7s)
-- Generating done (0.2s)
-- Build files have been written to: C:/xxx/xxx/SoapySDR/mybuild

Also, all those CMAKE deprecation warnings are very annoying.
What is the fix for those?

[eabase]

BUMP!

I managed to install suite after fixing a bunch of bugs, and adding a bunch of undocumented dependencies, but I don't know if it really runs, because I am not able to install the python packages.

The GUI and config .exe's work, but the rest? NFI!

I would appreciate if the Lime team could provide a pre-built working Windows package so at least we can have something to look at and compare with. There is no python packages or installer files, so how the heck is anyone supposed to be able to use this?

How do you install the (Windows) python packages?

• Where are they, and what are they?
• Dependencies?

I want to see one running (Native Windows python) PoC code example on Windows. IDK if that is too much to ask?

[rjonaitis]

Hi, LimeSuiteNG project does not provide python bindings directly, it only produces C++ dynamic libraries, which can be loaded as plugins in other software.
If you want to use it with python, then you would need to do that through SoapySDR or GNURadio provided python bindings.

The log you posted is from SoapySDR project source build, it is not part of LimeSuiteNG, so I cannot really help with it. SoapySDR project utilizes SWIG to generate python bindings, in your case it's not found on your system Could NOT find SWIG (missing: SWIG_EXECUTABLE SWIG_DIR) thus bindings generation becomes disabled.

The LimeSuiteNG itself only needs the SoapySDR's c++ headers/core library to build a plugin for it, the produced c++ shared library then should be installed into the SoapySDR plugins directory. Then SoapySDR would be able to locate the plugin, and you could use it through SoapySDR's python API.

[eabase]

Hi Ricardas,

Thank you for getting back to me. 👍
Yes, I managed to compile both, but the instructions are very confusing...

After having installed both Swig, Doxygen and fixed some bugs in your files causing compile errors.

While LimeSuiteNG require you to already have a working SoapySDR, you are now saying that I need to compile LimeSuiteNG first, and then SoapySDR after?

I opened ticket also on their repo...

---

Also, what happened to LimeUtils used to update the firmware?
(How do I do that?)

[eabase]

The following 2 files need to be modified:

src/FPGA/FPGA_common.cpp
src/chips/LMS7002M/MCU_BD.cpp

The git diff:

diff --git a/src/FPGA/FPGA_common.cpp b/src/FPGA/FPGA_common.cpp
index 6dbc2d4b..28578136 100644
--- a/src/FPGA/FPGA_common.cpp
+++ b/src/FPGA/FPGA_common.cpp
@@ -11,6 +11,7 @@
 #include <cmath>
 #include <thread>
 #include <vector>
+#include <chrono>

 using namespace std;
 using namespace std::literals::string_literals;
diff --git a/src/chips/LMS7002M/MCU_BD.cpp b/src/chips/LMS7002M/MCU_BD.cpp
index fb2b1e36..48be0772 100644
--- a/src/chips/LMS7002M/MCU_BD.cpp
+++ b/src/chips/LMS7002M/MCU_BD.cpp
@@ -18,6 +18,7 @@ using namespace std;
 #include "comms/ISPI.h"
 #include <functional>
 #include <string_view>
+#include <chrono>

 using namespace lime;
 using namespace std::literals::string_literals;

Also the Windows install path is wrong as the build is for x64 and not x86, so it should go into: C:\Program Files\ and not C:\Program Files (x86)\. Unfortunately I could not find where this is first set, so you need to pass the full path (including project name) to install prefix with, otherwise it put all the files into the Program Files root!

You also wanna disable all the annoying deprecation warnings. IDK why nobody bothers to fix the files with the trivial cmake_minimum_required.

cmake -B build -Wno-dev -Wno-deprecated --install-prefix 'C:\Program Files\SoapySDR'

[eabase]

There is a also a weird link warning:

Creating library C:/xxxx/LimeSuiteNG/build/src/Release/limesuiteng.lib and object C:/xxxx/LimeSuiteNG/build/src/Release/limesuiteng.exp
LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library [C:\xxxx\LimeSuiteNG\build\src\limesuiteng.vcxproj]

[rjonaitis]

While LimeSuiteNG require you to already have a working SoapySDR, you are now saying that I need to compile LimeSuiteNG first, and then SoapySDR after?

No. First SoapySDR has to be already installed in the system, so that it could provide the necessary headers/libraries. Then building LimeSuiteNG project would detect it (Windows is terrible for dependencies search, so most likely need manually to set the root directory where to find SoapySDR), and use it to build a plugin. Then the installation process of LimeSuiteNG would copy that plugin into directory where SoapySDR is looking for dynamic libraries to load for usage (assuming the installed SoapySDR provides CMake config files, that specify where that directory is, otherwise it could be anywhere and the installation would have to be done manually).

Also, what happened to LimeUtils used to update the firmware? (How do I do that?)

It got replaced with limeFLASH utility. Currently it does not have the option to automatically update to latest firmware, because some devices now have multiple different firmwares available. So you need to manually specify which firmware file to use.

user@computer:~$ limeFLASH --target="FPGA/FLASH" flash_programming_file.bin

Also the Windows install path is wrong as the build is for x64 and not x86, so it should go into: C:\Program Files\ and not C:\Program Files (x86)\

CMake nuance with Visual Studio, the project generation is complicated (due to possibility of having multiple configurations/architectures), if you would explicitly specify the architecture for CMake when configuring, then the install path would be set appropriately cmake .. -A x64

You also wanna disable all the annoying deprecation warnings. IDK why nobody bothers to fix the files with the trivial cmake_minimum_required.

Most of them are comming from external source files, so there is no way to omit them without patching the files after they are downloaded, that would make things more complicated. Because CMake depending on it's version handles some thing differently (there are cmake-policies ), simply increasing the minimum required version, has the possibility to break the project.
Some old/embedded linux platforms may provide outdated cmake versions, that would still be enough to make the project, but if the cmake_minimum_required is needlessly set higher, then that cmake would refuse to configure it. Then you would have to first build yourself a recent version of CMake from source (on potentially slow cpu, or would need to setup a cross compilation environment for specific hardware...), or attempt to guess and reduce the project's minimum required cmake version, but then again you wouldn't be able to know what is the true required minimum version and can easily have broken project. So it's really just a matter of ammount of effort/consequences just to remove a warning message, basically consider it a case of "as long as it works, don't touch it".

There is a also a weird link warning:

Seems to be the USB FX3 precompiled library was built with different compiler settings.

[eabase]

Then building LimeSuiteNG project would detect it, and use it to build a plugin. Then the installation process of LimeSuiteNG would copy that plugin into directory where SoapySDR is looking for dynamic libraries to load for usage.

Still sound awfully complicated. I would like to automate this whole process...

It got replaced with limeFLASH utility. ... So you need to manually specify which firmware file to use.

Where can I find the FW files?
I have a LimeSDR USB v1.4s.

if you would explicitly specify the architecture for CMake

Yes, I'm looking into this. I realize that the CLI (pwsh) VS Dev shell need to be set to use x64 as it is set to x86 by default, which I don't know what I used when I did it.

Some old/embedded linux platforms may provide outdated cmake versions,

Sure, but we should not use "old/embedded linux platforms" for anything. It's a huge security risk and also extremely inefficient use of the cpu resources. Most linux embedded HW can also handle updates.

There is a also a weird link warning:

Seems to be the USB FX3 precompiled library was built with different compiler settings.

I was checking the Cypress website and downlaoded the latest FX3 SDK.
Seem there is new version, so what are you actually supplying here?

FX3 SDK : FX3SDKSetup_1.3.4.exe was updated to ezusbfx3sdk_1.3.5_Windows_x32-x64.exe

• https://www.cypress.com/
• https://softwaretools.infineon.com/tools/com.ifx.tb.tool.ezusbfx3sdk

[eabase]

Have filed the following issues at SoapySDR here:

• How to build & install SoapySDR on Windows? pothosware/SoapySDR#446
• [documentation] How to build and install python package in native Windows-11 x64? pothosware/SoapySDR#448

[9600]

Then building LimeSuiteNG project would detect it, and use it to build a plugin. Then the installation process of LimeSuiteNG would copy that plugin into directory where SoapySDR is looking for dynamic libraries to load for usage.

Still sound awfully complicated. I would like to automate this whole process...

This behaviour is not in any way unusual and is typical for such plug-ins.

Where can I find the FW files? I have a LimeSDR USB v1.4s.

Classic Lime Suite downloads them and they are firstly organised by Lime Suite release:

https://downloads.myriadrf.org/project/limesuite/23.11/

As you can see the last release was November 2023 and Lime Suite NG being much more recent should be fine used with the latest LimeSDR-USB gateware.

Some old/embedded linux platforms may provide outdated cmake versions,

Sure, but we should not use "old/embedded linux platforms" for anything. It's a huge security risk and also extremely inefficient use of the cpu resources. Most linux embedded HW can also handle updates.

In an ideal world perhaps, but in any case we have no plans to force such breakage.

[eabase]

Hi Andrew, @9600

limeFLASH --target="FPGA/FLASH" flash_programming_file.bin

There is no *.bin files in that link. They are called *.img and *.rbf... What are those?
How to use and flash.

[eabase]

@9600

Ok, that is not going to work, because there are no *.bin files I could find.
They need to be build by make from their parts.

I found the FW/GW files from your page here:

• https://wiki.myriadrf.org/LimeSDR-USB#USB3_MCU_and_FPGA_Binaries

Then the *.img and *.rbf files are found here:

• https://github.com/myriadrf/LimeSDR-USB_FX3/tree/master/Debug (USB3 MCU firmware)
• https://github.com/myriadrf/LimeSDR-USB_GW/blob/master/output_files/LimeSDR-USB_lms7_trx_HW_1.4.rbf (FPGA gateware)

I see that there have been some updates since I got my board back in 2019, so it would be great if you can actually provide the *.bin files for download, somewhere.

[rjonaitis]

Depending on the FPGA, the gateware file extensions differ, so it's not necessarily .bin, limeFLASH just writes the raw binary content of the file into the FLASH memory. For the LimeSDR-USB the FPGA gateware file is .rfb https://github.com/myriadrf/LimeSDR-USB_GW/tree/master/output_files
To update do limeFLASH --target="FPGA/FLASH" LimeSDR-USB_lms7_trx_HW_1.4.rbf

FX3 controller firmware update is not yet added to limeFLASH, but it shouldn't be necessary, as the FX3 firmware did not had any updates since 2017 https://github.com/myriadrf/LimeSDR-USB_FX3/commits/master/