Embedded Systems · Wearable Technology
—
2026
Ultimatrix Step Tracker
My Role
Embedded Systems Developer
Project Type
University group project · Embedded mechatronics studios
University Subject
Embedded Mechatronics Studio
Tools & Technologies
RP2040 Zero · C/C++ · ADXL335 · Altium Designer · SolidWorks
Team Context
Multidisciplinary student team developing a complete wearable activity tracker.
Overview
Ultimatrix is a wrist-worn activity tracker integrating an RP2040 Zero microcontroller, an ADXL335 three-axis analog accelerometer, a custom PCB and a 1.28-inch circular touchscreen. The system samples physical movement through analog sensor inputs, processes the signals in embedded firmware and presents step count, pace, calories and time through an interactive wearable interface. The project combined sensor processing, electronics, firmware, interface design and physical product integration.
My Contribution
What I owned
My primary responsibility was developing the embedded step-tracking system and integrating it with the wearable interface. I created the motion-processing routine, implemented orientation-robust acceleration-magnitude analysis and configured continuous background sensor polling so steps could be tracked while users navigated other screens. I also integrated the step counter with the touchscreen interface, pace-indicator LEDs, reset behaviour, GPIO allocation, calibration procedures and accelerometer self-testing.
The Challenge
The system needed to distinguish genuine walking motion from sensor noise, tapping and changes in wrist orientation while operating on a resource-constrained microcontroller. The ADXL335 produced analog signals that required calibration, filtering and carefully selected thresholds. At the same time, the firmware needed to maintain responsive touchscreen navigation, update the display and track movement continuously without blocking other system functions.
Constraints
Key constraints included analog sensor noise, false step triggers, limited GPIO availability, compact wearable packaging, display and touch-controller integration, power requirements and continuous motion processing.
System & Design Development
How the system took shape
System Architecture
The system begins with the ADXL335 accelerometer, which measures acceleration on the X, Y and Z axes. These analog outputs pass through the custom PCB and signal-conditioning circuitry before being sampled by the RP2040 Zero.
Firmware converts the calibrated sensor readings into acceleration values, applies axis correction and combines all three axes into a resultant vector magnitude. A step-detection routine compares short-term movement against a moving baseline and generates a step event when the required threshold, release and timing conditions are satisfied.
Step events update the total step count and are shared with the pace-identification routine. The resulting activity information is used by the touchscreen interface, calorie and distance calculations and pace LEDs.
The main firmware loop also manages touch input, screen navigation, display updates, calibration, self-test and general system I/O.
Design Process
Development progressed from system requirements and subsystem allocation into electronics, firmware, user-interface and mechanical integration.
For the step-tracking subsystem, I first established the calibrated accelerometer-reading workflow and then developed a magnitude-based detector so the algorithm would not depend on a single axis. Testing showed that orientation changes, sensor noise and repeated peaks could cause false counts, so the routine was progressively refined using axis correction, a moving baseline, trigger and release thresholds, cooldown timing and maximum-impact rejection.
The step detector was then integrated into the main firmware loop so it could operate continuously in the background. Step events were connected to the touchscreen interface, pace-identification routine, calorie and distance calculations and reset behaviour.
Late-stage integration required further debugging of the display, GPIO mapping and PCB hardware before the system could be demonstrated as a complete wearable prototype.
Key engineering decisions
Orientation-robust vector magnitude
A single-axis detector would behave differently as the user rotated their wrist. I instead combined calibrated X, Y and Z acceleration into vector magnitude after applying axis correction gains.
This increased robustness to changing device orientation and reduced the influence of the unusually strong measured Z-axis response.
Moving baseline with threshold, release and cooldown logic
Gravity, slow orientation changes and repeated acceleration peaks made a simple fixed threshold unreliable. The detector therefore compares movement against a slowly changing local baseline.
A trigger threshold identifies candidate steps, a release threshold re-arms the detector and a 380 ms cooldown prevents multiple peaks from being counted as separate steps. A maximum-movement limit rejects large impacts such as table knocks.
Together, these mechanisms reduced false triggering while preserving responsiveness during normal walking.
Continuous background polling
Step tracking needed to continue even when the user was viewing the clock, settings or calorie screens. Instead of tying step detection to the Step Tracker interface, the sensor routine was called continuously from the main firmware loop.
Each valid step generates an event flag that can also be consumed by the pace-identification routine.
This separated sensing from presentation and allowed the wearable to behave as one integrated system rather than a collection of independent screens.
Testing & iteration
The step-tracking software was validated through functional and scenario-based testing on the physical prototype.
Tests covered stationary behaviour, normal walking, continuous background tracking, impact rejection, reset functionality, LCD updates, pace handoff, calorie and distance estimation and operation across different orientations.
Testing directly influenced the algorithm. Orientation sensitivity led to vector-magnitude processing and axis correction; repeated peaks led to cooldown and release logic; impact spikes led to a maximum-movement limit; and the need for continuous activity monitoring led to background polling in the main loop.
Hardware integration also required iterative debugging. The display software required modification for RP2040 compatibility, the PCB underwent revision and wiring rework, and late-stage testing identified a Z-axis fault that could not be fully diagnosed before the final demonstration.
Final outcome
The project resulted in a functioning wrist-worn embedded mechatronic prototype integrating motion sensing, custom electronics, embedded software, touchscreen interaction and mechanical packaging.
The completed system demonstrated real-time step tracking, pace classification, touchscreen navigation, clock functionality, calorie and distance estimation, accelerometer calibration and self-test, LED feedback and additional interactive software features.
The final demonstration confirmed that the different hardware and software subsystems could operate together as one integrated wearable system.
Results & Measurements
The embedded step-tracking routine passed all defined functional tests covering stationary operation, walking detection, background operation, reset behaviour, impact rejection, display updates, pace handoff, calorie and distance calculations and changing device orientation.
Stationary movement remained below the 0.08 g trigger threshold, normal walking produced step-count increments and background polling continued while other screens were active.
PCB testing also confirmed correct operation of the main power rails, indicator LEDs, touchscreen and output LEDs. The X- and Y-axis low-pass filters were successfully validated across their frequency response, while the Z-axis path was flagged for further investigation.
Limitations
The final prototype remained a proof-of-concept rather than a production-ready wearable.
A late-stage Z-axis fault could not be fully diagnosed before the final demonstration, and the corresponding analog-filter path required further review. Some hardware integration and validation also occurred late in the project, increasing the risk of unresolved issues.
The PCB and enclosure could be further reduced in size for a more practical wearable form factor, and earlier staged integration would allow more extensive long-duration testing, step-count accuracy benchmarking and power-consumption evaluation.
A future version would also benefit from more consistent version control and earlier end-to-end testing of hardware and software together.
Reflection
Ultimatrix showed me that embedded-product development is fundamentally an integration and iteration problem. A sensor routine can work independently but still behave differently once it is combined with display updates, shared GPIO, PCB hardware, mechanical packaging and other software functions.
The project strengthened my confidence in embedded programming, sensor processing, PCB design, user-interface development, system integration and technical testing. Debugging display compatibility, step-detection behaviour, PCB revisions and sensor faults reinforced the importance of systematic troubleshooting rather than assuming the first suspected cause is correct.
It also changed the way I think about engineering documentation. Recording limitations and unresolved faults is just as important as demonstrating successful functionality.
Most importantly, the project strengthened my interest in embedded systems, robotics, automation and automotive engineering and gave me experience taking an idea from requirements through implementation, testing and final physical integration.
Project Links