The Shape Of A Heartbeat Is A Firmware Decision

Mostafa Dhouib·10 min read

The Shape Of A Heartbeat Is A Firmware Decision

The short answer. A heartbeat you can feel through a wearable is not a vibration, it is a specific shape in time. The real thing is asymmetric and punctuated: a fast contraction taking roughly one third of the cycle, a brief hold at the top, a slower release, and then a genuine pause taking roughly two thirds of the cycle. At rest the whole cycle is about 0.8 seconds. A motor turning at a constant speed through a crank gives you a smooth, symmetric rise and fall with no pause at all, and that reads immediately as a machine running rather than as a heart. The mechanism cannot produce the shape, so the shape has to be commanded, which moves the entire perceptual problem into the controller. There is no model in this system, only a profile and a clock.

Put an actuator against a body and the first assumption is that the hard part is mechanical. Pick a quiet actuator, mount it well, give it enough travel.

That gets you movement. It does not get you a heartbeat, and the gap between the two is almost entirely in software.

The mechanism gives you motion, not a heartbeat

The simplest way to make something tap rhythmically is to turn a motor at a constant speed and convert the rotation into linear travel with a cam or a crank.

The displacement it produces is close to a sinusoid. The outward stroke and the return stroke take the same time, the acceleration is smooth throughout, and there is no interval where nothing is happening, because the mechanism never stops. Change the speed and you change the rate. You cannot change the shape, because the shape is a property of the geometry.

Against skin, that reads as a machine. Not as a quiet machine or a rough machine, just unmistakably as something rotating. The brain is extremely good at recognising periodic smoothness as mechanical, and a sinusoid is the clearest possible signature of it.

What a heartbeat looks like as displacement over time

The real thing has four distinguishable parts, and the proportions matter more than the amplitudes.

A fast contraction, taking roughly one third of the cycle. This is the part with an edge on it. It arrives quickly and it is the component that makes the beat feel like an event rather than a swell.

A brief hold near the peak. Short, but not zero. Without it the top of the beat feels like a bounce.

A slower release. Longer than the contraction and with no sharp edge. The asymmetry between a fast rise and a slow fall is a large part of what makes the pattern read as biological.

A real pause, taking roughly two thirds of the cycle. Nothing happens. This is the longest single part of the beat and it is the part a constant-speed mechanism cannot produce under any geometry.

At rest the complete cycle is about 0.8 seconds. So the active portion is a fraction of that, and the silence is the majority of it. The pause is not a gap between beats. It is the dominant feature of the pattern.

The pause is where the realism lives

Most of the effort instinctively goes into the stroke, because the stroke is what you feel. But two profiles with an identical stroke, one followed by a proper pause and one followed by an immediate return, feel like completely different things. The first is a beat. The second is a buzz with a rhythm imposed on it.

Silence is also the thing that makes the next beat legible. A beat is perceived by contrast with what precedes it, and if the preceding interval contains motion then the onset has nothing to stand out against. The pause is what gives the contraction its edge.

That has a direct consequence for how you build the thing. The requirement is not "move the actuator in a heartbeat pattern". It is "command a position trajectory in which motion occupies a minority of the cycle and stillness is enforced for the rest", and enforcing stillness is a controller behaviour.

So the shape becomes a firmware problem

Once you accept that the mechanism cannot supply the shape, the architecture follows.

You stop treating the actuator as something you run at a speed and start treating it as something you command to a position on a schedule. The controller holds a profile, which is a sequence of target positions against time, and a fixed time base. On each tick it computes or looks up where the actuator should be at that instant and commands it there. The profile encodes the asymmetry, the hold and the pause explicitly, because every one of those is just a run of target values.

Three properties of that structure are worth stating.

The time base has to be a hardware timer, not a delay loop. The perceived quality of a rhythm is sensitive to jitter in a way that amplitude is not. If the tick wanders, the beat sounds unwell even when every individual stroke is correct.

The profile belongs in data, not in control flow. A table of keyframes with interpolation between them is editable without touching logic. A heartbeat expressed as a sequence of conditionals and delays is a profile you cannot tune, and tuning is the entire activity.

Rate changes must scale the profile, not just the step size. If you want a faster beat, the contraction and the pause should not scale identically, because at a higher rate the pause shortens far more than the stroke does. Scaling the whole table uniformly gives you a fast version of the same shape, which is wrong in a way people notice without being able to say why.

There is no machine learning in this system

Worth saying plainly, because the description above involves perception, subjective tuning and a waveform, and those words attract an assumption.

There is no model. No training data, no inference, no learned parameters, nothing adaptive. The system is a lookup table, an interpolator and a timer interrupt. The behaviour is fully determined by numbers a person chose and can read.

