Week7

Week 7 Progress: BLE Transmission Testing on XIAO nRF52840

Objective:
To verify the BLE (Bluetooth Low Energy) functionality of the Seeed Studio XIAO nRF52840 microcontroller and test real-time data transmission from the ankle monitoring system to a mobile app.

Hardware Background:



 The microcontroller used is the Seeed Studio XIAO nRF52840, a compact and powerful board designed for wireless sensing applications. Key features relevant to this project include:

  • Processor: Nordic nRF52840 (ARM Cortex-M4F, 64 MHz)

  • Memory: 256 KB RAM, 1 MB Flash

  • Connectivity: Integrated BLE 5.0 support

  • Power: Supports 3.3V to 5V input, battery-friendly

  • Size: 21 x 17.5 mm, ultra-compact for wearables

  • Peripheral I/O: 6 analog/digital I/O pins, I2C, UART, SPI support

This microcontroller was chosen for its low power consumption, BLE capability, and small footprint—ideal for integrating into the wearable ankle device.

Implementation:

  • The board was programmed using the Arduino IDE with the Seeed nRF52 board package installed.

  • A custom BLE service was created with a writable characteristic named stateCharacteristic.

  • Real-time system state was formatted into a composite message and transmitted once per second via BLE.

  • Data includes:

    • Current system state (MOVING or STAT)

    • Alarm status (ALARM or NORMAL)

    • Average ADC value multiplied by 100 for precision (integer format)

  • BLE data could be monitored using the nRF Connect mobile app.

Code Explanation:



  • millis()： Get the system execution time.

  • stateCharacteristic.writeValue()： Write string value to the BLE stack and send to mobile application.

  • BLE.poll()： Deal with communication in the BLE stack.

Results:

  • BLE advertising and connection with a smartphone (via nRF Connect) worked reliably.

  • The composite string was correctly formatted and transmitted once per second.

  • Real-time values could be observed in the app, confirming the microcontroller’s BLE communication capability and data packaging logic.

Comments

Post a Comment

Popular posts from this blog

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

Week14

Image
Week 14 Progress: Data Analysis and Final Testing Improvements Objective: The primary goal of Week 14 was to complete a comprehensive round of performance tests on the ankle monitoring system and to conduct a thorough analysis of the collected sensor data. Emphasis was placed on evaluating the system’s ability to detect swelling through trend analysis, as well as verifying the accuracy of filtering techniques in eliminating short-term noise. Alongside empirical testing, the effectiveness of the core embedded logic written in C++ was further validated. Implementation: A key element of the test was real-time monitoring of ADC (Analog-to-Digital Converter) output values from the flex sensor under simulated swelling conditions. The image below shows the plotted  sampled ADC values  and their corresponding  filtered values  (exponentially smoothed): From this graph, we can observe two trends: The  blue line  shows raw sampled data, which fluctuates significantly...
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