Five vitals on one wrist: the interference problem in multi-parameter wearables

Flat illustration of a wrist wearing a monitoring bracelet with a wide inflatable cuff band, with five physiological signal traces including an ECG waveform converging by arrows into the device

Five vitals on one wrist: the interference problem in multi-parameter wearables

A remote patient monitoring bracelet that measures blood pressure, ECG, oxygenation, pulse, and skin temperature looks on a requirements document like five independent subsystems sharing a battery. In the enclosure it behaves like five subsystems actively degrading each other, and the architecture that survives is the one built around that fact rather than around the sensor list.

OVA Solutions is a team of experienced medical device hardware developers, 62 engineers who have taken more than 200 devices from concept to production. The program described here was full-cycle: requirements, concept, product and industrial design, mechanical and PCB design, embedded software, production, assembly, and quality control. Blood pressure was measured the conventional way, with an inflatable wrist cuff and an oscillometric algorithm, rather than through a cuffless optical estimate. The device ran Yocto Linux on an i.MX8M with containerized applications, dual-band Wi-Fi, Bluetooth 5.0, and a server connection for remote data exchange and remote configuration.

Those two choices, a real cuff and a real application processor, are the entire story of the build.

What each sensor does to its neighbors

The cuff needs a pump. The pump is a motor bolted to the same chassis as an ECG analog front end and a set of photodiodes. While it runs, it injects mechanical vibration into the optical path and electrical noise into a signal chain designed to resolve microvolts. The practical outcome is that ECG and SpO2 cannot be sampled during inflation, which turns five concurrent measurements into a scheduled sequence.

Skin temperature has the more insidious version of the same problem. An i.MX8M running Linux with Wi-Fi active dissipates real power into a small aluminum and plastic volume, and that heat reaches the temperature sensor through the enclosure long before it reaches equilibrium. Without deliberate thermal isolation the device reports a body temperature that partly tracks its own network traffic. The fix is mechanical and belongs in the concept phase: a thermal break between the compute stack and the sensor pod, a sensor placed on a skin-contact island with its own conduction path, and a settling delay written into the measurement schedule.

The 5 GHz radio and the ECG front end have a cleaner version of the conflict, solved with shielding, layout discipline, and transmission windows that avoid the ECG capture window.

Interference matrix of the bracelet showing which subsystem degrades which, with the cuff pump coupling mechanically and electrically into the ECG and optical channels and the compute stack coupling thermally into the skin temperature sensor
Every sensor pair in the bracelet, and what one does to the other under real operating conditions. This matrix is cheap to build during architecture and expensive to discover during DFM.

None of these are exotic problems. All of them are cheap at architecture and expensive at DFM, which is the reason to enumerate them before the block diagram exists.

The scheduling decision drives everything downstream

Once measurements are sequenced rather than concurrent, the sequence becomes the specification that constrains the rest of the device. Measurement cadence sets duty cycle. Duty cycle sets the power budget. The power budget sets the cell size. The cell size sets the enclosure volume, and the enclosure volume sets whether the thing is wearable at all.

Constraint chain running from measurement schedule to duty cycle, power budget, cell size and enclosure volume, with published mass and thickness figures for a cuff bracelet and a smartwatch at the end of the chain
The measurement schedule looks like a firmware detail and sits upstream of the industrial design. Each step is fixed by the one before it.

The public reference point for volume is the Omron HeartGuide, the one wrist-worn device with an inflatable oscillometric cuff whose specifications are fully published: 115 g in a 48 mm case, 14 mm thick. Apple publishes the Watch Series 10 at 29 to 42 g and 9.7 mm, depending on case size and material. The cuff, the pump, and the band structure account for that difference, and no amount of electronics miniaturization recovers it.

Runtime splits along the same line. Aktiia, which estimates blood pressure optically without a cuff, publishes 6 to 15 days for its IP68 bracelet. The Corsano CardioWatch, built by Corsano Health and distributed by Medtronic, is published at up to 7 days. Devices carrying both continuous sensing and an application processor sit at the short end of that range.

This matters commercially more than it matters technically. Corporate programs frequently open with a requirement that reads “smartwatch form factor, clinical-grade blood pressure, one week of battery.” Those three are not simultaneously achievable with a cuff today, and a vendor who agrees to all three is committing the client to a discovery that will surface at month twelve.

Where the accuracy actually comes from

ISO 81060-2 sets the bar for a blood pressure device at a mean error within 5 mmHg and a standard deviation at or below 8 mmHg against reference measurement. Modern validated wrist devices clear it. A 2023 validation of the U60EH wrist monitor reported a systolic mean difference of 1.51 mmHg with a standard deviation of 6.48, and a diastolic mean difference of 0.44 mmHg with a standard deviation of 5.98. Wrist monitors from the early 2000s reported standard deviations near 9 to 10 mmHg against arm-cuff devices in the 5 to 6 range, which is the gap that closed over two decades.

What closed it was mostly not the algorithm. It was cuff mechanics, band material, inflation control, and consistency of fit. Omron’s own description of the HeartGuide band centers on a flexible synthetic material that inflates around the wrist rather than a conventional bladder.

