Defined the Gaia 300 LED behaviour

Gaia 300 is a wireless concrete-monitoring transmitter designed for harsh field environments. The three LED indicators on the front of the device are the primary feedback mechanism for site teams in the field, communicating device status, connectivity, and errors without requiring a phone or app.

Three LEDs. One device. A full set of states to communicate: standby, configuration mode, monitoring, Bluetooth availability, low battery, data transfer, connection status, and errors. Each pattern had to be readable at a glance in the field, technically feasible for the hardware team to implement, and clearly distinguishable from every other pattern under real conditions. Defining the spec was one challenge. Getting it implemented exactly as specified was another.

I started by mapping every device state before designing any pattern, working from the hardware behaviour I had already documented in the Gaia 300 user flow. The states covered the full device lifecycle: sleep, wake-up, configuration, cable connection, monitoring, Bluetooth on and off, connection in progress, connected, data transfer, transfer error, disconnect, and return to sleep.

For each state, I defined the colour, the pattern, the timing, and what it needed to be distinguishable from. Green communicates device activity and cable status. Blue communicates Bluetooth availability. White communicates active connection and data transfer. Red communicates low battery and errors. The three LEDs map directly to the three thermocouple channels, so a user can see at a glance which cables are connected and which are not. I documented the full specification in Figma with annotated diagrams for each state, defining the LED sequence, timing values, and trigger conditions. That document became the reference for the hardware team during implementation. When the first build came back, I tested the behaviour against the spec and fed back on timing gaps, blink speeds, and pulse durations that did not match. We went through several rounds before the implementation was correct.

Print documents

In parallel, I wrote and designed the Quick Start Guide and the one-pager, both of which shipped in the box with the device. The Quick Start Guide covers the full setup process: battery installation, app download, configuration, thermocouple connection, Bluetooth connection, and data sync, with step-by-step instructions, annotated app screenshots, and a full LED reference table. The one-pager distils the Configure-Connect-Sync flow into three steps for users who need a fast reference onsite. Both documents use the Maturix brand language and visual system, and both reference the LED behaviour, so the print and hardware communication reinforce each other.

The LED behaviour shipped with the Gaia 300 hardware. The real work was not just defining the patterns: it was holding the hardware company to spec through multiple feedback rounds, testing each build against the documented behaviour, and feeding back until the implementation matched exactly. The Quick Start Guide and one-pager shipped in the product box, covering the full setup journey from unboxing to first data sync.