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
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.
Mike
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:
2 Likes
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 measureVNA.py 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.
Mike
Hi Mike,
Can you post the output from LimeUtil --find.
Also pinged the engineering team to see if they have any suggestions.
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. 
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:
- cyLimeLib Python module was not installed. This can be fixed by:
cd cyLimeLib/win
python setup.py install- 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 LMS7002_REGDESC_MR3.py 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 setup.py and get the following errors…
Here it is from notepad. (a bit more readable)
C:\Users\N1JEZ\Desktop\pyLMS7002M\cyLimeLib\win>python setup.py 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
cyLimeLib.cpp
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
cyLimeLib.obj
: 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)
cyLimeLib.obj
: 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)
cyLimeLib.obj
: 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)
cyLimeLib.obj
: 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)
cyLimeLib.obj
: 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
C:\Users\N1JEZ\Desktop\pyLMS7002M\cyLimeLib\win>
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…
Mike
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
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
Mike
Has anyone managed to get measureVNA.py 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.
@M0GLO
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 LMS7002_SX.py:
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 measureVNA.py:
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()
lms7002.verbose=0
lms7002.SX['T'].setFREQ(f)
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:
1 Like
My LimeSDR is somewhere between the US and me… I will hack on this some when it arrives.
2 Likes
@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!