7 Selecting and Integrating Components
Choosing sensors, actuators, communication modules, power parts, and bench tools from evidence
hardware component selection, IoT prototype components, sensor selection, actuator drive path, interface compatibility, power components, hardware integration
7.1 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.
7.2 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.
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.
7.3 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.
7.4 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?
Phoebe’s Why
Two of this chapter’s own hidden-circuit warnings are really the same physics lesson told twice. First: resistors on a shared node do not add when there are several of them, they combine in parallel, because each one offers the supply rail an independent path to drain current into the bus. Stack three “harmless” onboard pull-ups from three breakout boards and the bus sees a resistance a third of any one of them, not three times weaker. Second: a radio module’s transmitted power is not the whole story, because an antenna does not create energy, it only reshapes how existing energy spreads through space. A higher-gain antenna concentrates the same transmitter power into a narrower lobe, so two boards with an identical chip setting can radiate a genuinely different effective power depending only on the antenna soldered on – exactly why this chapter insists on “antenna behavior,” not just a working library call, before a communication module is accepted.
The Derivation
Parallel pull-up resistors on one shared node combine by reciprocal sum:
\[\frac{1}{R_{eq}} = \frac{1}{R_1}+\frac{1}{R_2}+\cdots+\frac{1}{R_n}\]
which, for \(n\) identical resistors, is simply
\[R_{eq} = \frac{R_{single}}{n}\]
and the resulting sink current when the bus is pulled LOW is plain Ohm’s law:
\[I = \frac{V_{DD}}{R_{eq}}\]
Antenna gain does not add transmitter power; it redirects it. Effective radiated power is the transmitter setting plus the antenna’s gain in dB:
\[\mathrm{EIRP(dBm)} = P_{tx}\mathrm{(dBm)} + G_{ant}\mathrm{(dBi)}\]
Worked Numbers: This Chapter’s Own Stacked Breakouts and Radio Module
- One breakout: a catalog-typical onboard I2C pull-up of \(10.0\ \text{k}\Omega\) on a \(3.30\) V bus sinks \(3.30/10{,}000 = 0.330\) mA when pulled LOW.
- Two breakouts stacked (this chapter’s own “two or three modules each add pull-ups” scenario): \(R_{eq} = 10.0/2 = 5.00\ \text{k}\Omega\), so \(I = 3.30/5000 = 0.660\) mA – already double.
- Three breakouts stacked: \(R_{eq} = 10.0/3 = 3.33\ \text{k}\Omega\), so \(I = 3.30/3330 = 0.990\) mA – triple the single-board current, and about \(33.0\%\) of a catalog-typical \(3.00\) mA sink-current rating for a small sensor IC, versus just \(11.0\%\) for one board alone. Nothing failed outright, but the margin the team thought it had is gone.
- Antenna gain, same LoRaWAN chip setting: a \(14.0\) dBm transmit power into a \(0\) dBi stub antenna gives \(\mathrm{EIRP}=14.0\) dBm; the same chip into a \(2.15\) dBi half-wave dipole gives \(14.0+2.15=16.15\) dBm – a \(10^{2.15/10}=1.64\times\) increase in radiated power with zero firmware change, which is why RSSI logged on the bench with one antenna does not transfer to a field unit with another.
Both numbers make the same point this chapter makes in words: a part number is not a design decision, because what the part does electrically depends on what else shares its node or its antenna port.
7.5 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.
7.6 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.
7.7 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.
7.7.1 Sensor Evidence Map
Review sensors across five evidence lanes before wiring them into a prototype.
7.7.2 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.
7.7.3 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?
7.8 Actuators and Loads
Actuator selection starts with the load. A controller pin is a command signal; it is not a motor supply, heater supply, relay supply, valve supply, or lighting supply.
Review the full drive path:
Common actuator categories:
- Motion outputs include servos, brushed motors, steppers, solenoids, pumps, and valves. Review stall current, startup current, mechanical stops, and thermal limits.
- Switching outputs include relays, solid-state switches, load switches, and transistor stages. Review contact type, leakage, isolation, and failure mode.
- Human feedback outputs include indicators, displays, haptic devices, and audio outputs. Review visibility, brightness, acoustic level, update rate, and user context.
- Power outputs include heaters, lighting loads, and external switched rails. Review current path, connector rating, wiring strain, and thermal evidence.
If a motor, relay, heater, pump, or light causes resets, the fix is often in power distribution, grounding, driver sizing, protection, or wiring layout. Firmware retries can hide the symptom without removing the electrical cause.
7.9 Communication Modules
Communication modules are hardware components with system-level consequences. They affect antenna placement, provisioning, credentials, energy use, enclosure design, update paths, and operational support.
7.9.1 Module Review Lanes
Use broad communication families cautiously:
- Local IP modules suit prototypes that can depend on existing network infrastructure and need direct application connectivity.
- Short-range personal-area modules suit pairing, commissioning, nearby control, and low-energy local interaction.
- Long-range low-throughput modules suit sparse telemetry where gateway placement and antenna evidence are part of the prototype.
- Wide-area modules suit remote prototypes that cannot rely on site infrastructure, but they add provisioning, power-state, and service-management evidence.
- Wired interfaces suit noisy environments, fixed equipment, lab rigs, and cases where power and data can share a controlled harness.
7.10 Power, Protection, Level Fit
Power components make the prototype survivable. Many integration failures are caused by treating the power tree as an afterthought.
7.10.1 Power Review Checklist
7.10.2 Interface Checks
- GPIO needs voltage compatibility, pull state, drive strength, interrupt behavior, and reset defaults.
- Analog inputs need input range, source impedance, filtering, reference stability, and noise review.
- I2C-style buses need address uniqueness, pull-up selection, bus capacitance, shared-ground integrity, and recovery from a stuck device.
- SPI-style buses need chip-select separation, clock mode, signal integrity, and cable length review.
- UART-style links need level compatibility, baud tolerance, direction clarity, and boot-message behavior.
- One-wire or pulse interfaces need timing margin, cable effects, and interrupt or timer support.
Before connecting a new component, write down the supply voltage, signal voltage, maximum current path, required interface pins, reset behavior, and first bench measurement. If one field is unknown, pause and find evidence before wiring.
7.11 Bench Tools and Evidence
Tools are part of the prototype process because they determine what can be proven. A team with only a working demo but no measurements has weak evidence.
7.11.1 Essential Bench Capabilities
7.11.2 Tool Selection Questions
- What failure would be invisible without this tool?
- Does the tool measure the signal at the same point where the failure occurs?
- Can the result be captured and attached to the component record?
- Will the tool still be useful when the prototype moves from breadboard to a wiring harness or PCB?
7.12 Incremental Examples
7.12.1 Accept Temperature Sensor Module
A classroom logger needs temperature readings inside a plastic enclosure. A BME280 breakout looks convenient, but the acceptance decision should stay tied to the measurement task.
- Confirm the required range, accuracy, and update interval against the enclosure use case, not against the breakout-board popularity.
- Check whether the module is powered from 3.3 V or 5 V, whether the SDA and SCL pull-ups are already installed, and whether the I2C address conflicts with another part.
- Wire the module alone to the selected controller, record a stable room reading, warm the enclosure by hand, and save the raw reading plus the library version used for conversion.
The component can be accepted only if the team can explain both the measurement fit and the interface fit. If the same sensor later moves from a breakout board to a PCB footprint, the pull-up and placement decisions must be reviewed again.
7.12.2 Drive a Small Pump Safely
A plant-watering prototype needs a small 5 V pump. The controller GPIO cannot power that load directly, so the component decision includes the pump, driver, supply, protection, and feedback path.
- Measure the pump’s startup current with a current-limited bench supply before connecting it to the controller rail.
- Select a MOSFET, relay module, or motor-driver board that can handle startup current and thermal load, then add a flyback path or transient suppression where the load requires it.
- Scope the 3.3 V controller rail while the pump starts, and record whether the controller resets, whether sensor readings shift, and whether wiring changes reduce the disturbance.
This example is harder because the selected “component” is really a drive path. A firmware command that turns the pump on is not enough evidence unless the power rail, driver stage, and safe state are also understood.
7.12.3 Portable Environment Logger
The team wants a portable logger that records temperature, humidity, light level, and enclosure-open events. The first prototype must prove that the selected components can be powered from a small battery, logged locally, and debugged without guessing.
7.12.4 Candidate Components by Role
7.12.5 First Integration Pass
- Power the controller alone from a current-limited source and record idle and active current.
- Add one sensor at a time, proving rail voltage, interface detection, and a believable reading before adding the next component.
- Add local storage after the sensor bus is stable, then test write behavior during reset and low-power transitions.
- Add battery operation only after the bench supply current evidence is understood.
- Record every accepted component with its role, required pins, power state, first test result, and unresolved risks.
7.12.6 Evidence Record
7.13 Component Record Template
Use a short record so future revisions can understand the decision without reconstructing the whole bench session.
- Role: What the component does in the prototype.
- Requirement: The measurement, output, communication, or power need it satisfies.
- Electrical fit: Supply rail, signal voltage, current path, protection, and reset state.
- Interface fit: Protocol, pins, addresses, timing, pull-ups, level shifting, and cable concerns.
- Mechanical fit: Connector, mounting, orientation, enclosure exposure, and service access.
- Bench proof: Measurement, screenshot, log, or observation that proves the component works in context.
- Open risk: Any assumption that must be checked again before PCB, enclosure, or field use.
- Decision: Accepted, conditional, rejected, or deferred.
7.14 Try It Now
Pick one component from a prototype you have seen or built. Write a four-line acceptance note:
- The component role and the requirement it supports.
- The supply voltage, signal voltage, current path, and interface pins.
- The first bench measurement or log that would prove it works before full integration.
- The unresolved risk that would block a PCB, enclosure, or field trial.
7.15 Find Missing Evidence
A team selects a 3.3 V SHT31 temperature/humidity sensor, an ESP32 development board, a microSD module, and a single-cell LiPo charger board for a greenhouse logger. Their notes say “all libraries installed and demo sketch runs.”
Name two missing pieces of component evidence before the prototype is accepted. Strong answers include measurable details such as I2C pull-up voltage, bus address, sleep current, SD-card write current, charger protection behavior, enclosure airflow, calibration reference, or how the logger behaves during a low-battery reset.
7.16 Level-Shift Before Connecting
7.17 Component Acceptance Evidence
7.18 Match Evidence to Component Decisions
7.19 Order the Integration Review
7.20 Common Failure Patterns
Example projects prove that a component can work somewhere. They do not prove that it matches your measurement range, enclosure, power state, interface boundary, or deployment environment.
Breakout boards are useful for bench evidence, but they hide layout, connector, pull-up, regulator, and protection choices that must be reviewed before a durable design.
When several new parts are added at once, failures become ambiguous. Add one component at a time and preserve the evidence that each new boundary works.
Many components behave differently during startup, brownout, sleep exit, or reset. Review the safe state before a prototype controls real loads or records important data.
7.21 Summary
Hardware components are accepted through evidence, not familiarity. A good component record connects the requirement to the electrical fit, interface fit, power behavior, mechanical constraints, bench proof, and unresolved risks. This keeps prototypes readable, debuggable, and ready for the next revision.
7.22 Key Takeaway
Component choices should be justified by electrical fit, availability, firmware support, environmental limits, testability, and lifecycle risk, not only by module convenience.
7.23 See Also
- Hardware Getting Started - build the first hardware prototype with a controlled setup sequence.
- Hardware Introduction - review the hardware prototyping path at a higher level.
- MCU vs MPU - decide what kind of controller belongs at the center of the prototype.
- PCB Design - move component evidence toward layout and fabrication decisions.