Vector Network Analyzer


Did anyone try the VNA software, that is available on github? Seems buggy and a little under-documented
I’d love to use is, but all I get is somehow random output, yet I calibrated correctly with shorting the ‘DUT’ of the directional coupler

Using LimeSDR to test Low/High/Band pass/stop filters

In looking at the documentation for the VNA, it says that the current Windows Driver we’re using for all our other apps is not compatible with the pyLMS7002M python package used for the VNA. It wants one to replace the driver using ZaDig. Not something I want to do.

Will this package be updated to work with the Windows driver? I’d love to work with the VNA.



Just to note that the pyLMS7002M repo has been updated and it’s now possible to use this and associated examples, e.g. VNA, via the LimeAPI — meaning the default driver on Windows — in addition to directly.

See the documentation for further details:


Very Cool!!!


I’m trying to get the VNA package running under Win10 with the LimeAPI (not USB via ZaDig)

I’ve done a full install of the VNA package including MatPlotLib and pySmithPlot. From Python, running “from pyLMS7002M import *” returns no error.

The Error I get when I try and run “python test50” is this (back end issue)

I must have missed something in the install…

Cython is installed.
Microsoft Visual C++ compiler for Python 2.7 is installed
I installed Pothos previously and the LimeSDR is working with other apps like SDR Console. I assume this install has the LimeSuite Shared Libraries?

Any help appreciated.


Hi Mike,

Can you post the output from LimeUtil --find.

Also pinged the engineering team to see if they have any suggestions.


Hi Andrew,

Here’s the result - appears normal.

Tnx for the help.


The new driver didn’t work on Win7, installing it gave me a USB device named LimeSDR but LimeSuite was unable to see it and SDR Console said the device was invalid.


You shouldn’t have had to install a new driver. The update enables use with the stock LimeSDR driver.


Cool, then I should be good then as I replaced the new driver with the old one after the fail.
I’ll shut up now unless I have issues again. :slight_smile:


Hi Mike,

Just received the following advice:

The pyLMS7002M package first tries to find LimeAPI DLL and falls back to direct communication if the DLL is not found.
The error message suggests that the LimeAPI DLL was not found and that direct communication was attempted.

There are two potential reasons why LimeAPI DLL was not found:

  1. cyLimeLib Python module was not installed. This can be fixed by:
    cd cyLimeLib/win
    python install
  2. LimeSuite.dll and FTD3XX.dll are not in the search path. This can be fixed by either copying these DLLs to a directory which is in the search path, or adding the location of DLLs to the search path.

The problem which the Ubuntu user encountered is related to character encoding.
The file had long dashes which are encoded with \xe3, and caused the error.
We haven’t encountered this error on our computers, and we’ve tested it in Python 2.7 both on Ubuntu and Windows.
Maybe the user is using Python 3?
Anyway, the solution is to replace long dashes with -.
I’ve made this change and committed the file to GitHub.


Hi Andrew,

It looks like my issue is with cyLimeLib. I ran and get the following errors…

Here it is from notepad. (a bit more readable)

C:\Users\N1JEZ\Desktop\pyLMS7002M\cyLimeLib\win>python install
running install
running bdist_egg
running egg_info
writing cyLimeLib.egg-info\PKG-INFO
writing top-level names to cyLimeLib.egg-info\top_level.txt
writing dependency_links to cyLimeLib.egg-info\dependency_links.txt
reading manifest file ‘cyLimeLib.egg-info\SOURCES.txt’
writing manifest file ‘cyLimeLib.egg-info\SOURCES.txt’
installing library code to build\bdist.win32\egg
running install_lib
running build_ext
cythoning cyLimeLib.pyx to cyLimeLib.cpp
warning: cyLimeLib.pyx:33:23: local variable ‘_devStr’ referenced before assignment
warning: cyLimeLib.pyx:34:19: local variable ‘_devStr’ referenced before assignment
warning: cyLimeLib.pyx:35:47: local variable ‘_devStr’ referenced before assignment
building ‘cyLimeLib’ extension
creating build
creating build\temp.win32-2.7
creating build\temp.win32-2.7\Release
C:\Users\N1JEZ\AppData\Local\Programs\Common\Microsoft\Visual C++ for Python\9.0\VC\Bin\cl.exe /c /nologo /Ox /MD /W3 /GS- /DNDEBUG -Ic:\python27\include -Ic:\python27\PC /TpcyLimeLib.cpp /Fobuild\temp.win32-2.7\Release\cyLimeLib.obj -O2

creating build\lib.win32-2.7

C:\Users\N1JEZ\AppData\Local\Programs\Common\Microsoft\Visual C++ for Python\9.0\VC\Bin\link.exe /DLL /nologo /INCREMENTAL:NO /LIBPATH:c:\python27\libs /LIBPATH:c:\python27\PCbuild /LIBPATH:c:\python27\PC\VS9.0 LimeSuite.lib /EXPORT:initcyLimeLib build\temp.win32-2.7\Release\cyLimeLib.obj /OUT:build\lib.win32-2.7\cyLimeLib.pyd /IMPLIB:build\temp.win32-2.7\Release\cyLimeLib.lib /MANIFESTFILE:build\temp.win32-2.7\Release\cyLimeLib.pyd.manifest
Creating library build\temp.win32-2.7\Release\cyLimeLib.lib and object build\temp.win32-2.7\Release\cyLimeLib.exp

: error LNK2019: unresolved external symbol _LMS_Close referenced in function “void __cdecl pyx_pf_9cyLimeLib_9cyLimeLib_4__dealloc(struct __pyx_obj_9cyLimeLib_cyLimeLib *)” (?pyx_pf_9cyLimeLib_9cyLimeLib_4__dealloc@@YAXPAU__pyx_obj_9cyLimeLib_cyLimeLib@@@Z)

