Early concept · comments welcome

Open instruments.
Better together.

Open Instrument is an open platform for test and measurement hardware: useful standalone instruments with a common way to communicate, synchronize and work as a system.

See the platform First instruments
Commodity interconnects. Deterministic hardware triggering. Open hardware and software. No proprietary electrical backplane.
Open Instrument modular OI logo
The platform

Standardize the boring parts.

The specification covers the shared infrastructure; instrument designers keep control of the measurement, source, load or I/O that makes their device unique.

OI Link

Two RJ45 ports. CAT5e. CAN-FD for control and a dedicated differential hardware trigger for deterministic timing.

OI Protocol

Discovery, identity and capability-based control. Software asks for what an instrument can do, not a hard-coded model number.

OI Power

A common 24 V service-power system with declared power classes. High-power DUT energy paths remain instrument-specific.

OI Local

Mandatory USB-C on every instrument for direct host communications, diagnostics and firmware update — plus physical Recovery.

OI Stack

An optional common footprint, U-height system, connector zones and airflow convention. Mechanical modularity without an electrical backplane.

OpenMeter
Low-voltage bench DMM
OpenIO
Digital control & fixture I/O
OpenPower 4
Four programmable electronics rails
OI Base
USB gateway · stack power · trigger
The key idea

The stack is packaging. The instruments remain instruments.

The stack standardizes mechanics and service connections, not the instrument itself. OI Local gives every device a direct USB-C connection; OI Link adds multi-instrument coordination when needed.

CAN says what. The trigger says when.
Principles at a glance

Useful alone. Powerful together.

Six rules guide the platform. They define the experience we want without prescribing how an instrument performs its core function.

01

Standalone first.

Every instrument must be genuinely useful by itself. The platform adds capability; it never becomes a dependency.

02

Interoperability by design.

Devices discover one another, expose capabilities and combine into systems without model-specific glue.

03

Software decides what. Hardware decides when.

Use the network for orchestration and deterministic hardware triggering where timing matters.

04

Commodity infrastructure.

RJ45, CAT5e, USB-C and readily sourced components beat bespoke cables, chassis and unicorn silicon.

05

Modular without a backplane.

Standardize mechanics, power and interface positions without making one expensive connector the architecture.

06

Build small. Compose big.

One instrument solves one problem well. Multiple instruments should naturally create larger capabilities.

Manifesto

Engineering commitments behind the principles.

The principles above describe the platform at a glance. These additional commitments cover the less visible details that make open instruments trustworthy, reproducible and pleasant to own.

01Separate system power from instrument energy.

OI Power runs the platform. High-power sourcing, sinking and DUT energy remain appropriate to each instrument.

02Isolation is explicit.

USB, OI Link, service power, chassis and DUT grounds must have documented relationships. Hidden current paths are measurement errors.

03Failure should be local and repairable.

Wear items and sacrificial protection should be replaceable wherever practical; small failures should not turn instruments into e-waste.

04The standard serves implementations.

OI defines interoperability, not the MCU, firmware language, enclosure material or analogue architecture.

05Leave room for what we have not imagined.

Reserve interfaces until there is a real use for them, and design extensions so existing instruments keep working.

06Open means reproducible.

Reference designs should publish source CAD, firmware, BOMs, calibration and test information — not just fabrication outputs.

07Sourceable by design.

Critical components should have public documentation and be readily purchasable in small quantities through normal distribution.

08There is always a way back.

Every device has OI Local USB-C and a physical recovery path that can restore firmware without OI Link, OI Power or a debug probe.

09Professional behaviour need not mean professional pricing.

Open hardware can still be protected, calibrated, deterministic and carefully characterized.

First reference projects

Four simple instruments to prove the idea.

The first hardware is intentionally modest: enough variety to exercise the platform, while each board remains a useful bench tool.

OI Base

Concept

The optional stack coordinator: USB-to-OI gateway, 24 V power distribution, bus termination, trigger generation and power monitoring.

USB-C host linkCAN-FD24 V OI PowerTrigger

OpenMeter

Architecture

A compact low-voltage bench DMM with a small colour display, logging and triggered measurements, focused on electronics rather than mains work.

~60 V maxADS125H02 candidateOI Local USB-CTriggered capture

OpenPower 4

Architecture

Four independently programmable low-power rails for embedded systems work, with per-channel voltage/current telemetry and sequencing. A common-return V1 keeps the design approachable.

4 channels0.8–12 Vup to 1 A/chshared ~30 W

OpenIO

Planned

The “hello world” OI instrument: protected digital I/O, relays, PWM and counters, and the simplest reference design to copy when creating a new device.

digital I/OrelaysPWMreference firmware
Work in progress

This is a proposal, not a finished standard.

We are publishing the architecture early so the weak assumptions can be challenged before interfaces harden.

  • OI Link pin assignments and the trigger electrical layer are not yet frozen.
  • OI Stack dimensions, U-height and rear connector locations still need mechanical prototypes.
  • OI Power classes, connector choice and hot-plug behavior need validation.
  • The application protocol still needs a decision on the underlying CAN software stack.
  • The reference instruments shown above are architecture concepts, not released hardware.
The standard should emerge from building the instruments.

The first boards are test cases for the specification. If a rule makes real hardware harder to use, repair or reproduce, the rule should change.