電装工芸日記
- 舞台照明機器の製作とか -
タグ「器具の製作」を含む投稿(時系列順)［75件］（2ページ目）
オレメモです。
LTCジェネレーターの制御は、パソコンやらRaspberryPi(以下、母艦と呼称)でLTCのバイナリを生成し、PICで所定のbpsの差動バイフェーズに変換することにします。
PICにはFIFOバッファーを構成しようと思っていますが、母艦からPICへの送信がバッファオーバーフローか遅延にならない様にタイミングを考慮しないといけません。PICから母艦へデータ送信要求(許可)をする方法が必要でしょう。FT232RLはフロー制御も出来ますからそれを使ってもいいのですが、RaspberryPiのUARTにはフロー制御がありません。GPIOを直接制御してその様な信号を作ってもいいのですが、フロー制御を持ちなくても済むならそれに越したことはありません。UARTはデータを双方向でやり取りできますので、PICから母艦へデータ送信要求を送ることにしましょう。
SMPTE12Mのフォーマットを8bit(1byte)区切りで見ますと、バイナリグループのビットを常に0にすることが条件ですが、上位4bitは0x0,0xB,0xF,(0x3)のどれかにしかなりません(0x3は逆再生した際にシンクワードで発生する値)。これ以外の値ならば制御コードとして使えます。ASCIIテキスト制御ではありませんから0x00と0xFF以外なら何でもいいので、双方で使える制御コードにしておけば後でわかりやすいかなと。
この場合、上位4bitは0x5か0xAが一般的でしょうか。2進数ならb0101またはb1010です。0x7F以下のASCII文字になる値がデバックしやすいかもしれないので0x5かな。
例えばですが、
0x50 初期化(LTC送信停止・バッファクリア)
0x51 これに続くデータは設定データ(設定はfpsとDF/NDF)
0x52 これに続くデータは送信データ
0x57 データエンド
0x58 データ受信要求
0x59 データ送信要求
0x5F データ(動作)エラー
こんな感じ？
後はbpsの精度をどこまで求めるかです。
タイムコードの項に延々と書いていますが、波形周期を得るタイマー割込みのコンペア値を動的に変化させることで長周期の精度を水晶発振子の精度ギリギリまで出すことは可能です。ですが、どこまでの精度が必要なんでしょうね。
#器具の製作 #タイムコード
LTCジェネレーターの制御は、パソコンやらRaspberryPi(以下、母艦と呼称)でLTCのバイナリを生成し、PICで所定のbpsの差動バイフェーズに変換することにします。
PICにはFIFOバッファーを構成しようと思っていますが、母艦からPICへの送信がバッファオーバーフローか遅延にならない様にタイミングを考慮しないといけません。PICから母艦へデータ送信要求(許可)をする方法が必要でしょう。FT232RLはフロー制御も出来ますからそれを使ってもいいのですが、RaspberryPiのUARTにはフロー制御がありません。GPIOを直接制御してその様な信号を作ってもいいのですが、フロー制御を持ちなくても済むならそれに越したことはありません。UARTはデータを双方向でやり取りできますので、PICから母艦へデータ送信要求を送ることにしましょう。
SMPTE12Mのフォーマットを8bit(1byte)区切りで見ますと、バイナリグループのビットを常に0にすることが条件ですが、上位4bitは0x0,0xB,0xF,(0x3)のどれかにしかなりません(0x3は逆再生した際にシンクワードで発生する値)。これ以外の値ならば制御コードとして使えます。ASCIIテキスト制御ではありませんから0x00と0xFF以外なら何でもいいので、双方で使える制御コードにしておけば後でわかりやすいかなと。
この場合、上位4bitは0x5か0xAが一般的でしょうか。2進数ならb0101またはb1010です。0x7F以下のASCII文字になる値がデバックしやすいかもしれないので0x5かな。
例えばですが、
0x50 初期化(LTC送信停止・バッファクリア)
0x51 これに続くデータは設定データ(設定はfpsとDF/NDF)
0x52 これに続くデータは送信データ
0x57 データエンド
0x58 データ受信要求
0x59 データ送信要求
0x5F データ(動作)エラー
こんな感じ？
後はbpsの精度をどこまで求めるかです。
タイムコードの項に延々と書いていますが、波形周期を得るタイマー割込みのコンペア値を動的に変化させることで長周期の精度を水晶発振子の精度ギリギリまで出すことは可能です。ですが、どこまでの精度が必要なんでしょうね。
#器具の製作 #タイムコード
「LTC Sound Player」を本格的に製作する前にLTCによって生産性が上がるのか検証しなければなりません。本番操作が楽でも結果的に作業量が増えたら本末転倒だからです。
音源を加工せずにLTCを出すことが目標ですが、まずはテスト音源を作成。花火屋さんに倣い、L-chに音楽、R-chにLTCです。今回は29.97fps(NDF)と25fpsの２種類を作ってみました。
LTCはここで作ってもらいました。便利なサイトがあるものです。
１時間目から本編開始とし、マイナス２フレーム(29.97fpsなら00:59:59.28)からのLTCです。２フレームは01:00:00.00を確実に掴んでもらうためのノリシロですが、普段の音源編集でも0.05秒程度のノリシロ(余白)を付けているので問題無いと思います。
吉と出るか凶と出るか。
そうそう、VLCをベースにするなら映像を元にしてもLTCが出せそうです。
#器具の製作 #タイムコード
音源を加工せずにLTCを出すことが目標ですが、まずはテスト音源を作成。花火屋さんに倣い、L-chに音楽、R-chにLTCです。今回は29.97fps(NDF)と25fpsの２種類を作ってみました。
LTCはここで作ってもらいました。便利なサイトがあるものです。
１時間目から本編開始とし、マイナス２フレーム(29.97fpsなら00:59:59.28)からのLTCです。２フレームは01:00:00.00を確実に掴んでもらうためのノリシロですが、普段の音源編集でも0.05秒程度のノリシロ(余白)を付けているので問題無いと思います。
吉と出るか凶と出るか。
そうそう、VLCをベースにするなら映像を元にしてもLTCが出せそうです。
#器具の製作 #タイムコード
LTC音源で卓が動きました。「MA dot2 core」です。
トリガータイムは手打ちも出来ますが「TC Record」機能を使えばLTCを受けながら「GO」を押すことでタイムが取れます。タイムの修正も現在値に対するプラスマイナスで行えます。
ただし、LTCが走り出してから認識するのに0.3sec.程度かかります。また、エグゼキューターをOffにしておいてもその時刻が来るとCUEが走ってしまいます。
装置を構成するには卓の挙動をよく観察しないといけませんが、一度覚えさせればその通りに再現してくれる感覚は良いですね。
追記
LTCの認識は同じ値を送り続けたら解決出来るかもしれません。スタートするまで１フレーム前のデータを繰り返し送り続けるのです。1:00:00.00からスタートするなら0:59:59.29(29.97fps)のデータを送り続けるのです。試すしかありませんが、アクティブな一時停止が実現出来れば手段が広がるように思います。
#器具の製作 #タイムコード
トリガータイムは手打ちも出来ますが「TC Record」機能を使えばLTCを受けながら「GO」を押すことでタイムが取れます。タイムの修正も現在値に対するプラスマイナスで行えます。
ただし、LTCが走り出してから認識するのに0.3sec.程度かかります。また、エグゼキューターをOffにしておいてもその時刻が来るとCUEが走ってしまいます。
装置を構成するには卓の挙動をよく観察しないといけませんが、一度覚えさせればその通りに再現してくれる感覚は良いですね。
追記
LTCの認識は同じ値を送り続けたら解決出来るかもしれません。スタートするまで１フレーム前のデータを繰り返し送り続けるのです。1:00:00.00からスタートするなら0:59:59.29(29.97fps)のデータを送り続けるのです。試すしかありませんが、アクティブな一時停止が実現出来れば手段が広がるように思います。
#器具の製作 #タイムコード
パソコンの音声再生アプリにはタイムコードを出す物があるらしい。
様々なアプリがあるので一概に言えませんが、タイムコードはLTCではなくMIDI-TimeCode(以下、MTC)ではないかと思われます。というか、それらのアプリの用途を考えたらMTCが自然かと。
LTCのメリットは音声信号であるため配線の選択肢が多いことです。仕込みの効率が良いのでLTCを望んでいるのです。
ですが、既存のアプリが使えるならその流儀を優先させた方が良いかもしれません。LTCを扱える調光卓はMTCも扱えますし、音声再生の視点ではMTCの方が汎用性が高いからです。
LTCのメリットでありMIDIの弱点となるのは音声信号として扱えるかと配線長です。この辺りを対策すれば音声再生側も調光卓側もMTCでいいんじゃないかと。
さて、どうしましょう。
LTCのメリットとMTCのメリットを足して、MTCを音声信号として送れるようにすればよくね？
MIDI全般に対応する気はありませんから、MTCに特化して音声信号(差動バイフェーズ)として送るのです。
参考
MIDIタイムコード規格
MIDIタイムコード(MTC)について調べてみた
有志の方のサイトです。
ここで言うMTCは記事にある「クォーター・フレーム・メッセージ F1 dd」のことです。
MTC(コマンド0xF1)はMIDIの回線をタイムコードで占有しないために２フレーム分の時間を使って送信するようです。
バイト送信のタイミングはMTCを出す側に依存するとしても、１フレームの時間で８バイト送れればいい。MTCに完全特化してコマンド0xF1を省けば４バイトです。
４バイトなら１フレームの時間内で40bit送れればよく、最もビットレートが速い30fpsでも1,200bpsあれば事足ります。差動バイフェーズで音声信号化しても問題無しです。
受信側はバイト受信の度に0xF1を付けた2バイトをMIDIとして送出するだけです。
この方法は僅かな遅れを生じますが、MTCは２フレーム遅れるのが前提の規格ですし、遅れが一定ならば実用上の問題は無いと考えます。
分解能が1/12～1/15秒であることもMTCの前提ですが、卓や灯体の遅延はもっと大きいし、これが見える人もそうそう居ないでしょう。
自画自賛ですが悪くないアイデアです。
#器具の製作 #タイムコード
様々なアプリがあるので一概に言えませんが、タイムコードはLTCではなくMIDI-TimeCode(以下、MTC)ではないかと思われます。というか、それらのアプリの用途を考えたらMTCが自然かと。
LTCのメリットは音声信号であるため配線の選択肢が多いことです。仕込みの効率が良いのでLTCを望んでいるのです。
ですが、既存のアプリが使えるならその流儀を優先させた方が良いかもしれません。LTCを扱える調光卓はMTCも扱えますし、音声再生の視点ではMTCの方が汎用性が高いからです。
LTCのメリットでありMIDIの弱点となるのは音声信号として扱えるかと配線長です。この辺りを対策すれば音声再生側も調光卓側もMTCでいいんじゃないかと。
さて、どうしましょう。
LTCのメリットとMTCのメリットを足して、MTCを音声信号として送れるようにすればよくね？
MIDI全般に対応する気はありませんから、MTCに特化して音声信号(差動バイフェーズ)として送るのです。
参考
MIDIタイムコード規格
MIDIタイムコード(MTC)について調べてみた
有志の方のサイトです。
ここで言うMTCは記事にある「クォーター・フレーム・メッセージ F1 dd」のことです。
MTC(コマンド0xF1)はMIDIの回線をタイムコードで占有しないために２フレーム分の時間を使って送信するようです。
バイト送信のタイミングはMTCを出す側に依存するとしても、１フレームの時間で８バイト送れればいい。MTCに完全特化してコマンド0xF1を省けば４バイトです。
４バイトなら１フレームの時間内で40bit送れればよく、最もビットレートが速い30fpsでも1,200bpsあれば事足ります。差動バイフェーズで音声信号化しても問題無しです。
受信側はバイト受信の度に0xF1を付けた2バイトをMIDIとして送出するだけです。
この方法は僅かな遅れを生じますが、MTCは２フレーム遅れるのが前提の規格ですし、遅れが一定ならば実用上の問題は無いと考えます。
分解能が1/12～1/15秒であることもMTCの前提ですが、卓や灯体の遅延はもっと大きいし、これが見える人もそうそう居ないでしょう。
自画自賛ですが悪くないアイデアです。
#器具の製作 #タイムコード
TRUE1のY分岐とT分岐の試作は繋ぎ目にコーキングを入れて終わりました。
数日放置してコーキングが固まったら水バケツに入れて具合いを見ます。
求めるのは防水ではなく防滴ですから浸水チェックは不要と言えば不要ですが、これでＯＫなら防滴性能があるとしていいでしょう。
#器具の製作
数日放置してコーキングが固まったら水バケツに入れて具合いを見ます。
求めるのは防水ではなく防滴ですから浸水チェックは不要と言えば不要ですが、これでＯＫなら防滴性能があるとしていいでしょう。
#器具の製作
タイムコードの使用にあたり卓(MAdot2)の挙動で重要となるのは次の点です。
・入力されたタイムコードがCUEに設定された値になると、エグゼキューターのON/OFFに関わらずCUEが走る。とにかく走る。
取り溢しが起こらないので安全という見方もありますがどうなんでしょう。
注意点が２点あります。
１）CUEに与えるタイムコード値はシーケンス内で重複してはいけない。
２）卓に入力されるタイムコードの有効無効を操作出来なければならない。
(1)については、卓よりもタイムコードを出す側の課題かもしれません。例えば20曲ある演目として、それぞれの曲が同じタイムコード値から始まってはいけないのです。プレイリスト内の通し値、もしくは曲ごとに開始値を設定する必要があります(１曲あたり10分割振りとか)。
(2)については、直しなどでタイムコードを受けたくない状況が想定されるからです。音響さんのチェックと照明の直しが同時進行するなど普通のことですからね。必要な時に有効にし、外したい時には外すのです。少し蛇足ですが、音響さんとは無関係に照明ローカルでチェックしたいこともあります。手元の音源でのチェックという意味です。もちろん音源にはタイムコードも伴う前提ですので、複数のタイムコードから選択出来ればいいのかなと。
一番の問題は(1)でしょうか。ここまでタイムコードの扱いに特化した音源再生アプリなんてあるのかな？
その筋に詳しい音響担当に相談していますのでしばらく待ちです。
・・・専用アプリ「LTC Sound Player」は作らないとだめかなぁ～。
#タイムコード #器具の製作
・入力されたタイムコードがCUEに設定された値になると、エグゼキューターのON/OFFに関わらずCUEが走る。とにかく走る。
取り溢しが起こらないので安全という見方もありますがどうなんでしょう。
注意点が２点あります。
１）CUEに与えるタイムコード値はシーケンス内で重複してはいけない。
２）卓に入力されるタイムコードの有効無効を操作出来なければならない。
(1)については、卓よりもタイムコードを出す側の課題かもしれません。例えば20曲ある演目として、それぞれの曲が同じタイムコード値から始まってはいけないのです。プレイリスト内の通し値、もしくは曲ごとに開始値を設定する必要があります(１曲あたり10分割振りとか)。
(2)については、直しなどでタイムコードを受けたくない状況が想定されるからです。音響さんのチェックと照明の直しが同時進行するなど普通のことですからね。必要な時に有効にし、外したい時には外すのです。少し蛇足ですが、音響さんとは無関係に照明ローカルでチェックしたいこともあります。手元の音源でのチェックという意味です。もちろん音源にはタイムコードも伴う前提ですので、複数のタイムコードから選択出来ればいいのかなと。
一番の問題は(1)でしょうか。ここまでタイムコードの扱いに特化した音源再生アプリなんてあるのかな？
その筋に詳しい音響担当に相談していますのでしばらく待ちです。
・・・専用アプリ「LTC Sound Player」は作らないとだめかなぁ～。
#タイムコード #器具の製作
頭の区切りが付かないので、LTC-Generatorの回路図を描いてみました。
FT232RLを使ってPICにUARTを送る
→ PICで所定のbpsの差動バイフェーズ化する
→ PICの出力を分圧して約1vp-p(要は2v)にする
→ オペアンプの1:1ボルテージフォロア回路で音声信号化
→ 出力
といった簡単な構成です。
1vなので音声信号としては約+3dBです。
グランドループさせない様にした方がいのかな？
追記
気分が乗って描いてしまった基板の3D図も揚げます。
折角なので発注しました。
本体価格は10枚で$19です。1枚300円しないのですから安いですねぇ～。
#器具の製作 #タイムコード
FT232RLを使ってPICにUARTを送る
→ PICで所定のbpsの差動バイフェーズ化する
→ PICの出力を分圧して約1vp-p(要は2v)にする
→ オペアンプの1:1ボルテージフォロア回路で音声信号化
→ 出力
といった簡単な構成です。
1vなので音声信号としては約+3dBです。
グランドループさせない様にした方がいのかな？
追記
気分が乗って描いてしまった基板の3D図も揚げます。
折角なので発注しました。
本体価格は10枚で$19です。1枚300円しないのですから安いですねぇ～。
#器具の製作 #タイムコード
オレメモです。
LTCの差動バイフェーズのクロックをPICで起こす計算です。
Fosc32MHz(8MHzPLLx4)にすると、Timer1でコンペアモードとするクロックは最速で8MHz。
１時間は3,600秒。
8MHzで1時間カウントすると28,800,000.000.カウント。
１時間あたりの総カウント数をこれに近づける。
CCPRxH/Lに与える値は次の通り。
● 30fps(2,400bps相当)
ベース値は1,666.
3回に2回、1,667.にする。
(1,666count×2,400bps×2倍周期×3,600秒)
＋(((2,400bps×2倍周期×3,600秒)÷3)×2)
＝28,800,000,000.
誤差無し
● 29.97fps(30÷1.001fps、約2,397.602bps相当)
ベース値は1,668.
3回に1回、1,669.にする。
(1,668count×2,397.602bps×2倍周期×3,600秒)
＋((2,397.602bps×2倍周期×3,600秒)÷3)+0.25
＝28,800,000,000.004238...
誤差 004238...
水晶発振子の精度からして十分だと思う。
※ 最後の＋0.25は４時間１回＋１するって意味。タイムコードは24時間時計なので因数だからいいかな。
● 25fps(2,000bps相当)
ベース値は2,000.
(2,000count×2,000bps×2倍周期×3,600秒)
＝28,800,000,000.
誤差無し
● 24fps(1,920bps相当)
ベース値は2,083.
3回に1回、2,084.にする。
(2,083count×1,920bps×2倍周期×3,600秒)
＋((1,920bps×2倍周期×3,600秒)÷3)
＝28,800,000,000.
誤差無し
以前の計算と何か違うのだけど、まぁいいか。
#器具の製作 #タイムコード
LTCの差動バイフェーズのクロックをPICで起こす計算です。
Fosc32MHz(8MHzPLLx4)にすると、Timer1でコンペアモードとするクロックは最速で8MHz。
１時間は3,600秒。
8MHzで1時間カウントすると28,800,000.000.カウント。
１時間あたりの総カウント数をこれに近づける。
CCPRxH/Lに与える値は次の通り。
● 30fps(2,400bps相当)
ベース値は1,666.
3回に2回、1,667.にする。
(1,666count×2,400bps×2倍周期×3,600秒)
＋(((2,400bps×2倍周期×3,600秒)÷3)×2)
＝28,800,000,000.
誤差無し
● 29.97fps(30÷1.001fps、約2,397.602bps相当)
ベース値は1,668.
3回に1回、1,669.にする。
(1,668count×2,397.602bps×2倍周期×3,600秒)
＋((2,397.602bps×2倍周期×3,600秒)÷3)+0.25
＝28,800,000,000.004238...
誤差 004238...
水晶発振子の精度からして十分だと思う。
※ 最後の＋0.25は４時間１回＋１するって意味。タイムコードは24時間時計なので因数だからいいかな。
● 25fps(2,000bps相当)
ベース値は2,000.
(2,000count×2,000bps×2倍周期×3,600秒)
＝28,800,000,000.
誤差無し
● 24fps(1,920bps相当)
ベース値は2,083.
3回に1回、2,084.にする。
(2,083count×1,920bps×2倍周期×3,600秒)
＋((1,920bps×2倍周期×3,600秒)÷3)
＝28,800,000,000.
誤差無し
以前の計算と何か違うのだけど、まぁいいか。
#器具の製作 #タイムコード
LTC Generator の基板が入荷しました。
今回はDHLを使ったこともありますが、オーダーしてから６日です。早し。
送料を見ると発送後2-3日で届く業者の中でDHLが一番安い。今までならDHLが一番高いくらいだったのに不思議。通常使っている日数が倍以上かかる安い業者と比べると３ドルしか違わない。不思議だなと思いつつ、安くて早いならヨシでしょう。数日早いと日程的にリフローの研究をジックリやる時間が取れるので数百円の違いはアリアリです。
組み立ては他の部品の入荷後ですが、リフローハンダの段取りを玉成することも含めての作業となります。
PICのファームウェアはもちろん、PC側のプログラムもありますのでしばらくかかりそうです。
今はFIFOのライブラリを考えています。これがまた簡単そうで難しい。
追記
秋月さんから部品が発送されたそうです。
次のオフにリフローの研究をジックリ出来そうです。
#電子工作 #器具の製作 #タイムコード
今回はDHLを使ったこともありますが、オーダーしてから６日です。早し。
送料を見ると発送後2-3日で届く業者の中でDHLが一番安い。今までならDHLが一番高いくらいだったのに不思議。通常使っている日数が倍以上かかる安い業者と比べると３ドルしか違わない。不思議だなと思いつつ、安くて早いならヨシでしょう。数日早いと日程的にリフローの研究をジックリやる時間が取れるので数百円の違いはアリアリです。
組み立ては他の部品の入荷後ですが、リフローハンダの段取りを玉成することも含めての作業となります。
PICのファームウェアはもちろん、PC側のプログラムもありますのでしばらくかかりそうです。
今はFIFOのライブラリを考えています。これがまた簡単そうで難しい。
追記
秋月さんから部品が発送されたそうです。
次のオフにリフローの研究をジックリ出来そうです。
#電子工作 #器具の製作 #タイムコード