STM32健康监测手环：从传感器到APP的全链路开发详解

简介：这是一套面向嵌入式初学者与物联网项目实践者的完整健康监测手环开发资源，基于STM32F103C8T6主控，集成ADXL345加速度计（实现精准计步与姿态识别）、MAX30102心率血氧模块、DS18B20体温传感器、DS1302实时时钟及0.96寸OLED显示，支持蓝牙数据上传与配套Android APP实时查看。资源共509个文件，涵盖82个C源码、88个头文件（.h）、80个编译中间文件（.o/.d）及2个Keil工程文件（.uvprojx），辅以原理图PDF、接线示意图、模块选型链接、PPT设计汇报稿、项目文档与APK安装包等，结构清晰、模块解耦，便于复现、调试与功能扩展。压缩包大小为416.35MB，内容已通过实机测试验证，功能效果与演示视频一致。目前已有622人学习下载，适用于课程设计、毕业设计、电子设计竞赛、大创项目及嵌入式系统实训，是掌握传感器驱动、低功耗设计、多任务协调与软硬协同开发的典型实战案例。 拿到这个压缩包的第一反应，大多数人应该跟我一样——直接解压，找到Keil工程，编译烧录，完事。等你真正把代码烧进去，屏幕亮了、数据滚了，才发现这套项目真正难的不是代码本身，而是从传感器到手机APP这条完整链路的每一个衔接点。你遇到过OLED有显示但心率全是零、蓝牙能配对但APP收不到数据、上位机读到一串乱码这类问题吗？这些坑我在调试过程中基本都踩过一遍。

这个项目属于典型的物联网嵌入式全链路开发，核心链路是：STM32采集传感器数据 → 串口转发给蓝牙模块 → 无线传输到手机APP → 解析显示。项目包里除了系统源代码，还包含了原理图、接线说明、主要模块选型购买链接、PPT、手机APP安装包和项目文档，无论你是做课程设计、毕业设计，还是想自己动手做一个可穿戴健康设备，这套东西都能作为完整的参考起点。下面我按实际开发顺序，把整个项目从硬件选型到APP联调的关键细节全部过一遍，顺便把那些文档里不会写、但会让你卡壳很久的问题一并讲清楚。

1. 健康手环要做什么：需求拆解与硬件选型背后的思路

1.1 先把手环的"健康监测"边界划清楚

很多人一听到健康监测手环，第一反应就是把心率、血氧、体温、血压、心电、睡眠监测全塞进去。作为一个课程设计或者毕设级别的项目，这种思路是大忌。功能叠得越多，传感器接口、电源管理、数据融合的复杂度就会指数级上升，最终很容易变成每个功能都做了，每个功能都没做好。

这套项目的定位很明确：监测人体关键生理参数并完成无线传输和APP展示。具体拆解下来就是4个核心指标：

• 心率：通过光电容积脉搏波描记法（PPG）测量，单位为bpm
• 血氧饱和度（SpO2）：同样基于PPG原理，通过红光和红外光的吸收差异估算
• 体温：通过数字温度传感器采集体表温度
• 运动步数：通过六轴加速度计的振动特征计算

为什么选这四个？因为它们分别代表了不同的传感器通信方式和数据处理逻辑：PPG信号涉及模拟前端和数字滤波，体温涉及单总线协议时序，步数涉及加速度数据的时域特征提取。可以说，这四个指标覆盖了嵌入式开发中I2C、单总线、定时器中断、数字信号处理这几大基本功，做完一个项目，整个STM32的核心外设基本都过了一遍。

这里有个很重要的认知：这是一个物联网教学项目，不是医疗设备。手环测出来的数据可以用作健康趋势参考，但绝不能宣称达到医疗级精度。MAX30102这类传感器受手指放置位置、环境光、皮肤色素、运动伪影的影响非常大，连续测量时波形基线漂移是常态。理解这一点，调数据时心态会稳很多。

1.2 主控为什么是STM32F103C8T6而不是别的芯片

主控选型这个问题我确实认真对比过。这套项目用的是STM32F103C8T6，也就是大家常说的"蓝丸"核心板。我后来仔细琢磨了一下，这个选择在当前环境下是最合理且对学生最友好的。

先看这颗芯片的底子：ARM Cortex-M3内核，主频72MHz，64KB Flash，20KB SRAM，内置USART、I2C、SPI、ADC、定时器等外设。放到健康手环这个场景里，跑传感器采集和协议封装绰绰有余。Flash空间也要算一笔账——HAL库本身会占掉20KB~30KB左右，加上传感器驱动和APP逻辑，64KB会有点紧张，但精打细算一下还是放得下的。如果你计划在代码里加更多功能，建议换用512KB Flash的STM32F103ZET6或者F407系列。

