LjPlay の時計のずれ ― カレンダータイマーの同期で補正できるか

2026-10-20 の試験(約 40 分)・スタッフ限定・照明は接続せず試験台の機器だけで測定

この試験の目的: LjPlay(M5Stack で LjStudio のデータを SD から再生する装置)は無人で 4 か月動かすのが目標。M5 の時計は補正しないと −23〜−73 ppm 遅れ、4 か月で約 8 分ずれる(2026-10-19 の試験)。照明用のカレンダータイマー(月差 13 秒・4 か月で約 52 秒)が Bluetooth で M5 の時刻を合わせ続ければ、ずれを 52 秒程度に抑えられるはず。それを、インターネットの時刻(NTP)に合わせた PC の時計を物差しにして確かめた。

★最終の結果(2026-10-20 夕方): 一日で 5 回直した後、LjPlay 3 台は月差 13 秒のタイマー(RTC)に 1 ms 単位でそろって従い、NTP の時刻に対して ±5 ppm の内側(3 台の差 2〜3 ms で一定・開始直後の差 7 ms・時刻の飛び/失敗/再起動 0)。4 か月の見込みは約 +30〜+50 秒(補正なしなら約 8 分)。詳しくは「0. 動画」の上の 1 本と「5-5」。下の赤枠は朝の時点の結論。

結論(朝・この 40 分では): 補正と補正の間は PC の時計とほぼ同じ速さで良好。しかし、補正が入るたびに「遅れる」向きの段が入り、40 分で約 100 ms 遅れた(−45 ppm 相当)。このまま積み上がれば 4 か月で約 8 分 = 補正なしと同じ。今日の試験では「補正できる」とはまだ言えない。同期を RTC に変えたあと、同じ方法で測り直す。

0. 動画で見る

公開準備中

★今日のまとめ: 検査の方法と結果(手順・画面の見方・3 つの測り方・合格の条件 → 朝の問題 → 直したこと → 夕方の結果・約 7:23・音声つき・VOICEVOX:No.7)

0:00 はじめに / 0:17 目的 / 0:42 試験台 / 1:02 検査の方法 / 1:25 録画の画面の見方 / 1:53 ずれの監視(録画を拡大) / 2:10 測り方 ① DMX の秒 / 2:43 測り方 ② ch15〜18 の時計 / 3:19 測り方 ③ 時計の物差し
3:43 合格の条件 / 4:09 朝わかった問題 / 4:36 直したこと / 5:10 3 台同時スタート(録画) / 5:37 開始直後 7 ms / 5:55 1 時間の様子 / 6:17 1 ms より細かく測る / 6:44 朝と夕方 / 7:07 残る課題と資料

公開準備中

カレンダータイマーの同期で補正できるか(約 4:21・音声つき・VOICEVOX:No.7)

0:00 はじめに / 0:16 問題: M5 の時計は遅れる / 0:47 試験の構成 / 1:08 0 からスタート(録画) / 1:25 同期が時刻を戻す / 2:00 タイマーが飛んだ瞬間(録画)
2:34 ずれと補正のグラフ / 2:59 2 時間の頭で同時に戻る / 3:15 頭へ戻った瞬間(録画) / 3:28 結果 / 3:59 これから

1. 問題と構成

M5 の水晶の時計は 4 か月で約 4〜8.6 分遅れる。カレンダータイマーは月差 13 秒

カレンダータイマーが BLE で 2 台の M5 に時刻を合わせる。M5 の DMX を受信機 2 台ずつで受け、PC(NTP)の時計と比べる

物差し: PC の時計(NTP ntp.nict.jp に同期)。M5 が DMX の ch11〜13 に出す「時・分・秒」の秒が変わる瞬間の到着時刻を PC の時計と比べる。受け取りの粗さは ±20 ms 程度(30 分で数 ppm まで読める)。
M5 本体の位相(phase_ms)も 1 分ごとに記録。PC からの補正(TRIM)は使っていない。

録画の 1 コマ(10:12:42)。左に 2 台の M5 の液晶(1:30:47.2 でそろう)、中央に監視、右に受信機 4 台、右下にカレンダータイマーの液晶

2. できごと

