Embedded Systems & Product Development Consultancy · London, UK

A low-power wearable medical device, from concept to pre-production

A healthcare company needed a connected wearable that patients could wear for long periods at home: small, accurate on every unit, easy to charge and synchronising its data to a phone. We led the hardware architecture, low-power electronics and firmware, and took the device from concept through prototypes and validation to pre-production.

At a glance

Industry: Medical & Health
Client: A healthcare device company
Our role: Hardware architecture, low-power electronics, firmware design and testing, sensor calibration, bring-up and integration, preparation for manufacture
Platform: Nordic nRF52840 (Arm Cortex-M4F, Bluetooth LE, NFC)
Key technologies: Zephyr RTOS, nRF Connect SDK, BLE, MCUboot, NFC, IMU and precision pressure sensors, USB and wireless charging, C/C++, CMake, UML, unit testing
Services: Product development · Electronics & PCB design · Embedded software & firmware · Hardware/software integration
Outcome: Taken from concept to pre-production, with BLE telemetry, secure provisioning and OTA updates working end to end

The challenge

A medical wearable lives under constraints that pull against each other. It has to be small and light enough to wear all day, last a full wear period on one charge and recharge easily at home, by USB cable or on a wireless pad. Its pressure and motion readings have to be accurate on every unit that leaves the factory, not just on the prototype on the bench. Patient data must stay protected on its way to the phone app, and firmware has to be updatable in the field without any risk of leaving a device unusable.

The client had a clinical concept and a clear idea of what the device had to measure. They needed a team to turn it into hardware, firmware and a design that could be manufactured.

Our Role

We owned the embedded side end to end: hardware architecture and component selection, low-power electronics design with schematic and layout reviews, all of the device firmware, prototype bring-up and system integration, and the provisioning and calibration workflows for manufacture. We worked alongside the client’s clinical and app teams throughout.

medical-wearable-electronics-block-diagram

System architecture

The device is built around a Nordic nRF52840: a Cortex-M4F with 1 MB of flash, 256 KB of RAM, a Bluetooth LE radio and an NFC tag interface on one chip. One SoC handling sensing, radio and security kept the board small and the power budget under control.

Sensing: analogue sensor front-ends sampled by the on-chip ADC, digital sensors on I²C and SPI, and an IMU for movement and wear detection.
Connectivity: Bluetooth LE to the patient’s phone, and NFC for tap-to-pair set-up.
Power: a rechargeable battery with charging and protection, a wireless charging receiver, and battery monitoring reported to the app.
Security: per-device identity and keys provisioned in production, encrypted and bonded BLE links, and signed firmware images.

Hardware design

Three antennas share a very small space: the Bluetooth antenna, the NFC antenna and the wireless charging coil. We planned their placement together from the start, kept the charging coil and its shielding clear of the radio, and tuned the Bluetooth antenna matching in the final enclosure rather than on an open board.

Component selection driven by size, quiescent current and long-term availability.
Load switches so sensors and peripherals are fully powered down between measurements.
The nRF52840’s DC/DC converter used for the radio and core supply, to cut active current.
Schematic and layout reviews at each revision, with test points and programming access kept for production.

Firmware

The firmware is written in C and C++ on Zephyr RTOS with the nRF Connect SDK. We set up a modular CMake build with the board described in devicetree, and wrote reusable static C++ libraries for the sensor, storage and communication layers so they can be carried into the client’s future products.

Drivers for the analogue and digital sensors, IMU, NFC, battery monitoring and board peripherals over SPI, I²C, UART, GPIO, ADC and PWM.
BLE telemetry: a custom GATT service with time-stamped readings stored on the device and synchronised whenever the phone reconnects, so no data is lost between sessions.
Secure provisioning: each device gets its own identity and keys in production, and pairs with the app using LE Secure Connections.
OTA updates: MCUboot with signed images and two image slots, updated over BLE, so an interrupted update leaves the device on its last working firmware.
Device configuration from the app, with settings validated and stored on the device.

Power

Sensors scheduled to wake, measure and power down rather than run continuously.
BLE connection and advertising intervals tuned separately for pairing, active sync and idle.
Battery state monitored and reported, so the app can warn the patient before the device runs flat.

Sensor calibration

Precision pressure sensors and an IMU only produce trustworthy data if every unit is calibrated. We characterised the sensors against reference equipment and built calibration into the firmware from the start.

Pressure sensors: offset and gain calibrated per sensor at several reference pressures, with temperature compensation applied in firmware.
IMU: accelerometer offset and scale, and gyroscope bias, calibrated per device, with a start-up check to catch drift.
Storage: calibration coefficients kept in a protected flash area with a version and checksum, separate from the application, so they survive every firmware update.

Bring-up and validation

We brought up each prototype revision on our bench and worked through sensor, communication, RF and power issues with oscilloscopes, logic analysers, a battery analyser, SWD debuggers and BLE diagnostic tools, fixing each on whichever side it belonged and feeding it into the next revision. Validation covered sensor accuracy after calibration, wireless performance in the enclosure, power consumption against the budget, and update and recovery behaviour.

Preparing for production

We automated calibration for manufacture. A production station steps each device through its calibration points, calculates the coefficients from the reference readings and loads a device-specific calibration configuration, together with the device’s identity and keys, then reads everything back to verify it. Each calibration record is stored against the serial number. Hardware architecture, firmware design, validation and power optimisation were documented in full for the client’s team and their regulatory work.

Results

The device went from concept through prototypes and validation to pre-production.
The power budget was met through hardware choices and firmware scheduling, measured on real hardware.
BLE telemetry, secure provisioning and OTA updates work end to end with the client’s app.
Pressure and motion sensors calibrated per unit, with calibration automated and verified in production.
Unit-tested firmware, designed and documented in UML, built on reusable C++ libraries the client’s team can extend.