选择这颗芯片还有两个实际层面上的原因。第一是生态：STM32CubeMX加HAL库的开发模式已经非常成熟，网上关于F103的例程多到看不过来，任何接口问题都能在社区找到答案，这对新手来说是保命级别的优势。第二是成本：核心板十几块钱，传感器模块单买都是几块到十几块，整套硬件成本可以压到100元以内。相比动辄几十美金的Nordic nRF52系列开发板，F103的试错成本实在太低了。

那为什么不直接用ESP32？ESP32集成蓝牙和WiFi，确实更适合可穿戴设备的原型开发。但有一个很现实的问题：ESP32的蓝牙通常用BLE协议栈，而BLE的GATT服务、特征值、通知机制对新手来说理解成本不低。STM32加HC-05的方案，本质是用串口透传把蓝牙通信简化成了"无线串口"，单片机端只需要把数据往串口扔，手机端通过蓝牙Socket收发数据，整个开发逻辑回归到最朴素的串口通信。对教学项目而言，这种"简单到几乎不会出错"的方案往往才是最优解。

1.3 传感器选型对比：为什么是MAX30102、DS18B20和MPU6050

下面把项目中涉及的几个核心传感器选型做一个系统对比：

说说我为什么对这些选型这么肯定。

MAX30102在健康监测类项目里几乎是"标配"。它内部集成了LED驱动电路、光电检测器和环境光抑制电路，能直接用红光和红外光两组LED交替照射皮肤组织，然后通过光敏二极管检测透射光或反射光的变化。芯片内部完成了一些初步的信号调理，输出的是经过ADC转换的数字值，MCU读取FIFO就能拿到原始PPG波形数据。相比早期方案需要自己搭建模拟放大和滤波电路的方式，它把前端硬件的复杂度转移到了芯片内部，代价是从寄存器配置到数据处理都需要自己摸索。

DS18B20选它主要是因为简单。用单总线协议，一个GPIO引脚就能搞定通信，而且测温精度0.5℃对体表温度监测完全够用。不过它的时序逻辑比较讲究，尤其要注意初始化时序中的复位脉冲和存在脉冲检测，后面第三章我会详细讲。

MPU6050提供六轴数据，加速度计用来测步数，陀螺仪可以用来判断手环姿态（比如翻腕亮屏）。实际上如果只为了计步，用个三轴加速度计LIS3DH就够，但MPU6050的资料和例程在ST社区里是海量的，调试起来更顺畅。

1.4 蓝牙方案的选择逻辑：为什么是HC-05而不是BLE

在正式动工前，蓝牙方案的选型值得多说几句。这个项目的完整链路是"STM32→串口→蓝牙模块→手机APP"，其中蓝牙是整个系统里最能卡住人的环节，很多人搞了几天都连不上，然后开始怀疑人生。

HC-05是经典蓝牙2.0 + EDR模块，工作在SPP（串口透传协议）模式下。使用者视角下，它的行为就像一个"无线串口线"：你往STM32的串口发数据，手机端就能收到，反之手机发数据，STM32端就能收到。这种透传模式把复杂的蓝牙协议栈封装掉了，MCU代码里完全不需要接触蓝牙协议，只需要老老实实操作串口。

那为什么不用低功耗蓝牙（BLE）？BLE的优势是功耗低，通信协议更现代，应用层需要用GATT服务和特征值来组织数据。BLE的开发流程通常是：在手机APP里扫描设备→连接→发现服务→使能通知→订阅特征值，然后双方通过特征值的读写和通知来交换数据。对于没有接触过BLE协议栈的开发者来说，这个学习曲线相当陡峭。我记得第一次做BLE项目，光搞清楚Service、Characteristic、Descriptor这三个概念的关系就花了不少时间，后面还有MTU协商、连接间隔、丢包重传这些细节。

HC-05则是把这一切变成了"串口收发"。只要配对成功，蓝牙模块和手机之间就会建立一个虚拟串口，发送方只管往串口寄存器写数据，接收方就能在APP的InputStream里读到同样的字节流。这种极低的抽象层级适合教学，也适合快速验证业务逻辑。代价是经典蓝牙的功耗远高于BLE，待机电流通常有几毫安甚至十几毫安，但作为一个插着USB线供电的桌面手环原型，这个缺点完全不影响使用。

项目包里实际用的是HC-05，这也是我推荐的方案。如果你的后续目标是做低功耗可穿戴设备，可以在整套逻辑跑通后，把HC-05替换成CC2541或者nRF52832模块，STM32端的代码几乎不用改，因为通信层依然是串口透传，变化的只是协议栈由经典蓝牙变成BLE，以及APP端需要改成GATT连接方式。

2. 原理图与接线里的关键细节：电压域、I2C地址和复位时序

2.1 电源方案的取舍：锂电池、充电模块与稳压芯片

原理图里最容易被新手忽略但又最容易出问题的地方就是电源。这套项目让我印象很深的一个细节是：MCU、传感器模块、蓝牙模块、OLED屏幕，四个部分的电压要求居然各不相同。

