Search Results for 'api'

Using the libsm_api.so.2.3.3 for RHEL8 we are getting “-11: Data synchronization error” when calling smGetVrtPackets(). This happens fairly consistently but also might not fail or might fail after some significant amount of time.

The setup is an SM200C. This is attached either via a sonnettech transceiver (fp10+) attached to a laptop or connected to a 10G switch connected to a server. Both are running RHEL 8.

This also happens when using Spike v3.9.0. Though most of time with Spike we’re getting a -6 error. Given the closed nature of libsm_api.so and no debug artifacts or sources I’m stumped. Any help would be appreciated. Thanks.

[Roger]

Hi ANguyen,

Thanks for the details provided.

The error is -8: Device Not Found. The error codes can be looked up in the API docs.

Is the SA44B working in Spike? If so, make sure Spike is not running when attempting to connect in LabVIEW. If not, it would be best to troubleshoot that first.

Note that the USB driver needs to be installed separately. It can be downloaded with this link. Unplug devices, right click on the driver and select “Run as administrator”. Then plug in device and run Spike.

If you are not able to get the SA44B running in Spike, please reach out to support@signalhound.com for more detailed troubleshooting.

– Roger

[kaiser]

Thanks Andrew.

I do have to say that with SM200C’s, the difference in speed between Queued Sweeps and non-queued is basically imperceptible in our application. It’s very very response non-queued…I’ll be able to test how the SM200B’s hold up doing the same. If I remember right the non-queued was significantly slower.

Here’s some of the various code bits for how we’re configuring the SignalHound.

sm_api.smSetSweepSpeed(handle, SmSweepSpeed.smSweepSpeedFast);
CurrentStatus = sm_api.smSetSweepCoupling(handle, 125.0e3, 125.0e3, 0.0001); //Gives a 3.1kHz scan, 138us blanking (similar spectrum sweep time, about 50% duty cycle).
sm_api.smSetSweepDetector(handle, SmDetector.smDetectorAverage, SmVideoUnits.smVideoLog);

sm_api.smSetSweepWindow(handle, SmWindowType.smWindowNutall);
sm_api.smSetSweepSpurReject(handle, SmBool.smFalse);
sm_api.smSetPreselector(handle, SmBool.smFalse);

//GPIO configuration
int gpiosteps = 2;
sm_api.SmGPIOStep[] Steps = new sm_api.SmGPIOStep[gpiosteps];

Steps[0].freq = 2.2e9;
Steps[1].freq = 2.38e9;
Steps[0].mask = 0x00;
Steps[1].mask = 0x0F;

sm_api.smSetGPIOState(handle, SmGPIOState.smGPIOStateOutput, SmGPIOState.smGPIOStateOutput);

I have a quick question about queued sweeps and how they work.

I have two signal hounds hooked up, and I basically just queue up 16 sweeps and then let them cook.

What’s happening is that sometimes it looks like I drop a sweep or am missing one or something, and then it re-inserts itself later.

The application very quickly switches between multiple RF sources, and does a scan and then switches to another one. For the sake of this effort, let’s say I have 20 different sources. I then plot a power graph showing the power at these different sources, and I continually do this over and over and over.

So I expect say a certain amount of power at source 10. And it’s usually correct. But sometimes that power shows up in the 9 slot, but then a couple of seconds later jumps back to the 10 slot. And then maybe 15 seconds later it jumps back to the 9 slot, and just kind of sometimes ping-pongs around but is only ever off by the single sweep.

The weird thing is that if I don’t queue sweeps (just use the normal smGetSweep), OR if I only queue 1 sweep it seems to work perfectly and all the energy stays in the bins it should be in. But anything above queueing a single sweep, and things get wonky.

Any thoughts?

Code outline is something like:

FastSpecAns[0].QueueSweeps(16);
FastSpecAns[1].QueueSweeps(16);
while (State == ArrayState.TRACKING)
{
SpectrumZero = FastSpecAns[0].GetFinishSweep();
SpectrumOne = FastSpecAns[0].GetFinishSweep();
}

And GetFinishSweep is basically just:

SmStatus f = sm_api.smFinishSweep(handle, QueuePos, null, Sweep, ref sweeptimeEpoch);
SmStatus s = sm_api.smStartSweep(handle, QueuePos);

QueuePos++;
if (QueuePos >= SweepsToQueue)
{
QueuePos = 0;
}

