Tagged connected-hardware
11 pieces
- · 8 min read
Turning a Sensor Off Does Not Turn It Off: Back-Powering Through Shared Bus Pull-Ups
Cut a sensor's supply rail and it can stay awake, drawing current through the pull-up resistors on a shared bus that never switches off. The current arrives through the part's own data pins via its protection diodes. Choosing a lower-power sensor changes nothing, because nothing about this is a property of the sensor. Negligible battery impact is a claim about the topology, not about the part.
- · 7 min read
Spend Your Effort on the Layer With No Reference Path and No Error Case
In a layered product, risk is not where the engineering is hardest. It is where there is neither a worked reference implementation nor a mechanism that fails loudly. In a camera stack, the firmware layer has a vendor reference path and hardware that inserts framing automatically. The descriptor handshake one layer above has neither, so an error there passes every in-house test and fails only when a third-party host tries to enumerate the device.
- · 10 min read
The Shape Of A Heartbeat Is A Firmware Decision
A convincing mechanical heartbeat is asymmetric and punctuated: a fast contraction over roughly one third of the cycle, a brief hold, a slower release, then a real pause taking roughly two thirds. A motor turning at constant speed produces a smooth sinusoid that reads as a machine running. The shape cannot come from the mechanism, so it has to come from the controller, and that makes the perceptual requirement a firmware problem. There is no machine learning anywhere in this system.
- · 10 min read
Stopping The Signal Is Not Switching It Off
Detaching or stopping the control signal to a servo does not remove power from it. The internal controller keeps running off the supply rail, and under mechanical load the servo can still draw current and hum audibly. Real silence requires cutting the supply rail with a transistor. In a battery wearable, the average current is set by what stays powered between events, which is why duty-cycled power gating buys hours and part selection does not.
- · 10 min read
Your Multimeter Cannot See Your Sleep Current
Current consumption in a well-designed low-power device spans several orders of magnitude across a duty cycle, from microamps asleep to tens of milliamps transmitting. A bench multimeter integrates over its own measurement window and is effectively blind across most of that range. The useful quantity is charge per event, not current, and the rule that saves the most time is this: if the meter says zero and the battery disagrees, the battery is right.
- · 10 min read
Ninety Percent Is Not Success: Update Telemetry That Measures The Wrong Stage
On at least one major connected-device platform, a firmware update progress figure reaching 90 percent means the download completed, not that the install completed. Teams read it as near-success when it is the moment just before the risky part begins. Telemetry that measures the wrong stage is worse than no telemetry, because it manufactures confidence. The fix is to report download, install, reboot and version confirmation as four separate stages.
- · 10 min read
Rolling Back On A Platform That Forbids Downgrades
Platforms that enforce a strictly-higher-version rule make conventional rollback impossible, because the device will refuse any image numbered below what it is running. The technique that works is forward-versioned rollback: take the known-good older binary, relabel it with a higher version number, and the device installs it as a normal upgrade while running the old safe code. It works, it creates a bookkeeping hazard, and it does not extend your recovery boundary past devices that still check in.
- · 10 min read
A Staged Rollout Of A Bad Build Is Still A Bad Build
A rollout ladder controls how many devices a build reaches, and that is the entire extent of what it does. It cannot make the build safe. A one percent rollout of firmware that bricks on power loss bricks one percent of the fleet, permanently. The gate that asks whether the build survives an interrupted update runs before device one, and missing evidence counts as a fail rather than as a reason to proceed carefully.
- · 6 min read
Edge or Cloud Inference: A Decision Table
This is usually argued on latency and cost, which are the two least decisive inputs. The questions that actually settle it are whether the system must work with no connectivity, whether the data can legally or contractually leave, and whether you can reach the device to fix what you got wrong.
- · 7 min read
Ship It Once, Reach It Never: Designing for Hardware You Cannot Touch
When a unit leaves the building, the set of decisions you can still change shrinks to almost nothing. The design question becomes which properties must be right at manufacture and which can be deferred, and getting that split wrong is the most expensive mistake in connected hardware because it is discovered across an entire production run at once.
- · 7 min read
The Update That Bricks the Fleet: OTA Failure Modes
An over-the-air update is the only operation where a bug can remove your ability to fix the bug. That single property should determine the entire design, and it produces requirements that look excessive until you consider what the alternative costs: a truck roll per unit, or a fleet you cannot reach at all.