Skip to content

CAN protocol

The full specification lives in its own repository, versioned with the firmware:

SAPPHIFY CAN protocol specification

Any team can write its own driver, replay its own logs, or integrate a SAPPHIFY device into a non-WPILib stack from that document alone. No SAPPHIFY software is required and no part of it is withheld. It is CC BY 4.0; implementations are unrestricted.

The closed alternative does not. There is no frame layout, no arbitration-ID reference and no DBC anywhere in CTRE’s documentation — what exists is consumer-level guidance about update frequencies and bus utilisation. That is a reasonable choice for them and a poor one for a team trying to understand what its sensor is actually doing.

Redux publishes theirs too. We are the second open vendor here, not the only one, and being second is still the right side of the line.

Standard FRC 29-bit extended identifiers: device type (5 bits), manufacturer (8), API class (6), API index (4), device number (6). ROTEM uses device type 4, “Gyro Sensor”.

Addressing, health flags, identity, configuration persistence, time synchronisation and firmware update are defined once and behave identically on every SAPPHIFY device. Only the measurement frames differ per product. A team that learns one device has learned all of them.

Every sample is timestamped on-device and published with its data, and a bus-time discipline message lets several devices share one time base. This works on a plain 1 Mbps bus, needs no companion hardware and costs nothing. The achievable precision will be measured and published, not asserted.