The Engineering Challenge

Fitness wristwatches operate in an unpredictable environment, which is far different from the controlled laboratory. A user can walk, speak, type, lift, drive or exercise while the wrist is constantly moving.

Motion data is usually noisy and orientation is constantly changing, moreover, the design proposals of a wrist watch that look great are often turning to slow motion and/or intensive use of the battery if the firmware is inadequately designed.

The Apollo4 Blue-based design needed to balance four competing priorities:

• Accurate and useful activity information – Users expect the watch to avoid obvious false steps while still recognising real movement.
• Fast and attractive display interaction – The watch should wake quickly, animate smoothly where appropriate and keep text readable in different usage conditions.
• Reliable mobile synchronization – Activity data should sync predictably without forcing the user to reconnect or reopen the app repeatedly.
• Long practical battery life – The device must spend most of its time in low-power states while remaining responsive to motion, touch or button events.

Our approach was to define these as system-level requirements from the beginning, rather than treating the sensor, UI and BLE implementation as separate tasks.

Wearable Hardware and Apollo4 Blue Firmware Architecturev

The wearable firmware was organised in independent but coordinated services: sensor acquisition, activity processing, display/UI, BLE communication, persistent storage, battery monitoring and device power control.

The IMU has a low-power serial interface and is configured to work with interrupts. The device does not keep polling under all conditions, in contrast to the need to wake up the processor when some activity is detected.

This design helps minimise the amount of unnecessary work done by the processor, which is important for gears that operate for days without being recharged.

The Apollo4 Blue firmware used a state-based power model. In an idle condition, the device retained only the functions required for timekeeping, movement wake-up, button or touch wake-up and BLE scheduling.

When the user raised their wrist or opened a screen, the firmware activated the display pipeline and required peripherals. After a timeout, it returned the system to an appropriate low-power state.

In the case of a commercial product, this architecture is more useful than giving a single value of the battery lifespan.

In reality, the battery performance depends on display brightness, on-screen time, BLE usage, sampling rate, watch face complexity, battery capability, and usage.

Activity Tracking and Motion-Sensing Logic

The activity-monitoring feature converted initial data received from the accelerometer and gyroscope into real-time information for the user. Before moving to conversion, the software eliminated unnecessary elements; it removed audio noise and gathered information about movements of relevance to walking and exercising.

A typical activity pipeline included:

• IMU initialization and calibration checks
• Configurable sampling and interrupt thresholds
• Motion filtering and gravity compensation
• Step-candidate detection
• Cadence and activity-window analysis
• False-positive reduction for vehicle movement or random hand motion
• Daily counter rollover and local record storage
• BLE-ready activity summaries for the companion app

Step detection was not implemented as a simplistic “one peak equals one step” rule. We used timing windows, amplitude thresholds, direction changes and cadence checks to help distinguish repetitive walking motion from isolated wrist movement. Thresholds were exposed as configuration values so that the algorithm could be tuned using field data from real usage scenarios.

The gadget preserved periodic recaps and carefully chosen time-stamped activity logs on the device. As a result, a user could still track their movements even when the device's phone was unavailable.

During the next secure Bluetooth Low Energy connection, the companion app asked the device to provide only the records which were not yet synchronized. The app confirmed that the process was completed successfully and allowed the device to denote the records as transferred. The described processes help to avoid any cases of mislaid information.

Custom Display UI and Watch-Face Development

The visual aspect was significant for the quality perception of this watch. Instead of coding each individual screen, we made a reusable user interface framework. The latter took care of the screen transitions, positioning widgets, fonts, icons, and themes.

Core screens included:

• Customisable digital and analogue watch faces
• Daily step count, distance estimate and active minutes
• Activity progress rings or bar indicators
• Workout summary screens
• Battery and Bluetooth connection status
• Notification preview and alert indicators
• Settings for brightness, units, screen timeout and vibration behaviour

Apollo4 Blue's graphics ability results in a highly effective watch user interface due to its support for layer composition and fast functions. However, a good wearable UI cannot simply be based on updating every pixel on each clock.

Instead, we took advantage of partial updates wherever we could. Also, we cached static resources and updated only an area that changed, e.g. numbers of time, step count or progress indicator.

The UI was also designed for wrist-level reading. Important metrics used strong visual hierarchy, large numerals and clear status colours.

We avoided putting too much information on a small screen. Product teams could choose brand colours, iconography, typography and watch-face styles without changing the underlying activity or BLE firmware.

BLE Mobile Synchronization and Companion-App Integration

The watch communicated with a companion mobile application using Bluetooth Low Energy. The BLE design defined a clear GATT service structure for device information, live activity status, historical activity records, watch settings and firmware version information.

A connection flow typically included device discovery, pairing or bonded-device recognition, secure data exchange, time synchronization and incremental activity upload.

To improve reliability, activity transfer was designed as a resumable process rather than a single large payload. The mobile application could request records in pages, confirm successful receipt and retry safely after interruption.

The companion application could provide:

• Device onboarding and pairing
• Current activity dashboard
• Daily, weekly and monthly history
• Watch-face and settings configuration
• Firmware version visibility
• Notification preferences
• Battery and connection status
• Optional cloud account synchronization

Privacy should be considered early. Activity data is personal data in many contexts, even when a watch is not marketed as a medical device. Our development process defines what data remains on the watch, what is transferred to the phone, what is sent to cloud services and how a user can remove their device or account data.

Testing, Validation and Product Readiness

The validation process for wearable devices entails much more than simply determining if a screen works and if a Bluetooth connection has been established. Our testing takes into consideration issues like motion conditions, device reconnection, low battery life and repeated charging cycles, as well as potential dry runs and continuation periods.

For this project type, our validation plan includes:

• Sensor calibration and step-count comparison against defined test walks
• False-step testing during desk work, driving and casual wrist movement
• Display stress testing for brightness, refresh and long-running screens
• BLE range, reconnection and interrupted-sync testing
• Local storage rollover and corrupted-record recovery checks
• Battery current measurement in sleep, active UI and synchronization modes
• Firmware reset, watchdog and error-recovery validation
• Production test-point and device-diagnostics planning

We document test conditions and limitations clearly. Consumer fitness metrics can help users understand trends, but they should not be represented as medical measurements unless the product has been developed, verified and regulated for that intended use.