Search Results for 'api'

[Andrew]

Hi Scott,

I’m sorry I didn’t realize you were also the same person we have been emailing.

I just sent a follow up email mentioning that based on my most recent understanding I don’t think there is an issue with the processing. I think the reason you see the “peak” or “corrupted data” at the 5MS/s rate is that you are centered at 100kHz, and the 0Hz (DC) feedthrough is coming into your spectrum. The filtering in the API is not sharp enough at that sample rate to filter out the 0Hz response. I recommend a post processing filter if you want to remove the 0Hz response, or reducing the sample rate to 2.5MS/s or below such that additional filtering helps remove the 0Hz feedthrough.

Does this sound like an accurate take on the information you have provided? If yes, then I believe the API is likely working nominally on your system.

I look forward to your response.

• This reply was modified 2 weeks, 2 days ago by Andrew.

[sreeder]

Andrew,

I have tested them and found some issues with bbGetIQUnpacked(). From my understanding when querying IQ data at a sample rate below 5MS/s (decimation greater than 8), a second FIR filter is applied to the data stream. It seems that the arm api implementation of this second FIR filter is corrupting data and reporting incorrect values on the RPi5 (a noise floor measurement [terminated analyzer] with decimation 16 using x86 will be around -130dBm while on ARM I see -80dBm [this is done with the same script, just different architecture]). GetIQUnpacked with decimations of 8 or less along with FetchTrace worked in my testing. I have seen this behavior in both PiOS lite as well as Ubuntu 24.04 on a Pi5

[Andrew]

There is now a BB60 Mac ARM API build in the latest SDK release here,

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

Please review the README in the macos_arm folder to understand it’s limitations (same as the Ubuntu aarch64 build).

• This reply was modified 1 month, 2 weeks ago by Andrew.

[Andrew]

Hi Michael,

The function vsgSetDigitalTuning allows you to control low spur mode. It has a different name, I apologize for the confusion.

https://signalhound.com/sigdownloads/SDK/online_docs/vsg_api/vsg__api_8h.html#a9dd9c01340e63f3101941122e320bbcc

Let us know if you have follow up questions.

• This reply was modified 1 month, 2 weeks ago by Andrew.
• This reply was modified 1 month, 2 weeks ago by Andrew.
• This reply was modified 1 month, 2 weeks ago by Andrew.

How can I disable Low Spur Mode in the VSG60 API?
When spur mode is enabled, I see unwanted signals. Please see the attached image files.

Thanks
Michael

Attachments:

You must be logged in to view attached files.

[Andy Leviss]

We’ve only been begging for Mac support for BB for over two years,so I guess what’s more indefinite wait?

The BB is the only of your analyzers that the live audio RF coordination and management industry can reliably use to do the wideband scans we need to do our jobs, so having Mac versions for almost every other family except that, and vague “it’ll come, eventually, maybe” is feeling pretty like Lucy, Charlie Brown, and the football to those of us in this field.

We’ve even given up on hope for Spike at this point; we’ve got multiple folks who can or will write a client for us, we just need the damned API

