因项目需要，测试了两家的几款灯光控制器，都是rs232串口程序控制的。测试方法可供参考。

710 >

图：测试的控制器

测试目的及方法

因为项目上碰到的坑，本测试主要关心速度方面的。包括：

测试方法：

710 >

图：测试环境

传感器使用硅光电池。其响应时间估计在微秒级，对这个测试是足够快的。

710 >

图：硅光电池

本测试的示波器截图中，绿色通道表示发出串口命令的时间，高电平为开（on），低电平为关（off）。黄色通道为硅光电池的电压。

响应延迟

灯亮时亮度都设为50(最大值都是255); 灯灭时亮度设为0(h款没有关的功能）或直接对应于关（l款）。

l款：实测在约10-12ms后灯光会亮，灯光灭的动作虽然也是从10-12秒开始，但灯灭的反应不是那么陡峭，大概需要18ms才能完全熄灭。

l款的命令是8个字节。9的波特率传输8个字符理论上也需要约7ms. 所以这个延迟属于一个合理的水平（为了测试速度的极限值，测试程序并没有读控制器的回应；如果回读，会慢不少）。

710 >

图：开和关的响应延迟（l款）

h款的响应延迟在50ms左右，要等亮度稳定下来，极端情况下要超过60ms。同样也是灯灭花的时间更多。

710 >

图：开和关的响应延迟（h款）

厂家说在完全关和亮之间切换，花的时间会比较多，多于亮度变化的时间。下图是用最低亮度1作为“关”进行的测试。可以看到改善并不显著，亮的时间少了约10ms，但暗下来的时间多了约20ms.

710 >

图：开和暗的响应延迟（h款）

最小命令间隔

不断缩小发送命令的间隔，可以看到变化。

比如，下图是l款12ms，可以看到基本是正常的。

710 >

图：命令间隔12ms（l款）

当间隔减至11ms时，从波形上可以看到有的命令来不及处理。肉眼也可看到闪烁节奏的偶尔变化。

710 >

图：命令间隔11ms（l款）

这说明对于l款，12ms是最小的命令间隔。这个值和前面测的响应延迟基本相当。

下面是h款的，50ms基本正常，

710 >

图：命令间隔50ms（h款）

40ms时，命令看起来没有遗漏。但有些在没有完全灭时就开始下一个周期了。

710 >

图：命令间隔40ms（h款）

30ms时，命令应该也没有遗漏，但灯基本上没有灭下来。

710 >

图：命令间隔30ms（h款）

所以对于h款，比较安全的命令间隔还是应该在50ms以上。

灯光频闪

前面的波形中可以看到，对于l款，高电平（即灯亮的时候）特别粗。其实这是因为灯光有频闪。我们可以顺便测试一下。

方法很简单，将灯打到常开，用示波器的更高档查看其波形的交流分量。可以看到频闪频率大约90khz。这对调光led是一个正常的水平。

710 >

图：l款灯光频闪（亮度50）

对于h款，则没有频闪。这可能是因为它用的恒流驱动模式。

710 >

图：h款灯光无频闪（绿色是树莓派低电平）

作为对比，绿色线是树莓派gpio的低电平，可以看到其噪声的大小。而灯光的波动比它小得多，可见灯光控制器电源和驱动还是不错的。

测试程序

测试程序放在github上：github.com/loblab/lightctrl

在python环境下运行。测命令延迟需要一个电平作为对比，所以用了树莓派。除此之外，其它测试其实是可以在pc上完成的。

710 >

图：测试程序

小结

本文对容易被忽视的rs232灯光控制器的程控速度和响应做了定量的测试。命令响应延迟和连续命令的最小间隔基本上相当。

l款的表现属于正常水平，也符合串口通讯的中端定位（更快的可能要使用网络接口了）。

h款的电源和灯光驱动做得不错，完全无频闪。但通讯和处理速度上太慢（波特率9的款更慢）。基本上只能用在低速切换的场合。但这产品定位就有点矛盾。无频闪固然好，但对于非超高速摄影（一般拍照，ms级曝光时间），90khz的频闪是完全够用的（原因可见前文：用相机定量检测灯光的频闪）。

另外，h款的串口接口用目前通用的usb转串口线不能连接（因为rx和tx反了）。l款的可以直接用。尽管rs232的rx和tx也是挺混乱的，但目前市场上的主流线缆也是一种事实标准，和它匹配会比较方便。还有，l款使用数显和数调，程控和手动是完全同步的，而h款还是多旋钮的方式。两种方式各有利弊，但数显数调更符合潮流一些。

以上是网络信息转载，信息真实性自行斟酌。