因項目需要，測試了兩家的幾款燈光控制器，都是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款，高電平（即燈亮的時候）特別粗。其實這是因為燈光有頻閃。我們可以順便測試一下。

方法很簡單，將燈打到常開，用示波器的更高檔查看其波形的交流分量?？梢钥吹筋l閃頻率大約90khz。這對調光led是一個正常的水平。

710 >

圖：l款燈光頻閃（亮度50）

對于h款，則沒有頻閃。這可能是因為它用的恒流驅動模式。

710 >

圖：h款燈光無頻閃（綠色是樹莓派低電平）

作為對比，綠色線是樹莓派gpio的低電平，可以看到其噪聲的大小。而燈光的波動比它小得多，可見燈光控制器電源和驅動還是不錯的。

測試程序

測試程序放在github上：github.com/loblab/lightctrl

在python環境下運行。測命令延遲需要一個電平作為對比，所以用了樹莓派。除此之外，其它測試其實是可以在pc上完成的。

710 >

圖：測試程序

小結

本文對容易被忽視的rs232燈光控制器的程控速度和響應做了定量的測試。命令響應延遲和連續命令的最小間隔基本上相當。

l款的表現屬于正常水平，也符合串口通訊的中端定位（更快的可能要使用網絡接口了）。

h款的電源和燈光驅動做得不錯，完全無頻閃。但通訊和處理速度上太慢（波特率9的款更慢）?；旧现荒苡迷诘退偾袚Q的場合。但這產品定位就有點矛盾。無頻閃固然好，但對于非超高速攝影（一般拍照，ms級曝光時間），90khz的頻閃是完全夠用的（原因可見前文：用相機定量檢測燈光的頻閃）。

另外，h款的串口接口用目前通用的usb轉串口線不能連接（因為rx和tx反了）。l款的可以直接用。盡管rs232的rx和tx也是挺混亂的，但目前市場上的主流線纜也是一種事實標準，和它匹配會比較方便。還有，l款使用數顯和數調，程控和手動是完全同步的，而h款還是多旋鈕的方式。兩種方式各有利弊，但數顯數調更符合潮流一些。

以上是網絡信息轉載，信息真實性自行斟酌。