Pacemaker

A comprehensive dual-chamber, rate-adaptive pacemaker system developed. The system integrates a Simulink-based pacemaker controller running on an FRDM-K64F microcontroller with a Python-based Device Controller-Monitor (DCM) application, implementing clinical-grade bradycardia pacing support across nine operating modes.

---

Table of Contents

1. System Overview
2. Pacing Modes Implemented
3. Technical Architecture
4. Hardware Specifications
5. Rate-Adaptive Algorithm
6. Serial Communication Protocol
7. DCM Software Structure
8. Testing & Verification
9. Skills Learned & Applied
10. Acknowledgements
11. Additonal In Depth Details

---

🎯 System Overview

Primary Function

A pacemaker system designed to provide bradycardia pacing support through:

• Dual-chamber pacing (atrium and ventricle coordination)
• Rate-adaptive pacing (accelerometer-based activity tracking)
• User diagnostics via Device Controller-Monitor (DCM)

Clinical Context

Bradycardia is defined as a condition where the heart beats slower than 60 BPM, leading to dizziness, fatigue, and reduced cardiac output. This system delivers timed electrical pulses to the heart chambers to maintain a consistent, healthy heart rate while allowing physicians to monitor and adjust therapy through the DCM.

System Components

Component	Description
Pacemaker (Pulse Generator)	Simulink/Stateflow model compiled and deployed to FRDM-K64F microcontroller with custom pacemaker shield
Device Controller-Monitor (DCM)	Python/Tkinter GUI application for clinicians to program parameters, view egram data, and monitor system status
Communication	UART serial protocol (57600 baud) for bidirectional data exchange
Rate Adaptation	3-axis accelerometer tracks patient activity to adjust pacing rate dynamically

---

⚙️ Pacing Modes Implemented

NBG (NASPE/BPEG) Generic Code

Position	Category	Letters
I	Chamber(s) Paced	O (None), A (Atrium), V (Ventricle), D (Dual)
II	Chamber(s) Sensed	O (None), A, V, D
III	Response to Sensing	O (None), T (Triggered), I (Inhibited), D (Dual)
IV	Rate Modulation	O (None), R (Rate-Adaptive)

Supported Modes

Mode	Pacing Chamber	Sensing Chamber	Response	Rate Adaptive	Description
AOO	Atrium	None	None	❌	Asynchronous atrial pacing
VOO	Ventricle	None	None	❌	Asynchronous ventricular pacing
AAI	Atrium	Atrium	Inhibit	❌	Demand atrial pacing
VVI	Ventricle	Ventricle	Inhibit	❌	Demand ventricular pacing
AOOR	Atrium	None	None	✅	Rate-adaptive asynchronous atrial
VOOR	Ventricle	None	None	✅	Rate-adaptive asynchronous ventricular
AAIR	Atrium	Atrium	Inhibit	✅	Rate-adaptive demand atrial
VVIR	Ventricle	Ventricle	Inhibit	✅	Rate-adaptive demand ventricular
DDDR	Dual (A+V)	Dual (A+V)	Dual (T+I)	✅	Rate-adaptive dual-chamber demand

Bonus Mode: DDDR with proper AV delay and pushbutton ventricular inhibit

---

🏗️ Technical Architecture

Simulink Components

The pacemaker controller consists of six coordinated modules:

Module	Function
COM_IN	Receives parameter updates from DCM via UART, decodes bytes, updates programmable parameters
COM_OUT	Packages parameters and egram data for transmission to DCM
BRADYCARDIA_MODES	Stateflow chart with FSMs for all nine pacing modes (AOO, VOO, AAI, VVI, AOOR, VOOR, AAIR, VVIR, DDDR)
PIN_ASSIGNMENTS	Hardware abstraction layer isolating clinical algorithms from microcontroller I/O
RATE_ADAPTIVE	Processes accelerometer data through DSP pipeline; implements rate-adaptive algorithms
DEFAULT_VALUES	Provides initial system parameters when no external DCM input is received

DCM Components

A modular Python application with clear separation of concerns:

Module	Purpose	Key Functions
user_management.py	Secure multi-user authentication with SHA-256 hashing	register_user(), authenticate_user(), list_users(), remove_user()
params.py	Parameter dataclass with validation against safe operating ranges	validate(), save_parameters(), load_parameters()
modes.py	Pacing mode parser with dynamic mode interpretation	parse_mode(), list_modes()
egram.py	Egram data buffer with circular buffer storage	add_sample(), get_recent(), get_all(), clear()
serial_interface.py	UART communication handler with packet encoding/decoding	Connect(), Disconnect(), Send_parameters()
dcm_gui.py	Complete Tkinter GUI with mode selection, parameter config, serial control, egram display	Full application controller

Hardware Abstraction Layer

Critical design principle: Hardware Hiding through dedicated Simulink subsystem.

Functional Command: "Pace the Ventricle" ↓ Hardware Abstraction Layer translates to:

1. Ensure PACE_CHARGE_CTRL = LOW (disconnect PWM from patient)
2. Set PACE_GND_CTRL = HIGH (complete return path)
3. Set VENT_PACE_CTRL = HIGH (discharge capacitor through ventricle)

Benefits:

• Core Stateflow logic remains hardware-independent
• Pin map changes confined to single subsystem
• Enhanced maintainability and portability

---

🔌 Hardware Specifications

Microcontroller: FRDM-K64F

Specification	Details
Processor	ARM Cortex-M4
Operating Voltage	2.97V - 3.63V
Bus Speed	16MHz
Communication	USB (OpenSDA), UART

Pin Mapping (Hardware Abstraction Layer)

K64F Pin	Direction	Logical Function	Description
D0	Input	ATR_CMP_DETECT	Digital input indicating sensed atrial event
D1	Input	VENT_CMP_DETECT	Digital input indicating sensed ventricular event
D2	Output	PACE_CHARGE_CTRL	Enable/disable main pacing capacitor charging
D3	Output	VENT_CMP_REF_PWM	PWM threshold for ventricular sense comparator
D5	Output	PACING_REF_PWM	PWM voltage level for pacing capacitor (controls amplitude)
D6	Output	ATR_CMP_REF_PWM	PWM threshold for atrial sense comparator
D8	Output	ATR_PACE_CTRL	Switch activation for atrial pacing
D9	Output	VENT_PACE_CTRL	Switch activation for ventricular pacing
D10	Output	PACE_GND_CTRL	Ground connection for electrode tips
D13	Output	FRONTEND_CTRL	Enable sensing circuitry for both chambers
A0	Input	ATR_SIGNAL	Raw filtered atrial electrogram
A1	Input	VENT_SIGNAL	Raw filtered ventricular electrogram

Key Programmable Parameters

Parameter	Units	Range	Nominal	Description
Lower Rate Limit (LRL)	ppm	30-175	60	Minimum guaranteed pacing rate
Upper Rate Limit (URL)	ppm	50-175	120	Maximum ventricular tracking rate
Atrial Amplitude	V	0.5-7.0	3.5	Voltage amplitude of atrial pulse
Ventricular Amplitude	V	0.5-7.0	3.5	Voltage amplitude of ventricular pulse
Pulse Width	ms	0.1-1.9	0.4	Duration of pacing pulse
ARP	ms	150-500	250	Atrial refractory period
VRP	ms	150-500	320	Ventricular refractory period
Reaction Time	sec	10-50	30	Rate acceleration time
Recovery Time	min	2-16	5	Rate deceleration time
Response Factor	-	1-16	8	Activity-to-rate mapping slope
Activity Threshold	-	1-7	4	Minimum activity to trigger rate change

---

🔬 Rate-Adaptive Algorithm

A mathematically rigorous signal processing pipeline converts accelerometer data to pacing rate adjustments:

Step 1: Accelerometer Data Processing

Step 1: Accelerometer Data Processing

Raw triaxial data: [1×3] vector in g (9.8 m/s²) Vector magnitude: ||A|| = √(x² + y² + z²) Moving average filter: attenuates high-frequency noise Signal normalization: [0,8] → [0,6] via linear scaling

Step 2: Rate Response Algorithm

If activity_level > activity_threshold: desired_rate = activity_level × response_factor × k + LRL where k = (MSR - LRL) / (activity_threshold_max × (response_factor_max - 1)) with constants: activity_threshold_max = 6, response_factor_max = 16 Else: desired_rate = LRL

Step 3: Temporal Response (1ms Time Steps)

Reaction Rate = (MSR - LRL) / (1000 × reaction_time) [ppm/ms] Recovery Rate = (MSR - LRL) / (60 × 1000 × recovery_time) [ppm/ms]

State Machine Logic:

• Active State (activity > threshold):
  • If current < desired: current += ReactionRate
  • If current > desired: current -= ReactionRate
• Recovery State (activity ≤ threshold):
  • If current > LRL: current -= RecoveryRate

---

📡 Serial Communication Protocol

Packet structure (34 bytes total):

Field	Size	Description
SYNC	1 byte	Start byte (0x16)
FN_CODE	1 byte	Read (0x22) / Write (0x55)
Data	28 bytes	Programmable parameters
Checksum	4 bytes	Error detection

Data Encoding:

• Little-endian storage for multi-byte values
• Type-casting: uint8, uint16, single (float)

COM_IN Module

Uses a serial receive block corresponding to the FRDM-K64F. Takes a data length of 34 bytes, counting a start byte, a read/write byte, and the parameters. Once the sync word byte is received, it either:

• Write byte sent: Each value gets defined from the DCM and typecasted to a new type
• Read byte sent: send_params() function is called from COM_OUT block, packing all data into uint8 before transmission

COM_OUT Module

Transmits both programmable parameters and electrocardiogram streaming data to the DCM simultaneously. All parameters that are uint16 or single experience byte packing before transmission.

---

📁 DCM Software Structure

DCM/
├── gui/ # Frontend Display
│ ├── init.py # Package initialization
│ ├── dcm_gui.py # Main GUI application
│ └── tkinter_demo.py # Tkinter example/reference
├── core/ # Backend Logic
│ ├── init.py # Package initialization
│ ├── user_management.py # User registration & authentication
│ ├── params.py # Parameters dataclass with validation
│ ├── modes.py # Pacing mode parser
│ ├── egram.py # Egram data buffer & structures
│ └── README.md # Core module documentation
├── storage/ # Persistent Local Files
│ ├── users.json # Registered users with hashed passwords
│ └── params.json # Saved pacemaker parameters
├── tests/ # Unit Test Benches
│ ├── init.py # Test package initialization
│ ├── test_user_managment.py # User management tests
│ ├── test_params.py # Parameter validation tests
│ ├── test_modes.py # Mode parsing tests
│ └── test_egram.py # Egram functionality tests
├── docs/
│ └── README.md # Additional documentation
├── run_dcm.py # Application launcher script
├── README_GUI.md # GUI documentation & usage guide
└── .gitignore # Git ignore rules

---

🧪 Testing & Verification

DCM Testing (pytest suite)

Module	Tests	Description
user_management	6 tests	User registration, authentication, 10-user limit, deletion
params	4 tests	Parameter validation, invalid LRL/URL rejection
modes	4 tests	Mode parsing, dynamic future mode interpretation
egram	4 tests	Sample addition/retrieval, circular buffer behavior
serial_interface	1 test	UART transmission verification

Simulink Testing (HeartView Test Suite)

Each of the 9 modes underwent systematic testing:

Test Category	Cases	Description
Rate Boundary	5 tests	Testing at LRL (60 BPM), mid-range (90 BPM), URL (120 BPM), below LRL (30 BPM), above URL (180 BPM)
Heart Off	1 test	No natural heart activity, verify continuous pacing
Rate Adaptive	3 scenarios	Walking, jogging, running activity levels
Parameter Change	1 test	Verify response to modified response factor/activity threshold

Sample Test Case: DDDR Mode

Test	Purpose	Input	Expected	Result
#12	Verify AV delay timing	Modified AV delay value	Ventricular pacing shifts accordingly	✅ Pass
#13	A PACE, V PACE	No intrinsic activity	Sequential AP + VP with AV delay	✅ Pass
#14	A PACE, V SENSE	Intrinsic ventricular activity	AP delivered, VP inhibited	✅ Pass
#15	A SENSE, V PACE	Intrinsic atrial activity	Atrial sensed, VP after AV delay	✅ Pass
#16	A SENSE, V SENSE	Full intrinsic activity	Complete inhibition of pacing	✅ Pass

---

📚 Skills Learned & Applied

Embedded Systems & Model-Based Design

• Simulink/Stateflow Development - Designed and implemented complex FSMs for clinical pacing modes
• Model-Based Design - Used Simulink as single source of truth with automatic C code generation
• Hardware Abstraction - Implemented hardware hiding for pin mapping and shield control sequences
• Real-Time Systems - 1ms time-step deterministic state machines with hard real-time constraints
• Microcontroller Programming - FRDM-K64F ARM Cortex-M4 deployment via Simulink Coder

Software Engineering

• Safety-Critical Development - Designed with patient safety as paramount concern
• Modular Architecture - Separation of concerns with high cohesion, low coupling
• Python GUI Development - Tkinter application with professional styling and user experience
• Serial Communication - UART protocol implementation with error detection and recovery
• Data Validation - Comprehensive parameter range checking with safety boundary enforcement
• Secure Authentication - SHA-256 password hashing and session management
• Testing & Verification - pytest unit testing, HeartView functional testing

Hardware & Electronics

• Circuit Design - Understanding of pacemaker shield sensing and pacing circuitry
• PWM Control - Pulse Width Modulation for analog voltage generation
• Pin Mapping - GPIO configuration and hardware abstraction
• Timing Analysis - Pulse width, amplitude, and refractory period control

Clinical & Domain Knowledge

• Cardiac Conduction System - Understanding of SA node, AV node, and cardiac electrophysiology
• Pacing Modes - NBG code interpretation and clinical applications
• Rate-Adaptive Algorithms - Accelerometer-based metabolic demand sensing
• Safety Standards - Clinical safety requirements for medical devices

Project Management

• End-to-End Development - From requirements analysis to final demo
• Technical Documentation - Comprehensive specification, design, and testing documentation
• Team Collaboration - Distributed work on Simulink and DCM components
• Version Control - Git for code management and collaboration

---

🙏 Acknowledgements

• Professor & TAs for guidance and support throughout the project
• Boston Scientific for the PACEMAKER System Specification (academic use)
• NXP for the FRDM-K64F microcontroller and Simulink support package
• HeartView Test Suite development team for the testing framework
• Group Members: Amaiam Ul Haque, Ayesha Dogar, Diego Verdin, Jumana Ismail, Meghan Garner, Mehr Bagga

---

Built with ❤️ for safety-critical embedded systems development and medical device engineering.

Additional In Depth Details

Part 1

Introduction

The purpose of the pacemaker system is to provide bradycardia pacing support through dual chamber pacing, rate adaptive pacing, and the provision of user diagnostics to better track a patient’s condition. Bradycardia is defined as a conditioned where the heart beats slower than 60 BPM, leading to dizziness, fatigue, and reduced cardiac output. The implementation of a pacemaker system will allow adjustment to the patient’s heart rate, through delivering timed electrical pulses into the chambers of the heart. This results in a consistent rate, with a healthier frequency. Furthermore, a pacemaker system allows for physician control and analysis through sensing the existing heart rhythms and providing necessary data, allowing a physician to adjust the machine as needed with a Device Controller-Monitor (DCM).

This deliverable establishes the core structure of the pacemaker system, operating as an integrated Pacemaker Design and DCM communicating over a serial interface. The goal is to develop the front-end GUI for the DCM and implement state flows for specified pacemaker modes in a permanent state for the Pacemaker Design, with these modes being AOO, VOO, AAI, and VVI, as well as their rate-adaptive versions AOOR, VOOR, AAIR, and VVIR, and a new DDDR mode. For said rate-adaptive modes, the system tracks patient activity using the on-board accelerometer and increases the lower rate limit for sufficient activity levels, accelerating the pacing to accommodate exercise and faster movement of a patient. Hardware hiding techniques are used to separate logic from physical device interfaces, allowing for adaptation in future deliverables. This scope includes expanding the DCM to support all required modes and parameters, as well as implementing serial communication to reliably transmit and receive information between DCM and Pacemaker. The system is capable of setting, storing, transmitting, and verifying programmable parameter data on the Pacemaker device.

In addition, the system is able to display egram data, be it atrial, ventricular, or both, upon user request. The GUI is used to display the data. This deliverable lays the foundation for full integration and testing in later stages while ensuring correct operation across all permanent and rate-adaptive pacing modes.

Requirements

2.2.1 DCM Requirements