時刻	できごと
10:09:22	録画開始(画面・DMX の全フレーム・数字)
10:09:39	監視から 2 台へ「0 からスタート」(送信 0.15 ms / 0.32 ms・返事 2 台 OK)
10:11:31.5	COM74 のタイマーが 0:01:52 → 1:29:37 へ飛ぶ(+5264.4 秒)= カレンダータイマーの同期がカレンダーの時刻へ戻した
10:11:55.6	COM23 も 0:02:16 → 1:30:01 へ(+5264.3 秒)。2 台とも「08:41:54 = 0 秒」の時間軸(差 47 ms)
10:14:30	COM74 の位相 −27 ms の補正と同時に、ずれが +30 ms の段
10:19	COM23 のずれが +33 ms の段(位相の補正は −4.5 ms)
10:41:55.644 / .645	2 時間の頭。2 台が 1 ms の差で同時に 0:00:01 へ。同時に 2 台ともずれが +55 / +37 ms の段
10:49:26	録画停止(本人が RTC 同期へ変更する作業に入る)

2 時間(7200 秒)で 1 周。10:41:55 に 2 台が 1 ms の差で同時に頭へ戻った

3. PC(NTP)の時計とのずれ

上: M5 の秒が切り替わる瞬間の遅れ(点 = 1 回ごと・線 = 1 分の中央値)/ 下: M5 の位相

2 分ごとの中央値(ms・+ は M5 の秒が PC より遅れて来る)

時刻	COM74	COM23
10:11	+36	+50
10:13	+44	+51
10:15	+74	+55
10:19	+76	+89
10:25	+72	+95
10:31	+67	+100
10:37	+67	+107
10:39	+71	+99
10:41	+124	+136
10:43	+135	+142
10:47	+136	+147

M5 の位相(STATUS の phase_ms)

時刻(1 分ごとの記録)	COM74 の位相	COM23 の位相
〜10:14	−114.1 ms	−7.1 ms
10:15	−141.1	−7.1
10:20	−143.8	−11.6
10:30	−148.9	−4.7
10:40	−158.3	−1.6

段と段の間は平ら: COM74 は 10:15〜10:40 の 25 分で +74 → +67 ms。補正なしの水晶なら 25 分で 35〜110 ms 遅れるはずなので、段の間は良い時計に従っている。
段はすべて遅れる向き: 10:14:30 COM74 +30 ms / 10:19 COM23 +33 ms / 10:41:55(2 時間の頭)2 台とも +55 / +37 ms。

4. 結果とこれから

段の原因の候補(未確認・制作担当に確認中): ① 位相の補正の向き・量 ② タイマーの秒が DMX の 1 フレーム(33 ms)単位で出るため、小さな補正でも 1 フレームの段に見える ③ 2 時間の頭でキューリストを始め直すときの遅れ(1 周ごとに積み上がるか)④ カレンダータイマー自身の時計(液晶の表示 ERR +0.99s・SYNC 2026-10-14 07:57:15)。

5. 補足: BLE 連動の今の作りと、これからの課題(2026-10-20 15 時時点)

この章は、M5・タイマーの制作担当がまとめた。

5-1. 何をつないでいるか

親はカレンダータイマー 1 台(壁のスイッチプレート型 S3DmxRj1・COM33)。時計は温度補償つきの RTC(DS3231・月差 13 秒相当)。
子は LjPlay(M5Stack の DMX 再生器)。今は 3 台: COM74(CoreS3 + DMX Base)・COM23(Core2 + 拡張ユニット・外部給電あり)・COM27(Core2 + 拡張ユニット・外部給電なし)。
つなぎ方は Bluetooth(BLE)の「広告」。電話のようにつなぎっぱなしにするのではなく、タイマーが一方的に「今どうあるべきか」を流し続け、LjPlay がそれを聞く。LjPlay も小さな広告で「自分は COM○○」とタイマーへ知らせる。

5-2. タイマーが流している中身(1 秒に 50 回)

項目	意味
再生 / 停止	いまショーを流すか止めるか
通し番号	指示が変わるたびに 1 つ進む。LjPlay は番号が変わったときだけ動く(同じ指示のくり返しでは何もしない)
ショーの経過(ms)	再生を始めてからの時間。15 時からは RTC の時計で数えている(5-5)
時刻合わせの回数	10 分ごと(毎時 00・10・20…分)に 1 つ進む合図
今の時刻(ms まで)	LjPlay が自分の時計(RTC)を合わせるのに使う
組番号・確認用の値	ほかの機器や別の組の指示を取り違えないため

5-3. LjPlay の動き

