M5Stack の DMX 連続試験 ― 「不一致」の原因を追った経過

M5Stack 2 台(送信 COM73 → DMX ケーブル → 受信 COM74)の試験で起きた、受信の劣化と「不一致」。電源を疑うところから、原因を見つけて直すまで ／ 2026-10-18 ／ スタッフ限定・社外に出さないこと

この頁で分かること
  1. 動画で見る
  2. 結論(先に)
  3. 試験の構成(2-1 画面の見方と使い方 ／ 2-2 カメラモニターの限界 を含む)
  4. 症状(何が見えていたか)
  5. 経過(見立てが 3 回変わった)
  6. 原因
  7. 直し方と、直ったかの確かめ方
  8. 直したあとの実測
  9. 残っている課題
  10. 考え方・やり方(この調査で効いたこと)
  11. 使った機器・道具

0. 動画で見る

原因は「測る道具」の側にあった ― 動画公開準備中

窓の役割と使い方つき・原因と改善のまとめ(11 分 8 秒・音声つき・字幕あり)

  1. 0:00 趣旨・画面の全体 / 0:57 DMX 連続試験の窓 / 1:50 PicoScope / 2:30 COM Port Scanner(それぞれの使い方)
  2. 3:14 カメラモニター(使い方と、命令での実演) / 4:50 カメラの限界(1 秒に数枚・表示が飛ぶ)
  3. 5:38 症状 / 5:59 見立てが 3 回変わった / 6:46 原因 / 7:39 直し方と確かめ方
  4. 8:27 直したあとの画面 / 9:47 残っている課題 / 10:28 まとめ

資料: この頁の PDF 版 ／ 編集用 Word 版

この頁の動画は撮り直した版です: 最初に撮った動画は、COM74 の液晶の表示(TX の周波数)が紛らわしい旧版のままだったため、表示を直したあとの画面で、窓の役割と使い方の説明から、最初から撮り直しました。調べ始めたときは電源を疑っていましたが、主な原因は電源ではなく、試験用スクリプトの側でした(下の 4〜5 章)。

1. 結論(先に)

見えていた症状本当の原因直し方
起動から約 4〜5 分たつと、受信が 25Hz → 9〜10Hz に落ち、画面が約 0.4 秒遅れ、「不一致」が毎秒数件に増えて戻らない試験用スクリプトが、COM73 から PC へ届く統計データ(1 秒に 1 回)を読んでいなかった。Windows 側の受信バッファが約 4.5 分で一杯になり、COM73 の書き込みが 1 回あたり約 0.1 秒ずつ待たされて、DMX 出力が止まったスクリプトで COM73 の受信を読み捨てる(1 行)。420 秒動かして劣化しないことを確認
送信周波数が 26Hz のように揺れるPC が 1 フレーム届くたびに 1 フレーム出す方式で、PC と USB の揺らぎがそのまま DMX の周期に出ていたCOM73 のファームを「自分のタイマーで 40ms ごとに送る」方式(25Hz 固定)に変更。オシロでも 25Hz で安定
十数秒に 1 回、512ch のうち一部のチャンネルの値が化ける未解決。周波数(20 / 25 / 40Hz)を変えても頻度は変わらない次回の撮影で、オシロを見て調べる

電源(10V 給電、USB の抜き差し)が主な原因ではありませんでした。最初は「電源環境で不安定」と見立てましたが、同じ劣化が、電源を変えなくても毎回、起動の約 4.5 分後に起きていました。

2. 試験の構成

COM役割ファーム(環境名)
COM73送信(DMX 出力)。CoreS3 + DMX-BASE。液晶に DMX の値(60ch ずつの表)を出すm5cores3-enttec-pro-monitor-fixed(今回新設)
COM74受信(DMX 入力)。CoreS3 + DMX-BASE。タイムテーブル再生機。液晶に ch1〜8 の棒と演出の進み(Cue)を出す。表示は 2026-10-18 に直した: 以前は「TX 39Hz / RX 25Hz」と出て数字が合わず紛らわしかったので、いまは「DMX OUTPUT (TX) only」「TX OUTPUT 25 Hz」だけの表示にした(送信周期を 25Hz にそろえる環境 m5s3lj2510-25hz)m5s3lj2510 → 表示を直した版 m5s3lj2510-25hz

