記事一覧

タイムコード考・・・その27

 基底クロックを作る方法を考えているワケですが、タイマーのクロックを8MHzにして閏カウントを3層まで組むと24fps、25fps、29.97fps、30fpsの4種類で丁度になります。

 受信は相手に合わせる工夫が必要ですが、送信はオレ様都合で処理出来ますので試験プログラムを書いてみましょう。

 モードは、

 24fps
 25fps
 29.97fps DF
 29.97fps NDF 
 30fps

 となりますね。

タイムコード考・・・その26

 てなワケで、タイムコードはややこしいなと思いつつ、これを作るなら基底クロックを生成できなきゃいません。

 PICにおいてFosc/4が4MHzの場合で考えてみます。

 カラーNTSCのタイムコードは1時間周期でツジツマを合わせる考え方なので1時間で考える。

 1時間のフレーム数は、

 [29.97fps] × [1時間:3600秒] = [107,892fph(フレーム・パー・アワー)]

 となります。

 別な計算ですと、

 [30fps] × [1時間:3600秒] - [フレーム間引き:2フレーム×54回] = [107,892fph]

 となります。

 意味合いとしては後者の方が正しい式ですね。

 タイムコードはどのフレームレートでも80bitです。
 1時間あたりのデータ量は次の通り。

 [107,892fph] × [80bit] = [8,631,360bph(ビット・パー・アワー)]

 タイムコードは差動バイフェーズなので4倍のクロックを基底にすると処理しやすい。

 [8,631,360bph] × [4倍] = [34,525,440count/h]

 1秒あたりは、

 [34,525,440count/h] ÷ [1時間:3600秒] = [9590.4Hz]

 となる。

 ・・・半端だな。

 クロックにおける1パルスの精度は1/100もあれば良いと思われるので、閏カウント(たまにパルス長を長くしたり短くしたりして長い目でのツジツマを合わせる)を入れます。・・・これは以前も書いた方法。
 以前の計算は1時間単位での考証をしていませんでした。これは思いもよらない誤差を引き起こす原因になりますので、今後は1時間単位で計算しようと思います。

 PICのFosc/4は4MHzですから、1時間あたりのカウント数は・・・

 [4,000,000Hz] × [1時間:3600秒] = [14,400,000,000count/h]

 これを時間あたりのタイムコードのデータ量で割る。

 [14,400,000,000count/h] ÷ [34,525,440count/h] = [417.0837504170838・・・・count/count]

 4MHzの命令クロックで417強のカウントをタイマーでやればいい。

 [34,525,440count/h] × [417count/count] = [14,397,108,480count/h]
 [14,400,000,000count/h] - [14,397,108,480count/h] = [2,891,520count/h]

 1時間あたり 2,891,520 カウント不足なので、周期的に閏カウントを入れるワケです。

 比較構文が増えると処理が重くなりますから、シンプル且つ確実なカウント方法を考えましょう。

 ここまでの計算は29.97fpsの話ですが、25fpsも24fpsも同様の考え方で良いと思います。

タイムコード考・・・その25

 またもや「待機」という仕事が続いたのでタイムコードの生成方法について考えてみた。
 以前書いたのには少々間違いがあったのでご注意を。

 さて、主なタイムコードのレートは次の通り。

 30fps(いわゆるノンドロップフレーム[NDF])
 30fps(カラーバースト無し・白黒用の古い30fps)
 29.97fps(いわゆるドロップフレーム[DF])
 25fps
 24fps

 ここで注意というか私自身が勘違いしていた点は30fpsに2種類あること。
 NTSCにおいて、白黒では1秒間に30フレーム丁度でしたが、カラー信号を送るために「カラーバースト信号」が必要になり白黒の信号よりもデータ量が増えてしまった歴史があります。そのためにカラーのNTSC信号は30fpsではなく29.97fpsになり、タイムコードの時間値を合わせるために各時の0分、10分、20分、30分、40分、50分目以外の各分00秒目はアタマの2フレーム分は「フレームカウント」を削除することになったそうな。各分00秒目のアタマは3フレーム目からってことです。ナンバリングはゼロからなので、最初のフレームは2です。

 細かいことはそのウチ本体ホームページで整理したいと思いますが、大事なことは・・・

 カラーNTSCは30fps[NDF]でも29.97fps[DF]でも1フレームあたりの時間ピッチは同じ。
 カラーNTSCの30fps[NDF]では1フレームが1/30秒より長いのでタイムコードの時間値が実時間に対して徐々にずれていきますが、これを補正するために途中のカウントをすっ飛ばして1時間あたりの換算ではツジツマを合わせようとしたらしい。。。

 ・30fps[NDF]だと実時間に対して時間値が遅れていき、29.97fps[DF]だと1時間に1回は丁度になるけどそれ以外はズレているとなります。カラーのNTSCのタイムコードは実時間に対して常にズレています。
 ・30fpsといっても歴史的には2種類あるから注意しましょう。

 ってことみたいです。

 カラーNTSCのDFかNDFかと呼んでくれた方がわかりやすいような気がしたりして。
 つことは、30fps丁度のNTSC信号は事実上今は無いってことになるんだろね?