Requirement	Status
DCM needs to store up to 10 unique users	Implemented in core/user_managment.py
DCM allows user registration and login	Implemented in GUI and user_managment.py
DCM provides data structures for programmable parameters	Implemented in core/modes.py
DCM provides data structures for egram storage	Implemented in core/egram.py
DCM validates parameter ranges	Validation function in modes.py follows appendix A
DCM should allow data persistence between sessions	User and settings are stored in JSON files under /storage
DCM should be tested	DCM was verified via pytest test suites
DCM should be able to connect to the pacemaker	Achieved with a menu that lets you select the port and connect/disconnect
DCM should be able to send programmable parameters to pacemaker	Achieved through a UART serial interface
DCM should showcase egram data	Button and specialized window to display a graph with the data.

Table 1. DCM Requirements

2.2.2 Simulink Requirements

Mode	Pacing Chamber	Sensing Chamber	Response to Sensed Event	Description
AOO	Atrium	None	None	Asynchronous atrial pacing
VOO	Ventricle	None	None	Asynchronous ventricular pacing
AAI	Atrium	Atrium	Inhibit	Demand atrial pacing
VVI	Ventricle	Ventricle	Inhibit	Demand ventricular pacing
AOOR	Atrium	None	None	Rate adaptive asynchronous atrial pacing
VOOR	Ventricle	None	None	Rate adaptive asynchronous ventricular pacing
AAIR	Atrium	Atrium	Inhibit	Rate adaptive demand atrial pacing
VVIR	Ventricle	Ventricle	Inhibit	Rate adaptive demand ventricular pacing
DDDR	Dual Chamber (Atrium and Ventricle)	Dual Chamber (Atrium and Ventricle)	Tracked	Rate adaptive dual chamber demand pacing with tracking

Table 2: Simulink Requirements

2.2.3 Parameter Effect on Behaviour

Mode Affected	Parameter	Resulting Design Behaviour
AOO, AAI, AOOR, AAIR, DDDR	ATR_PACE_CTRL	Sending a pace to the atrium.
VOO, VVI, VOOR, VVIR, DDDR	VENT_PACE_CTRL	Sending a pace to the ventricle.
AOO, AAI, AOOR, AAIR, DDDR	ATR_AMPLITUDE
VOO, VVI, VOOR, VVIR, DDDR	VENT_AMPLITUDE
AOO, AOOR, AAI, AAIR, DDDR	ATR_PULSEWIDTH	Defines interval between pulses to atrium.
VOO, VOOR, VVI, VVIR, DDDR	VENT_PULSEWIDTH	Defines interval between pulses to ventricle.
AAI, AAIR, DDDR	ATR_CMP_DETECT	Senses heart activity in atrium.
AAI, AAIR, DDDR	ARP	Interval after pulse in atrium where activity in atrium is ignored.
VVI, VVIR, DDDR	VENT_CMP_DETECT	Senses heart activity in ventricle.
VVI, VVIR, DDDR	VRP	Interval after pulse in ventricle where activity in ventricle is ignored.
AOOR, AAIR, VOOR, VVIR, DDDR	ADAPTED_RATE	Rate of pulses depending on activity threshold.
DDDR	FIXED_AV_DELAY	Interval between atrium pulse and ventricular pulse.
AOO, AOOR, AAI, AAIR, VOO, VVI, VOOR, VVIR, DDDR	LOWER_RATE_LIMIT	Minimum pulse rate.
AOO, AOOR, AAI, AAIR, VOO, VVI, VOOR, VVIR, DDDR	UPPER_RATE_LIMIT	Maximum pulse rate.
AOOR, AAIR, VOOR, VVIR, DDDR	REACTION_TIME	Speed at which pacemaker increases pacing rate in response to increased activity.
AOOR, AAIR, VOOR, VVIR, DDDR	RECOVERY_TIME	Speed at which pacemaker decreases pacing rate in response to decreased activity.
AOOR, AAIR, VOOR, VVIR, DDDR	ACTIVITY_THRESHOLD	How much movement must be detected before pacing rate gets increase.
AOOR, AAIR, VOOR, VVIR, DDDR	RESPONSE_FACTOR	How strongly pacing rate is increased once activity exceeds the threshold.
AOOR, AAIR, VOOR, VVIR, DDDR	RATE_SMOOTHING	Adjusts change in pacing interval by small steps, for smooth adjustment.

Table 3: Parameter Effects on Design Behaviour

Design

2.3.1 System Architecture

The system is architected into two primary, decoupled software components that will eventually communicate via a serial telemetry link:

1. Pacemaker (Pulse Generator): This constitutes the real-time critical subsystem. It is implemented as a Stateflow model within Simulink, which is compiled and deployed to the FRDM-K64F microcontroller. The microcontroller, coupled with the custom pacemaker shield, executes the pacing logic, processes sensed signals, and generates pacing pulses according to clinical requirements.

2. Device Controller-Monitor (DCM): This serves as the user-facing subsystem, implemented as a standalone application on a host computer. It provides a graphical user interface (GUI) for clinicians to program parameters, view system status, and request data. For this deliverable, the DCM operates as a front-end, with telemetry integration.

A foundational design principle applied to the Pacemaker subsystem is Hardware Hiding. This is implemented through a dedicated Hardware Abstraction Layer encapsulated in a Simulink Subsystem block. The purpose of this layer is to decouple the high-level, functional pacing logic (e.g., states for "Wait for Sense," "Pace Ventricle," "Start Capacitor Charge") from the low-level, specific, and sometimes complex sequences required to control the physical shield circuitry.

For example, the functional command "Pace the Ventricle" is translated by this abstraction layer into a precise, timed sequence of digital outputs:

1. Ensure PACE_CHARGE_CTRL is LOW (disconnecting PWM from the patient).

2. Set PACE_GND_CTRL HIGH to complete the return path.

3. Set VENT_PACE_CTRL HIGH to discharge the capacitor through the ventricle.

This design ensures that the core Stateflow logic remains clean, robust, and independent of the hardware implementation. Alterations to the pin map or underlying shield control sequences are confined to this single subsystem, significantly enhancing maintainability and portability.

Subsystem Integration and Communication

The architecture maintains clear separation of concerns between the major subsystems:

Simulink Pacemaker Controller implements the safety-critical pacing functions through several coordinated modules:

• COM_IN/COM_OUT Communication Modules manage all serial communication with the DCM, handling parameter updates, command processing, and diagnostic data transmission with comprehensive error checking and recovery mechanisms 

• BRADYCHARDIA_MODES Stateflow Chart encapsulates the complete set of finite state machines governing all supported pacing modes (AOO, VOO, AAI, VVI, AOOR, VOOR, AAIR, VVIR, DDDR), each implementing clinically validated timing cycles and response behaviors 

• PIN_ASSIGNMENTS Subsystem implements the hardware abstraction layer that provides complete isolation between clinical algorithms and microcontroller-specific input/output operations 

• RATE_ADAPTIVE Module processes accelerometer data through sophisticated digital signal processing pipelines and implements the rate-adaptive pacing algorithms with multiple configurable response characteristics 

DCM (Device Controller-Monitor) provides comprehensive clinical management capabilities through specialized components: 

• User Management Module handles secure multi-user authentication, registration, and session management with encrypted credential storage and access control policies 

• Parameter Management Module enables intuitive clinical configuration with comprehensive validation, safety boundary checking, and consistency verification across parameter interdependencies 

• Serial Communication Handler manages the telemetry interface with robust error detection, packet retransmission protocols, and connection state management 

• Egram Display System provides high-resolution real-time visualization of intracardiac electrogram signals with configurable display parameters and recording capabilities 

• Mode Configuration Interface guides clinicians through physiologically appropriate pacing mode selection with context-aware parameter recommendations and safety warnings 

This comprehensive architectural approach ensures that modifications, enhancements, or corrections to either major subsystem can be executed with minimal impact on the other, thereby facilitating independent development lifecycles, comprehensive testing strategies, and long-term maintenance while preserving overall system integrity and reliability. 

2.3.2 Programmable Parameters

To administer bradycardia therapy as needed, clinician programmable parameters have been implemented to allow for patient-specific control and delivery of pacing signals. The following table summarizes these programmable parameters.

Table 4: User Programmable Parameters

Programmable Parameter	Units	Nominal Values	Functionality
Mode	n/a	0, 1, 2, 3	Maps to each operating mode of the pacemaker. The mappings are as follows: AOO = 0, VOO = 1, AAI = 2, VVI = 3
Lower Rate Limit	ppm	30-175 (60)	Determines the minimum heart rate at which pulses may be delivered
Upper Rate Limit	ppm	30-175 (60)	Determines the maximum heart rate at which pulses may be delivered
Atrial Amplitude	V	3.5	Specifies the amplitude of the pulse delivered when pacing the atrium
Ventricular Amplitude	V	3.5	Specifies the amplitude of the pulse delivered when pacing the ventricle
Pulse Width	ms	1	Specifies the width of the pulse delivered when pacing either the atrium or the ventricle
ARP	ms	150-500 (250)	Specifies the time interval following an atrial event during which subsequent signals are temporarily ignored
VRP	ms	150-500 (320)	Specifies the time interval following a ventricular event during which subsequent signals are temporarily ignored
ATR CMP REF PWM	mV	0-100 (90)	Used to allow the PWM to charge the capacitor that sustains a constant voltage for comparison between noise and natural heart activity.
VENT CMP REF PWM	mV	0-100 (90)	Used to allow the PWM to charge the capacitor that sustains a constant voltage for comparison between noise and natural heart activity.
REACTION_TIME	ms	10000	Used so the accelerometer may determine the how the pacing rate is increasing. This is the time required to modify the maximum sensor rate lower rate limit to upper rate limit.
RECOVERY_TIME	ms	30000	Used so the accelerometer may determine how the pacing rate is decreasing. This is the time required to modify the ma
PVARP	ms	250	Specifies the time interval following a ventricular event when an atrial cardiac event shall not inhibit an atrial pace or trigger a ventricular pace.
FIXED_AV_DELAY	ms	150	Specifies the fixed programmable time period from an atrial event, whether intrinsic or paced, to a ventricular pace.
RESPONSE FACTOR		1-16	Used so that the accelerometer may determine the pacing rate that occurs at various levels of patient activity at a steady state.
ACTIVITY THRESHOLD		10-20	Used by the accelerometer to determine which value the sensor output should exceed before the rate is affected by activity data.
MAXIMUM SENSOR RATE	ppm	120	Determines the maximum allowed pacing as a result of sensor control. This rate is required for rate-adaptive modes and is independent of programming the URL.

These programmable parameters are referenced throughout the implementation of the bradycardia pacing modes. While pacing, the amplitudes, pulse widths, and refractory periods are used to ensure the accurate delivery of pulses per mode.

2.3.3 Hardware Inputs and Outputs

The interface of the FRDM K64F microcontroller is designed to utilize the board’s circuitry to apply designated actions onto the heart, transmitting and receiving pacing information as needed. There are twelve controlled signals acting as outputs, and two sensed signals acting as inputs. The functionality of these inputs and outputs, as well as their corresponding pin names and mappings, are detailed in Table 5: Hardware Inputs for Sensing Circuitry and Table 6: Hardware Outputs for Control Circuitry. These hardware inputs and outputs are used within the bradycardia modes submodule to define the logic for each pacing mode. This mapping is the concrete implementation of the Hardware Abstraction Layer. Figure 1. Hardware IO Module presents the hardware IO subsystem in Simulink.

Table 5: Hardware Inputs for Sensing Circuitry

Pin Name	Corresponding Variable	Pin Functionality	ON/OFF Result
DO	ATR_CMP_DETECT	Used to sense signals in the atrium. Includes the 5mV hysteresis.	ON: Outputs HIGH when signal voltage is higher than threshold voltage OFF: Otherwise
D1	VENT_CMP_DETECT	Used to sense signals in the ventricle. Includes the 5mV hysteresis.	ON: Outputs HIGH when signal voltage is higher than threshold voltage OFF: Otherwise

Table 6: Hardware Outputs for Control Circuitry

Pin Name	Corresponding Variable	Pin Functionality	ON/OFF Result
D2	PACE_CHARGE_CTRL	Used to allow the PWM to charge the primary capacitor, C22	ON: HIGH as the PWM charges C22 OFF: LOW as the PWM is disconnected from the circuit
D3	VENT_CMP_REF_PWM	Uses the PWM to charge a capacitor. Used to sustain a constant voltage when establishing a threshold for ventricular action potential sensing	ON: HGH as PWM enables charging OFF: LOW as PWM does not enable charging
D4	Z_ATR_CTRL	Used to analyze the impedance of the atrial electrode and connection between electrodes and atrium itself	ON: HIGH as the impedance circuit connects to the ring electrode of atrium OFF: LOW as the impendence circuit is disconnected
D5	PACING_REF_PWM	Used to charge primary capacitor of the pacing circuit	ON: HIGH as PWM voltage output saturates and charges C22 ON: LOW as PWM does not charge C22
D6	ATR_CMP_REF_PWM	Uses the PWM to charge a capacitor. Used to sustain a constant voltage when establishing a threshold for atrial action potential sensing	ON: HGH as PWM enables charging OFF: LOW as PWM does not enable charging
D7	Z_VENT_CTRL	Used to analyze the impedance of the ventricular electrode and connection between electrodes and ventricle itself	ON: HIGH as the impedance circuit connects to the ring electrode of ventricle OFF: LOW as the impedance circuit is disconnected
D8	ATR_PACE_CTRL	Uses to discharge the primary capacitor C22 through the atrium	ON: HIGH as current flows through the switch OFF: LOW as there is no current flow
D9	VENT_PACE_CTRL	Used to discharge the primary capacitor C22 through the ventricle	ON: HIGH as current flows through the switch OFF: LOW as there is no current flow
D10	PACE_GND_CTRL	Used to allow current to flow from the ring to the tip of the electrode in either the atrium or the ventricle	ON: HGIH as current controls the switch directly following the tip OFF: LOW as there is no current flow allowed
D11	ATRL_GND_CTRL	Used when discharging the blocking capacitor through the atrium to ensure no charge build up	ON: HIGH as the ATR_RING_OUT connected to GND OFF: LOW as the ATR_RING_OUT is disconnected to GND
D12	VENT_GND_CTRL	Used when discharging the blocking capacitor through the ventricle to ensure no charge build up	ON: HIGH as the VENT_RING_OUT connected to GND OFF: LOW as the VENT_RING_OUT is disconnected to GND
D13	FRONTEND_CTRL	Used in activating the sensing circuitry	ON: HIGH as sensing circuitry outputs the heart signal OFF: LOW as sensing circuitry disconnects from patient and does not have output
A0	ATR_SIGNAL	Outputs the atrial’s analog waveform prior to full rectification. As such, this signal represents the real-time activity in the heart, used for electrocardiogram outputs	ON: HIGH as the analog waveform is outputted. OFF: LOW as the analog wave if not outputted.
A1	VENT_SIGNAL	Outputs the ventricle;s analog waveform prior to full rectification. As such, this signal represents the real-time activity in the heart, used for electrocardiogram outputs	ON: HIGH as the analog waveform is outputted. OFF: LOW as the analog wave if not outputted.

Figure 1. Hardware IO Module

2.3.4 Rate Adaptive

The rate adaptive pacing system implements a sophisticated, multi-stage control architecture that accurately translates patient physical activity levels into physiologically appropriate pacing rate adjustments. The implementation follows a structured, mathematically rigorous signal processing pipeline that culminates in a deterministic finite state machine, ensuring predictable and safe operation under all physiological conditions.

*Comprehensive Signal Processing Pipeline *

Accelerometer Data Acquisition and Vector Processing: 

• Raw triaxial accelerometer data is continuously acquired as a [1×3] vector representing acceleration components along orthogonal axes in gravitational units (g = 9.8 m/s²) 

• The system computes the magnitude of the 3D acceleration vector to obtain a comprehensive, orientation-independent measure of physical activity intensity using the following mathematical formulation: 

• Vector dot product computation: A · A = x² + y² + z² 

• Magnitude calculation: |A| = √(x² + y² + z²) = √(A · A) 

• This vector magnitude calculation provides a rotation-invariant measure of physical activity intensity that remains consistent regardless of device orientation or positioning within the implant pocket, ensuring reliable activity detection across various patient anatomies and implantation sites 

Multi-Stage Signal Conditioning and Clinical Normalization: 

• A moving average filter with configurable window length is applied to the raw magnitude signal to effectively attenuate high-frequency noise components and transient motion artifacts while preserving clinically relevant activity trends and patterns 

• The conditioned signal undergoes precise normalization to map to the standardized activity threshold scale used in clinical practice: 

• Input signal dynamic range: [0, 8] gravitational units, covering the expected range of human physical activities 

• Clinical activity threshold range: [0, 6] corresponding to seven discrete activity levels {V-Low, Low, Med-Low, Med, Med-High, High, V-High} as established in clinical practice 

• Linear scaling transformation: scaled_activity = raw_signal × (6/8) 

