Micro:bit Sound Player

Overview

In this lesson, students learn how the micro:bit can produce sound and create a simple sound player controlled by button presses. Students will plan and organize information for a short “how it works” explanation, then test and troubleshoot their program.

Learning intentions

Students will be able to:

• Create a micro:bit program that plays a sound when a button is pressed.
• Use variables or structured logic to manage sound selection (e.g., mapping button A/B to different tones).
• Record the ordered steps of their build so someone else can understand and replicate it.
• Present and explain their solution clearly using visuals or on-screen information.

Success criteria

• I can write a program that plays at least one sound from button A and a different sound from button B.
• I can explain what each part of my program does in the correct order.
• I can troubleshoot when my sound does not play as expected and make a fix.
• I can share my program using a simple presentation with a graphic or chart.

Curriculum links

• Writing: organize ideas and include formatting/graphics to clarify meaning (CCSS.ELA-LITERACY.WHST.6-8.2a).
• Use variables for real-world relationships and write equations to represent them.
• Evaluate expressions at specific values when using formulas or parameter choices (CCSS.MATH.CONTENT.6.EE.A.2c).
• Include multimedia/visual displays in presentations to clarify information.

Lesson structure (45 minutes)

1. 0–5 min · Hook & model. Teacher plays a quick “button-to-sound” demo and asks: “What do you notice about what happens when you press each button?” Students turn-and-talk, then share one observation.

2. 5–12 min · Direct teach: sound blocks. Teacher shows the micro:bit blocks for producing sound (e.g., tones and simple melodies) and demonstrates button-triggered events (Button A / Button B). Students identify which blocks are events vs. sound actions and write a one-sentence summary.

3. 12–20 min · Plan with an organizer (writing). Teacher provides a simple template: “Goal → Buttons used → Sounds chosen → Steps → Troubleshooting.” Students fill it in for their own program before coding, using brief headings and at least one visual idea (like a small table mapping button to sound).

4. 20–31 min · Build & code sprint. Teacher circulates with targeted questions: “Which button triggers which sound?” “Do you need a variable or simple logic to switch sounds?” Students code in pairs, aiming for: button A plays Sound 1, button B plays Sound 2, and both are audible after downloading.

5. 31–37 min · Math connection mini-check (optional but quick). Teacher asks students to consider a parameter they can change (like tone frequency or tempo setting) and how changing an input affects an output. Students complete one short check: pick two settings and predict which sounds will feel “higher/lower” or “faster/slower,” recording it as an ordered pair or “if input then output” statement to connect to dependent/independent variable thinking (no long equations required).

6. 37–44 min · Share with visual explanation. Teacher asks pairs to present for 45–60 seconds using a poster or slide with: a diagram/table of button-to-sound mapping and a 3-step explanation. Students present and the audience gives one “I noticed…” and one “Try this…” comment.

7. 44–45 min · Exit ticket (quick assessment). Students answer on paper or in a form: “Which block starts the sound?” “What triggers each sound?” and “What is one troubleshooting step you used or would use?”

Resources

• micro:bit devices (paired use: 15 micro:bits if possible)
• computer stations with micro:bit editor (offline or classroom network)
• charging/download cables or USB ports
• printed planning template (Goal/Buttons/Sounds/Steps/Troubleshooting)
• simple presentation slide/poster template (button-to-sound table)
• headset or speaker option (if needed for clear audibility)
• exemplar demo screenshot (teacher-provided)

Assessment

• During build sprint: teacher checks button A/B triggers and confirms sounds play on the first try or after one fix.
• During planning: review organizer for clear mapping of buttons to sounds and a logical step sequence.
• Exit ticket: verify students can identify the event trigger and explain at least one troubleshooting step.

Differentiation

• Support: provide sentence starters for the organizer (“When I press Button A…”, “My sound does not play because…”, “I fixed it by…”). Offer a partially completed template with button mappings pre-made.
• Support: for students who need extra structure, give a “base code” that already includes button events, and students only choose sound blocks.
• Extension: challenge students to add a third option (pressing reset or adding a sequence/melody) and explain how their logic changes.
• EAL/SEN: allow students to use a diagram (arrow chart) instead of long written explanations; permit oral responses for the exit ticket if needed.