核心板上的STM32F103C8T6本身支持2.0V~3.6V供电，板载的AMS1117-3.3稳压芯片会把外部输入降到3.3V。MAX30102传感器模块的工作电压是1.8V~3.3V，所以3.3V供电没问题。DS18B20的供电范围是3.0V~5.5V，3.3V也在范围内。但有个坑：SSD1306 OLED模块虽然逻辑电平是3.3V，市面上很多模块的供电脚却标着5V，如果你直接接5V，模块上的稳压电路会把它降下来，但如果你的接线图里写的是"OLED VCC接3.3V"，请务必确认你手头的模块有没有集成稳压芯片，否则屏幕可能亮度不足或者干脆不亮。

电源架构大体分两种，说明电路的特点：

项目原理图采用的是第二种方案：TP4056充电模块负责给锂电池充电，电池输出通过升压模块稳定到5V，再经过板载的AMS1117降压到3.3V。锂电池电压3.7V到4.2V，不经过升压直接给AMS1117的话，AMS1117的压差要求（Dropout Voltage）大约是1V，意味着输入电压至少4.3V才能稳定输出3.3V，而电池在3.7V左右根本达不到这个门槛。所以先升压到5V再降压到3.3V，虽然多了一次能量损耗，但胜在稳定。

对了，还有一个特别容易出错的地方：蓝牙模块的供电。HC-05在工作时会产生较大的瞬时电流脉冲，如果电源设计不好，蓝牙一启动就会把电源电压拉低，导致MCU复位或者传感器读数异常。所以如果你发现系统一开机蓝牙能连上但一会儿就自动重启了，十有八九是电源供电能力不够，这时候在蓝牙模块的电源引脚旁边加一个100μF的电解电容和一个0.1μF的陶瓷电容，问题往往就能解决。

2.2 传感器接口电路读图要点：上拉电阻与I2C总线

打开原理图，第一件事不是看芯片具体怎么连，而是看I2C总线的结构。MAX30102、OLED屏幕和MPU6050这三块设备全部挂在同一条I2C总线上，这是原理图设计里最核心也最容易埋雷的地方。

I2C总线是开漏输出结构，这意味着总线上的设备只能把线拉低，不能主动拉高，所以I2C总线上必须有上拉电阻来保证空闲状态时SDA和SCL为高电平。标准I2C规范推荐上拉电阻阻值在1kΩ到10kΩ之间，常见取值是4.7kΩ。很多现成的传感器模块上已经自带上拉电阻了（尤其是GY-521这类MPU6050模块、MAX30102模块、SSD1306模块），如果你把多个模块挂到同一总线上，多个上拉电阻并联会降低总等效电阻，导致I2C信号上升沿变缓，严重时通信不稳定。

解决办法是：先确认每个模块是不是已经带上了上拉电阻。如果带了4.7kΩ，并联后等效电阻约1.6kΩ左右，通常情况下还能正常工作。要是你用的是不带任何外围电路的裸板传感器，那就必须在原理图里预留位置焊接4.7kΩ上拉电阻。我当时调试的时候见过一个很典型的故障：单独接OLED屏幕时一切正常，接上MAX30102之后偶尔出现数据错乱，最后发现就是两个模块都自带2.2kΩ上拉，并联后等效电阻太低，信号边沿太陡，干扰严重。

此外还要注意读原理图时的地址分配。I2C设备都有固定的7位地址：

• OLED SSD1306：地址为0x3C（默认）
• MAX30102：地址为0x57（固定，不可改）
• MPU6050：地址为0x68（AD0引脚接GND时）；如果AD0接VCC，地址变为0x69

这三个地址互不冲突，所以挂同一条总线没问题。但如果你自己扩展项目，加了一个地址也是0x3C的I2C设备，那就等着数据错乱吧。

2.3 接线时最容易方向搞反的引脚

项目包里带了接线说明文档，但我估计还是会有很多人看着表格焊错线。这里我把最容易出错的几根线单独拎出来说：

串口交叉接线：HC-05的TXD要接STM32的RX（PA10），HC-05的RXD要接STM32的TX（PA9）。我见过不下十个人在这里接反，结果是MCU发数据收不到反馈，蓝牙一点反应都没有。记住口诀：发对收、收对发。

DS18B20的DQ引脚：这个芯片只有三个引脚（VCC、DQ、GND），DQ既要发送命令又要读取数据，所以必须接一个4.7kΩ上拉电阻到VCC。如果接线图里没有标注这个上拉电阻的位置，实际测试时温度大概率读出来是-127℃或者85℃——这是DS18B20未插好或总线时序异常的典型表现。