PC の試験スクリプト tools\dmx_loop_test.py が、なめらかに変わる演出を作り(当初は 8 シーンを 3 秒ずつクロスフェードする 24 秒。撮り直した録画の時点では 255 秒・240 キューの長い演出)、COM74 へ USB で転送してタイマー再生させます。同じ演出を PC 側でも同じ時刻で計算して COM73 から DMX で送り、COM74 が受けた 512ch が、送ったフレームと完全に一致するかを数えます(一致・不一致)。

観察には、PicoScope 7(DMX の A / B 線の波形)と、USB カメラで撮った 2 台の液晶(カメラモニター。M5 の小さな液晶を AI が自分の目で見るための道具)を使いました。

2-1. 画面の見方と使い方(窓ごと)

画面の全体と窓の役割
図 1 画面の全体。番号は下の表(動画の撮り直した録画から)
#窓役割使い方
①②拡大窓(カメラモニターの Zoom 窓)カメラで写した M5 の液晶を拡大して見る。上が COM73、下が COM74拡大する範囲は、カメラモニターの Zoom ボタンでドラッグ、または HTTP の /roi で指定。右クリックで補間の切替、Ctrl+S または Capture ROI で拡大範囲を PNG 保存
③PicoScope 7DMX の電圧波形を、時間を横軸にして見る。A(青)と B(赤)の 2 台を同時に左のパネルで、実行/停止・時間軸(いまは 1 目盛 500µs)・トリガー(200mV)・各チャンネルの電圧の範囲(±2V)を決める。上の細い帯が全体、下が拡大。ルーラーで 2 点の時間差と電圧を読み、下の欄に周波数・サイクル時間が自動で出る。波形の乱れやノイズを見る窓
④カメラモニター(2 台)USB カメラの映像を見ながら、M5 の小さな液晶を拡大して見る道具。AI が HTTP で操作できる(1 台目 :8765、2 台目 :8775)上段: カメラ選択・Start/Stop・Capture(全体の静止画)・回転・Zoom(範囲指定)・Auto LCD(液晶を自動で探す)・AI Debug・戻す。右パネル: Auto Focus・Focus・Auto Exp・Exposure・Brightness。AI からは /brightness /focus /autofocus /roi /autolcd /capture /zoomcapture /burst など。露出(/exposure)は動かさない(カメラ 1 で映像が黒く止まることがある。黒が 3 秒続くと自動で開き直す)
⑤DMX 連続試験PC の python スクリプトの窓。COM73 から送った DMX と、COM74 が受け取った DMX が、完全に一致するかを数える起動は PowerShell で python -I tools\dmx_loop_test.py COM73 COM74 30(送信の COM・受信の COM・周波数)。止めるのは Ctrl+C。上の行は、不一致の数・演出の経過と Cue・ループ回数・遅延(平均/最大)・PC の停止時間。下の表は、チャンネルごとの送信値と受信値で、一致していれば右端に OK
⑥COM Port Scannerつながっている COM ポートを、VID/PID で自動識別して一覧にする2 秒ごとに自動で再スキャン(USB の抜き差しがすぐ反映)。Refresh で手動。Port が COM 番号、Device Name が機種名(M5 の書き込み台帳の名前も出る)。M5 は USB の差し口で COM 番号が変わるので、試験の前に COM73 / COM74 がどの機械かをここで確かめる

2-2. カメラモニターの限界 ― 1 秒に数枚しか取れないので、表示が飛ぶ

カメラモニターは、画面を1 秒間に数枚しか取れません。M5 の液晶は 25Hz(40ms ごと)で変わるので、カメラ越しの拡大窓では、数字や棒が飛んで見えます。M5 の表示が飛んでいるのではなく、カメラの取り込みが追いつかないためです。

カメラ画面が変わる回数(実測 2026-10-18)間隔
カメラ 0(Anker PowerConf C200・2560×1440)約 8.8 枚/秒中央 115ms(最大 141ms)
カメラ 1(USB Camera・1944×2592)約 2.3 枚/秒中央 452ms(最大 484ms)
M5 の液晶(比べる側)25 回/秒40ms
0.5 秒おきの 4 コマ
図 2 カメラ 1 の拡大窓を 0.5 秒おきに 4 コマ。コマとコマのあいだで、演出の時刻(00:01:54 → 55 → 56)も棒の高さも、まとめて飛ぶ

