10 Hardware Components: Selection Evidence
10.1 Start With the Decision
A sensor board may pass on a short lead and fail beside a motor. A part choice must include its supply, interface, and site.
10.2 Route Overview
This is part 1 of 2. Continue with Hardware Components: Power and Load Integration.
10.3 Part Objectives
- Record part, board, firmware, supply, and enclosure versions.
- Accept sensors and modules with bounded bench evidence.
10.4 Chapter Roadmap
- In 60 Seconds
- Start With the Story
- Overview: Components Carry Assumptions
- Accept Parts With Bench Evidence
- Modules Hide Circuit Choices
- Phoebe’s Field Notes: Two Things a Shopping List Cannot See — Parallel Ohms and Antenna Gain
- Component Selection Route
- A Part Number Is Not a Design Decision
- Sensor Selection
10.5 Start With the Story
A component list can make a prototype feel designed before anything has been measured. A temperature sensor, relay board, level shifter, radio module, and battery holder each carry hidden assumptions about voltage, timing, current, calibration, protection, and failure state. The story starts when the team proves each assumption with a small bench record instead of trusting the part number.
Use this chapter to turn selection into acceptance. A component joins the prototype only after its interface, power path, limits, and evidence record match the decision the build is supposed to answer.
10.6 Overview: Components Carry Assumptions
Every selected component brings assumptions about voltage, current, timing, calibration, noise, physical placement, supply quality, and firmware behavior. A prototype is safer when those assumptions are tested before the component is buried inside the full system.
Inspect Need and Interface in Figure 10.1 for overview: components carry assumptions. Before acting on overview: components carry assumptions, anchor the review at Need and Interface in it. The comparison reaches decision.
Read Need with Interface in Figure 10.1 for overview: components carry assumptions. Review it from the Need field to Interface, then the decision disposition. Both Need and Interface need evidence. That is the review order required by overview: components carry assumptions.
The selection decision is not complete when the part arrives. It is complete when the team can show why the part fits the requirement and what evidence proves it in this design.
Consider a greenhouse logger built from an ESP32 development board, an SHT31 temperature and humidity sensor, a capacitive soil-moisture probe, a microSD card module, a single-cell LiPo charger board, and a small pump controlled through a MOSFET. A shopping-list review might say all of those parts are common in hobby prototypes. A component review asks harder questions. Does the SHT31 board already include I2C pull-ups, and are those pull-ups tied to the same 3.3 V rail as the ESP32 pins? Does the soil probe output stay inside the ADC input range when the battery is freshly charged and when the cable is wet? Does the microSD module draw a write-current burst that resets the controller during a radio transmit? Does the pump’s startup current require a separate 5 V rail, flyback protection, or a local bulk capacitor? Those are component questions before they are system questions.
This is why the same named part can be acceptable in one prototype and rejected in another. A BME280 breakout may be fine for a classroom enclosure with a short harness and stable 3.3 V rail, but weak for an outdoor node where condensation, solar heating, cable strain, and enclosure airflow dominate the measurement. A relay module may switch a bench lamp cleanly, but still be the wrong choice near a battery node if its coil current, default state, and contact wear create support risk. Component selection is therefore a traceable argument: requirement, candidate, boundary conditions, bench evidence, and decision.
10.7 Accept Parts With Bench Evidence
Use the bench to separate component risk from system risk. A short standalone test often finds mistakes that are difficult to diagnose after sensors, radios, batteries, and actuators are combined.
- Electrical proof: check voltage levels, maximum current, pull-ups, protection, startup behavior, and whether the controller pin is allowed to drive or read the signal.
- Interface proof: confirm analog range, bus address, baud rate, timing, cable length, interrupt behavior, and expected failure response.
- Power proof: measure active, idle, startup, and load-transition current instead of relying only on a table value.
- Record proof: save part number, module variant, wiring, library version, test sketch, raw readings, photos, and the decision that the test supports.
A practical acceptance sequence starts with the component alone, then adds one neighboring boundary at a time. For a digital sensor, power it from a current-limited bench supply or known-good rail, confirm the address with an I2C scanner, record the raw reading, and change one physical condition so the reading responds in the expected direction. Then add the real cable length, enclosure position, and any neighboring I2C device. If errors appear only after the longer harness is installed, the evidence points toward pull-up value, bus capacitance, cable routing, shielding, or firmware timeout behavior rather than a vague “bad sensor” conclusion.
For an actuator path, test the load without the microcontroller first. Measure stall or startup current, confirm the driver rating, and check whether the controller rail moves when the load switches. A 5 V pump driven through a logic-level MOSFET might need a flyback diode, separate wiring for the load return path, and a local capacitor near the pump supply. An oscilloscope trace of the 3.3 V rail during startup is stronger evidence than a firmware log that says the command was sent. The acceptance record should name the exact pump, driver board or MOSFET, supply, protection part, wiring length, measured current, and safe state after reset.
For communication modules, the bench proof must include provisioning and antenna behavior, not only a successful library example. A LoRaWAN module should show join time, RSSI/SNR metadata, spreading factor, transmit current, and gateway placement notes. A Wi-Fi module should show reconnect behavior after access-point loss, credential-reset behavior, and current draw during connection setup. Accepting a component means the next person can repeat the evidence path, not merely believe that the demo once worked.
10.8 Modules Hide Circuit Choices
Inspect Micro-USB socket and B+ and B- pads in Figure 10.2 for modules hide circuit choices. To make modules hide circuit choices reviewable, locate Micro-USB socket beside B+ and B- pads on it. Keep OUT+ and OUT- pads with the decision.
Read Micro-USB socket with B+ and B- pads in Figure 10.2 for modules hide circuit choices. Read its setup by locating the Micro-USB socket, then the B+ and B- pads and OUT+ and OUT- pads. The pictured OUT+ and OUT- pads makes setup reproducible. Use B+ and B- pads to assign evidence ownership in modules hide circuit choices.
Breakout boards and ready-made modules may include regulators, level shifters, pull-up resistors, filters, protection parts, address jumpers, or default firmware. Those hidden choices can help a prototype, but they can also mask a design problem that returns when the team moves to a PCB or a different supplier.
Treat each module as a circuit with evidence, not as a black-box accessory. The handoff record should state which behavior belongs to the component, which behavior belongs to the support circuit, and which behavior still needs verification before production-style integration.
The hidden circuit matters because modules often solve a problem in a way that is only visible on the schematic. Many I2C sensor breakouts include pull-up resistors. If two or three modules each add pull-ups, the combined resistance can make the bus too strong for a long cable or low-power node. Some “5 V compatible” boards use level shifters; others simply rely on a sensor that tolerates the voltage on one pin but not another. Some microSD modules include a regulator and resistor divider, which can make a classroom demo easier while increasing current draw, slowing signal edges, or hiding the fact that the final design needs a native 3.3 V part. A component record should capture these support-circuit choices, not only the sensor or module name.
Power modules have the same issue. A TP4056-style charger board, a boost converter, and a small LiPo cell can make a portable prototype appear straightforward, but the real behavior depends on charge-current setting, load sharing, undervoltage protection, regulator dropout, switch leakage, and how the system behaves during USB plug-in or battery removal. A current monitor such as an INA219 or a bench supply readout can reveal whether the radio transmit burst, SD-card write, or actuator pulse exceeds the power path. Without that evidence, firmware teams may chase resets that are actually rail and layout problems.
Actuator modules also hide design choices. Relay boards may include transistor drivers, optocouplers, indicator LEDs, pull-downs, or active-low inputs. Motor-driver boards include current limits, thermal shutdown behavior, braking modes, and fault pins that should be wired or at least recorded. Moving from a module to a PCB means those decisions become the team’s responsibility. The under-the-hood question is therefore: which behavior did the component provide, which behavior did the support circuit provide, and which behavior must be preserved when the prototype becomes a durable design?
10.9 Learning Objectives
By the end of this chapter, you will be able to:
- Select sensors from measurement requirements, environmental constraints, interface fit, and calibration evidence.
- Choose actuators and load drivers by starting from the load, not from the controller pin.
- Compare communication modules by provisioning, antenna, energy, data path, and deployment constraints.
- Review power, protection, and level-shifting parts before connecting mixed-voltage subsystems.
- Assemble a practical bench workflow for verifying components before full-system integration.
10.10 Component Selection Route
Every component decision should move through the same review route: requirement, electrical fit, interface fit, power fit, bench proof, and record. Skipping the early gates creates prototypes that appear to work briefly but fail when the wiring changes, the battery is added, or the enclosure is closed.
The route is intentionally simple. It keeps the review conversation focused on evidence instead of preference:
Part numbers, module names, and breakout-board photos are weak evidence by themselves. The design decision is the documented reason the component meets the prototype requirement and the test that proves it works in this system.
10.11 Sensor Selection
Sensors turn physical conditions into electrical signals. The right sensor is the one whose evidence matches the measurement task, not the one that appears most common in example projects.
10.11.1 Sensor Evidence Map
Review sensors across five evidence lanes before wiring them into a prototype.
Inspect Sensor under review and bus address and pins in Figure 10.3 for sensor evidence map. At the decision point in sensor evidence map, use it to distinguish Sensor under review from bus address and pins. The conclusion depends on raw to units.
Read Sensor under review with bus address and pins in Figure 10.3 for sensor evidence map. Work through it from the Sensor under review field to bus address and pins, then the raw to units disposition. Both Sensor under review and bus address and pins need evidence. Preserve the raw to units condition in the handoff for sensor evidence map.
10.11.2 Reading a Sensor Spec Sheet
The five evidence lanes above have to come from somewhere. For most sensors, the primary source is the manufacturer’s spec sheet, and reading it well is a distinct skill from reading a product-page summary or a marketplace listing.
- Header block: the part number, revision letter, and publish date confirm the document matches the exact silicon on the bench. A revision change can move a spec row without changing the marketing name.
- Product description: a short paragraph naming the sensing principle (capacitive, piezoresistive, thermal, optical, and so on), the package, and the supply range. This is where mounting orientation, moisture sensitivity, and package footprint start.
- Specification table: the real evidence. Parameters are usually reported as Minimum, Typical, and Maximum rather than one number, because manufacturing spread is real, and the table states the exact supply voltage and temperature the numbers were measured at.
- Measurement conditions: the fine print above or beside the table tells you whether a spec still holds at your rail voltage and enclosure temperature, or whether it needs re-verification on the bench.
A ±2 g tri-axis analog accelerometer spec sheet makes the pattern concrete. Its specification table lists sensitivity as 560 mV/g typical, with a guaranteed range of 543 to 577 mV/g; a firmware calibration routine built only around the typical value will read low or high on parts near either edge of that range. The same table lists zero-g offset as 1.4 V typical between 1.26 and 1.54 V, an operating temperature range of -40 to 85 degrees C, a supply range of 1.8 to 3.6 V DC, and a noise-density figure that bounds achievable resolution more directly than the full-scale range does. None of those rows are optional reading: the offset and sensitivity ranges feed the calibration-fit question, the temperature range feeds the environment-fit question, and the supply range feeds the power-fit question this chapter already asks.
Treat the spec sheet the way this chapter treats a breakout module: as a source to extract evidence from and cite in the acceptance record, not a document to file away once the part is ordered. A component record that says “560 mV/g, 1.8-3.6 V, -40 to 85 degrees C, per the current datasheet revision” is stronger evidence than a record that only names the part.
10.11.3 Sensor Families
Use families as starting points, then verify the specific component.
- Environmental sensing covers temperature, humidity, pressure, light, gas, particle, and fluid conditions. These sensors often need placement and calibration review.
- Motion and position sensing covers acceleration, orientation, vibration, rotation, distance, and presence. These sensors often need mounting and noise review.
- Electrical sensing covers voltage, current, resistance, state, pulse counting, and power monitoring. These sensors often need isolation and measurement-range review.
- Human input sensing covers buttons, switches, touch pads, encoders, and proximity controls. These sensors often need debounce, accessibility, and enclosure review.
10.11.4 Sensor Review Questions
- What decision will the system make from this reading?
- What range and resolution does that decision actually need?
- What are the worst environmental conditions during the prototype test?
- How will the team know whether a suspicious reading is a sensor problem, placement problem, wiring problem, or firmware problem?
- What raw evidence should be saved before the component is accepted?
10.12 Continue to the Next Part
Carry this evidence into Hardware Components: Power and Load Integration, which begins with Actuators and Loads.