Search Results for 'api'

[Andrew]

PK,

The API would be the recommended way to automate with the VSG25. The VSG25 software and device does not support SCPI. SCPI automation is only supported on the VSG60 software.

The VSG25 API exposes most of the functionality of the user interface. It can be found in our SDK, linked below. See the user manual for programming examples.

https://signalhound.com/software/signal-hound-software-development-kit-sdk/

Let us know if you have follow up questions.

[PK]

Hello,

I am working with the Signal Hound VSG25A signal generator and using the VSG25 software. I would like to know if it is possible to control the device using SCPI commands directly, without going through the VSG25 software interface.

Specifically, I want to:

1) Send SCPI commands (e.g., set frequency, set power level, enable/disable output, burst mode, or frequency hopping).

2) Understand whether the VSG25A hardware has a built-in SCPI interface (USB or TCP/IP), or if control is only available through the provided API/SDK.

3) If SCPI is not supported directly, what is the recommended method for automation? (For example, should I use the API instead, or is there a way to use SCPI through the VSG25 software as a communication layer?)

Any guidance, example commands, or documentation links would be greatly appreciated.

Thank you!

[Andrew]

No it does not.

We have now released ARMv8 API builds for the BB60, SP145, and SM200/435 devices. This is API only, no Spike. The README in the documentation mentions the platform and compiler used for each build. None of the builds will support Windows+ARM.

[Andrew]

RSartell,

Porting Spike is definitely something we have talked about, but there isn’t a timeline for this right now. The work done on the APIs would benefit a Spike port.

From your previous post, it seems Windows on ARM is your target platform? As you’ve noticed, all my ARM compiles are for Linux or Mac. If we ported Spike, Linux would likely be the first target OS.

Andrew

[Andrew]

After long delay, we are happy to announce the availability of ARM (AArch64) support for the BB60 API. The API was compiled on the Nvidia Jetson AGX Orin platform. It’s expected to work on many ARMv8 Linux based systems.

Library files and README can be found in the SDK.

https://signalhound.com/software/signal-hound-software-development-kit-sdk/

[Andrew]

Our MATLAB examples are convenience classes that wrap and call the functions in the DLL. You can see everywhere we call a DLL function, the “calllib” function is used. It’s all just standard MATLAB code. As to which functions to call in the DLL, you would want to reference the VSG60 API (link below). What I recommend, is looking at the C++ examples in the SDK, creating your own example, then porting that to MATLAB. Writing your initial example in C++ is even better as you can prove functionality before the port.

https://signalhound.com/sigdownloads/SDK/online_docs/vsg60_api/index.html

Is there any documentation or guides on how to modify the VSG60 class? I am trying to utilize the external trigger on a VSG60A, but I am having trouble in MATLAB as the VSG60 class doesn’t expose the trigger like the .py API does. Or are there alternatives to generate a trigger that I have simply missed?

[mmark]

After a period of testing, I found that when receiving high-frequency signals via the API and performing FFT with window normalization, the measured power is correct. However, when receiving signals below 120 MHz, the power decreases as the frequency decreases, behaving like a high-pass filter.

We are using the SM200B IQ segment mode with the following settings: center frequency = 100 MHz, time_duration = 15.36e-3, ref_level = -10, trigger_type = “immediate”, and ext_trig_timeout = 1. Could it be that these parameter settings cause the received signal go through high pass filter(the preselector in user manual 3.2.4)? If so, is there a way to solve this problem?

p.s. I also tried to use smSetPreselector() and set False to it, but still didn’t work

[Andrew]

mmark,

There are a couple scaling factors you might need to consider when FFT’ing the I/Q data from our API.

– If you are requesting 16-bit I/Q data from our API, and you want to measure dBm, then you will need to get the I/Q correction and apply it via the equations in our API manual. If you are requested 32-bit floating point data (recommended), then the data is already scaled.

– The FFT itself. I would recommend scaling the Fwd FFT by N. What additional scaling you need to apply is dependent on which FFT library you are using. Some use scaling by default, some dont.

– If you are using a window function, you want to normalize the window before windowing the data.

– Once you have the above resolved, the output of the FFT can be converted to dBm using the equation

10*log10(I^2 + Q^2)

• This reply was modified 4 weeks, 1 day ago by Andrew.

