All Technical Articles
HardwareSensing

Inside the Sensor Cell: RRS-01 Hardware

By Engineering — Hardware · March 12, 2026 · 10 min read

Each sensor cell is a small, sealed, deterministic device. Here is what is on the board, why each part is there, and what we threw out before we got to v3.

The hardest part of designing the RRS-01 sensor cell was deciding what to leave out. Every additional component is another failure mode in a marine environment. The current revision is the third major board spin, and most of the work between v1 and v3 was subtraction.

What is on the board

  • 4-channel non-contact IR temperature array (16-bit, factory-calibrated).
  • A small ARM Cortex-M MCU for cell-local averaging and protocol handling.
  • EtherCAT slave controller (hardware, not software-emulated).
  • Conformal coating, sealed enclosure, IP66.

What we removed between v1 and v3

  • Local SD card for buffering — replaced by upstream retention at the segment master.
  • Status LEDs on the device — they were never visible behind installed vehicles.
  • A second microcontroller for redundancy — added more failure modes than it removed.
A simpler device is a more reliable device. We carry that bias hard.

Why hardware EtherCAT, not software

Deterministic sub-microsecond behavior on the bus is not achievable from a general-purpose microcontroller. The dedicated EtherCAT slave controller is non-negotiable for the timing guarantees we offer.

Frequently asked

Questions, answered

What is on an RRS-01 sensor cell board?+

A 4-channel non-contact IR temperature array (16-bit, factory-calibrated), a small ARM Cortex-M MCU for cell-local averaging and protocol handling, a hardware EtherCAT slave controller, and a conformal-coated, sealed IP66 enclosure. It is a small, sealed, deterministic device by design.

What was removed between v1 and v3 of the sensor cell?+

A local SD card for buffering (replaced by upstream retention at the segment master), status LEDs (never visible behind installed vehicles), and a second microcontroller for redundancy (it added more failure modes than it removed). Most of the work between v1 and v3 was subtraction — a simpler device is a more reliable device.

Why use a hardware EtherCAT slave controller instead of software emulation?+

Deterministic sub-microsecond behaviour on the bus is not achievable from a general-purpose microcontroller. The dedicated hardware EtherCAT slave controller is non-negotiable for the timing guarantees the system offers.

Related reading

Continue the thread