What students build
- A waiting state
- Random start delay
- Visible go signal
- Button response
- Measured elapsed time
- Early-press and restart rules
Guided Class Project
Guided Class Projectmicro:bit Reaction Timer
Wait for an unpredictable signal, press as quickly as possible, and make the timer distrust suspiciously early presses.
Visible system / hidden curriculum
Build something clear enough to test.
What students learn
- Microcontroller input
- Elapsed time
- Random delay
- State
- Fair tests
- Measurement limits
What students need
- Physical version requires a micro:bit and suitable connection method
- A browser micro:bit simulator can support logic work
A physical version requires a micro:bit; availability is confirmed before class. The logic can be introduced in a compatible simulator when hardware is not part of the session.
Suggested build order
Decisions and checkpoints, not a wall of copied blocks.
Students may use different artwork and implementation details. The shared structure keeps the concept teachable.
- 01
Create the waiting state
Task: Show that the test is ready but not started.
Build and test this part before adding the next system.
- Checkpoint
- Button presses have a defined waiting result.
- Likely mistake
- The timer begins immediately.
- 02
Add random delay
Task: Wait an unpredictable but bounded amount.
Build and test this part before adding the next system.
- Checkpoint
- Several runs use different delays.
- Likely mistake
- The delay range includes unusable values.
- 03
Show the go signal
Task: Record start time and display a clear cue.
Build and test this part before adding the next system.
- Checkpoint
- The cue and start timestamp happen together.
- Likely mistake
- Timing begins before the cue.
- 04
Measure the response
Task: Read the button and calculate elapsed time.
Build and test this part before adding the next system.
- Checkpoint
- A plausible result is displayed once.
- Likely mistake
- Repeated button input overwrites the result.
- 05
Handle early presses
Task: Detect a press before GO and reset fairly.
Build and test this part before adding the next system.
- Checkpoint
- Cheating or mistakes produce a clear state.
- Likely mistake
- An early press is counted as a perfect score.
Test it
Try the edges, not only the easy success.
- Can the same random delay repeat?
- What happens on an early press?
- Can holding the button trigger GO?
- Is time measured in the intended unit?
- Does a new test clear the old result?
Common mistakes
Read the clues before changing code.
- Start time is recorded too early.
- Button state carries into the test.
- Units are mislabeled.
- Old results remain active during restart.
Improve it
Preserve the core system while changing the project.
- Store several attempts.
- Show best and average results.
- Add false-start count.
- Compare two input methods and discuss fairness.
Challenge levels
Choose meaningful difficulty.
Builder
Produce one reliable reaction measurement.
Inventor
Store and compare three attempts.
Boss Level
Design a fair two-player protocol and explain its limits.
Show-teacher checkpoint
Demonstrate the working decisions.
- Waiting state
- Random delay
- Synchronized start cue
- Measured response
- Early-press handling
- One fairness limitation