sACN 只有 16 个灯光槽位，Property Value Count 为什么要填 17

sACN的Property Value Count包含Start Code，所以十六个灯光槽位对应计数十七。Start Code不是通道一；若把它漏算，后续槽位数或边界会偏一。校核时要注明偏移以整个UDP负载还是某一层PDU开头为原点。

先固定输入与适用条件

本例构造一个十六槽、Start Code为零的合成数据包，只检查计数和边界一致性。完整UDP负载的Property Value Count起点是123，Start Code在125，首个槽位在126；ETC局部解析函数使用Framing层相对偏移，不能直接照抄成整包位置。

Art-Net字段按官方4版Release V1.4、Revision 1.4dp核对。sACN例子限定ETC sACN v2.0.2所声明的E1.31-2018兼容字段及IPv4样本；现行ESTA目录已列E1.31-2025，2018亦含IPv6。本文不声称旧库实现新版全部功能。

按字段与边界执行

1. 先确认抓取的是完整UDP负载，记录总长度。若文件已经去掉Root或Framing层，应显式写出起始层，不能继续使用整包偏移。

2. 读取计数的两个大端字节，先验证至少能包含Start Code，再以减一得到槽位数。普通零Start Code的槽位含义与其他Start Code类型要分开。

3. 核对各层声明长度与实际负载边界，并确认最后槽位没有超出缓冲。本例采用严格相等检查，用来暴露计数与实际数据不一致的输入。

4. 生成count少一与负载截断反例，检查解析器输出拒绝原因。不要用补零让短包看起来完整，那会把缺失数据伪装成有效的零值。

用具体样例核对结果

正确包为126字节头部加16个槽位，总计142字节；计数17表示一个Start Code加16个值。附件同时生成计数16的错误包，以及删除末字节的截断包，严格校验只有正确包通过。结果保留每份完整hex和计数解读，不将本地最小校验器称为完整sACN协议栈。

通过条件是计数包含Start Code、槽位起点明确、实际数据量匹配。即使计数正确，还需其他PDU字段、源身份和接收策略都满足要求，才能讨论现场输出。这里不会把十六个槽位解释为十六盏灯，因为一盏灯可能占多个属性；灯具模式应由独立表格说明。

下载与复现

analyze.py、input.json、result.json。

下载的输入给出十六个已知值，解析器复现三种边界。交接时带上层级原点说明，比只写“偏移85”更可靠；抓包地址、真实CID与现场灯具表没有包含在本例。

把输入与脚本保存到同一个本地目录后执行 python analyze.py，脚本只读取输入、计算并重写同目录的结果文件。先保留原始附件副本，再将自己的脱敏输入另存为新版本，记录输入摘要与执行日期；不要把合成字段覆盖成看似真实的现场日志。

已用 Python 3.12.4 实际运行附件算法并检查断言。结果来自同目录合成输入；没有接入真实NDI源、控制器、灯具、接收卡或LED屏，不能据此填写现场验收通过。

对接下一步与一级来源

基础背景可看sACN（E1.31）灯光网络协议速查。相关流程收在展厅中控专题；需要项目对接时，带上本文输入及结果向SoftControl核对实际能力。

• 整包property count偏移及header长度。
• count含start code；解析时减1。

一级来源核对日期：2026-10-24。原始协议规则、本文原创运算和目标系统行为应分别留证；附件计算正确，不等于设备已经按该参数工作。