Show Technology2

トータルショーコントロール/(株)Mileruntechのブログ

ネットワーク&プロトコル

周波数ホッピング

spectrum CRMX

 知人からLumenRadioの電波がWi-spyだと弱々しく映るので心配という連絡をいただき、おや?と思って調べたのですが、当社で扱うLumenradioのDMXワイヤレスは、周波数ホッピングという方式を使っており、1MHz単位で高速に周波数を切換えるシステムです。これは送信機と受信機間でIDを参照し、互いに同期して電波を切り替えるもので、同じ環境にCRMXの送信機が何機あろうが、それぞれに接続した受信機との間で、それぞれにホッピングパターンを変えて、互いが干渉することなく、通信を行う事が可能です。

拡散周波数方式の一種に分類されるこのホッピングシステムですが、通常の周波数拡散方式が、中心周波数を挟んで5MHzを1つのチャンネルと定義し、このチャンネルを1つ選んで、一定の周波数帯域全体で電波を放出するのに対し、ホッピング方式だと、特にLumenradioの場合、2.4GHzから2.5GHzの間で、1スロット(1MHz)単位で、しかも自動で切り替えるシステムのため、通常はWiFiなどのためのサイトサーベイツール(事前調査)では、うまく表示しないのではないかと想像します。(Wi-spyについては、あまり詳しくないので、お店の人に確認したところ、そういう回答でした)

日本の電波法の規定では、電波の強さは、送信する帯域全体で見るようなので、周波数ホッピングシステムの場合、かなり広い範囲で電波を放出することとなり、1スロットあたりの強さは、3mW以下にするよう規定されています。(通常のチャンネル単位で行うSS方式は10mW以下)そういう意味では、Wi-spyのようなスペクトラムアナライザーにうまく表示されなくても当然かもしれません。

写真は、LumenRadioに付属するスペクトラムアナライザーですが、当然のことながらリアルタイムでの周波数切換えを表示することはできません。このツールは、Lumenradioの送信機のアンテナを利用して、周辺に飛ぶ電波を表示してくれる便利なツールです。これを見るとオレンジが周辺のワイヤレスの電波で、グリーンがCRMX自身が出す電波という表示です。ここで見る限り、帯域全体にグリーンが表示され、広く分布しているのがわかります。また、グレー表示は、よくぶつかる範囲を使用しないようにこちらでKiLLした範囲のチャンネルです。こうすることで、周辺機器との共存も可能になります。
こうした点がLumenradioの特徴で、その良さでもあります。ちなみに最大の送信距離は、500mになります。(もちろんよい環境でのことです)




舞台業界 制御システムのネットワーク化の今

照明のネットワークシステム推進論者 ? として、当ブログでは、この4年ほどの間、さまざまな情報を発信するとともに、昨年には、照明家協会のセミナーのほか、InterBEEという展示会でも話をする機会を得ました。関係方々には、感謝をいたしております。

 そのおかげで、皆様方において、ネットワークシステムについてのご理解が進んでいるのではないかと思っておりますが、時々いただくご意見に、私の主張が1つの方向性に偏っている印象を与えているように感じることがありますので、再度、この誤解を解くべく、話をしておきたいと思います。

 まず、照明のプロトコルに関して、私はアートネットだけを推進しているわけではありません。さりとてsACNだけがベストな選択肢だとも思わないし、パスポートプロトコルが悪いとも思いません。結局、今、使いやすいプロトコルを複数サポートしておけば、使う側が選択する話で、実はそれでいのではないかと思います。しかし、今、互換機材が多いのはアートネットなので、アートネットが便利であるのは確かです。そしてメディアサーバーも扱っている自分としては、アートネットは特定の企業が作ったプロトコルであろうと、ここまで広く普及したら、否定はできない。これも事実だと思うのです。

思うに、通信プロトコルはオープンなほうがよいし、その意味では、アートネットもsACNもそのどちらもが選択肢に入るだろうと思います。ただ、残念ながら、プロプライエタリープロトコルは周囲のさまざまな機器との互換を考えると、大きなシェアを持つのは難しいと言わざるを得ません。

次に、ネットワークの冗長化について、リングプロトコルを使ったトポロジーだけを推奨しているわけではなく、舞台向けの冗長化の仕組みとして、リングトポロジーの仕組みが最適だと感じているため、お薦めしているのであって、決してスパニングツリーが悪いと言っているわけではないのです。
正直、リカバリー速度などの点で、リングほど高速でなくてもよいのなら、ラピッドスパニングツリーを使用してもよくて、またそれほど多くのスイッチを使うことがなければ、例えば2台しかないといった場合に、リンクアグリゲーションでケーブルを複数つないでもいいのだろうと考えます。

