最終更新 2026-11-01 12:51 ・ 限定公開(URL を知る人だけ・検索には出ません)
DMX を 4 台の USB 受信機で同時に見張る — 動画の説明と「飛び」の正体
2026-11-01 11:41〜11:46 に撮った紹介動画 (約 5 分) の説明 ・ 担当: Ws (Dmx_Tool_M5) ・ 数字はモニターが 1 秒ごとに残した記録 (CSV) から拾いました
YouTube で開く: https://youtu.be/NSs_frU5sLM
- 新しく作った DMX 監視ツール (DmxUsbProMonitorM5) の紹介です。LjPlay (M5Stack) が出す 1 本の DMX を、USB 受信機 4 台で同時に受けて、1 枠ずつの細かい数字を表示・記録します。
- 録画中の 約 5 分 50 秒、4 台とも DMX は 1 枠も欠けていません。30Hz・長さ 512・誤り 0・途切れ 0・記録の抜け 0 でした。
- 画面に出ている「飛び」(橙色の数) は、DMX が抜けたのではなく、数え方の見かけです。LjPlay は Bluetooth でタイマーと時刻を合わせる M5Stack ですが、今回はその時刻を受けておらず、ch46〜49 に書く時刻が「秒まで」(1/100 秒が いつも 0) になっていたため、1 秒に 1 回、時刻が 1 秒ぶん進んで見え、モニターが「29 枠抜けた」と数えていました。演出の再生に影響が出ないのはこのためです (詳しくは 4 章)。
- (追記 12:4x) 録画の後も続けた 52 分間、4 台とも 93,631 枠ずつ受け、1 枠も欠けていません。飛びは同じ速さのまま一定で、原因も同じでした (5 章)。
1. 動画に映っているもの
M5Stack CoreS3 + DMX-BASE
512ch・30Hz で送る
COM61 / COM62 / COM63 / COM64
(USB-DMX-PRO 互換・FW2.9)
PC で表示・1 秒ごとに記録
U0〜U3 の 4 ユニバース
同じ PC の画面に、次のものを並べています。
- 上の 4 つの窓 = DmxUsbProMonitorM5。左から COM61・COM62・COM63・COM64。上半分が ch1〜150 の値、下半分が受信の検査の数字。
- 左下 = PicoScope (オシロスコープ)。DMX の線の波形そのもの。左寄りの平らな所が BREAK (枠の区切り)。
- 右下 = LjPlay の液晶をカメラで写したもの。CHASE・GREEN・BLUE・WHITE・RAINBOW・BLINK・SUNSET・Blackout の 8 つのボタンで演出を切り替えます。
動画の流れ
| 動画の時間 | 時刻 | 内容 (ナレーションの要旨) |
|---|---|---|
| 0:00〜1:35 | 11:41〜11:43 | PicoScope の波形と、出力している M5Stack (LjPlay) の紹介。CoreS3 でリチウム電池が無いと 8 秒に 1 回ちらつく件があり、細かく見張るために作った。以前は Wi-Fi で DMX を取っていたが、今は USB で 4 台を直接つなぎ、長さ・最大間隔・送り手の時刻まで細かく取って AI が長く記録できる。 |
| 1:35〜2:50 | 11:43〜11:44 | LjPlay の演出を切り替える (GREEN・Blackout など)。1 本を 4 台に分けて同時に見張っている。1 日見張っておき、乱れたときだけ AI が細かいデータを残す。 |
| 2:50〜3:20 | 11:44:2x | 受けた DMX を Art-Net (4 ユニバース) でも送り出し、ArtNet Multi Monitor で同じ中身が見える。IP の見張りも自作の道具 (IpPing)。 |
| 3:20〜4:00 | 11:44〜11:45 | 「飛び」が出ているが、ちらつきには影響していない。ただし理由はきちんと解析すべき (→ 4 章で解析)。 |
| 4:00〜4:30 | 11:45:5x | 窓を全部閉じて開き直す。4 つの窓は位置を覚えていて、Connect を押すだけで元どおり受信に戻る。 |
| 4:30〜5:14 | 11:46 | このツールも、PicoScope の取り込みも、DMX の演出ツールと M5 の再生専用機も、AI に頼んで作ったもの。 |
2. 画面の数字の意味 (よく出るもの)
- Hz・長さ
- この 1 秒に受けた枠の数と、1 枠の ch 数。LjPlay は 30Hz・512。
- 周期 ms・BREAK µs・MAB µs
- 受信機が線の上で測った値。枠と枠の間隔 33.10〜33.57ms、BREAK 173〜180µs、MAB 7〜16µs。
- 誤り・化け・戻り・途切れ・記録の抜け・受け損ね・余分な BREAK
- 線や受信の異常を数える欄。すべて 0 なら、DMX は欠けずに届いている。
- 送り手・時計差 ms
- LjPlay が ch41〜50 に書き込んでいる「ビルド日時・今の時刻・COM 番号」を読んだもの。#31 = com-31、時計差 = LjPlay の時刻 − PC の時刻。
- 飛び
- 上の「送り手の時刻」が、前の枠より 1.6 枠ぶん (約 53ms) 以上進んでいたら「その間の枠が抜けた」とみなして数える欄。DMX の線そのものではなく、ch46〜49 に書かれた時刻だけを見ているのがポイント (次の章)。
3. 録画中の結果 (4 台の記録から)
モニターが 1 秒ごとに残した記録 (11:41〜11:47 の約 350 秒) を数えました。
| 受信機 | 秒数 | Hz | 化け・戻り・誤り・途切れ・記録の抜け・受け損ね・余分な BREAK・短い BREAK・周期外れ | 飛び (合計) | 飛び (1 秒あたり) |
|---|---|---|---|---|---|
| COM61 | 349 | 30 | すべて 0 | 10,063 | 28.8 |
| COM62 | 348 | 30 | すべて 0 | 10,034 | 28.8 |
| COM63 | 347 | 30 | すべて 0 | 10,005 | 28.8 |
| COM64 | 345 | 30 | すべて 0 | 9,947 | 28.8 |
Hz は窓を開き直した 11:45:52 の 1 秒だけ 4〜5 (つなぎ直しの途中)。それ以外はずっと 29〜31。
4 台とも「飛び」が同じ速さ (1 秒に約 29) で増え、ほかの異常は 0。線の上で本当に枠が抜けていれば、受信機の「記録の抜け」や「受け損ね」、Hz の低下にも出るはずですが、どれも出ていません。
4. 「飛び」はなぜ出るのか (解析)
4-0. まず前提: LjPlay は「Bluetooth でタイマーと時刻を合わせる M5Stack」
LjPlay (M5Stack CoreS3) は、照明用のカレンダータイマー (COM33) が Bluetooth (BLE) で流す時刻を受けて、自分の時計を合わせながら演出を再生します。何台あっても同じ時刻にそろうので、複数台が同時に同じ演出を出せます。そろっているかを外から確かめるため、LjPlay は DMX の ch46〜49 に「今の時刻 (時・分・秒・1/100 秒)」を目印として書き添えています。モニターの「送り手」「時計差」「飛び」は、この目印を読んだ数字です。
- LjPlay の時刻同期 ― 検査の方法と結果 (月差 13 秒の時計に 3 台をそろえる・2026-10-20) 7 分 23 秒
- LjPlay 3 台の時刻をタイムサーバと比べる ― 2 時間・同期が無い場合の誤差つき (2026-10-23) 3 分 32 秒
- LjPlay の 8 演出を SW8 とタイマーで切り替える｜LjStudio と同時再生・ずれ 1 フレーム以内 4 分 23 秒
説明の頁: LjPlay の時計のずれ ― カレンダータイマーの同期で補正できるか ・ LjPlay の 8 演出を SW8 とタイマーで切り替える
今回の飛びは、このタイマーとの時刻合わせが行われていなかったために出たものです。違いを図にすると次のとおりです。
時刻は 1 秒間ずっと同じ値のまま 30 枠が出て、秒が変わった枠で 1 秒 (1,000ms) まとめて進みます。モニターは「1 枠 33ms のはずが 1,000ms 進んだ = 間の 29 枠が抜けた」と数えます。これが 1 秒に 1 回起きるので、飛びは 1 秒に約 29 ずつ増えます。DMX の枠は 1 枚も抜けていません。
4-1. 記録に残っていた証拠
モニターの記録には、各秒の最後に受けた「送り手の時刻」が残っています。抜き出すと次のとおりで、1/100 秒の桁がずっと .00 です (約 350 秒の記録のうち、.00 以外は 1 回だけ)。
| PC の時刻 | 受けた枠 (Hz) | 送り手 (LjPlay) の時刻 | 飛び (この 1 秒) |
|---|---|---|---|
| 11:43:14 | 30 | 11:43:04.00 | 29 |
| 11:43:15 | 30 | 11:43:05.00 | 29 |
| 11:43:16 | 30 | 11:43:05.00 | 0 |
| 11:43:17 | 30 | 11:43:07.00 | 58 |
| 11:43:18 | 30 | 11:43:08.00 | 29 |
PC の 1 秒と LjPlay の秒の変わり目はずれているので、たまに「秒の変わり目が 0 回 (飛び 0)」「2 回 (飛び 58)」の 1 秒があります。平均すると 1 秒に 29 弱 = 記録の 28.8 と合います。
4-2. 1 秒の中で起きていること
| 枠 | LjPlay が書いた時刻 (ch46〜49) | 前の枠との差 | モニターの判定 |
|---|---|---|---|
| 1 | 11:43:04.00 | — | — |
| 2〜30 | 11:43:04.00 (同じ) | 0ms | ふつう (53ms 未満) |
| 31 | 11:43:05.00 | 1,000ms | 飛び +29 (1000 ÷ 33.3 − 1) |
| 32〜60 | 11:43:05.00 (同じ) | 0ms | ふつう |
1/100 秒まで書かれていれば、時刻は枠ごとに 30ms か 40ms ずつ進むので、53ms を超えず飛びは数えられません。
4-3. なぜ 1/100 秒が 0 なのか (LjPlay のプログラムから)
LjPlay は ch46〜49 の時刻を次の順に選んで書きます (LjPlay/src/main.cpp の fillInfoCh)。
- BLE タイマー (COM33) の時刻を受けていれば、それを元に 1/100 秒まで書く。
- 受けていなければ、本体の RTC (時計 IC) の時刻を書く。RTC は秒までしか持たないので 1/100 秒は 0。
- どちらも無ければ 0。
今回は 2 の状態でした。つまり com-31 は起動してから一度も BLE タイマーの時刻を受けていないことになります。時計差が約 −10.6 秒なのも、BLE で合わせていない本体 RTC が PC より約 10.6 秒遅れているためです。
〔未確認〕BLE タイマーの時刻を受けていない理由 (タイマー COM33 が止まっていた・遠かった・com-31 の BLE が切ってあった など) は、まだ確かめていません。
4-4. 演出の再生に影響が出ない理由
- ch41〜50 の時刻は、試験の道具が「どの機体の・いつの枠か」を読むために LjPlay が書き添えている 目印 です。演出の進み方は LjPlay の中のショー時計で決まり、この目印の時刻は使っていません。
- DMX の線の上では、周期 33.10〜33.57ms・BREAK 173〜180µs で、枠は欠けずに届いています (3 章)。照明器具から見て何も起きていないので、ちらつきも出ません。
5. 録画の後も続けた記録の解析 (11:46〜12:38 の 52 分・中間報告)
動画の最後で窓を開き直した後 (11:45:54) も、4 台の見張りをそのまま続けています。12:38 までの 52 分間 (3,121 秒) の記録をまとめました。記録はまだ続いています。
5-1. 結果
| 受信機 | モニターが受けた枠 | 受信機の記録 (線の上で数えた枠) | 1 秒あたり | 周期 ms | BREAK µs | MAB µs | 本当の異常 |
|---|---|---|---|---|---|---|---|
| COM61 | 93,631 | 93,634 | 30.000 | 33.10〜33.58 | 173〜181 | 7〜16 | 0 |
| COM62 | 93,631 | 93,633 | 30.000 | 33.10〜33.58 | 173〜181 | 7〜16 | 0 |
| COM63 | 93,631 | 93,634 | 30.000 | 33.10〜33.58 | 173〜181 | 7〜16 | 0 |
| COM64 | 93,631 | 93,630 | 30.000 | 33.10〜33.58 | 173〜181 | 7〜16 | 0 |
「本当の異常」= 化け・戻り・大飛び・途切れ・記録の抜け・枠の誤り・余分な BREAK・短い BREAK・周期外れ・受け損ね・長さ変化の合計。受信機の記録の数が 1〜4 ずれるのは、52 分の区切りの瞬間にどちらの秒に入ったかの差です。
5-2. 「飛び」の推移
52 分間の飛びは 4 台とも約 91,500 (1 秒あたり 28.97〜28.99) で、動画のときと同じ速さのまま一定でした。LjPlay の時刻の 1/100 秒は、この間 1 度も 0 以外になっていません。4 章の「BLE の時刻を受けておらず、秒までの時刻を書いている」状態が続いています。
5-3. 画面で「Hz 27」や「最大間隔 100ms 超」が出た秒について
記録を見ると、Hz が 27 前後になった秒が 50 回ほど、「最大間隔」が 100ms を超えた秒が十数回ありました。調べた結果、どれも線の上の異常ではありません。
- その秒も前後の秒も、受信機の記録の通し番号は抜けておらず (記録の抜け 0)、線の上の周期は 33.10〜33.58ms のままでした。
- Hz 25〜27 の秒は、すぐ前 (または後) の秒が 31〜36 になっていて、合わせると 1 秒 30 枠に戻ります (例: COM61 の 11:52:26 は 前の秒 34 → 26 → 30)。受信機から PC へ USB で届くタイミングが少しまとまったり遅れたりして、PC の 1 秒の区切りに入る数が前後に振れただけです。
- 100ms を超えた間隔は、11:47:39〜43 には 4 台そろって出ています。〔推定〕PC 側がその間ほかの処理で忙しかったため (窓を動かした・別のソフトを開いた など)。PC 側の見かけなので、照明には関係しません。
11:45:54〜56 の Hz 5〜18 は、動画の中で窓を閉じて開き直した直後の 1〜2 秒です。
6. 直し方の案 (本人の判断待ち)
| 案 | やること | 手間 |
|---|---|---|
| A. BLE タイマーを使う | タイマー COM33 を動かし、com-31 が BLE の時刻を受けるようにする。1/100 秒が入り、飛びが止まるはず (未確認)。ファームの変更なし。まず確かめとして。 | 小 |
| B. LjPlay を直す (Ws) | BLE が無く RTC だけのときも、秒の変わり目からの経過で 1/100 秒を埋める。タイマーが無い現場でも飛びが 0 になる。 | 中 |
| C. モニターを直す (tool_cs) | 1/100 秒がずっと 0 の送り手は「飛び」を数えず、「時刻は秒まで」と表示する。 | 小〜中 |
Ws のおすすめは A で原因を確かめてから B。ファームの変更はまだしていません。
7. データの置き場所
- 元の動画: 本人 PC の画面録画 (2026-11-01 11:41:33〜11:46:47、5 分 14 秒)
- モニターの 1 秒ごとの記録:
e:\tmp\ai_dmxpromon\rxstat_1〜4_20261101.csv - 「飛び」の数え方:
E:\tool_cs\DmxUsbProMonitorM5\RxStats.cs(OnFrame) - LjPlay の時刻の書き方:
E:\Ws\PIO\DMX\Dmx_Tool_M5\LjPlay\src\main.cpp(fillInfoCh)