指示が変わったとき: 「停止」なら全チャンネル 0 で待つ。「再生」なら、経過が 2 秒未満ならその場で始め、それより先なら今のショーを出し続けながら裏で早送りして、追いついた瞬間に切り替える(DMX は止めない)。
演出の途中: 時計を飛ばさない。60 秒ごとにタイマーとのずれを測り、再生の速さだけを少し変えて寄せる(数十 ppm = 0.003% 程度で、見ても分からない)。始めてから 20 分は早めに、その後はゆっくり合わせる。
電波が届かなくなったとき: 止まらない。覚えた速さのまま再生を続け、戻ったらまた速さだけで寄せる。
PC からの「最初から」の命令: タイマーに従っている間は断る(ERR ble-sync)。全台を 0 から始めたいときは、タイマーで「手動 PLAY」をすると全台がそろって 0 から始まる。

5-4. 接続の状態の見方

11:43 のカメラの 1 コマ。中央がタイマー(上の帯に Bluetooth のマークと「23 27 74」)、左上が COM23、下が COM27。2 台とも経過 00:14:21.3・時計 11:43:44 でそろい、DMX の 20 ch に 23 / 27 が出ている

タイマーの液晶(11:31)。上の帯に聞こえている LjPlay の番号、右下に BL・LJ PLY・版・RTC OK

タイマーの画面のいちばん上: 青い Bluetooth のマークと、聞こえている LjPlay の番号(例「23 27 74」)。各 LjPlay が 0.5 秒ごとに出す小さな広告を、タイマーが聞いて出している。10 秒聞こえないと番号が消える。表示できるのは 8 台まで(受け取る側の台数そのものに上限は無い)。
LjPlay の画面の右上(「LjPlay」の右): Bluetooth のマーク。青 = タイマーの広告が届いている/白 = 指示の切り替えや時刻合わせのやり取りの最中/灰 = 3 秒以上届いていない(再生は続く)。
LjPlay の画面の下: 白い数字がショーの経過、その下のシアンの数字が本体の時計(タイマーの時刻に合わせてある)。
DMX の 20 チャンネル目: その LjPlay の番号(23 / 27 / 74)。受信機でどの機体の線かが分かる。
細かい数字: LjPlay は USB の命令 LJPLAY_STATUS? の 2 行目に、受信の強さ(rssi、今 −41〜−65 dBm で十分)・最後に受けてからの時間・測ったずれ・覚えた水晶の差を返す。タイマーは TIME? で、ms までの時刻とショーの経過を返す。

5-5. 今日わかったこと・直したこと

13:10〜14:11 の試験(1 時間): 時計の飛び 0 回、2 台の差 15〜20 ms、速さの補正は 20〜30 分で落ち着き、その後 1 分ごとの変化は ±1 ppm 以内。
ただし 2 台そろって PC(NTP)の時計より約 −15〜−17 ppm 遅れた(4 か月で約 3 分)。原因は、タイマーがショーの経過を RTC ではなく本体の水晶で数えていたこと。LjPlay は「月差 13 秒の RTC」ではなく、タイマーの水晶に従っていた。
14:20 に直した: タイマーが 1 分ごとに RTC の秒の切り替わりを ms の精度でとらえ、ショーの経過を RTC の時計から出す。NTP で RTC を合わせ直しても、ショーの経過は飛ばない。
14:38 にタイマーを NTP に合わせた(NTPSYNC): 前回(10-14)から 6.28 日で +988.6 ms 進んでいた = +1.8 ppm(月に約 4.7 秒)。合わせた後は NTP との差 −38 ms(測り方の誤差 ±31 ms)≒ 0。14:40:00.000(NTP の時刻)に手動 PLAY を送り、3 台がそろって 0 から始まった。
RTC 基準の試験(14:40〜15:41・3 台)の結果: 時計の飛び 0・送出失敗 0・再起動 0。速さの補正は 20 分で落ち着いた(COM74 ≒ 0・COM23 ≒ −16・COM27 ≒ −14 ppm = 各機体の水晶の差)。開始直後は 3 台が 30〜46 ms ずれていたが、速さだけで寄せて約 50 分で 10 ms 以内にそろった。COM74 は NTP の時計に対して約 −1〜−3 ppm で、±5 ppm(月差 13 秒相当)の内側。タイマー自身は NTP に対して +3.4 ppm。→ 月差 13 秒に同期できている見込み。
開始直後の直し(16:00 版): 開始の 15 秒後・42 秒後に位相で合わせるようにした → 開始 1〜2 分で 3 台の差 7 ms(前は 30〜46 ms で、そろうまで 50 分)。
DMX の ch15〜18 にショーの時計を出した(17:43 版): 受信機の側で 1 ms より細かく測れるようになった(同じ M5 を受ける受信機 2 台の差 0.3 ms 以内)。17:50〜18:11 の測定で、3 台の差は数 ms で一定、NTP に対して COM74 +2.7・COM23 +4.7・COM27 +4.0 ppm(タイマー自身 +3.2 ppm)。3 台ともタイマーに沿って動き、±5 ppm(月差 13 秒相当)の内側 = 月差 13 秒の時計に同期できている。4 か月の見込みは約 +30〜+50 秒(補正なしなら約 8 分)。
ほかに今日直したこと: PC からの「最初から」で 1 分後に元の時刻へ戻る件(断るようにした)、補正で 30 ms 前後の段が出る件(1 フレーム 8 ms までにならす)、2 時間のループの頭で毎回少し遅れる件(余った時間を次のループへ持ち越す)。