3.3V和5V不要混淆：MAX30102模块和MPU6050模块都明确是3.3V供电，接5V会直接烧坏。OLED模块有的写着支持3.3V~5V（内部有稳压），有的只支持3.3V，上电前一定要看模块背面丝印。HS-05蓝牙模块的VCC支持3.6V~6V，可以接5V，也可以接3.3V，不过接5V时逻辑电平是5V，而STM32引脚是3.3V容忍的（FT引脚可以容忍5V），所以也没问题。

共地：整个系统必须共地。MCU的地、传感器模块的地、蓝牙模块的地、电源模块的地全部要连到同一个GND网络。蓝牙模块如果不和STM32共地，会出现一串数据偶尔收到几个字节的诡异现象。

3. 传感器数据从寄存器到串口：代码编译下载与核心逻辑拆解

3.1 从CubeMX初始化到工程编译下载

拿到工程文件后，如果之前没有配置过STM32CubeMX的Keil工程，直接从源码开始也是能跑的，但理解一下工程生成的底层逻辑对后续二次开发很重要。这个项目的代码是在STM32CubeMX里初始化生成的，使用HAL库。

CubeMX里需要重点确认的配置项：

• RCC时钟：采用外部8MHz晶振，PLL倍频到72MHz系统主频
• USART1：波特率115200，8位数据，无校验，1位停止位（接HC-05）
• USART2（可选）：波特率115200，用于打印调试日志
• I2C1：标准模式100kHz或快速模式400kHz，接所有I2C设备
• GPIO：DS18B20接任意普通IO（比如PA1），OLED的复位引脚（如果有）接普通IO
• 定时器：SysTick做延时，TIM2做ADC采样定时触发或计步的时间基准

有一个非常容易忽略的地方：PB3、PB4和PA15这三个引脚默认是JTAG调试口。如果你把DS18B20接到了PB4，默认情况下这个引脚根本不受你控制，因为STM32复位后JTAG是开启的，PB4被JTAG占用。解决办法是在CubeMX里把Debug选项从JTAG改成Serial Wire或者直接禁用调试接口（禁用后就只能用ST-Link的SWD接口调试了）。很多人的代码烧进去后DS18B20怎么都读不到数据，一查原来是引脚被JTAG占用了。

代码烧录方式上，如果你用ST-Link，推荐直接用Keil的Download按钮。如果用串口下载（FlyMCU类工具），记得先把BOOT0拉高、BOOT1拉低，然后复位才能进入系统存储器引导模式。还有一点，工程配置里的Flash Download选项要选对芯片型号，从32KB写到64KB的项目如果选错Flash容量，下载到一半会报错。

3.2 心率血氧传感器MAX30102的工作流程：从PPG信号到心率数值

MAX30102是这个项目里技术含量最高的传感器，值得花笔墨认真讲。它的核心原理是光电容积脉搏波描记法（PPG）：心脏每次搏动都会引起血管内血容量变化，血容量变化会影响皮肤组织对光的吸收量。MAX30102内部有两个LED——红光LED（波长约660nm）和红外LED（波长约880nm），LED交替点亮，光线照射到皮肤组织后一部分被反射回来，被同一封装里的光电二极管接收转换成电信号。由于血管搏动，反射光强度会呈现周期性波动，这个波动的频率就是心率。

血氧饱和度的测量则利用了一个物理特性：氧合血红蛋白（HbO2）和脱氧血红蛋白（Hb）对红光和红外光的吸收系数不同。氧合血红蛋白对红外光的吸收更强，脱氧血红蛋白对红光的吸收更强。通过计算红光和红外光两个通道的AC分量（脉动部分）和DC分量（恒定部分）的比值，可以得到一个R值，再通过经验公式或查表转换成SpO2数值。

代码层面，MAX30102的驱动主要分几个步骤：

1. 寄存器初始化：配置FIFO写指针和读指针、模式设置（心率模式还是血氧模式）、采样率（典型的50Hz或100Hz）、ADC位数（18位或19位）、LED电流（几毫安到几十毫安可调）
2. 读取FIFO数据：MAX30102内部有32个采样点的FIFO，数据就绪后（中断引脚拉低或者状态寄存器的AFRL位被置位），MCU通过I2C批量读取FIFO中的数据
3. 数字滤波：原始PPG信号含有大量噪声，需要经过带通滤波器（典型范围0.5Hz到5Hz左右，对应30bpm到300bpm的心率范围）滤除基线漂移和高频噪声
4. 峰值检测：对滤波后的波形成分进行峰值检测，计算相邻峰值的时间间隔，换算成心率。比如两个峰值间隔0.8秒，心率就是75bpm

实测中我遇到的最常见问题是：传感器读数一直为0或者固定值。排查顺序是：

• 先确认I2C总线上的设备地址是否能扫描到（address = 0x57）
• 再确认寄存器初始化是否成功（读WHO_AM_I寄存器或者PART_ID寄存器，MAX30102的PART_ID应为0x15）
• 然后检查是否把手指正确放置在传感器上。官方的开发板设计是让传感器贴近手指指腹，手指要覆盖整个感光区域，不能留缝隙。光照环境太强也会干扰测量

