nRF52840 BLE Wearables: Cách Xây Thiết Bị Đeo Tay

Nếu bạn muốn làm một thiết bị đeo nhỏ, có BLE và chạy bằng pin được vài ngày hoặc vài tuần, nRF52840 là một nền tảng rất dễ bắt đầu. Nó không phải là chip mạnh nhất, nhưng có đúng những thứ mà wearable cần: BLE ổn định, nhiều ngoại vi, USB, crypto và tài nguyên đủ rộng cho một firmware nghiêm túc.

Mình viết bài này theo hướng thực hành. Không hứa một con số “chạy cả năm” khi chưa biết màn hình, cảm biến và chu kỳ kết nối của bạn là gì. Mục tiêu là giúp bạn dựng được một prototype có thể đo, debug và cải thiện từng bước.

Bắt đầu bằng một dự án mở

Trước khi vẽ PCB riêng, mình thường đọc một dự án đã đi qua các vấn đề khó. Ba repo đáng xem:

• K-Watch là smartwatch open hardware + firmware trên nRF52840 và Zephyr, có màn hình memory-in-pixel, cảm biến, haptic và power management.
• InkTime tập trung vào một smartwatch nRF52840 low-power với PCB và enclosure riêng.
• MakerWatch cho thấy một hướng smartwatch maker dùng module nRF52840, IMU và mạch quản lý pin.

ZSWatch cũng rất đáng đọc về kiến trúc Zephyr, app và companion app. Tuy nhiên, các bản hiện tại của ZSWatch dùng nRF5340, nên mình xem nó là tài liệu tham khảo về cách tổ chức hệ thống chứ không bê nguyên cấu hình phần cứng sang nRF52840.

Điểm chung mình rút ra: wearable không chỉ là “MCU + BLE + pin”. Màn hình, cảm biến, PMIC, firmware và cơ cấu wake phải được thiết kế cùng nhau.

nRF52840 hợp với loại wearable nào?

nRF52840 có Cortex-M4F 64 MHz, 256 KB RAM, 1 MB flash, BLE 5 và USB. Con số này đủ cho:

• vòng đeo tay ghi gia tốc, bước chân hoặc chuyển động;
• tag BLE có nút bấm, buzzer và cảm biến môi trường;
• đồng hồ đơn giản với màn hình e-paper hoặc memory-in-pixel;
• remote BLE, safety button hoặc thiết bị gửi telemetry về điện thoại.

Nó không phải là lựa chọn mình ưu tiên cho streaming audio, màn hình màu nặng hoặc xử lý tín hiệu sinh học phức tạp. Với các bài toán đó, nRF5340 hoặc một SoC có nhiều tài nguyên hơn sẽ thoải mái hơn.

Prototype đầu tiên nên để lộ mọi thứ: khi dây nối và từng module còn nhìn thấy, việc debug dễ hơn nhiều.

Kiến trúc phần cứng tối thiểu

Một prototype wearable dễ debug có thể bắt đầu từ các khối sau:

Khối	Lựa chọn thực dụng	Điều cần kiểm tra
MCU + BLE	nRF52840 module hoặc DK	antenna, flash, SWD và dòng sleep của board
Motion	IMU I2C/SPI có interrupt	có wake từ motion và mức dòng khi suspend không
Hiển thị	e-paper, MIP hoặc OLED nhỏ	dòng lúc refresh; OLED không nên bật liên tục
Nguồn	Li-Po + charger/PMIC	power path, bảo vệ pin, dòng quiescent
Input	nút, touch hoặc gesture	debounce và wake source

Trong giai đoạn đầu, mình thích dùng module có antenna sẵn và breakout riêng cho cảm biến. Nó lớn hơn sản phẩm cuối nhưng giúp tách lỗi firmware, nguồn và RF. Khi mọi thứ đã ổn, mới gom lại thành PCB 4 lớp có ground plane và đường antenna đúng khuyến cáo.

Đừng quên đo dòng của cả board. Một dev board có regulator, LED và USB-UART có thể tiêu thụ nhiều hơn module nRF52840 trần. Kết quả đo trên DK không nên được dùng để hứa hẹn thời lượng pin của sản phẩm cuối.

BLE: thiết kế GATT nhỏ, có version

BLE không phải là một cổng serial vô hình. Thiết bị wearable nên có GATT rõ ràng, ví dụ:

• Device Information: firmware version, hardware revision;
• Sensor Data: characteristic Notify cho packet đo lường;
• Control: characteristic Write cho lệnh cấu hình;
• Battery: Read/Notify cho phần trăm pin và trạng thái sạc.

Packet nên ngắn và có version. Với dữ liệu cảm biến, một binary packet cố định thường dễ kiểm soát hơn JSON:

struct sensor_packet {
    uint8_t version;
    uint8_t flags;
    int16_t ax_mg;
    int16_t ay_mg;
    int16_t az_mg;
    uint16_t sequence;
};

sequence giúp app nhận ra packet bị mất; flags cho phép bạn mở rộng mà không phá client cũ. Nếu gửi mẫu liên tục, hãy cân nhắc batch vài mẫu rồi notify một lần thay vì đánh thức radio cho từng mẫu.

