sACN 包有 Sync Address 就一定同步吗：怎样核对包头与实现能力

sACN数据包出现Synchronization Address或Force Synchronization位，只能证明字段存在，不能证明接收软件已经实现并启用同步。需要同时核对发送、接收两端能力及对应同步包的处理证据；仅凭配置窗口一个数字不能给出同步精度结论。

先固定输入与适用条件

本题只做字段清点和实现能力记录，使用同步地址零或一百、Force位关闭或开启四种组合。固定ETC sACN v2.0.2源代码中，同步相关宏及字段处理存在TODO，因此不能拿它的常量定义宣称该版本已完成同步发送或调度。

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. 保存原始数据包中的同步地址与Options，区分字段为零、非零及Force位是否置位。字段解析与执行能力分成两列，避免“能识别”被误写为“会执行”。

2. 查目标发送端是否真的产生规范要求的同步数据，接收端是否声明处理，以及软件版本。未知项写待核验，不用另一产品支持情况代替。

3. 对照固定实现源码，明确标出尚未实现的路径。本例只借常量验证位提取，不运行该库，也不依据TODO之外猜测其运行行为。

4. 若目标项目确需同步，再按所用E1.31版次与设备手册设计完整测试。记录内容帧、接收更新、物理输出的观察点，不能把数据包到达同时等同最终灯光同时。

用具体样例核对结果

附件四行组合都可以提取地址与Force位，但can_assume_synchronization始终为假，因为没有提供两端支持和同步包证据。地址零且Force置位的组合单独要求复核，不在缺少完整规范与实现证据时自造调度结果。脚本仅序列化字段，没有发包、等待或操作设备。

通过条件是字段值未丢失、每一项能力都有来源、未知未被自动当成支持。本地解析成功不代表流正在受同步包控制，也不意味着多个Universe会按同一时刻输出。现行2025版与旧实现的关系应按设备声明确认；本文不会把2018兼容子集写成2025全功能认证，更不会从常量0x20推导某一同步误差上限。

下载与复现

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

input是四组字段，result给出能力缺口清单。用于工程评审时，把设备与软件支持证明另存附件，并标出测量方法；当前报告只足以决定还缺什么证据，不能代替完整同步验收。

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

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

对接下一步与一级来源

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

• Force Sync常量与尚未实现的宏。
• 同步地址解析标记TODO。

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