4. 通信协议栈架构：OSI模型在TPMS中的应用
做射频通信这么多年，我越来越觉得，搞懂协议栈比调天线还重要。天线调不好，顶多是距离近点；协议栈设计不好，整个系统可能直接瘫痪。今天咱们就聊聊TPMS里的协议栈架构，看看OSI模型怎么落地到胎压监测上。
4.1 OSI模型在TPMS中的实际映射
OSI七层模型，教科书上讲得很清楚。但说实话，在TPMS这种资源受限的系统里，我们不会真的搞七层。我习惯把它压缩成四层：物理层、数据链路层、网络层和应用层。会话层和表示层？嗯，在TPMS里基本用不上，直接合并到应用层处理了。
| OSI模型 | TPMS协议栈 | 主要职责 |
|---|---|---|
| 应用层 | 应用层 | 数据解析、报警策略、ID管理 |
| 表示层 | 数据编码、加密（可选） | |
| 会话层 | 通信会话管理（TPMS通常无会话） | |
| 传输层 | 网络层 | 数据包路由、重传机制 |
| 网络层 | 地址分配、网络拓扑管理 | |
| 数据链路层 | 数据链路层 | 帧结构、CRC校验、冲突避免 |
| 物理层 | 物理层 | 调制方式、频率选择、发射功率 |
你看这个表格，TPMS的协议栈其实很精简。为什么？因为传感器节点就那么点资源——8位MCU、几KB的RAM、纽扣电池供电。你让它跑完整的TCP/IP协议栈？不现实。
4.2 物理层：信号从天线到比特
物理层是协议栈的最底层，也是最容易被忽视的一层。很多工程师上来就写代码，结果发现通信距离不够，回头才发现是物理层参数没选对。
频率选择：TPMS主流用315MHz（北美）和433.92MHz（欧洲/亚洲）。我个人偏好433MHz，因为波长更短，天线可以做得更小。但要注意，433MHz频段干扰也多——遥控器、车库门、甚至一些工业设备都在用。
调制方式：OOK（开关键控）和FSK（频移键控）是两大主流。OOK简单省电，但抗干扰差。FSK可靠性高，但功耗稍大。我建议：
- 电池寿命优先 → 用OOK，占空比控制在1%以内
- 可靠性优先 → 用FSK，牺牲一点功耗换稳定性
关键参数速查表
| 参数 | 典型值 | 说明 |
|---|---|---|
| 中心频率 | 433.92 MHz | ISM频段，免授权 |
| 调制方式 | FSK | 频偏 ±20~50 kHz |
| 数据速率 | 9.6 kbps / 19.2 kbps | 低速但可靠 |
| 发射功率 | +10 dBm (10 mW) | 法规限制，不可超过 |
| 接收灵敏度 | -110 dBm | 典型接收机指标 |
我曾经在一个项目里，为了省电把发射功率降到+5 dBm，结果停车场里死活收不到信号。后来发现是轮胎被金属轮毂遮挡，信号衰减太厉害。从那以后，我坚持用+10 dBm，配合良好的天线匹配，再没出过问题。
4.3 数据链路层：帧结构设计
数据链路层负责把物理层的比特流组织成有意义的帧。说白了，就是告诉接收端：「嘿，我要开始发数据了，这是格式，请按这个解析。」
一个典型的TPMS数据帧长这样：
| 前导码 (4字节) | 同步字 (2字节) | 帧头 (1字节) | 数据载荷 (8字节) | CRC (2字节) |
| 0xAAAAAAAA | 0x2DD4 | 0x01 | 压力+温度+ID... | 0x3A5C |各字段说明：
- 前导码：一串交替的0和1，帮助接收机锁定时钟。我习惯用4字节的0xAA，足够让接收机稳定下来。
- 同步字：一个特殊码字，告诉接收机「帧头要来了」。0x2DD4是我常用的，自相关性好，误检率低。
- 帧头：包含帧类型、长度、序列号等信息。1字节就够了，别浪费。
- 数据载荷：真正的胎压数据。8字节可以包含：轮胎ID（4字节）、压力（2字节）、温度（1字节）、状态（1字节）。
- CRC：循环冗余校验。2字节的CRC-16，足以检测常见错误。
避坑指南：我曾经见过一个团队，前导码只用了2字节，结果在强干扰环境下接收机频繁失锁。后来改成4字节，问题解决。记住：前导码不是越短越好，要给接收机足够的同步时间。
4.4 网络层：地址与路由
网络层在TPMS里相对简单，但绝不是可有可无。它主要解决两个问题：
- 地址分配：每个传感器需要一个唯一ID。我建议用4字节的ID，前2字节是厂商代码，后2字节是产品序列号。这样即使不同厂商的传感器混用，也不会冲突。
- 网络拓扑：TPMS通常是星型拓扑——传感器直接发给接收机，不经过中继。但有些大型车辆（卡车、大巴）需要中继器，这时候网络层就要处理多跳路由。
你想想看，一辆卡车有22个轮胎，每个轮胎一个传感器，再加上挂车的，可能超过30个节点。如果没有合理的网络层管理，接收机根本分不清哪个传感器对应哪个轮胎。
我习惯的做法是：在数据载荷里嵌入轮胎位置编码。比如：
位置编码：0x01 = 左前轮，0x02 = 右前轮，0x03 = 左后轮内，0x04 = 左后轮外...这样接收机收到数据后，直接根据位置编码就知道是哪个轮胎，不需要额外的路由表。
4.5 应用层：数据解析与报警
应用层是离用户最近的一层。物理层、链路层、网络层搞定了数据传输，应用层负责让数据变得有意义。
数据解析：原始数据是二进制，应用层要把它转换成可读的物理量。比如：
原始压力值：0x01F4
转换公式：压力(kPa) = 原始值 × 0.1 + 50
计算结果：0x01F4 = 500 → 500 × 0.1 + 50 = 100 kPa报警策略：这是应用层的核心。我一般设置三级报警：
- 低压报警：低于标准胎压的75%，持续3秒
- 高压报警：高于标准胎压的125%，持续3秒
- 快速漏气报警：1秒内压力下降超过30 kPa
经验之谈：报警阈值不要设得太死。我见过一个项目，低压报警设成80%，结果冬天温度下降，胎压自然降低，天天误报警。后来改成75%，配合温度补偿，误报率降了90%。
4.6 协议栈分层设计原则
分层设计不是学院派的空谈，它解决的是实际问题。我总结了几条原则：
- 层间接口要清晰：每层只暴露必要的API。比如物理层只提供「发送字节」和「接收字节」两个接口，上层不用关心调制方式。
- 层内高内聚：CRC校验只在数据链路层做，应用层不要重复校验。我曾经见过一个代码，链路层做了CRC，应用层又做了一次，白白浪费CPU和电池。
- 层间低耦合：修改物理层（比如从OOK改成FSK），不影响上层代码。这是分层最大的好处。
- 资源适配：TPMS资源有限，分层不能太细。我见过有人硬套OSI七层，结果代码体积膨胀了3倍，8KB的Flash根本装不下。
说白了，分层设计就像盖房子——地基、框架、水电、装修各司其职。地基坏了不会影响装修，装修改了也不用拆地基。TPMS协议栈也是一样，物理层换了，应用层代码不用动，这才是好的设计。
嗯，这一章内容不少。下一章咱们会深入物理层，聊聊天线匹配和阻抗调谐，那才是真正考验功力的地方。