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

Hi ANguyen,

The value of SA_TG_SWEEP is 4 (source: API docs). Any value above that will trigger the invalid param error.

Definitions can be found in the API docs at the link above and/or in the source code.

– Roger

There is not currently a way to do this. This is an interesting feature, thanks for suggesting it.

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

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.

Hi Charles,

Try renaming both .so files to have a “lib” prefix, and updating the CDLL call accordingly. So, the bbdevice directory would contain libbb_api.so and libftd2xx.so. The call would be bblib = CDLL("bbdevice/libbb_api.so")

You are correct that LD_LIBRARY_PATH needs to be set. We are updating the documentation.

Thanks for reaching out.

-Roger

Hi Ajaykumar,

It looks like an outdated version of the Signal Hound BB60 GNU Radio module is being used. This could be either because the repository was cloned before GNU Radio 3.9 support was added in August 2022, or because the 3.7 maintenance branch is being used (maint-3.7). Swig is not used in 3.9, and those swig directories and makefiles do not exist in the current codebase.

To solve this, you can clone the current repository, pull the latest changes, or if your repo is up to date, checkout the master branch.

Let me know if you continue to have issues.

Roger

Hi Matt,

The min and max arrays populated by saGetSweep_32f are 32-bit floating point numbers, not ints. So, use ct.c_float instead of ct.c_int in your array initializations.

Regards,
Roger

Hi ebohannon,

I just replied to your email with some suggestions. Let me know what works and I will update it here.

Thanks,

Roger

Hi Ray,

Unfortunately I have not been able to reproduce the issue you are having, and the debug message is too general to point me to anything specific.

The fact that you are receiving the exact same error message on two completely different systems, one of which is the same that we test on (18.04 LTS), suggests to me that the issue lies somewhere in your configuration or installation process. In debugging I would focus on peculiar commonalities shared by your two environments.

Let me know if you get any more specific debugging feedback, or if you want to share output that shows your exact process / command sequence.

Regards,
Roger

Hi hhonza501,

That is correct, the Event List contains events that occurred during the last sweep.

Currently, all events are logged in realtime, so an ongoing event is logged repeatedly, after each sweep, with an increasing duration. This is to ensure the accuracy of the log at any given time, and to safeguard the data in the event of an accidental system shutdown. However, we have decided to change this functionality, in favor of having an ongoing event logged only once, either when the signal disappears or logging ends, with its final duration. This change will be in the next Spike update.

Let me know if you have more questions about interference hunting mode.

Regards,
Roger

Hi Yu Ching,

I have created a new LabVIEW example for computing channel power. It is a modification of the continuous sweep example.

Let me know if you have any questions about it.

Regards,
Roger

Attachments:

You must be logged in to view attached files.

[Author]

Posts