When Two VBT Devices Disagree: Reconciling Velocity Readings

Your athlete finishes a set of 100 kg back squats with both a tethered LPT and a hip-mounted IMU running at once - something you did on purpose after a training partner insisted the IMU was reading 15% high. The LPT says 0.52 m/s. The IMU says 0.61 m/s. Same rep, same bar, same person, two numbers that don't just differ, they disagree by enough to move a velocity-loss cutoff from 20% to 6%, which is the difference between stopping the set and grinding out two more reps. This is not a rare glitch. Weakley et al. (2020), comparing a linear position transducer against a commercial IMU device across free-weight squat and bench press, found systematic mean bias ranging from 0.03 to 0.11 m/s depending on exercise and velocity zone, with the IMU consistently reading higher at slower velocities. Pérez-Castilla et al. (2019) reported similar exercise-dependent bias when comparing a smartphone app, an IMU, and a linear encoder against a criterion 3D motion capture system, with limits of agreement wide enough that the devices could not be used interchangeably without a correction. The disagreement you're seeing is not a defect in either unit. It's two different measurement principles reporting two different things, and the fix is a short cross-check, not a warranty claim.

A linear position transducer measures displacement directly - a cable unspools as the bar rises, and velocity is calculated as a first derivative of that measured position over time. It is close to a ground-truth measurement of the tether attachment point's vertical travel, with the main error sources being cable angle (if the unit isn't positioned directly under or in line with the bar path) and sampling rate limits at very fast or very slow velocities.

An IMU-based sensor takes a fundamentally different route: it measures acceleration (and often angular velocity) at the mount point, then integrates that signal once to estimate velocity. Integration is where the trouble starts. Small errors in the raw acceleration signal, sensor drift, and the choice of filtering algorithm all accumulate over the integration window, and the error is not constant - it tends to grow at lower velocities where the signal-to-noise ratio in the raw accelerometer data is worse. This is exactly the pattern both Weakley et al. and Pérez-Castilla et al. found: agreement was closer at higher velocities (jump-type or lighter-load movements) and diverged more at grinding, near-maximal velocities where IMU-based devices had to work hardest to separate real deceleration from noise.

If you have to pick one number to act on without running the cross-check below, the LPT is the safer default for grinding, near-maximal work - the exact zone where the two disagree most. This is not because IMUs are unreliable in general; for jump testing, ballistic movements, and lighter-load velocity zones, published agreement between IMU devices and criterion systems is often within 0.02-0.04 m/s, tight enough for most programming decisions. The problem is specifically the low end of the velocity spectrum, below roughly 0.5 m/s, where an LPT's direct position measurement stays accurate while an IMU's integrated estimate accumulates the most error per rep.

There's a practical exception worth knowing: if your LPT tether is mounted at an angle greater than about 15 degrees from vertical - common in commercial gyms where the unit has to sit off to the side of a rack - the LPT's own error grows enough that a well-calibrated IMU can actually be closer to true velocity. So trusting the LPT by default really means trusting whichever device has fewer known setup compromises, and that has to be checked, not assumed, for your specific rig.

Rather than guessing which device is closer to true velocity, run both at once across a load range that spans your actual training zones and see where the gap opens up.

Mount both devices correctly and independently - LPT tether aligned as close to vertical as your rack allows, IMU at its manufacturer-specified attachment point, not improvised. For each rep, record both readings and calculate the absolute difference and the percentage difference relative to the LPT reading (treating it as the interim reference unless you have reason to trust the IMU more per the exception above). Do this for at least 2-3 reps per load rather than one, since a single rep can be an outlier from a hitch in the bar path that affects one device more than the other.

Once you have the data, plot or simply eyeball the percentage difference against load. A gap that stays under roughly 5% across all three loads means the two devices are close enough to use interchangeably for programming purposes. A gap that grows as load increases - the far more common pattern - tells you exactly where to apply a correction or which device to defer to at which zone.

Three patterns show up most often once the cross-check data is in front of you, and each points to a different fix. A gap that is roughly constant across all loads (say, IMU reads 0.04-0.05 m/s high at every velocity) suggests a fixed calibration offset rather than a velocity-dependent integration problem - this is the easiest case, since you can apply a flat correction factor to the IMU readings and move on. A gap that widens specifically at the grinding zone while staying tight at the fast zone is the classic integration-drift signature described by Weakley et al. and points to the IMU's accuracy limit at low velocities rather than a mounting error; in this case, defer to the LPT for anything below about 0.5 m/s and trust either device above it. A gap that is inconsistent rep-to-rep with no clear pattern by load - sometimes IMU higher, sometimes lower, by varying amounts - usually means a mounting problem on one of the two devices rather than a device-level accuracy issue, and the fix is to recheck attachment points before concluding anything about the hardware itself.

One more pattern worth flagging: if the disagreement only shows up on the first rep of each set and tightens up by rep two or three, suspect the IMU's initialization or zeroing routine rather than a fundamental accuracy gap - some devices need a brief settling period after the bar starts moving before the integration math stabilizes, and a single-rep comparison will catch that as a false alarm.

Most programs don't have the luxury of running both devices forever. Once the cross-check protocol above gives you a documented offset - whether flat or velocity-dependent - the practical path is to pick one device as the system of record going forward and, if switching from one to the other mid-program, apply the documented correction to bridge historical data rather than starting a fresh trend line from zero. A 1RM estimate or velocity-loss threshold built on IMU data with a known 0.05 m/s low-velocity bias can be adjusted by that amount when comparing against future LPT-only sessions, preserving continuity in the athlete's profile instead of throwing away months of trend history over a device switch.

Re-run the 3-set cross-check any time you change mounting hardware, update either device's firmware, or notice a training call (a velocity-loss stop, an autoregulated load jump) that doesn't match how the set actually looked. Firmware updates in particular can silently change an IMU's internal filtering, which shifts the offset you documented previously without any external sign that something changed.

An intermediate lifter (bench press 1RM 110 kg) ran the 3-set protocol with a tethered LPT and a barbell-mounted IMU at 50%, 70%, and 85% loads. At 55 kg (50%), MCV averaged 0.98 m/s on the LPT and 1.01 m/s on the IMU - a 3% gap, well within noise. At 77 kg (70%), the LPT read 0.68 m/s against the IMU's 0.74 m/s, an 8.8% gap. At 94 kg (85%), the gap widened further: LPT 0.41 m/s versus IMU 0.49 m/s, a 19.5% difference - almost exactly the pattern Weakley et al. describe, with bias growing as velocity dropped.

The coach concluded the IMU had a velocity-dependent low-speed bias rather than a flat calibration offset, since a flat correction would not have explained the widening gap. Going forward, the team used the LPT as the reference for any set with a target MCV below 0.55 m/s (autoregulation cutoffs, 1RM estimation at heavy loads) and treated the two devices as interchangeable above that threshold, where the gap stayed under 5%. Six weeks later, a re-check at 85% load with an updated IMU firmware version showed the gap had narrowed to 11%, indicating a firmware-level filtering change rather than requiring the team to redo their entire velocity-loss protocol from scratch.