Source-linked AI summary
A Rapid Pipeline for Training and Deploying ML Models on WeBe Band
Ehsan Kourkchi, Asmita Asmita, Houman Homayoun, Mahdi Eslamimehr
TL;DR
Wearable-health teams can lack the embedded expertise needed to move ML models from development into realistic device testing. This paper integrates model development with automated firmware preparation, OTA deployment, and on-device profiling; its reported profiling shows a resource-efficiency trade-off between classical models and neural networks.
Problem
Wearable-health teams may lack embedded expertise to integrate and deploy ML models, leaving promising models in offline evaluation rather than realistic device tests.
Source: §I · p. 1Method
Results
Classical models such as Random Forest and Pattern Matching Engine achieve low latency and small memory footprints, while neural networks use more Flash and SRAM.
Source: §V · p. 6Takeaways & Limitations
The workflow supports systematic exploration of model trade-offs directly on target hardware rather than relying solely on offline benchmarks.
Source: §V · p. 6The gesture dataset and limited user pool demonstrate deployability and real-time performance, not clinical accuracy; broader datasets and cross-platform evaluation remain future work.
Source: §V · p. 6
Abstract
from arXiv · showhide
Developing optimized machine-learning algorithms for edge devices with limited computational and memory resources is challenging, time-consuming, and highly dependent on device-specific constraints. In this work, we streamline an edge ML workflow to enable rapid development, optimization, and deployment of machine-learning (ML) models directly on the WeBe Band, a wrist-worn wearable device designed for multimodal physiological data monitoring. The proposed system automatically generates hardware-efficient ML models that can be easily integrated into the WeBe core firmware, supporting AutoML, hardware-aware quantization, and performance profiling to build models that meet desired latency targets while remaining compatible with device memory and power limitations. The proposed framework tightly integrates the open-source Piccolo AI ecosystem with an automated pipeline that generates deployable firmware artifacts, performs hardware-aware model compilation, and supports over-the-air (OTA) deployment. The system supports multiple lightweight model classes, including classical machine-learning algorithms and neural networks, and provides built-in on-device profiling tools to evaluate inference latency and memory footprint under realistic execution conditions. Experimental results demonstrate clear trade-offs between model complexity and deployability on a microcontroller, showing that classical models offer strong real-time performance while lightweight neural networks require careful resource management. Rather than proposing new learning architectures, the current work mainly focuses on system-level automation, deployability, and enabling researchers and developers to rapidly iterate on models and evaluate them directly on target hardware. Although demonstrated on the WeBe Band platform, the workflow is designed to be extensible to other ML-powered edge devices.
I. Introduction
The gap between ML development and embedded deployment leaves many wearable-health models confined to offline evaluation. The proposed workflow automates integration and deployment while profiling models directly on the WeBe Band.
I. Introduction
- Wearable-health teams may lack embedded expertise, leaving promising ML models in offline evaluation instead of realistic sensing and execution tests.The paper identifies integration, compilation, and target-device deployment as steps a bridging workflow must streamline.Source: §I · p. 1
- The work emphasizes system-level automation rather than new learning architectures, with a workflow intended to extend beyond WeBe Band to other Cortex-M devices.The framework is presented as a basis for rapid model iteration and hardware-aware selection in embedded applications.Source: §I · p. 2
- The end-to-end workflow automates model integration, firmware compilation, and OTA deployment on the wearable platform.The backend generates firmware artifacts from uploaded data and model artifacts, which can be flashed or delivered OTA to WeBe Band.Source: §I · pp. 1–2
- On-device profiling measures latency and memory footprint across model classes, exposing trade-offs between complexity and real-time feasibility.The framework supports classical machine-learning algorithms and neural networks under microcontroller constraints.Source: §I · p. 2
A. Related Work
Prior TinyML work has emphasized inference optimization and domain-specific applications, while model integration into production-ready firmware often remains manual and device-specific. This leaves a deployment-workflow gap for research teams.
A. Related Work
- Existing edge-AI frameworks and toolchains primarily optimize inference performance and model compression rather than simplifying end-to-end research deployment.Prior work discusses microcontroller memory and computation constraints, with solutions centered on benchmarking and runtime optimization [1],.Source: A. Related Work · p. 2
- TinyML applications span industrial IoT, environmental monitoring, and wearable health, but often assume embedded expertise and manual firmware adaptation.Wearable-health analytics work showcases clinical ML applications but lacks a generalized workflow abstracting device-specific configurations.Source: A. Related Work · p. 2
- Trained-model integration remains manual and device-specific, requiring codebase changes, memory-layout adjustments, and hardware-dependent deployment steps.These requirements form a barrier for interdisciplinary teams working in healthcare and wearable sensing.Source: A. Related Work · p. 2
B. WeBe Band
WeBe Band provides multimodal sensing and embedded inference for wearable research. The workflow uses Piccolo AI for model development and prepares its exported knowledge packs for deployment, with an architecture intended to extend to other Cortex-M platforms.
B. WeBe Band
- WeBe Band combines physiological and activity sensors with software interfaces for collecting, managing, and processing data streams.Its sensors include four PPG channels, a tri-axial accelerometer, skin temperature, and EDA; the platform also offers a mobile app, web portal, Python SDK, and mobile API.Source: B. WeBe Band · p. 2
- The device supports on-device preprocessing, feature extraction, and inference on an ARM Cortex-M4F nRF52840 microcontroller.It has 1 MB of on-chip RAM and configurable sampling rates including 25, 50, 64, 86, and 100 Hz.Source: B. WeBe Band · p. 3
C. Piccolo AI
- Piccolo AI supports feature exploration and training across classical models and neural networks, exporting deployment artifacts as a knowledge pack ZIP archive.The workflow automates embedded-header generation and compilation, then prepares a deployable package for Bluetooth OTA flashing to WeBe Band.Source: C. Piccolo AI · p. 3
- Although implemented for WeBe Band, the workflow architecture can be adapted to other Cortex-M platforms such as STM32, ESP32, and Nordic nRF53-series devices.The paper describes WeBe Band as a reference implementation rather than an inherently device-specific design.Source: C. Piccolo AI · p. 3
III. Design and Implementation
The system organizes work into six stages from data acquisition through deployment and analysis. For its model-complexity evaluation, the study collected six gesture classes from two users and used a standardized preprocessing and labeling workflow.
III. Design and Implementation
- The system's six-stage workflow automates the path from data acquisition to model deployment and analysis.Data were collected at 25 Hz using WeBe Band and its companion mobile and web applications.Source: §III · p. 3, 1) Stage 1: Data Collection · p. 3
1) Stage 1: Data Collection:
- The evaluation focuses on motion detection, using six drawn-letter gestures performed consistently by two users rather than prioritizing dataset size or absolute model precision.The study emphasizes model building, deployment, and profiling on WeBe Band.Source: 1) Stage 1: Data Collection · p. 3
- Preprocessing handles missing values, synchronizes timestamps, normalizes sensor measurements, and formats data for WeBe firmware.Gestures were segmented into windows of about 100 or more samples, approximately four seconds, and labeled manually or semi-automatically in Piccolo AI.Source: 2) Stage 2: Data Pre-processing · p. 3
2) Stage 2: Data Pre-processing:
The workflow prepares data and trains models in Piccolo AI before exporting them for embedded deployment. It evaluates PME, Random Forest, and neural networks with distinct model configurations and reports their resource profiles.
2) Stage 2: Data Pre-processing:
- Piccolo AI imports preprocessed CSV files, supports automatic or manual feature selection and tuning, then exports trained models as Cortex-M-compatible Knowledge Packs.The Knowledge Pack contains the model artifacts and inference pipeline in a deployment-ready ZIP package.Source: 3) Stage 3: Model Generation · p. 3
3) Stage 3: Model Generation:
- PME compares incoming feature vectors with stored prototypes, with each prototype’s Area of Influence defining its similarity boundary.The experiments constrain the AIF range to 25–400 and dynamically allocate up to 128 neurons.Source: 3) Stage 3: Model Generation · pp. 3–4
- Table I reports each model’s architecture, approximate trainable parameters, maximum on-device inference latency, Flash storage, and runtime SRAM.The table covers PME, Random Forest, and neural-network configurations.Source: 3) Stage 3: Model Generation · p. 4, Table I · p. 4
- The Random Forest uses 40 decision trees with maximum depth 7, selected to balance classification performance and computational efficiency under microcontroller constraints.Its tree predictions are combined by majority voting.Source: 3) Stage 3: Model Generation · p. 4
- The fully connected neural networks use Adam, a 0.0015 learning rate, batch size 32, dropout 0.1, and batch normalization; deployment maps predictions below 60% confidence to Unknown.The study focuses on deployability, latency, and memory rather than classification accuracy or generalization.Source: 3) Stage 3: Model Generation · p. 4
4) Stage 4: Model Integration and Firmware Compilation:
The backend converts a model Knowledge Pack into firmware artifacts and an update package. It supports deployment to the WeBe Band through Bluetooth without manual firmware flashing.
4) Stage 4: Model Integration and Firmware Compilation:
- The backend parses the model Knowledge Pack, generates header files, embeds them in the firmware source tree, and compiles a deployable binary.It can deliver pre-compiled firmware and/or an OTA update package without requiring users to interact with the embedded toolchain.Source: 4) Stage 4: Model Integration and… · p. 4
- The process abstracts firmware modification and compilation by delivering pre-compiled firmware and/or an OTA update package.Users do not need to interact with the embedded toolchain.Source: 4) Stage 4: Model Integration and… · p. 4
- The OTA package can be flashed to the WeBe device through Bluetooth data packets using one command in the pipeline interface.This avoids physical device access and manual firmware flashing.Source: 5) Stage 5: Firmware Flashing · p. 4
5) Stage 5: Firmware Flashing:
After deployment, users can profile models on live sensor data and iterate on model and feature settings. The workflow is designed for portability beyond the WeBe Band, though broader compatibility remains future work.
5) Stage 5: Firmware Flashing:
- Users can run profiling scripts on live sensor data, compare model behavior, and iteratively tune hyperparameters and feature sets for execution on the WeBe device.The scripts may be custom or provided by the framework.Source: 6) Stage 6: On-Device Evaluation and… · p. 4
A. Hardware Portability Considerations
- The Knowledge Pack is parsed independently of hardware so headers and inference pipelines can be generated for different firmware targets.The OTA packaging process abstracts device-specific flashing and is adaptable to embedded hardware with comparable memory and compute characteristics.Source: A. Hardware Portability Considerations · p. 4
- Fig. 2 shows UMAP visualization of 66 extracted features and training and validation accuracy across epochs for the 64–64–32–16–8 neural network.The caption says the feature clusters separate gesture labels and attributes the slight curve gap to batch normalization and dropout regularization.Source: Figure 2 · p. 5
IV. Result
On-device profiling shows that maximum inference latency varies with model complexity: lightweight classical models are faster than deeper neural networks. The comparison uses identical features and window configurations on the WeBe Band.
A. Model Latency Analysis
- All models use identical feature sets and window configurations, and latency is measured on-device to compare architectures under the same hardware constraints.The profiling avoids external instrumentation to minimize measurement bias.Source: A. Model Latency Analysis · p. 5
- Firmware profiling hooks sample the 32-bit DWT cycle counter before and after each model call and convert cycle differences to microseconds using the 64 MHz system clock.The method is designed to measure execution latency with minimal overhead.Source: A. Model Latency Analysis · p. 5
- RF and PME achieve maximum inference latencies below 9 ms, while deeper neural networks exhibit higher latency.The reported results use models trained with the same 66 statistical features.Source: A. Model Latency Analysis · p. 5
B. Memory Footprint and System-Level Performance Comparison
On-device profiling shows a trade-off between model complexity and resource use: classical models balance low latency with modest memory, while neural networks require more resources. Sliding-window inference remains predictable and does not interrupt data collection.
B. Memory Footprint and System-Level Performance Comparison
- Classical models such as RF and PME provide the best overall balance of low latency and modest memory use, while neural networks require more resources.TensorFlow-based networks use approximately 15–24 KB of Flash for weights and more SRAM for intermediate activation buffers; their greater capacity can suit tasks needing higher accuracy or more complex decision boundaries when resources allow.Source: B. Memory Footprint and System-Level… · p. 5
- Although the current implementation uses TFLM for neural-network quantization and inference, the modular pipeline can accommodate alternatives such as CMSIS-NN with minimal architectural modification.Source: B. Memory Footprint and System-Level… · p. 5
- Unlike prior studies focused on offline benchmarks or simulation, this analysis profiles models directly on-device under realistic wearable constraints.The authors distinguish the workflow through automated firmware deployment and real-time profiling for rapid iteration and hardware-aware model selection.Source: B. Memory Footprint and System-Level… · p. 5
- 100-sample inference windows advance by 20 samples at 25 Hz, triggering inference about every 0.8 seconds over the latest 4 seconds without missed samples.Latency varies periodically with window updates; RF and PME are steadier, while the NN has higher latency and more pronounced peaks.Source: B. Memory Footprint and System-Level… · p. 6, Figure 3 · p. 6
V. Summary and Conclusion
The WeBe Band framework automates firmware integration, deployment, and on-device evaluation, supporting rapid model iteration without requiring deep firmware expertise. On-device results show a resource-efficiency trade-off between classical models and neural networks, while the study’s gesture data and limited user pool demonstrate deployability rather than clinical accuracy.
V. Summary and Conclusion
- The unified WeBe Band framework automates firmware integration and on-device evaluation, with hardware-aware compilation and OTA deployment to support rapid model iteration.The workflow is designed to reduce development time and technical overhead without requiring deep embedded-firmware expertise.Source: §V · p. 6
- Classical models offer low latency and small memory footprints on resource-constrained platforms, whereas neural networks use more Flash and SRAM for parameters and intermediate buffers.The results frame model complexity against real-time feasibility and resource efficiency on MCUs.Source: §V · p. 6
- The study prioritizes workflow automation and system-level evaluation over dataset scale or model generalization; its gesture data and limited user pool demonstrate deployability rather than clinical accuracy.Future work is proposed to expand datasets and sensing modalities and investigate cross-platform deployment beyond the current prototype.Source: §V · p. 6
- The authors suggest that rapid experimentation on wearable hardware may facilitate collaboration across clinicians, data scientists, and embedded engineers, and help translate TinyML research into healthcare applications.Source: §V · p. 6