灯光控制器的比较测试
作者:Kate 发布时间:2024-02-20 栏目: 理财课堂 0浏览
因项目需要，测试了两家的几款灯光控制器，都是rs232串口程序控制的。测试方法可供参考。
图：测试的控制器
测试目的及方法
因为项目上碰到的坑，本测试主要关心速度方面的。包括：
测试方法：
图：测试环境
传感器使用硅光电池。其响应时间估计在微秒级，对这个测试是足够快的。
图：硅光电池
本测试的示波器截图中，绿色通道表示发出串口命令的时间，高电平为开（on），低电平为关（off）。黄色通道为硅光电池的电压。
响应延迟
灯亮时亮度都设为50(最大值都是255); 灯灭时亮度设为0(h款没有关的功能）或直接对应于关（l款）。
l款：实测在约10-12ms后灯光会亮，灯光灭的动作虽然也是从10-12秒开始，但灯灭的反应不是那么陡峭，大概需要18ms才能完全熄灭。
l款的命令是8个字节。9600的波特率传输8个字符理论上也需要约7ms. 所以这个延迟属于一个合理的水平（为了测试速度的极限值，测试程序并没有读控制器的回应；如果回读，会慢不少）。
图：开和关的响应延迟（l款）
h款的响应延迟在50ms左右，要等亮度稳定下来，极端情况下要超过60ms。同样也是灯灭花的时间更多。
图：开和关的响应延迟（h款）
厂家说在完全关和亮之间切换，花的时间会比较多，多于亮度变化的时间。下图是用最低亮度1作为“关”进行的测试。可以看到改善并不显著，亮的时间少了约10ms，但暗下来的时间多了约20ms.
图：开和暗的响应延迟（h款）
最小命令间隔
不断缩小发送命令的间隔，可以看到变化。
比如，下图是l款12ms，可以看到基本是正常的。
图：命令间隔12ms（l款）
当间隔减至11ms时，从波形上可以看到有的命令来不及处理。肉眼也可看到闪烁节奏的偶尔变化。
图：命令间隔11ms（l款）
这说明对于l款，12ms是最小的命令间隔。这个值和前面测的响应延迟基本相当。
下面是h款的，50ms基本正常，
图：命令间隔50ms（h款）
40ms时，命令看起来没有遗漏。但有些在没有完全灭时就开始下一个周期了。
图：命令间隔40ms（h款）
30ms时，命令应该也没有遗漏，但灯基本上没有灭下来。
图：命令间隔30ms（h款）
所以对于h款，比较安全的命令间隔还是应该在50ms以上。
灯光频闪
前面的波形中可以看到，对于l款，高电平（即灯亮的时候）特别粗。其实这是因为灯光有频闪。我们可以顺便测试一下。
方法很简单，将灯打到常开，用示波器的更高档查看其波形的交流分量。可以看到频闪频率大约90khz。这对调光led是一个正常的水平。
图：l款灯光频闪（亮度50）
对于h款，则没有频闪。这可能是因为它用的恒流驱动模式。
图：h款灯光无频闪（绿色是树莓派低电平）
作为对比，绿色线是树莓派gpio的低电平，可以看到其噪声的大小。而灯光的波动比它小得多，可见灯光控制器电源和驱动还是不错的。
测试程序
测试程序放在github上：https://github.com/loblab/lightctrl
在python环境下运行。测命令延迟需要一个电平作为对比，所以用了树莓派。除此之外，其它测试其实是可以在pc上完成的。
图：测试程序
小结
本文对容易被忽视的rs232灯光控制器的程控速度和响应做了定量的测试。命令响应延迟和连续命令的最小间隔基本上相当。
l款的表现属于正常水平，也符合串口通讯的中端定位（更快的可能要使用网络接口了）。
h款的电源和灯光驱动做得不错，完全无频闪。但通讯和处理速度上太慢（波特率9600的款更慢）。基本上只能用在低速切换的场合。但这产品定位就有点矛盾。无频闪固然好，但对于非超高速摄影（一般拍照，ms级曝光时间），90khz的频闪是完全够用的（原因可见前文：用相机定量检测灯光的频闪）。
另外，h款的串口接口用目前通用的usb转串口线不能连接（因为rx和tx反了）。l款的可以直接用。尽管rs232的rx和tx也是挺混乱的，但目前市场上的主流线缆也是一种事实标准，和它匹配会比较方便。还有，l款使用数显和数调，程控和手动是完全同步的，而h款还是多旋钮的方式。两种方式各有利弊，但数显数调更符合潮流一些。
综上，感觉h家的这款产品在接口和通讯上比同类产品落后了一代。希望厂家能及时改善，与时俱进，提升产品竞争力。