信号处理上还有一个关键点：MAX30102输出的原始数据经过ADC转换后，DC分量很大（占80%以上），AC分量非常小。如果你想在调试阶段用串口打印原始数据观察波形，最好做一次差分处理（比如用当前值减去前一个值），就可以看到明显的脉搏波形了。否则打印出来是一串缓慢变化的大数字，很难看出规律。

3.3 体温传感器DS18B20：单总线协议的时序要求

DS18B20的协议是整个项目里对时序最敏感的部分。单总线协议只需要一根数据线，数据通信完全靠严格的时序关系来区分0和1。DS18B20的工作流程分为三步：初始化（复位脉冲+存在脉冲）、发送ROM命令（一般是跳过ROM匹配，命令码0xCC）、发送功能命令（启动温度转换0x44，或读取暂存器0xBE）。

单总线时序的关键点是延时精度。使用HAL库的HAL_Delay()函数做毫秒级延时没问题，但在微秒级时序里，HAL_Delay()的分辨率完全不够用。我推荐使用DWT->CYCCNT（Cortex-M3内核的周期计数器）或者直接拉高拉低I/O口后空转几个周期来实现微秒级延时。不推荐用普通的for循环空转做延时，因为不同编译优化等级下循环周期会变化，同一个延时函数在-O0和-O2下实际耗时差好几倍，换个优化等级时序就全乱了。

温度转换命令发出后，要等待转换完成。DS18B20在12位分辨率下最大转换时间是750ms，但实际通常几百毫秒就完成了。可以通过读取总线电平的方式判断转换是否结束：如果总线被拉低，说明还在转换；如果总线释放为高，说明转换完成。不过对新手来说，最简单可靠的方式就是转换后固定延时750ms再读温度。

读取温度数据时要注意字节顺序：DS18B20返回的暂存器数据中，第0字节是温度低字节，第1字节是温度高字节，合起来是一个16位有符号数。12位分辨率下低4位是小数部分，每1LSB代表0.0625℃。比如读到的两个字节是0xD1和0x07，组合后是0x07D1 = 2001，右移4位得到125，乘以0.0625得到7.8125℃。这个计算逻辑如果你搞混了，温度数值会差好几倍，一眼就能看出来不对。

最后提醒一下：不要把DS18B20的VCC接到3.3V以外的电压。有的资料说DS18B20支持"寄生供电"模式（只接两根线，从数据线上取电），但那种模式下要求数据线必须接很强的上拉，很多人搞不定。项目里直接用外部供电模式，VCC接3.3V，DQ线接MCU引脚，简单可靠。

3.4 自定义协议帧：串口数据是怎么组装的

有了传感器数据，接下来要解决的是一道经典的通信问题：怎样把多个数据可靠地从MCU传到手机APP。直接往串口扔字符串当然也能显示，但心率、血氧、体温、步数这几个数据混在一起，APP端没法区分哪个是哪个，而且一旦出现干扰字节，整条数据就废了。所以工程代码里定义了一套自己的帧协议。

这套协议常见的形式是这样的：

组装一帧数据的代码逻辑大致是这样：

uint8_t tx_buffer[12]; uint8_t index = 0; tx_buffer[index++] = 0xAA; // 帧头1 tx_buffer[index++] = 0x55; // 帧头2 tx_buffer[index++] = 0x08; // 数据长度 tx_buffer[index++] = DATA_TYPE_HEART_RATE; // 数据类型 tx_buffer[index++] = (uint8_t)(heart_rate >> 8); // 高字节 tx_buffer[index++] = (uint8_t)(heart_rate & 0xFF); // 低字节 tx_buffer[index++] = (uint8_t)(spo2 >> 8); tx_buffer[index++] = (uint8_t)(spo2 & 0xFF); tx_buffer[index++] = (uint8_t)(temperature_x10 >> 8); tx_buffer[index++] = (uint8_t)(temperature_x10 & 0xFF); tx_buffer[index++] = calculate_checksum(tx_buffer, index); // 累加和校验 tx_buffer[index++] = 0x0D; // 帧尾 tx_buffer[index++] = 0x0A; HAL_UART_Transmit(&huart1, tx_buffer, index, 100);

为什么用16位整数而不是直接传浮点数？因为单片机的浮点运算开销大，而且printf格式化浮点数还会引入不可控的代码体积。体温用"温度值乘以10"的方式存储（比如36.5℃存成365），APP端显示的时候再除以10，这样既保留了小数点精度，又避免了浮点传输的复杂度。这个思路在嵌入式通信里很常见，特别是对资源受限的MCU，用定点数代替浮点数是基本功。

协议帧设计也有一个取舍：是每个数据点单独一帧，还是把所有数据打包成一帧？工程里用的是每个传感器数据单独组帧的方式。这样APP端收到哪一帧就刷新对应的UI元素，逻辑清晰，扩展新传感器时只需要加一个"数据类型"的枚举值。缺点是传输频率高了以后帧头开销会加大，但对115200波特率来说，几字节的开销完全无所谓。

