PlatformsFaststream SiliconFaststream RadioFaststream VisionConnected EdgeFaststream SecureMobility & Rail
ProductsSemiconductor IPWireless & RANEdge & GatewaysTracking & IdentificationSoftware & FrameworksConnected Systems
Technology5G protocol stackWireless and RF architectureBaseband and low PHYForward error correctionControl and data planeHigh-speed interfacesFirmware and bootSilicon root of trustSoftware-defined vehicleAutomotive OTAFunctional safety
AIAI Engineering ServicesEdge AI & Embedded MLComputer Vision EngineeringSensor Fusion & PerceptionAI Silicon & AccelerationMLOps for DevicesAI Visual InspectionPredictive MaintenanceDriver MonitoringVideo Analytics & Safety
SolutionsSemiconductorIndustrial AIConnected ProductsAsset TrackingBluetooth AoA RTLSWearable TrackingAutomotive & MobilitySmart InfrastructureSecure IdentityWireless & SatellitePrivate 5GSmart WashroomsFuel ManagementSmart BuildingsWorker SafetyEnergy MonitoringSmart AgricultureSmart CityAutonomous PlatformsAssembly AutomationLiDAR Rail SafetyHardware Wallet
IndustriesSemiconductorTelecommunicationsIndustrial & ManufacturingAutomotive & MobilityTransportation & RailAerospace & DefenceHealthcare & MedicalEnergy & UtilitiesOil & GasRetailConsumer ElectronicsMedia & EntertainmentSmart Infrastructure & IoT
ServicesSystem Integration overviewASIC & SoC DesignRTL to GDSIIVerification methodologyDFT and silicon testLow-power designMixed-signal integrationDesign enablementFPGA DesignFPGA-to-ASIC ConversionAnalog, Mixed-Signal & RFHardware & High-Speed PCBEmbedded SoftwareCloud, OTA & Device ManagementManufacturing TransitionHow we engage
CompanyAbout FaststreamEngineering ExcellenceLeadership & OrganisationHow We EngageQuality & ComplianceStandards & EcosystemPartners & EcosystemTrust CentreLocations & DeliveryNewsroom & MediaCareersCase StudiesKnowledge CenterWhite PapersGlossaryNewsletterResources & Support
ContactStart a projectHow we engage
Talk to us
CONNECTED PRODUCT

On the wrist, the signal you want is buried in the motion you don't.

The body is a noisy place to take a measurement. A wrist- or body-worn sensor has to pull a small physiological signal out of constant motion, run for days on a tiny battery, and produce readings trustworthy enough to act on — three demands that pull against each other on the smallest of compute.

DomainConnected product, health wearable
PlatformsConnected Edge
ScopeSensing to trustworthy on-body reading
Binding constraintA trustworthy reading out of motion, on a tiny battery
DisclosureRepresentative programme; customer not named
CONTEXT

Where this started.

A body-worn health sensor measures something small — a pulse, an oxygenation, an activity signal — in a hostile place. The wearer moves constantly, the sensor shifts against skin, and ambient conditions change, so the raw signal is dominated by artefact. Pulling the real measurement out is a signal-processing problem before it is anything else.

And it has to do so within brutal constraints. The battery is tiny and days of life are expected, so the processing and the radio have to be miserly. The reading has to be trustworthy enough to inform a decision, which means knowing when it is unreliable rather than reporting a confident wrong number. And it all runs on the smallest of embedded compute.

So the firmware is engineered around that tension: motion-artefact rejection that recovers the signal, a power budget that buys days of life, and confidence-aware output that reports uncertainty honestly rather than a clean-looking guess.

CHALLENGES

4 problems, named.

Stated before any of them had an answer.

01

Motion buries the signal

On the body the wanted signal is small and the motion artefact is large; recovering the measurement from that is the core problem.

02

The power budget is tiny

Days of life on a small battery means the sensing, processing and radio all have to be miserly, which limits what the firmware can do.

03

A wrong reading is worse than none

If the measurement can inform a decision, a confident wrong value is dangerous; the system has to know when it is unreliable.

04

Compute is minimal

The artefact rejection and processing have to run on the smallest embedded compute, so the algorithms have to fit, not just work.

ARCHITECTURE

How it was built.

WEARABLE, SIGNAL FROM MOTIONSENSEOn-body sensorSignal amid artefactMotion referenceArtefact characterisedContact qualityKnown, not assumedRECOVERArtefact rejectionSignal pulled outOn-device processingFits tiny computeConfidenceReliability knownREPORTTrustworthy readingOr flagged uncertainLow-power radioDays of lifeSecure, privateBody data protected

The measurement is small and the motion is large. The firmware's job is recovering a trustworthy reading from that — on days of battery and minimal compute.

CONTRIBUTION

What Faststream did.

The scope of the work, rather than a capability list.

WHAT WAS HARD

The parts that consumed the schedule.

Rarely the subsystem that sounds difficult.

01

Recovering the signal

Pulling a small measurement out of large, variable motion artefact is the central difficulty, and it has to work across wearers and activities.

02

Doing it on nothing

The artefact rejection has to run on minimal compute within a tiny power budget; algorithms that work on a workstation have to be made to fit.

03

Honest uncertainty

Building a system that reports its own unreliability, rather than a clean guess, is harder and more important when a reading can inform a decision.

04

Life versus fidelity

More processing and more frequent sensing improve the reading and cost battery; resolving that trade for days of life is the design.

OUTCOME

What resulted.

Signal recovered

A usable physiological measurement pulled from motion-dominated raw data.

Days of life

A power budget that delivers the expected battery life on a small cell.

Honest readings

Output that flags its own uncertainty rather than reporting confident errors.

Private by design

Body-worn data protected on the device and in transit.

Confidentiality

Customer projects are presented at property, capability, outcome and integration level. Customer names, internal architecture, confidential deliverables and commercial terms are not disclosed. Where a detail would identify a customer it is omitted rather than approximated. More is available under a non-disclosure agreement, within the limits the customer has agreed.

PRODUCTS AND CAPABILITY USED

What this was built from.

Every item links to its own page.

WHERE THIS APPLIES

Industries this serves.

COMMON QUESTIONS

Questions this programme gets asked.

01

Why is motion the central problem for a wearable?

Because on the body the signal you want is small and the motion around it is large. The wearer moves constantly, the sensor shifts against the skin, and those movements produce artefact that can dwarf the physiological signal being measured. Recovering the real measurement from that noisy, motion-dominated data is a signal-processing problem that has to work across different wearers and activities — and it is the core of what makes a wearable trustworthy rather than merely present.

02

Why does it matter that the device reports uncertainty?

Because a reading that can inform a health decision must not be confidently wrong. There are moments — heavy motion, poor contact — when the signal simply cannot be recovered reliably, and the safe behaviour is to flag the reading as uncertain rather than emit a clean-looking number that happens to be wrong. Building that confidence awareness in is what separates a device whose readings can be acted on from one that occasionally misleads.

03

Why is the power budget so restrictive?

Because users expect a small, comfortable device to run for days without charging, and the battery that fits on the body is tiny. That forces the sensing, the artefact-rejection processing and the radio to all be miserly, and it limits the compute available for the signal processing. Much of the firmware design is resolving the tension between doing enough processing to get a trustworthy reading and doing little enough to reach the expected battery life.

FOUND THIS USEFUL?

Pass it on.

Written for engineers. Share it with one.

ShareLinkedIn
KEEP READING

Related work.

BUILD WITH FASTSTREAM

Bring us the difficult part.

Tell us the specification, the constraint and the deadline. Programmes that cross silicon, radio, embedded and AI are where Faststream is strongest.