TWE LITE

 現場でヒマが長かったので部品調べをしていたところ、こんなのを見つける。

 TWE LITE

 簡単に使える2.4GHz通信モジュールです。
 2.4GHzってことはLINE6大会の現場では恐ろしくて使えませんが、標準のファームウェアで簡単なスイッチリモコンを構成できるので便利ではないかと。
 見通しで最大で1km飛ぶとか。障害物が多少あっても50mくらいなら実用域でしょうから、舞台空間では十分に使えると思います。

 ファームウェアを自作すれば単体でもかなり高度なことも出来るそうですが、まずはシンプルに接点リモコンとして使ってみるのがいいと思います。消費電力が少ないので電池でも長時間駆動できそうです。

 千石電商さんで取扱いがあります。ケッコウお安い。

 先日くるみ割り人形の全幕に関わりましたが、ふくろう時計の分針と目のチカチカをリモコン化できたら便利かなと・・・思ったり。

 接点の入り口と出口を構成するのに少し知識が必要ですが、ここさえクリアしてしまえば便利に使えるアイテムになると思います。

追記

 TWELITEの解説書が入荷しました。
 DMX512を扱うには荊の道を歩くことになりますが、メーカーが出している基本的なライブラリでも思った以上にイロイロなことができるようです。
 オリジナルファームウェアの開発も、C/C++を使うのが本筋のようですが、Python3でも書けるのでかなり敷居が低いと思います。
 解説書には入口や出口の基本回路も掲載されています。簡単そうで出来なかった制御を作れますよ。

 「TWELITEではじめるカンタン電子工作」

 まめに更新されているみたいですから、できるだけ新しい版を手に入れてください。上記は2018/11/1版です。

CS-16-2型・・・その16

 スクローラーを作ってます。

 ディスコンになった部品の話を以前書きましたが、その代表株であるエンコーダー付きモーターは十分すぎるほどの在庫が自宅にありました。
 段ボール箱は目に付くところにあったのですが、試作品を入れた同じ箱の下だったのでそれもそうだと勘違い。筐体を追加製造したときにモーターも手に入れてたのでした。筐体と駆動部の部品は50台分もあるので当面大丈夫ですね。
 制御基板は売り切れだったので追加製造しています。要となるモータードライバーICはRoHS指令の区切りで廃番になった製品ですが、一時期に比べて流通在庫品の価格が下がり入手も簡単になりました。現役時に500円くらいで仕入れてた部品が廃番になった途端に4,000円弱まで値段が上がっていましたから流石に使えないなぁ~と思っていたのですが、今は1,000円ちょいです。デッドストック覚悟で50個手配しましたが、スクローラーがあと50台売れるかというと定かではありません。今回は数台のオーダーをいただきましたが、今後は在庫を売り切ったら廃番と言ってもいいでしょう。

Tour Z CAM/ETZ のオリジナル信号・・・どうやら正しく動くらしい

 事務所勤務でしたので、朝から日暮れまで実機で延々と動作させてみる。
 ずっと見てたワケじゃありませんが正しく動くみたい。
 外見は以前作った小型スプリッターと全く同じです。スプリッターを僅かに改造したハードウェアですから当たり前です。
 間違えちゃ困るので、カッティングシートプリンタでデカデカと名前を書いておきました。それと「これはスプリッターじゃないよー!」と、Google翻訳の直訳ですが、メッセージも書いた。
 ・・・これで間違えたら知ったこっちゃない(笑)

 ここしばらくの懸案がヒトツ終わったので気分が楽になった。