冗長化の仕組みは、通常の状態では機能しておらず、万が一の保険のような部分でもありますが、その施設の大きさに応じて、そこにどれだけのコストがかけられるか? というバランスで決まるものだろうと思います。よって、施設の特性によっては、リングトポロジーの冗長化などが、最適な場合もあれば、逆に過剰な設備に なってしまう場合もあるし、私は、必ずしもリングプロトコルのネットワーク化が必要だと言っているつもりはないのです。

 おそらく、これまで当ブログにおいてや、セミナーの他、協会雑誌などで私が発信する内容が、リングプロトコルを使った冗長化のシステムに集中していたため、まるでそのシステムの伝道者のような視線を浴びてしまったのであろうと感じます。(何年か前、とにかくリングトポロジーの良さを皆さんにお伝えしたかったの は事実ですが)

残念なのは、こうした行為によって、私が他のシステムに対して排他的な姿勢にあると多くの人に印象つけてしまったことかもしれません。でも、それは誤解で、リングトポロジーを組むほどの規模ではないという場合、先にあげたラピッドスパニングツリーなどのシステムを利用するのは、やぶさかではありません。要はその設備にマッチしたものを選択するということですね。

追記

幹線の選択について、規模が大きくなった場合、光ケーブルの選択は、私はベストだと感じています。
ノイズレスの点、将来性についても、光ケーブルはよい選択ではないでしょうか?





誰でもから難しいまで。。

花粉舞い散る季節になり、気分もブルーな3月です。
今日はある映像設備会社さんから送られて来たシリアルデバイスサーバーとネットワークスイッチのチェックを行いました。これはCatalystからプロジェクターのシャッターを制御するためにネットワーク経由でRs232コマンドを取り出すための装置です。

ネットワークスイッチは、アライドテレシスのスイッチングハブで、8ポートの単純なスイッチのわりに、コンソールポートもあり、SFPポートもあって、市場価格で5万円程度なれど、VLAN設定もできるというスイッチです。選択として悪くはありませんが、ここの製品、コンソールポートにあるRJ45の端子からRS232の変換がついていないので、それは別途購入くださいという不親切さ。HPとかシスコさんのは、変換ケーブルとかついてると思うのですが、せっかくブラウザーからの設定も可能なのに、IPをセットすることも、それを有効に切り替えることもできず、まあ、今回はそういう用途ではないから設定は無視します。(8ポートなら、そんな設定必要ないだろ?ということですね)

 こうして世の中、コンピューターを利用すると、なにかとネットワークが必要となり、今回のようなしょぼいネットワークであれば、皆が言う馬鹿ハブとか「すいっちんぐはぶ」とかで、ネットワークなんぞは、誰でも作れるというのは、きっと皆が承知しているとおりでしょう。

このイーサネットのよさは、本当に単純で誰でもできる簡単さが、良さでもあるのですが、ある一定規模に数が増えて、堅牢なシステムとかトポロジーとか考えだすと、1つ敷居が上がるのも事実。そしてL2レベルからIPルーティングのL3レベルに入ると、難しさが増してくるというのもあります。

スイッチがある一定数に増え、リングプロトコルやスパニングツリーなどを利用するとか、ノードもある程度の数に達すると、簡単なはずのネットワークも1つのシステムとして設計する段階に入ると思います。そしてネットワークからネットワークへとつなぐルーティングが入ってくると、また1つレベルが上がり、グローバルなネットワークにつなぐ段階になると、セキュリティーも考慮するようになるので、誰でもできるレベルではなくなってくる。この幅の広さがネットワークシステムの深さでもある。

今月も、ある施工現場でCatalystとコントローラを結ぶネットワークは電気屋さんが引いたCat5とオフィス用の「すいっちんぐはぶ」とやらでインフラは用意され、ネットワークなんてものは誰も特別視などしていないし、誰でもできるレベルの話なんでしょう。それでいい規模の場合なら、そのインフラで仕事をするだけですが、こうした環境で仕事をしながら、劇場のネットワークなどに関わると、本当にネットワークシステムというのは幅が広いと感じます。誰でもわかるし、作れるのだけど、実は奥が深い。




入荷したCRMX

IMG_1851

 長い間お待たせしていたルーメンレディオのCRMX及びRXを仕入れました。
