Week8

Week 8 Progress: BLE Android App Development and Testing

Objective:
To implement and test the BLE (Bluetooth Low Energy) communication feature on the Android mobile application, enabling real-time reception of status, alarm, and ADC data from the ankle-worn hardware device.

BLE Communication Principle (Android BLE Overview):
BLE is a wireless protocol designed for short-range, low-power communication. It works via a client-server model, where:

  • Peripheral (Server): The ankle-worn device (XIAO nRF52840), advertises services and characteristics.

  • Central (Client): The Android phone scans for nearby BLE devices, connects to a chosen peripheral, and subscribes to its characteristics.

On Android, the workflow is as follows:

  1. Scan for nearby devices using BluetoothLeScanner.

  2. Connect to a selected device using connectGatt().

  3. Discover Services to identify the available UUIDs.

  4. Enable Notifications for a given characteristic via descriptor 0x2902.

  5. Receive Updates when the peripheral updates that characteristic value (e.g., every second).

Implementation:
The app was developed using Jetpack Compose and Kotlin in Android Studio. It consists of:

  • A device scanning screen

  • A data display screen showing status, alarm, and live ADC values

  • BLE service handlers for connection, notification, and data parsing

🔧 Key Code Analysis

1. Device Scanning and Connection

  • Starts BLE scan and connects to selected device using a BluetoothGattCallback.

2. Service Discovery and Notification Enablement

  • This block enables BLE notifications from the device's custom characteristic. UUIDs were manually matched with the board's firmware.

3. Data Handling from Peripheral (BLE Notification)


  • Receives composite data string like "MOVING,ALARM,6423"

  • Splits it into status, alarm, and ADC value, and updates UI in real time

Results:

  • BLE device scanning and connection on Android were successful

  • Characteristic data was correctly received once per second and parsed without error

  • Real-time system status, alarm state, and ADC values were displayed in the app

  • The app provided stable and low-latency updates, verifying correct BLE integration with the board


Comments

Post a Comment

Popular posts from this blog

Week13

Image
Week 13 Progress: Testing Strategy Design and Simulation Objective: This week’s objective was to investigate the physiological significance of ankle swelling as a symptom of heart failure and to design a testing methodology that simulates this condition using available tools. The aim was to assess whether the current smart sock prototype could reliably detect early signs of edema through the flex sensor readings and trend detection algorithm implemented in previous weeks. Implementation: To begin with, a thorough background study was conducted on the clinical causes and relevance of ankle swelling, or  peripheral edema , especially in heart failure patients: According to the UK’s NHS website,  oedema  occurs when excess fluid builds up in body tissues, often affecting the ankles and feet. It’s particularly common among elderly or sedentary individuals and can be a sign of more serious conditions like  heart failure  or kidney problems【NHS†source】. HeartFailureMa...
Read more

Week9

Image
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 p...
Read more

Week1

Image
Week 1 Progress: System Testing and Redesign Planning During the first two weeks of the project, my main task was to test the previous prototype and develop improvement plans based on its performance. The system consists of two main parts: a wristband and an anklet module. As shown in the figure, the wristband worked relatively well. Once worn, it was able to accurately display heart rate and blood oxygen levels, although the SpO₂ readings occasionally showed inconsistencies. In contrast, the anklet system had several issues. It frequently produced errors during testing and often triggered false alarms when tested with a 3D-printed cone-shaped object. Additionally, the circuit design was overly complex and bulky, making it uncomfortable to wear.
Read more