When using SM200B, I tried to receive signals below 100 MHz transmitted from a signal generator through the API, and verified the received power with Spike. Then use FFT to calculate signal power.
I found that the signal power received via the API was much weaker than the transmitted signal, while Spike showed the signal power as normal. However, when I transmitted higher-frequency signals,like 500MHz、1GHz, both the API and Spike reported the received signal power correctly.
I also tried smgetIQcorrection() function but it didn’t work, so is there any solution for me to deal with this problem?

I am looking to utilize two separate c++ scripts to collect and save iq streaming data from an SM200C. The first script sets up the SM200C by opening the networked device and setting the iq stream parameters (data type, center frequency, ref level, etc), returning the handle to the opened device and leaving it idle. The second script uses the handle to initiate the capture for a specified length of time and save the data. The goal is to allow a user to begin a capture as soon as the second script is called so time isn’t wasted on setup, avoiding data loss. My initial tests indicate that the device doesn’t save the parameters from the first script; I’m forced to open the device again and send the same iq setup commands before a successful data capture can occur, causing significant delay and data loss in the process. Is a two-script setup possible? Or do I have to include setup and capture in the same script?

[Andrew]

Hi Jequin,

We have not yet built a LabView wrapper project for the SP145 API. It should be possible. One approach I could suggest now is to look at the SM LabView project and adapt it to the SP API. This may be difficult if you don’t have experience calling DLLs from LabView.

I don’t have a timeline on when we would have usable examples for the SP145 at this point.

If you attempt to build your own, and have any questions, please contact us at support@signalhound.com.

Thanks

[Andrew]

I’m using this thread as the general update thread on our ARM progress since it has the most visibility and comments on our forum. We are very much interested in supporting the ARM architecture and have been slowly adding support since our last update.

In our SDK we now have API builds for both the SP145 and SM200/435 for both the Nvidia Jetson Orin AGX and MacOS (M4 CPU). These APIs support a subset of functionality, namely sweeps and I/Q streaming with decimations up to 4, which hopefully covers most use cases. 10GbE support for our SM devices is also not supported on the Mac build, just the USB variants for now.

We are continuing to develop capability on ARM to support a larger subset of our APIs and new APIs altogether, (I.E. the BB60 API).

We appreciate everyone’s feedback and patience.

• This reply was modified 4 months, 4 weeks ago by Andrew.
• This reply was modified 4 months, 4 weeks ago by Andrew.

[joeqsmith]

Are you trying to use a 32-bit API with a 64-bit version of Labview?

I just tried it with LV64-bit 2020. Similar errors you show. Followed their instructions and seems fine.

2.2.3.2 Windows with 64-bit Labview
C:\Program Files\National Instruments\LabVIEW 2016\instr.lib
In the Signal Hound driver folder, you will need to rename the 64-bit DLL and either delete or rename the 32-bit DLL.
For example, for the BB series, rename bb_api.dll to bb_api-32.dll, and rename bb_api-64.dll to bb_api.dll.

• This reply was modified 5 months ago by joeqsmith.

Hi everyone,

We’re trying to interface the BB60 with LabVIEW, but we’re facing an issue where the api.dll file is not executing properly. We’ve successfully interfaced the VSG60 using the provided libraries and had no issues there. However, with the BB60, LabVIEW throws a DLL error related to api.dll.

I’ve attached a screenshot of the error for reference.
Has anyone else run into this issue or know how to fix it?

Any help or suggestions would be greatly appreciated!

Thanks in advance.

Attachments:

You must be logged in to view attached files.

[Andrew]

Yes, our SM API will support interfacing 2 SM200Cs simultaneously. I would recommend using the API and C++ for initial testing and proof of concept work. MATLAB adds significant overhead for streaming I/Q especially at high data rates. Our MATLAB examples only interface 1 device so it will need to be extended to support multiple devices. Starting with C++ will also help you understand how you will need to extend the MATLAB examples.

We would also generally recommend Linux over Windows if you are going to run multiple devices at the highest sample rate (200MS/s).

Hello-

I am trying to build gr-bb60 but get the following errors during cmake:

CMake Error at CMakeLists.txt:9 (find_package):
Could not find a package configuration file provided by “SoapySDR”
(requested version 0.4.0) with any of the following names:

SoapySDRConfig.cmake
soapysdr-config.cmake