技適マークの取得に苦労はしたものの、これだけ苦労すると我が子のようにかわいくなるものです。
この電波製品は、もしかすると光ファイバーのように、また投入タイミングが違うのかもしれませんが、ネットワークに対応したワイヤレスDMXというマイルランテック的にどまんなかを突いた製品を、どうしても放っておくことができませんでした。

電波製品は、その特性を理解して、うまく活用することで、良い結果が得られるのではないかと期待していますが、さすがにすべてをワイヤレスで行きましょうなどということはなく、弊社的にはネットワークシステムを補完する目的で、末端のどうしてもワイヤリングが不可能な場所などに活用して欲しいと思っています。また、最近はムービングライトのほうで、受信機を搭載した機種もあるので、活用の機会も増えるかもしれません。






投入時期が重要

先週、機材レンタルを行っている照明会社さんに、そういえば、直接お話をしたこともないし、もしかしたら光ファイバーとかその手の製品に興味があるだろうか?と想像し、デモをしたい旨を伝え、伺ったのだが、かなりするどい指摘をいただき、そこにはまったく必要がなかったような印象を受けた。

 まず第一にレンタル会社のお客さんが、照明器具は借りたとしても、光ケーブル指定でお願いしますとは言わないだろう。単に動くようにしてくれというだけである。
次に、光ケーブルを利用する現場というのは、ケーブルを延長する距離が何百メートルにも達するような現場であって、毎回そういう現場になるとは限らず、通常はCat5eのケーブルで問題ないのかもしれない。この点については、わざわざ光にメディア変換しなくても、Cat5eでも同様にイーサ化は可能だし、光にすることでメディアコンバーターまで必要になるのはコスト高になりすぎるということ。

正直、2年前にFiberFoxのケーブルを見つけた時は、心から感動し、多くの人の問題を解決できると思ったのだが、実際には、照明さんも電飾さんもすでになんらかの光ケーブルを導入済みかまたは、今回の例のようにまったく必要がないかで、残念ながらFiberFoxは投入時期を間違ったのかもしれない。本当にいいケーブルなのだが、いい製品だから売れるわけでもない。タイミングは重要なのだ。どうやら照明分野では、あまり必要がなかったようである。

しかしながら、FiberFoxはDVIエクステンダーとして、一部の映像さんの間でご好評をいただいてるので、無駄にはならなかったと思うし、また一部の照明さんにおいても、ツアー等でご利用いただき、高い評価をいただいているため、決して悪い選択ではなかったと考えてもよいのだろう。

さて、そんなわけで、今後のFiberFoxの販売チャンネルは、特定のチャンネルに固定する予定で、今のところ、照明業界向けには、富士ライト商事さんと、映像業界向けにはシーマさんを通して販売していくつもりです。(劇場等向けにはメーカーさんを通しての販売です)





基幹システムの保護について「まとめ」

久しぶりの更新です。今回は、少しネットワークの話をしてみます。
弊社は他の方々がどう思われているかは、さておき、照明信号の分配に関するネットワークシステムを提供する会社だと自負しており、機器のご提供だけでなく、自分たちの考えるシステム構築に関するアイデアや情報をご提供することも重要な役目であると感じている次第です。