[Andrew]

Hello BSchwartzer,

We no longer support the RPi builds for the SA devices. The RPi builds had several issues and we were not able to get the SA devices to run stable either on ARM or x86 Linux architectures. For the forseeable future, the SA’s are supported under Windows only.

Additionally, None of our devices are supported under ARM architectures. The BB, SP, and SM lines are supported in x86/64 Linux OS’s. We target Ubuntu primarily with some support for CentOS and Redhat.

We are evaluating the NVidia Jetson platform for specific device APIs (it will not include the SA44/124). We will have more information on that in the future.

If you have follow up questions, let me know.

I’m tring to run the example code for rpi2 from the sdk. from the directory signal_hound_sdk/device_apis/sa_series/lib/_obsolete/arm-rpi2 (obsolete)/sa_api_armv7-A_3_0_6/examples
I’ve maneged to compile them but during the runtime i’m getting the following error:
[ 8713.459978] 8<— cut here —
[ 8713.463074] Unhandled fault: alignment exception (0x001) at 0x7614fbba
[ 8713.469683] [7614fbba] *pgd=18a2d835, *pte=1931b75f, *ppte=1931bc7f
Bus error
Please help me to solve this

Thanks

I would like to connect the sa124b to nvidia TX2 (arm64) but I don’t have the libsa_api.so that fits my processor. The sdk comes only for ubuntu x64, rpi2, windows and beagleboard.
How can I get the library for arm64?

Thanks

[Andrew]

You are correct. The sweep recordings cannot currently be controlled via SCPI. This has been requested before and is something we hope to add to our software in a future release.

Until we can add this to the software, there might be another solution. You could use the API and store the data in the SHR file format. Located in the SDK, you can find an example SHR file parser project. From this project, you can learn about the file format and use the API to retrieve sweeps to store in your own SHR files.

Hi, I have a fleet of BB60C/D (QTY 27) units connected to antennas to monitor for receive in-band interference & signal quality. Occasionally we have to do long term monitoring and have the units recording 24/7. We have the unit connected to an RF switch to allow us to monitor either the LHCP or RHCP coming from the antennas. What I want to do is automate the following processes:

1. We have to log into the remote PC and manually stop and start the recording each day.

2. We have to manually change the file name of the recording each time to indicate if we’re on LHCP or RHCP pol. I’d like to be able to automate the naming of the file as well to represent that info. The remote PC has visibility into the state of the RF switch.

I would normally automate something like this with SCPI commands, but it seems that the SHR recording functions have no SCPI commands available. Also I was not able to find out how to interface with the SHR recording functions through the API.

Ideally I’d like to use SHR recordings instead of a custom API recording implementation as they already hold all of the data I need + they have your wonderful spike UI for playback. If I had to write a custom recording file through the API, I can guarantee my playback method would not be as pretty.

If you guys have any advice on what I should do, please let me know. Any help would be appreciated. Thanks.

[Andrew]

MCarr,

The API does not have any of the modulation capabilities. When using the API you have to provide your own waveform. You have a couple options,

– The VSG60 UI can be programmed using SCPI commands. in the SDK, look under the SCPI folder and you will find a manual and examples for configuring the software via SCPI commands. Labview has support for sending SCPI commands. In this scenario, the VSG60 software would be running, and then you would run a SCPI “script” in Labview (or any other programming language) that would configure the software.

– Generate your own I/Q waveform. If you don’t know how to generate a QAM waveform, you could use offerings from Labview such as,
https://www.ni.com/en/support/downloads/software-products/download.labview-modulation-toolkit.html#484334
or MATLABs communication toolbox. If you generate the waveform outside labview, then you would want to save it as a file, and in Labview, load the file and feed it to the API.

Hi,

We trying to replicate the attached modulation using the provided API in in C#.

I’m not clear how to perform this using the command set available.

Are there any examples or maybe just a bit of guidance to push us in the right dirrection.

Thanks

Attachments:

You must be logged in to view attached files.

[Andrew]

The API certainly should be able to interface several devices. We interface up to 8 devices in our manufacturing line using the API. What you will find is that most PCs will limit the number of actively streaming VSG60’s to 2, primarily limited by USB throughput and CPU cycles. Some PCs do struggle to transmit on 2 simultaneously. If you are also using one of our spectrum analyzers, you might consider moving the analyzer to another PC for making measurements.