4. 蓝牙通道的调试实录：配对失败、波特率与数据粘包

4.1 HC-05的AT指令配置与工作模式

HC-05是整套链路里"看起来简单、实际坑最多"的模块。它本质上是一个蓝牙转串口的桥接芯片，内部运行着完整的蓝牙协议栈。它有两种工作模式：AT指令模式（用于配置）和数据透传模式（正常工作）。

进入AT模式的方法通常是：按住模块上的小按钮，然后给模块上电，这时候模块的指示灯会以较慢的频率闪烁（大约2秒一次），此时串口发送AT指令会返回OK。另一种方式是把模块的EN引脚（或者KEY引脚）拉高，然后上电。

AT模式下波特率默认是38400（注意，不是115200，这是新手最容易踩的坑）。如果你用串口调试助手给HC-05发AT总是没有回应，先确认波特率是不是38400。数据透传模式下的默认波特率通常是9600（不同厂家固件不同，有的模块也是38400），所以STM32的USART波特率和HC-05透传波特率必须保持一致，否则收的数据就是乱码。

常用AT指令有这么几条：

AT // 测试通信，返回OK AT+NAME=HC-05 // 修改蓝牙名称 AT+PSWD=1234 // 修改配对密码 AT+UART=115200,0,0 // 设置串口波特率115200，停止位1位，无校验 AT+ROLE=0 // 设置角色：0从机，1主机，2回环 AT+ADDR? // 查询蓝牙地址

建议统一把透传波特率设为115200，和STM32的USART1保持一致。这样代码里既不用做波特率换算，也不需要额外的电平转换，STM32直接把数据发给HC-05，HC-05原封不动地无线发送给手机APP。

4.2 "连接不上"的完整排查链路

如果说这个项目有一个环节能让人卡三天，那就是蓝牙连接。我根据自己调试的体会，把用户最常见的各种接通失败切分成了四条链路，大家对照排查：

第一层：手机搜索不到HC-05

可能的原因有三个。一是模块压根没进入可被发现模式——HC-05从机模块默认处于可配对状态，但如果模块之前被配置过且已经配对过，可能不会自动进入可搜索状态，此时把模块断电重新上电，或者按住按钮让它重新进入AT模式试试。二是电源问题——蓝牙模块供电不足，射频发射功率不够，手机自然搜索不到，建议用独立5V电源给蓝牙模块供电。三是距离问题——手机和模块距离超过10米或者中间有金属遮挡，靠近一点就好。

第二层：能搜索到，但配对失败

HC-05的默认配对密码通常是1234或0000，但有些厂家的模块默认密码是随机生成的。此时需要通过AT指令AT+PSWD=1234重新设置一个已知的密码。另外，如果你的手机之前配对过这个模块，建议在系统设置里删除旧配对记录再重新配对，有时候旧缓存会干扰新配对。

第三层：配对成功，但APP连接不上

这是安卓端特有的坑。从安卓6.0开始，经典蓝牙扫描需要定位权限（ACCESS_FINE_LOCATION），安卓12开始引入了新的BLUETOOTH_SCAN和BLUETOOTH_CONNECT权限。很多人的APP直接报"连接失败"，其实不是代码问题，而是权限没给。安卓12及以上，手机在连接时会弹窗申请附近设备权限，如果用户点击了拒绝，APP代码里即使申请了权限也无法连接。完整的权限处理逻辑在第5章会详细讲。

第四层：APP连接成功，但收不到数据

连接成功说明蓝牙链路已经通了，收不到数据通常是以下原因：波特率不匹配（STM32串口和HC-05的波特率不一致）、接线有问题（TXD/RXD接反）或者代码里发送逻辑没跑起来。把HC-05模块的TXD和RXD分别接到一个USB转TTL模块上，用串口调试助手直接测蓝牙模块的收发，是区分"STM32端问题"还是"蓝牙模块问题"最快的方法。

我遇到过的一个比较隐蔽的问题：HC-05的指示灯变成快闪状态（约1秒闪2次）说明模块已经处于连接状态，但手机APP显示连接失败。最后发现是APP代码里用的UUID不对——经典蓝牙的SPP服务必须使用标准的SerialPortServiceClass_UUID，也就是00001101-0000-1000-8000-00805F9B34FB，UUID写错一个字符，即使模块已经连上，Socket通信还是会被拒绝。

4.3 波特率不匹配与数据粘包：两个最常见的通信异常

波特率问题在串口调试阶段几乎人人都会遇到。STM32端设置115200，而HC-05透传波特率还是出厂默认的9600，Stm32发过来的数据在HC-05端就会乱码。在手机APP端表现为收到一堆乱码符号。解决办法是：用USB转TTL连接HC-05，进入AT模式，发送AT+UART=115200,0,0，把透传波特率改成115200，然后重新上电。

