Katkat
Back

Design a smartwatch sensor subsystem

AppleSoftware Engineer · Onsite
HardSoftware EngineerOnsiteSystem Design

Last updated

This question tests your ability to design a resource-constrained embedded sensing subsystem, focusing on the trade-offs between energy efficiency, data latency, and algorithmic reliability in a wearable device.

Problem Statement

You are tasked with designing the heart rate monitoring subsystem for a next-generation smartwatch. The device must balance high-fidelity health tracking with extreme power constraints and a very small physical footprint.

Requirements

  1. Functional: The system must provide continuous heart rate (BPM) monitoring while the user is stationary and burst-mode monitoring during high-intensity exercise.
  2. Constraints:
    • Power: The sensor subsystem must consume less than 5mW on average.
    • Latency: BPM updates should be displayed on the watch face within 2 seconds of a heart rate change.
    • Reliability: The design must maintain accuracy (>95%) despite motion artifacts (e.g., arm swinging during a run).

Your Task

Describe the design of this subsystem. Your response should address:

  • Hardware Architecture: Which sensors (e.g., PPG, accelerometer) would you integrate and why?
  • Signal Processing Pipeline: How will you handle raw sensor data? Explain the split between firmware-level pre-processing and application-processor (AP) computation.
  • Power Management: How do you implement a duty-cycling strategy to extend battery life without sacrificing critical data capture?
  • Edge Cases: How does the system handle signal dropouts caused by poor skin contact or ambient light leakage?

Hints

Hint 1

Consider how an accelerometer can be used as a reference signal to filter out motion noise from the PPG (optical) sensor data.

Hint 2

Think about the benefits of offloading simple peak detection to a low-power microcontroller (MCU) versus waking up the high-performance application processor.

Hint 3

Address how you would calibrate the sensor sensitivity dynamically based on the battery level or the user's current activity state.

Follow-up questions

  • How would you handle the data pipeline if you were required to also detect atrial fibrillation (AFib) which requires higher sampling rates than standard BPM?
  • If the heart rate data shows a sudden, physically impossible spike, how would you design the firmware logic to handle this outlier before it reaches the UI?
  • What specific metrics would you monitor in the factory to ensure that sensor-to-skin coupling consistency is maintained across units?