If you are on Linux, please be sure to read the section on Linux in the VSG60 manual,
https://signalhound.com/sigdownloads/SDK/online_docs/vsg60_api/index.html#autotoc_md9

Opening a second device should be as simple as calling vsgOpenDevice a second time with a new handle variable. This will result in you having two handles, one for each device. The handle values should be 0 and 1 after the vsgOpenDevice function returns.

If you are on Windows, you can verify that you see 2 devices connected in the device manager. If you don’t, then you need to resolve this first. The LED should also be solid green on both units when connected and idle.

We have not tested multiple devices in our Python environment, but it should be the same. If possible, you can test multiple devices in C++. The Python wrapper simply wraps the C interface. You can see the function assignment in the vsg_api.py file.

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. After the second time using the vi I get the same error. Any suggestions on how to fix this? Is there a different dll available? Any help is appreciated. Thanks!!

Attachments:

You must be logged in to view attached files.

[SignalHoundUser]

Forum wont allow .py files. Hopefully the txt will work.

# -*- coding: utf-8 -*-

# This example generates a basic AWGN signal.

from vsgdevice.vsg_api import *
from time import sleep
import matplotlib.pyplot as plt
#numpy.set_printoptions(threshold=numpy.inf) #Use to print full length arrays

def plot_complex_fft(complex_data, sampling_rate):
# Calculate and plot the Frequency data
# Calculate FFT
fft_result = numpy.fft.fft(complex_data)
fft_freq = numpy.fft.fftfreq(len(complex_data), 1 / sampling_rate)
# print(fft_freq)
# Plot the results
plt.figure(figsize=(10, 6))

# Plot the frequency-domain signal (FFT)
plt.plot(fft_freq, numpy.real(fft_result), color=’red’, label=’I Data’)
plt.plot(fft_freq, numpy.imag(fft_result), color=’blue’, label=’Q Data’)
# plt.plot(numpy.abs(fft_result))
plt.title(‘FFT of Complex Signal’)
plt.xlabel(‘Frequency (Hz)’)
plt.ylabel(‘Amplitude’)

plt.show()

def plot_IQ(complex_data, sampling_rate):
# Plot the Time Series results
plt.figure(figsize=(10, 6))
# Separate the real and imaginary parts
I_data = numpy.real(complex_data)
Q_data = numpy.imag(complex_data)
# Plot the frequency-domain signal (FFT)
plt.plot(I_data, color=’red’, label=’I Data’)
plt.plot(Q_data, color=’blue’, label=’Q Data’)

# plt.plot(numpy.abs(fft_result))
plt.title(‘Complex Signal’)
plt.xlabel(‘Samples’)
plt.ylabel(‘Amplitude’)

plt.show()

def low_pass_filter(complex_data: numpy.ndarray, BW: int = 40e6, sampling_rate: int = 50e6) -> numpy.ndarray:
# translate bandlimit from Hz to dataindex according to sampling rate and data size
bandlimit_index = int(BW * (complex_data.size/2) / sampling_rate)
fsig = numpy.fft.fft(complex_data)

for i in range(bandlimit_index + 1, len(fsig) – bandlimit_index):
fsig[i] = 0

adata_filtered = numpy.fft.ifft(fsig)

return adata_filtered

def normalise_level(complex_data):
# Normalise average level to 0dB
aveSig = numpy.average(numpy.abs(complex_data))
aveSigdB = 20*numpy.log10(aveSig) # should be 0dB
print(“Normalised Signal dB = ” + str(aveSigdB))
complex_data *= 1/aveSig
aveSig = numpy.average(numpy.abs(complex_data))
aveSigdB = 20*numpy.log10(aveSig) # should be 0dB
print(“Normalised Signal dB = ” + str(aveSigdB))

return complex_data

def interleaved_to_complex(interleaved_data):
# Reshape the interleaved data into a complex array
complex_data = interleaved_data[0::2] + 1j * interleaved_data[1::2]
return complex_data

def complex_to_interleaved(complex_data):
# Separate the real and imaginary parts
real_parts = numpy.real(complex_data)
imag_parts = numpy.imag(complex_data)

# Interleave the real and imaginary parts
interleaved_iq = numpy.empty(2 * len(complex_data), dtype=numpy.float32)
interleaved_iq[0::2] = real_parts
interleaved_iq[1::2] = imag_parts