这里多说一句：HC-05的AT指令波特率（38400）和透传波特率（115200）是两回事。修改透传波特率后，AT指令仍然用38400通信，但数据透传会用115200。很多人在AT模式里设置完波特率后，直接断电接回STM32，发现还是一堆乱码——因为他在串口调试助手里测试时用的是AT波特率而不是透传波特率，验证方式不对。

数据粘包则是另一个高频问题。蓝牙是流式传输，没有消息边界的概念，MCU发出去的两帧数据在手机端可能合并成一包收到，也可能一帧被拆成两段收到。如果你在APP端直接读InputStream然后按固定长度解析，就会出现解析错位、数据乱跳的现象。

解决粘包问题的经典思路是：先按帧头定位，再按帧尾截断。APP端维护一个数据缓冲区，不断把新收到的字节追加进去，然后循环搜索缓冲区内是否存在完整的帧（找到0xAA 0x55帧头，再检查数据长度和校验和），如果能解析出完整帧就提取出来，处理完再从缓冲区中移除；如果缓冲区里只有半帧数据，就继续等待后续数据。这个逻辑在嵌入式开发里叫"分区缓冲"或者"状态机解析"，是所有串口通信协议的基础。

5. 安卓APP从配对到展示：把十六进制帧还原成健康指标

5.1 经典蓝牙连接全流程：权限、UUID与Socket

手机APP是本项目的"显示器"，它的核心任务是建立经典蓝牙SPP连接，读取数据流，解析协议帧，然后刷新UI。项目包里提供了安卓APP安装包，如果你只做MCU端，用现成的APP就够了；如果你要二次开发APP，下面把这些关键点讲清楚。

用Android原生API连接经典蓝牙，标准的开发流程是：

1. 声明权限：AndroidManifest.xml中加入蓝牙权限（旧版本：BLUETOOTH、BLUETOOTH_ADMIN；安卓12+：BLUETOOTH_SCAN、BLUETOOTH_CONNECT、BLUETOOTH_ADVERTISE）
2. 检查蓝牙是否开启：通过BluetoothAdapter的isEnabled()判断，未开启则调用系统Intent请求开启
3. 扫描设备：通过BroadcastReceiver接收ACTION_FOUND广播，获取远程设备名称和MAC地址
4. 建立Socket连接：用BluetoothDevice.createRfcommSocketToServiceRecord()方法，传入SPP标准的UUID（00001101-0000-1000-8000-00805F9B34FB），然后在子线程中调用connect()方法
5. 获取数据流：连接成功后，通过socket.getInputStream()读取数据，socket.getOutputStream()发送数据

权限这块是让安卓开发新手头疼的地方。安卓6~11，经典蓝牙扫描必须申请定位权限，因为系统认为蓝牙扫描可能暴露用户位置信息。很多人的APP在安卓13手机上直接闪退或者搜索不到设备，原因就是没申请ACCESS_FINE_LOCATION。安卓12及以上引入了更细粒度的蓝牙权限，需要在运行时分别申请BLUETOOTH_CONNECT和BLUETOOTH_SCAN。代码里建议做一个兼容处理：根据Build.VERSION.SDK_INT判断版本，动态申请不同组合的权限。

还有一个细节：蓝牙连接是耗时操作，绝对不能放在主线程。直接在主线程调用connect()会导致NetworkOnMainThreadException或者ANR（应用无响应）。项目APP里一定把连接逻辑放在子线程或者使用AsyncTask、Kotlin协程里，连接成功后通过Handler或runOnUiThread回到主线程更新UI。

5.2 协议解析与界面刷新：从字节流到实时数据卡片

APP端的核心逻辑代码其实不复杂，就是一个"字节流解析器"。按第3章说的帧格式，APP端每收到一帧数据，按类型字段分发到不同的UI元素上更新显示。

解析代码大概长这样：

// 假设已经有一个byte[] buffer，解析其中的帧 int i = 0; while (i < buffer.length - 1) { if (buffer[i] == (byte)0xAA && buffer[i+1] == (byte)0x55) { // 找到帧头 int length = buffer[i+2] & 0xFF; if (i + length + 4 < buffer.length) { byte type = buffer[i+3]; int value = ((buffer[i+4] & 0xFF) << 8) | (buffer[i+5] & 0xFF); byte checksum = calculateChecksum(buffer, i, i + length); if (checksum == buffer[i + length + 1]) { // 校验通过，刷新UI switch (type) { case 0x01: heartRateText.setText(value + " bpm"); break; case 0x02: spo2Text.setText(value + " %"); break; case 0x03: tempText.setText(String.format("%.1f ℃", value / 10.0)); break; case 0x04: stepText.setText(value + " 步"); break; } i += length + 4; continue; } } } i++; }

