【Next零 ;更新記事】


機材台車
(伊波桜化)



Canon HF G20
ワイコン比較テスト



自作LANCリモコン
製作レポート



JVC GY-HM650
試用レポート



Bluetoothインカム



EDIUS @ Mac



FUJINON XT17s
レンズレポート



EDIUS6 レポート



LEDビデオライト
SONY HVL-LBPA



GPGPU と NLE



HDR-XR520V
使用レポート



FIRECODER Blu
レポート



Core i7 で NLE



HVR-S270J
関連レポート



HD→SDダウンコン検証




【Note; Affiliate】

rss 1.0


楽天市場



B&H



Amazon.co.jp



・ ・ ・

 >>Grass Valley
 >>Adobe
 >>SONY
 >>Panasonic
 >>Manfrotto

 >>楽天市場
 >>ビデオ近畿
 >>SYSTEM5
 >>kakaku.com

【Next零 ;Key Contents】


reTMCD



Eye-One Display2
レンタル



非公式データバンク
EDIUS Bench



HVR-S270J
関連レポート


【Note; Affiliate】




サウンドハウス




Article offer cooperation


* * *
ACC*Software Leading...


Hosting Management by


* * *

BBS7.COM
MENURNDNEXT



〜 創想雑誌 〜


−>>2017/10/03/(Tue) Switching Logger (_prt)

■はじめに
 この度、タイムコード・ラボでは「Switching Logger(_prt)」を開発した。


 この黒い箱は、映像スイッチャーのスイッチング情報を、タイムコードと紐付けて記録するための装置である。
 「Switching Logger」を使うことで、収録現場でのスイッチングを XML形式を介してノンリニア編集機のタイムライン上で再現する事が可能で有り、スイッチング収録後の修正編集、フィニッシングを容易にする事が可能となる。

 「Switching Logger(_prt)」は、Roland V-1SDI のスイッチングトリガーを受けて、スイッチングされた瞬間のタイムコードを付加して、ログを取る単純なシステムだ。
 タイムコードは、各カメラや本線収録機にも分配され、全て同期している。


<「Switching Logger」には V-1SDIのシリアルデータと外部タイムコードを入力する>



 つまり、タイムコードが同期している要素として、
.好ぅ奪船鵐哀織ぅ潺鵐哀如璽
∨楡収録
3謄メラのパラ素材

 を得ることが出来る。

 これらのデータを、統合することでノンリニア編集プロジェクト上に現場スイッチングを再現することが可能となる。


■旧来の現場スイッチング
 現場スイッチング収録の最大のメリットは、編集時間の短縮だ。
 例えば6時間のイベント記録の場合、現場スイッチングであればイベント中にリアルタイムでスイッチングを行うために、基本となるスイッチングは当日の6時間で終わり、後日の修正編集は短時間で済む。
 一方、現場でスイッチングせず、カメラでパラ撮りした素材をノンリニア編集上でスイッチング(マルチカム編集)する場合、編集を作り込むことは出来るが、その代わり6時間のイベントをもう一度再生しながらスイッチングする必要があり、後編集の時間が膨大になる。


 ただし、現場スイッチングもメリットばかりではない。
 後日の修正編集が手間なのだ。
 通常、マルチカメラによる現場スイッチング収録では、スイッチングアウトを本線収録として、それを下敷きにして、スイッチングミスやカメラミス、または構成の変更を行う。
 ただ、本線収録はノンリニア上では一本のクリップとして認識されるため、スイッチングのタイミングは、編集者が見つけ出してカット点を付け加える必要がある。


<ノンリニア上では一本のクリップに見える為、スイッチング点を探す必要がある。>


 例えば、スイッチするカメラを入れ替えたい場合は、該当箇所を見つけてそのIN/OUT点をカットして、次に本線に同期さているカメラ素材と入れ替える必要がある。
 さらに、ディゾルブ箇所の変更などを行いたい場合は、ディゾルブが適用されている2つのカメラに跨がった部分のIN/OUT点を見つけて修正を行う必要がある。ディゾルブが連続している場合は、1カ所の修正のために前後の数カット分もやり直す必要があるだろう。

