最近在做一个产品的BUG调查，在修复Bug时，有一些思维方法上的碰撞，记录之。
有一个远程NAC模块，支持1-4个NAC电路。每一个路可以接几十个不同厂商的NAC设备。这个远程NAC模块用于输出标准所要求的Pattern. 标准要求不同NAC设备输出声音，闪光都要同步。远程NAC可以接到不同的主控制器(系统)上。
问题1: 输出闪光不同步。根据要求，各个NAC输出的闪光都要在10ms内，两次闪光间隔不能超过1s。
调查发现，每一pattern周期有4个小周期， 主控制器会在第一小周期内以广播的消息给所有远程NAC发送同步指令。同步指令包括了时间戳。但是这个时间戳是以10ms为单位的。而在远程NAC的输出标准值是990ms, 那么只要控制不好，非常容易就超出1s。也就不满足标准。
这主要是原来的设计没有考虑好，这个同步的时间的精度是不够的。在解决方案的讨论中，由于涉及多种主控制器，而且做认证比较麻烦，所以放弃在主控制器上改动。一个建议是，在远程NAC根据自己的时间轴和不同时间落差进行微调，这个当然能够实现，但同样得问题，这个时间轴是自己，单是另外一个远程NAC的时间轴是不一样的，从概率上来说还是有很大可能不同步的。另外一个建议把这同步时间平均分配到4个小周期内，而不是只对第一个小周期进行同步。完美的解决问题。
问题2: 连接到主控制器A时，经常发现“Group”命令无法收到。
调查发现这是主控制器A的问题。主控制器上电时就给远程NAC发送”Group”的命令，但是自己的软件逻辑出了问题，导致发送失败。 涉及认证的问题，主控制器的软件不能改。而且远程NAC可以连接不同的主控制器，这个”group”的值是不同的。方案只能在远程NAC上进行改动。改动方法就是让远程NAC的默认”group”设置为主控制器A的”group”. 好彩的事这个”group”对于某一种主控制器来说是不会变得。