VitaRF - Part 6 - NRF52-Based Heart-Rate & Temperature Wearable PCB for Home Assistant

Recap: I am building a wireless vitals sensor node (heart rate, SpO₂, temperature) that reports over BLE into Home Assistant as a smart way to keep watch over our loved ones, built up in three phases — DK bring-up, a custom miniaturized nRF52832 PCB, then a Matter over Thread proof of concept.

Past Posts

1. VitaRF - Part 1 - The Plan
2. VitaRF - Part 2 - Interface MAX30102 on NRF52
3. VitaRF - Part 3 - Interfacing MAX30208 on NRF52
4. VitaRF - Part 4 - Sending Sensor Data to Home Assistant via BLE on NRF52
5. VitaRF - Part 5 - Matter over Thread on nRF54L15 with Home Assistant

In the last post I confessed that I had put off the PCB for "just one day" to play with the nRF54L15. Well, the day is over, and the responsible side of my brain finally won. This post is about the Phase 2 board - the schematic and the layout.

Why a custom board at all

The nRF52832 DK works great on a desk, but nobody is going to wear a DK on their wrist. The goal for Phase 2 is a small, low-cost, low-power node that can be strapped on and charged without fuss. To keep things simple, there will be only one board design. One will be populated with the MAX30208 (temperature) and another with the MAXREFDES117 (HR/SpO₂).

What's on it

Yes, the list grew. The original plan was "MCU + sensor + battery". Then the accelerometer came in for fall detection, and once there is fall detection you want to tell the wearer something happened - hence the haptic motor and the buzzer. And once you have readings you don't want to lose them when the phone or Home Assistant is out of range - hence the flash. Classic feature creep, but every part has a reason I can defend. And I did get an idea from embeddedguy , Thanks to Him btw , which I am working on integrating. Running into a lot of problems, but I am determined to make it work.

The schematic is split into three hierarchical sheets - Power, MCU and Sensors - and the top level just wires them together: the shared I2C bus, the interrupt lines, and the two switched sensor rails.

Why the MB-N2 and not a bare nRF52832

I have used bare-chip designs quite a lot in my projects recently, and one of the downsides of using a bare chip on a 1.6 mm 2-layer board is that the 50 Ω feed line has to be about 3 mm wide. Which means i lose a lot of PCB space. So I decided to use a module, and I happen to have a lot of RedBear MB-N2 modules lying around. The RedBear MB-N2 is a small nRF52832 module that already has the RF matching, the antenna and the 32 MHz crystal on board, it is pre-certified, and it has castellated pads I can hand-solder. The company is no longer operational, but niche projects like this are the perfect use case to reduce my inventory of obsolete products.

A few things I still had to add around it:

• 32.768 kHz crystal (Y1, with 12 pF load caps). The MB-N2 does not have a 32 kHz crystal on board, and it is needed for low-power operation.
• DC/DC inductors (L3 10 µH + L4 15 nH, C23 1 µF). The nRF52832 has an internal DC/DC regulator that is a lot more efficient than its LDO, but it needs these external parts. The values match RedBear's own Blend 2 reference.

Everything else on the MCU sheet is fairly standard. The I2C pull-ups (R2/R3, 4.7k) are the only pull-ups on the whole bus, R7 pulls up the MAXREFDES117's open-drain interrupt, and the piezo is driven differentially from two GPIOs (P0.30/P0.31) through 100 Ω resistors - one pin goes high while the other goes low, so the piezo sees twice the swing of a single GPIO, about 6.6 V peak-to-peak from a 3.3 V rail. Louder, for free (Nordic's DevZone calls this a full H-bridge without the external parts). The SWD and reset lines only go to test points.

The flash is a W25Q128 on SPI with 10k pull-ups on /CS, /WP and /HOLD, so it stays deselected and writable while the nRF is in reset:

Power: one chip instead of three

The power design kept changing till I actually started the schematic. I started with an all-ADI discrete stack to match the sponsor kit (MAX1555 charger + MAX17048 fuel gauge + MAX38640A buck), then swapped the charger to a TI BQ24074 because I have used it before. Then it hit me: the whole project is Nordic anyway, so why not Nordic's own nPM1300? It folds the charger, fuel gauge, two buck regulators, two load switches, an LED driver and a ship-mode power button into one QFN32. One part, one set of decoupling values to get right instead of three. Nordic's Video at https://www.youtube.com/watch?v=2vBOIpyCltY is quite helpful to understand what nPM1300 can do. 

Here is how it looks in the schematic. The input side first:

• J1 (pogo) brings in VBUS, with just a 1 µF cap (C14). CC1/CC2 are left unconnected, there is no USB here.
• J3 is the Li-Po, straight onto VBAT with a 2.2 µF cap. NTC is tied to GND, since I am using a protected Li-Po pouch cell without an NTC (firmware has to disable NTC monitoring, or the charger refuses to charge).
• VSET1 to GND means BUCK1 stays off at power-up. VSET2 through R1 (390k) means BUCK2 comes up at 3.3 V on its own, before any firmware has run. That is important: the nRF52832 is powered by this buck, so it can't be firmware that turns it on.
• SW1 (It stands for the Switched Node not the Switch, I made this mistake couple of times) on SHPHLD is the power button. It wakes the device from ship mode (the nPM1300's "practically off" state, for storage and shipping). Once running, a short press is just an interrupt for firmware to use, and a long press resets.
• The two load switch inputs (LSIN1/2) and VDDIO all come from the 3.3 V rail, so the nPM1300's I2C runs at the same level as everything else on the bus.

And the output side:

• VSYS is the nPM1300's internal system rail, with 3× 10 µF. It also feeds PVDD, the bucks' input.
• BUCK1: SW1 → L2 2.2 µH → AUX_3V3 (spare, off). BUCK2: SW2 → L1 2.2 µH → +3.3 V, the main rail.
• PVSS1/PVSS2 are the bucks' power grounds. They go to GND through net ties NT1/NT2, the way Nordic's reference layout does it. The net tie decides where the noisy switching ground joins the main ground - right next to the PMIC - instead of letting it wander through the pour under the MCU.
• **LSOUT1/2 are the switched sensor rails, each with its own 10 µF and a test point.
• LED0/1/2 sink the RGB LED's cathodes; the common anode is on VSYS.
• GPIO0 is the PMIC's interrupt line to the nRF (charger events, button press).

Things I learnt from the nPM1300 datasheet:

• The two bucks are not identical. BUCK1's VSET resistor table only goes up to 2.7 V at power-up, BUCK2's goes up to 3.3 V. So the 3.3 V rail had to be BUCK2 (R1 = 390 kΩ 1 % on VSET2). If I had only looked at the block diagram, I would have wired 3.3 V to BUCK1 and found out at bring-up that it can't get there. BUCK1 is a spare rail, off at power-up, and L2/C6 can be left unpopulated.
• Buck inductors: Murata DFE201610E-2R2M=P2, 2.2 µH, 140 mΩ, 1.7 A. The datasheet asks for DCR ≤ 400 mΩ and Isat > 350 mA, so there is plenty of margin. One catch: the KiCad stock footprint I used is for the DFE201610P. Same body size, but I need to check the land pattern against the DFE201610E drawing.
• VSYS is not regulated. The datasheet says it plainly: VBUS "supplies VSYS but does not regulate its voltage". On battery, VSYS ≈ VBAT. While charging, it sits close to VBUS, up to ~5.5 V. This is new to me, because the BQ24074 which I am used to does the opposite: when input power is present, its power-path output (OUT) is regulated to 4.4 V (datasheet, Device Comparison Table), so whatever hangs off it never sees more than that even with a 5 V charger plugged in. The nPM1300 just passes VBUS through. That matters for anything I hang off VSYS, and it is why the 10 µF caps on VSYS/VBUS are 16–25 V parts, to limit the DC-bias derating.
• The sensors get switched rails. LOADSW1 feeds +3V3_PPG (MAXREFDES117) and LOADSW2 feeds +3V3_TEMP (MAX30208), so firmware can cut a sensor's power completely between readings.
• The LED driver has no PWM. I assumed "LED driver" meant brightness control. It is strictly on/off at a fixed ~5 mA per channel. So no smooth colour fades, just 8 fixed colours and slow blinking.

I swapped the USB-C port for a 2-pin magnetic pogo connector. On a wearable that will be charged every day, a magnetic connector is much nicer than fiddling with a port, and there is no opening to keep dust and sweat out of. The trade-off is that without the CC lines, the nPM1300's input current limit stays at its 100 mA default until firmware raises it. So charging is slow until the firmware is written.

The sensor sheet

The LIS2DE12 accelerometer sits on the shared I2C bus, with CS tied high to select I2C mode and SA0 high for address 0x19. INT1 and INT2 go to separate GPIOs, because free-fall detection and general motion detection need different interrupt logic, and the chip can run both at once on separate pins.

The two sensor connectors are just the bus, power and ground. J4 is the MAXREFDES117 ribbon (GND, INT, SDA, SCL, +3V3_PPG), and J2 is the FPC connector for the MAX30208 sponsor flex (GND, SDA, SCL, +3V3_TEMP). Only one of them gets populated per board.

Layout

The layout split itself quite naturally: all the ICs on the top, all the connectors on the bottom. The MB-N2 takes the top half of the front, with the flash to its right. The nPM1300 and its two bucks sit in the bottom-left corner, close together so the switching loops stay small, with the buzzer above them and the power button and RGB LED in the middle. The DRV2605L and the LIS2DE12 are on the right.

On the back: the magnetic pogo connector along the bottom edge, the battery (J3) and motor (J6) JST-SH connectors, the MAX30208 FPC connector (J2) and the MAXREFDES117 ribbon pads (J4) on the left, the two solder jumpers, and the test points. 

J4 HaCK

There is no Connector for the J4 MAXREFDES117 Connector. It is just few rectangular pads spaced in a way that I can strip an end of a Ribbon connector and solder it on directly, the other end I will split them and solder to the MAXREFDES117 Board. I use this hack quite a lot for prototype PCB or when I am doubtful of the connection orientation. Here is a pic of the hack from my last Implementation. 

Test points

There are 16 test points (1.5 mm pads), on every rail, I2C, UART and SWD. There is no SWD header on this board, so programming is via T13 (SWDIO), T15 (SWDCLK), T17 (reset) and GND, with wires soldered on for the first flash.

Code and Hardware Files

All the KiCad files (schematic, layout, project library) and the fabrication outputs (Gerbers, BOM, pick-and-place) are in the hardware/vitarf-node folder of the project repo, along with the firmware from the earlier posts: https://gitlab.com/arvindsa/vitarf-e14

Final Notes

The schematic is done and reviewed, and the layout is routed with the DRC errors cleared. The most valuable part of this phase was the review, not the routing: two regulators shorted together, a split I2C net, and a buzzer that would never have buzzed, all caught on paper. Off to JLCPCB it goes.