Sensors That Stay Awake: The Tilt Synth Fixes

Someone built a tilt-controlled synth, set the board down on a desk, and it buzzed anyway. Then it went quiet and stayed quiet. They spent two days convinced the hardware was broken. It wasn't — and chasing that one report turned into the most useful week we've had in a while.

Here's what was actually happening. Motion sensors are twitchy by nature; the very last bit of a reading wobbles constantly, even on a board that isn't moving. We were treating every one of those wobbles as real movement, so a still board fired a tone five times a second — which blurs into one continuous buzz. Motion capabilities now carry a noise deadband, a small threshold a reading has to clear before it counts as a change. It's tuned from each sensor's published noise floor, low enough that a deliberate ten-degree tilt still triggers instantly, high enough that a resting board says nothing. And because a deadband on the wrong kind of sensor is worse than none at all — a light sensor in a dark room legitimately reads the same value forever — we went capability by capability rather than switching it on everywhere.

The "then it stops" half was a different problem. Motion chips wake up asleep and have to be told to start measuring, and some of them quietly slip back to sleep after a power blip. We'd written the wake-up instructions for those boards, we'd written a check that re-sends them every thirty seconds — and neither had ever reached a single device, because of one branch in the code that dropped the instructions for exactly the sensors that need them most. That's fixed now, and four more chips that boot asleep got proper wake-up sequences too. We also added a check that fails the build whenever a setting is written down but read by nothing, which caught six more of these ghosts, including one where a device asking for a fast serial connection was silently opened at a twelfth of the speed.

While we were in there, we straightened out the reading loop itself. Every sensor declares how often it wants to be read — anywhere from every ten milliseconds to every two minutes — and we'd been ignoring all of that and reading everything at the fastest rate on the board. A sensor asking for one reading a minute was getting six thousand. That number is now one. Since these boards share a single connection between all their sensors, freeing up that traffic makes everything else more responsive, and some chips genuinely return nonsense if you read them faster than they can measure. Timing now runs on a steady clock that can't be yanked around when the board syncs the time of day, which used to freeze your live readout for hours without a single log line. And when you unplug a module, we finally forget about it properly — plug something new into the same spot and its first reading gets through, instead of being compared against a ghost of whatever was there before.

One last bit of housekeeping, in the honest-rather-than-flattering category. While auditing the catalogue we found three boards whose descriptions named one chip while their technical details named another, with the manufacturer's own datasheet sitting right there contradicting both. One was just a mislabel. The other two had been marked as verified-on-hardware when the evidence says nobody ever verified them, so we've moved them back to untested and written down exactly why. We'd rather tell you a board is unproven than let you find out the hard way — and a new check now catches this the moment it happens again. All of it adds up to the same thing: your board does what its sensors actually say they do, and stays doing it.