return interleaved_iq

def complex_AWGN(length, stddev):

iq = numpy.random.normal(0, stddev, length) + 1j * \
numpy.random.normal(0, stddev, length) # .astype(numpy.float32)
return iq

def generate_iq():
# Open device

ret = vsg_open_device()
print(ret)
handle = ret[“handle”]

serialNumber = vsg_get_serial_number(handle)[“serial”]

# Configure generator
freq = 1.0e9 # Hz
sample_rate = 50.0e6 # samples per second
BW = 40.0e6 # Target bandwidth of AWGN
level = -20.0 # dBm

vsg_set_frequency(handle, freq)
vsg_set_level(handle, level)
vsg_set_sample_rate(handle, sample_rate)
vsg_recal(handle)

# Gernerate Waveform
iq = complex_AWGN(16384, 100)
iq = low_pass_filter(iq, BW, sample_rate)
iq = normalise_level(iq) #Set IQ to 0dB
iq = complex_to_interleaved(iq)

vsg_repeat_waveform(handle, iq.astype(numpy.float32), int(len(iq)/2))
print(“Waveform set”)

# Ramp Power
for power in range(-100, -30, 5):

vsg_set_level(handle, power)
print(“Power = ” + str(power))
scaling = vsg_get_IQ_scale(handle)[“iq_scale”]
print(“scaling = ” + str(scaling))
sleep(1)
print(“complete”)
# Stop waveform
vsg_abort(handle)

# Done with device
vsg_close_device(handle)
print(“closed”)

if __name__ == “__main__”:
generate_iq()

[andrewclegg]

The older version I’m running now shows 3.4.2. If it’s helpful, the “About” screen also shows BB API Version 4.2.0, SAAPI Version 3.1.4, SM API Version 2.0.2, product ID 4300-1101. This is pretty much a random version that I still had the install package sitting around my disk drive, so whatever happened was after this version. The connectivity issue started roughly a year ago. So not very exact, but that would give you a rough range. It occurred to me at the time that it would be useful if it was possible to download previous versions of drivers and Spike. Is that a thing?

An important fact is that I’m still running Windows 7 on this particular installation. So perhaps if I had a laptop running Windows 11 it wouldn’t be an issue. When I find some time I can give that a try, but I usually don’t like to mess with things that are stable.

I am trying to capture the MAX power value of a single SBAND ping, using the Python API.
I am able to do it using the Spike software (see attached) but I’m having problems configuring the BB60C the same way using the library.

Can somebody help me reproduce the same spectrum analyzer behavior?

That would mean:
1-Configure SA w/ MAX HOLD feature
2-Send ping
3-Retrieve max value.

Thanks.

Attachments:

You must be logged in to view attached files.

[Roger]

Hello, there are a few steps required for Linux use:

1. Trim the version info off the shared object library file name, and place it in folder bbdevice/ along with libftd2xx.so.

So, bbdevice/ should contain:

– bb_api.py
– libbb_api.so
– libftd2xx.so

2. Change the CDLL import line in bb_api.py to read:

bblib = CDLL("bbdevice/libbb_api.so")

3. Set the LD_LIBRARY_PATH to the bbdevice/ directory (since that’s where the ftdi library is):

Run in terminal from the examples/python directory:

export LD_LIBRARY_PATH="$(pwd)/bbdevice"

Now the examples should be able to be run from the examples/python directory.

[HDwi]

(f”{‘Error’ if status < 0 else ‘Warning’} {status}: {bb_get_error_string(status)} in {func.__name__}()”)

and i got this error when i try to running bb_api.py

I try to run sweep_plot.py from the example in linux 18.04 but i got error said ‘module bbdevice.bb_api not found. it was said to put bb_api.so in bbdevice folder but i couldn’t find it, i just found libbb_api.so.5.0.5 in the lib directory? I already tried this examples in windows platform and had no problem

[Andrew]

Hi NMullin,

Thanks for the follow up.

I do not believe there is currently a way to play a streaming scenario only once. I will see if this is something that can be easily added.

I should at least mention, that it is possible to use the API to transmit a waveform. The API is an interface for programmatically controlling the instrument without need for the UI application. This would allow you to perform this task relatively easy if you are comfortable writing software. See link below for more information.

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