01
Opt in explicitly.
No OI standard is mandatory for every project. Each claim is shown separately; selecting OI Link also selects OI Protocol, while OI Stack selects OI Link, OI Protocol, and OI Power.
Draft 1 standards · discussions open
Open instruments.
Open instruments.
Better together.
The Open Instrument Project is building an open platform for interoperable test and measurement hardware: instruments that remain useful on their own, but gain new capability when they communicate, synchronize, and compose into systems.
Commodity interconnects. Deterministic hardware triggering. Direct USB-C ownership and recovery. Open standards, open reference hardware, and no proprietary electrical backplane.
The standards
Standardize the boring parts.
The Open Instrument standards define shared infrastructure without imposing a universal all-or-nothing platform. Projects choose the standards they implement and report each choice separately on their OI Compatibility Badge. OI Link requires OI Protocol. OI Stack requires OI Link, OI Protocol, and OI Power so instruments can be chained with shared communication, triggering, semantics, and service power. Within each claimed standard, its interoperability requirements still apply.
OI-01 · Draft 1
OI Link
Requires OI Protocol. Two 8P8C ports and CAT5e carry CAN-FD control plus a dedicated differential hardware trigger for deterministic timing.
OI-02 · Draft 1
OI Protocol
Transport-independent identity, capabilities, requested vs actual state, measurements, faults, triggering, and composition.
OI-03 · Draft 1
OI Power
A common 12 V service/housekeeping domain. High-energy DUT paths remain instrument-specific where appropriate.
OI-04 · Draft 1
OI Standalone
Direct USB-C standalone host access, firmware update, and a physical recovery path that works from ordinary 5 V VBUS.
OI-05 · Draft 1
OI Stack
Opt-in compound profile requiring OI Link, OI Protocol, and OI Power, with a common footprint, U-height system, service connector zones, and airflow conventions — without an electrical backplane.
OI Meter 1
Low-voltage bench DMM
OI Basic
Digital control & fixture I/O
OI Supply 3
Three programmable electronics rails
OI Base
Gateway · service power · trigger
The key idea
The stack is packaging. The instruments remain instruments.
For projects that adopt it, OI Standalone provides direct USB-C access when an instrument is used on its own. OI Link adds multi-instrument control and deterministic timing. OI Power keeps a stacked instrument's service/control domain alive without pretending to be a universal DUT-energy bus.
CAN says what. The trigger says when.
Principles at a glance
Useful alone. Powerful together.
Six principles guide the platform without dictating how an instrument performs its core function.
02
Interoperability by design.
Devices expose identity, resources, capabilities, state, and faults so systems do not depend on model-specific glue.
03
Software decides what. Hardware decides when.
Use the network for orchestration and a dedicated electrical trigger where deterministic timing matters.
04
Commodity infrastructure.
8P8C, CAT5e, USB-C, commodity service power, and readily sourced components beat proprietary cables and unicorn silicon.
05
Modular without a backplane.
Standardize interfaces, mechanics, and service zones without making a blind proprietary connector the architecture.
06
Build small. Compose big.
One instrument solves one problem well. Multiple instruments can then become a larger virtual instrument or automated test system.
Engineering commitments
Open should mean more than published Gerbers.
These commitments cover the less visible details that make an open instrument reproducible, serviceable, predictable, and pleasant to own.
01Separate service power from DUT energy.
When adopted, OI Power keeps the instrument alive. High-energy sourcing, sinking, and DUT paths stay appropriate to each instrument.
02Grounding and isolation are explicit.
Every implemented interface has a documented relationship to chassis and DUT grounds. Hidden current paths are not acceptable architecture.
03Failure should be local and repairable.
Protection and wear items should fail predictably and remain replaceable wherever practical.
04The standards serve implementations.
Interoperability is normative. MCU family, firmware language, PCB tool, and analogue topology are not unless compatibility genuinely depends on them.
05Reserved means reserved.
Leave room for future needs instead of allocating pins, protocol space, or connector functions before there is a concrete requirement.
06Open means reproducible.
Reference projects publish editable source, BOMs, firmware, calibration, manufacturing information, tests, and design rationale.
07Sourceable by design.
Reference hardware uses publicly documented parts that ordinary builders can actually buy through normal distribution.
08There is always a way back.
A project claiming OI Standalone provides a documented firmware-recovery path without an OI network, service power, enclosure opening, or debug probe.
09Professional behaviour need not mean professional pricing.
Open hardware can still be protected, calibrated, deterministic, characterized, and pleasant to use.
Reference projects
Build the standards against real instruments.
Reference projects are useful tools in their own right and practical test cases for the standards. Implementation choices remain implementation choices; they do not automatically become platform requirements.
OI Supply 3
Active · Draft 1A compact three-channel programmable electronics supply and the first substantial reference design being used to exercise OI Standalone, OI Link, OI Protocol, OI Power, and the stack/service-power model.
3 channels0.8–15 V5 A max/ch20 W/ch60 W aggregateUSB-C PD
OI Base
ConceptAn optional coordination and service-power reference device: USB-to-OI gateway, OI Link termination, trigger generation, and stack power monitoring.
USB gatewayCAN-FD12 V OI PowerTrigger
OI Meter 1
PlannedA compact low-voltage bench DMM concept focused on embedded electronics, logging, and synchronized measurements rather than mains electrician use.
low-voltage bench DMMOI Standalonetriggered capture
OI Basic
ArchitectureA deliberately simple digital/relay instrument intended to be the reference “hello world” implementation for building a new OI-compatible device.
digital I/OrelaysPWM/countersreference firmware
Community
The discussion is live.
The standards are public early on purpose. Use Discussions for ideas, project work, and project-level questions; once something becomes actionable, move it into the repository that owns the work.
📣
Announcements
Project updates and maintainer announcements.
💡
Ideas & Proposals
Early standards, feature, instrument, tooling, and ecosystem ideas.
🙌
Open Instrument Projects
Specific implementations, reference designs, prototypes, and active projects.
💬
Project & Organisation
Roadmap, repositories, standards process, licensing, community, and governance.
Current status
Draft standards. Real implementation work.
Draft 1 captures the architecture as it stands on 16 August 2026. It is intentionally not a claim that interoperability details are finished.
- OI-01 Link: CAN-FD and the pair allocation are established; bit rates, trigger PHY, termination details, and chain limits remain open.
- OI-02 Protocol: capability/state semantics are defined at the conceptual level; the final wire/application foundation is not selected.
- OI-03 Power: 12 V service power and service-alive behavior are established; connector geometry, tolerances, and detailed protection remain open.
- OI-04 Standalone: for an OI-04 claim, USB-C direct access and firmware-independent 5 V recovery are baseline requirements; the canonical host USB framing remains open.
- OI-05 Stack: required OI Link, OI Protocol, and OI Power interoperability plus the no-backplane/service-zone model are established; physical dimensions, airflow, mounting, and connector coordinates still need prototypes.
The standards should emerge from building the instruments.
Reference hardware is not decoration for a finished specification. It is how assumptions get tested. If a rule makes a real instrument harder to use, repair, reproduce, or integrate without improving interoperability, the rule should be challenged.