Search Results for 'api'

Hello, our company is currently considering acquiring a VNA400 unit.
We would like to use it with automatic calibration modules even if third party modules.
Do you have this integration planed in the near future even if it is only posssible by the api.
Alternativly will you produce your own calibration modules or even partner with other company for the process.
Best Regards, Pedro.

[Justin Crooks]

Garth,
Yes, if you wanted to do this programatically, you could use the sa_api and tg_api. Do 2 sweeps, one with your reference through, and one with your DUT. For each point within the sweep, tune the TG then do a small (100 kHz span or smaller) sweep around the signal and find the max value. Subtract the 2 sweeps for your insertion loss. We created a support ticket for this issue, but I don’t know where it is in the queue, so a “DIY” TG sweep might be a good solution in the short run.

• This reply was modified 1 week, 3 days ago by Justin Crooks.

[Andrew]

The API does not have a equivalent command for reference level offset (RLO). The logic for RLO is done entirely in Spike. Fortunately it is simply offsetting the reference level you set through the API. For example, a RLO of 20dB (implying something like a 20dB attenuator in line) would mean setting the reference level in the API 20dB lower.

• This reply was modified 3 weeks ago by Andrew.

[jfer]

Just a quick update on this, I was just able to get the sm_example_open_networked_device C++ example to work with my network configuration, so it’s only the Python API I am currently having trouble with

Hi

I am using the BB60C in a remote Python application.

Does anyone know the remote command/API command to set the external reference level offset?

The Spike SW does have an input field for the reference level offset!

I am running on latest SW from the web-page.

Thanks in advance
LPE

Hello,

I have the SM200C using a Sonnet Solo10G SFP+ (Thunderbolt 3 Edition) going into an Intel NUC running Ubuntu 22. After going through the 10GbE Network Configuration Guide I was able to get Spike to connect to the device and even change the device network configuration through the Spike SM Network Configuration utility. However I have been unable to connect to the device through the Python API, including the networked_speed_test.py example. It just returns that no device is found. Any advice for this?

Thanks!

[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 1 month, 3 weeks 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 5 months, 3 weeks ago by Andrew.
• This reply was modified 5 months, 3 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, 3 weeks ago by joeqsmith.