Parkinson's Tremor-Suppression EMG Cuff
Wearable system for real-time detection of Parkinsonian tremor using forearm EMG signals. Built Python simulation to validate signal processing approach and suppression triggers before hardware integration.
The clinical need
Parkinson's disease affects approximately 1 million people in the U.S., with resting tremor (4–8 Hz) being one of the most disabling symptoms. Tremor impairs fine motor tasks: writing, eating, grasping objects. This severely reduces quality of life. Current treatment options are limited. Pharmacological interventions have variable efficacy and side effects, while deep brain stimulation (DBS) is invasive, costly, and not accessible to all patients.
Non-invasive wearable solutions that can detect tremor onset in real time and trigger suppression mechanisms remain underdeveloped. A wearable EMG cuff capable of identifying tremor timing could enable counter-stimulation or mechanical dampening strategies, offering patients a low-risk intervention option.
Detection complexity
Parkinsonian tremor occurs at 4–8 Hz in forearm musculature. Detecting this narrow frequency band in real time from EMG requires robust signal processing. Noise, motion artifacts, and physiological variation complicate detection. Hardware-first approaches risk wasting time on non-viable signal chains.
Simulation-driven validation
Build a complete Python signal processing pipeline modeling the EMG flow through bandpass filter, feature extraction, and detection algorithm. Simulate tremor dynamics at known frequencies. Validate detection sensitivity and latency before any hardware fabrication. De-risk the hardware build.
System architecture
The wearable system follows a classical real-time biomedical signal processing flow. EMG sensors on the forearm capture muscle electrical activity, which is then processed through a tight filtering and feature extraction pipeline to identify tremor-specific signatures.
Design decisions
Bandpass filter centered at 6 Hz. Parkinsonian tremor peaks around 4–8 Hz. A Butterworth bandpass filter (6th order, 4–8 Hz) isolates tremor signatures while rejecting DC drift, low-frequency movement, and high-frequency noise. Real-time latency is critical. We target less than 100 ms end-to-end detection.
Multi-feature detection, not single threshold. RMS energy alone generates false positives from voluntary muscle activation. We combine RMS, spectral power concentration, and coherence across electrode channels. A tremor detection event requires all three features to align, raising specificity without sacrificing sensitivity.
Python simulation before hardware. We modeled tremor dynamics (sinusoidal + noise) and stress-tested the pipeline against realistic EMG corruption. Only after validating detection accuracy on simulated data did we move toward hardware fabrication. This iterative de-risking prevented costly false starts.
Interactive: See the filter in action
This visualization shows a live EMG signal being processed through a 6th-order Butterworth bandpass filter. Watch how the filter isolates the 5.8 Hz tremor signal from power line interference and motion artifacts.
This is a simplified simulation. The real device uses a 6th-order Butterworth bandpass filter at 4 to 8 Hz.
Regulatory and safety framework
This wearable medical device concept must adhere to international standards for medical device safety, biocompatibility, and electromagnetic compatibility. Understanding regulatory pathways early shapes architecture choices and validation protocols.
Electromagnetic compatibility (EMC) for medical electrical equipment. Critical for wearables operating near body and in varying EM environments.
Biocompatibility of medical devices. Electrode materials and skin-contact components must meet cytocompatibility and irritation thresholds.
Safety requirements for medical electrical equipment. Risk analysis, electrical safety, and design controls.
For novel wearable neurotech devices without predicate. Requires comprehensive design history file and clinical validation.
Signal processing targets
Validation metrics measure both the accuracy of our tremor detection algorithm and the real-time feasibility of the system.
Implementation stack
Technology rationale
scipy.signal: Production-grade filtering (Butterworth, Chebyshev, Bessel). We compared multiple designs for phase distortion and attenuation characteristics before settling on 6th-order Butterworth, offering excellent rolloff without excessive phase lag.
numpy for vector operations: EMG processing is array-heavy. numpy's C-backend ensures real-time throughput even with 1+ kHz sampling rates across multiple channels.
matplotlib for validation: Time-domain waveforms, FFT spectrograms, and filter response plots proved critical for debugging detection failures and tuning thresholds iteratively.
What this taught me
Simulating before building saves months
A week of Python modeling revealed that naive single-channel thresholding would produce unacceptable false positive rates. Multi-channel coherence checks added complexity but eliminated the problem. Hardware teams found this out the hard way. We caught it in simulation.
Biomedical signals are hostile
Textbooks show clean sinusoids. Real EMG is fractional-volt noise contaminated with motion artifacts, ECG cross-talk, and 60 Hz hum. Every design choice (filter order, feature set, threshold) had to survive adversarial noise tests before acceptance.
Regulatory thinking must start early
EMC, biocompatibility, and design controls are not afterthoughts. Building regulatory awareness into the signal processing design (choosing components with certified datasheets, documenting filter design rationale) streamlines later validation.
Post-Mortem
What I got wrong.
The simulation worked. But that doesn't mean every decision along the way was right.
The 6th-order Butterworth performed beautifully on my generated tremor signals: clean sinusoids plus Gaussian noise. When I later tested with publicly available EMG datasets that included real motion artifacts, the filter's performance dropped noticeably. Real forearm EMG during daily activities contains bursts of voluntary muscle activation that overlap the tremor band. My simulation didn't model that overlap, so the detection thresholds I'd tuned were too aggressive. I should have incorporated published EMG datasets from the start, not after the pipeline was "done."
The project was framed as "tremor detection and suppression," but I spent 90% of the time on detection. The suppression trigger was a binary output: detected or not. I never modeled what happens downstream. How fast does the pneumatic actuator respond? What happens if the detection is right but the suppression fires 200 ms late? Those questions matter for clinical viability, and I treated them as someone else's problem. In a real device program, the detection and actuation teams would need to co-design the latency budget from day one.
My metrics were sensitivity and specificity, reported as percentages. I never asked: what does a false positive actually do to the patient? If the cuff fires suppression during voluntary movement, it fights the patient's own muscles. That's not just annoying. It could cause injury or erode trust in the device within days. The cost of a false positive is categorically different from the cost of a false negative, and my evaluation framework treated them as symmetric. A clinical engineer would have caught that immediately.
Questions You Might Ask
Answers before the interview.
If I were screening this portfolio, these are the three questions I'd ask. So here they are, answered.
Because the signal processing pipeline is the highest-risk subsystem. If the filter design can't isolate tremor from noise at the frequencies we care about, no amount of good hardware saves the project. A week of Python modeling told us the detection approach was viable before we spent money on electrodes, ADCs, and PCB fabrication. The simulation also let us iterate on filter order, feature sets, and detection thresholds at a pace that hardware prototyping can't match. The tradeoff is that simulation can't catch everything (see "What I got wrong" above), but it de-risked the most expensive failure mode.
It wouldn't, not without significant rework. The simulation uses synthetic tremor signals that model the frequency content but not the variability of real Parkinsonian tremor. Real patients show intermittent tremor, variable amplitude, and co-occurring voluntary movement. The multi-feature detection approach (RMS + spectral power + coherence) is designed to handle that, but the thresholds would need recalibration on clinical recordings. If I continued this project, the next step would be validating against the PhysioNet Parkinson's tremor dataset before touching hardware.
Three things. First, validate against real EMG data from published datasets on day one, not after the pipeline is built. Second, model the full closed-loop system including suppression actuator dynamics, because detection latency and actuation latency are coupled. Third, bring in a clinician or movement disorder specialist early to pressure-test whether the detection sensitivity targets actually matter for patient quality of life. The 95% sensitivity target I set was an engineering number, not a clinical one. A neurologist might tell me 80% sensitivity with zero false positives during voluntary movement is more valuable than 95% sensitivity with occasional misfires.
Interested in this work?
I bring signal processing rigor, medical device regulatory depth, and a bias toward validation-before-build to every project. Looking for roles in wearable biomedtech, diagnostics, or neural interfaces.