電装工芸日記
- 舞台照明機器の製作とか -
タグ「Art-net」を含む投稿［102件］（3ページ目）
同軸ケーブルにEthernetを通すMoCAを調べています。
分波器と呼ぶべきか分配器と呼ぶべきか、splitterについて参考になったサイトがありました。
「HTEM5 – How do I know if my splitter is MoCA 2.5 compatible?」
Google先生に翻訳して頂いて読むところ、
１）テレビアンテナ用の分配器を使う。
２）双方向通信が可能な物。＜＝追加
３）1000MHz以上に対応する物。
４）MoCA対応と刻印のある製品が望ましい。
てなことが読み取れました。
さらに、ケーブル配線の条件として、
５）経路中に増幅器(アンテナブースター)が無いこと。
６）メインの分配器からの配線は100ヤード(90メートル)以内にする。
との記載もありました。
既設のテレビ回線を利用することが主目的の様ですからその筋の用品が使えるのでしょう。
追記
分波器の条件には「双方向通信」も必要らしい。アンテナから受信機へ一方通行で繋がるだけの物はダメという意味です。
この点を明記した製品は少なく判断が難しいので、MoCA対応と謳われている製品を選んだ方が無難っぽい。
MoCA対応品はMoCA2.0と刻印されている製品が多い様子ですが、MoCA2.0と2.5の違いは同時に通信されるチェンネル数らしいので、MoCA2.0対応品ならMoCA2.5にも使えるような気がします。
#[Art-Net]
分波器と呼ぶべきか分配器と呼ぶべきか、splitterについて参考になったサイトがありました。
「HTEM5 – How do I know if my splitter is MoCA 2.5 compatible?」
Google先生に翻訳して頂いて読むところ、
１）テレビアンテナ用の分配器を使う。
２）双方向通信が可能な物。＜＝追加
３）1000MHz以上に対応する物。
４）MoCA対応と刻印のある製品が望ましい。
てなことが読み取れました。
さらに、ケーブル配線の条件として、
５）経路中に増幅器(アンテナブースター)が無いこと。
６）メインの分配器からの配線は100ヤード(90メートル)以内にする。
との記載もありました。
既設のテレビ回線を利用することが主目的の様ですからその筋の用品が使えるのでしょう。
追記
分波器の条件には「双方向通信」も必要らしい。アンテナから受信機へ一方通行で繋がるだけの物はダメという意味です。
この点を明記した製品は少なく判断が難しいので、MoCA対応と謳われている製品を選んだ方が無難っぽい。
MoCA対応品はMoCA2.0と刻印されている製品が多い様子ですが、MoCA2.0と2.5の違いは同時に通信されるチェンネル数らしいので、MoCA2.0対応品ならMoCA2.5にも使えるような気がします。
#[Art-Net]
同軸ケーブルに Ethernet を通す方法というか規格には「MoCA」(「モカ」と発音？)というのがあるらしい。テレビアンテナからの配線を含め、すでに施工されている同軸ケーブルに Ethernet を通そうという指向みたい。日本語の情報が少ない感じですが、次のサイトが参考になります。
「MoCA 2.5 を使用しTVの同軸ケーブルを使ってLAN構築」
有益な情報が含まれていますが、ここの情報だけではMoCAの全貌は把握出来ません。諸々理解するには少し時間がかかりそうですが、1000mの配線長でＧ(ギガ)クラスのネットワークを構築できるという謳い文句は魅力的です。テレビアンテナに使える同軸ケーブルは安価で入手性がいいので尚更です。
ケーブルには75Ωの同軸ケーブルを用いるそうです。推奨されるケーブルの規格の詳細やグレードは把握できていませんが、すでに施工されているテレビアンテナの配線を利用することも想定してるそうですので最上位グレードのケーブルが求められているワケでもなさそうです。家屋内の商用電源配線にLANを乗せるPLCと似ているとか思ったり。
MoCAの規格は1.0からあり、小売りで手に入る製品では2.5が今のところ最上位みたいです。表記は「MoCA2.5」です。2.5は世代を表すのではなく、スループットの最大理論値が2.5Gbpsって意味らしいです。
この名称で検索するとまぁまぁ出てきますので興味のある方は是非調べてみてください。
具体的な例が見当たらないので人柱をしましょう。amazonに次の製品があったのでポチってみました。先日ポチったのは未出荷だったのでキャンセルです。
「TRENDnet Ethernet Over Coax MoCa 2.5アダプター (2個パック) TMO-312C2K MoCA 2.0/1.1/1.0 RJ-45ギガビットLANポート ネットスループット最大1Gbps対応 最大16ノード対応 ブラック」
期待値は200mくらいの配線で８ユニバースの Art-Net を実用レベルで通せることです。10baseのLANでも可能な内容ですから、これが通らない様では話になりません。
イマイチ不明なのは、上記製品の「同ネットワーク内にノードを16個設置出来る」という謳い文句を形にする配線方法です。会場のあちらこちらに安い線材でノードを置けたら便利だろうなぁ～というイメージはありますが、メーカのマニュアルを読んでも構築の具体例が見当たりません。MoCAに関する他の情報を見ますと分波器を使えば分岐出来るようですが、どんな分波器を意味しているのかがわかりません。上記のサイトを読みますと MoCA2.5 の変調周波数は 1,125〜1,675 MHz らしいので、テレビアンテナの分波器でいいなら 2400MHz まで対応する物を使えばいいのかな？とか思いつつも分からんことだらけです。
入荷には２週間くらいかかるそうです。時間はあるので、空き時間にノンビリと調べを進めましょう。実機が入荷したら１対１接続から始めて分岐の方法も探ってみるつもりです。分波器は中華電機にオーダーしてみました。これも２週間くらいで入荷する見込みです。
あと、設置済みケーブルのインピーダンスの測定方法は次のサイトが参考になります。同軸ケーブルはインピーダンスが合わないと能率が激落ちするので重要です。50Ωでも通るには通るでしょうが、スループットも信頼性もどうなるのでしょうね。
「特性インピーダンスを測定してみました！」
測定にはLCRテスターが必須です。一般のご家庭は知りませんが我が家では常備アイテムです。テスターと繋ぐ先バラケーブルと末端をショートするコネクタを作れば既設の埋め込み配線も測定できると思います。
#[Art-Net]
「MoCA 2.5 を使用しTVの同軸ケーブルを使ってLAN構築」
有益な情報が含まれていますが、ここの情報だけではMoCAの全貌は把握出来ません。諸々理解するには少し時間がかかりそうですが、1000mの配線長でＧ(ギガ)クラスのネットワークを構築できるという謳い文句は魅力的です。テレビアンテナに使える同軸ケーブルは安価で入手性がいいので尚更です。
ケーブルには75Ωの同軸ケーブルを用いるそうです。推奨されるケーブルの規格の詳細やグレードは把握できていませんが、すでに施工されているテレビアンテナの配線を利用することも想定してるそうですので最上位グレードのケーブルが求められているワケでもなさそうです。家屋内の商用電源配線にLANを乗せるPLCと似ているとか思ったり。
MoCAの規格は1.0からあり、小売りで手に入る製品では2.5が今のところ最上位みたいです。表記は「MoCA2.5」です。2.5は世代を表すのではなく、スループットの最大理論値が2.5Gbpsって意味らしいです。
この名称で検索するとまぁまぁ出てきますので興味のある方は是非調べてみてください。
具体的な例が見当たらないので人柱をしましょう。amazonに次の製品があったのでポチってみました。先日ポチったのは未出荷だったのでキャンセルです。
「TRENDnet Ethernet Over Coax MoCa 2.5アダプター (2個パック) TMO-312C2K MoCA 2.0/1.1/1.0 RJ-45ギガビットLANポート ネットスループット最大1Gbps対応 最大16ノード対応 ブラック」
期待値は200mくらいの配線で８ユニバースの Art-Net を実用レベルで通せることです。10baseのLANでも可能な内容ですから、これが通らない様では話になりません。
イマイチ不明なのは、上記製品の「同ネットワーク内にノードを16個設置出来る」という謳い文句を形にする配線方法です。会場のあちらこちらに安い線材でノードを置けたら便利だろうなぁ～というイメージはありますが、メーカのマニュアルを読んでも構築の具体例が見当たりません。MoCAに関する他の情報を見ますと分波器を使えば分岐出来るようですが、どんな分波器を意味しているのかがわかりません。上記のサイトを読みますと MoCA2.5 の変調周波数は 1,125〜1,675 MHz らしいので、テレビアンテナの分波器でいいなら 2400MHz まで対応する物を使えばいいのかな？とか思いつつも分からんことだらけです。
入荷には２週間くらいかかるそうです。時間はあるので、空き時間にノンビリと調べを進めましょう。実機が入荷したら１対１接続から始めて分岐の方法も探ってみるつもりです。分波器は中華電機にオーダーしてみました。これも２週間くらいで入荷する見込みです。
あと、設置済みケーブルのインピーダンスの測定方法は次のサイトが参考になります。同軸ケーブルはインピーダンスが合わないと能率が激落ちするので重要です。50Ωでも通るには通るでしょうが、スループットも信頼性もどうなるのでしょうね。
「特性インピーダンスを測定してみました！」
測定にはLCRテスターが必須です。一般のご家庭は知りませんが我が家では常備アイテムです。テスターと繋ぐ先バラケーブルと末端をショートするコネクタを作れば既設の埋め込み配線も測定できると思います。
#[Art-Net]
本業が忙しい。工作が出来ない。哀しい。
稼がんといけませんので仕方なし。
こんなとき、ちょっとしたアイデアが出るもの。
ジャンク品ですが、5Cクラスと思われるBNC同軸ケーブルと２回路の音声ケーブルが１本になっている複合ケーブル(ジープケーブル)が手元にあります。50mが２本と100mが１本です。
出処は書けませんが、とんでもなく品質の良いケーブルです。もちろん機械強度も高い。
丈夫で長さがあるので音声回線にDMXを通していましたが、考えてみたら同軸ケーブルにEtherでArt-Net通したらよくね？音声回線にはインカムとLTC通したらよくね？
今回は「同軸ケーブルが望ましいので積極採用！」ではなく、ジャンクなケーブルを活かすって意味ですから実用域のアダプタが安く手に入ればアリかな？って話です。
調べてみますと100Mbpsクラスの変換器なら入口出口のセットが１万円くらいで手に入ります。DMXマルチケーブルや屈強なLANケーブルで作ることを考えたら十分に安い。こんなんでもカタログスペックでは数百メートル引き回せるそうですから十分。
これは試すしかありませんのでポチリました。
幸い株で稼いだ分で賄えます。このところ株価の動きがアホみたいに大きいので、たまたま波に乗れたら３週間で原資の８％くらい取れました。巧い人は１年で何倍にもするのでしょうが、博才が皆無な私でも４月から月平均６％くらい取れています。どこに預けても増えるどころか実質目減りですから、損切り上等！で波を読むことを楽しんでます。現物なら目減りしても借金を背負うことはありませんから気楽なものです。運が良ければ持ち金が増える課金ゲームですね。昨年はちょっと負けましたが、自分に対する待ちどころがわかり始めた今年は負け分を取り返して小遣いくらいは稼げてます。自分を相手にポーカーをしているような気分ですけど。
#[Art-Net]
稼がんといけませんので仕方なし。
こんなとき、ちょっとしたアイデアが出るもの。
ジャンク品ですが、5Cクラスと思われるBNC同軸ケーブルと２回路の音声ケーブルが１本になっている複合ケーブル(ジープケーブル)が手元にあります。50mが２本と100mが１本です。
出処は書けませんが、とんでもなく品質の良いケーブルです。もちろん機械強度も高い。
丈夫で長さがあるので音声回線にDMXを通していましたが、考えてみたら同軸ケーブルにEtherでArt-Net通したらよくね？音声回線にはインカムとLTC通したらよくね？
今回は「同軸ケーブルが望ましいので積極採用！」ではなく、ジャンクなケーブルを活かすって意味ですから実用域のアダプタが安く手に入ればアリかな？って話です。
調べてみますと100Mbpsクラスの変換器なら入口出口のセットが１万円くらいで手に入ります。DMXマルチケーブルや屈強なLANケーブルで作ることを考えたら十分に安い。こんなんでもカタログスペックでは数百メートル引き回せるそうですから十分。
これは試すしかありませんのでポチリました。
幸い株で稼いだ分で賄えます。このところ株価の動きがアホみたいに大きいので、たまたま波に乗れたら３週間で原資の８％くらい取れました。巧い人は１年で何倍にもするのでしょうが、博才が皆無な私でも４月から月平均６％くらい取れています。どこに預けても増えるどころか実質目減りですから、損切り上等！で波を読むことを楽しんでます。現物なら目減りしても借金を背負うことはありませんから気楽なものです。運が良ければ持ち金が増える課金ゲームですね。昨年はちょっと負けましたが、自分に対する待ちどころがわかり始めた今年は負け分を取り返して小遣いくらいは稼げてます。自分を相手にポーカーをしているような気分ですけど。
#[Art-Net]
照明器具のメンテナンスでは製作中のArtNet-Engineを通してDMX信号を送っています。
入力をデコードして一時スタックし、それをエンコードして送るだけの状態ですが、目に付く遅れもなく不審な挙動もなく何の芸もなく普通に動きます。
今のところ遅れても１フレームなので、このレスポンスでまとまれば御の字かなと。当たり前が当たり前に出来ればそれでいいのです。
ボチボチ現場対応も増えつつあり、部下の仮打ちが終わって作業スペースを確保出来たので本業の道具もメンテナンスしなければなりません。ArtNet-Engineなど趣味の開発はペースダウンです。
#[Art-Net] #電子工作
入力をデコードして一時スタックし、それをエンコードして送るだけの状態ですが、目に付く遅れもなく不審な挙動もなく何の芸もなく普通に動きます。
今のところ遅れても１フレームなので、このレスポンスでまとまれば御の字かなと。当たり前が当たり前に出来ればそれでいいのです。
ボチボチ現場対応も増えつつあり、部下の仮打ちが終わって作業スペースを確保出来たので本業の道具もメンテナンスしなければなりません。ArtNet-Engineなど趣味の開発はペースダウンです。
#[Art-Net] #電子工作
ANSIエスケープシーケンスによるテキスト画面表示はやりたいことのやり方が見えてきました。先にも書いた通り、ウィンドウマネージャに近い考え方で関数ライブラリにまとめる方針です。
ArtNet-Engineの主処理を書き進めたいところですが、処理の状況を確認する手段が無いと作業性が悪いので画面表示を一通り作ってしまおうという考え方です。
平行してコマンド入力も作っています。ArtNet-Engineの主処理に先行するのは画面と同じ理由ですが、この辺りが見えてこないと処理全体の構成を決めかねることにも繋がるからです。
ですが、コマンド入力がなかなか手ごわい。画面表示であれば決められた手順で結果が出ればいいのですが、コマンド入力は規則性が薄いユーザーの操作を受け付けるからです。scanf()などを用いて文字列を取得するのは簡単ですが、これではイメージする操作性にはなりません。特定のキーをショートカットのコマンド入力とし、一つ目のコマンドに続くコマンドを制限したい。コマンドに与える数値も範囲を制限もしたい。もちろん、適切なエラーメッセージを入力の都度出したい。キー入力の都度、制限と処理を行うことになりますが案外難しい。ダラダラとコマンド毎に専用処理を書いてもいいのですが、メンテナンス性を考えると出来るだけ汎用化したい。もちろん、他のコマンドを学習したユーザーがこのコマンドはこう打てばいいだろうと予測出来る適切なコマンド体系にもしたい。プログラムを書く前のアルゴリズムを考えるのに難儀しています。
#[Art-Net] #Ｃ言語
ArtNet-Engineの主処理を書き進めたいところですが、処理の状況を確認する手段が無いと作業性が悪いので画面表示を一通り作ってしまおうという考え方です。
平行してコマンド入力も作っています。ArtNet-Engineの主処理に先行するのは画面と同じ理由ですが、この辺りが見えてこないと処理全体の構成を決めかねることにも繋がるからです。
ですが、コマンド入力がなかなか手ごわい。画面表示であれば決められた手順で結果が出ればいいのですが、コマンド入力は規則性が薄いユーザーの操作を受け付けるからです。scanf()などを用いて文字列を取得するのは簡単ですが、これではイメージする操作性にはなりません。特定のキーをショートカットのコマンド入力とし、一つ目のコマンドに続くコマンドを制限したい。コマンドに与える数値も範囲を制限もしたい。もちろん、適切なエラーメッセージを入力の都度出したい。キー入力の都度、制限と処理を行うことになりますが案外難しい。ダラダラとコマンド毎に専用処理を書いてもいいのですが、メンテナンス性を考えると出来るだけ汎用化したい。もちろん、他のコマンドを学習したユーザーがこのコマンドはこう打てばいいだろうと予測出来る適切なコマンド体系にもしたい。プログラムを書く前のアルゴリズムを考えるのに難儀しています。
#[Art-Net] #Ｃ言語
RaspberryPi4Bが正価で入手出来たと先日書きました。国内はまだの様ですが、中国からRaspberryPiCM4も正価で入手出来ました。
CM4は組込み用途に特化し過ぎているために単体では何も出来ませんが、用途に合わせてインターフェースボードを作ればコンパクトでスッキリしたハードウェアを構成出来ます。
いずれオリジナルのインターフェースを作ってみたいと思っていますが、とりあえずはEtherNetが２口付いた既製品と共にCM4をオーダー。
ArtNet-PatchはCM4を用いて作りたいのです。プログラミングには4Bを使っていますが、製品にするにはちょっと違うので。
#RaspberryPi #[Art-Net]
CM4は組込み用途に特化し過ぎているために単体では何も出来ませんが、用途に合わせてインターフェースボードを作ればコンパクトでスッキリしたハードウェアを構成出来ます。
いずれオリジナルのインターフェースを作ってみたいと思っていますが、とりあえずはEtherNetが２口付いた既製品と共にCM4をオーダー。
ArtNet-PatchはCM4を用いて作りたいのです。プログラミングには4Bを使っていますが、製品にするにはちょっと違うので。
#RaspberryPi #[Art-Net]
ArtNet-Engineの入口出口キー操作は触るたびに問題点が見えてきます。なかなか次に進めません。
次の課題は受信スタックです。これは得たデータをレーンと呼ぶ内部的な経路と送信元毎に仕分けしたモノです。８レーン８送信元、６４ユニバースの一時保存です。一見データ量が多いようですが32kBです。映像画像に比べたらわずかな量です。
受信毎に本処理まですればいい気もしますが、送信元から送られるデータは時間的に一定ではありませんので、受信の都度本処理までするとややこしくて重くなるのです。
ならば、一定の規則で受信データを整頓し、送信元×レーン毎の入れ子に最新値という形で一時保存してから本処理を行えばシンプルな処理になります。
こんなややこしいことをしてもDMX規格の最大速の１フレーム程度にレイテンシーを抑えようとしています。
もちろんタイムアウトも必要です。DMXはデータが１秒間更新されなければ送信が無くなったと判断する規格ですから受信日時を見て判断します。これは優先度が低い処理ですから優先度が高い処理が実行されない空き時間を用います。極端な話、タイムアウトは１秒が基本でも５秒かかったところで実用上の問題は無いと考えます。そんなにかかることは無いと思いますが、２秒くらいで処理されれば実用だと思います。それ以前にDMXのタイムアウトが１秒ってことを知る人が少ないのですから気にしない。
#[Art-Net]
次の課題は受信スタックです。これは得たデータをレーンと呼ぶ内部的な経路と送信元毎に仕分けしたモノです。８レーン８送信元、６４ユニバースの一時保存です。一見データ量が多いようですが32kBです。映像画像に比べたらわずかな量です。
受信毎に本処理まですればいい気もしますが、送信元から送られるデータは時間的に一定ではありませんので、受信の都度本処理までするとややこしくて重くなるのです。
ならば、一定の規則で受信データを整頓し、送信元×レーン毎の入れ子に最新値という形で一時保存してから本処理を行えばシンプルな処理になります。
こんなややこしいことをしてもDMX規格の最大速の１フレーム程度にレイテンシーを抑えようとしています。
もちろんタイムアウトも必要です。DMXはデータが１秒間更新されなければ送信が無くなったと判断する規格ですから受信日時を見て判断します。これは優先度が低い処理ですから優先度が高い処理が実行されない空き時間を用います。極端な話、タイムアウトは１秒が基本でも５秒かかったところで実用上の問題は無いと考えます。そんなにかかることは無いと思いますが、２秒くらいで処理されれば実用だと思います。それ以前にDMXのタイムアウトが１秒ってことを知る人が少ないのですから気にしない。
#[Art-Net]
本業はちょいちょいで終わったのでArtNet-Engineを書き進めました。
ユニバースによる処理時間のムラはサンプルデータとして使っているMAdot2の仕様によるものみたいです。細かくは計測していませんが、８ユニバース出すとして、ユニバース毎に均等の時間割りで送信するのではなく、８ユニバースを一気に送信して長い休みを入れているようです。このため、最初のユニバースでは処理が重くなり、後のユニバースでは処理が軽くなる現象が起きるのだと思われます。主にArtNet-Engineからの送信に影響があったようで、受信したら即送信していたものを一時スタックしてからユニバース毎に均等の時間割りで送信する様にしたところムラが無くなりました。RaspberryPiの送信処理に何か負担がかかっていたのでしょう。
現時点での１フェーズの処理時間は平均して100usec以下です。出現確率が高い例外値が250usecくらいで、極マレに出てくる最大値が900usecくらいです。処理時間が保証されないOSですからこんなもん？。
作りたい物にはなりそうですが、８ユニバース８卓(６４ユニバース入力)は厳しい気がします。これに対応するには１フェーズが確実に350usec未満でなければなりませんが、例外値がやってきた時にプリフリーズを起こしそうです。登録できる調光卓(送信元)は８台ですが、同時に使える(HTPミックスの対象となる)のを３-４台くらいにしておけば現実的かもしれません。Art-Netの規格書に「マルチキャストは４０ユニバースが上限だと思いますよ」と書いてあるのは伊達じゃないようです。
どの要素が時間を使っているのか不明なので組んで実測しますかね。ダメなら減らすダケです。
ただ、構造体とポインタが使えるとこういったデータ処理は楽です。構造体はPythonのタプルに似ていますがシンプルなのでPythonより書きやすいかもしれません。ポインタは参照渡しですのでデータの扱いが速いのです。それ以前に何をするにも速いですけど。
追記
調整したところ、１ユニバース受信する１フェーズが平均30usec、例外値が200usec程度になりました。
同時に８卓使っても１本のArt-Netに統合する現場はマレだと思いますケド、間に合いそうな数値が出たので、その様に書いて後で調整します。増やすのは大変ですが減らすのは簡単ですから。
送信の間隔はユニバース数と希望fps数から自動計算にしました。将来的にfpsを設定して調整出来れば良いかなと。
#[Art-Net] #Ｃ言語
ユニバースによる処理時間のムラはサンプルデータとして使っているMAdot2の仕様によるものみたいです。細かくは計測していませんが、８ユニバース出すとして、ユニバース毎に均等の時間割りで送信するのではなく、８ユニバースを一気に送信して長い休みを入れているようです。このため、最初のユニバースでは処理が重くなり、後のユニバースでは処理が軽くなる現象が起きるのだと思われます。主にArtNet-Engineからの送信に影響があったようで、受信したら即送信していたものを一時スタックしてからユニバース毎に均等の時間割りで送信する様にしたところムラが無くなりました。RaspberryPiの送信処理に何か負担がかかっていたのでしょう。
現時点での１フェーズの処理時間は平均して100usec以下です。出現確率が高い例外値が250usecくらいで、極マレに出てくる最大値が900usecくらいです。処理時間が保証されないOSですからこんなもん？。
作りたい物にはなりそうですが、８ユニバース８卓(６４ユニバース入力)は厳しい気がします。これに対応するには１フェーズが確実に350usec未満でなければなりませんが、例外値がやってきた時にプリフリーズを起こしそうです。登録できる調光卓(送信元)は８台ですが、同時に使える(HTPミックスの対象となる)のを３-４台くらいにしておけば現実的かもしれません。Art-Netの規格書に「マルチキャストは４０ユニバースが上限だと思いますよ」と書いてあるのは伊達じゃないようです。
どの要素が時間を使っているのか不明なので組んで実測しますかね。ダメなら減らすダケです。
ただ、構造体とポインタが使えるとこういったデータ処理は楽です。構造体はPythonのタプルに似ていますがシンプルなのでPythonより書きやすいかもしれません。ポインタは参照渡しですのでデータの扱いが速いのです。それ以前に何をするにも速いですけど。
追記
調整したところ、１ユニバース受信する１フェーズが平均30usec、例外値が200usec程度になりました。
同時に８卓使っても１本のArt-Netに統合する現場はマレだと思いますケド、間に合いそうな数値が出たので、その様に書いて後で調整します。増やすのは大変ですが減らすのは簡単ですから。
送信の間隔はユニバース数と希望fps数から自動計算にしました。将来的にfpsを設定して調整出来れば良いかなと。
#[Art-Net] #Ｃ言語
本業もやらねばなりませんがArtNet-Engineも進めたい。
ArtNet-Engineの課題はデータ処理の構成です。
まずは入力です。同じネットワークに複数の調光卓を繋ぐことは出来ますが、ユニバースの重複によるトラブルには対策が必要です。
送信元IPアドレスで仕訳けることが基本になると思いますが、どうせなら選択しつつマージしてしまおうかと。
フェスなどでは複数の調光卓を設置して使い分けるのはよくあることです。単純な差し替えとかネットワーク切り替え機などを使ってもいいのですが、選択とマージ(HTPミックス)が出来たらそれはそれでいいかなと。バックアップ卓を併設することも出来るし。
内部的には８ユニバースのパッチを考えていますが卓も８台想定します。６４ユニバースの交通整理をするのでRaspberryPiの処理能力で間に合うのかわかりませんがダメなら数を減らします。
当面は送信元の仕分けと６４ユニバースを８ユニバースにマージする処理を書きます。
処理の構造をどうするか考えていますが、データの保存には構造体配列や構造体の中に構造体を入れるなど複雑な変数構成が必要になりそうです。
Pythonとは違い、for文が速いＣ言語なら繰り返しと条件分岐を織り交ぜた処理も書きやすそうです。Ｃ言語の習得の難所でもあるポインタもこういった処理では効果を発揮します。
#[Art-Net] #Ｃ言語
ArtNet-Engineの課題はデータ処理の構成です。
まずは入力です。同じネットワークに複数の調光卓を繋ぐことは出来ますが、ユニバースの重複によるトラブルには対策が必要です。
送信元IPアドレスで仕訳けることが基本になると思いますが、どうせなら選択しつつマージしてしまおうかと。
フェスなどでは複数の調光卓を設置して使い分けるのはよくあることです。単純な差し替えとかネットワーク切り替え機などを使ってもいいのですが、選択とマージ(HTPミックス)が出来たらそれはそれでいいかなと。バックアップ卓を併設することも出来るし。
内部的には８ユニバースのパッチを考えていますが卓も８台想定します。６４ユニバースの交通整理をするのでRaspberryPiの処理能力で間に合うのかわかりませんがダメなら数を減らします。
当面は送信元の仕分けと６４ユニバースを８ユニバースにマージする処理を書きます。
処理の構造をどうするか考えていますが、データの保存には構造体配列や構造体の中に構造体を入れるなど複雑な変数構成が必要になりそうです。
Pythonとは違い、for文が速いＣ言語なら繰り返しと条件分岐を織り交ぜた処理も書きやすそうです。Ｃ言語の習得の難所でもあるポインタもこういった処理では効果を発揮します。
#[Art-Net] #Ｃ言語
各所の処理タイミングで難儀しましたが、第１フェーズと呼んでもいい段階は終わりました。
まとまったのは次の通り。
１）Art-Netを受信してデコード。
２）エンコードして送信。
３）受信値を表示。
４）カーソルキーでユニバースを切り替えるなど、キーボードによる画面操作。
この程度ではありますが、これから先の基本が多く含まれているのでかなりの進歩だと自画自賛。
スッキリした画面に値がキレイに表示されると気持ち良いです。
ちなみに、画面表示を除く主処理１フェーズの所要時間は平均150usec、最大600usecくらいです(30fps:8ユニバースのArt-Netを受信/デコード/エンコード/送信する処理)。Pythonに比べたら圧倒的に速い。
今後機能を追加してどれくらい重くなっていくのかは未知数ですが、現時点では期待値込みの次第点でしょう。
次はデータ処理の本丸です。
Pythonである程度作れた処理ですが、Pythonならではの便利機能が使えないなら私にとってかなり難しいことなので、処理の手順をキッチリ考えたいと思います。
追記
処理タイミングを調整したところ１フェーズの処理時間が50usec程度減りました。小さな数値ですが比率としては大きい。
不思議なのは、受信している８ユニバース中、０ユニバースに比べ７ユニバースの処理が倍くらい速く処理時間の変動が少ないことです。出力のフレームレートをDoctorMXで計測すると同じ値なので謎です。今は動いているバグですと後々問題になりそうそうなので確認しますが、速いユニバースは１フェーズ90usec前後で安定して動いているのでこれが平均になれば御の字です。この数値で揃えば現在考えている最大規模も処理出来ると思います。
#[Art-Net]
まとまったのは次の通り。
１）Art-Netを受信してデコード。
２）エンコードして送信。
３）受信値を表示。
４）カーソルキーでユニバースを切り替えるなど、キーボードによる画面操作。
この程度ではありますが、これから先の基本が多く含まれているのでかなりの進歩だと自画自賛。
スッキリした画面に値がキレイに表示されると気持ち良いです。
ちなみに、画面表示を除く主処理１フェーズの所要時間は平均150usec、最大600usecくらいです(30fps:8ユニバースのArt-Netを受信/デコード/エンコード/送信する処理)。Pythonに比べたら圧倒的に速い。
今後機能を追加してどれくらい重くなっていくのかは未知数ですが、現時点では期待値込みの次第点でしょう。
次はデータ処理の本丸です。
Pythonである程度作れた処理ですが、Pythonならではの便利機能が使えないなら私にとってかなり難しいことなので、処理の手順をキッチリ考えたいと思います。
追記
処理タイミングを調整したところ１フェーズの処理時間が50usec程度減りました。小さな数値ですが比率としては大きい。
不思議なのは、受信している８ユニバース中、０ユニバースに比べ７ユニバースの処理が倍くらい速く処理時間の変動が少ないことです。出力のフレームレートをDoctorMXで計測すると同じ値なので謎です。今は動いているバグですと後々問題になりそうそうなので確認しますが、速いユニバースは１フェーズ90usec前後で安定して動いているのでこれが平均になれば御の字です。この数値で揃えば現在考えている最大規模も処理出来ると思います。
#[Art-Net]