Photoplethysmography (PPG) looks simple on a block diagram: an LED shines into the skin, a photodiode measures what comes back, and the small rhythmic change in that light follows blood volume with each heartbeat. In a wearable it is one of the hardest signals to get right, because the part you want is a tiny ripple riding on a large offset, in the presence of ambient light, movement, variable skin contact and a battery that cannot afford to leave the LED on.

This note walks through the signal chain stage by stage and what the firmware is responsible for at each one. It reflects the kind of work behind our smart ring and sleep coach projects, where signal quality and power budget had to be solved together. For the wider picture of how wearable constraints interact, start with wearable device firmware design constraints.

What you are actually measuring

The photodiode sees a large steady component, the light that is reflected or scattered by skin, tissue and bone and that does not change with the pulse, plus a much smaller pulsatile component caused by blood volume changes. The ratio of the two, often called the perfusion index, varies widely with the person, the body site, temperature and how the device is pressed against the skin. Everything downstream exists to extract that small component reliably.

Wavelength matters. Green light is commonly used for heart-rate sensing at the wrist, while red and infrared are used where oxygen saturation is estimated, because oxygenated and deoxygenated blood absorb them differently. Which one you choose, and at which body site, sets the signal strength you start with, and it is largely a hardware decision that firmware must live with.

The signal chain, end to end

raw photodiode current
  -> transimpedance amp + ADC           (analog front end)
  -> ambient-light subtraction          (done in the AFE or in firmware)
  -> DC removal + band-pass filter      (isolate the pulsatile component)
  -> motion reference (accelerometer)   (adaptive cancel or gate)
  -> peak / spectral tracking           (rate estimate with continuity)
  -> signal-quality index               (decide whether to trust it)
  -> output: value + confidence

Each stage is a place where signal can be lost for good. Information thrown away early, by saturation or aggressive filtering, cannot be recovered later by a smarter algorithm.

Stage 1: LED drive and the analog front end

Most of the controllable power in a PPG sensor is the LED current, so this stage is where signal quality and battery life collide. The analog front end converts photodiode current to a voltage, digitizes it, and in many integrated parts handles LED timing and ambient subtraction in hardware.

  • Avoid saturation first. If the front end clips on the large steady component, the pulsatile part is lost. Clipping is not always obvious in the output, so the firmware should detect it explicitly.
  • Use the full range without clipping. Too little signal wastes resolution; too much saturates. The goal is to keep the steady level inside the converter range with the ripple using as much of it as possible.
  • Pulse the LED, do not leave it on. The LED is lit only during short windows around each sample. The on-time per sample, the current, and the sample rate together set average power, and each is a lever.
  • Check settling. The front end needs time to settle after the LED switches. Sampling too early gives a value contaminated by the previous state.

Stage 2: ambient light and cross-talk

Sunlight and indoor lighting reach the photodiode too, and indoor lighting can flicker at mains-related frequencies. A standard approach is to take a measurement with the LED off just before or after the LED-on measurement and subtract it, so that slowly varying ambient light cancels. Many AFEs do this in hardware. Where they do not, the firmware must schedule the paired samples closely enough in time for the subtraction to be valid.

Mechanical design matters here as well: a light barrier between emitter and detector so that the photodiode sees light that has passed through tissue, not light that leaked across the surface of the device. Firmware cannot fix a poor optical path, but it can detect when the signal looks wrong and report it.

Stage 3: closing the loop with automatic gain control

Skin tone, fit, perfusion and temperature change the amplitude from one person to the next and from one minute to the next. A fixed LED current and gain will be wrong for someone. Production designs add a slow control loop that adjusts LED current and front-end gain to keep the signal in the usable range.

  • Make the loop slow relative to the pulse. If gain changes within a heartbeat, it distorts the waveform you are trying to measure. Adjust over many beats and avoid changing it during a measurement window.
  • Include the energy cost. A higher LED current for a hard-to-read user costs battery. Decide a ceiling and what the device does when it reaches it, such as lowering its confidence rather than draining the battery.
  • Mark gain changes in the data. Downstream algorithms need to know when a step in the signal was caused by the firmware, not the body.

Stage 4: filtering and getting the pulse out

The pulse rate of interest sits in a narrow band, roughly a Hz or two for a resting adult and several Hz for a high heart rate. A band-pass filter removes the slowly drifting baseline and high-frequency noise. On a microcontroller this is usually done with fixed-point or single-precision arithmetic, and the filter is chosen for its group delay and cost as much as for its frequency response. A filter that distorts the waveform shape can break features that depend on it.

Sampling rate is a trade-off the algorithm owner should set. Enough to represent the pulse waveform and the motion reference, no more, because each additional sample costs LED energy, processing and storage.

