☀️ ライト M5Stack LjPlay の DMX が止まる原因の解析と改修
2026-10-19 の試験(約 50 分の録画 2 本)から。止まったのは M5 ではなく、DMX 受信機(USB-DMX-PRO 互換) 。計測の案内・不良個所・原因・修正内容を、時間軸つきでまとめた ／ スタッフ限定・社外に出さないこと
この試験の目的
LjPlay は、M5Stack のような簡易な ESP32 の機器で、LjStudio で作った照明のデータを SD カードから読み込んで再生する装置です。 別に作ったカレンダータイマー(季節と時間帯のスケジュールでシーン番号を出す)から指令を受けて、時間単位でいろいろなシーンを動かすことを想定しています。
設置したあとは人がいない状態で、何か月も動き続けること(無人運転)が基本 です。そのため、DMX が止まらずに安定して出続けること、時刻がずれないこと、止まっても自分で戻ることを、出荷の前に段階を踏んで確かめる必要があります。
この頁は、その出荷前の試験プログラム の記録です。2026-10-19 の試験で見つかった不良(DMX が止まって見えた件)の原因と直した内容をまとめ、より精度の高い、より安定したものになるまで、検査と修正を続けて、出荷できる完全なものに仕上げていきます。当面の目標は 12 時間の連続運転で途切れ 0 回、最終の目標は 4 か月の無人運転です。
この頁で分かること
動画で見る(約 11:06)
結論(先に)
計測の案内(構成・手順・画面の見方・表示の読み方)
時間軸(いつ何が起きて、何を直したか)
不良個所と原因と修正内容(①〜⑥)
受信機のファーム担当への改善要望(ウォッチドッグ)
M5 側で確認が要る点(calc・OVERRUN)
残っている課題と次の一手
使った機器・道具・資料の場所
追記 ― 外部 12V(電池)の関与(給電)
0. 動画で見る
公開準備中 検査の目的と試験のしくみ(1 時間の試験の 1 回目の結果つき・約 5:44・音声つき・VOICEVOX:No.7)
0:00 はじめに / 0:13 LjPlay とは / 0:35 無人運転が基本 / 1:01 試験の段階 / 1:27 試験台の構成 / 2:01 監視画面 2:25 試験中の録画(オシロの DMX 波形) / 2:50 3 台の時計がそろっている / 3:26 S1 1 回目の結果 / 4:22 受信機 COM86 が止まった瞬間 / 4:36 今日分かった課題 / 5:16 これから 公開準備中 計測の案内つき・不良個所と原因と修正内容(約 11:06・音声つき・VOICEVOX:No.7)
0:00 はじめに / 0:17 測定の構成 / 0:52 計測の手順 / 1:29 監視画面の見方 / 2:24 表示の読み方 / 3:03 止まりの年表 3:53 11:36 A が無音・M5 は動作中 / 4:24 受信機を直接読む / 4:55 13:33 受信機のリセットで復旧 / 5:16 13:58 B が無音・COM74 は動作中 6:01 不良① 受信機が固まる / 6:41 不良② 一致の表示 / 7:16 不良③ 基準と表示精度 / 7:51 不良④ C が 0 に戻らない / 8:39 不良⑤ 録画の切り離し 9:08 M5 の calc と OVERRUN / 10:06 受信機への改善要望 / 10:35 まとめ
0-2. 試験の進め方(出荷までの検査計画)
段階ごとに時間を延ばし、条件を本番に近づけます。NG(DMX の途切れ)が出た段階は、原因を直したあと最初からやり直します。
段階 内容 合格
S1 1 時間 × 3 回連続(試験台) 途切れ 0 回 × 3 S2 12 時間(夜間) 途切れ 0・送出失敗 0・再起動 0・2 台の時刻のずれ ±1 秒 S3 72 時間・途中で監視の PC を再起動 監視が止まっても M5 は出し続ける S4 外乱(電源の瞬断・USB/SD/DMX 線の抜き差し・温度) 自分で戻る(戻るまでの秒数を記録) S5 7 日・本番の電源と配線・灯体あり(人の立会い) 途切れ 0・時刻のずれが決めた方式で ±1 秒 S6 30 日・本番相当・遠隔監視 月次点検の手順で問題なし
測り方 : 1 台の M5 を受信機 2 台で受け(止まったのが受信機か M5 かを見分ける)、M5 本体の状態(送出の数・失敗・再起動・メモリ)を 3 秒ごとに問い合わせ、全部を録画と数字で残す。時刻は DMX の ch11〜13(時・分・秒)で 3 台を直接比べる。出荷前に決めること : M5 の水晶のずれは −23〜−73 ppm(4 か月で約 8.6 分)。カレンダータイマーの指令で時間単位にシーンを動かすので、毎日の合わせ直しか補正の方式を決める。CoreS3 の USB が固まる件(遠隔で操作できなくなる)の対策。S1 の 1 回目(2026-10-19 20:55〜21:53) : 3 台(COM23・COM74・LjStudio-play)を 0:00 にそろえて開始(3 台のタイマー値が毎秒一致・21:07 の同じ瞬間に 00:12:13.0 / 13.2 / 13.1)。M5 2 台の DMX は 58 分間、途切れ 0 回 。見張りは 58 分 8 秒で NG を出して止めた(受信機 COM86 だけが 1.3 秒無音・同じ M5 を受ける COM96 は受信中 = 測る側の受信機の停止。その 4 秒前に受信機 4 台が同時に 110 ms 遅れた)。次は、NG の判定を「同じ M5 の受信機が全部止まったとき」に直して、2 回目・3 回目へ。
1. 結論(先に)
止まったのは、DMX 受信機(S3 互換 USB-DMX-PRO)。M5(LjPlay)は止まっていない。 受信機は USB では生きていて問い合わせに返事をするのに、DMX だけ入らなくなる。ソフトの開き直しでは戻らず、物理リセットで戻る。止まっている間も、M5 の液晶は RUNNING・TX 30Hz で時間が進んでいる。監視プログラムの表示と動作の不良を 5 件直した(②一致の判定・③基準と表示精度・④C が 0 に戻らない・⑤録画の切り離し・①受信機の自動再接続と M5 本体の同時観察)。
受信機のファームに、ウォッチドッグ (3 秒受信なしで再初期化 → 10 秒でリセット)・USB 送信を詰まらせない・診断項目、を要望した(Ws へ依頼済み)。
M5 の液晶に OVERRUN(calc 47〜66 ms)が出た点は、M5 の安定性として Ws に確認を依頼した(開始時の SD 読み込みなどの可能性。確証なし)。
訂正: 当初の記録(同日の連絡ファイル)では「COM73 の DMX が線の上で止まった」と書いたが、取り消し 。止まっていたのは受信機側だった。
2. 計測の案内
2-1 測定の構成
M5 の DMX は XLR で USB の受信機に入り、PC の監視が読む。LjStudio-play(C)は Art-Net で PC の中で受ける。 2-2 手順(4 ステップ)
監視を起動 → 「0 から全部スタート」→「● 録画 開始」→ 止まったら診断を読む 2-3 監視画面の見方
番号は図の下の説明と同じ。ずれの精度は ±3 ms 程度なので、小数は出さず整数で表示する。 2-4 表示の読み方(正常と異常)
受信は A・B が 30/秒、C が 40/秒なら正常。診断が「受信機が無音・M5 は動作中」なら受信機の停止。 録画中は、エクスプローラーでファイルのサイズが 0 のまま に見えるが、実際は書けている(開いている間は一覧が更新されない)。サイズを見るのは録画を止めてから。
3. 時間軸(いつ何が起きて、何を直したか)
録画から 1 分ごとに受信の有無を数えた。緑=受信中・赤=録画があるのに無音・灰色=録画なし/監視を入れ替えていた(不明) 時刻 出来事 区分 メモ 09:21 / 09:32 / 10:01 A(受信機 COM86)の受信が 0 になる。監視の開き直しで戻る場合と戻らない場合 不良① 当初は「M5 の出力が止まった」と見立てたが、後に受信機側と判明 10:15 受信機を開き直すタイマーが一度も動かないバグを修正(5 秒の再受信要求が同じ時計を戻していた) 修正 別の時計に分けた 10:21 録画を監視から切り離す(映像は別プロセス rec_video.py) 修正 ⑤ 監視を止めると録画も止まる問題 10:27 データの突き合わせ(全 ch)を追加。「データ ★不一致」の表示 修正 ② 時刻だけ見て「一致」としていた問題 10:46 50 分の連続録画を開始。B(COM61)は 65 分間、一度も受信できない 不良① 録画で確認 10:49 監視を起動し直す(録画は同じ録画の続きに入る) 確認 ⑤ 切り離しの確かめ 10:50 「0 から全部スタート」ボタンを追加・実行。A・B は 0 に戻り、C(LjStudio-play)は途中から 不良 ④ C のタイマー ch が 36 秒進んだまま 11:36 A の受信が 0(以降 12:51 まで)。M5 の液晶は RUNNING・TX 30Hz のまま 不良① 動画 clipA 11:50 録画停止(約 64 分) 12:51 見張りが `startall` を送り直す → A・B が復活 M5 の再スタートで受信機が再同期した可能性 13:08 「0 から全部スタート」が LjRun へ `restart` も送るようにする 修正 ④ その後の 0 スタートで 3 つの時刻が 0.1 秒以内に揃う 13:14 2 本目の録画を開始(約 48 分) 13:20 ずれの基準を A から LjStudio-play(C)に変更 修正 ③ A が常に 0 で、基準が違った 13:22 A の受信が 0(13:33 まで約 11 分) 不良① 13:27 ずれ・幅・ドリフトを整数表示にする(精度は ±3 ms 程度) 修正 ③ 小数 2 桁は精度に見合わない 13:30 監視を止めて受信機を直接読む。COM86 は 0 バイト(問い合わせには返事)、COM61 は 4 秒で 122 フレーム 原因の切り分け 受信機は USB では生きている 13:33 COM86 を物理リセット → A の受信が戻る 確認 動画 clipB 13:35 受信機を入れ替え。両方受信中 確認 13:53–13:59 B(COM61)が 6 分間無音。COM74 の液晶は RUNNING のまま。13:59 に COM86 を抜き差しすると A と B が同時に戻る 不良① USB の接続・給電の関与も残る。動画 clipC 13:58 M5 本体の同時観察(3 秒ごとに状態を問い合わせ)と診断を追加 修正 ① 受信機が無音で M5 が動作中なら「受信機の停止」と出す 14:02 録画停止(約 48 分) 14:05 受信機のファーム担当(Ws)へ、ウォッチドッグの改善要望を依頼 要望 E:\_ai_requests\
4. 不良個所と原因と修正内容
① 受信機(USB-DMX-PRO)が固まる
11:36 の録画。右下の監視画面で A の受信が 0/秒。左上の M5 液晶(COM73)は RUNNING・TX 30Hz で時間も進んでいる。 13:58 の録画。B(受信機 COM61)は 13:53 から受信 0/秒。COM74 の液晶は RUNNING・TX 30Hz。 13:30 に監視を止めて受信機を直接読んだ結果。COM86 は DMX 0 バイト(問い合わせには返事)、COM61 は 4 秒で 122 フレーム。 13:33 COM86 を物理リセットした直後。A の受信が 30/秒に戻った。
症状: 受信が突然 0 になる。A は 11:37 から 14 分以上・13:21 から 12 分。B は 10:46 から 65 分・13:53 から 6 分。C(Art-Net)は途切れない。原因(見立て): ESP32-S3(USB ID 303A:1001)の USB-DMX-PRO 互換機が、DMX を受けたまま固まる。ソフトの開き直し・DTR の入れ直し・受信開始(ラベル 8)の送り直しでは戻らず、物理リセットで戻る。13:59 には A と B が同じ瞬間に戻ったので、USB の接続や給電の関与も残る(確証なし)。監視側の修正: 5 秒で受信開始を送り直し・10 秒でポートを開き直す。10:15 に「10 秒の開き直しが一度も動かない」バグも直した。M5 本体の同時観察(13:58 追加): 3 秒ごとに M5 の USB へ状態(経過時間)を問い合わせ、受信機の受信状況と並べて診断する。「受信機が無音・M5 は動作中 → 受信機の停止」と、画面と記録(events.log)に出す。
各枠の「M5 本体」の行: 応答あり・経過時間・診断(正常/受信機の停止/M5 側を疑う) 受信機 M5 本体 診断
無音 動作中 ★受信機(USB-DMX-PRO)の停止 届いている 応答なし 制御側(USB)だけの問題 無音 応答なし ★M5 側を疑う
② 「一致」と出るのに、データは違う
修正後の表示。見出しに「データ ★不一致」。下に全 ch の突き合わせ結果。
症状: 見出しが緑の「バラツキ 22 ms」で、LjStudio-play と LjPlay の中身が違うのに一致に見えた。原因: 見ていたのは、各入力のデータに入っている「時刻」だけ。全チャンネルの値は一度も比べていなかった。修正(10:27): ずれ分を戻した全 512 ch を、基準と 1 枚ずつ突き合わせる。1 枚でも違えば赤の「★不一致」。C は時刻の形式が違うので、データ照合でずれ(粗さ ±20 ms)を探し、合う位置が無ければ「照合できず」と出す。
③ ずれの基準が A のままだった / 小数が出ていた
基準 C に対するずれ。A・B は +65〜+93 ms 前後(C より進んでいる)。
症状: 基準が A だったので、A のずれが常に 0.0。本来の基準は LjStudio-play(C)。ずれが「86.22 ms」のように小数 2 桁まで出ていたが、実際の精度は ±3 ms 程度。修正(13:20 / 13:27): --ref C で起動。実行中は inbox に ref C で替えられる。表示は整数(生の値は status.json と log.csv に小数のまま残す)。精度の目安: 受信機は USB のまとめ送りで 1 フレームごとの到着が約 20 ms ばらつく。数秒の平均で約 2 ms。C は PC 内の Art-Net で、USB 受信機を通らないため、A・B との間には数 ms〜10 ms 台の系統的な誤差が混ざりうる。A と B の間が、いちばん信じられる。
④ LjStudio-play(C)が 0 に戻らない
最初の 0 スタートで、C だけ途中から(ch12 のタイマーが 36 秒進んでいた)。
症状: 13:10:11 の録画の最初のコマで、A・B の ch12 = 2、C の ch12 = 40。原因: LjRun は、動き始めたあとの UDP の開始合図(LJRUN_START)を無視する(多重発火防止)。inbox の restart は時計を 0 に戻すが、走っているシーケンス(ch12 のタイマーなど)は戻らない 。修正(13:08): 「0 から全部スタート」が、M5 2 台への開始(約 0.15 ms・0.3 ms)と同時に、LjRun の inbox へ restart も送る(約 0.9 ms 以内)。その後の 0 スタートでは、3 つの時刻が 0.1 秒以内で揃った(13:35 に A 56.475 / B 56.475 / C 56.375 秒)。残る課題: 最初の 1 回で C が揃わない場合がある。確実に頭から戻したいときは、inbox の cuelist 1(CueList を載せ替えて 0 から。RgbTimer のショー専用の番号)が効くことを確認した。「0 から全部スタート」へ併用するかは未決。
⑤ 監視を止めると、録画も止まる
映像は別のプロセス(rec_video.py)が撮る。監視が止まっても映像は続き、起動し直すと同じ録画の続きに入る。
症状: 監視の再起動のたびに録画が終わっていた(ffmpeg も監視の中で動かしていたため)。修正(10:21): 映像を別のプロセスに切り離す。録画中は ACTIVE.json が残り、監視を起動し直すと frames_2.bin・log_2.csv …と続きに入る。rec stop でだけ録画が終わる。確かめ: 録画中に監視を 4 回入れ替えても、映像は 1 本のまま約 48 分(637 MB)続いた。DMX フレームと数字ログは、監視が止まっている間だけ空く。
⑥ 表示の精度(③と同じ修正)
「1 ms 未満は出さない」と画面に書いた。精度が不明な数字は表示しない、という方針。
5. 受信機のファーム担当への改善要望(ウォッチドッグ)
Ws へ依頼済み(E:\_ai_requests\2026-10-19_tool_cs_to_Ws_USB-DMX-PRO受信機が固まる_ウォッチドッグ改善要望.md)
ウォッチドッグ: 直近 3 秒、DMX フレームを 1 つも受けない → 受信側(UART・esp_dmx)を再初期化。10 秒で戻らなければ esp_restart()(USB から見ると物理リセットと同じ)。頻発しないよう間隔を広げ、回数を数える。USB 送信を詰まらせない: 書き込みにタイムアウト。ホストが読まないときは古いフレームを捨てて最新だけ送る。DTR の再接続で受信を再開。診断の出口: 最後に受けてからの ms・フレーム数・BREAK 数・オーバーフロー数・再初期化回数・USB 書込タイムアウト回数。「ライン上の活動はあるのにフレームが来ない」か「ラインが無音」かで、固まりの場所が切り分けられる。
受け入れ条件: 受信機 2 台で LjPlay 2 台の DMX(512 固定長・30Hz)を 60 分連続で受け、無音が 2 秒を超えた回数が 0 を 3 回連続で完走(rec_marathon.py で判定)。人為的に固めた後(ホストを 20 秒読まない・XLR を抜き差し)も 10 秒以内に自己復帰して 30Hz に戻る。
6. M5 側で確認が要る点(calc・OVERRUN)
左=10:46 開始の録画(calc 1466µs・2485µs・OVERRUN なし)/ 右=13:14 開始の録画(calc 47636µs・66154µs・RUNNING [OVERRUN])
DMX は 1 フレーム約 33 ms。calc がそれを超えると OVERRUN。TX は 30Hz のまま出ているが、M5 の処理が一時重くなっている。
値は 26 分間ずっと変わらない(ピーク保持の見込み)。開始時の SD 読み込みか、は Ws の確認が要る。calc の定義と OVERRUN の条件の確認を依頼済み 。
7. 残っている課題と次の一手
受信機の改修(ウォッチドッグ)の反映待ち。反映後に rec_marathon.py で 60 分の完走試験(どれか 1 つでも 2 秒止まったら録画停止して最初から。3 回連続で完走)。
受信機を入れ替えて(13:35)から、止まる側が受信機について行くか・M5 側かを見る。次に止まったとき、監視の診断が記録する。
A・B と C の間のずれ(約 70〜90 ms)と、データの中身の不一致(LjStudio-play と LjPlay)は、データ修正中。
C の 0 戻しを毎回確実にする案(cuelist の併用)は未決。
8. 使った機器・道具・資料の場所
M5Stack CoreS3 + DMX-BASE 2 台(COM73・COM74)。受信機は USB-DMX-PRO 互換(ESP32-S3)の COM86・COM61。LjStudio-play(LjRun)は i8。照明は接続せず、試験台のみ。
監視: tools\dmx_sync_monitor\dmx_sync_monitor.py(README.md に使い方)。見張り: rec_marathon.py。録画: rec_video.py。
録画: e:\tmp\ai_dmxsync\rec\20261019_104640・20261019_131411(映像・DMX 全フレーム・数字ログ)。ログ: events.log。
動画の作り直し: tools\dmx_sync_monitor\analysis_video\build_video_15.py。
9. 追記 ― DMX-BASE の外部 12V(電池)の関与(2026-10-19 夕方)
この頁の結論「止まったのは M5 ではなく受信機」との関係は、整理中です。 下の事実が分かったため、時間軸の「止まり」のうち、電池で説明できるものと、受信機の固着で説明できるものを、ログで分けて確かめています。分け終わったら、結論の文言と動画の説明を直します。
2026-10-19 夕方、COM73・COM74(M5Stack CoreS3 + DMX-BASE)の DMX-BASE の外部入力 12V(電池)を交換 したところ、ファームを変えずに 、COM74 の線が受信機 COM61・COM115 の両方で 30.0/秒に戻りました(受信監視 rx_watch の記録 16:40:27)。電池を替えたのは 16:40 より前ですが、時刻は記録していません。
それ以前の症状は、電池の消耗と矛盾しません。「M5 は動いているのに、受信機に DMX が入らない」「2 台同時」「再起動で戻らない」「時間とともに悪化」。CoreS3 は USB 給電で動き続けるため、M5 の STATUS(tx_ok が進み tx_fail=0)も液晶(30Hz)も正常に見えたまま、線の上の DMX だけが出ていなかった ことになります。
電池の電圧の測定値は、記録にありません。 電圧の低下なのか、ノイズなのかは、確定していません。「AC アダプタにすればよい」とは限りません。スイッチング電源そのもののノイズで NG になる可能性があります。給電(電池・AC・USB)は、電圧の低下とノイズの両方を測って切り分けます。
検査の記録には、給電条件(外部入力の種別・電圧・ノイズ、USB の有無、筐体)の欄を足しました(Dmx_Tool_M5\LjPlay\DOCS\LjPlay_継続検査_給電条件記録.md)。数台の組み合わせで続ける検査では、この書式で 1 回ごとに残します。
受信機 COM61・COM86・COM96 に書いた FW2.8(USB 送信バッファ 2048・待たない書込み・ウォッチドッグ 8 秒)の効果は、長期観察で判定する段階です。電池交換の効果と区別するため、受信機のファームと給電は、同時に変えません。
公開準備中
公開準備中
![左=10:46 開始の録画(calc 1466µs・2485µs・OVERRUN なし)/ 右=13:14 開始の録画(calc 47636µs・66154µs・RUNNING [OVERRUN])](images/09a_M5の液晶_calcとOVERRUN.jpg)