• Mathematical clamping operation ensures the normalized activity remains within the physiologically relevant [0,6] range, preventing overflow conditions and maintaining system stability 

Clinical Rate Response Algorithm: 

The system converts processed activity levels to appropriate pacing rates through a mathematically precise, clinically configurable response function: 

• Input Parameters: Processed activity level, programmed response factor (1-16), activity threshold (1-7), Lower Rate Limit (LRL: 30-175 ppm), Maximum Sensor Rate (MSR: 50-175 ppm) 

• Response Calculation Algorithm: 

• For activity levels exceeding the programmed clinical threshold: 

• DesiredRate = activity_level × response_factor × k + LRL.  
  Where the scaling factor k = (MSR - LRL) / (activity_threshold_max × (response_factor_max - 1))  
  With clinically established constants: activity_threshold_max = 6 and response_factor_max = 16 

This formulation ensures linear scaling between the activity level and the resulting sensor-indicated rate, with the response factor controlling the slope of this relationship 

• For sub-threshold activity levels: DesiredRate = LRL, maintaining baseline support 

• Safety Enforcement Mechanism: The algorithm constrains the desired rate within the clinically safe boundaries [LRL, MSR] through mathematical saturation functions, ensuring patient safety under all operating conditions 

Temporal Response Characteristics Implementation: 

The system implements physiologically appropriate graduated rate changes to ensure patient comfort and hemodynamic stability: 

• Reaction Rate Calculation governs the rate increase dynamics during activity detection: 

ReactionRate = (MSR - LRL) / (1000 × reaction_time)  [in units of ppm/ms]  

Where reaction_time is clinically programmed in seconds (range: 10-50 seconds)  

This calculation determines how many pulses per minute are added during each millisecond processing cycle when the current rate is below the sensor-indicated rate 

• Recovery Rate Calculation governs the rate decrease dynamics during activity cessation: 

RecoveryRate = (MSR - LRL) / (60 × 1000 × recovery_time)  [in units of ppm/ms]  

Where recovery_time is clinically programmed in minutes (range: 2-16 minutes)  

This calculation determines how many pulses per minute are subtracted during each millisecond processing cycle when the current rate should return toward the baseline LRL 

*Deterministic Finite State Machine Operation *

The rate adaptation logic operates through a rigorously defined deterministic finite state machine that orchestrates all pacing rate adjustments in precise 1ms time steps, ensuring predictable and safe system behavior: 

Active Adaptation State (engaged when physical activity exceeds the configured clinical threshold): 

• If the current pacing rate is below the sensor-indicated desired rate: 
  current rate += ReactionRate (gradual acceleration toward target) 

• If the current pacing rate exceeds the sensor-indicated desired rate: 
  current rate -= ReactionRate (gradual deceleration toward target) 

• This symmetrical adjustment mechanism ensures smooth convergence toward the appropriate sensor-indicated rate regardless of initial conditions 

Recovery State (activated when activity levels subside below the programmed threshold): 

• If the current pacing rate exceeds the programmed Lower Rate Limit: 
  current rate -= RecoveryRate (controlled return to baseline) 

• If the current pacing rate is at or below the LRL: no adjustment required (maintain baseline support) 

• The recovery rate is typically configured to be slower than the reaction rate, reflecting physiological recovery patterns 

State Transition Logic: 

• Transitions between operational states occur automatically and instantaneously based on continuous real-time activity threshold assessment 

• The state machine implements hysteresis where appropriate to prevent rapid cycling between states during borderline activity conditions 

• All state transitions are deterministic and predictable, with no undefined states or transition conditions 

Mathematical Safeguards and Boundary Conditions: 

• All rate calculations include comprehensive boundary checking to ensure values remain within physiologically plausible ranges [LRL, MSR] 

• Floating-point arithmetic operations include protection against overflow, underflow, and division-by-zero conditions 

• Rate change calculations include sanity checks to prevent excessively large adjustments that could cause patient discomfort 

• The system maintains audit trails of rate adjustments for diagnostic purposes and clinical review 

This comprehensive, mathematically rigorous implementation ensures the pacing rate adapts appropriately to patient physical activity while maintaining strict safety constraints and providing clinically appropriate response characteristics. The design carefully balances responsiveness with stability, preventing excessive rate fluctuations while ensuring timely adaptation to metabolic demands. The calculations provide a mathematically sound foundation for translating raw sensor data into clinically meaningful, physiologically appropriate pacing rate adjustments that enhance patient quality of life during physical activity while maintaining safety as the paramount concern. 

2.3.5 Serial Modules

The design involves a COM_IN and COM_OUT modules, corresponding to serial write and serial read respectively.

COM_IN uses a serial receive block corresponding to the FRDM-K64F. It takes a data length of 34 bytes, counting a start byte, a read/write byte, and the parameters we expect to receive. Additionally, little-endian storage has been applied for parameters stored in multiple bytes, such as uint16 or single. The receive block expects the uint8 data type. Initial values are defined, but once the State flow receives the sync word btye, it then prepares to echo back parameters (if a read byte is sent) using the send_params() function or receive and redefine parameters (if a write byte is sent).

Assuming a write byte is sent, each value gets defined from the DCM and typecasted to a new type, if it differs from uint8. The state flow then returns to standby, and waits to receive more information from the DCM, if it were to get sent.

Assuming a read byte is sent, the send_params() function is called from the COM_OUT block. All data to be sent is packed into uint8, before coming together in a MUX and then being sent to the DCM using a serial transmit block corresponding to the FRDM-K64F.

Figure 2: COM_IN Stateflow

The COMM_OUT subsystem, which corresponds to serial write, transmits data to the DCM. Both the parameters detailed in Table 4: User Programmable Parameters and the electrocardiogram streaming data are transmitted to the DCM simultaneously. As the transmission block anticipated receiving uint8 data, all parameters that are uint816 or single experience byte packing before transmission.

Figure 3: COM_OUT Function

2.3.6 Pacing Mode State Machine Design

There are nine pacing (bradycardia) modes in our system design: AOO, VOO, AAI, VVI, AOOR, VOOR, AAIR, VVIR, and DDDR. Only one mode operates at a time in the pacemaker. The tables below outline the description and role of each state. The tables below describe the purpose and system behaviour of each mode.

State	Condition/Description	System Behaviour
AOO	Paces the atrium at a fixed rate and does not monitor the heart’s natural activity. It continuously delivers pacing pulses at the programmed INTERVAL, which defines the time between each atrium pulse.	First, the capacitor is charged by PACE_CHARGE_CTRL = 1, after INTERVAL, it sends a pacing pulse (ATR_PACE_CTRL = 1) for the duration of ATR_PULSEWIDTH. The pulse’s amplitude is determined by ATR_AMPLITUDFE. After the pulse ends, ATR_PACE_CTRL = 0, the capacitor discharges and the cycle repeats.

Table 7: AOO Mode Description

Figure 44. AOO Pacing Mode

State	Condition/Description	System Behaviour
VOO	Paces the ventricle at a fixed rate and does not monitor the heart’s natural activity. It continuously delivers pacing pulses at the programmed INTERVAL, which defines the time between each ventricle pulse.	First, the capacitor is charged by PACE_CHARGE_CTRL = 1, after INTERVAL, it sends a pacing ventricle output pulse, (VENT_PACE_CTRL = 1) for the duration of VENT_PULSEWIDTH. The pulse’s amplitude (i.e. how strong the voltage is) is determined by VENT_AMPLITUDFE. After the pulse ends, VENT_PACE_CTRL = 0, the capacitor discharges and the cycle repeats.

Table 8: VOO Mode Description

Figure 55. VOO Pacing Mode

State	Condition/Description	System Behaviour
AAI	Paces the atrium only when the natural atrial misses a beat within the programmed INTERVAL. It monitors the natural atrial activity by using the comparator input ATR_CMP_DETECT.	The pacemaker turns on sensing FRONTEND_CTRL = 1 to detect natural atrial beats. Then, the capacitor charges PACE_CHARGE_CTRL = 1 and waits for INTERVAL. If a natural P-wave from HeartView is detected using P-wave ATR_CMP_DETECT = 1, no pacing pulse is sent, the system resets and waits for the next cycle. However, if no heartbeat is detected within the ARP (atrial refractory period) the pacemaker paces the atrium by having ATR_PACE_CTRL = 1 where it sends a pulse of amplitude and duration, ATR_AMPLITUDE and ATR_PULSEWIDTH. After the pulse is finished, ATR_PACE_CTRL = 0, capacitor discharges and the system returns to sensing mode to check for the next natural beat again. Before the ARP ends, the pacemaker continues to sense for the duration of INTERVAL – ARP before restarting the next pacing.

Table 9: AAI Mode Description

Figure 66. AAI Pacing Mode

State	Condition/Description	System Behaviour
VVI	Paces the ventricle only when the natural heart fails to contract on its own. It monitors the natural ventricular activity using the comparator input VENT_CMP_DETECT.	The pacemaker turns on sensing by setting FRONTEND_CTRL = 1 to detect natural R-waves. The capacitor charges, PACE_CHARGE_CTRL = 1 and waits for the programmed INTERVAL. If R-wave is detected, VENT_CMP_DETECT = 1, the pacemaker does not pace, and it resets the timer and continues sensing. However, if no heartbeat is detected within VRP (the ventricular refractory period), the pacemaker delivers a pacing pulse, VENT_PACE_CTRL = 1 that sends a pulse of amplitude and duration, VENT_AMPLITUDE and VENT_PULSEWIDTH. After the pulse is finished, VENT_PACE_CTRL = 0, the capacitor discharges, and the system returns to sending mode to check for the next natural beat again. After the VRP ends, the pacemaker continues to sense for the duration of INTERVAL – VRP before restarting the next pacing.

Table 10: VVI Mode Description

Figure 77. VVI Pacing Mode

State	Condition/Description	System Behaviour
AOOR	Paces the atrium at a fixed rate which is determined by the ADAPTED_RATE. It doesn’t sense atrial activity and ignores the natural heartbeats.	The pacemaker charges the atrial pacing capacitor via PACE_CHARGE_CTRL = 1 and waits for the duration of ADAPTED_RATE. After this duration passes, ATR_PACE_CTRL = 1 sends an atrial pulse using ATR_AMPLITUDE and ATR_PULSEWIDTH and when the pulse is done, ATR_PACE_CTRL = 0, t capacitor discharges and the cycle repeats without sensing.

Table 111: AOOR Mode Description

Figure 88. AOOR Pacing Mode

State	Condition/Description	System Behaviour
VOOR	Paces the ventricle at a fixed rate which is based on ADAPTED_RATE. This mode does not sense ventricular activity and ignores natural ventricular beats.	The pacemaker charges the ventricular pacing capacitor via PACE_CHARGE_CTRL = 1 and waits for ADAPTED_RATE. After the duration ends, VENT_PACE_CTRL = 1 delivers a ventricular pulse with VENT_AMPLITUDE and VENT_PULSEWIDTH. Then, after pacing, VENT_PACE_CTRL = 0, the capacitor discharges and the pacing cycle restarts without sensing.

Table 122: VOOR Mode Description

Figure 99. VOOR Pacing Mode

State	Condition/Description	System Behaviour
AAIR	Paces the atrium only when no natural atrial beat is sensed within ADAPTED_RATE. This mode monitors intrinsic activity using ATR_CMP_DETECT.	The pacemaker charges C22, PACE_CHARGE_CTRL =1, and enables sensing via FRONTEND_CTRL = 1. If ATR_CMP_DETECT before the interval ends, the pacing is inhibited. When there are no beats, ATR_PACE_CTRL = 1 delivers an atrial pulse with ATR_AMPLITUDE and ATR_PULSEWIDTH. After pacing and ARP, we continue resuming for sensing for the next natural beat.

Table 133: AAIR Mode Description

Figure 10. AAIR Pacing Mode

State	Condition/Description	System Behaviour
VVIR	Paces the ventricle only if no natural atrial beat is sensed within ADAPTED_RATE. This mode monitors intrinsic activity using ATR_CMP_DETECT.	The pacemaker enables sensing via FRONTEND_CTRL = 1 and charges C22 via PACE_CHARGE_CTRL = 1. If ATR_CMP_DETECT = 1 before the interval ends, then pacing is inhibited. Otherwise, if no beat appears, ATR_PACE_CTRL = 1 delivers an atrial pulse with ATR_AMPLITUDE and ATR_PULSEWIDTH. After pacing and ARP and it continues sensing for the next natural heartbeat.

Table 144: VVIR Mode Description

Figure 1110. VVIR Pacing Mode

State	Condition/Description	System Behaviour
DDDR	Performs dual-chamber sensing and pacing where it senses P-waves and R-waves via ATR_CMP_DETECT and VENT_CMP_DETECT to pace the atrium and/or ventricle as needed.	The pacemaker senses the atrium first and if no P-waves occur then ATR_PACE_CTRL = 1 delivers an atrial pace. After the AV delay, if no V-wave is detected then VENT_PACE_CTRL =1 delivers a ventricular pace. Then it goes into ARP and VRP before it returns to dual sensing in order to begin the next cycle.

Table 152: DDDR Mode Description

Figure 13. DDDR Pacing Mode

2.3.6 Simulink Diagram

Below is the full Simulink diagram that includes six subsystems. Each of these subsystems handles a specific part of the pacemaker’s signal flow. The first subsystem is the COM_IN subsystem, which receives parameter updates from the DCM, and it reads incoming bytes, decodes them, and updates all programmable parameters. The second subsystem is the Default Values subsystem which gives the initial system parameters when no external DCM input is received. This subsystem also does conversions from BPM, voltage amplitude scaling, and etc. and all those default signals feed directly into the pacing logic. The third block is the Bradycardia Modes block which determines which pacing mode is operating on the pacemaker. The fourth subsystem is the Rate Adaptive Subsystem which generates the adapted rate using inputs such as activity threshold, response factor, LRL & MSR, etc. to be used to the five new modes AOOR, VOOR, AAIR, VVIR, and DDDR. The fifth subsystem is the FRDM-K64F Pin Assignments block which connects the input and output pins used in the Simulink to the actual hardware board. Finally, the last subsystem is the COM_OUT subsystem which packages all pacing parameters and signals such as mode, rate limits, amplitudes, etc. into a sterilized byte stream for transmission over UART so the DCM can read the pacemaker’s current state.

Figure 1411. Full Simulink Diagram

2.3.8 DCM Software Structure

Table 16. DCM Directory Structure

DCM/ gui/ (Frontend Display) init.py (Package initialization) dcm_gui.py (Main GUI application - login, dashboard, parameters) tkinter_demo.py (Tkinter example/reference code) core/ (Backend Logic) init.py (Package initialization) user_management.py (User registration and authentication) params.py (Parameters dataclass with validation) modes.py (Pacing mode parser - AOO, VOO, AAI, VVI) egram.py (Egram data buffer and structures) README.md (Core module documentation) storage/ (Persistent Local Files) users.json (Registered users with hashed passwords) params.json (Saved pacemaker parameters) tests/ (Unit Test Benches) init.py (Test package initialization) test_user_managment.py (User management tests) test_params.py (Parameter validation tests) test_modes.py (Mode parsing tests) test_egram.py (Egram functionality tests) docs/ (Documentation) README.md (Additional documentation) run_dcm.py (Application launcher script) README_GUI.md (GUI documentation and usage guide) .gitignore (Git ignore rules)

The DCM is structured in way in which the backend logic, found in the core directory acts like a library that is then utilized by the front-end GUI. Files in the core directory allow for hardware hiding, providing a several standardized functions that although do not interact with the hardware for this deliverable will be used as the direct link in the upcoming deliverable.

,

15, 16, 17, 18, 19, 20, 21, 22, 23, & 24: Full DCM User Interface

Part 2

Requirements Potential Changes

3.1.1 Simulink Requirements Potential Changes (Deliverable 1 to Deliverable 2)

The key requirements will evolve to include the implementation of additional states that allow for rate adaptivity through an on-board accelerometer. This will introduce four new required bradycardia states that feature rate modulation, as well as a bonus state, described in Table 17: List of Evolving Bradycardia Operating Modes. To incorporate the rate modulation, the use of a 3-axis accelerometer will allow the generation of electrical signals based on physical activity. To correctly implement these electrical signals, the pacemaker shall correctly increase the Lower Rate Limit for effective rate-adaptive pacing. In implementing these changes, new parameters will be defined.

Additionally, the DCM will communicate with the Pacemaker, which will require the implementation of serial read and write communication modules for successful transmission and reception of data. In the anticipation of the DCM communicating with the Pacemaker, the input parameters were intentionally handled through a modular design to facilitate the expected adjustment.

