因项目需要，测试了两家的几款灯光控制器，都是RS232串口程序控制的。测试方法可供参考。
- L款：厂家L，波特率9600, 2通道
- H款：厂家H，波特率115200, 8通道和4通道
测试目的及方法
因为项目上碰到的坑，本测试主要关心速度方面的。包括：
- 控制器响应延迟：即发出或收到命令（开和关）到灯光实际反应（亮和灭）的时间滞后；
- 控制器连续处理两条命令的最小间隔时间。
- 顺便简单测了下频闪。
测试方法：
- 循环发送开和关的命令；
- 发送命令的同时通过树莓派GPIO给出一个电平信号；
- 用光电传感器和示波器跟踪查看灯光的反应。
传感器使用硅光电池。其响应时间估计在微秒级，对这个测试是足够快的。
本测试的示波器截图中，绿色通道表示发出串口命令的时间，高电平为开（on），低电平为关（off）。黄色通道为硅光电池的电压。
响应延迟
灯亮时亮度都设为50(最大值都是255); 灯灭时亮度设为0(H款没有关的功能）或直接对应于关（L款）。
L款：实测在约10-12ms后灯光会亮，灯光灭的动作虽然也是从10-12秒开始，但灯灭的反应不是那么陡峭，大概需要18ms才能完全熄灭。
L款的命令是8个字节。9600的波特率传输8个字符理论上也需要约7ms. 所以这个延迟属于一个合理的水平（为了测试速度的极限值，测试程序并没有读控制器的回应；如果回读，会慢不少）。
H款的响应延迟在50ms左右，要等亮度稳定下来，极端情况下要超过60ms。同样也是灯灭花的时间更多。
厂家说在完全关和亮之间切换，花的时间会比较多，多于亮度变化的时间。下图是用最低亮度1作为“关”进行的测试。可以看到改善并不显著，亮的时间少了约10ms，但暗下来的时间多了约20ms.
最小命令间隔
不断缩小发送命令的间隔，可以看到变化。
比如，下图是L款12ms，可以看到基本是正常的。
当间隔减至11ms时，从波形上可以看到有的命令来不及处理。肉眼也可看到闪烁节奏的偶尔变化。
这说明对于L款，12ms是最小的命令间隔。这个值和前面测的响应延迟基本相当。
下面是H款的，50ms基本正常，
40ms时，命令看起来没有遗漏。但有些在没有完全灭时就开始下一个周期了。
30ms时，命令应该也没有遗漏，但灯基本上没有灭下来。
所以对于H款，比较安全的命令间隔还是应该在50ms以上。
灯光频闪
前面的波形中可以看到，对于L款，高电平（即灯亮的时候）特别粗。其实这是因为灯光有频闪。我们可以顺便测试一下。
方法很简单，将灯打到常开，用示波器的更高档查看其波形的交流分量。可以看到频闪频率大约90KHz。这对调光LED是一个正常的水平。
对于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家的这款产品在接口和通讯上比同类产品落后了一代。希望厂家能及时改善，与时俱进，提升产品竞争力。