Stage 5: motion artifact, the dominant problem

Movement changes how the sensor couples to the skin and shifts blood in the tissue under it. The result can be much larger than the pulse and can sit at frequencies that overlap with it, for example during walking or running, where arm swing can resemble a heart rate. Simple filtering cannot separate the two.

The standard approach is to use an accelerometer as a reference for the motion, sampled in sync with the optical channel:

  • Adaptive cancellation. Use the accelerometer signal to estimate the motion component in the optical signal and subtract it. This works when the coupling between motion and artifact is reasonably stable and fails when it is not.
  • Spectral tracking with motion rejection. Compute the spectrum of both signals, identify peaks that line up with the motion frequency, and reject them. Tracking the previous estimate helps choose between competing peaks.
  • Gating. When motion is too large for any algorithm to recover the signal, say so and wait. A missing value is better than a wrong one, particularly if the number feeds a decision.

The key firmware requirement is time alignment. The optical and motion samples must share a clock or be timestamped consistently, or the cancellation will be working on mismatched data.

Stage 6: quality and confidence

The most important output of a PPG pipeline is not the number but how much to trust it. A signal-quality index can combine several cheap indicators: whether the front end was saturated, how large the pulsatile component is relative to noise, how well the waveform repeats from beat to beat, how much motion was present, and whether the device was worn at all.

That confidence should travel with the value to the app and the cloud. It lets downstream logic skip bad periods, as in the data-quality checks for off-body periods and dropout that matter so much in the sleep coach, rather than treating every sample as equally reliable.

Putting power back in

Because the LED and the radio are the main controllable power consumers, much of the design is about not sampling when it is not useful:

  • Reduce the duty cycle when the user is still and the signal is stable, and raise it during activity.
  • Sample continuously only where the use case needs it. Spot checks every few minutes are far cheaper than continuous sensing and are enough for many trend-based products.
  • Use the accelerometer, which is cheap to run, to decide when optical sensing is worth doing.
  • Do conditioning on the device and send results, not raw streams, as we did on the ring, because radio time is expensive. See power profiling firmware for how to measure it properly.

Implementation concerns on a small MCU

  • Deterministic timing. Sampling and LED timing should be driven by hardware timers and the sensor's own FIFO, not by software delays. Jitter in sample timing becomes noise in the spectrum.
  • Memory. Windowed spectral methods need buffers; size them against available RAM early, and consider processing in blocks.
  • Arithmetic. Choose fixed-point or floating-point deliberately, depending on whether the part has a hardware FPU, and test for overflow and precision loss.
  • Tests on recorded data. Save raw sensor traces from real users in different conditions and replay them through the algorithm on a host machine so changes can be compared. This is where the approach in firmware unit testing pays off.

Validating the result

Bench tests with a simulator prove the electronics work. They do not prove the product works on people. Validation needs a reference device and participants across skin tones, ages, body sizes and activities, covering rest, walking, exercise and sleep, with enough hours to capture the awkward cases. Report accuracy together with the fraction of time the device returns no value, because the two trade against each other.

If the output is intended to inform a health decision, the standard of evidence and the regulatory expectations change, and that should be settled before the design is frozen. See connected medical device regulatory basics.

Checklist before you commit to a design

  • Has the optical path been designed and tested with the intended body site and skin range?
  • Does the firmware detect saturation, loss of contact and gain changes?
  • Are optical and motion samples aligned in time?
  • What is the power cost at the worst-case user, and what happens at the ceiling?
  • Is confidence reported alongside every value?
  • Is there a library of recorded real-world traces to regress against?

Common questions

What is a PPG signal chain?

It is the sequence of stages that turns light reflected from skin into a heart-rate or similar measurement: LED drive and photodiode front end, ambient-light cancellation, gain control, filtering, motion-artifact reduction using an accelerometer, rate estimation and a signal-quality check.

Why is motion the hardest problem in wearable PPG?

Movement changes how the sensor couples to the skin and can create artifacts larger than the pulse and at overlapping frequencies, for instance arm swing during walking resembling a heart rate. Firmware typically uses an accelerometer as a reference to cancel or reject the motion component, or declines to report when the signal is unrecoverable.

How do you reduce PPG power consumption?

The LED is usually the biggest controllable load, so reduce its duty cycle and current, sample only as fast as the algorithm needs, take spot measurements instead of continuous ones where the use case allows, use the low-power accelerometer to decide when optical sensing is worthwhile, and process on the device rather than streaming raw data.

Why should a PPG pipeline report confidence?

Because a number without a confidence value hides bad data. A signal-quality index lets the app and cloud ignore periods with saturation, motion or poor contact instead of treating every sample as equally reliable.