Zephyr và vòng đời năng lượng

Với wearable, mình thích cách tiếp cận event-driven của Zephyr: hệ thống ngủ khi không có việc, rồi chỉ thức bởi timer, GPIO, sensor interrupt hoặc BLE event. Tránh một vòng while chạy liên tục để đọc cảm biến — nó dễ viết nhưng thường là nơi pin bị đốt mà không ai để ý.

Luồng cơ bản có thể là:

1. IMU chạy ở chế độ low-power và phát interrupt khi có chuyển động.
2. nRF52840 thức dậy, đọc một burst mẫu qua I2C/SPI.
3. Firmware cập nhật bộ đệm hoặc trạng thái bước chân.
4. BLE notify theo chu kỳ đã chọn, rồi quay lại sleep.
5. Màn hình chỉ refresh khi dữ liệu thay đổi hoặc người dùng nhấn nút.

Trong Zephyr, cấu hình board, GPIO interrupt, I2C và BLE nên nằm trong device tree/Kconfig thay vì rải hard-code trong application. Bắt đầu từ sample BLE peripheral chính thức, sau đó thêm từng ngoại vi và đo sau mỗi thay đổi. Cách này chậm hơn một chút ở ngày đầu nhưng tiết kiệm rất nhiều thời gian khi lỗi xuất hiện.

Low-power thật sự nằm ở duty cycle

Không có một “dòng tiêu thụ của nRF52840” duy nhất. Pin nhìn thấy tổng của nhiều trạng thái:

I_avg ≈ (I_sleep × t_sleep + I_sensor × t_sensor + I_radio × t_radio + I_display × t_display) / T

Bạn có thể cải thiện bằng những quyết định rất đời thường:

• tăng advertising interval khi thiết bị chưa cần được tìm thấy liên tục;
• dùng connection interval hợp lý, không chọn nhanh nhất chỉ vì app phản hồi thích hơn;
• tắt regulator hoặc sensor không dùng;
• gom dữ liệu rồi gửi một lần;
• debounce nút bằng timer, không busy-wait;
• để màn hình ngủ và chỉ vẽ lại phần thay đổi nếu driver hỗ trợ.

Đừng tối ưu bằng cảm giác. Hãy đo advertising, connected idle, sensor sampling, notify và màn hình refresh như các testcase riêng.

Một con số sleep current đẹp trong datasheet chưa nói lên nhiều nếu màn hình, cảm biến và BLE chưa được đo cùng nhau.

Đo pin trên bàn rồi mới đeo lên tay

Một USB power meter rẻ có thể giúp bạn bắt đầu, nhưng thường không bắt được các đỉnh radio ngắn. Khi cần hiểu sâu hơn, dùng power analyzer hoặc oscilloscope có shunt phù hợp. Điều cần ghi lại không chỉ là mA trung bình mà còn là:

• dòng peak khi TX và refresh display;
• thời gian thiết bị ở từng state;
• số lần reconnect;
• dòng khi charger cắm/rút;
• thời lượng pin với firmware release thực tế.

Sau đó mới test trên cổ tay: đi bộ, gõ bàn, cầm điện thoại ở túi quần, mất kết nối rồi đi vào vùng phủ sóng lại. Wearable tốt là thiết bị vẫn hành xử dễ đoán khi người dùng không đứng yên trên bàn lab.

Đừng chỉ test trên bàn. Vị trí đeo, chuyển động của tay và khoảng cách tới điện thoại đều ảnh hưởng trải nghiệm.

Một lộ trình prototype ít rủi ro

Mình sẽ chia thành bốn mốc:

1. BLE hello world: quảng bá, connect, một service và một characteristic notify.
2. Sensor loop: thêm IMU, interrupt và packet có sequence.
3. Battery loop: thêm charger, battery measurement, sleep/wake và đo dòng.
4. Wearable loop: thêm màn hình/nút, enclosure, test RF trên cơ thể và test thời lượng pin.

Ở mỗi mốc, lưu lại firmware, cấu hình, sơ đồ nối dây và kết quả đo. Một bảng nhỏ trong repo thường có giá trị hơn một câu “low power” trong README.

Mình sẽ chọn gì?

Nếu bạn muốn học BLE và làm một wearable sensor hoặc đồng hồ đơn giản, mình sẽ bắt đầu với nRF52840 DK hoặc một module có USB/SWD rõ ràng, rồi đọc K-Watch và InkTime để học các quyết định hệ thống. Firmware có thể đi theo Zephyr; app điện thoại chỉ cần một GATT client nhỏ để kiểm tra trước.

Khi prototype chạy ổn, việc quan trọng nhất không phải thêm feature mà là giảm những lần thức không cần thiết, kiểm tra antenna trên PCB cuối và đo lại toàn bộ power budget. Đó là lúc một demo BLE bắt đầu trở thành một thiết bị đeo dùng được.

Tài liệu và dự án tham khảo

• Nordic nRF52840 Product Specification
• Zephyr Bluetooth API documentation
• Zephyr nRF52840 DK board documentation
• K-Watch trên GitHub
• InkTime trên GitHub
• MakerWatch trên GitHub
• ZSWatch trên GitHub