Problem
The device had to coach a user without depending on a constantly connected phone. It needed to detect motion events, decide whether a strike happened inside the intended response window, calculate a repeatable motion-derived score, give immediate feedback, retain session records, and later expose useful data and firmware-management functions through a companion tool.
The public Reflex Strike Technology page is used here as a proof link for the product identity. The detailed engineering description is based on the reviewed project workspace, not scraped Facebook claims.
System context
Accelerometer samples
|
v
Short history buffer and strike candidate detection
|
v
Training state machine and scoring window
|
+-- OLED / LED / audio feedback
+-- athlete and session records in flash
+-- BLE data and firmware-management protocol
|
v
Android management / update toolFirmware and edge-case challenge
This was not an RTOS design; responsiveness came from bounded event-driven firmware, explicit states, compact buffers, time marks, and BLE SoftDevice behavior. The embedded logic had to separate real training events from noise, keep UI feedback immediate, and preserve records across sleep, low battery, resets, and update transitions.
Important edge cases included unprompted strikes, strikes outside the response window, sensor noise, flash-log wraparound, invalid stored metadata, settings changes during use, sleep/low-power transitions, BLE disconnects, and ensuring the normal runtime and firmware-update path did not corrupt each other's state.
Implementation approach
Evaluate a motion window
Use recent acceleration history and post-impact analysis rather than making a decision from a single raw sample.
Keep coaching local
Provide immediate OLED, LED, and audio feedback on the device so training remains useful without a phone in the loop.
Persist compact records safely
Store athlete/session information and strike records in flash with circular-log handling and safe defaults for invalid metadata.
Separate runtime and service paths
Keep normal training behavior, BLE management, Android data access, and firmware update workflow distinct enough to reduce field-service risk.
Outcome
The result was a connected training product with embedded motion analysis, offline device behavior, persistent records, Android management, and firmware-service capability. It demonstrates how a small embedded product becomes convincing when sensor logic, user feedback, storage, BLE, and update behavior are engineered together.