The engineering consequence is a sequencing rule. Run the ISO 81060-2 validation against the real mechanical band, in the real enclosure, as early as a functional unit exists. Validating an algorithm against a bench cuff and then transferring it to production mechanics repeats the work, because the mechanics carry most of the variance.

Application processor or microcontroller

Most wearables run a low-power microcontroller because the power arithmetic is decisive. This device ran Linux with Docker containers, Qt for the interface, and Python alongside C.

The justification was integration rather than compute. The client required server-side data exchange, remote configuration of the device in the field, and the ability to update measurement applications independently of the firmware image. Containers on Linux deliver that directly. A microcontroller architecture delivers it through a custom protocol, a custom updater, and a custom deployment story that the team then owns for the life of the product.

That is a defensible trade, and it is a trade rather than an upgrade. It costs runtime, it costs thermal headroom next to a temperature sensor, and it adds a boot sequence to a device a clinician expects to respond immediately. The recommendation is to decide it explicitly against the integration requirement, write down the runtime cost in hours before committing, and stop treating a Linux wearable as the default modern choice.

The short version for a program director

Build the sensor interference matrix before the block diagram, listing every sensor pair and what one does to the other under real operating conditions. Convert that matrix into a measurement schedule during architecture, because the schedule sets the power budget and the power budget sets the enclosure. Put thermal isolation between compute and any thermal sensor into the mechanical concept rather than into DFM. Validate blood pressure against ISO 81060-2 on production mechanics as early as possible, since the band and fit carry more variance than the algorithm. Choose the processor class against the integration requirement, with the runtime cost written down in hours.

This device went through production, assembly, and quality control with the cuff intact, and that single decision fixed its mass, its runtime, and its measurement schedule together. A program that treats those three as independent requirements tends to discover, somewhere around the second enclosure revision, that they were always one requirement wearing three names.

Common questions

Why can a multi-parameter wearable not measure all five vitals at once?

Because the sensors interfere with each other. The cuff pump is a motor mounted to the same chassis as an ECG analog front end that resolves microvolts and a set of photodiodes reading a pulse waveform. While the pump runs it injects vibration into the optical path and electrical noise into the ECG chain, so ECG and SpO2 cannot be sampled during inflation. Five concurrent measurements become a scheduled sequence.

Why does a bracelet with a blood pressure cuff weigh more than a smartwatch?

The cuff, the pump and the band structure account for the difference. Omron publishes the HeartGuide, the one wrist device with an inflatable oscillometric cuff whose specifications are fully published, at 115 g in a 48 mm case, 14 mm thick. Apple publishes the Watch Series 10 at 29 to 42 g and 9.7 mm. Electronics miniaturization does not recover that gap.

Is wrist blood pressure accurate enough for clinical use?

Modern validated wrist devices clear ISO 81060-2, which sets a mean error within 5 mmHg and a standard deviation at or below 8 mmHg against reference measurement. A 2023 validation of the U60EH wrist monitor reported a systolic mean difference of 1.51 mmHg with a standard deviation of 6.48, and a diastolic mean difference of 0.44 mmHg with a standard deviation of 5.98.

What closed the accuracy gap between wrist and arm blood pressure monitors?

Mechanics rather than algorithms. Wrist monitors in the early 2000s reported standard deviations near 9 to 10 mmHg while arm-cuff devices sat in the 5 to 6 range. What closed that gap over two decades was cuff mechanics, band material, inflation control and consistency of fit. Omron’s own description of the HeartGuide band centers on the material that inflates around the wrist rather than on signal processing.

How does the compute stack corrupt a skin temperature reading?

By heating the enclosure. An i.MX8M running Linux with Wi-Fi active dissipates real power into a small aluminum and plastic volume, and that heat reaches the temperature sensor through the enclosure long before it reaches equilibrium, so the device reports a body temperature that partly tracks its own network traffic. The fix is mechanical: a thermal break, a sensor on its own skin-contact island, and a settling delay in the schedule.

When does a wearable justify Linux instead of a microcontroller?

When the integration requirement rather than the compute load calls for it. This device ran Yocto Linux on an i.MX8M with containers because the client needed server-side data exchange, remote configuration in the field, and measurement applications updated independently of the firmware image. That choice costs runtime, thermal headroom next to a temperature sensor, and boot time, so it should be decided against the integration requirement with the runtime cost written down in hours.


Sources: ISO 81060-2:2018 · validation criteria of ISO 81060-2, open access · U60EH wrist monitor validation, 2023 · Kikuya et al., wrist versus arm cuff accuracy, 2002 · Omron Healthcare, HeartGuide instruction manual · Apple Watch Series 10 technical specifications · Aktiia battery documentation · Corsano CardioWatch, distributed by Medtronic

If you are building something in this space, we are glad to look at it with you. Grab a slot on Lisa’s calendar at calendly.com/lisa-voronkova/30min, and if nothing there works, write to lisa@ovasolutions.com.