3. 症状(何が見えていたか)

(症状が出ていた当時の画面は、M5 の表示が旧版だったため、載せていません。直したあとの画面は 7 章です。)

4. 経過(見立てが 3 回変わった)

見立ての変遷
図 3 見立ての変遷と、決め手になった 2 つのこと
時刻出来事
07:14依頼「2 台つなぎの M5Stack のプログラム確認」。COM7 と COM17 の 2 台が見えた
07:16〜07:20各機の MAC を読み、台帳で照合。USB のポート位置で COM 番号が変わっていたので、COM73 / COM74 に戻して、台帳の最終記録のファームを 2 台とも書き込んだ
07:24COM74 が DMX 入力、COM73 が DMX 出力で通信試験。3 パターンとも送受信が一致(合格)
07:27〜07:32「常に動くデータで、止めるまで連続試験」。全 512ch を滑らかなサイン波にし、COM73 の液晶を DMX モニターの表示(グリッド)に書き換えた
08:12周波数が違う理由を確認。COM74 の TX 39Hz は COM74 自身の固定出力(25ms 周期)で別物。COM73 の 26Hz は PC が送る速さと一致
08:14「なめらかに変化する演出再生に」。24 秒の演出を COM74 へ USB 転送してタイマー再生。最初の転送は USB の受信バッファ(4096B)に溢れて失敗したので、2000B ずつ 60ms 間隔に変更
08:17〜08:23COM74 の画面で RUNNING (FADE) / 経過時間 / Cue 5/9 が動くのを確認。このころから、約 8 秒に 1 回、一部のチャンネルが化けるフレームが記録され始めた(60 秒で 7〜8 件、約 0.4%)
08:28不一致が毎秒 5 件ほどに急増。画面は変化なし。10V 給電に切り替えた連絡が 08:34 にあり、時刻が近いので給電が原因と見立てた(後で誤りと判明)
08:36給電を止めても遅延は残ったまま。「ノイズが続いているのではなく、給電切替で一度止まり、溜まりが残った」と説明した(これも誤り)
09:18〜09:21「周波数を落としても安定させる方法を」。過去の記録(2026-05-16)の「PC 経由の送信は 19〜22Hz で揺れ、ESP32 自身のタイマー送信は 35Hz で完全に固定」を参考に、COM73 のファームを自分のタイマーで 40ms ごと(25Hz)に送る方式にして書き込み。液晶とオシロで 25Hz の安定を確認
09:29不一致の中身を調べると、「値の化け」ではなく約 0.65 秒前の正しい値だった。試験スクリプトの「ずれ量の推定」(1 件 0.1 秒超の重い計算)が、受信の読み取りを遅らせる悪循環を起こしていたと判断して、計算を削除(部分的な原因)
09:40〜09:50遅延(ms)と PC 側の処理停止時間を表示するよう計測を追加。5 分と 7 分の連続測定を 2 回。遅延は最初は約 33ms で正常。起動の約 4.5 分後に突然 430ms に跳ね、受信が 10Hz に落ちて戻らない。PC 側の処理停止は最大 3〜6ms で、PC は止まっていなかった
09:51約 5 分後に COM73 と COM74 の液晶を撮影して比較。COM73 の送信 Hz も COM74 の受信 Hz も 10Hz に落ちていた(取りこぼし drop は増えていない)。COM74 に届く DMX 自体が 10Hz、つまり COM73 の出力が止まっていると判明
09:53仮説: COM73 は 1 秒に 1 回 USB で統計を書くが、試験スクリプトは COM73 を「書き込み専用」で開いていて受信を読んでいない。バッファが満杯になると書き込みが待たされ、COM73 のループが止まる
09:55スクリプトに COM73 の受信を読み捨てる 1 行を追加して 420 秒測定。劣化なし(受信 23〜26Hz、遅延約 30ms)=真因
09:56〜10:00送信周波数を 20 / 25 / 40Hz に変えて 100 秒ずつ測定。不一致は 9 / 9 / 13 件。周波数は残る問題の原因ではない
10:02〜10:15撮影用の窓を、修正版で再起動(位置は変えず)。10:15 にもう一度起動し直し

決め手は 2 つでした。

5. 原因

