Smart Hex software

The firmware abstracts local hardware so the main controller can consume stable observations. All hexes use the same image; identity and address are assigned during enumeration. The language, toolchain, and libraries remain open.

Sensor processing

Analog processing needs ADC averaging, stable-reading windows, resistance calculation, tolerance bands, insertion/removal detection, and empty/unknown handling. Digital robber detection needs debounce. Thresholds, sample intervals, and stability durations must come from measurements, not arbitrary defaults in this wiki.

Local state contract

HexStatus {
  index
  firmwareVersion
  land
  roads[3]
  buildings[3]
  robber
}

This is an illustrative contract, not a packet layout. Identity readings must distinguish empty and unknown from a recognized piece. Diagnostics should also expose raw ADC readings and inferred resistance, separately from normal compact reports.

OLED rendering

The main controller sends meaning, such as SET_NUMBER 8 or SET_DISPLAY_MODE ROLLED; it does not stream a framebuffer. The hex renders number and probability dots locally:

      8
    •••••

Intended modes include normal number, rolled/highlighted, robber present, setup, error, and updating. Mode precedence, duration, and what happens on communication loss remain to be specified. Prefer a bounded display-memory strategy suitable for the controller.

Lifecycle and errors

Startup initializes local hardware, waits for chain eligibility, accepts runtime identity, and begins reporting. A reset requires coordination with enumeration rather than assuming the previous address remains valid. Malformed commands must not modify output or state partially. Unknown resistor readings should preserve useful diagnostics.

Firmware version should be queryable separately from a future protocol version. Communication timing, error codes, retry behavior, and disconnect timeout belong in the protocol. Calibration storage and firmware updating are future concerns.