Prepare a reliable school electronics demo

Turn a breadboard prototype into a clear demonstration with repeatable tests, honest claims and a backup plan.

Start by writing one sentence describing what the audience should observe. A touch-controlled servo shows event detection and position commands; it does not prove a door lock is secure. A PIR timer demonstrates output timing; it does not prove occupancy. Keeping the claim precise makes both the explanation and testing easier.

Make a parts checklist from the project, then list extras separately: the correct USB data cable, a laptop, a regulated external supply, matching power connectors and any mounting materials. A product cart may enforce minimum quantities, and an adapter may not include a barrel breakout. Confirm the actual connectors before presentation day.

Verify the prototype on a desk using only low voltage. Inspect polarity and module labels with power removed, then power one subsystem at a time. For the servo demo, keep its external positive separate from the USB-powered UNO 5V pin while sharing ground. Use an unloaded horn and keep fingers clear.

Prepare five short tests: startup, normal operation, a held input, a missing input, and reset/recovery. Write down the expected indicator or message for each. A reaction game should reject a false start; an ultrasonic demo should identify a missing echo. Showing one failure case often teaches more than showing only a perfect run.

Label signal wires or keep a wiring table with pin, destination and voltage. Secure the board and power connector so a loose wire does not spoil the demonstration. Keep a spare data cable, saved sketch and printed instructions. Do not depend on live internet access to retrieve code during the event.

Rehearse a two-minute explanation: the problem, input, decision, output and one limitation. Let someone who did not build it try the controls. If they press and hold when you expected a tap, improve the instructions or event handling. Prefer understandable behavior over adding features at the last minute.

Finish with measurements or observations, and distinguish software checks from physical tests. A successful compile does not verify wiring, sensor performance or supply current. These RoboXol examples have software logic checks, not physical board verification. Extend them with recorded hardware test results before presenting them as proven builds. References for board examples and libraries: https://docs.arduino.cc/built-in-examples/