電装工芸日記
- 舞台照明機器の製作とか -
タグ「タイムコード」を含む投稿［52件］（5ページ目）
オレメモです。
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の回路図を描いてみました。
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円しないのですから安いですねぇ～。
#器具の製作 #タイムコード
タイムコードの使用にあたり卓(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」は作らないとだめかなぁ～。
#タイムコード #器具の製作
MIDIのビットレートは31,250kbps、8MHzの256分の１です。
ほぼUARTであり、スタートビット0/1bit、データ8bit、ストップビット1/1bitです。
これならPICのUARTで誤差無しで扱えます。
送信回路は電源5vとTTLレベルのUARTに220Ωを入れたシンプルな物。受信回路がフォトカプラ前提なので信号自体は反転しています。
信号経路がGNDショートすると23mAほど流れます。PICなら耐えられますが、UARTのI/Oがオーバーロードになるならバッファートランジスタ(2SC1815でもスピードアップコンデンサを入れればキレイな波形が出るハズです)を入れた方がいいかもです。
凄くシンプルなMTCジェネレーターならすぐ作れそうです。
#タイムコード
ほぼUARTであり、スタートビット0/1bit、データ8bit、ストップビット1/1bitです。
これならPICのUARTで誤差無しで扱えます。
送信回路は電源5vとTTLレベルのUARTに220Ωを入れたシンプルな物。受信回路がフォトカプラ前提なので信号自体は反転しています。
信号経路がGNDショートすると23mAほど流れます。PICなら耐えられますが、UARTのI/Oがオーバーロードになるならバッファートランジスタ(2SC1815でもスピードアップコンデンサを入れればキレイな波形が出るハズです)を入れた方がいいかもです。
凄くシンプルなMTCジェネレーターならすぐ作れそうです。
#タイムコード
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 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ジェネレーターの制御は、パソコンやら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ジェネレーターの研究を進めてみます。
これは「LTC Sound Player」で使うタイムコードジェネレーターで、UARTで受信したデータをPICで送出する物です。間にFT232RLを繋げばパソコン等からUSBでも制御出来るハズです。
FT232RLはUSBシリアル変換ICです。比較的簡単な回路で動き、ドライバは最近のOSなら予め入っているか自動でインストール出来ます。
FT232RLのいいところはMacでもWindowsでもLinuxでも使えることです。アプリケーションからは極々シンプルなシリアルデバイスに見えるので、大半の開発言語の標準ライブラリで扱うことが出来ます。
当初Ｃ言語で開発しようと思ったのですが、音源再生やらLTCジェネレーターの構成を考えていくとPythonを用いるのが良さそうです。巧く書けばMacでもWindowsでもLinux(RaspberryPi)でも使えるモノになるからです。
#器具の製作 #タイムコード
LTCジェネレーターの研究を進めてみます。
これは「LTC Sound Player」で使うタイムコードジェネレーターで、UARTで受信したデータをPICで送出する物です。間にFT232RLを繋げばパソコン等からUSBでも制御出来るハズです。
FT232RLはUSBシリアル変換ICです。比較的簡単な回路で動き、ドライバは最近のOSなら予め入っているか自動でインストール出来ます。
FT232RLのいいところはMacでもWindowsでもLinuxでも使えることです。アプリケーションからは極々シンプルなシリアルデバイスに見えるので、大半の開発言語の標準ライブラリで扱うことが出来ます。
当初Ｃ言語で開発しようと思ったのですが、音源再生やらLTCジェネレーターの構成を考えていくとPythonを用いるのが良さそうです。巧く書けばMacでもWindowsでもLinux(RaspberryPi)でも使えるモノになるからです。
#器具の製作 #タイムコード
昨日に引き続きバレエ発表会です。
道具の転換だけですからリハ中の今はヒマなのでアイデアを整理しています。
課題は「LTC Sound Player」です。
wavやmp3の音源プレイヤーですが、再生している音源と並列のLTCも出力します。先日も書いたネタですが、折角の空き時間ですから改めて整理しています。
音源再生にはVLCのライブラリであるlibvlcを使います。もっと直接的にOSとやりとりする方法もあるようですが、フォーマットやコーデックの違いをVLCが吸収してくれるので頼った方が間違いありません。記述はC言語系ならC++ですから勉強が増えますが、Pythonなら比較的簡単に書けそうです。
LTCの出力にはPICを挟みます。LTCの変調は差動バイフェーズですが、RaspberryPiには専用モジュールはありませんし、ソフトウェアで波形を起こすよりPICを使った方が自分には簡単です。RaspberryPiとはUARTやSPIで通信します。
レイテンシーを管理したガチの業務用ならC++記述しなければなりませんが、とりあえず作ってみようならPythonでイイと思います。
#器具の製作 #タイムコード
道具の転換だけですからリハ中の今はヒマなのでアイデアを整理しています。
課題は「LTC Sound Player」です。
wavやmp3の音源プレイヤーですが、再生している音源と並列のLTCも出力します。先日も書いたネタですが、折角の空き時間ですから改めて整理しています。
音源再生にはVLCのライブラリであるlibvlcを使います。もっと直接的にOSとやりとりする方法もあるようですが、フォーマットやコーデックの違いをVLCが吸収してくれるので頼った方が間違いありません。記述はC言語系ならC++ですから勉強が増えますが、Pythonなら比較的簡単に書けそうです。
LTCの出力にはPICを挟みます。LTCの変調は差動バイフェーズですが、RaspberryPiには専用モジュールはありませんし、ソフトウェアで波形を起こすよりPICを使った方が自分には簡単です。RaspberryPiとはUARTやSPIで通信します。
レイテンシーを管理したガチの業務用ならC++記述しなければなりませんが、とりあえず作ってみようならPythonでイイと思います。
#器具の製作 #タイムコード
Linux上のＣ言語でLTCの波形を起こせたらと思ったのですが、処理能力の総量は余裕タップリなものの、Art-Netエンジンを作った際に感じた挙動ムラから想像するに許容範囲を越える波形ムラが起こりそうです。LinuxはOSそのものや他のモジュールに引っ張られて100～300usecくらい待たされることがあるのですが、LTCの波形を起こすのにこの条件はよろしくありません。RTOSを使わないなら普通のことですけどね。
ならばLTCを起こすところにはPICを使ったらいいかな？適材適所？
LinuxからUARTなどでフレーム情報を送ってPICでLTCを生成するのです。２～４フレーム分くらいPICにバッファすればLinux側に動作ムラがあっても安定した波形を出すと思われます。
差動バイフェーズで信号を反転する時間ピッチは25fpsで250usecです。29.97fpsではなく25fpsとしているのは、PALのレートなのでLTC対応の演出機器は100%対応するし、何よりも計算がしやすく誤差も出にくいために当面の試作には良いかなと。250usecは32MHzのPICで2,000命令相当の時間です。これだけあれば大概ことは１フェーズ分実行出来ます。実行周期はTMR1やTMR2による周期割込みを使えばPICのクロック素子相当の精度を得られます。
求める精度は、周期が0.001%未満、差動バイフェーズの立ち上がり立下り精度が5%未満です。無理は無さそうです。
書いてて思ったのですが、こんなLTCジェネレーターをこれまでに作らなかった自分が不思議。
#タイムコード #PIC #電子工作
ならばLTCを起こすところにはPICを使ったらいいかな？適材適所？
LinuxからUARTなどでフレーム情報を送ってPICでLTCを生成するのです。２～４フレーム分くらいPICにバッファすればLinux側に動作ムラがあっても安定した波形を出すと思われます。
差動バイフェーズで信号を反転する時間ピッチは25fpsで250usecです。29.97fpsではなく25fpsとしているのは、PALのレートなのでLTC対応の演出機器は100%対応するし、何よりも計算がしやすく誤差も出にくいために当面の試作には良いかなと。250usecは32MHzのPICで2,000命令相当の時間です。これだけあれば大概ことは１フェーズ分実行出来ます。実行周期はTMR1やTMR2による周期割込みを使えばPICのクロック素子相当の精度を得られます。
求める精度は、周期が0.001%未満、差動バイフェーズの立ち上がり立下り精度が5%未満です。無理は無さそうです。
書いてて思ったのですが、こんなLTCジェネレーターをこれまでに作らなかった自分が不思議。
#タイムコード #PIC #電子工作