Search Results for 'api'

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

[pooja.sagathiya]

Hi,
I am using a BB60C and its working well with the Spike SW. But when using the LabVIEW examples, I keep getting the “Device not open” error when running the vi. I re-loaded the bb_api-64.dll driver from the LabVIEW drivers download (and deleted the -64 text) and restarted by PC and got the vi to work once.Any help is appreciated. Thanks!!

[Andrew]

Hello rlisboa,

There is no current timeline on availability for this. You can follow updates here, https://signalhound.com/support/forums/topic/bb60c-api-for-arm/

I will be sure to update the linked thread when we do have something to share.

Currently the only ARM support we have is for the SP145 API, compiled on the NVidia Jetson (Orin AGX) platform.

Regards

When will there be API ARM support for the BB60?

[Andrew]

We have made one small step in this direction yesterday with the release of the SP145 API for the Nvidia Jetson AGX Orin platform. This is a highly requested pairing. It supports sweeps and I/Q streaming with some minor limitations. Hopefully some of you here or future visitors looking for ARM platform support can benefit from these efforts.

If you have any follow up questions or issues with the API, please reach out to me at aj@signalhound.com.

All of these files are now located in our SDK.

Thanks

[Andrew]

Hello,

This scenario is also unfortunately not something you are going to be able to make work with the capabilities of the BB60s. The video trigger is a function of software running on the PC, so it’s fully post acquisition and USB transfer. Any sort of trigger mechanism using the video trigger detection would have very poor resolution.

Additionally the BB60s are not really a good choice for generating a pulse. One of the ports can be configured as a logic high or low, but the resolution on this is very poor.

There might be an alternative way to accomplish this. If you have an external trigger source, such as a GPS PPS signal, that you could route that to both BB60s, the API will mark the position in I/Q stream where the external triggers occur and you could measure them relative to the video triggers you detect. A rather elaborate setup and some code to tie it together, but that should give you something like 40ns of resolution on the timing differences between 2 BB60s.

Our other devices, the SM and SP analyzers, have an internal GPS, which with a GPS antenna could be used to timestamp the data, which would also give you a relative timing between the 2 analyzers of ~40ns, essentially trading the need for an external trigger source with an external GPS antenna for each receiver. The timestamping is all done automatically, so the final code might be slightly simpler.

Let us know if you have follow up questions.

[RGedminas]

Justin,
Thank you for the response. I am once again trying to accomplish a similar task. I would like to have my bb60c and bb60d both in zero span with a video trigger setup in software. From there I would like each device to output a trigger pulse when the video trigger is triggered, from there I would like to use an oscilloscope to measure the delay between the two triggers. Is this possible with the API?