Tour Z CAM/ETZ のオリジナル信号・・・実機ができた

 TourZCAM/ETZのMaster-Slave信号をDMX変換する装置が出来ました。

 Master-Slave信号にはRGBの3色のデータしかありませんので、DMXの001-003にそれぞれを出すだけです。
 DMX側のアドレスを設定出来るようにするか?とも思ったのですが、直接ぶら下がるだけですので意味が無い。シンプルにしました。

 PICのUSARTの挙動に勘違いしていたところがあったのでその対策で時間を取られました。
 USARTを有効にした場合、データを送信していない時の出力はHですが、USARTが活きていてもTRISをINPUTにしてPullUp/Downすれば自由な長さのBreakTimeが作れるんじゃね?と思っていましたが、TRISに関わらず出力されてしまう。USARTモジュールは通常I/Oと並列に組まれた完全に別な回路みたい。この方法はダメでした。
 ところが、TXSTAのTXENで送信をディセーブルにするとUSARTが起動していても通常I/Oを機能させられるみたい。回路にPullDown抵抗が入っているためにPIC自体の正確な挙動は確認できていませんが、望んだ挙動になったことは確か。マニュアルのブロック図を見るとTXENはシリアル送信を動かすクロックに関与しているみたいだけど、USARTの出力バッファにも関与しているんじゃないかと思われる。ちなみに12F1822での話です。

 BreakTimeの送信方法は次の通り。

1)512chのデータを送りきったら(TXSTAのTRMTを監視して把握)TXSTAのTXENをディセーブルにしてPORT出力をLにする。

2)タイマーで88usec以上カウント。

3)MarkAfterBreakを生成するため、TXREGに0xC0(0x00でもいいのだが、MarkAfterBreakが規格ギリギリの値になって不安定なので、長めにするために0xC0とした)をセットし、TXSTAのTXENを1にして送信をイネーブルにすると0xC0が送信される。

4)以降、StartCode-001ch-002ch・・・と送る。

 以前実験した際、TRISの切替で行けた気がしたのですが、そういえば受信機能だけをイネーブルしてTXENがディセーブルの状態だったかもしれません。
 DMX512の様に長いBreakTimeの生成はPIC16のUSART機能では対応していないのでログラムでそれを書きますが、ひょっとすると機種ごとにハードウェアの構成が違って書き分けないといけないかもしれません。使う機種ごとにUSARTの挙動をチェックしないといけませんね。

 TourZCAM/ETZのMaster-Slave信号は先日書いた通りでした。ただ、「値が変化した時にだけ送信される」ってのが追加事項です。変化が無くても2~3秒に一回は送っている感じもしますが、同じ明かりのままではデータ送信の間隔を測定できるワケありませんな。
 色データはパリティを処理しなくてもいいのですが、折角組んだので使っています。ちゃんと処理できればエラー回避にもなりますし。
 0x55送信であえてパリティエラーを使ってヘッダーとするのは思いもよらない方法でしたが、これは今後使えそうです。近々Dimmer-SSRを作りたいのでそれに使ってみましょう。

 なんのこっちゃい話でした。

 名前は「CAM to DMX」としておきます。
 わかりやすいのが一番です。

 見た目は以前作ったスプリッターのままなので、間違ってしまう可能性はありますね(笑)

追記

 イネーブルとディセーブルを間違って書いたところがあったので修正しました。

Tour Z CAM/ETZ のオリジナル信号・・・実機の案

 実機を作るのは手数が多いのですが、ハードウェアは以前作ったスプリッターに少し手を加えるだけで行けそう。
 8ピンのPIC12F1822でDMXの受信状況を判断する機構にしていますが、基板のパターンを1本切ってジャンパーを1本入れ、PICのUARTのTXを出力するようにすればOK。
 プログラムはゼロから書くようですが、UARTを受信してUARTを送り出すだけですから、1日あればベータ版まで書けるでしょう。

 これに気が付いて少し気が楽になる。

Tour Z CAM/ETZ のオリジナル信号

 Tour Z CAM/ETZ を使っています。

 全天候型のLEDカラーミックススポットとしては初期の製品ですが、なかなか使えます。

 このスポットにはタイムも設定できるシーン記憶が付いております。
 これがケッコウ便利。
 昨年のクリスマスもDMX卓やレコーダーを使わず、Tour Z CAM/ETZ だけで色が変わるライトアップを構成しました。アタマになる奴にシーンを入れ、その下に繋がる奴をSlaveモードにすればアタマの動作に従います。
 全部を同じに動かせばいいなら案外十分だったりします。

 ところがです、別の種類のスポットも Tour Z CAM/ETZ に同調させて欲しいとキタ。
 信号はオリジナルらしく他のDMX機器は反応しない。このオリジナル信号をDMXに変換しないといけない。

 ロジックアナライザを買ったのはこれの解析のためですが、ようやくプロトコルがわかる。

 以下、宇宙語と呼ばれてしまうことが多いオレメモ。。。

 基本は250kbpsのRS485。DMXと同じ物理層です。Hレベルでインターバルし、スタートビットがLで1bit、ストップビットがHで1ビット、パリティが1ビット、LSB-MSBです。
 パケットは、ヘッダが0x55、0X00の2バイト、色データがRGB各色1バイトで3バイトです。全体で5バイトみたい。ストロボはパラメータを送信せずに色データでやってるみたい。
 パリティにちょっとクセがあります。Hビットが奇数個で0、偶数個(0x00は偶数個とみなす)で1が基本ですが、ヘッダの0x55におけるパリティは偶数個なのに0です。これがわかるまで20分くらい悩みました。
 インターバルタイムが無茶苦茶長いみたいでロジアナでは検出できませんでしたが、オリジナル信号を受けてDMXに変換するならこれを知らなくてもいい。数十バイト分の空白を検知したら折り返しとすればいいので、プログラム的には大雑把に測ればいい。

 さて、プロトコルがわかったので早急にプロトコルコンバーターの実機製作です。

 この10月は濃い現場が立て続けで体力の限界どころか精神崩壊寸前でした。
 9月下旬から段取り物が目白押しで、10月の下旬には [体育館の仮設施工の施工監督]→[くるみ全幕の舞台監督]→[100コマ以上の展示会の電源出し]という異種格闘技を1週間でこなしていました。自称変人ですが、さすがにここ2ヶ月は本業以外のことは無理でした。

 と、言い訳を書いてしまいますが、異種格闘技はまだまだ続きます。
 その一種としてこんなおかしなプロトコルコンバーターを作らないといけません。
 3週間後には現場仕込みです。
 間に合うかな?

