第三章 UHF RFID协议解析：ISO 18000-6C协议栈、Q协议、盘点流程详解
各位同学，今天我们来啃一块硬骨头——UHF RFID的协议栈。说实话，刚入行那会儿，我看着ISO 18000-6C的协议文档，头都大了。几百页的英文规范，各种时序图、状态机，看得人想摔键盘。但后来我发现，只要抓住几个核心点，这东西其实没那么玄乎。
咱们今天就把ISO 18000-6C协议栈、Q协议和盘点流程这三块，掰开了揉碎了讲清楚。我保证，听完这节课，你至少能看懂读写器和标签之间的“对话”了。
3.1 ISO 18000-6C协议栈长什么样？
ISO 18000-6C，很多人也叫它EPC Class 1 Gen 2。这两个名字其实是一回事，只是出身不同。ISO是国际标准组织给的编号，EPCglobal是行业联盟的叫法。你出去面试，说哪个都行，但最好两个都知道。
这个协议栈，说白了就是定义了读写器和标签之间怎么“说话”。它分三层：
- 物理层（Physical Layer）：管信号的调制、编码、速率这些底层东西。比如它规定用DSB-ASK、SSB-ASK或PR-ASK调制，数据速率可以从40kbps到640kbps。嗯，这里要注意，速率越高，通信距离通常越短，这是个取舍。
- 标签标识层（Tag Identification Layer）：这是核心层，管盘点、读写、访问这些操作。我们今天重点讲的Q协议和盘点流程，就在这一层。
- 会话层（Session Layer）：管多个读写器同时工作时怎么不打架。它定义了S0、S1、S2、S3四个会话，还有SL（Selected）标志。我刚开始做多读写器项目时，就是没处理好会话冲突，导致标签反复被盘点，效率极低。
核心要点：ISO 18000-6C协议栈是读写器和标签之间的“通信规则”。物理层管“怎么传”，标签标识层管“传什么”，会话层管“谁先传”。
3.2 Q协议——防碰撞的核心机制
好，接下来咱们聊聊Q协议。这是UHF RFID里最巧妙的设计之一。你想想看，一个读写器发个命令，周围几百个标签同时响应，那不就乱套了吗？Q协议就是用来解决这个问题的。
Q协议本质上是一种时隙ALOHA算法。读写器先告诉标签：“我给你们分了2^Q个时隙，你们随机选一个回复。”Q值越大，时隙越多，碰撞概率越低，但盘点时间也越长。Q值越小，时隙越少，盘点快但容易撞车。
我记得有一次在仓库做测试，现场有5000多个标签。我一开始设Q=8，结果碰撞率高达40%，盘点一圈要3分钟。后来我把Q调到15，碰撞率降到5%以下，但时间也涨到了8分钟。这就是典型的trade-off。
Q协议的工作流程是这样的：
- 读写器发送Query命令，里面包含Q值。所有标签收到后，在0到2^Q-1之间随机生成一个时隙号。
- 时隙号为0的标签，立即回复RN16（一个16位的随机数）。
- 读写器收到RN16后，发送ACK命令确认。标签收到ACK后，回复EPC数据。
- 如果多个标签同时回复，就会发生碰撞。读写器检测到碰撞后，发送QueryRep命令，让所有标签的时隙号减1。
- 时隙号减到0的标签，再次尝试回复。如此循环，直到所有标签都被盘点完。
避坑指南：我曾经遇到过一个坑——Q值动态调整的时机。有些读写器在碰撞发生后立即增大Q值，这其实不对。正确的做法是：先统计空时隙、成功时隙和碰撞时隙的比例，再决定是否调整Q值。我后来写了个自适应Q值算法，效果比固定Q值好很多。
Q值的动态调整，业内常用的方法是Q-adaptive算法。简单说就是：
- 如果碰撞时隙太多（比如超过50%），Q值加1，增加时隙数。
- 如果空时隙太多（比如超过60%），Q值减1，减少时隙数。
- 如果成功时隙比例合适（30%-40%左右），保持Q值不变。
这个算法说起来简单，但实际调参很考验经验。我建议你在项目初期先用固定Q值跑通流程，再慢慢优化动态调整策略。
3.3 盘点流程详解——从Query到ACK
好了，现在我们把整个盘点流程串起来。一个完整的盘点周期，大概分这么几步：
| 步骤 | 命令 | 方向 | 说明 |
|---|---|---|---|
| 1 | Select | 读写器→标签 | 选择要盘点的标签群体（可选） |
| 2 | Query | 读写器→标签 | 启动盘点周期，指定Q值 |
| 3 | RN16 | 标签→读写器 | 时隙号为0的标签回复16位随机数 |
| 4 | ACK | 读写器→标签 | 确认收到RN16，要求回复EPC |
| 5 | EPC数据 | 标签→读写器 | 标签回复EPC码（96位或更长） |
| 6 | QueryRep | 读写器→标签 | 时隙号减1，继续下一轮 |
你可能会问：“为什么要有RN16这一步？直接回复EPC不行吗？”
嗯，这个问题问得好。RN16的作用是防冲突确认。你想啊，EPC数据有96位甚至更长，如果多个标签同时回复，碰撞后整个数据都废了。而RN16只有16位，碰撞后损失小，重传成本也低。读写器先确认RN16没碰撞，再让标签回复EPC，这样效率高得多。
我做过一个测试：在密集标签环境下，有RN16机制的盘点成功率比没有的高出30%以上。所以别小看这16位随机数，它是整个协议的精妙之处。
注意事项：盘点过程中，读写器必须严格遵守时序要求。比如Query命令发出后，标签需要在T1时间内回复RN16。T1的值取决于读写器到标签的距离，一般几十微秒。如果读写器超时等待时间设置不对，要么漏掉标签，要么误判碰撞。我建议你留出20%的余量。
3.4 实战经验：盘点参数怎么调？
最后，我分享几个实际项目中的调参经验。这些参数直接影响盘点性能：
- Q值初始值：如果标签数量未知，我习惯从Q=8开始。如果已知标签很多（比如上千个），直接设Q=12以上。
- Session选择：单读写器场景用S0就够了。多读写器场景，建议用S1或S2，配合SL标志使用。
- Select命令：如果只需要盘点特定区域的标签，先用Select命令过滤，能大幅减少无效标签的干扰。
- 功率设置：别一上来就开最大功率。我见过有人把功率调到30dBm，结果标签过饱和，反而读不到。从20dBm开始，逐步增加，找到最佳点。
好了，关于ISO 18000-6C协议栈、Q协议和盘点流程，今天就讲这么多。下一节课，我们会深入标签的存储结构和访问命令，到时候你会看到更多有意思的细节。记住，协议这东西，光看文档是不够的，一定要动手写代码、跑测试。我当年也是踩了无数坑，才慢慢摸出门道的。