Add the installation prefix of “SoapySDR” to CMAKE_PREFIX_PATH or set
“SoapySDR_DIR” to a directory containing one of the above files. If
“SoapySDR” provides a separate development package or SDK, be sure it has
been installed.

____________________________________________

Output of #SoapySDRUtil -info:
######################################################
## Soapy SDR — the SDR abstraction library ##
######################################################

Lib Version: v0.8.1-4build1
API Version: v0.8.0
ABI Version: v0.8
Install root: /usr
Search path: /usr/lib/x86_64-linux-gnu/SoapySDR/modules0.8
Search path: /usr/local/lib/x86_64-linux-gnu/SoapySDR/modules0.8 (missing)
Search path: /usr/local/lib/SoapySDR/modules0.8 (missing)
Module found: /usr/lib/x86_64-linux-gnu/SoapySDR/modules0.8/libHackRFSupport.so (0.3.4)
Module found: /usr/lib/x86_64-linux-gnu/SoapySDR/modules0.8/libLMS7Support.so (23.11.0)
Module found: /usr/lib/x86_64-linux-gnu/SoapySDR/modules0.8/libRedPitaya.so (0.1.1)
Module found: /usr/lib/x86_64-linux-gnu/SoapySDR/modules0.8/libairspySupport.so (0.2.0)
Module found: /usr/lib/x86_64-linux-gnu/SoapySDR/modules0.8/libaudioSupport.so (0.1.1)
Module found: /usr/lib/x86_64-linux-gnu/SoapySDR/modules0.8/libbladeRFSupport.so (0.4.1)
Module found: /usr/lib/x86_64-linux-gnu/SoapySDR/modules0.8/libmiriSupport.so (0.2.5)
Module found: /usr/lib/x86_64-linux-gnu/SoapySDR/modules0.8/libosmosdrSupport.so (0.2.5)
Module found: /usr/lib/x86_64-linux-gnu/SoapySDR/modules0.8/libremoteSupport.so (0.5.2)
Module found: /usr/lib/x86_64-linux-gnu/SoapySDR/modules0.8/librfspaceSupport.so (0.2.5)
Module found: /usr/lib/x86_64-linux-gnu/SoapySDR/modules0.8/librtlsdrSupport.so (0.3.3)
Module found: /usr/lib/x86_64-linux-gnu/SoapySDR/modules0.8/libuhdSupport.so (0.4.1)
Available factories… airspy, audio, bladerf, hackrf, lime, miri, osmosdr, redpitaya, remote, rfspace, rtlsdr, uhd
Available converters…
– CF32 -> [CF32, CS16, CS8, CU16, CU8]
– CS16 -> [CF32, CS16, CS8, CU16, CU8]
– CS32 -> [CS32]
– CS8 -> [CF32, CS16, CS8, CU16, CU8]
– CU16 -> [CF32, CS16, CS8]
– CU8 -> [CF32, CS16, CS8]
– F32 -> [F32, S16, S8, U16, U8]
– S16 -> [F32, S16, S8, U16, U8]
– S32 -> [S32]
– S8 -> [F32, S16, S8, U16, U8]
– U16 -> [F32, S16, S8]
– U8 -> [F32, S16, S8]

______________________________________________

Debug on cmake:
CMake Debug Log at CMakeLists.txt:9 (find_package):
The internally managed CMAKE_FIND_PACKAGE_REDIRECTS_DIR.

/home/came454/Downloads/soapy-bb60/SoapyBB60C/build/CMakeFiles/pkgRedirects

<PackageName>_ROOT CMake variable [CMAKE_FIND_USE_PACKAGE_ROOT_PATH].

none

CMAKE_PREFIX_PATH variable [CMAKE_FIND_USE_CMAKE_PATH].

none

CMAKE_FRAMEWORK_PATH and CMAKE_APPBUNDLE_PATH variables
[CMAKE_FIND_USE_CMAKE_PATH].

none

Env variable SoapySDR_DIR [CMAKE_FIND_USE_CMAKE_ENVIRONMENT_PATH].

none

CMAKE_PREFIX_PATH env variable [CMAKE_FIND_USE_CMAKE_ENVIRONMENT_PATH].

none

CMAKE_FRAMEWORK_PATH and CMAKE_APPBUNDLE_PATH env variables
[CMAKE_FIND_USE_CMAKE_ENVIRONMENT_PATH].

