4. 协议栈优化：MAC层参数调优与调度策略
UWB的功耗问题，很多时候不是硬件不行，而是协议栈没用好。我见过不少团队，硬件选型没问题，天线匹配也做了，但功耗就是降不下来。一查，发现MAC层参数全是默认值，调度策略也没动过。说白了，就是软件没跟上硬件的节奏。
这一章，我们重点聊MAC层的几个关键参数：数据速率、包长度、重传机制，还有调度策略和监听唤醒的优化。这些都是我在实际项目中反复调过的东西，踩过坑，也填过坑。
4.1 数据速率：不是越快越好
很多人觉得，数据速率越高，传输时间越短，功耗自然就低了。这个逻辑没错，但有个前提——你得看链路预算。
UWB的数据速率和接收灵敏度是成反比的。速率越高，灵敏度越低，通信距离就短。如果你的应用场景是短距离（比如10米以内），那用高速率没问题。但如果是仓库定位、隧道巡检这种场景，高速率会导致重传率飙升，功耗反而更高。
关键结论：数据速率的选择，本质是“传输时间 vs 重传概率”的权衡。
我在一个物流分拣项目里遇到过这种情况。当时默认用了6.8 Mbps的速率，结果在金属货架密集的区域，丢包率接近15%。后来降到850 kbps，丢包率降到2%以下，虽然单次传输时间长了，但总功耗反而降了30%。
所以我的建议是：
- 短距离、低干扰场景（如室内桌面定位）：用6.8 Mbps或更高
- 中距离、多径严重场景（如仓库、车间）：用850 kbps或110 kbps
- 远距离、低功耗优先（如隧道、矿井）：用110 kbps，配合长前导码
4.2 包长度：短包不一定省电
包长度这个参数，很多人会忽略。直觉上，包越短，发送时间越短，功耗越低。但实际不是这样。
UWB的帧结构里，前导码和帧头是固定的开销。如果你把数据负载压得太短，那有效数据占比就低，相当于大部分能量都花在“传输开销”上了。
举个例子：
| 数据负载（字节） | 总帧长（μs） | 有效数据占比 | 每字节能耗（nJ） |
|---|---|---|---|
| 10 | 320 | 3.1% | 48 |
| 100 | 480 | 20.8% | 7.2 |
| 500 | 1200 | 41.7% | 3.6 |
看到没？10字节的包，每字节能耗是500字节的13倍。所以，如果你的应用允许，尽量把多个小数据合并成一个包发送。我习惯的做法是：在应用层做一个数据聚合缓冲区，攒够一定量再发。
小技巧：对于周期性上报的场景（如每100ms上报一次位置），可以把5-10次数据合并成一个包，每500ms发一次。这样功耗能降一半以上。
4.3 重传机制：别让重传变成“重灾区”
重传是功耗的隐形杀手。一次重传的能耗，相当于正常发送的2-3倍（因为还要监听ACK）。如果重传率超过10%，那功耗基本就失控了。
我见过最夸张的一个案例：某定位系统，重传率高达40%，电池续航从标称的3个月直接掉到2周。查到最后，发现是重传超时时间设得太短，导致大量不必要的重传。
关于重传，我有几个经验：
- 重传次数上限：建议设3次。超过3次还失败，说明信道条件太差，不如等下一个周期再试。
- 重传超时时间：不要用固定值。我习惯用“自适应超时”——根据最近几次的RTT（往返时间）动态调整。信道好的时候用短超时，信道差的时候自动延长。
- 指数退避：每次重传的等待时间翻倍。第一次等5ms，第二次等10ms，第三次等20ms。这样能避免多个设备同时重传造成碰撞。
注意：有些芯片的MAC层自带重传机制，但默认参数往往偏保守。一定要根据你的实际场景重新配置，不要偷懒用默认值。
4.4 调度策略：让设备“轮流说话”
在多设备场景下，调度策略直接影响功耗。如果所有设备都在同一时间争抢信道，那碰撞和重传就会急剧增加。
我常用的调度策略有两种：
- TDMA（时分多址）：每个设备分配一个固定的时隙，只在属于自己的时隙里发送数据。其他时间休眠。
- 轮询调度：由中心节点依次询问每个设备，设备收到询问后才回复。
这两种方式各有优劣：
| 策略 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| TDMA | 无碰撞，功耗可预测 | 时隙分配不灵活，扩展性差 | 设备数量固定、周期上报 |
| 轮询 | 灵活，支持动态加入 | 中心节点功耗高，有轮询延迟 | 设备数量少、事件触发 |
我个人更倾向于TDMA，尤其是设备数量在50个以内的场景。时隙长度可以根据每个设备的数据量动态调整，这样既保证了效率，又避免了浪费。
4.5 减少不必要的监听与唤醒
这是功耗优化里最容易被忽视的一环。很多设备的功耗大头，其实不在发送数据的时候，而是在“监听”和“等待”的时候。
UWB接收机的功耗通常比发射机低一些，但也不容小觑。如果设备一直处于监听状态，那功耗基本和连续接收差不多。
我的优化思路是：
- 占空比监听：不要一直监听，而是每隔一段时间醒来听一下。比如每100ms醒来听1ms，这样监听功耗就能降到原来的1%。
- 唤醒序列：在发送数据前，先发一个短的唤醒序列。设备平时处于深度休眠，只有检测到唤醒序列才会进入接收模式。
- 事件驱动：尽量让设备在“有事”的时候才工作，没事就休眠。比如定位标签，可以只在需要定位的时候才唤醒，平时完全休眠。
一个真实案例：我曾经优化过一个资产追踪系统，原来设备每100ms唤醒一次监听信标，功耗是2.5mA。后来改成每1秒唤醒一次，配合唤醒序列，功耗降到0.3mA。电池续航从2周延长到4个月。
4.6 知识体系总览
下面这张图，把MAC层优化的几个关键点串起来了。你可以把它当作一个检查清单，每次做功耗优化时对照着看。
4.7 实战建议：从哪开始调？
如果你现在面对一个功耗偏高的UWB系统，不知道从哪下手，我建议按这个顺序排查：
- 先看监听占空比：这是最容易出问题的地方。用示波器量一下设备唤醒的频率和时长，算一下实际占空比。
- 再看重传率：在log里统计重传次数。如果超过5%，优先优化数据速率和超时参数。
- 然后看包长度：检查应用层是不是在频繁发送小包。如果是，做数据聚合。
- 最后调调度策略：如果设备数量多，考虑从CSMA切换到TDMA。
我的习惯：每次只改一个参数，改完跑24小时测试，记录功耗和丢包率。不要一次性改多个参数，否则出了问题你根本不知道是哪个引起的。