原因は、機器ではなく「測る道具」の側にありました。

原因の図
図 4 原因のしくみ
  1. COM73 は、1 秒に 1 回、統計データを USB で PC に書く。
  2. 試験スクリプトは COM73 を「書き込み専用」で開いていて、この統計を読んでいなかった。
  3. 読まれないデータが Windows の受信バッファに溜まり、約 4.5 分で満杯になる。
  4. COM73 の書き込みが、1 回あたり約 0.1 秒ずつ待たされ、COM73 のループが止まって、DMX 出力が 25Hz → 10Hz に落ちる。
  5. COM74 の受信も 10Hz になり、画面が遅れて、「不一致」が増える。COM74 の取りこぼし(drop)が増えないのは、COM74 に届く DMX 自体が 10Hz だったため。

6. 直し方と、直ったかの確かめ方

直し方
図 5 直し方 3 つ
#直し方確かめ方・結果
1試験スクリプトで、COM73 の受信を読み捨てる(1 行)420 秒(7 分)動かして劣化なし。受信 23〜26Hz、遅延は約 30ms のまま
2COM73 のファームを、PC からフレームが届くたびに出す方式から、「自分のタイマーで 40ms ごと(25Hz 固定)に送る」方式へ変更(TX_FIXED_PERIOD_MS)液晶とオシロの両方で 25Hz の安定を確認
3送信周波数を 20 / 25 / 40Hz に変えて、100 秒ずつ測定不一致は 9 / 9 / 13 件。周波数は「一部チャンネルの化け」の原因ではなかった

7. 直したあとの実測

撮り直した録画(12:00〜12:07)の最後の約 80 秒で読んだ数字です。試験は録画の頭(12:00)に動かし直していて、この部分は起動から約 5.5〜7 分後。以前は、起動から 4〜5 分で劣化していました。

直したあとの画面全体
図 6 直したあとの画面全体(起動から約 6 分)。動画の 8:27〜から
項目起動から約 5.5 分約 6.2 分約 6.8 分
COM73 の液晶の周波数25Hz25Hz25Hz
COM74 の画面(TX OUTPUT)25Hz25Hz25Hz
遅延(平均 / 最大)32 / 80 ms32 / 40 ms33 / 80 ms
PC の処理停止(最大)6 ms5 ms6 ms
演出の進み(Cue)73 / 240109 / 240143 / 240
不一致の累計222529
液晶と試験の窓
図 7 左 = 2 台の液晶(上 COM73「25Hz」・下 COM74「TX OUTPUT 25 Hz」)／ 右 = 試験の窓(全チャンネル OK)

受信は落ちず、遅延も 30ms 前後のまま、演出も進み続けました。一方、不一致は約 74 秒で 7 件(約 10 秒に 1 回)、録画全体(約 400 秒)では 28 件(約 14 秒に 1 回)で、ゆっくり増えています(次章)。

8. 残っている課題

残っている課題
図 8 残っている課題
  1. 十数秒に 1 回、512ch のうち一部のチャンネルの値が化けるフレーム。1 ch だけのもの、数十 ch、200〜350 ch のものがある(チャンネル全体が欠けているわけではない)。周波数・給電を変えても変わらない。原因が COM73 の出力 / DMX ケーブル / COM74 の受信のどこにあるかは未特定。オシロで BREAK・MAB・データの波形を、この周期に合わせて観察する。
  2. 「前後フレーム混在」(受信フレームの前半と後半が、前後のフレームの値になる)が、一致の大半を占める。値は正しく、COM74 が DMX 送出の待ち時間のあとに受信バッファを読むための現象と考えられる。不具合ではない。
  3. COM73 の台帳(FLASH_LIST)に、今回の書込み(m5cores3-enttec-pro-monitor-fixed)は未反映。変更したソース(enttec_pro_monitor_main.cpp・platformio.ini・tools\dmx_loop_test.py)は未コミット。

9. 考え方・やり方(この調査で効いたこと)

10. 使った機器・道具

2026-10-18 ／ スタッフ限定。図と動画の画面は、照明を接続せず、試験台の機器だけで撮った画面です(図は、撮り直した録画 12:00〜12:07 と、動画用に作った図解から切り出したもの)。時刻と数字は、担当者とのやり取りの記録、ファイルの更新時刻、試験の表示から拾いました。