(╯°□°）╯︵ ┻━┻

[Andrew]

Hi scubajosh,

I apologize for the confusion, yes we use the aarch64 folder for the builds on the Nvidia Jetson. For APIs that have ARM Mac builds we use a folder called “macos_arm”. We have them for the SP and SM APIs, but not the BB API currently. I have confirmed we do have an open ticket to get this for the BB60 API. I don’t have a timeframe on this work right now, but I will be sure to update this thread when complete.

[scubajosh]

macOS Apple Silicon (aarch64 / M-series) native library support for BB60C

Hi Signal Hound team,

We’re integrating the BB60C into a Python application on macOS Apple Silicon (M1/M2/M3/M4). The lib/aarch64/libbb_api.so.5.0.10 in your SDK zip is a Linux ELF shared object compiled for the SYSV ABI. macOS uses the Mach-O binary format — CDLL() (Python ctypes) and dlopen() cannot load an ELF .so on macOS regardless of CPU architecture. Even though both the Jetson and Apple Silicon are aarch64, the OS ABIs are incompatible.

**What we need:** a macOS aarch64 build of bb_api as a .dylib (Mach-O shared library).

**What that requires on your end:**

1. **Build toolchain** — compile on macOS (Xcode clang or clang from Homebrew targeting arm64-apple-macosx). The Jetson/Ubuntu g++ build cannot produce Mach-O output.

2. **Dependencies to swap:**
– libusb-1.0 → use the macOS Homebrew build (brew install libusb), or link against IOUSBLib.framework directly. The libusb project ships macOS ARM64 builds.
– libftd2xx → FTDI ships a macOS ARM64 D2XX driver (.dylib) at ftdichip.com — the same download page you reference in README_aarch64.txt has a macOS section.

3. **Link flags** — replace -Wl,-rpath Linux syntax with macOS equivalents:
`
clang++ sources -o libbb_api.dylib -dynamiclib \
-install_name @rpath/libbb_api.dylib \
-arch arm64 \
-target arm64-apple-macosx11.0 \
-lusb-1.0 -lftd2xx \
-Wl,-rpath,@loader_path
`

4. **USB device permissions** — on macOS the equivalent of udev rules is an IOUSBLib entitlement or a signed driver kext/dext. For development/testing, running with elevated permissions or via a USB user-space claim (which libusb handles automatically on macOS) is sufficient without a kernel driver.

5. **Deliverable** — a lib/macos_arm64/libbb_api.dylib (or libbb_api.N.N.N.dylib with a symlink) in the SDK zip, alongside any required libftd2xx.dylib. The libusb-1.0.dylib can be expected as a Homebrew dependency rather than bundled.

**The ARM64 limitation note in your README** (sweep/IQ only is fine — we only need IQ streaming and sweep modes.
**( 1 kHz min RBW will not work for security TSCM work I would need at least 300hz RBW)

• This reply was modified 1 month, 3 weeks ago by scubajosh.

[sreeder]

It is great to have the API working on ARM; however, are there any updates this year/plan to have an ARM version of Spike? Having it run on something like a Pi 5 would be a game changer.

[jhenderson]

Hello,

I am targeting sample acquisition from my BB60C (or D) in the HF frequency ranges 0 – 20 MHz. I have the “typical” stream IQ mode working, but I wanted to see how the output compared to using the Direct RF flag that documentation hints at existing.

I’ve tried every combination of initializing things that I can think of, but I cannot avoid getting a SEGFAULT at the bbGetIQUnpacked/bbGetIQ call.

Something that’s missing from the documentation is a specific example of how that streaming type (BB_DIRECT_RF) is used.

I’m on Linux using api 5.0.9

• This topic was modified 1 month, 4 weeks ago by jhenderson.

[kaiser]

I’m currently trying to implement streaming IQ with trigger inputs on an SM200C.

A few years back we had implemented this on some SM200B’s and it worked as expected (a 1PPS into the GPIO port of the signal hound showed up as expected).

Now we have a new application, and can’t seem to get the triggers to work.

If I sit there and query the GPIO via the API, I see it toggle from 0 to 1 and back and forth as expected. But when I do IQ streaming, the triggers buffer is always returned as zeros.

I’ve stepped through every function, and they all return smNoError, so I don’t see what’s going wrong here. Tried a second SM200C and have the same issue.

sm_api.dll from Aug 21, 2025.

private void SetupRFSamplerForIQStreaming()
{
AppLogger.Info(“Configuring Signal Hound for IQ Streaming”);
try
{
try { _SH.AbortMeasurements(); } catch { }
_SH.SetGpioDirections(true, true); //trying this to see if we get triggers..
// _SH.SetGPSTimebaseUpdate(); //Sets the Timebase to begin updating with GPS time if available

_SH.SetIQCenterFreq(_RXCenterFreqInMHz * 1.0e6);
_SH.SetIQBandwidth(_RXBandwidthInMHz * 1.0e6);
_SH.SetRefLevel(-10);
_SH.SetIQDataType(SmDataType.smDataType32fc);
_SH.DisableGPIOSweep();
_SH.SetGPIOTriggerEdgeType(Rising: true);

_SH.SetIQQueueSize((float)(2.62 * 16)); //maximum amount of buffer
_SH.SetIQSampleRate(1); //1 is no decimation, max speed, acts on the powers of 2. We want to go as fast as possible for best time precision

_SH.ConfigureMode(SmMode.smModeIQStreaming);

var f = _SH.GetIQParameters();
RfSampleRateInHz = f[0];
}
catch { AppLogger.Error(“Failure to Configure Signal Hound For IQ Streaming”); }
}

• This topic was modified 3 months ago by kaiser.

[Roger]

Hi tschmitz,

The issue appears to be that the net_count variable is uninitialized. The smNetworkConfigGetDeviceList function uses its pararameter deviceCount to determine how large the serials array is, so it can return a maximum of that many devices (zero in this case).

In other words, the second line of code should be: int net_serials[SM_MAX_DEVICES], net_count = SM_MAX_DEVICES;

I know it is odd that the seemingly equivalent function for USB devices (SM200B/SM435B) does not have this requirement.

Let me know if this doesn’t fix it.

– Roger

• This reply was modified 4 months, 3 weeks ago by Roger.

[tschmitz]

Hello, I think I discovered a bug with device discovery.

When I run the following code with an SM200C connected (both USB-2.0 and 10GbE SFP+ connected), I get no devices found.

    int serial_numbers[SM_MAX_DEVICES], count;
    int net_serials[SM_MAX_DEVICES], net_count;
    int all_serials[SM_MAX_DEVICES * 2] = {0}, all_count = 0;

    SmStatus status = smGetDeviceList(serial_numbers, &count);
    LOG_DBG("Fetched %d serial numbers from <code>smGetDeviceList</code>", count);

    if (status != smNoError) {
        throw std::runtime_error(smGetErrorString(status));
    }

    status = smNetworkConfigGetDeviceList(net_serials, &net_count);
    LOG_DBG("Fetched %d serial numbers from <code>smNetworkConfigGetDeviceList</code>",
            net_count);

    if (status != smNoError) {
        throw std::runtime_error(smGetErrorString(status));
    }

    for (size_t i = 0; i < count; i++) {
        all_serials[all_count] = serial_numbers[i];
        all_count++;
    }

    for (size_t i = 0; i < net_count; i++) {
        all_serials[all_count] = net_serials[i];
        all_count++;
    }

I also found if I add a delay of roughly 1.5 seconds between the two API calls, it correctly finds the SM200C. Reversing the API calls also works, but I have a feeling that it breaks discovery for the SM200B/SM435B.

OS: Ubuntu 22.04
API Version: 2.3.8
C++ Standard: C++11
CPU: AMD Ryzen 9 9955HX

• This topic was modified 4 months, 3 weeks ago by tschmitz. Reason: Additional info
• This topic was modified 4 months, 3 weeks ago by tschmitz. Reason: Formatting

[Andrew]

If using Spike there is unfortunately not a way to trigger off the internal PPS.

If using the API, then this would be possible by using the I/Q timestamps. When I/Q streaming via the API with GPS lock, the timestamps would give you indication of when the PPS trigger occurred and you take action at the appropriate time.

[Craig]

I found the list. For archeologists after me, it is in the SDK download under:

\signal_hound_sdk\scpi\Spike

My mistake was looking in the API folder for the device.

I see in the SCPI documentation that limit lines are supported but I can’t find anywhere in the API or code examples that even mention their usage.

Where can I find examples for setting and querying limit lines statuses?

[Andrew]

Hi Jonathan,

Spike can only control one channel of the PCR4200 at a time. You can change which channel is controlled using the Utilities -> Diagnostics selection. Each channel will behave identically. Support for the PCR4200 in Spike is primarily to assist with troubleshooting in network configuration and to make single channel spectrum analysis measurements using the receiver.

The full power of the PCR4200 is exposed through the API. There you can access the multi channel streaming, phase coherent measurements, and simultaneous sweep + stream.

The API files can be downloaded from our SDK here here,
https://signalhound.com/software/signal-hound-software-development-kit-sdk/

API documentation can be viewed here,
https://signalhound.com/sigdownloads/SDK/online_docs/pcr_api/index.html

If you would like to discuss your use case in more detail, please email me directly at aj@signalhound.com.

Regards

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

[Andrew]

We do have minimal ARM Mac support for the SP145 in the form of compiled APIs. If you were writing your own software you could take advantage of them to use the instrument on Mac. You can find those libraries in our SDK. Porting Spike is a much larger project, and no effort has been made on this port yet. It has been requested a few times over the years, there is some interest. I can’t provide any timelines or estimates on this project.

Hello, our company is currently considering acquiring a VNA400 unit.
We would like to use it with automatic calibration modules even if third party modules.
Do you have this integration planed in the near future even if it is only posssible by the api.
Alternativly will you produce your own calibration modules or even partner with other company for the process.
Best Regards, Pedro.

[Justin Crooks]

Garth,
Yes, if you wanted to do this programatically, you could use the sa_api and tg_api. Do 2 sweeps, one with your reference through, and one with your DUT. For each point within the sweep, tune the TG then do a small (100 kHz span or smaller) sweep around the signal and find the max value. Subtract the 2 sweeps for your insertion loss. We created a support ticket for this issue, but I don’t know where it is in the queue, so a “DIY” TG sweep might be a good solution in the short run.

• This reply was modified 8 months, 4 weeks ago by Justin Crooks.