Week12

Week 12 Progress: BLE Control, Reset Commands, and Exporting Graphs

Objective:

To finalize app interaction logic by adding BLE-based command sending (RESET), exporting chart visuals to the gallery, and refining the feedback interface.

Implementation:

This week focused on expanding interactivity, BLE write operations, and implementing advanced features such as exporting graph images. These additions greatly enhanced the app’s practicality and user-friendliness.

  1. Reset Command via BLE Write:

The reset function allows users to instruct the microcontroller to restart all monitoring. The code sends a "RESET" string to a writable BLE characteristic (19B10003...) using:


commandCharacteristic.value = "RESET".toByteArray()

gatt.writeCharacteristic(commandCharacteristic)

dataList.clear()



This command clears chart history and resets backend data processing, with confirmation shown via a Toast.

  1. Image Export of Chart View:

A bitmap of the chart is captured from the Compose surface using drawing cache logic. The captured image is saved using the Android MediaStore API:


val bitmap = Bitmap.createBitmap(view.drawingCache)

saveBitmapToGallery(bitmap)



Support is included for both Android 10+ and legacy directory structures, making it future-proof. A success/failure message is displayed after each export operation.

  1. Descriptor Configuration for Notifications:

BLE notification setup is handled during service discovery. A CCCD descriptor is written to ensure that the app is notified whenever the BLE peripheral updates a characteristic:


val descriptor = stateCharacteristic.getDescriptor(UUID.fromString("00002902-..."))

descriptor?.value = BluetoothGattDescriptor.ENABLE_NOTIFICATION_VALUE

gatt.writeDescriptor(descriptor)


Without this step, BLE callbacks like onCharacteristicChanged wouldn’t trigger.

  1. UI Enhancements and Command Buttons:

UI buttons for Disconnect, Reset, and Export were added and tested. Conditional display logic ensures that only relevant controls are visible based on connection state. Every action provides immediate feedback through Toast.makeText.

Results:

  • BLE command writing works reliably across test cases.

  • Users can reset the monitoring system from the app without restarting hardware.

  • Real-time BLE updates now support notification-based architecture.

  • Exported chart images verify app completeness and readiness for demo.





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