UI设计上，我建议至少包含四个实时数据卡片：心率、血氧、体温、步数，再加上一个连接状态栏和一条实时波形曲线（有心率波形显示的项目观感会好很多，演示时特别加分）。波形曲线的数据源就是MAX30102的PPG原始数据，需要在协议帧中额外增加一个"原始波形"数据类型，APP端用一个自绘View或LineChart控件来画。

5.3 异常阈值告警：让手环"有用"而不是"白做"

一个只显示数据的健康手环，做完之后很容易被问"那它到底有什么用"。增加异常阈值告警功能，是整个项目从"数据采集器"升级成"健康监测设备"的关键一步。

实现思路很简单：APP端在每次解析到新数据后，拿数值和预设的阈值区间做比较：

• 心率：正常范围通常取60~100bpm，低于50或高于120触发提醒（静息状态下）
• 血氧：正常SpO2应高于95%，低于94%需要提示
• 体温：体表温度参考范围35.5℃~37.5℃

当某项指标超出阈值时，APP弹出一个通知（Notification）或者切换界面卡片的高亮颜色，同时可以发出蜂鸣声或震动。代码上只需要在收到有效帧时加一个if判断即可：

if (heartRate > 120 || heartRate < 50) { alertTextView.setText("心率异常！请休息并复查"); alertLayout.setBackgroundColor(Color.RED); } else { alertTextView.setText("心率正常"); alertLayout.setBackgroundColor(Color.GREEN); }

这个功能如果在做课程设计答辩时演示，效果会非常直观——用手用力按压传感器，让心率读数迅速飙升，系统立刻弹出"心率异常"的告警，评委一眼就能看懂整个项目做了什么。我个人觉得这比单纯展示一堆数字要有说服力得多。

6. 系统联调时的故障排查清单与实战经验

6.1 常见问题对照表：现象、原因与解决方向

整套系统联调时，我把高频故障整理成一张排查表，直接对照操作就行：

这张表基本覆盖了我在开发过程中遇到的所有问题，如果你按照表里的顺序排查，90%的异常都能定位到具体环节。

6.2 我调试这个项目时的几点体会

最后分享几条在实操中沉淀下来的经验，都是文档里不会写但很实用的东西。

第一，务必按模块分步调试，不要一股脑把全部代码烧进去然后期望它一次跑通。建议调试顺序是：OLED显示 → DS18B20温度 → MAX30102波形 → 蓝牙透传 → APP联调。每一步调通后再叠加上一步。如果直接全套上，任何一个环节出问题你都很难判断是哪个模块的锅。我见过太多人把代码烧进去后屏幕亮了、蓝牙也能连，但APP上显示的温度是85℃、心率是恒定的0，然后不知道从哪里开始排查。分步调试看起来慢，实际上才是最快的。

第二，善用串口打印调试信息。在STM32端通过USART2打印关键变量（比如每个传感器的原始值、协议帧的序列号），连接电脑串口工具实时查看，能帮你在没有屏幕的情况下快速定位问题。尤其是在蓝牙模块联调时，先在串口端确认数据帧格式正确，再排查无线传输环节，效率翻倍。

第三，MAX30102的数据要用心率波形的"形态"来判断是否正常，而不是只看算出来的数值。如果你在串口工具里打印PPG原始数据并画出波形，应该能看到类似于心电图那样规律的起伏。如果波形是一条水平线，说明传感器没采到有效信号；如果波形很密集但振幅很小，说明手指贴合位置或者LED电流需要调整；如果波形不规则、忽高忽低，说明身体在晃动或者环境光干扰严重。学会观察波形形态，比盯着计算出来的心率数值更有判断力。

第四，安卓APP的蓝牙权限适配要提前想好。很多人的项目在演示的时候，借来的手机是安卓14系统，结果APP装上去能打开但搜索不到任何设备——不是代码逻辑问题，是权限弹窗没处理或者BLE扫描限制。我建议在做APP时，把权限逻辑做成启动页引导式的：APP启动后先检查蓝牙权限和定位权限，缺失就弹窗申请，拒绝的话再次提醒，直到用户授权为止。这样不管谁来演示，只要点几个"允许"就能正常连接设备。

第五，也是我最大的体会：这个项目的核心价值不在MCU代码本身，而在于打通"采集→传输→展示→告警"这条完整链路后的系统思维。你会发现在这个过程中，每一个环节的坑都是独立的，但它们彼此耦合——电源不稳会导致传感器读数跳变，传感器读数跳变会导致APP误报警，APP误报警又会让演示效果大打折扣。真正把整个链路稳定下来，需要对每一个环节的原理都有足够的理解，这种"全链路思维"正是物联网开发最重要的能力。做好这个手环，等于把嵌入式、蓝牙通信、安卓应用开发三块技能都过了一遍，这个积累比项目本身的代码量值钱得多。

本文还有配套的精品资源，点击获取