How to Build a Smartwatch: Picking a Chip

Original Article ↗ Hacker News Discussion ↗

Chip Architecture Choices (Single vs Dual MCU)

  • Some expected a 2‑chip design (application + BLE radio), noting that high‑power MCUs often lack RF.
  • Others argue more chips greatly increase PCB, BOM, passives, communication, firmware‑update, and debug complexity, which can outweigh battery gains.
  • Counterpoint: from the CPU’s view, BLE firmware is often just a blob either way; difference is bigger in layout, supply chain, and shared peripherals (e.g., displays) than in software.

ESP32 vs nRF / SiFli for Watches

  • ESP32 praised for integrated Wi‑Fi+BLE, rapid iteration, community support, and suitability for hobbyist smartwatch platforms (e.g., MicroPython, Linux-on-ESP32-S3).
  • Criticism: original ESP32 radio seen as “insanely” power‑hungry; even newer S3/C6 are “acceptable” but not optimal if runtime is the priority.
  • Examples shared where ESP32 watches achieve only hours to <1 day of continuous use, versus days for nRF‑based watches (e.g., PineTime getting roughly a week or more).
  • Some see Wi‑Fi as a killer feature enabling standalone watches; others prefer ultra‑efficient BLE‑only MCUs and phone tethering.

Battery Life vs Features (“How Smart Is Smart?”)

  • Strong split: some want NFC payments, GPS, LTE, rich notifications; are fine charging every 1–2 days and see multi‑week battery as unnecessary trade‑off.
  • Others prioritize long life (week+), simple notifications, alarms, basic heart‑rate, and sunlight‑readable displays; they view phone‑like watches as overkill.
  • Acknowledgement that everything is a trade‑off: Garmin‑style devices show multi‑week life with many features is possible but with larger, pricier hardware.

Open Source SDK and BLE Blobs

  • Enthusiasm that a low‑power smartwatch chip has an “open source” SDK, but disappointment the BLE stack is still a binary blob.
  • Debate on whether “open source SDK” is misleading when major functionality is closed.
  • Several posters claim radio blobs are closed for IP and regulatory reasons (preventing out‑of‑spec transmission, subject to NDAs, patents, FCC obligations).
  • Others are skeptical of the regulatory argument and see it mainly as IP protection; argue source could be published while production devices use signed/locked firmware.

Pebble Compatibility and Software Ecosystem

  • Backwards compatibility with compiled ARM Pebble apps/watchfaces is seen as a major constraint, especially for a tiny team.
  • Some argue tiny apps could be ported or run via VMs/extension mechanisms; pushback notes many apps are closed source, making ISA‑level compatibility valuable.

User Desires and Alternative Devices

  • Noticeable niche wanting “dumb” watches or straps with just vibration notifications and very small form factors; several mention Casio‑style or Citizen BLE watches, Mi Bands, and hybrid analog devices.
  • Others mention Bangle.js (Espruino), PineTime, cheap Freqchip‑based watches, and subscription‑based trackers (e.g., Whoop) as interesting alternative ecosystems, with debate over subscriptions vs one‑time hardware sales.