Bradycardia State	Operating Mode
AOOR	A: Pacing in the atrium, O: Heart sensing off, O: Response to sensing off, R: rate Modulation
VOOR	V: Pacing in the ventricle, O: Heart sensing off, O: Response to sensing off, R: Rate modulation
AAIR	A: Pacing in the atrium, A: Sensing in the atrium, A: Inhibited response, R: Rate modulation
VOOR	A: Pacing in the ventricle, O: Sensing in the ventricle, O: Inhibited response, R: Rate modulation
DDR	D: Pacing in both atrium and ventricle, D: Sensing in both atrium and ventricle, D: Dual response (trigger or inhibit), R: Rate modulation

Table 17: List of Evolving Bradycardia Operating Modes

3.1.2 DCM Requirements Potential Changes

The key requirements will evolve to account for the additional pacing modes. Additionally, the saving and exporting of data in various formats, such as pdfs, will be required. A real time electrogram will display data received from the heart’s atrium and ventricle through serial communication.

3.1.3 Requirements Potential Changes (Deliverable 2 and Beyond)

Currently, the Deliverable 2 model implements the use of serial communications via a USB serial interface. For a real-world device, a wireless communication protocol (e.g radio frequency communications) could be implemented to allow for remote programming and monitoring without an invasive physical connection.

Additionally, future considerations would include additional safety and functionality testing. For instance, the testing of unexpected edge cases that have the potential for non-desirable behaviour would be key for assuring safety. Currently, the bounding of the pulse intervals serves as a safety precaution, but potential hardware concerns or failures should be considered as well.

fun

Design Decision Potential Changes

3.2.1 Design Decision Potential Changes (Deliverable 1 to Deliverable 2)

As additional pacing modes are expected to be implemented in the future, it is likely that a more robust approach will be required in the pacemaker design. The current pacemaker design hinges off the relative simplicity of four pacing modes. In contrast, the rate-adaptive modes will require additional rate modulating parameters and complex decision logic to determine pacing or sensing. As a result, the input Mode parameter, as presented in Table 3 of programmable parameters, will no longer pose as a direct decision parameter. In the future, it will serve as a decision parameter that then determines a subset of parameters parsed by a generalised state flow. This generalized state flow will perform the action of any pacing mode given the subset of parameters it requires. Finally, an additional layer of I/O operations will be required to produce the EGMs representing analog readings from the heart.

3.2.2 Design Decision Potential Changes (Deliverable 2 and Beyond)

For the future, perhaps the design could be modified to be less hardware intensive while still maintaining effective, relevant calculations. Throughout the deliverable, the microcontroller consistently exhibited success when performing calculations according to the samples received from the accelerometer. As such, perhaps the rate adaptive pacing module could be re-designed with a different approach when sampling from the accelerometer.

Module Description

3.3.1 DCM Modules

user_management.py

Purpose

Handles all user-related operations, including registration, authentication, and deletion. Implements the 10-user storage limit required by the specification and ensures credential security using SHA-256 hashing.

Key functions

Function	Description	Visibility
register_user(username,password)	Add new user	Public
authenticate_user(username,password)	Validate user	Public
list_users()	Return all users	Public
remove_user(username)	Deletes a user	Public
reset_users()	Wipes all user data	Public
_load_users()/_save_users()/_hash_password()	Internal helpers for file I/O	Private

Table 18: user_managment.py functions

Global Variables:

MAX_USERS = 10 and USER_FILE – path to storage/users.json

Interactions:

Called by GUI layer for login and registrations.

Independent of all other core modules

parameters.py

Purpose:

Defines the configurable pacing parameters using by the pacemaker. Furthermore, it also provides validation against the safe operating ranges in Appendix A and functions for saving and loading parameters.

Key functions:

Function	Description	Visibility
PacemakerParameters	Dataclass containing LRL, URL, amplitudes, pulse widths, ARP, VRP.	Public
validate()	Ensures all values fall within allowable ranges.	Public
to_dict()	Converts parameters to a serializable dictionary.	Public
save_parameters(params)	Writes validated parameter set to params.json.	Public
load_parameters()	Reads and reconstructs a PacemakerParameters object.	Public

Table 19: params.py functions

Global Variables:

PARAMS_FILE – path to storage/params.json

Interactions:

Called by GUI layer to populate and validate the parameter entry fields.

Parameters may later be transmitted to the controller in Deliverable 2

modes.py

Purpose:

Represents and interprets pacing modes using the three-letter code. Automatically extracts paces, sensed and response attributes from any valid mode string. To increase the scalability of the project the codes are not hardcoded but rather read through and a function checks their validity. This will allow more modes to be implemented in the future.

Key functions:

Function	Description	Visibility
PacemakerMode	Enum of supported modes (AOO, VOO, AAI, VVI).	Public
parse_mode(mode)	Parses Enum member or string into ModeInfo dataclass.	Public
list_modes()	Returns dictionary of mode → description.	Public
ModeInfo	Dataclass storing parsed fields and human-readable description.	Public

Table 20: modes.py functions

Interactions:

Called by GUI layer for mode selection.

May be referenced by the communication interface.

egram.py

Purpose:

Provides data structures for real-time electrogram signal storage. Captures atrial, ventricular, and surface ECG samples in fixed-size circular buffers.

Key functions:

Function	Description	Visibility
EgramSample	Dataclass for a single sample (timestamp, channel, value).	Public
EgramBuffer(maxlen=1000)	Initializes channel-specific circular buffers.	Public
add_sample(channel, value, timestamp=None)	Appends new sample to appropriate buffer.	Public
get_recent(channel, n)	Retrieves last n samples.	Public
get_all(channel)	Returns full buffer contents.	Public
clear()	Empties all buffers.	Public

Table 21: egram.py functions

Interactions

Will receive data from the communication interface.

GUI will read and plot buffer contents.

Serial Interface.py

Purpose:

Provides functions to receive and send data to the pacemaker through UART

Key functions:

Function	Description	Visibility
Connect	Connects to the pacemaker	Public
Disconnect	Disconnects device	Public
_build_packet	Builds the packet as a byte array with a start and command bit.	Private
Send_parameters	Sends the built packet to the device.	Public
_read_loop	Reads data from the UART port and if needed extracts the egram samples.	Private
_process_data	Automatically parses the read data and appends to the egram class.	Private

Table 17: egram.py functions

Interactions

Sends data to the egram module to facilitate visualization. In addition it heavily interacts with the gui as it sends and receives all the parameters.

dcm_gui.py

Purpose:

Provides the complete graphical user interface for the DCM system. Implements user authentication, pacing mode selection, parameter configuration with validation, serial communication, status monitoring, and real-time egram display. Serves as the primary interaction point between medical personnel and the pacemaker configuration system.

Key Functions:

Function	Description	Visibility
DCMApplication	Main application controller class managing all GUI screens, serial state, egram window, and overall application logic	Public
init(root)	Initializes GUI window, ttk styles, serial interface state, parameter caches, and displays login screen	Public
show_login_screen()	Renders login interface with username/password fields and user count	Public
show_registration_screen()	Displays new user registration form with validation (max 10 users)	Public
show_dashboard()	Main interface displaying mode selection, parameter inputs, serial controls, pushbutton inhibit, and status monitoring	Public
clear_window()	Removes all widgets from the window to prepare for screen transition	Public
main()	Entry point that creates the Tk root window and launches the DCM GUI	Public
_handle_login(username, password)	Authenticates credentials via the user_management module	Private
_handle_registration(username, password, confirm_password)	Validates and registers new users, enforcing max-user limit	Private
_handle_logout()	Confirms logout, disconnects serial interface, closes egram windows, and returns to login screen	Private
_select_mode(mode)	Highlights selected pacing mode and updates interface to display its parameters	Private
_display_parameter_message()	Displays placeholder text when no pacing mode is selected	Private
_display_parameters_for_mode(mode)	Dynamically generates scrollable parameter input fields based on the selected mode	Private
_get_mode_parameters(mode)	Returns mode-specific parameter list for all supported modes (AOO, VOO, AAI, VVI, AOOR, VOOR, AAIR, VVIR, DDDR)	Private
_validate_mode_parameters(mode)	Validates only parameters applicable to the selected mode using Deliverable 2 rules	Private
_save_parameters()	Validates, saves, and persists parameters to params.json	Private
_load_parameters()	Loads previously saved parameters from storage	Private
_handle_serial_connect()	Connects/disconnects serial port, updates connection state, and handles errors	Private
_transmit_parameters()	Validates and transmits parameter packet to pacemaker device via serial interface	Private
_request_parameters()	Requests current parameters from the pacemaker over serial	Private
_set_pushbutton_inhibit(active)	Mirrors hardware inhibit pushbutton: forces ventricular amplitude to 0 V while held (DDDR only)	Private
_show_egram_window()	Creates, configures, and displays the real-time egram visualization window	Private
_toggle_egram_streaming()	Starts or stops live egram streaming from the device	Private
_clear_egram()	Clears the egram display and associated data buffers	Private
_update_egram_display()	Renders updated atrial/ventricular waveform samples on the egram canvas	Private
_on_egram_data(channel, value)	Callback executed when egram samples are received from the device	Private
_configure_styles()	Applies ttk theme configuration for the GUI’s professional appearance	Private
_get_default_parameters()	Loads stored parameters or returns default system values	Private

Table 22: DCM system

Interactions

• Calls user_management module for authentication and user management

• Calls params module for parameter validation and persistence

• Uses modes module for mode definitions, IDs, and allowed parameter sets

• Uses serial_interface module for device communication when available

• Provides visual feedback for validation errors, save success, connection status, and real-time egram streaming activity

3.3.2 Simulink Modules

The Pacemaker design was modeled through three distinct submodules. These consist of the serial read, default parameters, the bradycardia states, serial write, rate-adaptive pacing, and the hardware IO. The parameters are used calculate, store, and pass values between these three modules. Through employing a loosely coupled approach, modules new to Deliverable 2 could be implemented with minimal impact on the existing modules. As a result of this flexible approach, the system is easier to maintain and extend as requirements evolve.

Module Interface Specifications:

The parameters module does conversions and transformations on various clinician programmable parameter, receiving them from the COM_IN module that initially received from the DCM. All of these variables, as Inputs on Simulink, are publicly scoped for use within the bradycardia states module. In terms of black-box behaviour, the “secrets” of this module are the hardcoded parameter values that are used across the system.

The hardware IO module defines the sensed and controlled signals across the pacemaker system and their physical pin mappings on the microcontroller shield. All of these variables, as both inputs and outputs on Simulink, are publicly scoped for use within the bradycardia state module. In terms of black box behaviour, the “secrets” of this module are the particular pin mappings for each pin to the FRDM-K64F microcontroller.

Module Internal Design

The bradycardia states module handles the decision-making logic of the pacemaker. It encompasses the four pacing modes required for this deliverable, and it does not handle any of the IO board operations. As such, the state flow for each respective pacing mode is designated as a private function of that module. Throughout the pacing modes, state variables from the programmable parameters are set to high and low to match the operation of each mode. Input states are set to control the pacing mode, while output states are set to later be used by the hardware module.

The serial reading and write modules handle byte storage of each parameter to ensure safe and successful transmission. For example, COM_IN typecasts and assigned the bytes received by the DCM to each respective parameter. COM_OUT byte packs each parameter so that it may be transmitted as an uint8.

The rate-adaptive pacing module uses accelerometer data from the FRDM-K64F microcontroller to ultimately adjust the pacing rate. Rate smoothing is applied to produce a stable activity metric which can resist short-term noise. The activity threshold, response factor, MSR, and LRL, which are global parameters, then work to output the desired pacing rate using an activity-to-rate mapping function. Reaction or recovery constants are used to gradually adjust the current rate upon comparison with the desired rate, ultimately generating the sensor-controlled rate. It is this value which is then exposed to the main pacemaker logic.

Testing

3.4.1 DCM Testing

To debug and test the DCM a modular approach was undertaken. The core directory was tested individually, making sure that all the functions worked before interfacing it with the GUI. To make sure that the tests were adequate and organized a pytest test suite was created under DCM/tests. All core files have test files which test boundary conditions on the functions which are public and used by the GUI to ensure correct functionality. All the test mentions pass under macOS15.6, python 3.11.4 and pytest 7.4.0 environment.

Test ID	Purpose of Test	Input Conditions	Expected Output	Actual Output
UM-1	Verify successful user registration and authentication	Username: “diego”, Password: “abc”	Registration returns True; authentication returns True	As expected
UM-2	Prevent duplicate user registration	Username: “diego” (already exists)	Second registration returns False	As expected
UM-3	Reject incorrect password on login	Username: “diego”, Password: “124”	Authentication returns False	As expected
UM-4	Enforce 10-user limit	Add 11 users sequentially	11th registration returns False	As expected
UM-5	Validate user deletion	Register “charlie”, remove “charlie”	Removal returns True; user no longer in list	As expected
UM-6	Prevent deleting non-existent users	Remove “charlie” again	Removal returns False	As expected

Table 23: user_management.py test cases

Test ID	Purpose of Test	Input Conditions	Expected Output	Actual Output
PAR-1	Validate correct parameter set	Typical valid set (LRL=60, URL=120, amplitudes=3.5, widths=0.5, ARP=VRP=250)	validate() returns True	As expected
PAR-2	Reject invalid LRL	LRL=20 (below range)	Raises ValueError	Exception raised as expected
PAR-3	Reject invalid URL < LRL	LRL=100, URL=90	Raises ValueError	Exception raised as expected
PAR-4	Reject amplitude out of range	Atrial amplitude = 10.0	Raises ValueError	Exception raised as expected

Table 24: parameter.py test suite

Test ID	Purpose of Test	Input Conditions	Expected Output	Actual Output
MOD-1	Parse AOO mode correctly	Mode = “AOO”	Paced = A, Sensed = O, Response = O; description includes “Atrium paced”	As expected
MOD-2	Parse VVI mode correctly	Mode = “VVI”	Paced = V, Sensed = V, Response = I; description includes “Inhibit response”	As expected
MOD-3	List available modes	list_modes()	Returns dict with {AOO, VOO, AAI, VVI} keys	As expected
MOD-4	Parse future mode dynamically	Input string “DOO”	Paced = D, Sensed = O, Response = O; valid description generated	As expected

Table 25: modes.py test suite

Test ID	Purpose of Test	Input Conditions	Expected Output	Actual Output
EGM-1	Verify sample addition and retrieval	Add 3 atrial samples (0.1, 0.2, 0.3) → get_recent(2)	Returns last 2 values [0.2, 0.3]	As expected
EGM-2	Verify circular buffer behavior	Add 4 ventricular samples to buffer of size 3	Retains last 3 values [1.0, 2.0, 3.0]	As expected
EGM-3	Retrieve and clear samples	Add 2 surface samples → call clear()	Buffers empty after clear	As expected
EGM-4	Handle invalid channel inputs	Add sample to “invalid” channel	Raises ValueError	As expected

Table 26: egram.py test suite

Test ID	Purpose of Test	Input Conditions	Expected Output	Actual Output
SI-1	Verify that the Serial Interface module sent the correct data through UART	Programmable parameters set to arbitrary values, mode cycles through all of them	In heart view, expected to see the mode of the pacemaker to change.	As expected

Table 27: DCM_uart_test.py test suite

3.4.2 Simulink Testing

Each pacing mode will react differently and output accordingly to the current input. A set of various tests are made according to the possible cases, which includes positive cases, verifies that the mode works as intended with valid inputs, and negative cases, the system’s response to invalid/unexpected inputs.

Default parameters to keep in mind for test cases:

• User Selection (i.e. Minimum resting heart rate) = 60 BPM

• Lower Rate Limit = 60 BPM

• Upper Rate Limit = 120 BPM

Each pacing mode has 6 test cases:

• Test 1: Heart rate at the minimum resting heart rate at 60 BPM.

• Test 2: Heart rate in between the lower and upper rate limit at 90 BPM, which is between 60 BPM and 120 BPM.

• Test 3: Heart rate at the upper rate limit of 120 BPM.

• Test 4: Heart rate below the lower rate limit at 30 BPM, which is below the lower limit of 60 BPM.

• Test 5: Heart rate above the upper rate limit at 180 BPM, which is above the upper limit of 120 BPM.

• Test 6: Natural heart off.

NOTE: A test for the heart rate at the lower boundary is not explicitly tested as the lower rate limit and minimum resting heart rate are the same. These two parameters are the same as to avoid unnecessary pacing to extend the pacemaker’s battery life as well as to let the natural heart beat on its own whenever it has the capacity to do so.

Pacing Mode: AOO

The variable pacingMode is set to 0, the corresponding pacing mode value of AOO.

Purpose of ALL tests: to verify that the pacemaker ignores the natural heart and atrial paces at a fixed rate of 60 BPM.

Expected Output for ALL tests: Consistent atrial pacing at 60 BPM.

Test Case #1:

Purpose: To test the pacemaker’s atrial pacing ignoring the minimum resting heart rate of 60 BPM, and pace regardless.

Input conditions:

• Atrial Activity: ON – pulse width = 1ms