5-6. ほかの電波機器との混信

取り違え: 起こらない。LjPlay は「識別の文字・版・組番号・確認用の値」が全部合う広告だけを使い、スマホやイヤホンなどの広告は読み捨てる。
同じ作りのタイマーが近くに 2 台あると、両方の指示が混ざる。今は全台が既定の組(組 1・合言葉 0)。現場や部屋ごとに組番号と合言葉を分ければ防げる。確認用の値は誤操作よけで暗号ではないので、わざと偽の指示を出されることは防げない。
電波の混み合い(WiFi など): Bluetooth の広告は WiFi と重なりにくいチャンネルを使う。同じ指示を 1 秒に 50 回くり返すので、何回か取りこぼしても届く。時刻合わせも、60 秒分の受信のうち遅れの小さいものを使うので、取りこぼしに強い。
本体の負担: 8 台でも、タイマーの受信の処理は 1 秒に 16 回・メモリは約 100 バイト。DMX の送り出しは別の処理なので影響しない。

5-7. これからの課題

#	課題	次にすること
1	RTC 基準のタイマーで、NTP の時計に対するずれが ±5 ppm 以内に入るか	3 台とも ±5 ppm の内側を確認(5-5・ch15〜18 の時計で 20 分)。開始直後の差も 7 ms に直した。残りは 12 時間以上の確認(2 時間の頭を含む)
2	機種(CoreS3 / Core2)による DMX の出る遅れの差	3 台を受信機で測り、遅い機体の設定 `bleout_ms` に差を書く(14:36 の試しでは 3 台の差 22 ms)
3	時・分・秒のチャンネルが同じフレームでそろわない(1 フレームだけ「60 秒戻り」に見える)	データ(各シーケンスの 25 ms の刻み)か再生側かを調べる
4	電波が届かないと、次の開始・停止ができない	各 LjPlay が時刻表も受け取って保存し、自分の時計で始める・止める(「方式 B」)
5	近くに別のタイマーがあると混ざる / 偽の指示を防げない	現場ごとに組番号・合言葉を分ける運用。必要なら署名つきに
6	9 台以上を画面に出したい	表を増やし、表示を 2 段か台数にする
7	Core2 の USB シリアルが、PC からの開け閉めのくり返しで固まることがある(本体と DMX は動き続ける)	監視は開いたまま読む・間隔を空ける。抜き差しで戻る
8	出力の差し口	DMX の出力は PORT B に統一(PORT C は入力用)。COM75 は PORT C が使えなくなり休止、COM27 は SD カードの不良を交換

6. 関連の資料

動画(限定公開): 3 台の時刻・同期が無い場合の誤差(10-23・wnOYWvO5a8A) / 今日のまとめ・検査の方法つき(3OLXu9tA3ig) / 朝のカレンダー同期の試験(zwvHkVlxgIY) / 検査の目的と試験のしくみ(S3b6I4OOz0U) / DMX 止まりの解析(Z-DmcOEQaYQ)
前日の記事: M5Stack LjPlay の DMX が止まる原因の解析と改修(2026-10-19)
社内の資料(試験の記録): docs\M5_LjPlay_無人運用試験\ の 07_報告_2026-10-20.md(今日のまとめ)・05_観察記録_2026-10-20.md(§1〜§14)・06_時刻同期の要件と検査.md(要件と合格の条件)

7. 追記 2026-10-23: 3 台の時刻をタイムサーバと 2 時間比べた・同期が無い場合の誤差

3 台の時刻をタイムサーバと比べる(2 時間・同期が無い場合の誤差つき・約 3:32・音声つき・VOICEVOX:No.7)

