Before the governor: why heart-rate control needs a warm-up
A cold heart-rate reading is a delayed answer to a body that has only just started moving. Letting the belt chase it is the wrong first conversation. Our plan is a visible, deterministic 6–10 minute load ramp — and only then does heart-rate control get permission to push.
A quiet mistake at the start
TreadPilot already waits after a speed or incline change before judging the next heart-rate sample. That wait is useful, but it is not a warm-up. Today, entering a segment can still send its starting speed and incline immediately. The controller is being patient after the command; the body was not prepared before it.
Heart rate and oxygen uptake both take time to answer a new load. During those opening minutes, a low number does not mean the runner needs a faster belt — it can simply mean the response has not arrived yet. The American Heart Association recommends 5–10 minutes of slower, gradual movement. For an automatic treadmill, that is also a control-system boundary: prepare first, regulate second.
The ramp is calculated from the work
The planned warm-up starts no faster than 3.0 km/h and climbs by at most 0.5 km/h per minute. Its length depends on the first heart-rate-controlled segment's starting load. Only one axis may rise at a time: speed first, calibrated incline only afterwards. It lasts at least six minutes and at most ten; if the intended start cannot be reached inside those limits, the app asks for an authored warm-up instead of secretly steepening the ramp.
Four phases, four different permissions
The full warm-up, its start and its added duration are visible before the belt moves.
The belt follows the confirmed load plan. A low pulse can never accelerate it beyond that plan.
Fresh high HR and every existing safety ceiling may slow or stop. Missing HR grants no upward authority.
Only after the ramp, with a fresh sensor and a reconciled treadmill state, may band-following begin.
The decision
Every program that uses automatic heart-rate control will get one warm-up at the start by default. It is load-led, not pulse-led; it adds time instead of stealing minutes from the prescribed work; and its final command meets the first controlled segment, so there is no large jump at the hand-off.
There are two honest exceptions. A program author can mark an existing segment explicitly as a warm-up, or the runner can knowingly turn the automatic phase off. Names are not enough: a segment called “Easy start” in one language must not be guessed into a safety role. The program stores that role and the reason automation was suppressed.
The 6–10 minute plan and 0.5 km/h-per-minute slew are conservative product decisions, not an experimentally optimal dose. A crossover pilot still has to measure early overshoot, time in zone, command count, comfort and skip rate. Until then, the Lab calls this a planned method, not a proven performance improvement.
Safety does not wait for the warm-up
The explicit start confirmation, device limits, manual takeover, stale-link behaviour, forced slow-down and emergency stop all stay active. The only thing delayed is permission to increase load in pursuit of a band. Any safety reduction, manual takeover, stale machine state or link failure cancels every remaining upward ramp step for that warm-up; it cannot quietly resume without a new plan and confirmation. If heart-rate data is missing at the hand-off, the app waits without increasing, then offers fixed-load continuation or stop. It does not choose on the runner's behalf.