• Ventricular Activity: OFF – pulse width = 0ms

• Heart Rate: 60 BPM

• AV Delay: duration = 30ms

Expected output: Even though, atrial activity is on, giving the heart a chance, the pacemaker ignores it and paces accordingly at 60 BPM.

Actual output:

Figure 25. AOO Test Case 1

Result: Pass. The actual output matches the expected, as the pacemaker atrial paces at 60 BPM ignoring the heart’s atrial pacing at minimum resting heart rate.

Test Case #2:

Purpose: To test the pacemaker’s atrial pacing ignoring a heart rate of 90 BPM, within the normal range, and pace regardless.

Input conditions:

• Atrial Activity: ON – pulse width = 1ms

• Ventricular Activity: OFF – pulse width = 0ms

• Heart Rate: 90 BPM

• AV Delay: duration = 30ms

Expected output: Even though, atrial activity is on, giving the heart a chance, the pacemaker ignores it and paces accordingly at 60 BPM.

Actual output:

Figure 2612. AOO Test Case 2

Result: Pass. The actual output matches the expected, as the pacemaker atrial paces at 60 BPM ignoring the heart’s atrial pacing within normal range.

Test Case #3:

Purpose: To test the pacemaker’s atrial pacing ignoring the heart rate of the upper rate limit of 120 BPM, and pace regardless.

Input conditions:

• Atrial Activity: ON – pulse width = 1ms

• Ventricular Activity: OFF – pulse width = 0ms

• Heart Rate: 120 BPM

• AV Delay: duration = 30ms

Expected output: Even though, atrial activity is on, giving the heart a chance, the pacemaker ignores it and paces accordingly at 60 BPM.

Actual output:

Figure 2713. AOO Test Case 3

Result: Pass. The actual output matches the expected, as the pacemaker atrial paces at 60 BPM ignoring the heart’s atrial pacing at the upper rate limit.

Test Case #4:

Purpose: To test the pacemaker’s atrial pacing ignoring a heart rate below the lower rate limit of 30 BPM, and pace regardless.

Input conditions:

• Atrial Activity: ON – pulse width = 1ms

• Ventricular Activity: OFF – pulse width = 0ms

• Heart Rate: 30 BPM

• AV Delay: duration = 30ms

Expected output: Even though, atrial activity is on, giving the heart a chance, the pacemaker ignores it and paces accordingly at 60 BPM.

Actual output:

Figure 2814. AOO Test Case 4

Result: Pass. The actual output matches the expected, as the pacemaker atrial paces at 60 BPM ignoring the heart’s atrial pacing below the lower rate limit.

Test Case #5:

Purpose: To test the pacemaker’s atrial pacing ignoring a heart rate of above the upper rate limit of 180 BPM, and pace regardless.

Input conditions:

• Atrial Activity: ON – pulse width = 1ms

• Ventricular Activity: OFF – pulse width = 0ms

• Heart Rate: 180 BPM

• AV Delay: duration = 30ms

Expected output: Even though, atrial activity is on, giving the heart a chance, the pacemaker ignores it and paces accordingly at 60 BPM.

Actual output:

Figure 2915. AOO Test Case 5

Result: Pass. The actual output matches the expected, as the pacemaker atrial paces at 60 BPM ignoring the heart’s atrial pacing above the upper rate limit.

Test Case #6:

Purpose: To test the pacemaker’s atrial pacing ignoring the heart’s atrium not pacing at all, and pace regardless.

Input conditions:

• Atrial Activity: OFF – pulse width = 0ms

• Ventricular Activity: OFF – pulse width = 0ms

• Heart Rate: 30 BPM

• AV Delay: duration = 30ms

Expected output: The pacemaker atrial paces accordingly at 60 BPM.

Actual output:

Figure 3016. AOO Test Case 6

Result: Pass. The pacemaker atrial paces consistently at 60 BPM, even when the heart’s atrium isn’t beating on its own at all.

Test Case #7:

Purpose: To test the pacemaker’s atrial pacing ignoring the heart’s atrium not pacing at all, under any high activity level (e.g. Shaking). Since AOO mode is not rate-adaptive, the pacemaker will continue pacing at the lower rate limit.

Input conditions:

• Atrial Activity: OFF – pulse width = 0ms

• Ventricular Activity: OFF – pulse width = 0ms

• Heart Rate: 60 BPM

• AV Delay: duration = 30ms

• Activity level = Shaking (walking, running or jogging)

Expected output: The pacemaker atrial paces accordingly at 60 BPM, the lower rate limit and does not follow a desired rate.

Actual output:

Figure 31. AOO Test Case 7

Result: Pass. Since this pacing mode does not include rate adaptivity, the pacemaker will still pace at the LRL of 60 BPM regardless of any activity.

Pacing Mode: VOO

The variable pacingMode is set to 1, the corresponding pacing mode value of VOO.

Purpose of ALL tests: to verify that the pacemaker ignores the natural heart and ventricular paces at a fixed rate of 60 BPM.

Expected Output for ALL tests: Consistent ventricular pacing at 60 BPM.

Test Case #1:

Purpose: To test the pacemaker’s ventricular pacing ignoring the minimum resting heart rate of 60 BPM, and pace regardless.

Input conditions:

• Atrial Activity: OFF– pulse width = 0ms

• Ventricular Activity: ON – pulse width = 1ms

• Heart Rate: 60 BPM

• AV Delay: duration = 30ms

Expected output: Even though, ventricular activity is on, giving the heart a chance, the pacemaker ignores it and paces accordingly at 60 BPM.

Actual output:

Figure 3217. VOO Test Case 1

Result: Pass. The actual output matches the expected, as the pacemaker ventricle paces at 60 BPM ignoring the heart’s ventricular pacing at minimum resting heart rate.

Test Case #2:

Purpose: To test the pacemaker’s ventricular pacing ignoring the normal heart rate of 90 BPM, and pace regardless.

Input conditions:

• Atrial Activity: OFF– pulse width = 0ms

• Ventricular Activity: ON – pulse width = 1ms

• Heart Rate: 90 BPM

• AV Delay: duration = 30ms

Expected output: Even though, ventricular activity is on, giving the heart a chance, the pacemaker ignores it and paces accordingly at 60 BPM.

Actual output:

Figure 3318. VOO Test Case 2

Result: Pass. The actual output matches the expected, as the pacemaker ventricle paces at 60 BPM ignoring the heart’s ventricular pacing between the lower and upper rate limit.

Test Case #3:

Purpose: To test the pacemaker’s ventricular pacing ignoring the upper rate limit’s heart rate of 120 BPM, and pace regardless.

Input conditions:

• Atrial Activity: OFF– pulse width = 0ms

• Ventricular Activity: ON – pulse width = 1ms

• Heart Rate: 120 BPM

• AV Delay: duration = 30ms

Expected output: Even though, ventricular activity is on, giving the heart a chance, the pacemaker ignores it and paces accordingly at 60 BPM.

Actual output:

Figure 3419. VOO Test Case 3

Result: Pass. The actual output matches the expected, as the pacemaker ventricle paces at 60 BPM ignoring the heart’s ventricular pacing at the upper rate limit.

Test Case #4:

Purpose: To test the pacemaker’s ventricular pacing ignoring the below lower limit heart rate of 30 BPM, and pace regardless.

Input conditions:

• Atrial Activity: OFF– pulse width = 0ms

• Ventricular Activity: ON – pulse width = 1ms

• Heart Rate: 30 BPM

• AV Delay: duration = 30ms

Expected output: Even though, ventricular activity is on, giving the heart a chance, the pacemaker ignores it and paces accordingly at 60 BPM.

Actual output:

Figure 35. VOO Test Case 4

Result: Pass. The actual output matches the expected, as the pacemaker ventricle paces at 60 BPM ignoring the heart’s ventricular pacing at the lower rate limit.

Test Case #5:

Purpose: To test the pacemaker’s ventricular pacing ignoring the heart rate above the upper rate limit of 180 BPM, and pace regardless.

Input conditions:

• Atrial Activity: OFF– pulse width = 0ms

• Ventricular Activity: ON – pulse width = 1ms

• Heart Rate: 180 BPM

• AV Delay: duration = 30ms

Expected output: Even though, ventricular activity is on, giving the heart a chance, the pacemaker ignores it and paces accordingly at 60 BPM.

Actual output:

Figure 3620. VOO Test Case 5

Result: Pass. The actual output matches the expected, as the pacemaker ventricle paces at 60 BPM ignoring the heart’s ventricular pacing above the upper rate limit.

Test Case #6:

Purpose: To test the pacemaker’s ventricular pacing ignoring the heart’s ventricle not pacing at all, and pace regardless.

Input conditions:

• Atrial Activity: OFF– pulse width = 0ms

• Ventricular Activity: OFF – pulse width = 0ms

• Heart Rate: 30 BPM

• AV Delay: duration = 30ms

Expected output: The pacemaker ventricular paces at 60 BPM.

Actual output:

Figure 3721. VOO Test Case 6

Result: Pass. The actual output matches the expected, as the pacemaker ventricle paces at 60 BPM, even though the heart is not pacing at all.

Test Case #7:

Purpose: To test the pacemaker’s ventricular pacing when the heart is not pacing at all, under any high activity level (e.g. Shaking). Since VOO mode is not rate-adaptive, the pacemaker will continue pacing at the lower rate limit.

Input conditions:

• Atrial Activity: OFF – pulse width = 0ms

• Ventricular Activity: OFF – pulse width = 0ms

• Heart Rate: 30 BPM

• AV Delay: duration = 30ms

• Activity level = Shaking (walking, running or jogging)

Expected output: The pacemaker ventricular paces accordingly at 60 BPM, the lower rate limit and does not follow a desired activity-based rate.

Actual output:

Figure 38. VOO Test Case 7

Result: Pass. Since this pacing mode does not include rate adaptivity, the pacemaker will still pace at the LRL of 60 BPM regardless of any activity.

Pacing Mode: AAI

The variable pacingMode is set to 2, the corresponding pacing mode value of AAI.

Purpose of ALL tests: to verify that the pacemaker’s atrial only paces when the natural atrium is below the lower limit rate, otherwise it’s inhibited.

Test Case #1:

Purpose: To test operating mode AAI at the minimum resting heart rate of 60 BPM ensuring the atrial does not pace.

Input conditions:

• Atrial Activity: ON – pulse width = 1ms

• Ventricular Activity: OFF – pulse width = 0ms

• Heart Rate: 60 BPM

• AV Delay: duration = 30ms

Expected output: The pacemaker should not pace itself.

Actual output:

Figure 3922. AAI Test Case 1

Result: Pass. The actual output matches the expected, as the pacemaker inhibits atrial pacing since the heart’s natural atrium is not below the lower limit rate.

Test Case #2:

Purpose: To test operating mode AAI at a heart rate of 90 BPM, which is in between the lower and upper rate limit ensuring the atrial does not pace.

Input conditions:

• Atrial Activity: ON – pulse width = 1ms

• Ventricular Activity: OFF – pulse width = 0ms

• Heart Rate: 90 BPM

• AV Delay: duration = 30ms

Expected output: The pacemaker should not pace itself.

Actual output:

Figure 4023. AAI Test Case 2

Result: Pass. The actual output matches the expected, as the pacemaker inhibits atrial pacing since the heart’s natural atrium is not below the lower limit rate.

Test Case #3:

Purpose: To test operating mode AAI at the upper rate limit of 120 BPM ensuring the atrial does not pace.

Input conditions:

• Atrial Activity: ON – pulse width = 1ms

• Ventricular Activity: OFF – pulse width = 0ms

• Heart Rate: 120 BPM

• AV Delay: duration = 30ms

Expected output: The pacemaker should not pace itself.

Actual output:

Figure 4124. AAI Test Case 3

Result: Pass. The actual output matches the expected, as the pacemaker inhibits atrial pacing since the heart’s natural atrium is not below the lower limit rate.

Test Case #4:

Purpose: To test operating mode AAI at a heart rate of 30 BPM, which is below the lower rate limit ensuring the atrial does pace.

Input conditions:

• Atrial Activity: ON – pulse width = 1ms

• Ventricular Activity: OFF – pulse width = 0ms

• Heart Rate: 30 BPM

• AV Delay: duration = 30ms

Expected output: The pacemaker should pace itself at 60BPM.

Actual output:

Figure 4225. AAI Test Case 4

Result: Pass. The actual output matches the expected, as the pacemaker is atrial pacing at the lower rate limit of 60 BPM, since the heart’s natural atrium is below the lower limit rate.

Test Case #5:

Purpose: To test operating mode AAI at a heart rate of 180 BPM, which is higher than the upper rate limit ensuring the atrial does not pace.

Input conditions:

• Atrial Activity: ON – pulse width = 1ms

• Ventricular Activity: OFF – pulse width = 0ms

• Heart Rate: 180 BPM

• AV Delay: duration = 30ms

Expected output: The pacemaker should not pace itself.

Actual output:

Figure 4326. AAI Test Case 5

Result: Pass. The actual output matches the expected, as the pacemaker inhibits atrial pacing since the heart’s natural atrium is not below the lower limit rate.

Test Case #6:

Purpose: To test operating mode AAI when the natural atrium is not pacing at all, ensuring the pacemaker’s atrial does pace.

Input conditions:

• Atrial Activity: OFF – pulse width = 0 ms

• Ventricular Activity: OFF – pulse width = 0ms

• Heart Rate: 30 BPM

• AV Delay: duration = 30ms

Expected output: The pacemaker should pace itself.

Actual output:

Figure 4427. AAI Test Case 6

Result: Pass. The actual output matches the expected, as the pacemaker is atrial pacing at a consistent 60 BPM, since the heart’s natural atrium is not functioning at all, so it is definitely below the lower limit rate.

Test Case #7:

Purpose: To test AAI when the natural atrium is not pacing at all, under any activity such as shaking. Since AAI is not rate adaptive, the pacemaker should still follow the fixed lower rate limit.

Input conditions:

• Atrial Activity: OFF – pulse width = 0ms

• Ventricular Activity: OFF – pulse width = 0ms

• Heart Rate: 60 BPM

• AV Delay: duration = 30ms

• Activity level = Shaking (walking, running or jogging)

Expected output: The pacemaker arterially paces accordingly at 60 BPM, the lower rate limit and does not follow a desired activity-based rate.

Actual output:

Figure 45. AAI Test Case 7

Result: Pass. Since this pacing mode does not include rate adaptivity, the pacemaker will still pace at the LRL of 60 BPM regardless of any activity.

Pacing Mode: VVI

The variable pacingMode is set to 3, the corresponding pacing mode value of VVI.

Test Case #1:

Purpose: To test operating mode VVI at the minimum resting heart rate of 60 BPM ensuring the ventricle does not pace.

Input conditions:

• Atrial Activity: OFF – pulse width = 0ms

• Ventricular Activity: ON – pulse width =1ms

• Heart Rate: 60 BPM

• AV Delay: duration = 30ms

Expected output: The pacemaker should not pace itself.

Actual output:

Figure 4628. VVI Test Case 1

Result: Pass. The actual output matches the expected, as the pacemaker inhibits ventricular pacing since the heart’s natural ventricle is not below the lower limit rate.

Test Case #2:

Purpose: To test operating mode VVI at the minimum resting heart rate of 90 BPM, which is in between the lower and upper rate limit ensuring the ventricle does not pace.

Input conditions:

• Atrial Activity: OFF – pulse width = 0ms

• Ventricular Activity: ON – pulse width =1ms

• Heart Rate: 90 BPM

• AV Delay: duration = 30ms

Expected output: The pacemaker should not pace itself.

Actual output:

Figure 4729. VVI Test Case 2

Result: Pass. The actual output matches the expected, as the pacemaker inhibits ventricular pacing since the heart’s natural ventricle is not below the lower limit rate.

Test Case #3:

Purpose: To test operating mode VVI at the upper rate limit of 120 BPM ensuring the ventricle does not pace.

Input conditions:

• Atrial Activity: OFF – pulse width = 0ms

• Ventricular Activity: ON – pulse width =1ms

• Heart Rate: 120 BPM

• AV Delay: duration = 30ms

Expected output: The pacemaker should not pace itself.

Actual output:

Figure 4830. VVI Test Case 3

Result: Pass. The actual output matches the expected, as the pacemaker inhibits ventricular pacing since the heart’s natural ventricle is not below the lower limit rate.

Test Case #4:

Purpose: To test operating mode VVI at a heart rate of 30 BPM, which is below the lower rate limit ensuring the ventricle does pace.

Input conditions:

• Atrial Activity: OFF – pulse width = 0ms

• Ventricular Activity: ON – pulse width =1ms

• Heart Rate: 30 BPM

• AV Delay: duration = 30ms

Expected output: The pacemaker should pace itself.

Actual output:

Figure 4931. VVI Test Case 4

