Edge-deployed compressed sensing for artifact-sparse wearable biosignal streams

When we deploy wearable biosensors for continuous monitoring, we quickly confront a harsh reality: the data deluge. A single-channel ECG at 250 Hz generates over 21 million samples per day. Multiply that by multiple sensors—PPG, EEG, accelerometry—and the bandwidth, storage, and power demands become unsustainable. Traditional compression methods like lossy wavelet or differential encoding reduce data but add computational overhead that drains batteries. Compressed sensing (CS) offers an alternative: sample at sub-Nyquist rates directly at the sensor, then reconstruct the signal later. But CS is not a silver bullet. Its effectiveness depends critically on the signal being sparse in some domain—and on artifacts being minimal. This guide focuses on the niche but valuable scenario where biosignal streams are artifact-sparse, meaning motion and interference are low, and the physiological signal itself has a compact representation. We will walk through the theory, the algorithms, the deployment workflow, and the trade-offs, so you can decide if edge-deployed CS is right for your wearable system.

Why artifact-sparse biosignals are ideal for compressed sensing

Compressed sensing relies on two key properties: sparsity and incoherence. A signal is sparse if it can be represented by a small number of non-zero coefficients in some basis (e.g., wavelet for ECG, Gabor for EEG). Incoherence means the sensing basis (random projections) is uncorrelated with the representation basis. When both hold, we can reconstruct the signal from far fewer samples than the Nyquist rate.

For wearable biosignals, motion artifacts are the enemy of sparsity. A clean ECG segment has a sparse wavelet representation—mostly zeros except for the QRS complexes and T waves. But add a sudden arm movement, and the artifact spreads energy across many coefficients, destroying sparsity. CS reconstruction then produces distorted signals or fails entirely. Therefore, CS is most viable when the signal is artifact-sparse: periods of low motion, such as during sleep, sedentary office work, or controlled exercise (e.g., stationary cycling). In these windows, the underlying physiology dominates, and CS can achieve high compression ratios (e.g., 10:1 to 20:1) with minimal error.

When to consider CS for wearables

We recommend CS for applications where the data collection environment is relatively controlled, or where artifact detection can gate CS activation. Examples include:

• Continuous glucose monitors (CGM) paired with heart rate variability (HRV) during rest periods
• Sleep-stage monitoring using EEG and EOG in a quiet bedroom
• Post-surgical recovery monitoring where patient movement is limited

Conversely, CS is a poor fit for free-living, high-activity scenarios unless combined with an artifact classifier that switches to full Nyquist sampling when motion is detected. This hybrid approach is common in research prototypes but adds complexity.

Core frameworks: how compressed sensing works on edge devices

At its heart, CS solves an underdetermined system: y = Φ x, where y is the compressed measurement vector (M samples), Φ is an M×N sensing matrix (M << N), and x is the original N-sample signal. Since M < N, there are infinitely many solutions. The CS insight is that if x is sparse in a basis Ψ (so x = Ψ s, with s having K << N non-zero entries), we can recover s by solving a convex optimization problem: minimize ||s||₁ subject to y = Φ Ψ s.

On an edge device (e.g., a Cortex-M4 or a low-power FPGA), we cannot run general-purpose solvers like interior-point methods. Instead, we deploy lightweight reconstruction algorithms that run either on the device itself (for real-time feedback) or on a gateway (e.g., a smartphone). The sensing matrix Φ is usually a random Bernoulli or Gaussian matrix, but for hardware efficiency, we often use a deterministic sparse matrix (e.g., each row has only a few ±1 entries) to reduce multiply-accumulate operations during encoding.

Three reconstruction algorithms compared

The choice of reconstruction algorithm affects reconstruction quality, latency, and energy. We compare three common approaches:

For edge deployment, we often use a variant of iterative thresholding because it requires only matrix-vector multiplications and thresholding operations, which are well-supported on fixed-point hardware. The trade-off is that ISTA may need hundreds of iterations to converge, but with a good initialization (e.g., zero-filling) and a warm start from the previous window, we can reduce iterations to 20–50.

Execution: a step-by-step workflow for deploying CS on edge

Deploying CS on a wearable involves four phases: offline design, firmware implementation, validation, and adaptive tuning. We outline each below.

Phase 1: Offline signal analysis