■「Switching Logger」のメリット
 「Switching Logger」を利用した場合は、ノンリニアのプロジェクトに展開された段階で、全て編集点(カット点)がついている為、カメラの入れ替えやタイミングの修正は簡単だ。
 従来のノンリニア編集上のマルチカム編集と同じ手法で修正が行える。


<ノンリニア上ではこの様に表示され、編集点やONタリーカメラの把握が容易。>

 
 この場合、ノンリニア編集ソフトのタイムラインが本線収録と同等と考えられるので、極端な話、現場で本線収録をする必要も無い。
 スイッチャーを持ち込むにも拘わらず、本線を巻き取る必要が無いのである。

 さて、この「Switching Logger」には、ノンリニア編集での修正を容易にするというメリット以外にも幾つかのメリットが生まれる。

A:出力の遅延したカメラを使用できる
B:HD収録に4Kカメラを活用できる
C:カメラ情報(キャラ)を出したままにできる


 以上が考えられる。
 以下、具体的に解説していこう。

A:出力の遅延したカメラを使用できる
 これは、昨今散見される問題で、カメラの HD-SDI や HDMI からの出力映像が何フレームか遅延しているという物だ。
 カメラ側の処理が高度化した為に、最終的な出力が送れてしまっているという問題だ。
 特に、4Kカメラから HDにダウンコンした場合に大きな遅延が見られるため、従来のスイッチング現場では、そういったカメラは混成不可能と言われてきた。
 しかし、遅延しているのは飽くまでも出力であって、カメラ内部の記録ではない。
 「Switching Logger」を使うシステムでは、ノンリニア編集上でのタイムラインが本線であり、カメラで収録された素材を直接参照するため、現場の出力の遅延は問題にならない。
 「Switching Logger」を使うことで、出力遅延のあるカメラも混成することが可能になる。

B:HD収録に 4Kカメラを活用できる。
 HD収録が基本となる収録に 4Kカメラを利用することのメリットは、編集時に拡大やズームワーク、またはパンなどができることだ。
 しかし、スイッチング収録の現場では 4Kのカメラを入れたとしても、本線はHDで収録されてしまっており、また編集時には1本になっている本線収録クリップ内から、4Kカメラを活用したカットを見つけ出して、そのIN/OUT点を手動で付けて、4Kカメラで収録した素材に置き換えて、拡大などの処理をする必要があり、4Kカメラを使えば使うほど手動作業が増えて面倒になってしまう。
 しかし、「Switching Logger」では、何度も繰り返すように、既にノンリニア編集上でのタイムラインで編集点が付いており、4Kカメラを使った箇所は明確になっており、直ちに 4K素材に対して任意の処理を掛ける事ができる。
 積極的に4Kカメラを使っても、編集時に苦にならない。

C:カメラ情報(キャラ)を出したままにできる。
 カメラ出力(HD-SDI や HDMI)に、撮影情報(アイリス値やズーム、REC状態など)の表示をスーパーインポーズしたまま、スイッチングできる。
 本来であれば、キャラ付きの本線収録は事故以外の何物でもなかったが、「Switching Logger」を使うことで、飽くまでも活用するのはカメラ本体が収録するファイルとなるため、カメラ出力をキャラ付きにしても問題ない。
 小型スイッチャーとデジなどを使ったマルチカム収録現場は、低予算でスイッチャーがスイッチングをしながら幾つかの役務を兼任することは当たり前になっている。
 別途 VEを用意したりすることは難しいので、カメラの状態監視はそれぞれのカメラマンの責任なるが、その点では事実上スタンドアローンと変わらないので、事故やミスも起きやすい。
 キャラ付きの映像をスイッチャーベースで確認できることで、録画忘れやメディア残量チェックの他、誤ってゲインやシャッターが入っていたり、フォーカス値が極端に狂っていたり等の状態を把握することができる。
 また無人カメラの状態も、同様に確認できるため、安心感が違うだろう。


