This project implements a multi-mode cardiac pacemaker and external Device Controller-Monitor (DCM). The system was developed for MT 3K04 based on the Boston Scientific Pacemaker System challenge.
The pacemaker logic runs on a FRDM-K64F Freedom board, while the heart model is represented using an STM32 Nucleo board with supporting driver circuitry. Pacemaker control logic is modeled in MATLAB Simulink/Stateflow, and the DCM is built in Python with a graphical user interface, SQL-backed parameter storage, and UART-based serial communication.
This project is an academic embedded systems/control project and is not intended for clinical or medical use.
The goal of this project was to design, implement, and test a programmable pacemaker system with multiple pacing modes, real-time hardware interaction, and an external control interface.
The system consists of two major components:
-
Pacemaker Controller
- Runs on the FRDM-K64F board.
- Implements pacing logic generated from Simulink/Stateflow.
- Interfaces with sensing and pacing hardware.
-
Device Controller-Monitor (DCM)
- Python desktop application.
- Allows users to configure pacemaker parameters.
- Stores user credentials and programmed parameters.
- Communicates with the pacemaker through UART serial communication.
- Multi-mode pacemaker control logic
- MATLAB Simulink/Stateflow implementation
- Auto-generated embedded control code for FRDM-K64F
- Python-based DCM with GUI
- SQL-backed user and parameter storage
- UART serial communication between DCM and pacemaker
- Support for programmable pacing parameters
- Rate-adaptive pacing using accelerometer input
- Hardware-in-the-loop testing with a simulated heart platform
- Egram window for signal visualization
The pacemaker supports the following permanent pacing modes:
| Mode | Description |
|---|---|
| AOO | Atrial asynchronous pacing |
| VOO | Ventricular asynchronous pacing |
| AAI | Atrial demand pacing |
| VVI | Ventricular demand pacing |
| AOOR | Rate-adaptive atrial asynchronous pacing |
| VOOR | Rate-adaptive ventricular asynchronous pacing |
| AAIR | Rate-adaptive atrial demand pacing |
| VVIR | Rate-adaptive ventricular demand pacing |
| DDDR | Dual-chamber, rate-responsive pacing |
Each mode supports programmable parameters related to pacing rate, pulse characteristics, refractory periods, sensing, and rate adaptation.
Supported parameter categories include:
-
Pulse Parameters
- Pulse amplitude
- Pulse width
-
Rate Parameters
- Lower Rate Limit (LRL)
- Upper Rate Limit (URL)
- Maximum Sensor Rate (MSR)
- Atrial Refractory Period (ARP)
- Ventricular Refractory Period (VRP)
- AV delay
-
Rate-Adaptive Parameters
- Activity threshold
- Reaction time
- Recovery time
- Response factor
- Maximum sensor rate
Device Controller-Monitor
│
│ UART Serial Communication
▼
FRDM-K64F Pacemaker Controller
│
│ Pacing / Sensing Signals
▼
STM32 Nucleo Heart Simulator + Driver Circuitry
The DCM is responsible for programming and interrogating the pacemaker. The FRDM-K64F board runs the pacing logic and communicates with the heart simulator through sensing and pacing hardware interfaces.
The pacemaker controller is implemented on the FRDM-K64F Freedom board.
Responsibilities include:
- Running generated pacemaker control logic
- Receiving programmed parameters from the DCM
- Processing atrial and ventricular sensing inputs
- Delivering pacing outputs
- Supporting rate-adaptive pacing using accelerometer data
- Sending device status and Egram data back to the DCM
The heart simulator is implemented using an STM32 Nucleo board with driver circuitry.
Responsibilities include:
- Simulating atrial and ventricular heart activity
- Providing sensed signals to the pacemaker
- Receiving pacing pulses from the pacemaker
- Supporting hardware-in-the-loop validation of pacing modes
The pacemaker control logic is modeled using MATLAB Simulink and Stateflow.
The model is divided into three major sections:
Handles communication between the pacemaker and the external DCM.
Responsibilities include:
- Receiving programmed parameters
- Receiving selected pacing mode
- Handling serial communication inputs
- Processing accelerometer inputs for rate adaptation
Contains the main pacing decision logic.
Responsibilities include:
- Mode selection
- Atrial and ventricular pacing decisions
- Sensing and inhibition logic
- Refractory period handling
- Rate-adaptive behaviour
- AV delay timing
- Dual-chamber pacing coordination
Maps abstract pacing and sensing states to physical hardware pins.
Responsibilities include:
- Driving atrial and ventricular pacing outputs
- Controlling sensing and impedance-related outputs
- Driving LEDs and hardware indicators
- Mapping Simulink signals to board-level outputs
Rate-adaptive modes use accelerometer data to estimate patient activity and adjust pacing rate accordingly.
The rate-adaptive subsystem:
- Reads accelerometer input.
- Computes activity magnitude.
- Smooths the activity signal.
- Maps activity level to a target pacing rate.
- Adjusts pacing rate between the Lower Rate Limit and Maximum Sensor Rate.
- Uses reaction and recovery time settings to avoid abrupt rate changes.
This allows the simulated pacemaker to increase pacing rate during higher activity and gradually return to baseline during rest.
Each pacing mode is implemented using Stateflow states with pacing and timing logic.
Asynchronous pacing modes.
- Pace at a fixed interval derived from LRL.
- Do not respond to sensed cardiac activity.
- Alternate between charging and pacing states.
Demand pacing modes.
- Sense atrial or ventricular activity.
- Inhibit pacing when intrinsic activity is detected.
- Use refractory periods to prevent inappropriate sensing.
Rate-adaptive asynchronous modes.
- Extend AOO and VOO behaviour.
- Adjust pacing period based on activity-derived sensor rate.
Rate-adaptive demand pacing modes.
- Extend AAI and VVI behaviour.
- Include sensing, inhibition, refractory periods, and rate adaptation.
Dual-chamber rate-responsive pacing.
- Supports both atrial and ventricular sensing.
- Coordinates pacing between chambers.
- Incorporates AV delay.
- Uses rate-adaptive pacing behaviour.
The DCM is a Python desktop application used to configure, monitor, and communicate with the pacemaker.
Key features include:
- Tkinter-based graphical user interface
- User authentication
- Support for up to 10 users
- Secure password handling
- Per-user pacemaker parameter storage
- SQL database for users and parameters
- Mode-specific parameter editing
- Egram display window
- Serial communication over UART
- Pacemaker programming and interrogation
- Send/receive confirmation and communication status feedback
The DCM communicates with the pacemaker using UART.
The serial communication module supports:
- Parameter packing into byte arrays
- Parameter unpacking from received messages
- Pacemaker programming
- Pacemaker interrogation
- Communication status checking
- Device identity handling
- Error and confirmation feedback
pacemaker-controller/
├── dcm/ # Python DCM application, GUI, database, and serial communication
├── simulink/ # Simulink and Stateflow pacemaker models
├── firmware/ # Generated or embedded pacemaker code
├── docs/ # Reports, diagrams, and project documentation
├── tests/ # Test cases and validation notes
├── artifacts/ # Screenshots, plots, logs, and demo outputs
├── README.md
└── requirements.txt
Create and activate a virtual environment:
python -m venv .venv
.venv\Scripts\activateInstall dependencies:
pip install -r requirements.txtIf a requirements file is not available, install the core dependencies manually:
pip install pyserialTkinter and SQLite are typically included with standard Python installations.
From the repository root, run the DCM application:
python dcm/main.pyIf the project uses a different entry-point file, run the main GUI script inside the dcm/ folder.
Connect the system hardware before programming or interrogating the pacemaker:
- Connect the FRDM-K64F pacemaker board to the computer.
- Connect the STM32 Nucleo heart simulator to the pacemaker driver circuitry.
- Confirm that the correct serial port is selected in the DCM.
- Program or interrogate the pacemaker through the DCM interface.
Open the Simulink model in MATLAB and deploy it to the FRDM-K64F board.
General workflow:
- Open MATLAB.
- Open the pacemaker Simulink model.
- Confirm hardware support package settings.
- Build and deploy the model to the FRDM-K64F.
- Use the DCM to configure mode and parameters.
- Validate pacing behaviour using the heart simulator.
Testing covered both pacemaker control logic and DCM functionality.
Test cases were developed for:
- AOO
- VOO
- AAI
- VVI
- AOOR
- VOOR
- AAIR
- VVIR
- DDDR
Tests verified pacing timing, sensing response, refractory behaviour, rate adaptation, and mode-specific outputs.
The DCM was tested for:
- User login and authentication
- User creation limits
- Parameter validation
- Mode selection
- Database storage and retrieval
- Serial communication failures
- Known and unknown pacemaker connection scenarios
- Egram window behaviour
- GUI responsiveness
Serial communication tests included:
- No connected device
- Known device connected
- New device connected
- Parameter send and receive confirmation
- Interrogation response handling
- Error and timeout scenarios
- Implement all specified pacing modes.
- Support programmable pacing parameters.
- Use hardware-hiding abstractions through Simulink subsystems.
- Support sensing, pacing, and refractory timing.
- Implement rate-adaptive behaviour using accelerometer input.
- Communicate with the DCM over UART.
- Display and edit programmable parameters.
- Store user credentials and mode parameters.
- Support up to 10 users.
- Communicate with the pacemaker through serial telemetry.
- Display communication status.
- Provide Egram visualization.
- Support pacemaker programming and interrogation.
The project demonstrates a working academic pacemaker control system with embedded control logic, hardware-in-the-loop testing, and an external Python-based controller-monitor.
The implementation shows integration across:
- Embedded systems
- Model-based design
- State-machine control
- Serial communication
- GUI development
- SQL-backed parameter storage
- Hardware testing
- Faraaz Ahmed
- Manav Bal
- Daksh Mathur
- Armin Sound
- Gavin Carrol
- Manav Bal