none

Paths specified by the find_package HINTS option.

none

Standard system environment variables
[CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH].

/usr/local
/usr
/
/usr/games
/usr/local/games
/snap

CMake User Package Registry [CMAKE_FIND_USE_PACKAGE_REGISTRY].

none

CMake variables defined in the Platform file
[CMAKE_FIND_USE_CMAKE_SYSTEM_PATH].

/usr/X11R6
/usr/pkg
/opt

CMake System Package Registry
[CMAKE_FIND_PACKAGE_NO_SYSTEM_PACKAGE_REGISTRY].

none

Paths specified by the find_package PATHS option.

none

find_package considered the following locations for SoapySDR’s Config
module:

/home/came454/Downloads/soapy-bb60/SoapyBB60C/build/CMakeFiles/pkgRedirects/SoapySDRConfig.cmake
/home/came454/Downloads/soapy-bb60/SoapyBB60C/build/CMakeFiles/pkgRedirects/soapysdr-config.cmake
/usr/local/SoapySDRConfig.cmake
/usr/local/soapysdr-config.cmake
/usr/SoapySDRConfig.cmake
/usr/soapysdr-config.cmake
/usr/lib/x86_64-linux-gnu/SoapySDR/SoapySDRConfig.cmake
/usr/lib/x86_64-linux-gnu/SoapySDR/soapysdr-config.cmake
/SoapySDRConfig.cmake
/soapysdr-config.cmake
/lib/x86_64-linux-gnu/SoapySDR/SoapySDRConfig.cmake
/lib/x86_64-linux-gnu/SoapySDR/soapysdr-config.cmake
/usr/games/SoapySDRConfig.cmake
/usr/games/soapysdr-config.cmake
/usr/local/games/SoapySDRConfig.cmake
/usr/local/games/soapysdr-config.cmake
/snap/SoapySDRConfig.cmake
/snap/soapysdr-config.cmake
/opt/SoapySDRConfig.cmake
/opt/soapysdr-config.cmake

The file was not found.

Lastly, lsusb -t shows the bb60 attached but no driver associated. I followed the ftdi driver install instructions with success, I believe.

System is Ubuntu 24.04.

Thanks.

Hi,

I am trying to better understand the fast sweep mode on the SM435C device (using the SDK).

My understanding is that in this mode, the device captures a single frame (max. 16384 samples) at each LO step, computes the windowed FFT, and stitches the results from each step. Since the internal sampling rate is 250MSPS, but the actual signal bandwidth is 160MHz (probably lower if the optional preselector is used under 645MHz), only 16/25 * N_FFT bins are used/valid.

Based on my experiments, the device has 6 discrete N_FFT options (power-of-two, 512 – 16384). Thus, the FFT bin frequency widths are also just a few discrete options (i.e. 250 MHz/ N_FFT). The RBW is calculated by multiplying these with the selected window’s noise bandwidth (thus, given a specific window, we also have 6 discrete truly different RBW options).

My questions:
– Is the detector setting relevant in this mode (I assume not, if a single FFT frame is created at each LO step)?
– When I configure the device with different RBWs (smSetSweepCoupling), and I query the actual results (smGetSweepParameters), it seems that many more RBWs can be set/used (the actual RBW is close to an arbitrary requested value). But, the sweep size only changes according to the discrete options I described above. Is there something I completely misunderstand in this mode?

Thank you!
(BTW, I am new to this, but I enjoy the easy-to-use device and very accessible API. Kudos for making the software and documentation publicly accessible).

[Andrew]

The concept of a preset does not exist in the API, that is only in the Spike software.

Also, you are correct, the API provides just the sweep and I/Q data from the instrument. Any measurements on the data need to be performed in your application.

As Roger noted, the SCPI commands support both loading presets and exporting trace data.

Let us know if you have follow up questions.

[galc]

Thanks Roger.
I am still not sure how to create a function which will load user preset (i.e. ini file) as it is done using Spike.

Looking in the ini file content I find a lot of parameters which seem to be not configurable using the API. Say for example configuring the trace type parameter or the average count. Same goes for markers.

I find that the API doesn’t cover a lot of the functionality that Spike features.

I did understand that saving samples to a *.csv can be done using the saGetSweep_32f and saGetSweep_64f functions.

Will appreciate help regarding the issue.