時刻の出し方: タイマーと M5 2 台は、DMX の ch41〜50 に同じ形で時刻を出す(ch41〜45 = 版の日時 / ch46〜49 = その機器の時計の時・分・秒・1/100 秒 / ch50 = COM 番号)。ch1〜40 は演出。受信機の窓 3 つから Art-Net で 3 台を同時に受け、1 フレームごとに「届いた時刻(NTP)− 機器の時刻」を記録した。
開始: 14:32:00(NTP)にタイマーへ WiFi の Web 命令で LJPLAY(タイマーの USB は未接続。往復の半分だけ早く送った)。COM74 は 15 秒後に位相を 3.9 ms 合わせ、あとは速さだけで寄せた。
結果(14:32〜16:37・2 時間 5 分): 3 台の差は 4〜11 ms で 2 時間ほぼ一定(速さの差 0.1〜0.4 ppm)。送信の失敗・再起動・途切れ 0。3 台そろって NTP に対して約 +3.5 ppm 進む = タイマーの時計(RTC)の速さで、月に約 9 秒(月差 13 秒の内側)。値が −190〜−205 ms なのは、タイマーの時計がタイムサーバより約 0.2 秒進んでいるため(届くまでの遅れを含む)。

2 時間 5 分の記録。3 台の線が重なって動く = M5 2 台がタイマーの時計に従っている

録画のあとも観察を続けた: 4 時間 32 分(14:33〜19:05)

時刻(30 分ごとの中央値)	COM74	COM23	タイマー COM33	COM23 − COM74	タイマー − COM74
14:33	−173.8 ms	−169.0	−178.5	+4.8	−4.7
15:33	−186.4	−182.5	−190.6	+3.9	−4.2
16:33	−199.4	−195.7	−204.8	+3.7	−5.4
17:33	−213.0	−207.9	−216.8	+5.1	−3.8
18:33	−225.3	−220.1	−230.5	+5.2	−5.2
19:03	−229.3	−223.9	−233.6	+5.4	−4.3

3 台の差は 4 時間半を通して 4〜6 ms(動き ±1 ms 程度)。M5 2 台はタイマーの時計から離れない。
3 台とも NTP に対して同じ速さ(COM74 +3.59・COM23 +3.55・タイマー +3.74 ppm)= タイマーの RTC の速さ。月に約 9.5 秒で、月差 13 秒の内側。値が −174 → −229 ms と動くのは、3 台そろってこの速さで進むため(ずれが積み上がっているのではない)。
COM74 は開始から 4 時間 33 分、送信の失敗 0・over 0・再起動 0。BLE で見たタイマーとのずれ +0.4〜0.5 ms、周期の補正 −0.5〜−0.6 ppm で落ち着いていた。記録は 1 台あたり 31〜34 万件。
14:30 に監視から「0 から全部スタート」を押したとき、COM74 は ERR ble-sync で断った(同期中は PC からの 0 スタートを断る直しが、設計どおり働いている)。
残るのはタイマーの時計そのものの進み(19:00 で NTP に対し約 +0.3 秒)。タイマーをタイムサーバに合わせ直せば 0 に戻る。

4 時間 32 分の観察。3 台の線が重なったまま、タイマーの時計の速さ(約 +3.6 ppm)で一緒に動く

もし BLE の同期が無かったら(水晶のまま走った場合の最大のずれ)

条件	水晶の差	2 時間	6 時間	4 か月
COM74 単独	約 1 ppm	約 10 ms	約 20 ms	約 10 秒
COM23 単独	約 15 ppm	約 110 ms	約 0.32 秒	約 2.6 分
COM27 単独	約 13 ppm	約 90 ms	約 0.28 秒	約 2.3 分
10-19 に測った最悪の機体	73 ppm	約 0.53 秒	約 1.6 秒	約 12.6 分
2 台の差の最悪(10-19)	50 ppm	約 0.36 秒	約 1.1 秒	約 8.6 分
途中で BLE が途切れた(覚えた補正で走る)	2〜5 ppm	10〜40 ms	40〜110 ms	―

水晶の差は、各 M5 が同期の中で覚えた補正(10-20)と、10-19 の補正なしの測定から。温度で数 ppm 変わるので目安。BLE の同期があれば、どの機体もタイマー(月差 13 秒の RTC)と同じ速さで動く。

気づいたこと: 画面の録画が 96 分で止まった(DMX の記録は最後まで取れた。録画の道具を、止まったら続きを撮るように直した)/ch15〜18 の細かい時計は、ch1〜40 を演出に使う版で無くなった(いまは 1/100 秒で比べる)/タイマーは約 0.2 秒進んでいるので、タイムサーバに合わせ直す。

記録: 観察記録 docs\M5_LjPlay_無人運用試験\05_観察記録_2026-10-20.md §3・解析の道具 tools\dmx_sync_monitor\drift_vs_ntp.py・録画 rec\20261020_100922(40 分)

最終更新 2026-10-24 07:55(7 章を追記)