智能手表项目开发日志 003：计步和报警，真正考验的是边界条件

计步不能只看一次加速度

如果每次加速度超过阈值就加一步，手表稍微晃动一下就会出现错误计步。我们采用了更简单但更可靠的边沿判断：先计算三轴加速度平方和，减少开方带来的计算开销；再将结果和阈值比较，只有从“低于阈值”进入“高于阈值”的上升沿时才增加步数。

代码中的 step_detect() 使用 above 记录上一次是否处于高位，使用 quiet 记录连续低于阈值的次数。这样一次摆动不会在高位持续期间重复计数，信号回落后才能重新等待下一次上升沿。

参数必须和真实佩戴场景一起调

当前实现把原始加速度阈值设为 3000，并保留了滤波长度、采样周期和静默计数等参数。它们不是脱离硬件就能确定的常数：手表佩戴在手腕、放在桌面或拿在手里时，运动幅度完全不同。

所以这一阶段的重点不是宣称算法已经达到产品级精度，而是先建立可调参数和可观察输出。通过串口打印加速度和步数，可以快速判断是阈值过低导致误计步，还是阈值过高导致漏计步，再结合真实动作逐步校准。

温度报警要避免反复响

设备读取线程将 30℃作为当前高温判断阈值。当温度超过阈值时，系统调用 alarm_mode1()，让蜂鸣器和灯光持续提示 10 秒。为了避免每次循环都重复触发，代码使用 status_tempalarm 作为开关：报警触发后先关闭状态，只有通过云端命令重新打开，才会允许下一次报警。

这是一种很实用的原型设计。报警不只是“判断条件成立就响”，还需要记录已经处理过的状态，否则设备会在每轮采样里不断重复执行报警动作。

久坐提醒是另一个时间问题

久坐线程每隔 60 秒比较前后步数，当步数变化不超过 5 步时触发间歇提醒。alarm_mode2() 通过蜂鸣器和 RGB 灯交替开关，持续一段时间后自动结束。

这里还存在一个产品层面的取舍：提醒阈值不能过于敏感，否则用户只是安静阅读几分钟也会被打扰；阈值过于宽松，又失去了健康提醒的意义。当前实现先把检测、提示和开关控制链路跑通，后续再通过真实使用数据调整时间窗口和步数差阈值。

阶段结果

这一阶段让“传感数据”变成了“可以被用户感知的行为”：步数会刷新，温度过高会报警，长时间不活动会提醒，云端还可以控制这些功能的开关。下一阶段将把设备交互继续扩展到非接触式 NFC 和语音控制，让同一套状态模型支持更多输入方式。