Collect representative clean biosignal data (e.g., 24 hours of ECG from a public database like PhysioNet). Determine the sparsity basis: wavelets (Daubechies 4 for ECG), Gabor frames for EEG, or discrete cosine transform for PPG. Compute the sparsity level K: the number of coefficients that capture 99% of the signal energy. For a 1-second ECG window (250 samples), K might be 10–15. Set the compression ratio M/N = 2K/log(N) as a starting point (e.g., M = 60 for N=250).

Phase 2: Firmware implementation

Implement the sensing matrix Φ as a lookup table of indices and signs to avoid floating-point multiplication. During each sampling window, the ADC samples are multiplied by ±1 and accumulated into M bins. This can be done in a DMA interrupt with minimal CPU load. For reconstruction, we implement a fixed-point iterative thresholding algorithm. Key steps:

1. Initialize s = 0 (in sparse domain)
2. Compute residual r = y - Φ Ψ s
3. Project residual onto sparse domain: g = Ψ^T Φ^T r
4. Apply soft thresholding: s = soft(s + μ g, λ)
5. Repeat until residual norm drops below threshold

We store Ψ and Ψ^T as precomputed matrices (if the basis is orthogonal) or as fast transform functions (e.g., FWT for wavelets).

Phase 3: Validation with artifact injection

Test the system with clean signals and then with simulated artifacts (e.g., additive Gaussian noise, baseline wander, abrupt shifts). Measure reconstruction SNR and root-mean-square error. If SNR drops below 20 dB, consider lowering the compression ratio or adding an artifact detection pre-step.

Phase 4: Adaptive tuning

On the device, monitor the reconstruction residual. If it spikes, the signal may no longer be sparse (artifact present). In that case, either discard the compressed block and request a full Nyquist sample, or increase the compression ratio (i.e., reduce M) temporarily. This adaptive CS approach is more robust but requires a feedback channel.

Tools, stack, economics, and maintenance realities

Implementing CS on a wearable requires careful selection of hardware and software. Microcontrollers with hardware multiply-accumulate (MAC) units, such as the Arm Cortex-M4 or M7, are suitable for iterative thresholding. For higher throughput, a small FPGA (e.g., Lattice iCE40) can accelerate matrix-vector multiplications. On the software side, we recommend using the CMSIS-DSP library for optimized fixed-point operations. For prototyping, MATLAB or Python (with PyWavelets and SPGL1) is invaluable for offline tuning.

Cost and energy trade-offs

CS reduces radio transmission energy (the biggest power drain in many wearables) because fewer bytes are sent. For a typical BLE module, transmitting 1 byte costs about the same as executing 10–100 CPU instructions. So a 10:1 compression ratio can cut transmission energy by 90%. However, the reconstruction energy on the gateway (smartphone) must be considered. If the gateway runs a greedy pursuit algorithm, it may consume 100 mJ per reconstruction, which is negligible compared to the wearable's savings. Overall, CS is most economical when the wearable is battery-constrained and the gateway has ample power.

Maintenance and model drift

Over time, a patient's physiology may change (e.g., due to medication, disease progression), altering the sparsity pattern. We recommend periodic recalibration: every few months, collect a full Nyquist sample for a few minutes, recompute the sparsity basis, and update the firmware. This is feasible if the device supports over-the-air updates.

Growth mechanics: scaling CS across device fleets

Once you have a working CS pipeline on one device, scaling to a fleet requires attention to variability. Not all patients have the same sparsity level. For example, a patient with atrial fibrillation will have a less sparse ECG than a healthy subject. To handle this, we can use a patient-specific sparsity basis learned from a short calibration recording. Alternatively, a universal basis (e.g., Daubechies 4) with a conservative compression ratio (e.g., 4:1) works for most.

Data pipeline for fleet learning

Collect compressed measurements from all devices, reconstruct on a cloud server, and analyze reconstruction quality. If a device consistently shows high error, flag it for recalibration. This feedback loop allows continuous improvement without manual intervention. We have seen teams reduce average compression ratio from 8:1 to 12:1 over six months by tuning per-device parameters.

Regulatory and clinical considerations

