Physical computing connects instructions with elements of the material world. An input supplies information, such as a button’s state or a movement reading. The controller runs the program that interprets that value. An output communicates or causes an effect: lighting an LED, showing a symbol or moving a mechanism. A sensor obtains information about a physical feature; an actuator produces a physical effect. These roles are related but not interchangeable. A connected component is not necessarily being read by the program, nor does its presence guarantee a prepared response.

The input, processing and output chain describes information. Power supplies energy for operation and should be represented separately in connection drawings. A USB cable can serve both purposes, but receiving energy does not prove that new code was transferred. Before assembly, identify the change you want to detect and who will interpret the result. An output can be technically correct yet unhelpful if nobody understands its alert. The functional diagram helps review the idea without confusing component count with solution quality.

The micro:bit integrates an LED matrix, buttons and sensors we can program in MakeCode. Board version matters: a built-in microphone and speaker are available on versions that include them, not on every micro:bit. Identify the available equipment before choosing inputs and outputs. In MakeCode, on start prepares a response once, while button events run their instructions when triggered. A simple starting symbol helps check that we recognize the environment and know what should appear at startup.

The simulator represents the board and lets us change inputs to test logic. It does not check power, cables or every physical component’s behavior. Transferring loads code onto the board using the classroom procedure; it must then be tested there. A charge-only cable may supply energy without carrying data. If old code remains, inspect the file and transfer before rebuilding the algorithm. Keep a copy you can reopen in MakeCode and check its contents. A filename or photograph does not guarantee that the latest version was saved.

A reading is the value obtained when we query an input. The micro:bit uses part of its LED matrix to detect light, represented by MakeCode from 0 to 255. This is a relative reading scale, not a measurement in lux. Orientation, shadows and location affect the result. MakeCode’s reference warns that the first query returns zero while light sensing is activated; inspect subsequent readings before concluding that it is dark. An initial zero and a later measured zero need context.

Temperature is estimated from the processor’s sensor and expressed in degrees Celsius, but this does not make the board a clinical thermometer. The accelerometer provides acceleration information and supports gesture detection; a shake does not describe every exact position. If the model includes sound input, check what its scale represents before assigning units. Collect several readings under similar conditions. Five per condition reveal variation and possible overlaps. The table must explain how each value was obtained and distinguish physical measurement from simulator controls.

A threshold is a value we choose to separate cases and give each one a different response. The comparison determines the boundary: if we ask whether a reading is less than the threshold, an exactly equal value does not satisfy that condition. It belongs to the other alternative. An if / else structure assigns a response to both cases. Understanding this relationship lets us explain behavior at the boundary instead of leaving equality without a planned decision.

The chosen value needs justification. In the numerical trial we use 50 and check 49, 50 and 51 to investigate the rule with known inputs. These numbers are simulated, rather than classroom measurements or a setting suitable for every device. The physical threshold is chosen from observed series, with five readings per condition. If the series overlap substantially, a boundary may distinguish them poorly; reviewing measurement conditions helps us understand the problem before changing the number.

As well as comparing correctly, the program needs current information. A variable retains the last value stored: querying the sensor only before forever makes repeated decisions use an old value. Inside the loop, reading, storing, comparing and updating the output connects each response with a new query. A short pause makes the alert easier to observe, but delays that sequence’s next check. Its duration depends on the tested use. This automatic behavior applies a human-written rule; it does not involve training an artificial intelligence model.

Illumination can change gradually even when an alert shows only two responses. To understand this difference, we distinguish the physical feature, the sensor’s signal and the value used by the program. A sensor transforms an environmental variation into a signal: an analog signal represents variation within a range, while a digital signal uses defined states. Querying the input gives us a manageable representation, such as a number. Integer numbers do not mean physical illumination has been reduced to on or off.

The reduction to two cases happens when we apply a rule. Several different readings can produce the same alert because they remain on the same side of the threshold. The number can therefore change while the icon stays the same without anything being faulty. Showing readings helps investigate variation; showing a symbol can help someone understand what to do. The two presentations serve different needs. Keeping trial data lets us justify the decision even when the everyday interface displays only the alert.

Interpreting the value requires knowing the particular input. Its documentation explains the signal it uses and the meaning of its result; analog or digital alone does not specify the voltage a connection accepts. Nor does zero always establish that a device is missing: it may be a valid reading or a documented initial behavior. This information connects environmental changes with what appears on screen and helps us choose a response based on the value’s meaning.

An external component needs suitable power, reference and signal connections for its model. GND is the circuit’s common potential reference. Supply voltage and the permitted signal level are different facts: correctly powering a module does not guarantee that its signal is compatible with the board. Connector appearance or kit brand does not prove compatibility either. The specification must identify the exact reference, connections, adapter and programming environment. Without that information, we cannot draw a connection as though it had been validated.

Motors and servos may require specific power supplies and controllers. A pin sending an instruction does not replace a source capable of delivering the required energy. ACEBOTT stations use only assemblies and adapters reviewed by the teacher. Echidna Black2 uses its own connections and environment; comparing inputs and outputs does not make programs interchangeable. Assemble without power and request review before connection. If compatibility has not been established, use integrated sensors or the prepared independent station and record that alternative.

A prototype is a version for testing an idea before treating it as finished. Begin with a specific need and user: who needs the alert, in which situation and what they should do when they see it. This description gives input and output choices a purpose. A more striking display does not necessarily improve understanding. Symbol, placement and instructions must communicate the alert’s meaning and limits. We can ask another pair to interpret it without first explaining our intention.

Construction also affects operation. A support that changes sensor orientation can alter readings, and a casing can hide the display. Keep controls accessible and avoid forcing parts. Define an improvement and a related test: comprehension for a message change, stability for a placement change. Repeat comparable conditions before and after. Finally, plan disassembly and reuse of the board and materials. Explaining an observed limitation is part of design: distinguishing two tested conditions does not prove that the device works everywhere.

An acceptance test compares a prototype with a requirement written beforehand. One photograph cannot demonstrate that an environmental alert is automatic. Observe at least two conditions and return to an earlier one without restarting. This return helps reveal a stale reading or a stuck program. Record condition, value, expected response, observed response and conclusion. Numerical boundary cases can be tested with known simulated inputs without presenting them as exact physical measurements reproduced on the board.

Evidence must state where each test ran. Simulation investigates logic; the board supplies evidence of material interaction. If equipment is unavailable, document completed and pending work without changing labels. Missing or uninterpretable readings are examined through the prepared procedure, without unplugging powered modules or inventing error values. Debug by changing one cause at a time and repeating the case. A01 combines design and a first physical microtest; A02 includes the device, record, instructions and improvement. Each partner explains the functional chain and a personal decision.