A prototype light can say ready, waiting or action received. It can also become decoration that leaves the user unsure what happened. Before choosing a brighter lamp or more pixels, decide which state the person needs to recognize.
Interactive games such as the Reflexes Machine described by Arduino in September 2026 give physical feedback a specific role. On our bench we tried three smaller options: a switched LED module, a high-power LED module behind a driver, and a 64-pixel WS2812 matrix, on RP2040 boards with MicroPython programs built in BIPES.
Start with an unambiguous on and off
The simple LED program set GPIO7 high, waited four seconds and set it low. A second version repeated one second on, one second off. These are enough to test whether a state change is visible from where the user will stand.
Our notes for this test had one mismatch worth admitting: the code capture filed under the blink example actually showed a PWM ramp from a later test. We describe the blink blocks as written, and do not treat that capture as verifying them.
The PWM version stepped a 1 kHz duty command upward by 10000 and reached 60000. It is one increasing ramp, not a fade up and down. A duty proportion also does not equal perceived brightness, so equal duty steps should not be assumed to look like equal brightness steps.
A driver brings power and heat questions
The high-power LED module has its own driver. Its program used GPIO6 at 1 kHz and raised the duty value by 200 every half second, ending at 8000. On the 16-bit duty_u16 scale, 8000 is about 12.2% of the command range. That is not full brightness, and the test is not a demonstration of maximum light output.
We did not measure illumination, temperature or behavior inside a housing. Those matter more than the code. If the light is a status indicator, first establish that it is noticeable without glare. If it is meant to illuminate a task, that is a different optical and thermal requirement, and the driver, the LED's heat path and the enclosure all have to be checked together.
Pixels need an indexing rule as well as a color
The WS2812 program declared 64 pixels on GPIO21 and set successive entries to red. Earlier entries were not cleared, so the effect is a progressive fill, not a single moving dot.
The loop also ran one step too far. For 64 pixels, valid zero-based indices are 0 to 63, but the generated code used range(65), so the last pass tried to write index 64. The fix is to loop over 0 to 63:
for i in range(64):
np[i] = (255, 0, 0)
np.write()
We have not yet run that corrected loop on the hardware, and the partial console output we have should not be read as a completed cycle. An addressable array also has power requirements of its own; data control and supply both need to be planned, especially at higher brightness with many pixels lit.
Choose the least complicated output that reads clearly
For each state the user must recognize, write down:
- what the light does (on, off, blink rate, color, position);
- how long it stays that way;
- what ends it.
Then test it where it will be seen: through the intended diffuser or window, at the real viewing distance and in the room lighting of the trial. A steady, single-color indicator is often easier to understand than an animation. If two states look similar from three meters away, change the pattern, not the code that drives it.
Only after the states read clearly is it worth picking a brighter part or a larger matrix, and at that point the driver, power budget and heat in the closed enclosure become the main engineering questions.