The ScanaStudio SDK
ScanaStudio v6 is split in two: a server that owns the instruments and the data, and clients that talk to it. The ScanaStudio GUI window is one of those clients. Your script is another, and it uses exactly the same interface.
Everything you can do in ScanaStudio, you can do from code: configure a
device, arm a trigger, capture, run protocol decoders, take measurements, drive
the pattern generator, export, save a .scana. The GUI and the SDK use the same
interface, so there is no reduced "automation subset".
Four client libraries, all MIT-licensed:
| Language | Package |
|---|---|
| Python | ikalogic-scanastudio on PyPI |
| NodeJS | @ikalogic/scanastudio on npm |
| Rust | scanastudio-client on crates.io |
| C | libscanastudio, downloaded as one archive |
The C library is what lets LabVIEW, MATLAB, C# and existing C or C++ test benches drive a ScanaStudio server without speaking WebSocket themselves.
This documentation describes the SDKs at 0.2.5. All four packages share one version number and are released together.
Always install the latest version of whichever package you use. A client only talks to a server whose protocol version it knows. If a connection is refused with a version mismatch, one side is older than the other: upgrade the SDK, or update ScanaStudio.
- The ScanaStudio SDK — this section. Drive the instrument from outside the application, in Python, NodeJS, Rust or C.
- Logic Analyzers Scripting — write protocol decoders and pattern generators that run inside ScanaStudio, in JavaScript. The decoders this SDK may use are written with that API.
- Logic Analyzers hardware API — the legacy IHWAPI, which this SDK supersedes. See below.
This supersedes the old hardware API
Until now, driving an Ikalogic analyser from code meant the IHWAPI (Ikalogic
Hardware API): one C library per device family (sp209api, sp259api,
sp1000gapi), each with its own function set, limited to opening a device and
reading raw transitions. The SDK replaces it:
| IHWAPI (legacy) | ScanaStudio SDK | |
|---|---|---|
| Languages | C, and whatever can call a C ABI | Python, NodeJS, Rust and C |
| API surface | A different one per device family | One, identical across every device |
| Protocol decoding | ❌ None — raw transitions only | ✅ Every ScanaStudio decoder, with its results as packets, items and hex |
| Triggers | ❌ Basic only | ✅ Edge, logic, pulse, multi-step, external, and A/B sequences |
| Pattern generation | ❌ Not available | ✅ Full generator control, with an interpreted preview |
| Measurements | ❌ Do the arithmetic yourself | ✅ Markers and measurements, computed server-side |
| Export | ❌ Write your own | ✅ CSV of samples, packets, hex or raw items |
| Saving | ❌ Not available | ✅ Save and reopen .scana files |
| Remote | ❌ Local USB only | ✅ Any machine on the network |
| Session lifetime | Dies with your process | Lives on the server: disconnect, come back, rejoin |
| Concurrency | One process, one device | Several clients on one server, watching the same capture |
New integrations should use the SDK. The IHWAPI stays available for existing code but will not gain features.
If you have IHWAPI code, see Migrating from the hardware API, which maps each call to its SDK equivalent.
Where to go next
- Installation: get a package and a server.
- Your first capture: the shortest complete program, on a demo device, no hardware needed.
- Core concepts: the ideas behind the API, language-neutral.
- Feature coverage: what each SDK supports.
- Guides & use cases: complete programs for a bench test, a datalogger, decode and export, measurements, the pattern generator and remote access.
- API reference: every call, in four languages.
Every server offers demo devices that behave like real hardware. Every example in this section runs on one. Note that demo devices generate pseudo-random signals, not real protocol traffic.