VitaRF is my entry for element14's Smart Home & Healthcare Challenge. I try to come up with an offbeat idea for these design challenges, but by the time I applied for the sponsored kit I was exhausted and just wrote the most obvious idea looking at what was in the kit - a wearable that reads body temperature and heart-rate/SpO₂ using Analog Devices sensors and gets that data into Home Assistant over BLE. I proposed the plan in two stages: get it working on the sensor boards + nRF52832 DK first, then shrink it onto a custom PCB second. That was before I got gifted an nRF54L15 kit as part of the How To Build A Smart Home Device With Matter webinar. Now that I know I'll soon have one in hand, I'm adding a third phase as a stretch goal: send this data over Matter. Details below.
Why nRF52832
Wearable means requiring good battery life along with wireless connectivity, so it was almost a reflex to reach for the nRF52 family. I've already got 30+ nRF52832 chips lying around, and a while back I got the SoC working with a chip antenna (first chip antenna PCB design), so I'm not dependent on expensive antenna modules for this either.
The three-phase plan
Phase 1 - An nRF52832 DK reads both sensors over their native interfaces and forwards the data via BLE to a Radxa Q6A running Home Assistant. No custom hardware yet - just prove the sensor-to-HA path works end to end.
Phase 2 - Replace the DK with a custom nRF52832 PCB. One board design, capable of talking to either sensor, but only 2 PCBs get assembled and each one only gets wired for one sensor at a time. This, along with a 3D-printed casing and a Velcro / TPU band, becomes the wearable - something you can strap to an arm.
Phase 3 - An nRF54L15 DK becomes the Matter sensor device, an nRF52840 DK acts as an 802.15.4 Radio Co-Processor, and together they give the Radxa Q6A/Home Assistant Thread Border Router setup something to talk to. I'm mainly doing this to actually learn how a Matter implementation works under the hood.
The reasoning for staging it this way is simple: ship something that works early, shrink it down once it does, and only then spend time on the architecture that's more future-proof but less proven for this use case. If Phase 3 turns out to be a dead end in the time I have, Phases 1 and 2 already stand on their own as a complete submission.
Research Phase - Kits on the way
I went through the datasheets for both sensors and their evaluation boards, and worked out how they actually operate - especially the flex cable pinout on the MAX30208.
Power architecture decided for the Phase 2 custom PCB. I landed on Nordic's own nPM1300 PMIC because I wanted to try this all-in-one approach. It bundles charger, fuel gauge, two buck converters, an RGB LED driver, and a ship-mode power button into one part, with first-party nRF Connect SDK support - since the whole board is nRF-centric anyway, one part with matching firmware support beat three parts with more familiar sourcing. Details in the upcoming post.
Status LED designed around what the hardware actually supports, not what I assumed it supported. I originally figured LED Driver meant PWM dimming and smooth color mixing. The nPM1300's LEDDRV outputs are on/off only, no duty-cycle field - that killed the fade idea, so the design is now a fixed 8-color palette (green/yellow/red for vitals, blue for charging, magenta for sensor fault) driven straight off the PMIC, zero extra GPIOs or resistors needed.
Final notes
Nothing's actually been powered on yet - this first post is all phase-planning, datasheet reading, and locking in the power/LED architecture. I still need to figure out if I can use LabVIEW well enough. And, Worth a mention: ADI has their own reference design for this exact kind of thing, MAXREFDES104 - a wrist-worn SpO₂/ECG/HR/temp platform that even uses the same MAX30208 from the Kit. Keeping it bookmarked as something to learn from as I go.