Result: Pass. The actual output matches the expected, as the pacemaker ventricular pacing is consistently at 60 BPM filling in the missing spots of the natural ventricle, since the heart’s natural ventricle is below the lower limit rate.

Test Case #5:

Purpose: To test operating mode VVI at the minimum resting heart rate of 60 BPM ensuring the ventricle does not pace.

Input conditions:

• Atrial Activity: OFF – pulse width = 0ms

• Ventricular Activity: ON – pulse width =1ms

• Heart Rate: 60 BPM

• AV Delay: duration = 30ms

Expected output: The pacemaker should not pace itself.

Actual output:

Figure 5032. VVI Test Case 5

Result: Pass. The actual output matches the expected, as the pacemaker inhibits ventricular pacing since the heart’s natural ventricle is not below the lower limit rate.

Test Case #6:

Purpose: To test operating mode VVI at the minimum resting heart rate of 60 BPM ensuring the ventricle does not pace.

Input conditions:

• Atrial Activity: OFF – pulse width = 0ms

• Ventricular Activity: OFF – pulse width = 0ms

• Heart Rate: 30 BPM

• AV Delay: duration = 30ms

Expected output: The pacemaker should not pace itself.

Actual output:

Figure 5133. VVI Test Case 6

Result: Pass. The actual output matches the expected, as the pacemaker inhibits ventricular pacing since the heart’s natural ventricle is not below the lower limit rate.

Test Case #7:

Purpose: To test VVI when the natural ventricle is not pacing at all, under any activity such as shaking. Since VVI is not rate adaptive, the pacemaker should still follow the fixed lower rate limit.

Input conditions:

• Atrial Activity: OFF – pulse width = 0ms

• Ventricular Activity: OFF – pulse width = 0ms

• Heart Rate: 60 BPM

• AV Delay: duration = 30ms

• Activity level = Shaking (walking, running or jogging)

Expected output: The pacemaker arterially paces accordingly at 60 BPM, the lower rate limit and does not follow a desired activity-based rate.

Actual output:

Figure 52. VVI Test Case 7

Result: Pass. Since this pacing mode does not include rate adaptivity, the pacemaker will still pace at the LRL of 60 BPM regardless of any activity.

NOTE**: Test cases 9,10,11 do not apply to the AOO, VOO, AAI, VVI modes as they are not rate adaptive.

Pacing Mode: AOOR

The variable pacingMode is set to 4, the corresponding pacing mode value of AOOR.

Purpose of ALL tests: to verify that the pacemaker ignores the natural heart and atrial paces at a dynamic rate of the calculated desired rate.

Expected Output for ALL tests: Consistent atrial pacing at desired rate.

Test Case #1:

Purpose: To test that AOOR ignores natural atrial activity and paces at the resting desired rate of the pacemaker.

Input conditions:

• Atrial Activity: ON – pulse width = 1ms

• Ventricular Activity: OFF – pulse width = 0ms

• Heart Rate: 60 BPM

• AV Delay: duration = 30ms

• Activity Level: Resting

Expected output: Even though, atrial activity is on, giving the heart a chance, the pacemaker ignores it and paces accordingly at desired rate of 60 BPM.

Actual output:

Figure 53. AOOR Test Case 1

Result: Pass. The actual output matches the expected, as the pacemaker atrial paces at 60 BPM ignoring the heart’s atrial pacing at minimum resting heart rate.

Test Case #2:

Purpose: To test the pacemaker’s atrial pacing ignoring a heart rate of 90 BPM, within the normal range, and paces at the desired resting rate.

Input conditions:

• Atrial Activity: ON – pulse width = 1ms

• Ventricular Activity: OFF – pulse width = 0ms

• Heart Rate: 90 BPM

• AV Delay: duration = 30ms

• Activity Level: Resting

• Desired rate (due to resting): 60 BPM

Expected output: Even though, atrial activity is on, giving the heart a chance, the pacemaker ignores it and paces accordingly at the desired 60 BPM rate.

Actual output:

Figure 54. AOOR Test Case 2

Result: Pass. The actual output matches the expected, as the pacemaker atrial paces at the desired 60 BPM ignoring the heart’s atrial pacing within normal range.

Test Case #3:

Purpose: To test the pacemaker’s atrial pacing ignoring the heart rate of the upper rate limit of 120 BPM, and paces at the desired resting rate of 60 BPM.

Input conditions:

• Atrial Activity: ON – pulse width = 1ms

• Ventricular Activity: OFF – pulse width = 0ms

• Heart Rate: 120 BPM

• AV Delay: duration = 30ms

• Activity Rate = Resting

• Desired heart rate = 60 BPM

Expected output: Even though, atrial activity is on, giving the heart a chance, the pacemaker ignores it and paces accordingly at 60 BPM desired rate.

Actual output:

Figure 55. AOOR Test Case 3

Result: Pass. The actual output matches the expected, as the pacemaker atrial paces at 60 BPM desired rate ignoring the heart’s atrial pacing at the upper rate limit.

Test Case #4:

Purpose: To test the pacemaker’s atrial pacing ignoring a heart rate below the lower rate limit of 30 BPM, and paces at the desired resting rate.

Input conditions:

• Atrial Activity: ON – pulse width = 1ms

• Ventricular Activity: OFF – pulse width = 0ms

• Heart Rate: 30 BPM

• AV Delay: duration = 30ms

• Activity Rate = Resting

• Desired heart rate = 60 BPM

Expected output: Even though, atrial activity is on, giving the heart a chance, the pacemaker ignores it and paces accordingly at 60 BPM of the desired resting rate.

Actual output:

Figure 56. AOOR Test Case 4

Result: Pass. The actual output matches the expected, as the pacemaker atrial paces at 60 BPM ignoring the heart’s atrial pacing below the lower rate limit.

Test Case #5:

Purpose: To test the pacemaker’s atrial pacing ignoring a heart rate of above the upper rate limit of 180 BPM, and pacing at the desired rate regardless.

Input conditions:

• Atrial Activity: ON – pulse width = 1ms

• Ventricular Activity: OFF – pulse width = 0ms

• Heart Rate: 180 BPM

• AV Delay: duration = 30ms

• Activity Rate = Resting

• Desired heart rate = 60 BPM

Expected output: Even though, atrial activity is on, giving the heart a chance, the pacemaker ignores it and paces accordingly at 60 BPM of the desired rate.

Actual output:

Figure 5734*. AOOR Test Case 5*

Result: Pass. The actual output matches the expected, as the pacemaker atrial paces at desired rate of the 60 BPM ignoring the heart’s atrial pacing above the upper rate limit.

Test Case #6:

Purpose: To test the pacemaker’s atrial pacing ignoring the heart’s atrium not pacing at all, and pace regardless at the desired heart rate.

Input conditions:

• Atrial Activity: OFF – pulse width = 0ms

• Ventricular Activity: OFF – pulse width = 0ms

• Heart Rate: 30 BPM

• AV Delay: duration = 30ms

• Activity Rate = Resting

• Desired heart rate = 60 BPM

Expected output: The pacemaker atrial paces accordingly at 60 BPM.

Actual output:

Figure 58. AOOR Test Case 6

Result: Pass. The pacemaker atrial paces consistently at the desired heart rate of 60 BPM, even when the heart’s atrium isn’t beating on its own at all.

Test Case #8:

General Purpose: To test the pacemaker’s atrial pacing behaviour under walking activity, where the desired pacing rate increases above the resting rate. In AOOR, the pacemaker ignores the natural heart and paces the atrium with the desired walking rate not the heart rate.

Case 8.1: Purpose:

To ensure that if the patient’s walking activity level and natural heart rate is below the desired walking rate, then the pacemaker ignores the natural heart rate and increases pacing rate to be like the desired walking rate.

Case 8.2: Purpose:

To ensure that if the patient’s walking activity level and natural heart rate are equal to the desired walking rate, then the pacemaker ignores the natural heart rate, being within the desired range.

Case 8.3: Purpose:

To ensure that if the patient’s walking activity level and natural heart rate is greater than the desired walking rate, then the pacemaker ignores the natural heart rate and paces at the desired rate as long as it’s below MSR.

Input conditions:

• Atrial Activity: OFF – pulse width = 0ms

• Ventricular Activity: OFF – pulse width = 0ms

• Heart Rate: 30 BPM

• AV Delay: duration = 30ms

• Activity level = walking

• Lower limit rate = 60 BPM

• Maximum Limit rate = 120 BPM

• Desired rate = 61.5 BPM = 62 BPM

Expected output of 8.1, 8.2, 8.3: The pacemaker atrial paces accordingly at 62 BPM of the desired rate and ignores the natural heart rate whether it's less than, equal to, or greater than the desired rate.

Actual output:

8.1:

Figure 59. AOOR Test Case 8.1

8.2:

Figure 60. AOOR Test Case 8.2

8.3:

Figure 61. AOOR Test Case 8.3

Result: Pass. The pacemaker atrial paces consistently at the desired heart rate of 61.5 BPM, even when the heart’s rate is equal to or less than or greater than that range.

Test Case #9:

General Purpose: To test the pacemaker’s atrial pacing behaviour under jogging activity, where the desired pacing rate increases above the walking rate. In AOOR, the pacemaker ignores the natural heart and paces the atrium with the desired jogging rate not the heart rate.

Case 9.1: Purpose:

To test that when the heart rate is below the desired jogging rate, the pacemaker ignores the heart rate and increases pacing to the jogging desired rate.

Case 9.2: Purpose:

To test that even when the natural heart rate equals the desired jogging rate, the pacemaker still only follows the desired jogging rate.

Case 9.3: Purpose: To test that even when the natural heart rate exceeds the desired jogging rate, the pacemaker still only follows the desired jogging rate as long as the desired rate is below MSR.

Input conditions:

• Atrial Activity: OFF – pulse width = 0ms

• Ventricular Activity: OFF – pulse width = 0ms

• Heart Rate: 30 BPM

• AV Delay: duration = 30ms

• Activity level = jogging

• Lower limit rate = 60 BPM

• Maximum Limit rate = 120 BPM

• Desired rate = 63 BPM

Expected output of 9.1, 9.2, 9.3: The pacemaker atrial paces accordingly at 63 BPM of the desired rate and ignores the natural heart rate whether it's less than, equal to, or greater than the desired rate.

Actual output:

9.1:

Figure 62. AOOR Test Case 9.1

9.2:

Figure 63. AOOR Test Case 9.2

9.3:

Figure 64. AOOR Test Case 9.3

Result: Pass. The pacemaker atrial paces consistently at the desired heart rate of 63 BPM, even when the heart’s rate is equal to or less than or greater than that range.

Test Case #10:

General Purpose: To test the pacemaker’s atrial pacing behaviour under running activity, where the desired pacing rate increases above the jogging rate. In AOOR, the pacemaker ignores the natural heart and paces the atrium with the desired running rate not the heart rate.

Case 10.1: Purpose:

To test that when the heart rate is below the desired running rate, the pacemaker ignores the heart rate and increases pacing to the running desired rate.

Case 10.2: Purpose:

To test that even when the natural heart rate equals the desired running rate, the pacemaker still only follows the desired running rate.

Case 10.3: Purpose: To test that even when the natural heart rate exceeds the desired running rate, the pacemaker still only follows the desired running rate as long as the desired rate is below MSR.

Input conditions:

• Atrial Activity: OFF – pulse width = 0ms

• Ventricular Activity: OFF – pulse width = 0ms

• Heart Rate: 30 BPM

• AV Delay: duration = 30ms

• Activity level = walking

• Lower limit rate = 60 BPM

• Maximum Limit rate = 120 BPM

Expected output of 10.1, 10.2, 10.3: The pacemaker atrial paces accordingly at 65 BPM of the desired rate and ignores the natural heart rate whether it's less than, equal to, or greater than the desired rate.

Actual output:

10.1:

Figure 65. AOOR Test Case 10.1

10.2:

Figure 66. AOOR Test Case 10.2

10.3:

Figure 67. AOOR Test Case 10.3

Result: Pass. The pacemaker atrial paces consistently at the desired heart rate of 65 BPM, even when the heart’s rate is equal to or less than or greater than that range.

Test Case #11:

Purpose: To test how the pacemaker’s rate adaptive behaviour changes when the Response Factor and Activity Threshold parameters are changed. This shows that the device adapts the desired pacing rate differently all depending on the new parameter settings.

Input conditions:

• Atrial Activity: OFF– pulse width = 0ms

• Ventricular Activity: OFF – pulse width = 0ms

• Heart Rate: 30 BPM

• AV Delay: duration = 30ms

• Activity level = jogging

• Lower limit rate = 60 BPM

• Maximum Limit rate = 120 BPM

• Modified Parameters:

• Response Factor increased (from 8 to 12)

• Activity Threshold increased (from 0 to 4)

Expected output: The desired pacing rate increases with a higher response factor and requires higher activity to trigger rate adaption when the activity threshold is raised. The desired rate will be 96 BPM which was calculated by the following formula:

Desired Rate = Lower Rate Limit + (Activity Level x Response Factor x Scaling Coeff)

= 60 + (4 x 12 x 0.75) = 96 BPM

Note: Activity level can be the following: Resting (0), Walking (2), Jogging (4), & Running (6)

Actual output:

Figure 68. AOOR Test Case 11

Result: Pass. The pacemaker correctly adjusts its desired pacing rate according to the updated Response Factor and Activity Threshold, demonstrating proper rate-adaptive parameter behavior.

Pacing Mode: VOOR

The variable pacingMode is set to 5, the corresponding pacing mode value of VOOR.

Purpose of ALL tests: to verify that the pacemaker ignores the natural heart and ventricular paces at a fixed rate of 60 BPM.

Expected Output for ALL tests: Consistent ventricular pacing at desired rate of 60 BPM.

Test Case #1:

Purpose: To test the pacemaker’s ventricular pacing ignoring the minimum resting heart rate of 60 BPM, and pace at desired rate regardless.

Input conditions:

• Atrial Activity: OFF– pulse width = 0ms

• Ventricular Activity: ON – pulse width = 1ms

• Heart Rate: 60 BPM

• AV Delay: duration = 30ms

• Activity Level: Resting

Expected output: Even though, ventricular activity is on, giving the heart a chance, the pacemaker ignores it and paces accordingly at the desired rate 60 BPM.

Actual output:

Figure 69. VOOR Test Case 1

Result: Pass. The actual output matches the expected, as the pacemaker ventricle paces at 60 BPM ignoring the heart’s ventricular pacing at minimum resting heart rate.

Test Case #2:

Purpose: To test the pacemaker’s ventricular pacing ignoring the normal heart rate of 90 BPM, and pace at desired rate regardless.

Input conditions:

• Atrial Activity: OFF– pulse width = 0ms

• Ventricular Activity: ON – pulse width = 1ms

• Heart Rate: 90 BPM

• Activity Level: Resting

• AV Delay: duration = 30ms

Expected output: Even though, ventricular activity is on, giving the heart a chance, the pacemaker ignores it and paces accordingly at the desired rate of 60 BPM.

Actual output:

Figure 70. VOOR Test Case 2

Result: Pass. The actual output matches the expected, as the pacemaker ventricle paces at 60 BPM ignoring the heart’s ventricular pacing between the lower and upper rate limit.

Test Case #3:

Purpose: To test the pacemaker’s ventricular pacing ignoring the upper rate limit’s heart rate of 120 BPM, and pace at desired rate regardless.

Input conditions:

• Atrial Activity: OFF– pulse width = 0ms

• Ventricular Activity: ON – pulse width = 1ms

• Heart Rate: 120 BPM

• AV Delay: duration = 30ms

• Activity Level: Resting

Expected output: Even though, ventricular activity is on, giving the heart a chance, the pacemaker ignores it and paces accordingly at the desired rate of 60 BPM.

Actual output:

Figure 71. VOOR Test Case 3

Result: Pass. The actual output matches the expected, as the pacemaker ventricle paces at 60 BPM ignoring the heart’s ventricular pacing at the upper rate limit.

Test Case #4:

Purpose: To test the pacemaker’s ventricular pacing ignoring the below lower limit heart rate of 30 BPM, and pace at desired rate regardless.

Input conditions:

• Atrial Activity: OFF– pulse width = 0ms

• Ventricular Activity: ON – pulse width = 1ms

• Heart Rate: 30 BPM

• AV Delay: duration = 30ms

• Activity Level: Resting

Expected output: Even though, ventricular activity is on, giving the heart a chance, the pacemaker ignores it and paces accordingly at the desired rate 60 BPM.

Actual output:

Figure 72. VOOR Test Case 4

Result: Pass. The actual output matches the expected, as the pacemaker ventricle paces at 60 BPM ignoring the heart’s ventricular pacing at the lower rate limit.

Test Case #5:

Purpose: To test the pacemaker’s ventricular pacing ignoring the heart rate above the upper rate limit of 180 BPM, and pace at desired rate regardless.