: error LNK2019: unresolved external symbol _LMS_GetDeviceList referenced in function “struct _object * __cdecl __pyx_pf_9cyLimeLib_9cyLimeLib_getDeviceList(void)” (?__pyx_pf_9cyLimeLib_9cyLimeLib_getDeviceList@@YAPAU_object@@XZ)

: error LNK2019: unresolved external symbol _LMS_Open referenced in function “int __cdecl pyx_pf_9cyLimeLib_9cyLimeLib_2__cinit(struct __pyx_obj_9cyLimeLib_cyLimeLib *,struct _object *)” (?pyx_pf_9cyLimeLib_9cyLimeLib_2__cinit@@YAHPAU__pyx_obj_9cyLimeLib_cyLimeLib@@PAU_object@@@Z)

: error LNK2019: unresolved external symbol _LMS_TransferLMS64C referenced in function “struct _object * __cdecl __pyx_pf_9cyLimeLib_9cyLimeLib_6transferLMS64C(struct __pyx_obj_9cyLimeLib_cyLimeLib *,struct _object *,struct _object *)” (?__pyx_pf_9cyLimeLib_9cyLimeLib_6transferLMS64C@@YAPAU_object@@PAU__pyx_obj_9cyLimeLib_cyLimeLib@@PAU1@1@Z)

: error LNK2019: unresolved external symbol _LMS_UploadWFM referenced in function “struct _object * __cdecl __pyx_pf_9cyLimeLib_9cyLimeLib_8UploadWFM(struct __pyx_obj_9cyLimeLib_cyLimeLib *,struct _object *)” (?__pyx_pf_9cyLimeLib_9cyLimeLib_8UploadWFM@@YAPAU_object@@PAU__pyx_obj_9cyLimeLib_cyLimeLib@@PAU1@@Z)
build\lib.win32-2.7\cyLimeLib.pyd : fatal error LNK1120: 5 unresolved externals

error: command ‘C:\Users\N1JEZ\AppData\Local\Programs\Common\Microsoft\Visual C++ for Python\9.0\VC\Bin\link.exe’ failed with exit status 1120


FTD3XX.dll and LimeSuite.dll are definitely in my search path as from the cyLimeLib\win directory I can run LimesuiteGUI which is in the same directory.

Not sure where to go from here…



Hi Mike,

Seems like the issue is related to building for 32-bit:

For some reason Visual Studio linker adds underscore to the symbol name in 32 bit Windows, while in 64 bit versions it does not.

cyLimeLib distribution contains LimeSuite.lib for 64 bit Windows, so the 32 bit linker cannot use it.
The simplest solution would be to use 64 bit Visual Studio running vcvars64.bat instead of vcvars32.bat

TDD with SoapyLMS7

I understand the concept…

Sorry to be so dense, but I’m not sure how to actually get the linker to use 64 bit.

I see the .bat files



Has anyone managed to get to accept a start and end freq in the 1MHz to 150MHz range?
It errors for me saying it has to be between 240MHz and 3.8GHz.


Is this the error you’re seeing?

“Not Valid LO Frequency. 240 MHz< F_LO < 3.8 GHz”

It seems that this comes from this method ln

 def setFREQ(self, F_LO, IntN_MODE=False, SPDUP_CTUNE=False, PD_TLOBUF_CTUNE=False):                                                                                
     Calculates FF-DIV Modulus. Calls VCO Corse Tuning Method. Configures PLL in LMS7002.                                                                           
     F_REF = self.chip.fRef   # get the chip reference frequency                                                                                                    
     if not (0.24e9<=F_LO<=3.8e9):                                                                                                                                  
          raise ValueError("Not Valid LO Frequency. 240 MHz< F_LO < 3.8 GHz")                           

Which in turn is called by

startFreq = 2.30e9                                                                                                                                                      
endFreq = 2.6e9                                                                                                                                                         
nPoints = 101                                                                                                                                                           
measName = sys.argv[1]   
freqs = numpy.linspace(startFreq, endFreq, num=nPoints)                                                                                                                 

res = []                                                                                                                                                                
resPhase = []                                                                                                                                                           
pgaGains = []                                                                                                                                                           
lnaGains = []                                                                                                                                                           
for i in range(0, len(freqs)):                                                                                                                                          
    # Measure reference power levels and phase                                                                                                                          

    f = freqs[i]                                                                                                                                                        
    logTxt("f="+str(f)+"... ", end="")                                                                                                                                  
    startTime = timer()                                                                                                                                                 

It seems that there might be a minunderstanding in what setFREQ() does. It seems that is sets the LO frequuency, which then can be multiplied/divided to get other frequencies.

Have a look at the code and see if you agree with my estimation… to be honest I didn’t spend long looking at it, but that’s how it seems to work.

Long story short, if you want the VNA exmaple to work over a wider frequency range, a bit of hackage might be in order.

Or, maybe just changing the check in setFREQ() to this:

if not (1e6<=F_LO<=3.8e9):


That’s the one I keep getting.
I was kind of afraid that I might need to hack the multiplier calls into the script.
Hi ho hi ho off to the API docs I go…


If you have nothing better for doing, the SI5351 library from Jason NT7S handles LO/multiplier calculation very nicely:


My LimeSDR is somewhere between the US and me… I will hack on this some when it arrives.


@andrewback … I want to explore the use of pyLMS7002M on Windows 10, but don’t understand what the LimeAPI is. I have looked for definitions/files on GitHub etc. but it still eludes me!

Please could you explain what LimeAPI is and where I can find it or use it? Thanks!