差動バイフェーズでGO!・・・2クロック目

 差動バイフェーズは久しぶりのネタです。
 タイムコード(LTC)で使われる送信方式で、ここでは細かい説明を省きますが、音声信号として送信することも可能なデジタル信号です。

 どうして思い出したかというと、「SPIで制御するディマーを作ったらどうか」について考えていたときです。
 今日の現場は現地照明でしたが、袖に居なきゃならないけどやることは無い2回まわしだったもので、居眠りしてるワケにいきませんので何か考えようと時間潰しで思いにふけっておりました。

 主題は「簡単なシリアル信号を受信して動くディマーを作ろう」ってアイデアです。すべてのディマー回路にDMXを処理させるのは無駄がありますし、一つのマイコンでDMXの受信から複数回路の位相制御までさせるのはナカナカ荷が重い。
 ならば、アタマにDMXを受信して簡単なシリアル信号を送出するマイコンを組み、その配下に簡単なシリアル信号を受けて位相制御をするマイコンを組んだらいいんじゃねーのって思ったワケです。これならイロイロな受電方式の調光ユニットを組み合わせだけで構成できます。

 ココの要の「簡単なシリアル信号」に差動バイフェーズ方式を使ったらいいでないの?って思ったのです。
 SPIでもいいのですが、クロック信号が必要ですし、SPIでアタマ抜きリレーをすると後にデータが届くのにかなり遅れが出てしまいそうです。内部モジュールのSPIを使うのは一見楽ですが、実は面倒になりそうな気配。。。
 クロック信号無しなら普通のUARTでもいいのですし、WS2812の様式を真似てもいいのですが、この際、差動バイフェーズを採用してそのウチ作ろうと考えているLTCの習作を兼ねるのがいいんじゃないかと。

 差動バイフェーズの受信はPICの入力変化割り込みとタイマーを使えば簡単です。
 変化割り込み時のタイマーが、、、
1)カウントオーバーフローならパケットの折り返しと判断
2)カウントオーバーフローではないけど0を表す値より大きいならタイマーをクリアする
3)0を表す長さなら0を受信したとしてタイマーをクリアする
3)1を表す長さなら1を受信したとしてタイマーに補正値を加算する(次の変化割り込みで上記の(2)と判断されるような値を加算する)
 転送速度を欲張らなければかなりラフな処理でもいける。初めてLTCの規格を読んだ時にはどうしたものか悩みましたが、割り切って読み解くと案外簡単でした。

 WS2812的なアタマ抜きリレーの処理ですが、自分の取り分の8bitを受信するまでは信号をリレーしなければいいだけです。折り返しを認識したらフラグをクリアするだけだし。

 これなら9,600bpsでも36chを1秒間に約30回更新できます。
 DMXのリフレッシュレートは44回/秒だし、NTSCの映像は30fpsだし、こんなもんでも十分じゃないかと思いますが、不足なら19200bpsくらいにすればいい。

 PICのFoscを32MHzとして256カウント周期で処理したら31,250bpsになります。
 差動バイフェーズは1bit送信するのに2フェーズ使った方が楽なので15,625bpsとなり、36chなら約50回更新できます。
 受信側は8bitタイマーのプリスケーラーを4か8にして変化割り込みで値を見て、タイマーがオーバーフローしたら折り返しとすればいい。
 欲張らず、こんなところかな?

ページ移動

過去ログ