If the biosignal is used for clinical decision-making (e.g., arrhythmia detection), CS reconstruction must not introduce artifacts that mimic or mask pathologies. We recommend validating the CS pipeline against a gold-standard Nyquist-sampled dataset, measuring sensitivity and specificity for the target clinical event. In many cases, CS with 10:1 compression preserves diagnostic accuracy for heart rate variability and QRS detection, but subtle ST-segment changes may be distorted. Always consult the relevant regulatory guidance (e.g., FDA's guidance on software as a medical device) and include disclaimers that CS is for general information and not a substitute for professional medical advice.

Risks, pitfalls, and mistakes with mitigations

Even experienced teams fall into common traps. We list the most frequent ones and how to avoid them.

Assuming sparsity where it doesn't exist

The biggest mistake is applying CS to signals that are not sparse in any practical basis. For example, raw accelerometer data during walking is dense in both time and frequency domains. CS will produce poor reconstructions. Mitigation: always verify sparsity empirically. Compute the cumulative energy plot; if more than 10% of coefficients are needed to capture 99% energy, CS is unlikely to work well.

Ignoring quantization effects

Compressed measurements are real numbers; on an edge device, they are quantized to 8–12 bits. Coarse quantization introduces noise that can swamp the reconstruction. Mitigation: use dithering or increase the number of measurements M slightly to compensate. A rule of thumb is to add 10–20% more measurements if using 8-bit quantization.

Using a fixed sensing matrix for all channels

In multi-sensor wearables, using the same random matrix for each channel can create cross-channel interference. Mitigation: use independent random seeds for each channel, or use a block-diagonal sensing matrix.

Overlooking reconstruction latency

On a gateway, iterative algorithms may take tens of milliseconds per window. For real-time biofeedback (e.g., closed-loop stimulation), this latency is unacceptable. Mitigation: use a faster algorithm like OMP with a fixed number of iterations, or move reconstruction to the cloud with a buffered approach.

Mini-FAQ and decision checklist

We address common questions that arise when teams first consider CS for wearables.

Does CS reduce power consumption on the wearable?

Yes, primarily by reducing radio transmission. The encoding step (random projections) is computationally light—typically a few hundred MACs per window. The savings from transmitting fewer bytes far outweighs the encoding cost. However, if the device also performs on-board reconstruction (e.g., for local display), the power benefit may diminish.

What is the minimum compression ratio for acceptable quality?

For artifact-sparse ECG, we have seen acceptable quality (SNR > 25 dB) at M/N = 0.2 (5:1 compression). For EEG, where sparsity is lower, ratios of 2:1 to 3:1 are more realistic. Always validate with your specific signal.

Can CS be combined with other compression methods?

Yes. After CS reconstruction, the signal can be further compressed losslessly (e.g., with Huffman coding) if needed. But the primary gain comes from CS's sub-Nyquist sampling, not post-processing.

Decision checklist

• Is the signal sparse in a known basis? (wavelet, DCT, Gabor)
• Are motion artifacts rare or can they be detected?
• Is the wearable power-constrained and the gateway power-unconstrained?
• Is reconstruction latency acceptable (e.g., > 100 ms)?
• Can we tolerate occasional reconstruction failures?

If you answered yes to all, CS is a strong candidate. If you answered no to any, consider hybrid approaches or alternative compression.

Synthesis and next actions

Edge-deployed compressed sensing is not a universal solution, but for artifact-sparse wearable biosignal streams, it offers compelling advantages: reduced transmission energy, longer battery life, and lower bandwidth usage. The key is to validate sparsity empirically, choose a reconstruction algorithm that fits your hardware constraints, and implement adaptive mechanisms to handle artifacts when they occur.

To get started, we recommend the following next steps:

1. Collect 10 minutes of clean biosignal data from your target scenario.
2. Test sparsity in wavelet or DCT domain—if K < 0.1*N, proceed.
3. Simulate CS in Python with M = 2K*log(N) and measure reconstruction SNR.
4. Implement the encoder on your target MCU using fixed-point arithmetic.
5. Validate with artifact injection and tune M or algorithm parameters.
6. Deploy a pilot on 5–10 devices and monitor reconstruction quality over a week.

Remember that CS is a tool, not a magic wand. Use it where it fits, and combine it with other techniques (artifact detection, adaptive sampling) for robust performance. As edge hardware becomes more capable, the line between CS and traditional compression will blur, but for now, CS remains a valuable option for power-constrained, artifact-sparse applications.