複数カメラの同期とバースト転送を検証する

この試験で確認すること

同時露光と同時到着は異なる要件です。露光の整列と共通回線のバースト負荷を別々に確認します。

本稿はメーカーに依存しない立上げ試験の方法です。設定変更前に、使用するカメラ、レンズ、センサ、制御装置の型式別マニュアルを確認してください。計算表の数値は仮定例であり、Deyi Visionの実測結果や製品仕様ではありません。

適用条件

共通ハードウェアトリガまたは仕様が明確な予約撮像を使います。PTPでは対応機能と時計の安定性を確認し、ロックだけで同時露光と判断しません。

同時露光、時刻同期、同一部品への画像紐付けのどれが必要かを分けます。全カメラとネットワーク機器の対応を確認し、PTPロックだけで露光同期を証明しないでください。各取得列を識別し、グループ内の欠落や重複を判別できるようにします。

試験機材と記録

共通点滅ターゲットまたは時間出力、カメラ別ID、時刻、通信カウンタを準備します。構成、パケット間隔、転送遅延、キュー深さを記録します。

部品・周期ID、カメラID、フレームID、露光、トリガ方法、時計の定義、完全受信をグループごとに記録します。共用リンクと受信キューも記載します。共通光イベントまたは文書化された出力を同じ測定器で観測し、露光との関係を残します。ソフト到着時刻では代用できません。

試験手順

1. 時計または共通入力信号を先に確認する。
2. 同期画像1000組を取り、光学ターゲットか出力で露光差を測る。
3. 本番容量とバースト頻度で全台を動かし、不完全画像とキュー増加を記録する。
4. 同時露光が必要なら対応設定で転送だけをずらし、再起動と時計マスター変更後に再試験する。

まず単独動作を確認し、次に全グループの必要メンバーを照合します。共通イベントで露光のずれを測り、転送完了とキュー増加を別に記録します。対応する送信ずらしを使う場合も露光試験を続け、受信改善が同期悪化を隠さないようにします。

仮定条件による計算表

仮定例では4台が各2 MBを10 fpsで送信し、平均80 MB/s、1組のバーストは8 MBです。有効100 MB/sと仮定すると排出に最低80 msを要し、通信オーバーヘッドは含みません。

aggregate_payload = cameras * bytes_per_frame * fps
4 * 2 MB * 10 = 80 MB/s
burst_drain_time >= 8 MB / 100 MB/s = 80 ms
clock_offset != exposure_skew != delivery_skew

平均帯域は長期負荷、バースト排出時間は瞬間負荷を示します。経路の実効帯域は測定または根拠が必要です。排出前に次が始まれば平均が低くてもキューが増えます。オーバーヘッドと受信動作を考慮し、計算した最短時間をタイムアウト設定とはみなしません。

試験の流れ

結果の読み方

露光が同時でも到着は異なり、到着が同時でも露光は異なり得ます。グループIDごとに露光ずれと転送完了を別に表示し、不完全グループも残します。まれなずれで移動部品の測定が無効になるなら、平均だけの安定性では不十分です。

トラブルシューティング

• 平均帯域に余裕があってトリガごとに損失するならバースト競合を疑う。
• 受信時刻が近くても露光同期とは限らない。時計系が異なる時刻は直接比較できない。

グループだけ失敗するなら単独試験と受信統計、共用ボトルネックを比較します。時刻ドリフトでは全期間の同期状態とオフセットを記録します。重複メンバーは周期紐付けを先に確認します。再接続後はグループIDと時計も再検証します。

受入判定と引継ぎ

露光差、画像完全性、到着期限の限界を別に定めます。最悪バーストで時計安定とキュー上限を確認し、時計変更後の再収束も記録します。

生データ、設定、試料ID、判定限界を一式で保存してください。関連製品と事前準備のガイドを参照し、記録した要件をDeyi Visionに相談できます。

新しいグループで露光整合と完全受信の両方を本番ホスト負荷、最大想定形式、トリガパターン、共用通信下で確認します。欠落カメラや不完全グループは明示的な無効判定にします。台帳、同期観測、転送設定を保存し、カメラや帯域変更時に再検証します。