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