■現場への導入
 先日、これらのメリットを活用すべく、マルチカメラ収録の現場に「Switching Logger」を導入し、収録を無事に終えることができた。


 写真の通り、4Kミラーレスカメラの DC-GH5 をセンター引きカメとして使用し、スイッチャーに入力している。
 GH5は舞台全景よりもやや広めに画角を作って安全マージンを確保し、編集時に53%ぐらいに修正してやることで舞台全景にする。

 また、4Kからのダウンコンなので少々の遅延があるが「Switching Logger」のシステムには関係ない。

 さらに、無人配置したGH5のメディア残量の把握や、各有人カメラの状況を把握する為に、HD-SDI や HDMI にはキャラ(文字情報)を載せたままにしている。
 そのため、メディア残量を心配したりREC忘れを憂慮することもなく、また有人カメラに対してはアイリス値を見て値を揃えさせる指示をだせたり、フォーカス値が舞台撮影ではあり得ない数値になっていたため修正を促したりできた。

 一応、テストでスイッチングアウトを本線として収録しているが、当然 GH5は遅延し、キャラが乗ったままの本線収録ファイルができあがっている。
 もちろん、この“本線収録”を利用することはない。


<それぞれのカメラ映像にも、本線収録(左下)にもキャラが乗っている>



■XMLへの変換と課題
 さて「Switching Logger」は「何時何分何秒何フレームに何カメをスイッチしたか?」というデータがひたすらログとして記録されるだけで、そのログ自体はノンリニア編集のプロジェクトデータになっていない。
 この「時間とスイッチ」のデータを元に、ノンリニア編集ソフト上で読み込めるプロジェクト形式にコンバートする必要がある。
 当初は、単純に EDLにコンバートする事を考えたが、EDLの場合は本線収録にカット点が付いただけのプロジェクトになってしまい、裏……つまり“OFFタリー”のカメラを扱うのに向いていない。
 その為、XML仕様で編集プロジェクトを組み立てることにした。

 XMLであれば、タイムラインをそのまま再現できる為“ONタリー”と“OFFタリー”のカメラの把握と活用が容易になる。


<明るい部分が“ONタリー”、暗い部分が“OFFタリー”状態だ>


 また、XMLであれば一般的なノンリニア編集ソフトがそのプロジェクトインポートをサポートしているため、様々なソフトで編集を行う事ができる。
 私がテストしているだけでも、EDIUS 、Premiere、DaVinci Resolve、Final Cut Pro で XMLの利用が可能である。

 また「Switching Logger」も、仕組みとしては「スイッチングした」というトリガーにタイムコードを紐付けているだけなので、スイッチャーを Roland V-1SDI に限る必要も無い。
 特にタリー出力のあるスイッチャーであれば、それをトリガーにしてタイムコード付きのログを取ることが可能だ。


 さて XMLの活用だが、現時点では XMLの仕様を把握し、サンプルとしての XMLベースの編集プロジェクトの生成に成功しているという段階だ。
 まだ、ログからの XML生成は開発途上にある。

 また、今回の XML検証で分かった事は、EDIUS の XMLインポート機能には幾つかのバグが見られるということで、結構苦労している。
 最大の問題は、XML上に記述されている「クリップの有効/無効」のフラグが認識されていないことだ。
 つまり、ONタリーのクリップもOFFタリーのクリップも関係なく、全てON(有効)になってしまっており、このままでは最上段トラックのクリップがひたすら再生されるだけになってしまう。


<EDIUSでは全てのクリップが有効……ONタリーになるため、実際には最上段の紫のクリップしか表示されない>


 当然、他のノンリニア編集ソフトは、ちゃんと 有効/無効フラグを認識しており、正しいスイッチングタイムラインを再現している。


<同じ XMLファイルを読み込んだもの。EDIUSだけ他のソフトと処理が違うのが分かる>

 

 このバグは、早期に EDIUS側が修正してくれると思うが、修正までにこちらの収録案件の納期が間に合わないので(笑)、解決策を思い付いた。
 有効クリップだけマージして、最上段のトラックに並べてしまうのだ。
 勿論、EDIUS内のマルチカム編集のマージ機能は使えないので、XMLにコンバートする段階でマージトラックを生成してしまうつもりだ。
 当然、パラ収録素材が並ぶトラック上で、ONタリークリップを把握するのは面倒だが、スイッチング本線をタイムライン上で再現するという目的は果たせるし、修正作業自体には大きな不利にはならないだろう。
 