そんなわけで、昨年のInterBEEにおいては、ネットワークの知識と題したチュートリアルセッションなどにも登壇させていただいたし、またこれまでにも、照明設備においては、リングプロトコルを利用した冗長化の仕組みは有効であると、解説をしてきました。(リングプロトコルの解説

この話は、特にDMX信号の基幹経路として、リングプロトコルを利用した冗長化がもっとも有効であるという論旨で、決して末端のスイッチや、特定のスイッチにぶら下がるノード等の機器までをも保護する目的ではなく、コンソール側のスイッチが2重化できる上に、経路が2重化されることで、信号経路のための予備回線を設けることができるというものです。

このシステムにおいては、各拠点での電源喪失や、トラブルによってシステム全体をダウンさせないという意図があり、ネットワークにつながるすべての装置をバックアップするようなものではないです。しかし、これまでにも、バックアップシステムを強調するがあまり、基幹システムの保護の観点を逸脱し、末端の機器にまでバックアップが効かなければ、こうした仕組みは意味がないというような誤解した論理を展開される方や、ノードの末端までリングにすべき?というような話もあり、バックアップシステムとか冗長化というと、かなり話が飛躍するものだと感じたものでした。

 リングプロトコルによる冗長化の良さは、そのリカバリー時間の早さ、システム全体の保護の有効性にあり、スイッチ個々の故障すべてに対応するものではなく、本当にすべての機器のバックアップを考慮するなら、すべての装置、ノードやムービングライトや何もかもが2台以上必要になり、事故が発生する確率に対して保護を計るためにかかるコストとのバランスは大きく崩れます。そこは皆さんご理解いただけるものと思います。

 さて、幹線の保護に最適なのは、言うまでもなくリングトポロジーの仕組みですが、経路を2重化する点では、物理トポロジーがリングのようにシンプルならば、ラピッドスパニングツリープロトコルでも同様の効果が得られるでしょう。(切り替わる速度は、やはりリングが早いですが)私はスパニングツリーの仕組みを否定しているわけではないので、切り替わり速度が高速なラピッドスパニングツリーを利用するのなら決して反対ではないのです。ただ比較するならリングプロトコルのほうがどうしても高速になりますよね?ということです。このあたりはコストとまた効果を天秤にかけてバランスをとっていただければいいのでしょう。

そして、末端のノードや機器に至る経路を2重化したいというのであれば、ノードそのものがトランクポートを持ち、リンクアグリゲーションのような仕組みで複数のイーサネットポートで受信する方法があります。ただ、ノードはそこまでは対応しておらず、現時点でこれは不可能ですが、ネットワークの技術を使えば、こうしたことは可能になるのは確かです。コストの面はさておいてですが。






小劇場にもネットワークシステム

cbgk_008

 渋谷のど真ん中に位置する小劇場に仕事で行った友人が、「小さいのにさ、ネットワークシステムになってて、進んでるんだよね。DMXなんてあちこちに出てるからケーブル引かなくていいんで便利だったよ」と言ってくれた。「そう、そこはうちの製品でネットワークシステムを組んだんだよ」という会話がつい最近ありましたが、ようやく写真をいただいたので更新しました。

シブゲキ

この劇場はライティングデザイナーの方が設計した劇場で、彼が考えるシステムでは、やはり将来に向けてDMXはネットワーク化しておきたいし、映像設備などもメディアサーバーを考えているとのことで、相談の連絡があり、以前からの知り合いでもあったことから、もちろん喜んで引き受けました。

この劇場は、場所が渋谷なだけに、有名な劇団などが公演を行うわけで、おそらくは尖った演出が多く行われる事でしょうし、DMXユニバースはさほど使わないとしても、今後のLED化を見越してネットワークにしておきましょうということになり、とは言うものの、大劇場のような大きな設備ではないため、イーサネットケーブルの距離も100m以内に収まる事から、光ケーブルは使わず、リングトポロジーのシステムは持ち込みませんでした。

よって、調光室にあるGigabitSwitchから上手と下手の2カ所に向けてCat6ケーブルが引かれ、キャットウォークやステージのノードはこの2つのGigabitSwitchに分散して接続されています。ノードは昨年、発売されたばかりの2ポートノードのトラスタイプが採用され、これが劇場内に分散配置されます。

友人は主に演劇分野でデザインやオペレーションなどを行ういわゆる照明さんですが、彼曰くは、あまり深く考えなくてもあちこちにノードがあってDMXはそこから取ればいいわけだから簡単だよと言ってくれているので、小劇場の世界でもこうしたネットワークシステムは作業時間の短縮になり、作業効率の改善に役立っているように見えます。つまりネットワークを使うとか使わないとか、またユニバースはそんなに必要ないということではなく、DMXインフラがすでにあるというキャパシティーが、作業効率だけでなく、デザインや仕込み自体にふくらみや安心を与えるのであると思うのです。

*ちなみに、こうした設備でやり玉にあがるネットワークのせいで、カットインアウト等の反応の遅さが気になるというのは、コンソールのリフレッシュレートの遅さが根本原因であり、コンソールがネットワーク対応のものか、より早いリフレッシュレートになると改善します。




LumenRadio製品の技術基準認証取得

長い長いトンネルが続きましたが、ようやく認証がおりたとの電話をもらいました。
ワイヤレス製品の販売というのは、本当に大変な手間がかかります。しかし、本当によい製品を多くの方々にご提供したいという思いは強く、この製品については、なんとかして販売したいと思いました。
そして、ようやくその認証がおりたわけです。

CRMXのテクノロジーについては、こちらのページをご覧下さい。


これにより、今月からご注文受付が可能になるとともに、お貸し出しも可能になりました。デモ機材を数台ご用意しておりますので、テストしてみたいと言うご要望があれば、ご連絡ください。
プロフィール

mrt_usami

タグクラウド
QRコード
QRコード
  • ライブドアブログ