API
Protocol Reference
Documented data protocols, serial interfaces, and extension APIs for building compatible accessories, surface displays, and dive planning integrations.
Inter-Board Communication
rebus — rebreather bus
rebus is a community effort to define a CAN-bus-based communication layer that makes rebreather electronics truly interoperable. Any vendor can build a board that speaks rebus and plug it into an openCCR system. The specification is developed openly in openccr/docs and governed by the community.
Why rebus?
Most rebreather electronics use proprietary internal buses, meaning head controllers, HUDs and computers from different vendors are incompatible by default. rebus exists to change that. It is an openCCR community initiative to define a shared, open communication standard for rebreather modules and their communication — so that any rebus-compatible board, from any builder, can participate in the same system.
CAN Bus Foundation
rebus is built on CAN bus, a differential serial standard proven in automotive and industrial applications. CAN provides inherent noise immunity, multi-node addressing, and hardware-level error detection — properties that make it well-suited for safety-critical embedded systems. Precise electrical parameters such as baud rate, termination, and topology are being defined in the community specification.
Open Message Registry
Above the physical layer, rebus defines a message format and an open registry of message types — the shared vocabulary boards use to exchange oxygen readings, control commands, alarm events, display updates, and diagnostic data. The registry is community-governed: any contributor can propose new message types for new device categories, with the full registry maintained in openccr/docs.
Safety & Fault Tolerance
Because rebreathers are life-support equipment, the rebus specification will define how the system behaves when nodes fail: how faults are detected, how alarms are broadcast across surviving nodes, and how the system degrades gracefully. These safety behaviours are as much a part of the standard as the frame format, and will be developed through community review and open discussion.
Build Your Own Compatible Hardware
Any hardware developer can build a rebus-compatible board. The specification will define exactly what a conforming node must implement: how to join the bus, how to register its capabilities, and how to exchange data with the rest of the system. Reference implementations and integration guides are maintained in openccr/docs to make third-party development straightforward.
Work in Progress
rebus is actively being specified. The community is working through physical layer parameters, frame formats, addressing schemes, and the initial message type registry. If you build rebreather electronics or safety-critical embedded systems and want to help shape the standard, contributions are welcome in the openccr/docs repository.
Repository — openccr/docs
Documentation & API Reference
The openccr/docs repository is the authoritative source for all
openCCR documentation: protocol specifications, integration guides, safety analysis,
and the companion app API. Licensed under CC BY 4.0.
rebus Protocol Specification
Full normative specification for the rebus protocol. Covers physical layer, frame format, message type registry, addressing scheme, timing requirements, fault detection, and bus recovery procedures. Includes worked examples and oscilloscope waveform references.
Companion App API
Command protocol used between the companion app and the openCCR device over BLE. Documents all configuration read/write commands, calibration procedures, log transfer protocol, and firmware update sequence. Enables third-party app developers to build compatible tooling.
Safety Analysis (FMEA)
Failure Mode and Effects Analysis documents for each subsystem. Identifies single-point failures, their effects on diver safety, detection mechanisms, and mitigations applied in hardware and firmware. Required reading before modifying sensor, control, or alarm subsystems.
Data Formats
Dive Log Schema
openCCR log files are transferred from the device via the companion app and exported in three formats. Schema definitions are in openccr/docs.
openCCR Binary
Native on-device format. Fixed-width records at the configured sample rate. Each record: 4-byte Unix timestamp, 2-byte depth (cm), 3× 2-byte cell millivolts, 2-byte voted PO₂ (mbar), 1-byte setpoint (mbar × 10), 1-byte solenoid state, 1-byte alarm bitmask, 1-byte temperature (°C + 40 offset). Records are appended sequentially; the log header contains device ID, firmware version, and calibration constants.
CSV Export
Human-readable comma-separated export generated by the companion app from the binary log. Column headers match the binary record fields. Suitable for import into spreadsheet tools and Python/R analysis environments. Includes a metadata header block with dive summary statistics (max depth, bottom time, min/max PO₂, alarm count).
UDDF Export
Universal Dive Data Format export for compatibility with third-party dive log software (Subsurface, DiveLog, MacDive). Maps openCCR log fields to the UDDF 3.2.2 schema.