Skip to content

LED diagnostics

Hardware diagnostic

LED diagnostics are part of normal firmware; there is no separate diagnostic preset. Four quick clicks on the primary/state button enter diagnostics on both input profiles. This remains reachable when an S3 bootloader consumes reset-held presses to enter recovery.

With an ordinary gesture-disabled bootloader, the startup sequence also works:

  1. Hold the wearable button while powering up. With web/Wi-Fi enabled and a valid AP password, this requests the usual Wi-Fi recovery mode.
  2. Release the button completely. Continuing the original hold does nothing.
  3. Make the next press a five-second hold. The diagnostic starts once, and releasing this hold does not toggle power or leave recovery.
  4. Single-click to resume animations. The current radio mode remains selected.

A shorter first press after the boot release cancels the diagnostic sequence; later holds use the normal profile mapping (brightness on single-button profiles, radio switching on v2 button 1). The sequence also works when web/Wi-Fi is compiled out or no AP password is configured, and needs a configured wearable button.

Diagnostics use saved topology and normal brightness/current limits without changing persistent settings. The recovery AP remains usable during diagnostics. Raw acceleration/gyro and filtered tilt/energy print at 1 Hz; button events are logged.

The repeating cycle has no full-white phase:

  1. Left purple only, 1.5 s; right remains black.
  2. Right pink only, 1.5 s; left remains black.
  3. Both red, green, then blue, 1.5 s each, with corresponding serial labels.
  4. One purple pixel walks around the left outline, then the right, 350 ms per pixel.
  5. Both black for 1 s; repeat.

Walking starts at the short-edge base, passes the tip, and ends at the long-edge base; serial logs identify each coordinate. A zero-count ear skips its walk phase. Effects and diagnostics render at 50 Hz; normal output targets 500 Hz for WS2812 temporal dithering. Off and update modes stop ordinary frame transmission. With WS2812, each ear has a dedicated native RMT channel. The render owner prepares both payloads, launches both channels, then waits for both to complete; their wire transmissions overlap. Starts have a small software dispatch skew, so this is not hardware-synchronised latching. The channels stay enabled between frames; flash/settings work waits for completed output. Ear RMT transfers use no DMA. The managed led_strip component still handles the one-time boot matrix clear; its blocking refresh API is not used for the ear outputs. The ear backend stores 24 pre-encoded RMT symbols per pixel plus one reset symbol, in internal RAM for IDF's copy encoder. At 18+18 pixels the symbol buffers total 3,464 bytes; at 64+64 they total 12,296 bytes, plus handles/driver allocations. The copy encoder and TX interrupt retain their configured IRAM placement.

Single-click exits diagnostics without rebuilding or reflashing. Power-cycling with the button released also returns to normal startup. Keep existing local diagnostic configs/build directories if needed; they are ignored and no longer have presets.