RISETech x NUST BIOMISA
Wearable Epilepsy Monitor
EPIC, short for EPIlepsy Care, was a research stage wearable built to monitor generalized tonic clonic seizure events, log relevant sensor data, and notify caregivers through a connected mobile app. I developed it at RISETech with the BIOMISA group at The College of Electrical & Mechanical Engineering (CE&ME).
This was my first professional embedded project after university. As the Systems Design Engineer at RISETech, I was responsible for the design and implementation of this device, covering electronics architecture, schematic design, PCB layout, sensor integration, firmware, signal acquisition and filtering, BLE communication, battery and charging design, enclosure CAD, prototyping, testing, documentation, and supplier coordination.
Project Brief
- Type
- Medical research wearable prototype
- MCU
- Nordic nRF52832 BLE SoC
- Firmware stack
- nRF5 SDK, SoftDevice S132, and SEGGER Embedded Studio
- Sensing
- sEMG, 6-axis IMU, and PPG
- Form factor
- Biceps worn rechargeable armband
- My scope
- Electronics, firmware, power, enclosure, testing, and handoff
1.Why this device needed to exist
01 There was a real safety and caregiver awareness gap
To address generalized tonic clonic seizures. If a patient has repeated motor seizures while asleep, alone, or away from direct supervision, a caregiver may not know in time to respond. The point was not diagnosis or prediction. It was faster awareness, faster response, and better event visibility for the people looking after the patient.
That need is not marginal. The World Health Organization estimates that around 50 million people worldwide have epilepsy, and nearly 80% live in low and middle income countries where access to diagnosis, treatment, and follow up is often limited.
02 For caregivers and doctors
In most cases, life threatening seizures are preceded by less intense ones that patients often do not notice or report. We aimed to detect these smaller seizure events in time to alert a caregiver before a serious episode, so they could attend to the patient and provide the necessary care or medication sooner.
The device also needed to record event duration, frequency, and intensity. Patients may not remember events clearly, and caregivers may not witness every episode. Logging events created a more objective record for doctors when they were trying to understand the patient's condition and treatment needs.
03 The sensing approach had to fit the target seizure type
Generalized tonic clonic events were the right target because strong rhythmic muscle activity and body motion are much easier to observe with wearable muscle and motion sensing than subtler seizure types.
That is also where the wearable evidence is strongest. The ILAE/IFCN clinical practice guideline found high level evidence for automated detection of generalized tonic clonic and focal to bilateral tonic clonic seizures, while the evidence for subtler seizure types was much weaker.
04 Existing solutions did not solve the local access problem
Commercial devices proved the need was real, but they also highlighted the access gap. Systems like NightWatch+ and Empatica EpiMonitor already existed, but they were commercial, closed, and in some cases expensive or subscription based. A locally developed research platform would be more useful for experimentation, adaptation, and lower cost deployment.
EPIC had to become a real wearable system rather than just a sensor board. It needed to be small enough to wear, stable enough to capture useful signals, practical for everyday use, and robust enough to run from a rechargeable battery, stay connected to a phone, and hold up through real test sessions.
2.Challenges faced
01 Capture a useful signal from the body
The core sensing challenge was EMG. Generalized tonic clonic seizures often involve strong muscle activity, which made surface EMG a good candidate signal. It was also the noisiest signal in the system. Placement, skin contact, motion, and electrical noise could all degrade it.
The signal had to hold up on the body, not just on the bench. Getting there took repeated work on filtering, calibration, placement, and mechanical stability.
- Maintain stable electrode contact
- Reduce noise and motion artifacts
- Detect whether placement was good enough
- Capture high rate EMG without overwhelming the system
02 Use multiple sensors to improve detection accuracy
EMG alone was useful, but it did not provide enough context. The system also needed motion and physiological information, so EPIC combined sEMG, a 6-axis IMU, and a Photoplethysmography (PPG) sensor. The point was to improve detection quality, not just to add hardware.
Each signal had different noise behavior, sampling needs, and placement constraints. The EMG and IMU were the primary signals for detecting seizure related muscle contraction and arm movement, while PPG served as a supporting validation signal through heart rate and pulse related changes.
03 Turn a research prototype into something wearable
A research prototype can easily stay a collection of boards and wires. For EPIC, that was not good enough. It had to sit on the arm, run from a rechargeable battery, talk to a phone, and stay usable during real test sessions.
The enclosure, PCB shape, battery position, buttons, band design, and electrode contact all affected whether someone could realistically wear it for long periods. Ergonomics and mechanical iteration were core parts of the project, not a finishing step.
04 Keep the device small without making it hard to build and test
The main PCB shrank to roughly 0.5 x 2 inches while still carrying the nRF52832, power system, battery measurement, BLE communication, charging support, and sensor interfaces. In a wearable, every millimeter competes with comfort, wiring, charging access, and reworkability.
The final layout did not come from one clean design pass. It came from repeatedly testing physical arrangements until the electronics, enclosure, and sensor placement stopped fighting each other.
3.Technical approach
Hardware architecture
EPIC was built around the Nordic nRF52832, selected for its low power BLE capability and suitability for a compact wearable. The hardware combined a compact custom main PCB with a separate off the shelf EMG analog front end that I tuned heavily for this application.
The system integrated sEMG, a 6-axis IMU, a PPG sensor, a rechargeable 500 mAh LiPo battery, battery measurement, charging circuitry, and BLE communication. The complete prototype weighed about 150 grams and was shaped around a biceps worn form factor.
The firmware ran on Nordic's nRF5 SDK with SoftDevice S132 handling the BLE stack, and SEGGER Embedded Studio was used as the main development environment.
Early prototypes were more modular so controllers, sensors, and signal chain ideas could be changed quickly. Later versions moved toward the smaller integrated board and enclosure once the sensing approach was more stable.
Sensor acquisition and signal processing
The firmware sampled EMG at 1 kHz, and IMU and PPG at 200 Hz. The 1 kHz rate was chosen because EMG is usually treated as a signal that carries useful content up to roughly ~500 Hz, so the ADC rate needed to be at least twice that upper band if we wanted to preserve it cleanly. That is also the direction given by the ISEK reporting standard, SENIAM recommendations, and Peter Konrad's ABC of EMG. At 1 kHz, the Nyquist limit is 500 Hz, which lined up with the intended EMG bandwidth and meant anything above that had to be attenuated by the analog front end before the ADC.
The algorithm cycle itself ran inside the ADC callback, which kept the EMG sensor rate a stable 1 kHz rather than depending on a looser foreground loop. That helped keep acquisition, filtering, and feature extraction time-consistent from sample to sample.
On the wearable, I kept the work close to the sensors: acquisition, calibration, digital filtering, DSP, feature extraction, seizure detection, battery measurement, and BLE transmission. The mobile side handled further classification and analysis using the processed data and features coming from the wearable.
The EMG signals took the most work because raw EMG was sensitive to placement, motion artifacts, skin contact, and electrical noise. In the early testing phase, upper arm placement over the brachial muscle gave the most usable signals, while other placements were noticeably less reliable. I used linear phase FIR filters designed with the Parks-McClellan algorithm so the signal could be cleaned without distorting timing more than necessary.
- EMG intensity
- Muscle spasm activity
- Motion patterns
- Placement and sensor quality indicators
Sensor fusion and BLE communication
The project used EMG, IMU, and PPG together because each sensor covered a different part of the problem. EMG captured muscle activity, the IMU captured motion and spasm context, and PPG added supporting physiological context.
The wearable used BLE GATT notifications to send processed sensor data, event data, and battery state to the app. I tuned bonding, advertising, and reconnection behavior so the system stayed usable during app connected testing instead of only under ideal conditions.
The intended prototype setup was a nearby phone, with an expected BLE range of about 2 meters during testing and demonstration.
Power and battery behavior
The device used a 500 mAh LiPo battery and was designed to run for at least one day. In practice, long duration test sessions reached about 30 hours.
I implemented battery level measurement, low battery alerts, and charging safety circuits as part of the device's battery management.
This included undervoltage, overvoltage and overcurrent protections.
4.Enclosure and wearable design
Mechanical design was part of the sensing system
The enclosure was not cosmetic. If the device did not sit correctly on the body, the electrodes would not maintain good contact and the signal would degrade. Mechanical design directly affected signal quality.
Placement and calibration had to work together
The device was worn around the biceps area because that gave the best balance between EMG signal quality, repeatable placement, and a wearable form factor. During the prototype phase, upper arm placement over the brachial muscle consistently produced the most usable EMG data.
I also implemented a placement and calibration workflow so the system could adapt to user-to-user variation and guide users toward a usable fit.
Iteration was constant
I designed the enclosure in SolidWorks and iterated it through 3D printing. In total, the project went through about 26 enclosure revisions and 5 hardware prototype versions. Those iterations refined curvature, component and battery placement, charging port and button access, internal wiring, and overall comfort.
Comfort still mattered
The final variant used an off the shelf elastic band and a locally made custom soft leather cover over the printed enclosure. That changed the feel of the prototype from a hard plastic electronics box into something users could realistically wear over long testing periods.
5.Testing and validation work
01 Continuous engineering testing
Testing was continuous throughout the project. I ran bench tests, signal checks, motion tests, BLE range checks, charging tests, battery runtime measurements, enclosure fit tests, long duration logging, false trigger exploration during normal activity, and pre clinical lab work.
02 Real users and real wear conditions
The prototype was tested with about 12 users during development. Long duration sessions reached roughly 30 hours. Those tests mattered because a good bench signal did not guarantee a stable signal on the arm, and a comfortable enclosure did not guarantee good electrode contact.
03 Daily development logs
I maintained daily development and testing logs with observations, plots, photos, logs, and engineering notes. Those records helped guide decisions across electronics, firmware, filtering, enclosure design, and placement strategy.
04 Useful as a research tool, not only a demo
The system could also collect raw data for offline work in MATLAB and Python. That made EPIC useful as a research tool because signal processing and algorithm work could continue off device and be compared against embedded behavior.
6.Outcome
By the end of my work, I had delivered a working wearable with custom hardware, integrated sEMG, IMU, and PPG sensing, 1 kHz EMG acquisition, 200 Hz IMU and PPG acquisition, DSP based signal conditioning, BLE GATT communication, rechargeable battery, and a refined biceps worn enclosure.
The final handoff gave RISETech and the BIOMISA team at NUST a working prototype they could take into further research and planned clinical verification. By that point, the electronics, firmware, mechanics, placement workflow, and test process had been worked through together instead of being left as separate problems.
7.Retrospectives
My intro to product firmware development
Coming out of university, firmware was not my strong side. I was far more confident in the broader mechatronics work and, within embedded, in hardware: schematics, PCB layout, signal chains, power design, and physical integration. Most of that confidence came from freelancing as an embedded hardware engineer through the second half of my bachelors degree.
Firmware, by contrast, looked harder than hardware, and I had quietly decided I would not be good at it. EPIC proved me wrong. With no punishing requirements or strict timelines hanging over it, the project gave me room to actually enjoy writing firmware and to find it far more approachable than I had feared.
An early EPIC firmware snapshot: the whole device state machine, including BLE transmissions, was running inside the ADC ISR.
The code itself was a mess though. The snippet above is a small sample: the entire device state machine, BLE transmissions included, lived inside the ADC ISR, with magic numbers everywhere and dozens of flags and configuration values scattered across the file. It moved the prototype forward, but it is not how I would structure firmware today.
What it was not, was functionally bad. The sensing and detection algorithm could track drifting baselines, flag bad placement or sensor removal almost immediately, hold a stable data rate, and accept rudimentary remote configuration from the mobile app during testing. The capability was all there, but the structure around it was simply immature.
This was the project where I stopped treating firmware as something beyond me. It became the stepping stone into my later work at MRS.
The technical carryover was real
The signal work carried forward directly. The acquisition, filtering, and bio signal processing I learned here paid off on the Smart Insole Firmware project, where I again faced noisy real world sensor data, timing sensitive acquisition, and embedded DSP running close to the hardware.
The Nordic experience carried just as far. Cutting my teeth on the nRF52832 made the later jump to the nRF52840 almost frictionless, since the BLE model, toolchain habits, low power mindset, and general nRF52 development patterns all translated directly. That same track record is what made the case for an nRF52 part when the MTronic motion and light sensor needed a new platform after the ESP32-C3 hit a hard battery-life ceiling.