Week9

Week 9 Progress: State Machine Design and System Modularity


Objective

To modularize the ankle monitoring code by implementing a two-state state machine (MOVING / STATIONARY) to detect whether the user is currently in motion or in a stable position for trend detection. The goal is to trigger alarm conditions only when reliable stationary measurements are available.


Implementation: State Machine Architecture

The firmware now uses a simple finite state machine (FSM) with two primary states:

  • MOVING: The user is moving, sensor data fluctuates significantly, and trend evaluation is temporarily disabled.

  • STATIONARY: The user is still. Trend data is collected to determine if ankle swelling is occurring.

📌 Transition Logic:

  • Transition from MOVING → STATIONARY happens when sensor variation over a defined window is small (low deviation).

  • Transition from STATIONARY → MOVING happens when at least 3 significantly different readings appear within the window (indicating movement or postural change).

🔍 Example Code: MOVING → STATIONARY


🔍 Example Code: STATIONARY → MOVING


Results

  • The state machine reliably filters out noisy periods of movement.

  • Transitions are smooth and based on defined thresholds.

  • Forms a clean foundation for applying long-term trend detection in the next stage.








Comments

Popular posts from this blog

Week1

Week4