Skip to content

frame limit 256

Jump to bottom
GeneralD edited this page Jun 24, 2026 · 1 revision

実験: LED アニメーションのフレーム数上限 = 256(2^8)

CyberBoard R4 の Custom LED スロット(page 5/6/7)に詰められるアニメーション フレーム数の真の上限を実機で確定した記録。

問い

純正 AM Master / コミュニティ製 merger では「フレーム数が 300 を超えると 書き込めない」とされていた。これは アプリ/UI の制約か、firmware/ハードウェアの 制約か? そして真の上限はいくつか?

手法 — 「数字を描くフレーム」

ACK(JSON_END の rev[2]==1)は受理を意味するだけで、実際に格納・再生 された証拠にはならない(garbage in, ACK out)。LED フレームには読み戻し経路が 無いため、目視が唯一の ground truth。

そこで各 display フレームに自分の index を数字で描画した(40×5 マトリクスに 3×5 ピクセルフォント)。スロットが 0,1,2,… と数え上げ、ループ(0 に戻る) 直前の最大値+1 = 実際に再生されたフレーム数。generate_numbered.py 参照。

結果(実機 R4, 2026-06-22)

書き込み ACK 再生で観測した最大 index 結論
1 スロット × 30 枚 ✓ 29 → ループ 手法の妥当性確認(30 枚=正しく全再生)
1 スロット × 400 枚 ✓ 255 → ループ 256(2^8)で頭打ち。ACK は通るが 256 枚しか再生されない
1 スロット × 800 / 1600 枚 ✓ (未計測) ACK は上限を示さない(1600 でも受理)
2 スロット × 各 200 枚 ✓ 両方 199 → ループ per-slot(各スロット独立。合計 400 でも両方フル再生)
3 スロット × 各 300 枚 ✓ 各 255 → ループ per-slot 256 を 3 スロットで再確認。300 枚送っても 256 で頭打ち
公式 UI 作成 300 枚(256〜299 に赤マーカー) ✓ 赤マーカー出ず 公式オーサリング設定でも 256 で頭打ち(後述)

公式オーサリング設定での最終確認

「自作ツールのエンコードが怪しいのでは」を排除するため、純正 AM Master の UI で 作成した 300 フレーム設定(AM CB Index (1).json)を使って追試した。元アニメ (0〜78)+ 暗転区間(79〜255)の後ろ、256〜299 を赤ベタ(#FF0000)で上書きして 書き込み(キーマップは merger 既知正解を保持、frame_num=300)。

→ 実機スロット 1 で 赤ブロックは一切表示されなかった(256 以降に到達しない)。 自作エンコードでも公式オーサリング設定でも結果は同一 = 256 上限は firmware 由来で確定。

結論

  • 真の上限 = per-slot 256 枚(2^8)。firmware の再生 index/カーソルが 8 ビット。 プロトコル上は frame_num・display frame_index とも 2 バイト送出できるが、 firmware 内部が uint8 のため 256 で切る。
  • per-slot 独立。3 スロット合計では 256×3 = 768 枚まで使える。
  • 「300」は純正 AM Master のドット作成画面の作成上限(UI ハードキャップ)で、 merger の MAX_FRAMES=300 はこれを写した値。どちらも真の 256 を捉えていない過大マージン。
  • 帰結: 純正ツールで 257〜300 枚目を作り込んでも永遠に表示されない(作成上限 300 と 再生上限 256 の不一致)。本プロジェクトのツールは firmware を直叩きするため、 各スロット 256 枚をフルに活用できる。

3 段モデル(確定)

層 上限 由来 性質
firmware 再生 256 / スロット 再生 index/カーソルが 8 ビット 真の上限。超過分は永遠に表示されない
公式 UI 作成 300 / スロット AM Master ドット作成画面のハードキャップ 作り込めるが 257〜300 は死にフレーム
プロトコル / ACK 実質無制限(frame_num 2 バイト=最大 32767) 64B フレーム構造 ACK は受理を示すだけ。上限を示さない

補足: 256 超が「未格納」か「格納はされ再生カーソルだけ 8bit ラップ」かは LED 読み戻し 経路が無いため外部から区別できない。実用上はどちらも「使えるのは 256 枚」。 per-key(keyframes)側は frame_index が 1 バイト送出のため構造上も 256 上限(別途要確認)。

ファイル

  • generate_numbered.py — 数字描画フレームの生成器(--write で実機書き込み)。
  • base.json — 中立なスケルトン設定(個人キーマップを含まない。証拠生成の土台)。
  • three-slots-300frames.json.gz — 証拠: 3 スロット × 各 300 枚の数字フレームを 詰めた設定(2.0MB → gzip 16.6KB)。これを書き込むと各スロットが 255 でループする。

再現

# 証拠 JSON を再生成(スケルトン土台)
python generate_numbered.py --frames 300 --slots 5,6,7 --out three-slots-300frames.json

# 実機へ書き込み(キーマップ保護のため実設定を土台にする)
python generate_numbered.py --frames 300 --slots 5,6,7 \
    --base /path/to/your/known-good.json --out /tmp/dev.json --write
# → 各 Custom LED スロットが 0..255 でループ(300 枚送っても 256 で頭打ち)

実機書き込みは既存のキーマップ等を保持するため --base に実設定を指定する (base.json スケルトンを書くとキーマップが消えるので注意)。証拠 JSON 自体は 個人情報を含めないためスケルトン土台で生成している(LED フレーム部=検証対象は同一)。

Clone this wiki locally