Search Results for 'api'

[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 3 weeks, 2 days 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, 3 weeks ago by Andrew.
• This reply was modified 4 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 4 months, 3 weeks 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.

[Roman]

Andrew, thank you for response!

– Is there an event that consistently leads to lost GPS lock?
– Yes, jamming.

– Does your GPS antenna have access to clear sky?
– Yes, sure.

– Is it possible one of the messages is configuring the device in an undesirable state?
– We haven’t got possibility to reproduce main problem with devices under jamming. But we can get simmilar behavior if we send coldboot command [ 0xB5, 0x62, 0x06, 0x04, 0x04, 0x00, 0xFF, 0xFF, 0x01, 0x00 ], 9th byte (0x01) repesents “Reset Type”
0x00 = Hardware reset (watchdog) immediately
0x01 = Controlled software reset
0x02 = Controlled software reset (GNSS only)

In case of 0x02(Controlled software reset (GNSS only)) it continue work(without jamming) but it doesn’t help for devices under jamming.

Unfortunately its bad news that we can’t get GPS info without lock status.

We wanna try to connect external GPS. Will it be possible to get proper timestamp in spectrum and IQ traces from external GPS?
Also will be possible to communicate with external GPS through sm_api?

[Roger]

Hi Gal,

There are potentially two ways to accomplish this in Python: using Spike’s SCPI interface or with the device API. The SDK contains the needed resources for both, and can be downloaded here.

1. SCPI

Spike can be programmatically controlled with SCPI commands. Presets can be loaded using the following commands, for named and quick presets respectively:

:SYSTem:PRESet[:USER]:LOAD
*RCL

Then, an acquisition command such as :TRACe[:DATA]? would be used to get the sweep data, which Python could then output to CSV.

An example to get you started is in the SDK at scpi/Spike/examples/python/scpi_simple_sweep.py. The Spike SCPI Programming Manual is also there as a command reference.

2. API

This is a direct connection to the device that is an alternative to Spike.

The configuration functions would be used to replicate the Spike preset, followed by an acquisition function to get the data, and then output CSV from Python.

An example to get you started is in the SDK at device_apis/sa_series/examples/python/sweep_plot.py. The API documentation is available there and online here.

Let me know if you have further questions.

Roger

Hello, I’m trying to automate a procedure we use the SA44B for.

Two steps of the procedure are loading user preset and exporting trace data to a *.csv file for further analysis.

I couldn’t find an option to it outside of Spike program. Is it possible to get the same functionality using Python with the existing API?
If not in Python, I can take an example in other language.

Thanks.

[Andrew]

Roman,

The API is setup to only return UBX messages when GPS is locked and outputting NMEA sentences. This is a result of how we package and return this data. For this reason, yes, you would need to see GPS lock before expecting messages.

Is there an event that consistently leads to lost GPS lock? Is it after sending a message? Does your GPS antenna have access to clear sky? I can’t say that I have seen a scenario or heard from a customer that a reboot of the device was required to attain GPS lock. Is it possible one of the messages is configuring the device in an undesirable state?

We only have experience sending the NAV5 message for changing the platform model. That code example is in our SDK (you probably already found it). I have not used the cold boot command. If it forces the GPS to do a cold boot, this will take many minutes or longer to get GPS lock again, I’m assuming you are waiting an appropriate amount of time?

[Justin Crooks]

Jay,
Our Audio Demod tool in Spike would be able to give you the exact frequency of the audio pilot tone, but unfortunately it clamps to 20 kHz. In normal swept mode your accuracy will be limited to your RBW. Marker peak, delta, next peak would give you the audio frequency +/- your RBW. An RBW of 1 Hz would give you a 1 Hz accuracy. If this is not accurate enough, the next step would be to either put in a request for us to increase the maximum audio frequency in the Audio Demod mode, or use the API and do the FM demod yourself.
The peak deviation can be viewed in zero span mode FM, as you did. Measuring a local max, then a local min, with markers, should give you a peak-to-peak deviation.

• This reply was modified 6 months, 3 weeks ago by Justin Crooks.