Input conditions:

• Atrial Activity: OFF– pulse width = 0ms

• Ventricular Activity: ON – pulse width = 1ms

• Heart Rate: 180 BPM

• AV Delay: duration = 30ms

• Activity Level: Resting

Expected output: Even though, ventricular activity is on, giving the heart a chance, the pacemaker ignores it and paces accordingly at the desired rate of 60 BPM.

Actual output:

Figure 73. VOOR Test Case 5

Result: Pass. The actual output matches the expected, as the pacemaker ventricle paces at 60 BPM ignoring the heart’s ventricular pacing above the upper rate limit.

Test Case #6:

Purpose: To test the pacemaker’s ventricular pacing ignoring the heart’s ventricle not pacing at all, and pace at desired rate regardless.

Input conditions:

• Atrial Activity: OFF– pulse width = 0ms

• Ventricular Activity: OFF – pulse width = 0ms

• Heart Rate: 30 BPM

• AV Delay: duration = 30ms

• Activity Level: Resting

Expected output: The pacemaker ventricular paces at the desired rate of 60 BPM.

Actual output:

Figure 74. VOOR Test Case 6

Result: Pass. The actual output matches the expected, as the pacemaker ventricle paces at 60 BPM, even though the heart is not pacing at all.

Test Case #8:

General Purpose: To test the pacemaker’s ventricular pacing behaviour under walking activity, where the desired pacing rate increases above the resting rate. In VOOR, the pacemaker ignores the natural heart and paces the ventricle with the desired walking rate, not the heart rate.

Case 8.1: Purpose: To ensure that if the patient’s walking activity level and natural heart rate is below the desired walking rate, then the pacemaker ignores the natural heart rate and increases pacing rate to be like the desired walking rate.

Case 8.2: Purpose:
To ensure that if the patient’s walking activity level and natural heart rate is equal to the desired walking rate, then the pacemaker ignores the natural heart rate, being within the desired range.

Case 8.3: Purpose:
To ensure that if the patient’s walking activity level and natural heart rate is greater than the desired walking rate, then the pacemaker ignores the natural heart rate and paces at the desired rate as long as it’s below MSR.

Input conditions:

• Atrial Activity: OFF – pulse width = 0ms

• Ventricular Activity: OFF – pulse width = 0ms

• Heart Rate: 30 BPM

• AV Delay: duration = 30ms

• Activity level = walking

• Lower limit rate = 60 BPM

• Maximum Limit rate = 120 BPM

Expected output of 8.1, 8.2, 8.3:
The pacemaker ventricular paces accordingly at 61.5 = 62 BPM of the desired rate and ignores the natural heart rate whether it's less than, equal to, or greater than the desired rate.

Actual output:

8.1:

Figure 76. VOOR Test Case 8.1

8.2:

Figure 77. VOOR Test Case 8.2

8.3:

Figure 78. VOOR Test Case 8.3

Result: Pass. The pacemaker ventricular paces consistently at the desired heart rate of 61.5 BPM, even when the heart’s rate is equal to or less than or greater than that range.

Test Case #9:

General Purpose: To test the pacemaker’s ventricular pacing behaviour under jogging activity, where the desired pacing rate increases above the walking rate. In VOOR, the pacemaker ignores the natural heart and paces the ventricle with the desired jogging rate not the heart rate.

Case 9.1: Purpose: To test that when the heart rate is below the desired jogging rate, the pacemaker ignores the heart rate and increases pacing to the jogging desired rate.

Case 9.2: Purpose:
To test that even when the natural heart rate equals the desired jogging rate, the pacemaker still only follows the desired jogging rate.

Case 9.3: Purpose: To test that even when the natural heart rate exceeds the desired jogging rate, the pacemaker still only follows the desired jogging rate as long as the desired rate is below MSR.

Input conditions:

• Atrial Activity: OFF – pulse width = 0ms

• Ventricular Activity: OFF – pulse width = 0ms

• Heart Rate: 30 BPM

• AV Delay: duration = 30ms

• Activity level = jogging

• Lower limit rate = 60 BPM

• Maximum Limit rate = 120 BPM

Expected output of 9.1, 9.2, 9.3:
The pacemaker ventricular paces accordingly at 63 BPM of the desired rate and ignores the natural heart rate whether it's less than, equal to, or greater than the desired rate.

Actual output:

9.1:

Figure 80. VOOR Test Case 9.1

9.2:

Figure 81. VOOR Test Case 9.2

9.3

Figure 82. VOOR Test Case 9.3

Result: Pass. The pacemaker ventricular paces consistently at the desired heart rate of 63 BPM, even when the heart’s rate is equal to or less than or greater than that range.

Test Case #10:

General Purpose: To test the pacemaker’s ventricular pacing behaviour under running activity, where the desired pacing rate increases above the jogging rate. In VOOR, the pacemaker ignores the natural heart and paces the ventricle with the desired running rate not the heart rate.

Case 10.1: Purpose: To test that when the heart rate is below the desired running rate, the pacemaker ignores the heart rate and increases pacing to the running desired rate.

Case 10.2: Purpose:
To test that even when the natural heart rate equals the desired running rate, the pacemaker still only follows the desired running rate.

Case 10.3: Purpose: To test that even when the natural heart rate exceeds the desired running rate, the pacemaker still only follows the desired running rate as long as the desired rate is below MSR.

Input conditions:

• Atrial Activity: OFF – pulse width = 0ms

• Ventricular Activity: OFF – pulse width = 0ms

• Heart Rate: 30 BPM

• AV Delay: duration = 30ms

• Activity level = running

• Lower limit rate = 60 BPM

• Maximum Limit rate = 120 BPM

• Desired rate = 64.5 = 65 BPM

Expected output of 10.1, 10.2, 10.3:
The pacemaker ventricular paces accordingly at 65 BPM of the desired rate and ignores the natural heart rate whether it's less than, equal to, or greater than the desired rate.

Actual output:

10.1

Figure 83. VOOR Test Case 10.1

10.2

Figure 84. VOOR Test Case 10.2

10.3

Figure 85. VOOR Test Case 10.3

Result: Pass. The pacemaker ventricular paces consistently at the desired heart rate of 65 BPM, even when the heart’s rate is equal to or less than or greater than that range.

Test Case #11:

Purpose: To test how the pacemaker’s rate adaptive behaviour in VOOR changes when the Response Factor and Activity Threshold parameters are changed. This shows that the device adapts the desired pacing rate differently depending on the new parameter settings.

Input conditions:

• Atrial Activity: OFF– pulse width = 0ms

• Ventricular Activity: OFF – pulse width = 0ms

• Heart Rate: 30 BPM

• AV Delay: duration = 30ms

• Activity level = Jogging

• Lower limit rate = 60 BPM

• Maximum Limit rate = 120 BPM

• Modified Parameters:

• Response Factor increased (from 8 to 12)

• Activity Threshold increased (from 0 to 4)

Expected output: The desired ventricular pacing rate increases with a higher response factor and requires higher activity to trigger rate adaption when the activity threshold is raised. Since VOOR always ignores the natural heart, the pacemaker will pace at the new desired rate calculated using the updated parameters. he desired rate will be 96 BPM which was calculated by the following formula:

Desired Rate = Lower Rate Limit + (Activity Level x Response Factor x Scaling Coeff)

= 60 + (4 x 12 x 0.75) = 96 BPM

Note: Activity level can be the following: Resting (0), Walking (2), Jogging (4), & Running (6)

Actual output:

Figure 85. VOOR Test Case 11

Result: Pass. The pacemaker correctly adapts the ventricular pacing rate based on the increased Response Factor and Activity Threshold, showing proper rate-adaptive behaviour in VOOR mode.

Pacing Mode: AAIR

The variable pacingMode is set to 6, the corresponding pacing mode value of AAIR.

Purpose of ALL tests: to verify that the pacemaker’s atrial only paces at desired rate when the natural atrium is below the desired rate, otherwise it’s inhibited.

Test Case #1:

Purpose: To test operating mode AAIR at the minimum resting heart rate of 60 BPM ensuring the atrial does not pace.

Input conditions:

• Atrial Activity: ON – pulse width = 1ms

• Ventricular Activity: OFF – pulse width = 0ms

• Heart Rate: 60 BPM

• AV Delay: duration = 30ms

• Activity Level = resting

Expected output: The pacemaker should not pace itself.

Actual output:

<img src="./media/image79.png" title="A screenshot of a computer

AI-generated content may be incorrect." style="width:6.5in;height:2.69792in" />

Figure 86. AAIR Test Case 1

Result: Pass. The actual output matches the expected, as the pacemaker inhibits atrial pacing since the heart’s natural atrium is not below the lower limit rate.

Test Case #2:

Purpose: To test operating mode AAIR at a heart rate of 90 BPM, which is in between the lower and upper rate limit ensuring the atrial does not pace.

Input conditions:

• Atrial Activity: ON – pulse width = 1ms

• Ventricular Activity: OFF – pulse width = 0ms

• Heart Rate: 90 BPM

• AV Delay: duration = 30ms

• Activity Level = resting

Expected output: The pacemaker should not pace itself.

Actual output:

<img src="./media/image80.png" title="A screenshot of a graph

AI-generated content may be incorrect." style="width:6.5in;height:2.66667in" />

Figure 87. AAIR Test Case 2

Result: Pass. The actual output matches the expected, as the pacemaker inhibits atrial pacing since the heart’s natural atrium is not below the lower limit rate.

Test Case #3:

Purpose: To test operating mode AAIR at the upper rate limit of 120 BPM ensuring the atrial does not pace.

Input conditions:

• Atrial Activity: ON – pulse width = 1ms

• Ventricular Activity: OFF – pulse width = 0ms

• Heart Rate: 120 BPM

• AV Delay: duration = 30ms

• Activity Level = resting

Expected output: The pacemaker should not pace itself.

Actual output:

<img src="./media/image81.png" title="A screenshot of a computer

AI-generated content may be incorrect." style="width:6.5in;height:3.125in" />

Figure 22. AAI Test Case 3

Result: Pass. The actual output matches the expected, as the pacemaker inhibits atrial pacing since the heart’s natural atrium is not below the lower limit rate.

Test Case #4:

Purpose: To test operating mode AAIR at a heart rate of 30 BPM, which is below the lower rate limit ensuring the atrial does pace.

Input conditions:

• Atrial Activity: ON – pulse width = 1ms

• Ventricular Activity: OFF – pulse width = 0ms

• Heart Rate: 30 BPM

• AV Delay: duration = 30ms

Expected output: The pacemaker should pace itself at the desired rate of 60BPM.

Actual output:

<img src="./media/image82.png" title="A screenshot of a graph

AI-generated content may be incorrect." style="width:6.5in;height:2.71875in" />

Figure 23. AAI Test Case 4

Result: Pass. The actual output matches the expected, as the pacemaker is atrial pacing at the desired limit of 60 BPM, since the heart’s natural atrium is below the lower limit rate.

Test Case #5:

Purpose: To test operating mode AAIR at a heart rate of 180 BPM, which is higher than the upper rate limit ensuring the atrial does not pace.

Input conditions:

• Atrial Activity: ON – pulse width = 1ms

• Ventricular Activity: OFF – pulse width = 0ms

• Heart Rate: 180 BPM

• AV Delay: duration = 30ms

• Activity Level = resting

Expected output: The pacemaker should not pace itself.

Actual output:

<img src="./media/image83.png" title="A screenshot of a computer

AI-generated content may be incorrect." style="width:6.5in;height:2.71875in" />

Figure 24. AAI Test Case 5

Result: Pass. The actual output matches the expected, as the pacemaker inhibits atrial pacing since the heart’s natural atrium is not below the lower limit rate.

Test Case #6:

Purpose: To test operating mode AAIR when the natural atrium is not pacing at all, ensuring the pacemaker’s atrial does pace.

Input conditions:

• Atrial Activity: OFF – pulse width = 0 ms

• Ventricular Activity: OFF – pulse width = 0ms

• Heart Rate: 30 BPM

• AV Delay: duration = 30ms

• Activity Level = resting

Expected output: The pacemaker should pace itself.

Actual output:

<img src="./media/image84.png" title="A screenshot of a graph

AI-generated content may be incorrect." style="width:6.5in;height:2.71875in" />

Figure 25. AAI Test Case 6

Result: Pass. The actual output matches the expected, as the pacemaker is atrial pacing at a consistent 60 BPM desired rate, since the heart’s natural atrium is not functioning at all, so it is definitely below the lower limit rate.

Test Case #8:

General Purpose: To test the pacemaker’s atrial pacing behavior under walking activity where the desired pacing rate increases above the resting rate. In AAIR mode, the pacemaker only paces the atrium if the natural atrium is atrium at the desired rate if the natural atrium is below the desired waling rate.

Case 8.1: Purpose: To ensure that when the patient’s walking activity level and natural heart rate is below the desired walking rate, the pacemaker paces the atrium at the desired walking rate.

Case 8.2: Purpose:
To ensure that when the natural heart rate equals the desired walking rate, the pacemaker inhibits atrial pacing because it is within the desired range.

Case 8.3: Purpose:
To ensure that when the natural heart rate is greater than the desired walking rate, the pacemaker inhibits atrial pacing as long as the natural rate is above the desired rate.

Input conditions:

• Atrial Activity: OFF – pulse width = 0ms

• Ventricular Activity: OFF – pulse width = 0ms

• Heart Rate: 30 BPM

• AV Delay: duration = 30ms

• Activity level = walking

• Lower limit rate = 60 BPM

• Maximum Limit rate = 120 BPM

Expected output of 8.1, 8.2, 8.3:
The pacemaker atrial paces at the desired rate of approximately 62 BPM only when the natural atrium is below the desired rate, and inhibits pacing when the natural rate is equal to or greater than the desired rate

Actual output:

8.1 8.2

8.3

Result: Pass. The pacemaker behaves correctly by pacing only when the natural atrium is below the desired heart rate of 61.5 BPM.

Test Case #9:

General Purpose: To test the pacemaker’s atrial pacing behaviour under jogging activity, where the desired pacing rate increases above the walking rate. In AAIR, the pacemaker only paces when the natural atrium is below the desired jogging rate.

Case 9.1: Purpose: To test that when the natural heart rate is below the desired jogging rate, the pacemaker atrially paces at the jogging desired rate.

Case 9.2: Purpose:
To test that when the natural heart rate equals the desired jogging rate, the pacemaker inhibits atrial pacing.

Case 9.3: Purpose: To test that when the natural heart rate exceeds the desired jogging rate, the pacemaker inhibits atrial pacing as long as the desired rate is below MSR.

Input conditions:

• Atrial Activity: OFF – pulse width = 0ms

• Ventricular Activity: OFF – pulse width = 0ms

• Heart Rate: 30 BPM

• AV Delay: duration = 30ms

• Activity level = jogging

• Lower limit rate = 60 BPM

• Maximum Limit rate = 120 BPM

Expected output of 9.1, 9.2, 9.3:
The pacemaker artially paces at 63 BPM desired rate only when the natural atrium is below the desired jogging rate, and inhibits pacing when the natural rate is equal to or greater than the desired rate.

Actual output:

9.1

9.2

9.3

Result: Pass. The pacemaker paces at 63 BPM only when needed, and inhibits pacing when the natural heart rate is equal to or higher than that range.

Test Case #10:

General Purpose: To test the pacemaker’s atrial pacing behaviour under running activity, where the desired pacing rate increases above the jogging rate. In AAIR, the pacemaker paces only when the natural atrium is below the desired running rate.

Case 10.1: Purpose: To test that when the natural heart rate is below the desired running rate, the pacemaker atrially paces at the running desired rate.

Case 10.2: Purpose:
To test that when the natural heart rate equals the desired running rate, the pacemaker inhibits atrial pacing.

Case 10.3: Purpose: To test that when the natural heart rate exceeds the desired running rate, the pacemaker inhibits atrial pacing as long as the desired rate is below MSR.

Input conditions:

• Atrial Activity: OFF – pulse width = 0ms

• Ventricular Activity: OFF – pulse width = 0ms

• Heart Rate: 30 BPM

• AV Delay: duration = 30ms

• Activity level = running

• Lower limit rate = 60 BPM

• Maximum Limit rate = 120 BPM

• Desired rate = 64.5 = 65 BPM

Expected output of 10.1, 10.2, 10.3:
The pacemaker ventricular paces accordingly at 65 BPM of the desired rate and ignores the natural heart rate whether it's less than, equal to, or greater than the desired rate.

Actual output:

10.1:

10.2:

10.3:

Result: Pass. The pacemaker ventricular paces consistently at the desired heart rate of 65 BPM, even when the heart’s rate is equal to or less than or greater than that range.

Test Case #11:

