Smart Logic Decisions

Overview

In this third lesson of “Micro:bit Innovations,” students learn how if/else logic and Boolean conditions let a program make smart choices based on inputs (button presses and accelerometer movement). They build a small Micro:bit “smart light” system and connect logical decisions to real-world engineering constraints.

Learning intentions

Students will be able to:

• Use if/else logic to handle different input conditions in a Micro:bit program.
• Write and test Boolean conditions using true/false logic.
• Predict what a program will do for given inputs before running it.
• Explain how logic helps a device respond intelligently in a real-world scenario (traffic light or vending machine style).

Success criteria

Students can:

• Correctly implement at least one if/else branch responding to a button input and one additional condition responding to accelerometer input.
• Determine the truth of conditions (e.g., “button A is pressed?”) and match it to the correct output behavior.
• Describe in complete sentences how their logic changes the outcome based on the input.
• Debug one problem by identifying which conditional branch produced an unexpected result.

Curriculum links

• Number System — multiplication and division of signed numbers and rational numbers (work supports reasoning with negative/positive quantities used in accelerometer thresholds).
• Number System — understand addition and additive inverses (supports representing “opposite” movement/direction in accelerometer decisions).
• Number System — subtraction as adding the additive inverse (supports rewriting conditions like “magnitude of change”).
• Number System — interpret quotients of integers as rational numbers (supports reasoning about thresholds computed from sensor readings).

Lesson structure (45 minutes)

1. 0–5 min · Hook (Real-world logic). Teacher shows two quick scenarios: “If the button is pressed, a light changes; if not, it stays.” Students do a quick think-pair-share: what actions should happen in each case?

2. 5–12 min · Mini-lesson (if/else + Boolean). Teacher explains: Boolean condition evaluates to true/false; if/else chooses the branch; inputs must be compared to something meaningful (for Micro:bit: button state, accelerometer direction or range). Students complete a 3-question “predict first, run later” worksheet with conditions and expected outputs.

3. 12–22 min · Demo (Smart Light starter). Teacher builds the MakeCode smart light skeleton live:

• Show one output (LED on/off or one color/brightness step).
• Add an if/else for Button A pressed to turn the LED pattern one way, and the else branch for not pressed. Students watch and then answer: “Which condition is true here, and which branch runs?”

4. 22–32 min · Guided build (Add accelerometer condition). Teacher provides a scaffold: students add a second decision using accelerometer (example: “tilt forward/back” using a threshold, or “shake” using a simple movement check). Students implement:

• if accelerometer condition is met, show a “warning” light pattern; else show “normal” pattern. Teacher circulates with a checklist: condition reads clearly, branch outputs match the design, and code compiles.

5. 32–40 min · Rapid test & debug cycle. Teacher instructs a test protocol: choose 2 inputs that should produce different outputs, test, then record results. Students run their programs twice, complete a brief debug log (“Expected / Observed / Fix”).

6. 40–45 min · Exit ticket (Explain logic). Teacher prompts: “Write one sentence for each branch: If ___ is true, then my Micro:bit does ___. If ___ is false, then it does ___.” Students submit on paper or in a digital form.

Resources

• Micro:bit devices (or simulator) and MakeCode accounts prepped
• USB cables or charging stations
• Printed “Predict First” worksheet (3 questions)
• Smart Light starter code handout or a class project template
• Accelerometer threshold reference card (teacher-provided numbers/targets)
• Debug log sheet (“Expected / Observed / Fix”)
• LED pattern cards (e.g., normal vs warning visuals)
• Timer for test/debug cycle

Assessment

• Formative checks during mini-lesson predictions (teacher listens for correct truth-branch reasoning).
• Guided build checklist (teacher verifies each group has implemented both an input condition and correct if/else output).
• Exit ticket: must include clear if/else statements matching their code behavior.

Differentiation

• Support:
• Provide sentence frames: “If Button A is pressed (true), then LED shows ___. If it is not pressed (false), it shows ___.”
• Offer a partially completed MakeCode project with placeholders for the accelerometer condition.
• Give a small set of suggested thresholds and pattern choices.
• Extension:
• Students who finish early add one nested conditional: e.g., if Button A is pressed AND tilt is detected, show a special “boost” pattern.
• EAL/SEN:
• Reduce language load by allowing students to fill in blanks from the logic cards and by using icons (true/false, up/down, normal/warning).
• Pair students strategically so one can verbalize reasoning while the other types/clicks blocks.
• Misconception support:
• If students confuse “true/false,” require them to circle which condition is true for a tested input before running the program.