3 Sensor Hardware Selection

Build the Hardware Decision Record

A hardware decision record captures why one candidate was accepted and why alternatives were rejected. It should be clear enough that another reviewer can repeat the reasoning after procurement, installation, maintenance, or replacement.

Rejected candidates are useful evidence. Record why a part was excluded: wrong measurand, narrow range, poor environmental fit, interface risk, weak placement, calibration burden, power cost, missing diagnostic state, or maintenance access. This prevents the same unsuitable option from returning later as an undocumented shortcut.

Worked example. A wearable motion-capture node makes the interface and lifecycle rows concrete. The design requirements come first and drive the hardware, not the reverse: fully wireless, no external infrastructure such as fixed cameras, real-time and interactive, and easy enough to use that the technology becomes ordinary rather than a lab novelty. A node meeting that brief, such as the Orient-5 design, pairs two radios (Bluetooth at 2.5KB/s and a 2.4GHz link at 50KB/s) with an 8kHz gyroscope and 4kHz accelerometer, and reports fused quaternion orientation at 200Hz over Bluetooth or 2500Hz over the 2.4GHz link. That radio choice is itself a hardware decision with a lifecycle consequence: a TDMA-scheduled 2.4GHz deployment running twelve nodes can sustain a 128Hz update rate per node, but doubling to twenty-four nodes on the same shared link halves it to 64Hz. The accepted-evidence row should record which of those two operating points the application actually needs before more nodes get added to the network.

Hardware Fit Fails at Boundaries

Weak hardware decisions usually fail where the physical world meets the data path. A sensor may measure the right quantity but in the wrong location. It may have a convenient bus but lose units or error states. It may pass calibration in one condition but drift in another. It may draw more power after warm-up, stabilization, retries, or environmental stress than the node budget allows.

To make the boundary problem concrete, inspect Figure 3.3 before judging this device by connector or resolution alone. The photograph identifies the physical camera assembly; the key selection question is the kind of data that assembly produces and what the downstream path must preserve.

In Figure 3.3, start at the lens and camera body, then follow the ribbon connection into the processing boards. Unlike an ordinary frame camera, a Dynamic Vision Sensor reports changes in brightness as events, so timing, interface bandwidth, storage, and algorithms must accept an event stream. The hardware can be electrically compatible yet still be wrong for a frame-based application. That example connects physical fit to the evidence and service boundaries reviewed next.

False confidence is common. A hardware module may produce stable numbers while sensing the enclosure temperature instead of room air. A digital interface may hide analog front-end noise. A low-power sensor may become high-cost when warm-up, radio retries, and frequent validation are included.

Worked example. A comfort sensor mounted in a sealed electronics box can read 29 °C while the room reference thermometer reads 22 °C, because the board, regulator, and radio warm the enclosure. The I2C transaction is still valid and the data may be smooth, but the physical boundary is wrong: the sensor is measuring self-heating plus trapped air. A defensible fix might move the probe into free airflow, add a vented shield, record an offset only if it remains stable against a reference, and retest whenever the enclosure, board power, sampling interval, or mounting location changes.

The under-the-hood rule is to ask what would make the selected hardware lie, go silent, drift, saturate, or become unserviceable. If that change would alter the application decision, it belongs in the decision record as a limit, diagnostic, fallback, or retest trigger.

Worked example. Clinical fall-risk assessment shows three very different hardware answers to the same measurement claim: how well can a person maintain postural balance? The CDC put the annual US cost of falls at roughly \$34 billion in 2013, projected to reach \$55 billion by 2020, which is why the hardware choice behind "measure balance" is not a minor detail. The current gold standards sit at opposite ends of the hardware trade-off: interview-and-observation tests (a timed sit-to-stand, a timed up-and-go walk, a single-leg stance) are cheap but subjective and non-repeatable, while gait-lab force plates with reflective motion-capture markers are objective but expensive equipment few clinics can install. Between those two, a Dynamic Vision Sensor (DVS) camera -- an event camera that reports pixel-level brightness changes at roughly 1µs resolution instead of full frames, a response profile researchers have likened to the visual cortex's V1 layer -- has been proposed as an off-body, non-contact candidate that integrates with an existing clinical workflow at a fraction of a force plate's cost (Nalci et al., IEEE EMBC 2015). The evidence-fit question for a hardware record is not "which sensor is most advanced" but which of these three known limits -- subjective and non-repeatable, objective but unaffordable at scale, or new enough that its clinical validation is still being built -- the application can actually live with.

Validate a Balance-Sensing Claim, Not Just the Camera

A DVS balance experiment becomes evidence only after its event stream is reduced to a repeatable motion measure and compared across controlled conditions. One useful summary is total event-motion variance over a fixed trial, normalized by the same declared reference so that trials remain comparable. Eyes-open, eyes-closed, and eyes-closed-with-haptic-feedback trials then test an expected ordering rather than merely producing three attractive traces: removing visual feedback should change sway evidence, while useful feedback should move the measure toward the accepted reference condition. Normalization helps comparison, but it does not remove the need to record trial duration, region of interest, distance, lighting, event thresholds, filtering, stance protocol, and missing or saturated events.

Repeat the protocol for left- and right-foot stance and retain per-participant results. A mean alone can hide a method that works for one stance side or a few participants but fails elsewhere. Side-to-side asymmetry may be a real characteristic of the person, a placement or occlusion effect, or processing bias; the validation record should not choose among those explanations without follow-up evidence. Report the distribution, paired differences, exclusions, and repeatability before claiming that the method generalizes.

A second sensor can test whether both systems preserve the same dynamics. Estimate power spectral density from synchronized DVS and balance-board signals using the same time interval and clearly documented preprocessing. Agreement in the frequency bands relevant to postural sway is stronger evidence than similar-looking time plots, because it checks where motion energy is distributed. Disagreement is diagnostic rather than automatically disqualifying: camera geometry, event noise, board calibration, filtering, sample timing, or genuinely different measured quantities can all change the spectra. Hardware acceptance therefore requires both discriminating conditions and agreement limits against a reference—not a single demonstration that the DVS produced data.