Purpose: To test how the pacemaker’s rate adaptive behaviour in AAIR changes when the Response Factor and Activity Threshold parameters are changed. This shows that the device adapts the desired pacing rate differently depending on the new parameter settings.

Input conditions:

• Atrial Activity: OFF– pulse width = 0ms

• Ventricular Activity: OFF – pulse width = 0ms

• Heart Rate: 30 BPM

• AV Delay: duration = 30ms

• Activity Level: Resting (doesn’t matter)

• Activity level = Jogging

• Lower limit rate = 60 BPM

• Maximum Limit rate = 120 BPM

• Modified Parameters:

• Response Factor increased (from 8 to 12)

• Activity Threshold increased (from 0 to 4)

Expected output: The desired ventricular pacing rate increases with a higher response factor and requires higher activity to trigger rate adaption when the activity threshold is raised. Since VOOR always ignores the natural heart, the pacemaker will pace at the new desired rate calculated using the updated parameters. the desired rate will be 96 BPM which was calculated by the following formula:

Desired Rate = Lower Rate Limit + (Activity Level x Response Factor x Scaling Coeff)

= 60 + (4 x 12 x 0.75) = 96 BPM **NOTE this formula is applied when finding any of the desired rates

Note: Activity level can be the following: Resting (0), Walking (2), Jogging (4), & Running (6)

Actual output:

Result: Pass. The pacemaker correctly adapts the atrium pacing rate based on the increased Response Factor and Activity Threshold, showing proper rate-adaptive behaviour in AAIR mode.

Pacing Mode: VVIR

The variable pacingMode is set to 7, the corresponding pacing mode value of VVIR.

Test Case #1:

Purpose: To test operating mode VVIR at the minimum resting heart rate of 60 BPM ensuring the ventricle does not pace.

Input conditions:

• Atrial Activity: OFF – pulse width = 0ms

• Ventricular Activity: ON – pulse width =1ms

• Heart Rate: 60 BPM

• AV Delay: duration = 30ms

• Activity Level = resting

Expected output: The pacemaker should not pace itself.

Actual output:

<img src="./media/image92.png" title="A screenshot of a computer

AI-generated content may be incorrect." style="width:6.5in;height:2.72917in" />

Figure 26. VVI Test Case 1

Result: Pass. The actual output matches the expected, as the pacemaker inhibits ventricular pacing since the heart’s natural ventricle is not below the lower limit rate.

Test Case #2:

Purpose: To test operating mode VVIR at the minimum resting heart rate of 90 BPM, which is in between the lower and upper rate limit ensuring the ventricle does not pace.

Input conditions:

• Atrial Activity: OFF – pulse width = 0ms

• Ventricular Activity: ON – pulse width =1ms

• Heart Rate: 90 BPM

• AV Delay: duration = 30ms

• Activity Level = resting

Expected output: The pacemaker should not pace itself.

Actual output:

<img src="./media/image93.png" title="A screenshot of a graph

AI-generated content may be incorrect." style="width:6.5in;height:2.70833in" />

Figure 27. VVI Test Case 2

Result: Pass. The actual output matches the expected, as the pacemaker inhibits ventricular pacing since the heart’s natural ventricle is not below the lower limit rate.

Test Case #3:

Purpose: To test operating mode VVI at the upper rate limit of 120 BPM ensuring the ventricle does not pace.

Input conditions:

• Atrial Activity: OFF – pulse width = 0ms

• Ventricular Activity: ON – pulse width =1ms

• Heart Rate: 120 BPM

• AV Delay: duration = 30ms

• Activity Level = resting

Expected output: The pacemaker should not pace itself.

Actual output:

<img src="./media/image94.png" title="A screenshot of a graph

AI-generated content may be incorrect." style="width:6.5in;height:2.70833in" />

Figure 28. VVIR Test Case 3

Result: Pass. The actual output matches the expected, as the pacemaker inhibits ventricular pacing since the heart’s natural ventricle is not below the lower limit rate.

Test Case #4:

Purpose: To test operating mode VVIR at a heart rate of 30 BPM, which is below the lower rate limit ensuring the ventricle does pace.

Input conditions:

• Atrial Activity: OFF – pulse width = 0ms

• Ventricular Activity: ON – pulse width =1ms

• Heart Rate: 30 BPM

• AV Delay: duration = 30ms

• Activity Level = resting

Expected output: The pacemaker should pace itself.

Actual output:

<img src="./media/image95.png" title="A screenshot of a graph

AI-generated content may be incorrect." style="width:6.5in;height:2.71875in" />

Figure 29. VVIR Test Case 4

Result: Pass. The actual output matches the expected, as the pacemaker ventricular pacing is consistently at 60 BPM filling in the missing spots of the natural ventricle, since the heart’s natural ventricle is below the lower limit rate.

Test Case #5:

Purpose: To test operating mode VVIR at the minimum resting heart rate of 60 BPM ensuring the ventricle does not pace.

Input conditions:

• Atrial Activity: OFF – pulse width = 0ms

• Ventricular Activity: ON – pulse width =1ms

• Heart Rate: 60 BPM

• AV Delay: duration = 30ms

• Activity Level = resting

Expected output: The pacemaker should not pace itself.

Actual output:

<img src="./media/image96.png" title="A screenshot of a graph

AI-generated content may be incorrect." style="width:6.5in;height:2.72917in" />

Figure 30. VVI Test Case 5

Result: Pass. The actual output matches the expected, as the pacemaker inhibits ventricular pacing since the heart’s natural ventricle is not below the lower limit rate.

Test Case #6:

Purpose: To test operating mode VVIR at the minimum resting heart rate of 60 BPM ensuring the ventricle does not pace.

Input conditions:

• Atrial Activity: OFF – pulse width = 0ms

• Ventricular Activity: OFF – pulse width = 0ms

• Heart Rate: 30 BPM

• AV Delay: duration = 30ms

• Activity Level = resting

• Desired rate = 60 BPM

Expected output: The pacemaker should not pace itself.

Actual output:

<img src="./media/image97.png" title="A screenshot of a graph

AI-generated content may be incorrect." style="width:6.5in;height:2.72917in" />

Figure 31. VVI Test Case 6

Result: Pass. The actual output matches the expected, as the pacemaker inhibits ventricular pacing since the heart’s natural ventricle is not below the lower limit rate.

Test case #8:

General Purpose: To test the pacemaker’s ventricular pacing behaviour under walking activity, the desired pacing rate increases above the resting rate. In VVIR, the pacemaker only paces the ventricle if the natural ventricular rate is below the desired walking rate.

Case 8.1: Purpose:

To ensure that when the natural ventricular rate is below the desired walking rate, the pacemaker ventricularly paces at the desired walking rate.

Case 8.2: Purpose:

To ensure that when the natural ventricular rate equals the desired walking rate, the pacemaker inhibits pacing.

Case 8.3: Purpose:

To ensure that when the natural ventricular rate is above the desired walking rate, the pacemaker inhibits pacing as long as the desired walking rate is below MSR.

Input conditions (Test 8):

• Atrial Activity: OFF – pulse width = 0ms

• Ventricular Activity: ON – pulse width = 1ms

• Heart Rate: 30 BPM

• AV Delay: duration = 30ms

• Activity level = walking

• Lower rate limit = 60 BPM

• Maximum Limit Rate = 120 BPM

Expected output (8.1, 8.2, 8.3):

The pacemaker ventricularly paces at approximately 62 BPM only when the natural ventricular rate is below the desired rate, and inhibits pacing when the natural rate is equal to or greater than the desired rate.

Actual output:

8.1:

8.2:

8.3:

Result:
Pass. The pacemaker behaves correctly by pacing only when the natural ventricular rate is below the desired heart rate.

Test Case #9 (Jogging)

General Purpose:

To test the pacemaker’s ventricular pacing behaviour under jogging activity, where the desired pacing rate increases above the walking rate. In VVIR mode, pacing is delivered only if the natural ventricle is below the desired jogging rate.

Case 9.1: Purpose:

To test that when the natural ventricular rate is below the desired jogging rate, the pacemaker paces at the desired jogging rate.

Case 9.2: Purpose:

To test that when the natural ventricular rate equals the desired jogging rate, the pacemaker inhibits pacing.

Case 9.3: Purpose: To test that when the natural ventricular rate exceeds the desired jogging rate, the pacemaker inhibits pacing as long as the desired jogging rate is below MSR.

Input conditions (Test 9):

• Atrial Activity: OFF – pulse width = 0ms

• Ventricular Activity: OFF – pulse width = 0ms

• Heart Rate: 30 BPM

• AV Delay: duration = 30ms

• Activity level = jogging

• Lower rate limit = 60 BPM

• Maximum Limit Rate = 120 BPM

Expected output (9.1, 9.2, 9.3):

The pacemaker ventricularly paces at 63 BPM which is the desired rate only when the natural ventricular rate is below the desired jogging rate, and inhibits pacing when the natural rate is equal to or greater than the desired rate.

Actual Output:

9.1:

9.2:

9.3:

Result:
Pass. The pacemaker paces at 63 BPM only when needed and inhibits pacing otherwise.

VVIR – Test Case #10 (Running)

General Purpose:

To test the pacemaker’s ventricular pacing behaviour under running activity, where the desired pacing rate increases above the jogging rate.
In VVIR, pacing occurs only when the natural ventricle is below the desired running rate.

Case 10.1 — natural heart rate < desired running rate

Purpose:
To test that when the natural ventricular rate is below the desired running rate, the pacemaker paces at the running desired rate.

Case 10.2 — natural heart rate = desired running rate

Purpose:
To test that when the natural ventricular rate equals the desired running rate, the pacemaker inhibits pacing.

Case 10.3 — natural heart rate > desired running rate

Purpose:
To test that when the natural ventricular rate exceeds the desired running rate, the pacemaker inhibits pacing as long as the desired rate is below MSR.

Input conditions (Test 10):

• Atrial Activity: OFF – pulse width = 0ms

• Ventricular Activity: OFF – pulse width = 0ms

• Heart Rate: 30 BPM

• AV Delay: duration = 30ms

• Activity level = running

• Lower rate limit = 60 BPM

• Maximum Limit Rate = 120 BPM

• Desired rate = 64.5 BPM → 65 BPM

Expected output (10.1, 10.2, 10.3):

The pacemaker ventricularly paces at 65 BPM only when the natural ventricular rate is below the desired running rate, and inhibits pacing when the natural rate is equal to or greater than the desired rate.

Actual Outcome:

10.1:

10.2:

10.3:

Result:
Pass. The pacemaker paces only when the natural ventricular rate is below the desired rate for running and inhibits pacing otherwise.

Test case 11:

Purpose: To test how the pacemaker’s rate adaptive behavior in VVIR changes when the Response Factor and Activity Threshold parameters are changed. This will verify that the pacemaker adjusts the desired ventricular pacing rate depending on the updated parameter settings.

Input conditions:

• Atrial Activity: OFF– pulse width = 0ms

• Ventricular Activity: OFF – pulse width = 0ms

• Heart Rate: 30 BPM

• AV Delay: duration = 30ms

• Activity Level: Jogging

• Lower limit rate = 60 BPM

• Maximum Limit rate = 120 BPM

• Modified Parameters:

• Response Factor increased (e.g., from 8 to 12)

• Activity Threshold increased (e.g., from 0 to 4)

Expected Output: The desired ventricular pacing rate will become higher when the Response Factor is increased, and it will need more activity to trigger rate adaptation when the Activity Threshold is raised. The VVIR mode ignores the atrium completely, thus only ventricular pacing is delivered, thus the pacemaker will pace at the new desired rate of 96 BPM which is found by the following formula:

Desired Rate = Lower Rate Limit + (Activity Level x Response Factor x Scaling Coeff)

= 60 + (4 x 12 x 0.75) = 96 BPM

Note: Activity level can be the following: Resting (0), Walking (2), Jogging (4), & Running (6)

Actual output:

Result:

Pacing Mode DDDR:

The variable pacingMode is set to 8, the corresponding pacing mode value of DDDR.

Test Case #12:

Purpose:
To test the pacemaker’s dual-chamber timing behaviour when the AV Delay is changed, ensuring the pacemaker still maintains proper atrial tracking and ventricular pacing at the new timing interval.

Input conditions:
Atrial Activity: OFF – pulse width = 0ms
Ventricular Activity: OFF – pulse width = 0ms
Heart Rate: 30 BPM
AV Delay: duration = modified value
Activity Level: Resting
Desired rate: 60 BPMz

Expected output:
The pacemaker paces the atrium at 60 BPM.
After each atrial pace, the pacemaker waits the new AV Delay and delivers a ventricular pace if no intrinsic ventricular event is detected. The ventricular pace timing should visibly shift in HeartView according to the updated AV Delay.

Actual output:

Result:
Pass. The actual output matches the expected, with the ventricular pacing occurring consistently after the updated AV Delay.

Test Case #13:

Purpose:
To test the pacemaker’s full dual-chamber pacing behaviour when the heart provides no intrinsic atrial or ventricular activity, confirming that DDDR performs sequential A PACE and V PACE.

Input conditions:
Atrial Activity: OFF – pulse width = 0ms
Ventricular Activity: OFF – pulse width = 0ms
Heart Rate: 30 BPM
AV Delay: duration = 30ms
Activity Level: Resting
Desired rate: 60 BPM

Expected output:
The pacemaker paces the atrium at 60 BPM due to absence of intrinsic atrial activity.
The pacemaker then paces the ventricle after the AV Delay, resulting in clear sequential AP followed by VP.

Actual output:

Result: Pass. The actual output matches the expected, as the pacemaker correctly delivers A PACE and V PACE with appropriate AV synchrony.

Test Case #14:

Purpose:
To test the pacemaker’s behaviour when atrial pacing is required but intrinsic ventricular activity is present, verifying that DDDR delivers A PACE and V SENSE.

Input conditions:
Atrial Activity: OFF – pulse width = 0ms
Ventricular Activity: ON – pulse width = 1ms
Heart Rate: 60 BPM
AV Delay: duration = 30ms
Activity Level: Resting

Expected output:
The pacemaker paces the atrium at 60 BPM desired rate because no intrinsic atrial activity is present. The pacemaker then waits the AV Delay and inhibits ventricular pacing because intrinsic ventricular activity arrives on time, resulting in A PACE and V SENSE.

Actual output:

Result:
Pass. The actual output matches the expected, as the pacemaker correctly delivers A PACE and inhibits V PACE due to intrinsic ventricular sensing.

**Test Case #**15:

Purpose:
To test the pacemaker’s behaviour when intrinsic atrial activity is present but intrinsic ventricular activity is absent, confirming A SENSE and V PACE behaviour.

Input conditions:
Atrial Activity: ON – pulse width = 1ms
Ventricular Activity: OFF – pulse width = 0ms
Heart Rate: 60 BPM
AV Delay: duration = 30ms
Activity Level: Resting
Desired rate: 60 BPM

Expected output:
The pacemaker inhibits atrial pacing and tracks the intrinsic atrial activity (A SENSE).
After each sensed atrial event, the pacemaker waits the AV Delay and paces the ventricle, resulting in V PACE.

Actual output:

Result:
Pass. The actual output matches the expected, as the pacemaker senses atrial activity and correctly provides ventricular pacing after AV Delay.

Test Case #16:

Purpose:
To test full inhibition of pacing when both intrinsic atrial and ventricular activity are present, confirming A SENSE and V SENSE behaviour.

Input conditions:
Atrial Activity: ON – pulse width = 1ms
Ventricular Activity: ON – pulse width = 1ms
Heart Rate: 60 BPM
AV Delay: duration = 30ms
Activity Level: Resting
Desired rate: 60 BPM

Expected output:
The pacemaker inhibits atrial pacing due to intrinsic atrial sensing and inhibits ventricular pacing due to intrinsic ventricular sensing.
HeartView should show A SENSE and V SENSE with no pacing spikes.

Actual output:

Result: Pass. The actual output matches the expected, as the pacemaker correctly inhibits both atrial and ventricular pacing when intrinsic activity is present.

Mode: General Rate Adaptivity:

Purpose: To check that the pacemaker adjusts the desired pacing rate faster or slower depending on the configured Reaction time or Recovery time.

Expected Output:

• Test 1: When the reaction time increases, the pacing takes longer to reach the desired state and vice versa.

• Test 2: When the recovery time increases, the pacing takes longer to reach the desired rate.

Actual Output:

Result: Pass.

The results match the expectations where, when Reaction time = 10s, the desired rate rises quickly during activity. When Reaction time = 30s, the desired rate rises more gradually, taking longer to reach the adaptive rate.

As for Recovery time, when Recovery time = 1 min, the desired rate falls back to the lower limit quickly after activity stops, but when it equals 5 min, the decrease is slower and more gradual as well.

All of this shows the pacemaker rate adaptive responds correctly where it slows down or speeds up depending on the configured Reaction Time and Recovery Time values.

4 Assurance Case