Field log · Hardware · BLE

Fighting engine vibration in a BLE brake-pedal sensor

The idea was simple: strap a Bluetooth motion sensor to the brake pedal, detect when it's pressed, and log it as evidence. The idea stayed simple for exactly as long as the engine was off. This is the log of everything between "it works on my desk" and "it works in a running car."

The goal of the project was to record brake-pedal activity during unintended-acceleration incidents — a small BLE inertial sensor on the pedal, an Android app listening over Bluetooth Low Energy, and a timeline that could later be exported as a report. On a desk, detecting a "press" is almost embarrassingly easy: the sensor tilts and accelerates, you threshold the magnitude, done. Then you put it in a car, start the engine, and every naive assumption you made falls apart at once.

The problem: a running engine never sits still

An idling engine transmits a constant, surprisingly strong vibration through the entire cabin, including the pedal. To an accelerometer, that vibration looks like a continuous stream of small accelerations in every axis. My first detector — threshold the acceleration magnitude, fire on a spike — turned into a machine gun of false positives the moment the engine turned over. The sensor couldn't tell "the driver pressed the pedal" apart from "the engine is running," because both produce acceleration. The signal I wanted was buried under a noise floor that only existed in the exact environment the device is meant for.

Iterating the detector, paradigm by paradigm

The BrakeDetector went through several complete rewrites, not just tuning passes. Each paradigm failed in an instructive way:

• Raw magnitude threshold. Simplest, and useless with the engine on. Vibration crosses any threshold low enough to catch a gentle press.
• High-pass filtering the acceleration. Better at removing the constant component, but engine vibration isn't purely constant — it has structure that leaks through, and hard braking has low-frequency content that the filter also eats. You end up trading false positives for missed presses.
• Angle-based detection. Track the pedal's pitch angle over a short window and fire when it swings past a threshold and holds. This is what finally separated "pressed" from "vibrating," because a press is a sustained rotation and vibration is zero-mean jitter around a resting angle.
• Debounced state machine. Wrap the angle detector in an explicit pressed/released state with hold times, so a single press produces exactly one event instead of a burst.

Even the angle approach needed a rest-angle baseline that adapts slowly — the pedal's neutral position isn't identical between mounts or between cars — while ignoring fast jitter. Slow adaptation for drift, fast rejection for vibration: those two requirements pull in opposite directions, and most of the tuning was finding a window length that honored both.

The bug that hid in the timing

One defect outlived several rewrites and I want to name it because it's the kind that makes you doubt your sensor rather than your code: an alternating-detection period. Under certain conditions the detector would catch one press, miss the next, catch the one after, miss again — a clean every-other-press pattern. A perfectly alternating failure is almost never a sensor problem; hardware noise is random, not tidy. It's a state-machine bug: the "released" transition wasn't completing before the next press arrived, so every second press landed while the machine still thought it was mid-press. Regular, rhythmic failure means logic, not physics. I eventually deferred the last of it, but the diagnosis — tidiness implies code — is the transferable part.

Mounting is part of the algorithm

The part I underestimated most: how the sensor is physically attached changes the data more than any code. A loose mount adds its own resonance and turns a clean rotation into a smeared one. A mount that constrains the pedal's natural arc changes the very angle you're detecting. I spent real time on the mount design, and every change to it invalidated some of my threshold tuning, because I'd effectively changed the input distribution. With embedded sensing, the physical setup and the signal processing are not separate problems — they're one problem, and you can't finish the software while the hardware is still moving.

What I'd tell myself at the start

Three things. First, test in the real environment immediately — a desk prototype for a car sensor validates almost nothing, because the entire difficulty is the environment you're not simulating. Second, detect the physical quantity that noise doesn't corrupt — here, orientation instead of acceleration; the right feature makes the filtering almost unnecessary. Third, read the shape of your failures — random misfires point at the physical world, but any regular, repeating pattern is your own state machine confessing. None of these is specific to brakes; they're what building any BLE motion product teaches you, usually the expensive way.

This is an account of a personal engineering project, not automotive-safety advice. Anything intended to record vehicle behavior should be validated far more rigorously than a hobby build before it's relied on.