<有効クリップだけマージするという苦肉の策。EDIUSのバグ修正に期待だ>



 さらに現在、再現条件の確認中なのだが、例えば12:59:00;00をタイムラインの冒頭タイムコードにして、そこにクリップを配置した XMLをインポートすると、何故か24時間後の 12:59:00;00 にクリップが配置されてしまう。
 最初、冒頭タイムコードを設定した XMLをインポートした際に、クリップがタイムラインに配置されなかったため、冒頭タイムコードを設定すると、EDIUSはクリップを読み込めないバグがあるのかと思ったが、タイムラインを縮小してみると24時間後の部分に配置されていて、目が点になった……。 
 勿論、その他の XML対応のノンリニア編集ソフトではその様な問題は起こっていない。

 さらにさらに辛いのが、EDIUSには XMLエクスポートの機能が無いことだ。
 「Switching Logger」での XML生成ワークフローでは、一旦、ノンリニア編集ソフトのタイムライン上で、各カメラの素材クリップを各トラックに配置して、その同期だけは合わせておく必要がある。
 これは同期が合っているだけのノーカットのタイムラインプロジェクトになるのだが、その状態を XMLとしてエクスポートして、それによって生成された XMLをベースにして「Switching Logger」で取得したカット点を自動的に挿入していく仕組みだ。
 その為、ノンリニア編集ソフト上でのクリップの同期合わせは重要な作業なのだが、EDIUSに XMLエクスポート機能が存在しないために、他のソフトを使って作業をする必要がある。
 しかし、使い慣れていないせいもあってか、他のソフトが非常に使いにくい。
 タイムラインの初期タイムコードの設定の仕方も分かりにくかったが、素材クリップが持っているオリジナルのタイムコードをどこで確認したら良いのか分からないので、トラック間の同期合わせや、そのクリップとタイムラインのタイムコードの一致させ方などが分からない。
 このシステムでは、タイムラインのタイムコードと素材クリップのタイムコードも揃っている必要があるのだ。
 つまり、タイムコードをフリーランで走らせた素材クリップで、13時に収録が始まったとすれば、タイムライン上の13:00:00;00に素材クリップの13:00:00;00を配置する必要がある。
 まぁ、この仕様は「13:00:00;00を00:00:00;00とみなす」というタイムコードのオフセット処理を掛ける事で変更可能であるが…(と言うことを昨夜の風呂で思い付いた)

 いずれにせよ、EDIUS をメインソフトで編集している私としては、EDIUS は XMLの取扱に対しては最も遅れているノンリニア編集ソフトであるということを、初めて認識させられた。
 当初、クリップの有効/無効フラグを認識できていないと知ったときは、本気で編集ソフトの乗り換えを考えた。
 その後すぐに思い付いた解決策を見出さなかったら、DaVinci Resolve へ移行していた可能性が大きい(笑
 ともあれ、EDIUS には XMLの取扱に対して、今後大きく改善を望みたい。


■デジ主体の現場スイッチングの未来へ
 本文で、しれっと登場している Roland V-1SDI は実はこの8月に購入した物だ。
 私にとっては、初めてのスイッチャー機材だ。
 実は「Switching Logger」は、V-1SDIを導入してから思い付いた物ではない。
 自分が業務にスイッチャーを導入するならば、必ず必要となる修正編集のワークフローを十全に(楽に)してからでないと、労力が嵩むだけだと思い、ずっとログシステムのことはアイディアとして温めていた。
 いよいよスイッチャーを用いる業務が増えてきて「Switching Logger」を現実の物にする必要が迫ってきた時に Roland V-1SDI であれば、RS-232Cからのシリアルデータもリファレンス公開されており、思い描いているシステムが作れると確証できたので V-1SDIを「Switching Logger」実現のために導入したのだ。


<2017年夏、プログラマーの松ケンとの開発風景>


 勿論、先にも述べたように、このシステムはスイッチングトリガーを取り出せるスイッチャーであれば、どれにでも応用可能だ。

 ただ、この「Switching Logger(_prt)」はプロトタイプだ。
 現在の仕様では、V-1SDIの RS-232Cから出ているシリアルデータを利用しているが、取り出せる情報が少なく、発展性には課題がある。
 今後は USB-MIDI側のデータを利用して、更に応用を進めていく予定だ。
 既に発展的な利用方法を企画・提案しており、「Switching Logger」を中核としたデジクラスでのマルチカム・スイッチング収録の現場環境を改善していく計画である。
 いずれ、改めて公開したい。


 「Switching Logger」は、現場スイッチングによるメリットと、マルチカム編集でのメリットを両立させることが出来るシステムである。
 もしくは、現場スイッチングによるデメリットとマルチカム編集によるデメリットを排除したシステムである。

 まずは、先日のマルチカム収録案件で基礎となる「Switching Logger」のシステムを確立し、未来の開発に繋げていきたい。


「Switching Logger(_prt)」


△このページのTOPへ戻る

コメント

君島里之(2017/10/09 12:14)
素晴らしいです。流石ですね。FaceBookでも書きましたが、私もこんな物を作ってみました。https://youtu.be/Hg-IZBUF4Y0
ediusでのedlリストはマルチカメラ編集にはダメだと思って、ハードウェアで考えた結果、こういうか形になりました。
xmlファイルというのを初めて知りました。実体は未だ見た事がありませんが。それとtimecodeとタリー信号とを紐付けて記録することが、私の能力では、てきませんでした。arduinoで出来る事は際限ないですね。これからの発展を楽しみにしています。

宏哉(2017/10/12 14:34)
ありがとうございます!
DTMF信号を拾って、テンキーのシグナルに変換して現場スイッチングを再現する!っていうのに、思わず唸ってしまいました。いろいろなアイディアがあって楽しいです!
必要は発明の母! これからも色々なアイディアを形にしていきたいですね!

Name   Message 
 日本の首都を入力する認証です→ 


−>>2017/09/28/(Thu) メルボルン2017。


 只今、オーストラリアはメルボルンで取材中だ。

 先日のロンドン取材を無事に終えて、今度はメールボルンへの移動。
 イギリス ― オーストラリアを結ぶ飛行機の直行便は2017年9月現在存在しないため、ロンドンから一旦 羽田/成田と日本を経由してから、メルボルンへ向かった。(※2018年春にパース ― ロンドン/飛行距離:14,498キロ/ 飛行時間:約17時間の航路が開かれる予定)

 
 さて、メルボルンを訪れるのは6年ぶり。オーストラリアに来るのも2年半ぶりだ。
 メルボルンの街には高層ビルが増えた印象で、今も新しいビルの建築があちらこちらで続いている。

 ロケ初日は、曇ったり雨が降ったりとグズついた天気だったが、翌日からは晴れが多くなり、外ロケも順調に進んでいる。
 


 この記事を書いている今日は、メルボルン最終日。
 まだ幾つか取材ネタが残っていて、何れもグルメネタなので重たい撮影だ。
 
 最後まで頑張ろう!


△このページのTOPへ戻る

 

コメント

Name   Message 
 日本の首都を入力する認証です→ 


−>>2017/09/18/(Mon) 渡英。

 イギリスはロンドンに滞在中です。
 昨日、関西を台風が襲う前に東京・羽田に向かいフライト。
 現地時間の夕方に到着し、翌日の今日からロケ開始です。


 ロンドンは曇天が基本と聞いていましたが、今日は青空も顔を覗かせて、その機会に実景も撮影します。
 ……ですが、やはり基本は曇天。しかも時折冷たい雨も降り、服装は晩秋ぐらいの暖かな格好でないと、風邪を引きそうです。
 それでも中には、半袖Tシャツで街を歩いている白人男性もいたりして、見ているこっちが寒くなります…。


 実は、私にとってはイギリスは初めて。
 以前、トランジットで立ち寄った事はありますが、トランジットは訪問国数に数えないので、今回が初渡英です。
 とりあえず、美味いものがないと聞く英国で「フィッシュアンドチップス」は外せないだろうということで、初日の晩ご飯は、それに。
 ……ま、世界中何処で食べても同じですね(笑
 結構私はフィッシュアンドチップスは好きなので、色んな国で食べてます。
 なお、2日目の今日はインド料理屋さんでカレーにしました。


<本日の撮影は、ロンドンで人気のスイーツ!>


 さて、今日はまだ60分もカメラを回していません。
 しかし、明日からは忙しくなりますよ〜!
 初イギリス、しっかりたっぷり楽しんできます!


△このページのTOPへ戻る

コメント

Name   Message 
 日本の首都を入力する認証です→ 


−>>2017/09/14/(Thu) SONY PXW-Z450 投入。

 去年の冬頃から関西の某大手ケーブルテレビ局で、携帯電話の電波帯域を使った IP生中継の仕事をさせてもらっています。
 番組ではスポーツからカルチャー、お買い物情報まで、関西を中心とした話題を扱っています。
 番組中に生中継コーナーがあり、私が担当するのはスポーツやグルメなどのネタが多い様です。
 なお、カメラ的には 7〜8分程度の生中継をカメラ一台だけで現場を見せ切る仕事になります。


<SONY PDW-850 に Teradek BOND Pro を抱かせて IP中継を実現>


 使っているカメラは、SONY PDW-850。
 ショルダーマウントタイプの XDCAM カメラです。

 が、今日はカメラに大きな変化が!
 今日は、SONY PXW-Z450 を投入!!!
 そう 4K ENGカメラです。


 そこに、私のお気に入り"HDVF-EL30”がVFとして装備!


 さらに、レンズは FUJINON UA18×5.5BE !!
 これは私が大好きな同社の HA18×5.5BE の 4K Premier モデルです。


 まさに 4K ENG の標準スタイルとも言うべき仕様で、今日の IP生中継に臨みます!!!
 が、中継自体は HD で、Z450 自体も HDフォーマットに設定。
 IP伝送帯域も3Mbps前後ですので、4K のアドバンテージはありません。

 実はこのZ450は「中継」ではなく「ロケ」で使われており、今月になって導入されたばかり。
 カメラが空いているときは中継にも持ち出して良いということだったので、私のわがまま……というか私欲を出して、今日は中継現場に Z450 を持ち出させてもらいました。
 中継での使用実績が無かったので、そのチェックも兼ねて、という事で。

 画質は判断ができない現場なので画質の事は脇に置いておきますが、カメラとレンズと VF は使い易い組み合わせです。

 VFの"HDVF-EL30”は、やはり見やすいし、液晶モニタが上部に付いているお陰でディレクターや演者さんに画を確認して貰いやすいのが良いです。

 また、最近のカメラには搭載されている仕様ですが、アサイン設定で、レンズ鞍のRETボタンに拡大フォーカスが割り当てられるので、担ぎでENGを振っていても、レンズから手を放すことなく拡大フォーカス機能が使えるのが素晴らしいです。(デジでは当たり前だったけど)
 あと、拡大した映像が HD-SDIアウトされないのも GOOD(笑
 信じられないことに SONY HVR-S270J は拡大フォーカス機能を使うと、HD-SDIアウトも拡大映像が出力されるので、外部収録などでカメラアウトを使っている時は拡大フォーカス禁止なんですよね。
 その問題を SONY にメールで投げたら、何の返信も無かったですね〜。はは〜ん☆

 そして、FUJINON UA18 の引き尻と望遠端の使いやすさ。
 1カメで7〜8分間の生中継一本撮りをしないとイケないこの現場では、最高に使い易いレンズです。
 狭い店内での複数人出演や、料理のドン寄りなど、広角から望遠まで必要十分な焦点距離を確保できます。HA16の様なテレ端での極端な Fドロップや滲みなどもないので、HA16で失敗した〜って思っている方も、是非帰ってきて欲しいですね! HA18 や UA18 に!

 もうホント、資金や償却などを考えず、趣味的に今一番欲しい組み合わせが、PXW-Z450 + HDVF-EL30 + UA18×5.5BEですね〜。

 いや、そんな SONYさん永久貸与とか、いいですよ、大丈夫ですよ〜。え?どうしてもって言うなら…。
 FUJINONさんも、そんな無期限貸出とか、困りますよ〜。え、どうしてもって言うなら…。
 そういう夢を毎晩見ています orz...


 さて、残念ながら結局は本番では Z450 は使いませんでした。
 中継リハーサル中、ガンマイクの SENNHEISER MKH416-P48U3 をカメラ直刺しで使おうとすると、ちょっと原因不明のノイズが…。
 バリバリとかいうノイズではなく、キュルキュル?みたいなノイズ音が連続もしくは断続的に出てしまい、予備で持って行っていた SONY PDW-850 だとその現象が出ないという症状…。
 事前の音声チェックの時は出ていなかったと思うのですが…。

 生中継中に出ると、どうしようも無いので安全第一を考えて、いつも使っている PDW-850 を本番では使用しました。
 残念……。


<予備機として SONY PDW-850 を持って行っておいて良かった…>

 

 現在は引き続き原因究明中ですが、今日は Z450を実験的に現場に持って行って正解でした。
 予備機がある状態で、こうしたトラブルを発見できたことに意味があった訳です。
 次に中継現場に放り込む頃には、原因が特定されて、症状が改善していることを願っています。

 そして、是非とも PXW-Z450 を現場で振り回してみたいです!


△このページのTOPへ戻る

コメント

Name   Message 
 日本の首都を入力する認証です→ 


−>>2017/09/05/(Tue) arltcsw-master。

 先日の Arduino Leonardo とブレッドボードで作ったプロトタイプの電子回路を、ユニバーサル基板に実装して、外装を施して、現場で使えるレベルの物にする。

 ユニバーサル基板やコネクタ、そしてケースなどを日本橋で買って帰って、作業に取り掛かる…。


 と、その前に、回路図の整理だ。
 想定回路図と実際のプロトタイピング時の実装では、相違が出てる部分がいくつかあったので、そこを洗い直し。
 回路図も自分が分かりやすい様に、書き直した。



 回路構成は、大きく分けて3つ。
 信号Aを読み取る回路と、信号Bを読み取る回路、そして信号Bが正常に入力された際に点灯するパイロットランプ回路Cだ。
 回路Cは、ダイオードを点灯させるだけなので単純。最初に取り掛かる。
 Arduino 側で、信号Bが正常に入力されていれば LEDを点灯させる命令を書き加えるだけで良い。


 次に、回路構成が単純な信号Bを構築。
 信号増幅用のトランジスタを中心に回路を組む。

 最後に、信号A用の回路。
 こちらは、ICチップを介して入力信号Aを TTL に変換している。


 電子部品の基板実装が済めば、信号入力用のコネクタやケーブル類をケースに取り付けて、基板に配線する。

 とりあえず、回路図通りに組み上がった!!
 早速動作テストだ。


 回路を中心に、PCとUSB接続。
 信号Aと信号Bを発生させる機器にもそれぞれ接続し、テスト!!!

 !!!?
 おかしい!
 信号Aは正常に入力されているが、信号Bが不正だ。
 正常に入力されていれば、点灯するはずの LEDも点かない。

 配線ミスか? そもそもの回路図間違い?
 何が原因か?
 回路図を攫い直しながら、ブレッドボードで組んだプロトタイプ回路と比較する。
 実際に使った電子部品なども一つ一つチェック。
 間違いは無い…。

 ……なんだ。

 ここは基本に立ち返って、テスタで 1端子ずつ測っていこう…。
 と、幾つかのパーツの測定をしていると、信号Bの入力のグランドが落ちていない。おいおい…。
 見た目はちゃんとハンダ付けされているように見えているのだが、テスターで反応がない。
 確かにパソコン側のシリアルモニタで確認した無意味なログの文字列も、それなら納得いく。
 今一度、しっかりとハンダ付けをやり直して、再びテスト!


 信号Bを入れた瞬間に、LEDが点灯。
 さらに信号Aを入力してやると、理想通り……設計通りのログが取り出せた。

 おおおおおお、夢にまた一歩。
 あとは、取り出したログを、必要なフォーマットに変換するアプリを作るだけだ。
 ここまで来れば、完成したも同然。
 最終段のアプリ制作は、松ケンの手に掛かれば幼稚園児の砂遊び程度の作業だろう(笑)


 実際には、松ケンが回路の特性解析を行うと、今の回路構成では信号Bの系統に少し危うい部分があり、正式版ではコンパレータを使って分圧回路を形成し直す必要がありそうだと分かったので、それは後日の課題だ。

 とりあえず、このまま現場に投入することができるスタイルまでは、持ってこられた。
 最終段のアプリが完成したら、正式にお披露目したい!


<本日の、推奨物欲。>


△このページのTOPへ戻る

 

コメント

Name   Message 
 日本の首都を入力する認証です→