That is not a compromise, it is the correct design, for three reasons.

There is nothing to learn. The target is a fixed perceptual effect. It does not vary by user in a way the device can observe, and there is no feedback signal that tells the device whether the last beat felt right. A learning system needs an error to minimise, and here there is none available at runtime.

Determinism is the product. The value of the output is its exact timing. A component that could decide to behave differently is a defect source, not a feature.

It fits the part and the budget. A table lookup in a timer interrupt costs almost nothing in cycles, memory or current. Anything that had to run inference would change the processor, the power budget and the cost.

What still makes it hard

Removing the model does not make it easy, and the difficulty is in the gap between what you command and what the body feels.

The actuator has limited bandwidth. The fast contraction asks for a sharp edge, and the mechanism has mass and inertia. Command a step and you get a ramp with overshoot. The profile has to be written for what the actuator can actually track, which means the commanded shape and the delivered shape are different documents.

Overshoot and ringing destroy the pause. The actuator settling after a stroke is motion, and motion during the pause is exactly what you were trying to eliminate. So the end of the release matters as much as the start of the contraction, and often the fix is to shape the deceleration rather than to make the stroke stronger.

Backlash eats small movements. Any slack in the drive train means the first part of a commanded move produces no output at all, which shifts the perceived onset and shortens the perceived stroke.

The load varies. How tight the strap is, where it sits, and the compliance of the tissue underneath all change the relationship between commanded position and felt pressure. The profile lives in command space and the requirement lives in perception space, and nothing maps one to the other except trying it.

So tuning is empirical and it is done against a body, not against a plot. Which means the most important piece of infrastructure on the project is the ability to change the profile and feel the result immediately, without a rebuild. A profile you can edit live converges in an afternoon. A profile that requires a compile and a flash per iteration does not converge at all, because the loop is longer than anyone's patience for small differences.

The honest limit

Everything above is calibrated against perception, and perception is subjective and unmeasured here. There is no reference waveform for how a heartbeat should feel through a strap, no instrument that scores it, and no agreed metric. The proportions, one third contraction and two thirds pause, describe the mechanical event being imitated. They are a strong starting point and not a specification of the felt result.

A profile that reads convincingly on one person and one mounting arrangement can read differently on another, because the mechanical coupling is part of the signal path and it changes with the body. There is no claim here about a physiological or therapeutic effect either. The subject is fidelity of imitation, and fidelity of imitation is not evidence of anything happening downstream of it.

And the sinusoid criticism has a boundary. A constant-speed mechanism feels mechanical in the context of a slow, discrete, punctuated pattern. For a continuous buzz it is entirely appropriate, and for that application all of the above is unnecessary cost.

FAQ

Why does a motor running at constant speed not feel like a heartbeat? Because constant rotation through a crank or cam produces a smooth, symmetric sinusoid with no still interval. A real beat is asymmetric and punctuated, with a fast contraction over roughly one third of the cycle and a genuine pause over roughly two thirds. Continuous smooth motion is the clearest signature of something rotating, so the brain reads it as a machine immediately.

What is the actual shape of a convincing mechanical heartbeat? Four parts in sequence. A fast contraction taking roughly one third of the cycle, a brief hold near the peak, a slower release, and then a real pause taking roughly two thirds of the cycle. At rest the complete cycle is about 0.8 seconds, which means stillness occupies the majority of it and the stroke is a short event inside it.

Why is the pause the important part? Because a beat is perceived by contrast with what came before it. If the interval before the stroke contains motion, the onset has nothing to stand out against, and the result feels like a buzz with a rhythm rather than a series of beats. Two profiles with the same stroke feel entirely different depending on whether the pause is real.

Is there any machine learning in a system like this? No. It is a keyframe table, an interpolator and a hardware timer. There is no model, no training data and no inference. There is also nothing to learn, because the device has no runtime signal telling it whether the last beat felt right, and a learning system needs an error to minimise.

Why does the profile need to be data rather than code? Because tuning is the whole job, and it is empirical. Keyframes in a table with interpolation between them can be adjusted and felt immediately. A heartbeat expressed as nested conditionals and delay calls cannot be adjusted without touching logic, and if each iteration costs a compile and a flash, the loop is too slow to converge on a subjective target.

What limits how sharp the contraction can be? The actuator. A sharp commanded edge meets mass, inertia and backlash, so the delivered motion is a ramp with overshoot and the first part of any move may produce no output at all. Overshoot matters twice over, because the actuator still ringing after a stroke puts motion into the pause, which is the part that was supposed to be silent.