BB60C-API for ARM

That is a huge pitfall… All my frustrations are lazer focused on using my BB on my ARM computers via Spike. Back to my Harogic SAM60 with native support.

Appreciate the update.

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.

There are currently no plans to port Spike to ARM at this time.

Thanks

[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, 1 week ago by scubajosh.

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.

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

(╯°□°）╯︵ ┻━┻

@Andy Leviss

Two years… Try four years. It’s abundantly clear that they don’t see the engineers that travel and use their devices as a user base they want to please nor care about.

Its 2026 you can vibe code it in like 30 minutes with a codex account…

[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 ago by Andrew.

Amazing I will test it out today and let you know. I know with using TSCM software and spike i can get down to 10hz rbw on the bb60c is this limitation on RBW because of the driver or are you doing post processing while sweeping to get it down to 10hz?

[Andrew]

Scubajosh, the RBW/VBW is limited to 1kHz minimum in this build. Additional processing is needed to reach 10Hz.

• This reply was modified 1 month ago by Andrew.

The aarch64 shared object file readme notes it is compiled on the Nvidia Jetson for Ubuntu 20.04. Would it be possible to get a version compiled on PiOS 64 or a Debian 13 OS with kernel 6.12?

[Andrew]

sreeder,

Have you tested them in your configurations and verified they would not work? I have customers reporting success on the RPi5 under Ubuntu when using the Nvidia aarch64 builds. Both PiOS and Debian are similar enough I would expect them to work.

• This reply was modified 19 hours, 43 minutes ago by Andrew.

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]

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 18 hours, 56 minutes ago by Andrew.

[Author]

Posts