(57)【特許請求の範囲】
【請求項１】
オーディオ通信システムの方法において、
１つ以上の有線オーディオデバイス用の有線ネットワーク上および１つ以上のスレーブ無線オーディオデバイス用の無線ネットワーク上で、有線および無線通信手段を有するマスターデバイスから複数のオーディオデバイスを制御するステップと、
前記有線オーディオデバイスの各々から、マスターデバイスからのポーリングメッセージに対する応答を受信するステップと、
スレーブ無線オーディオデバイスから受信される全てのメッセージおよびポーリング情報によって適切な時間内に応答することによって、ローカルマスターとして動作するスレーブ無線オーディオデバイスのうちの１つからスレーブ無線オーディオデバイスの状態を示す総ポーリング情報をマスターデバイスにおいて受信するステップとを有していて、
前記ローカルマスターは、ポーリング応答を生成する全スレーブ無線オーディオデバイスを発見し、ローカルマスターによって予め決定されかつ確認されているように、予め設定されていた時間、マスターデバイスによる周期的なポーリングと同時に起こる以前のポーリング応答の全てをバッファリングし、マスターデバイスによる全スレーブ無線オーディオデバイスに対するポーリング要求の発行の直後に、バッファリングされた以前のポーリング応答を解放し、
前記ローカルマスターは、ポーリングの明示的なステップを実行し、全ポーリング応答情報を組み立てて、組み立てられたポーリング応答情報をマスターデバイスに送信する
ことを特徴とする方法。
【請求項２】
総ポーリング情報を供給するマスターとして動作するスレーブ無線オーディオデバイスのうちの１つは、所定のサイクルでオーディオデバイスをローカルにポーリングすることを特徴とする請求項１に記載の方法。
【請求項３】
少なくとも１つのマスターデバイスおよび複数のスレーブ無線オーディオデバイスを含むオーディオ通信ネットワークのための方法において、
ヘッダフィールド、アドレスフィールド、引数フィールド、およびベリファイヤフィールドを必須に含むメッセージを送信するステップを有していて、
前記メッセージの引数フィールドは、メッセージがポーリングメッセージである場合には、いかなるバイトも含まず、アドレスフィールドの４つの最上位ビットは、再生するオーディオデバイスのためのオーディオゾーンを識別し、アドレスフィールドの４つの最下位ビットは、ポーリングされているオーディオデバイスを識別する
ことを特徴とする請求項１に記載の方法。
【請求項４】
少なくとも１つのマスターデバイスおよび複数のスレーブ無線オーディオデバイスを含むオーディオ通信ネットワークのための方法において、
ヘッダフィールド、アドレスフィールド、引数フィールド、およびベリファイヤフィールドを必須に含むメッセージを受信するステップを有していて、
前記メッセージの引数フィールドは、メッセージがポーリングメッセージである場合には、いかなるバイトも含まず、アドレスフィールドの４つの最上位ビットは、再生するオーディオデバイスのためのオーディオゾーンを識別し、アドレスフィールドの４つの最下位ビットは、ポーリングされているオーディオデバイスを識別する
ことを特徴とする請求項１に記載の方法。
【請求項５】
少なくとも１つのマスターデバイスおよび複数のスレーブ無線オーディオデバイスを含むオーディオ通信ネットワークのための方法において、
ヘッダフィールド、アドレスフィールド、引数フィールド、およびベリファイヤフィールドを必須に含むメッセージを組み立てるステップを有していて、
前記メッセージの引数フィールドは、メッセージがポーリングメッセージである場合には、いかなるバイトも含まず、アドレスフィールドの４つの最上位ビットは、再生するオーディオデバイスのためのオーディオゾーンを識別し、アドレスフィールドの４つの最下位ビットは、ポーリングされているオーディオデバイスを識別する
ことを特徴とする請求項１に記載の方法。
【請求項６】
前記メッセージを送信するステップを更に有していることを特徴とする請求項５に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の説明は、オーディオネットワークを管理することに関係する。
【背景技術】
【０００２】
家族の何人かが、さまざまな部屋で異なるオーディオを選択して聴くことができ、しかもそれぞれの部屋に追加音源を用意する必要はない。中心となる部屋に置かれているマスターデバイスに接続されているCDチェンジャまたはデジタル音楽プレーヤーなどの中央集中音源は、マスターデバイスと通信する他の部屋にあるスレーブデバイスからアクセスされ、制御されることができる。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
一般に、一態様では、本発明は、少なくとも1つのマスターデバイスおよび複数のスレーブデバイスを含むマルチゾーンオーディオ通信ネットワークの方法を特徴とする。この方法は、コマンドを含むメッセージをデバイス上のリモートコントロールまたはコントロールボタンからマスターデバイスで受信することおよびコマンドを1つまたは複数のスレーブデバイスに送信することを含む。
【課題を解決するための手段】
【０００４】
実際の例では、以下の特徴のうちの1つまたは複数を含むことができる。メッセージは、送信されスレーブデバイスを制御するために使用される前にマスターデバイスで処理される。コマンドは、マスターデバイスを通じて、マスターデバイスで処理されることなく1つまたは複数のスレーブデバイスに渡される。リモートコントロールは、マスターデバイスとスレーブデバイスの両方を制御する。コマンドは、マスターデバイスとスレーブデバイスとの間の第1の通信チャネル上で送信される。オーディオストリームは、第1の通信チャネル上でコマンドと多重化される。オーディオストリームは、マスターデバイスとスレーブデバイスとの間の第2の通信チャネル上で送信される。第1の通信チャネルは、無線チャネルを含む。スレーブは、リモートコントロールを介して複数のゾーンに動的に構成される。スレーブデバイスは、さらに、ローカルの音源に接続され、スレーブデバイスは再生のためローカルの音源とオーディオストリームとから選択する。
【０００５】
一般に、他の態様では、本発明は、マスターデバイス、および1つまたは複数のスレーブデバイスを備えるマルチゾーンオーディオネットワーク制御システムを特徴とし、マスターデバイスは、コマンドを含むメッセージをデバイス上のリモートコントロールまたはコントロールボタンから受信し、そのコマンドをスレーブデバイスに送信する回路を備える。
【０００６】
一般に、他の態様では、本発明は、少なくとも1つのマスターデバイスおよび複数のスレーブデバイスを含むオーディオ通信ネットワークの方法を特徴とし、この方法は、複数の優先度をメッセージに割り当て、マスターデバイスからスレーブデバイスに最高優先度の保留メッセージを送信することを含む、通信プロトコルを使用してマスターデバイスから1つまたは複数のスレーブデバイスを制御することを含む。
【０００７】
一般に、他の態様では、本発明は、少なくとも1つのマスターデバイスおよび複数のスレーブデバイスを含むオーディオ通信ネットワークの方法を特徴とし、この方法は、複数の優先度をメッセージに割り当て、マスターデバイスからのポーリングメッセージに対する応答としてスレーブデバイスからマスターデバイスに最高優先度の保留メッセージを送信することを含む、通信プロトコルを使用してマスターデバイスから1つまたは複数のスレーブデバイスを制御することを含む。
【０００８】
実際の例では、以下の特徴のうちの1つまたは複数を含むことができる。最高優先度の保留メッセージは、スレーブデバイスを制御するための情報を含む。
【０００９】
一般に、他の態様では、本発明は、少なくとも1つのマスターデバイスおよび複数のスレーブデバイスを含むオーディオ通信ネットワークの方法を特徴とし、この方法は、マスターデバイスから複数のオーディオデバイスを制御し、第1のサイクルでオフ状態にあるオーディオデバイスの第1の集合および第2のサイクルでオン状態にあるオーディオデバイスの第2の集合をポーリングすることを含み、第2のサイクルは第1のサイクルよりも短い。
【００１０】
実際の例では、以下の特徴のうちの1つまたは複数を含むことができる。オーディオデバイスの第2の集合のすべてのメンバがポーリングされ、その後、オーディオデバイスの第1の集合の単一メンバがポーリングされ、というように、このステップは、循環ラウンドロビン方式で繰り返される。
【００１１】
一般に、他の態様では、本発明は、オーディオデバイスがオン状態にある場合にオーディオデバイスに関連付けられているゾーンに基づいて音源から再生するためにマスターデバイスから複数のオーディオデバイスのうちの1つを制御することを含む方法を特徴とする。
【００１２】
一般に、他の態様では、本発明は、オーディオデバイスがローカル状態にある場合にマスターデバイスで処理せずにマスターデバイスを通じてオーディオデバイスに対しすべてのコマンドを渡すことを含むマスターデバイスから複数のオーディオデバイスのうちの1つを制御することを含む方法を特徴とする。
【００１３】
一般に、他の態様では、本発明は、オーディオデバイスが非応答状態にある場合にオーディオデバイスのリモートコントロールからキー押下を監視することを含む、マスターデバイスから複数のオーディオデバイスのうちの1つを制御することを含む方法を特徴とする。
【００１４】
一般に、他の態様では、本発明は、オーディオ通信システムのメッセージ同期処理のための方法を特徴とし、この方法は、複数のメッセージを送信することを含む、マスターデバイスから複数のオーディオデバイスを制御することを含み、それぞれのメッセージは、連続バーストとして送信され、第1のメッセージの終わりから第2のメッセージの始まりまでの間の所定の最短時間遅延が保持される。
【００１５】
一般に、他の態様では、本発明は、オーディオ通信システムのための方法を特徴とし、この方法は、1つまたは複数の有線オーディオデバイス用の有線ネットワーク上で、および1つまたは複数の無線デバイス用の無線ネットワーク上でマスターデバイスから複数のオーディオデバイスを制御することを含む。
【００１６】
実際の例では、以下の特徴のうちの1つまたは複数を含むことができる。有線オーディオデバイスのそれぞれからポーリングメッセージに対する応答が受信され、無線デバイスのうちの1つから無線デバイスの状態を示す総ポーリング情報が受信される。総ポーリング情報を供給する無線デバイスのうちの1つは、所定のサイクルにより無線デバイスをローカルでポーリングする。総ポーリング情報は、所定の時間間隔で無線デバイスのうちの1つにより送信される。
【００１７】
一般に、他の態様では、本発明は、オーディオ通信システムのための方法を特徴とし、この方法は、ネットワーク上で複数のオーディオストリームを送信すること、および複数のオーディオストリームのうちのそれぞれ1つを再生するためネットワーク上の1つまたは複数のオーディオデバイスを制御することを含む。
【００１８】
実際の例では、以下の特徴のうちの1つまたは複数を含むことができる。オーディオデバイスのうちの1つは、ネットワーク上のマスターデバイスからのメッセージに基づいて複数のオーディオストリームのうちの第2のストリームを再生することに切り替わるように制御される。メッセージは、オーディオストリームを指定する情報を含む。
【００１９】
一般に、他の態様では、本発明は、少なくとも1つのマスターデバイスおよび複数のスレーブデバイスを含むオーディオ通信ネットワークの方法を特徴とし、この方法は、ネットワーク接続されている音源およびオーディオデバイスに接続されているローカル音源を含む、音源からオーディオデバイスにオーディオストリームを送信し、オーディオデバイス上の音源に関する情報を表示することを含む。
【００２０】
一般に、他の態様では、本発明は、少なくとも1つのマスターデバイスおよび複数のスレーブデバイスを含むオーディオ通信ネットワークの方法を特徴とし、この方法は、本質的にヘッダフィールド、アドレスフィールド、引数フィールド、およびベリファイヤフィールドからなるメッセージを送信することを含む。
【００２１】
実際の例では、以下の特徴のうちの1つまたは複数を含むことができる。メッセージの引数フィールドは、メッセージがポーリングメッセージである場合にはバイトを含まず、アドレスフィールドの最上位ビットは、再生するオーディオデバイスのオーディオゾーンを識別し、アドレスフィールドの最下位ビットは、ポーリングされているオーディオデバイスを識別する。
【００２２】
一般に、他の態様では、本発明は、少なくとも1つのマスターデバイスおよび複数のスレーブデバイスを含むオーディオ通信ネットワークの方法を特徴とし、この方法は、本質的にヘッダフィールド、アドレスフィールド、引数フィールド、およびベリファイヤフィールドからなるメッセージを受信することを含む。
【００２３】
一般に、他の態様では、本発明は、少なくとも1つのマスターデバイスおよび複数のスレーブデバイスを含むオーディオ通信ネットワークの方法を特徴とし、この方法は、本質的にヘッダフィールド、アドレスフィールド、引数フィールド、およびベリファイヤフィールドからなるメッセージを組み立てることを含む。
【００２４】
実際の例では、以下の特徴のうちの1つまたは複数を含むことができる。メッセージが送信される。
【００２５】
一般に、他の態様では、本発明は、少なくとも1つのマスターデバイスおよび複数のスレーブデバイスを含むオーディオ通信ネットワーク用のオーディオ通信プロトコルを特徴とし、このプロトコルは、本質的にヘッダフィールド、アドレスフィールド、引数フィールド、およびベリファイヤフィールドからなるメッセージ形式を含む。いくつかの実装では、メッセージの引数フィールドは、メッセージがポーリングメッセージである場合にはバイトを含まず、アドレスフィールドの最上位ビットは、再生するオーディオデバイスのオーディオゾーンを識別し、アドレスフィールドの最下位ビットは、ポーリングされているオーディオデバイスを識別する。
【００２６】
本発明の利点としてとりわけ、以下のうちの1つまたは複数がある。オーディオネットワーク制御システムは、交換可能なスレーブデバイス(例えば、オーディオ再生またはオーディオ情報表示デバイス)で動作することができる。このため、マスターデバイスとスレーブデバイスとを混ぜてマッチングさせることにより、複数の統一小売価格を組み立てられる。スレーブデバイスは、共通通信プロトコルを使用することができる。マスターデバイスは、スレーブデバイスの特徴またはユーザインターフェイスの仕様を知る必要がない。共通通信プロトコルを使用することに加えて、スレーブデバイスには、共通の一連の動作がありえる。例えば、すべてのスレーブデバイスは、同じようにミュート、ミュート解除、音量調整コマンドに応答することができる。それとは別に、いくつかのスレーブデバイス(例えば、無線デバイス)は、共通通信プロトコル(例えば、メッセージ形式)のいくつかの共通の態様を共有できるが、他の態様(ポーリング手順)では異なる場合がある。
【００２７】
さらに、オーディオネットワーク制御システムを使用することで、ユーザは、複数の部屋にわたって、また複数のリモコンを使用しても、継ぎ目のない運用を行える。システムは、リモートルームでも、メインルームとほぼ同じように動作することができる。スレーブデバイスは、マスターデバイスのリモコンでも、ネイティブリモコンとほぼ同じように機能することができる。この継ぎ目のない動作を実現するために、マスターデバイスは、リモートコントロールから受信したコマンド(例えば、無線周周波数(RF)または赤外線(IR)リモコン)を適切なスレーブデバイスにディスパッチすることができる。新しい機能を持つ将来のスレーブデバイスとの相互運用性を確実なものとするため、マスターデバイスは、不明なコマンドをスレーブデバイスへ通り抜けさせることができる。マスターデバイスは、そのコマンドがどのようなものであるかを知る必要はない。この点で、マスターデバイスは、ルータとして機能し、コマンドの発信元と送信先を判別する。場合によっては(例えば、音源変更コマンド)、コマンドはマスターデバイスのコマンドプロセッサに送られる。他の場合には(例えば、不明なコマンド)、コマンドは、スレーブデバイスに直接経路指定される。この決定は、スレーブデバイスの状態および受信したコマンドに基づく。このようにして、新しいタイプのスレーブデバイスに拡張可能なシステムを作成することが可能である。
【００２８】
いくつかのスレーブデバイスは、それ自体、システムとすることもでき、他の接続されたデバイスに対する制御統合を含むことができる。そのような制御自動化は、通常、スレーブデバイスのネイティブリモートコントロールを通じてアクセスされる。その制御自動化は、上記の経路指定メカニズムを介してサポートすることができるマスターデバイスのリモートコントロールからアクセス可能である。スレーブデバイス側で制御統合に対応するために、マスターデバイスによる追加処理は必要ない。
【００２９】
通信プロトコルは、スレーブスピーカ上のローカルボタンでマスターコンソールを制御できるようにする優先順位付けされたメッセージを含む。スレーブデバイスは、ステータスなどあらゆる種類のメッセージをコンソールに送り返すことができるが、最高優先度のメッセージは、例えばスレーブスピーカ上のローカルボタンが押されたときの「制御」コマンドである。制御コマンドは、マスターコンソールを制御するために使用される。
本発明の他の特徴および利点は、以下の詳細な説明および請求項から明白になるであろう。
【図面の簡単な説明】
【００３０】
【図１Ａ】部屋が複数ある環境におけるオーディオネットワーク制御システムの図である。
【図１Ｂ】オーディオネットワークの通信プロトコルをグラフィックで表した図である。
【図２】マスターおよびスレーブデバイスのハードウェアインターフェイスの図である。
【図３】送信機の回路図である。
【図４】パルスタイミング図である。
【図５Ａ】受信機の回路図である。
【図５Ｂ】受信機の回路図である。
【図６】ピン配置の図である。
【図７】ピン配置接続図である。
【図８】ピン配置接続図である。
【図９】通信プロトコルのタイミング図である。
【図１０】通信プロトコルのタイミング図である。
【図１１】データフィールドのビット列の図である。
【図１２】データフィールドのビット列の図である。
【図１３】データフィールドのビット列の図である。
【図１４】データフィールドのビット列の図である。
【図１５】データフィールドのビット列の図である。
【発明を実施するための形態】
【００３１】
１．概要
図1Aは、部屋が複数ある環境におけるオーディオデバイスのネットワークを含むオーディオネットワーク制御システム100を示している。システム100は、第1の部屋120にマスターデバイス110およびスレーブデバイス112Aを、第2の部屋122にスレーブデバイス112Bおよび112C、および第3の部屋124にスレーブデバイス112D〜112Fを備える。マスターデバイス110は、例えば、コンピュータの通信機能(例として、デスクトップ、ラップトップ、またはハンドヘルドコンピュータ)を利用するスタンドアロンのコントロールコンソールまたは制御プログラムを備える。スレーブデバイス112A〜112Dは、スピーカ、オーディオ再生および/または記録機能を備える電子デバイス、またはオーディオストリームに関する情報を収集し、および/または表示するデバイスを含む、さまざまなデバイスのどれかを備えることができる。スレーブデバイスは、図1Bに概略が示されているように、マスターデバイスインターフェイスおよびスレーブデバイスインターフェイスを含む通信プロトコル140により通信チャネル(例えば、有線バスまたは無線チャネル)を介してマスターデバイス110と通信する。
【００３２】
ユーザは、マスターまたはスレーブデバイス上のローカルコントロールボタンを介して、または1つまたは複数のリモートコントロール、例えば、マスターデバイス用のリモートコントロール130またはスレーブデバイス用のリモートコントロール132を使用することにより、直接デバイスのどれかを制御することができる。IRリモートコントロールは、対応するデバイスに配置されているコントロールに類似するコントロールを備えることができる。IRリモートコントロールからのコマンドは、IRリモートコントロールと同じ部屋に置かれているデバイスに伝播することができる。IRリモートコントロールからのコマンドにより、ローカルデバイスは、受信コマンド(例えば、スイッチオン/オフ、ステーション変更、音量調整など)に対する応答として何らかの方法で状態を変更することができる。
【００３３】
いくつかの実際の例では、1つのリモートコントロール、例えばマスターリモートコントロール130は、マスターデバイス110およびスレーブデバイス112A〜112Dの両方を制御することができる。例えば、RFリモートコントロールは、マスターデバイス、1つまたは複数のスレーブデバイス、またはマスターおよびスレーブの両方のデバイスのいずれかを制御することができる。いくつかの実装では、RFリモートコントロールは、スレーブデバイスを直接制御しない。その代わりに、RFリモートコントロールから発行されたコマンドは、まず最初に、マスターデバイスに送信され、その後、マスターがコマンドに基づいて動作するか、またはスレーブデバイスに渡して動作させることができる。
【００３４】
スレーブデバイスが直接制御されるか、または単一のRFリモートコントロールを通じて制御できるという事実を調整するために、ポーリングを使用して、スレーブデバイスに関するステータス情報を収集する。スレーブデバイスまたはIRリモートコントロール上のコントロールを使用して、スレーブデバイスの状態を変更する場合、ポーリングプロセスでは、変更された状態に関する情報を取得し、それをマスターデバイスに供給し、マスターデバイスがスレーブの状態(またはいくつかの実装では、オン/オフステータス、音量レベル、またはミュートステータスなどの状態の少なくとも部分集合)を認識するようにする。物理的インターフェイスを通じて、またはIRリモートコントロールを介してデバイスに直接発行されるコマンドは、RFリモートコントロール(または、マスターデバイスと同じ部屋にあるリモートコントロール)を介して発行されるコマンドと異なる形で処理することができる。マスターデバイスと同じ部屋にあるIRリモートコントロールは、マスターデバイスを通じてコマンドを発行することができ、したがって、マスターと異なる部屋に配置されているRFリモートコントロールと同じ動作をすることができる。
【００３５】
リモートコントロールは、双方向リモートコントロールを含むことができる。例えば、コマンドはリモートコントロールからマスターデバイスに発行され、データはマスターデバイスからリモートコントロールに送り返され、ユーザに表示される。送り返されるデータは、ネットワークに接続されたさまざまなデバイスの状態のステータスとすることができるか、またはユーザに対して演じられるデジタル作品を含むハードドライブ上に格納されているデータなど、マスターデバイスのさまざまな機能に関連付けられているデータとすることができる。
【００３６】
いくつかの実際の例では、スレーブデバイス112A〜112Dは、さらに、互いに通信する。いくつかの実際の例では、オーディオネットワーク制御システム100は、複数のマスターデバイスを備える。
【００３７】
オーディオネットワーク制御システム100は、複数の「ゾーン」に分けることができる。それぞれのデバイスは、アドレスにより識別され、それぞれの部屋は、部屋コードにより識別され、それぞれのゾーンは、ゾーンコードにより識別される。例えば、Zone1は、第1および第2の部屋(RoomAおよびRoomB)内にデバイスを備え、Zone2は、第3の部屋(RoomC)内にデバイスを備えることができる。
【００３８】
通常動作では、マスターデバイスは、接続されているすべてのスレーブデバイスを連続してポーリングし、それらがネットワーク上にあり、オンになっているかを判別する。例えば、実際の一例では、スレーブデバイスに対しては、「On」、「Off」、「Local」、または「Not Responding」の4つの状態がありえる。ほかに、スレーブデバイスに対する状態が4つよりも少ない実例も、多い実例もありえる。マスターデバイスのコマンド処理は、次のようにしてスレーブデバイスの状態に応じて進行する。
【００３９】
すべての状態において、マスターデバイス110は、以下で詳述するように、音量およびミュートコマンドをマスターリモート130から通信プロトコル140に従って一致する部屋コードを持つスレーブデバイスに経路指定する。ポーリングした結果、スレーブデバイスが「オン」になっていることをマスターデバイスが検出すると、マスターデバイス110は、適切なゾーンをアクティブ化し、最後に選択された音源の再生を開始する。ゾーンがすでに再生している場合、スレーブデバイスはそのゾーンに対する現在の音源を結合する。与えられたゾーンに接続されているすべてのスレーブデバイスが「オフ」または「ローカル」のいずれかであるとマスターデバイス110が判別した場合、これは、そのゾーンの電源を切る。
【００４０】
スレーブデバイスが「オン」状態の場合、マスターデバイスに知られている制御コマンドは、マスターデバイス固有の方法により処理される。マスターデバイス110によって認識できない新しい特徴を備えるスレーブデバイスなどの不明なコマンドが適切なスレーブデバイスに渡される。これにより、マスターデバイス110は、追加された新しいコマンドを含むことができるスレーブデバイスの新しいクラスに拡張することができる。
【００４１】
スレーブデバイスが「Local」状態にある場合、トランスポートコマンドを含むすべてのコマンドが、マスターデバイス110を通じて適切なスレーブデバイスに渡される。トランスポートコマンドは、マスターデバイス110によりローカルで処理されない。このため、すべてのマスターデバイス110内部トランスポートとともにリモートデバイスのローカルトランスポートでも完全にコンテキスト依存のトランスポートコマンドが使用可能である。
【００４２】
スレーブデバイスが「Off」状態にある場合、トランスポートコマンドを含むすべてのコマンドが、マスターデバイス110を通じて適切なスレーブデバイスに渡される。これにより、ローカル音源選択コマンドまたはOn/Offコマンドを送信することによりスレーブデバイスの電源を入れることができる。「On/Off」コマンドの場合、スレーブデバイスは前に選択された音源で電源オンになる。音源がマスターデバイス110であった場合、状態は「On」に設定され、これは、次のポーリングサイクルで捕捉される。この方式は、それぞれのスレーブデバイスが各自の動作を管理するという点で非常に拡張性が高く、マスターデバイス110は、それぞれのスレーブデバイスに関して最小限度のことのみを知っているだけでよい。
【００４３】
スレーブデバイスが「Not Responding」状態にある場合(例えば、サードパーティ製のアンプの場合のように)、トランスポートコマンドを含むすべてのコマンドは、上述の「Off」状態の場合と同様に、マスターデバイス110を通じて適切なスレーブデバイスに渡される。しかし、マスターデバイス110は、リモートからオン/オフおよび音源選択キー押下を追跡することによりそれらのスレーブデバイスに対するオン/オフ状態変数を管理する。このため、マスターデバイス110はゾーンをいつ適切にシャットダウンするか(例えば、それを使用している部屋がいつオフになるか)を知ることになる。スレーブデバイスの電源がオンになり、ネットワーク上での応答を開始した場合、その応答に含まれるオン/オフ状態情報は高い優先度を与えられ、その部屋に対するマスターデバイス110オン/オフ状態変数を更新するために使用される。
【００４４】
２．通信プロトコル
通信プロトコル140により、マスターデバイスは、それぞれ一意的なアドレス(高々1つのスレーブデバイスが与えられたアドレスを使用することができる)を持つ所定の数(例えば、一実施例では15)のネットワーク接続スレーブデバイスをサポートすることができる。これらのアドレスは、例えば、RoomA、RoomB、RoomCなどで、最大RoomO(15個のスレーブデバイスの場合)である。16番目のアドレス(実際には、RoomP)は、ブロードキャストメッセージ用に予約されている(すべてのスレーブデバイス向けである)。これら15個のスレーブデバイスは、リモートコントロールコマンドに対する応答として、与えられた任意の時点に、Zone1、Zone2、または追加ゾーンオーディオストリームのどれかを再生することができる(またはどれも再生しない)。したがって、通信プロトコル140に対して、部屋コードだけで、特定のスレーブデバイスを識別することができ、スレーブデバイスに送信されるゾーン情報は、単に、再生されることが意図されているオーディオストリームをスレーブデバイスに知らせるだけである。
【００４５】
通信プロトコル140は、「プラグ&プレイ」機能を持つ。ネットワークまたは他のスレーブデバイスの電源を切らずに、またマスターデバイス110の電源を切らずに、新しいスレーブデバイスをいつでもネットワークに追加することができる。
【００４６】
1つのスレーブデバイスアドレス(例えば、RoomO)を共有アドレスとして使用し、マスターデバイス110上のZone2可変オーディオ出力に割り当てることができる。このアドレスに設定されたRFリモートコントロールからのVolume Up/Downコマンドが、スレーブデバイスのメッセージを起動し、このZone2可変オーディオ出力に給電する内部音量調節チップを制御する。
【００４７】
３．マスターデバイス回路
３．１  概要
スタンドアロンコンソール200マスターデバイスの実際の一例が図2に示されている。コンソール200のハードウェアインターフェイスは、制御データバス202、およびオーディオインターフェイス204、および+10VのTurn On信号206を含む。制御データバス202は、コンソール200からネットワーク接続スレーブデバイス208に接続されることを意図されている2線式(DataおよびGND)双方向半二重インターフェイスである。すべてのデータおよび制御メッセージは、このバス200経由で送信される。メッセージ送受信は、19.2kbpsに固定されており、以下に定義されたパケット化およびタイミング規則に従う。
【００４８】
最大150フィートのネットワーク長(コンソール200からスタブ上の最も遠いスレーブデバイスまで)をサポートすることができ、ケーブル配線は、ディジーチェーンまたはスター型構成(またはそれらの組み合わせ)に従う。電気的には、ネットワーク接続スレーブデバイスは並列に配線される。
【００４９】
Data信号は、1kΩのプルアップ抵抗を通してコンソール側の+5Vに入り、メッセージが送信されていない場合には+5V(通常はHIGHレベル)でアイドル状態となる。ネットワーク接続スレーブデバイスは、オプションにより、ローカルの+5V音源への1MΩのプルアップ抵抗を含み、これにより、コンソールから切断されたときにData信号を知られている状態へバイアスすることができる。いくつかの実際の例では、信号伝達(コンソール200とともにネットワーク接続スレーブデバイスからの)は、Data信号をローカルのGNDに引き込むオープンコレクタトランジスタを通じて実現される。
【００５０】
３．２  送信機の詳細
本例では、それぞれのスレーブデバイスはバス202とインターフェイスし、+5Vを許容でき、また最悪時のプルアップ抵抗(約650Ω、15個のスレーブデバイスの効果を考慮して)で完全プルダウン(飽和を保証)することができるオープンコレクタトランジスタを通して信号を送る。バス202は家庭内に張り巡らされ、また過去の著しい電気的雑音源となりうるため、フィルタ/保護コンポーネントも用意すべきである(バス上で最大100pF)。バス送信機の出力セクション例が図3に示されている。他の送信機トポロジも可能である。送信機の電気的パラメータは以下のとおりである。
【００５１】
【表１】
0005383775.tif 000002
【００５２】
スピーカケーブルの長さが120フィートだと、ネットワークに約.01μFの余分な容量を負荷としてかけることになる。したがって、図4に示されている波形は、最悪の場合の数のスピーカによりロードされた最大長のネットワークの上へのスレーブデバイスにより駆動されるスタートビットに対する最悪の場合の駆動波形を表す。バス容量によるビットの拡張に注意されたい。ビット立ち下がり時間は、立ち上がり時間よりも約10倍高速であろう。この実施例に対するパラメータを以下に示す。
【００５３】
【表２】
0005383775.tif 000003
【００５４】
３．３  受信機の詳細
バス受信機は、ネットワーク上で立ち下がり遷移を検出し、それらをマイクロプロセッサに中継する。受信機回路は、スレーブデバイスに対しては立ち下がり受信しきい値を約2.6Vに設定し、コンソール200に対しては3Vに設定する。この実施例では、ヒステリシスは与えられない。したがって、いくつかの多重遷移が、ノイジービットのエッジで発生しうる。スレーブデバイスでは、その受信アルゴリズムがそれらの遷移を許容できない場合、ヒステリシスを加えるであろう。例えば、標準的なUART(Universal Asynchronous Receiver/Transmitter)デバイスおよびビットセルの中心付近でビットをサンプリングするその他の方式では、多重遷移を許容する。ネットワークのHIGH/LOW時間を測定するためにエッジトリガ割り込みを使用してデータを復号化する受信方式では、リアーミングの前に割り込みサービスルーチンに十分な遅延が存在していない限り、ヒステリシスを必要とする可能性がある。理想的には、使用する回路に関係なく、ソフトウェアで擬似ヒステリシスを実施するデバウンス方式を実施すべきである。
【００５５】
バス受信機は、さらに、ネットワーク過渡電流に耐えなければならない。したがって、受信機回路は、図3に示されているように、送信機出力段の保護ノードからタップオフされる。このトポロジでは、ネットワークスレーブデバイスにより送信されるすべてのデータは、それ自体の受信機内にフィードバックされる。ソフトウェアは、これに耐えられるよう十分に堅牢でなければならない。+5Vおよび+3.3Vバス受信機回路例は、それぞれ、図5Aおよび5Bに示されている。送信機の電気的パラメータは以下のとおりである。
【００５６】
【表３】
0005383775.tif 000004
【００５７】
３．４  +10V Turn-On線
コンソール200は、+10V Turn-On信号206を供給する。この信号は、与えられたZone上でアクティブなスレーブデバイスがない場合にLOWレベル(GNDに2.2Kプルダウン)であり、あればHIGHレベル(限流HIGH側PNPスイッチ、負荷に応じて+8.8Vから+10Vを供給)である。最大駆動能力は、+8.8Vで約75mAである。したがって、スレーブデバイスがこの線を他の目的(Energy Starなど)に使用する場合、スレーブデバイス1つ当たり引き込む電流が5mAを超えないよう注意しなければならない(5mA=75mA/スレーブデバイス15個)。このような電流引き込みは、さらに、コンソールのワット損を減らすために、単に一時的なものでなければならない。
【００５８】
３．５  オーディオインターフェイスの詳細
スレーブデバイスインターフェイスは、オーディオインターフェイス204とともに、本明細書で説明されている制御データバス202を含む。ネットワーク接続スレーブデバイスに対するオーディオ信号出力の一種に固定出力がある(例えば、常に、全量が送信される)。音量調節は、スレーブデバイス内で実施される。このため、スレーブデバイスで信号対雑音比が最大になる。可変出力も備えられ、例えば、従来のスレーブデバイスをサポートする。1つまたは複数の信号出力は、アナログ出力、デジタル出力、またはアナログ出力とデジタル出力の組み合わせとすることができる。オーディオ信号の分配は、通信プロトコル140に従ってマスターデバイス110と通信する機能を持つ「スマート」スピーカを含む「スマートスピーカシステム」である、スレーブデバイスのネットワークに関して以下で説明される。
【００５９】
「メインルーム」スマートスピーカシステムでは、コンソール200は、以下で詳しく説明するように、Zone1 Speaker Output mini-DIN、ピン1および2上でS/PDIFベースの差動デジタルオーディオストリームを供給する。このオーディオストリームは、スピーカによる負荷がかかったときに、(非標準)3Vpp出力レベルに対し構成されており、トランスで絶縁され、平衡している。放射を低減するためグラウンドへの390pFのフィルタキャパシタが追加される。
【００６０】
コンソール200は、さまざまなデータ転送速度(フレーム/秒(FPS))で、例えば、48kFPSから最大192kFPSまでの速さでオーディオストリームを生成することができる。コンソール200は、さまざまな圧縮形式のうちのどれか、例えば、PCM、AC-3、DTS、MPEG2、またはAACでデジタルオーディオを生成することができる。圧縮形式は、スピーカにより識別され復号化される。
【００６１】
家中の「非メインルーム」スマートスピーカシステムでは、アナログ出力ステレオのペア(Zone1に対する左/右およびZone2に対する左/右)は、以下で詳述するように、Zone2 Speaker Output mini-DINコネクタ上に備えられる。これらの左/右ペアは両方とも固定出力である。フルスケール(最大)の出力信号は約2Vrmsで、標準的な再生レベルは約300〜400Vrmsとなる。コンソールの内部および外部音源に対する再生レベルは、コンソール内でゲインスケーリングされており、等しい振幅で再生される。
【００６２】
これらの出力は、約50Ωの直列抵抗がそれぞれの出力に追加された、OPアンプにより本質的に駆動される、標準のシングルエンドアナログ出力である。47μFのDC阻止キャパシタが、コンソール内のそれぞれの出力信号に追加され、その後に100K抵抗器がつながりコンソールのアナロググラウンドをそれぞれ基準とする。この出力インピーダンスは、最大15個までのスピーカ(入力段は以下で定義される)を駆動することができ、しかも、低周波応答の不要な減衰または損失が発生しないことが予想される。以下では、適切なゾーン/ゾーン絶縁および雑音遮蔽を保証するためのケーブル配線ガイドラインを示す。
【００６３】
Zone2 Speaker Outputコネクタピン1および2は、さらに、可変入力スピーカ用の左/右可変アナログ信号ペアも備える。これらの信号は、ピン3および4のZone2固定出力と同一であるが、コンソール200の内側のZone2音量調節チップにより減衰することができる。
【００６４】
家中に長いオーディオケーブルを引き回すと、耳に聞こえるほどの雑音を拾いやすいことが判明している。したがって、制御データバス202にインターフェイスするスピーカでは、オーディオ入力段に差動アンプ(「diffアンプ」)を構成すべきである。これらの差動アンプ入力の基準として、専用Audio Referenceがコンソール200から送られ、他のネットワーク導線とともに含まれる。ケーブル配線の詳細を以下で説明する。いくつかの実際の例では、ネットワーク接続スピーカのオーディオインターフェイスの特徴として、以下のものがある。
【００６５】
・  Zone1およびZone2入力diffアンプ回路は、同じでなければならない(同じゲイン、雑音レベル、および帯域幅、スピーカの音質目標に合致している)。
【００６６】
・  Diffアンプは、すべての脚が等しく平衡している状態で使用すべきである。
【００６７】
・  ネットワークからそれぞれの脚を見たときの抵抗は、20KΩ以上でなければならない。これにより、例えば、Diffアンプは10KΩの抵抗器をそれぞれの脚に付けて構成されるようにできる。
【００６８】
・  それぞれの脚はネットワークにキャパシタを介して接続されるべきであり、キャパシタはすべて等しい値を持つ。それぞれのネットワーク接続スレーブデバイスは、所望の周波数応答に基づいてそれ固有のキャパシタ値を持つことができる。
【００６９】
・  専用Audio Reference信号を、Diffアンプ、Zone1 Left/RightとともにZone2 Left/Rightに対し使用しなければならない。オーディオ電流がこの信号に還流し、Zone1/Zone2絶縁を破壊するのを避けるために、Audio ReferenceをDiffアンプのみのNON-INVERTING脚に対し使用しなければならない。1マイクロアンペアrms以下のオーディオ電流が、Audio Reference信号上に誘起されなければならない。これは92dBの絶縁(許容可能な最低値とみなされる)を維持する。
【００７０】
コンソール200とインターフェイスするように開発されたスマートスピーカは、2つの可能なオーディオストリーム、Zone1ストリームまたはZone2ストリームのうちの1つを選択することができる。選択は、スマートスピーカコマンドを介して制御される。したがって、スマートスピーカは、スマートスピーカメッセージを管理するマイクロプロセッサの制御の下で、そのネットワークオーディオ入力に2入力、ステレオオーディオマルチプレクサ(MUX)を備えるべきである。このMUXをDiffアンプの前に構成する作業は、コスト低減につながるが、パフォーマンスの低下または上記特徴のうちのいくつかを除去することのないように慎重に行わなければならない。
【００７１】
３．６  コンソールスピーカ出力のMini-DINコネクタ
コンソール200は、2つの9ピンSpeaker Output mini-DINコネクタを、Zone1に1つ、Zone2に1つ、備える。図6は、9ピンmini-DINコネクタを見た場合のピン配置例を示している(差し込んだ場合のように)。コネクタは、導電性シェル600を備える。これらのコネクタに対するピン配置を以下に示す。
【００７２】
ZONE1:
ピン1:メインスピーカ用のS/PDIF0デジタルオーディオ信号(Z1_NET0)。
ピン2:メインスピーカ用のS/PDIF1デジタルオーディオ信号(Z1_NET1)。
ピン3:Zone1固定左アナログオーディオ信号(Z1_LEFT)。可変でない。
ピン4:Zone1固定右アナログオーディオ信号(Z1_RIGHT)。可変でない。
ピン5:GND。
ピン6:Zone1の+10V Turn On信号(Z1_TURNON)。
ピン7:Zone1のSmart Speaker Data(Z1SPKR_DATA)。
ピン8:GND。
ピン9:接続なし。
シェル:GND。
【００７３】
ZONE2:
ピン1:Zone2可変左アナログオーディオ信号(OUTLVAR)。
ピン2:Zone2可変右アナログオーディオ信号(OUTRVAR)。
ピン3:Zone2固定左アナログオーディオ信号(Z2_LEFT)。
ピン4:Zone2固定右アナログオーディオ信号(Z2_RIGHT)。
ピン5:Buffered Zone1固定右アナログオーディオ信号(BZ1_R)。
ピン6:Zone2の+10V Turn On信号(Z2_TURNON)。
ピン7:Zone2のSmart Speaker Data(Z2SPKR_DATA)。
ピン8:GND。
ピン9:Buffered Zone1固定左アナログオーディオ信号(BZ1_L)。
シェル:GND。
【００７４】
３．７  ネットワーク接続スピーカの入力mini-DINコネクタ
ネットワーク接続スマートスピーカも、同様に、バス202に接続するための9ピンmini-DINコネクタを備える。この一方のコネクタは、Zone1およびZone2のLeft/Rightオーディオとともに、Data線、デジタルグラウンド、およびオーディオDiffアンプの基準電圧として使用する別のグラウンドを取り込む。オプションにより、+10V Turn On信号も取り込める。全部で8本の導線にしかならないが、スピーカは、ケーブルを反転可能にできるように、コンソールのと同じ(ただし、デュアルではなくシングルのみ)9ピンmini-DINを使用するように定義される。
【００７５】
スピーカのmini-DINは、以下のピン配置となっている。
ピン1:未接続(コンソールのZone2可変左アナログオーディオ)。
ピン2:未接続(コンソールのZone2可変右アナログオーディオ)。
ピン3:Zone2固定左アナログオーディオ信号。
ピン4:Zone2固定右アナログオーディオ信号。
ピン5:Zone1固定右アナログオーディオ信号。
ピン6:Zone2の+10V Turn On信号。
ピン7:Zone2のSmart Speaker Data。
ピン8:Audio Reference(diffアンプの専用グラウンド)。スピーカの製品グラウンドに結線されない。
ピン9:Zone1固定左アナログオーディオ信号。
シェル:GND、スピーカのデジタル(製品)グラウンドとして使用される。スピーカ内のピン8 GNDに短絡しない。
【００７６】
３．８  ケーブル配線の詳細
いくつかの実際の例では、スマートスピーカをコンソール200のZone2 Speaker Outputに接続するためのケーブルは、図7に示されているような独立のシールドを使用する、ピン3から9までの1:1パススルーを持つ。ピン1および2は、接続されておらず、ケーブルは反転可能である。8線ケーブルを4つのシールド付きツイストペアケーブル(Bose Corporation社の部品番号257187)とともに使用してスピーカをコンソール200に接続する場合、図7に示されているように接続することができる。
【００７７】
いくつかの従来のスピーカ(AM5P/AM2OP、Bose Corporation)では、直接、Zone2 Speakerコネクタにプラグを差し込み、正常に動作させることができ、新しいスピーカ(LSA2、A2、およびBallpark、Bose Corporation)と共存できる。これらは、ピン1&2上でZone2 Variable Left/Right信号を使用するとともに、ピン6上で+10V Turn-On線を使用する。ピン8は、Turn-On線を遮蔽し、スピーカをグラウンドに接続するために使用される。シェル600のグラウンドは、このスピーカ内のAudio Referenceに使用される。これらのケーブルは、内部で、ピン5をシェルグラウンドに短絡し、Zone1 Fixed Right出力を新しいスピーカから使用できなくする-これらのスピーカが新しいスピーカとZone2を共有する必要がある場合に特殊なスプリッタを使用してこれを防止する(コンソールシェルをスプリッタOutputのピン5に接続するが、この出力のシェルは浮動状態にしておく)。
【００７８】
従来のスピーカケーブルがコンソール200のZone2 Speaker Outputに差し込まれた場合、ピン5上のZone1 Fixed Rightオーディオ出力信号はグラウンドに短絡される。Fixed Rightオーディオ出力はバッファリングされるため、新しいスタイルのスピーカをサポートする必要がなければ、この信号をグラウンドに短絡するのが安全である。しかし、新しいスピーカを従来スピーカと併用する場合、特別なスプリッタを使用する必要がある。このスプリッタ内の接続は図8に示されているとおりである(コンソール側がオスであり、Speaker Output側がメスである)。
【００７９】
スプリッタの従来出力は以下の特徴を持つ。
1.ピン5をシェルに短絡する、出力に差し込まれるケーブルは、Z1 Fixed RightをGNDに短絡しない。
2.そのピン8グラウンドは、デジタルGNDに使用できる(Data信号、さらには+10V Turn-Onの場合)。
3.そのシェルグラウンドは、ピン5に短絡され、Left/Rightオーディオ遮蔽に使用することができる。
【００８０】
スプリッタのNew Speaker出力は、コンソールmini-DINからのピン3から9(およびシェル)のフルパススルーである。新しいスピーカは、決して、ピン1〜2のVariableオーディオ信号を使用せず、実際には、ピン1〜2をアクセサリ(例えば、ボールパークペデスタル)用のオーディオ出力として使用することができ、したがって、これらはスプリッタ内に含まれない。
【００８１】
４．通信プロトコルの詳細
通信プロトコル140は、コンソール200と1組のネットワーク接続スピーカとの間で1線(グラウンドを含めて2線)、双方向、半二重、信号伝達方式を使用する。
【００８２】
すべての通信は、コンソール20の背後にあるSpeaker Output mini-DINコネクタから引き回されるケーブル上のSpeaker Data線を介してネットワーク接続スピーカに送られる。この信号のアイドル状態は、コンソール内の1KΩ抵抗器を介してプルアップされた、論理HIGHレベル(+5V)である。送信は、コンソール200およびスピーカ内の直接キーイングオープンコレクタトランジスタ段により行われる。
【００８３】
プロトコル140では、19.2Kbpsビットレート、1スタートビット、1ストップビット、およびパリティビットなしの設定を使用する。メッセージバイトを以下で定義する。以下の例では、すべてのメッセージバイトは、LSB(最下位ビット)を先に送信する。
【００８４】
４．１  許容可能な論理レベル
信号伝達の論理レベルは以下のとおりである(バス202のSpeaker Data線に示されているとおり)。
【００８５】
【表４】
0005383775.tif 000005
【００８６】
４．２  ビット幅
すべてのネットワーク接続デバイスで使用する19.2kbpsのデータ転送速度は公称転送速度の0.5%内となるように保証される。これにより、必ず、各バイトのストップビットまでのエッジ精度は±5%となる(送信機と受信機の両方について最悪の場合のタイミング誤差を想定すると、±10%)。したがって、ビット幅は以下のように定義される。
【００８７】
【表５】
0005383775.tif 000006
【００８８】
これらの許容範囲は、バス送信機により生成されるとおりビット幅に適用される。実際の受信ビット幅は、最悪の場合のネットワーク上では歪むことがある。
【００８９】
４．３  メッセージタイミング
スピーカの同期をとるために、メッセージがパケット化され(バイト間の遅延なしで、1つの連続バーストとして送信される)、メッセージ間タイミングは以下のように制御される。
【００９０】
【表６】
0005383775.tif 000007
【００９１】
ネットワークから見た場合の共通4バイトコマンドおよび応答のメッセージ例が図9に示されている(バス202はHIGHレベルでアイドル状態)。
【００９２】
４．４  メッセージ同期
上の表に示されているように、コンソール200では、ネットワークが、新しい伝送を開始するまでに少なくとも1.066m秒の間アイドル状態になっていることを確実にする。この遅延は、意図的に、コンソールメッセージとスピーカ応答との間の許容可能な遅延よりも長くとってあり、ネットワーク上のデバイスは単純なタイムアウトを使用して、必要な場合に(理想的には、進行中に)コンソールとの再同期をとることができる。スピーカがコンソールとの再同期に使用する推奨タイムアウトは、916μ秒(916μ秒=767μ秒+(1.066m秒-767μ秒)/2.)である。スピーカ側で、ネットワークが916μ秒の間アイドル状態にあったと識別した場合、そのスピーカは、受信ルーチンをリアーミングすることができ、次のコンソールメッセージをその先頭から適切に捕捉する。
【００９３】
スピーカでは、安全に469μ秒を超える最初のネットワークアイドル時間の間待つことにより受信コンソールメッセージの終わりを識別することができる(メッセージ本文内の1の可能な最長な列)。推奨タイムアウトは、約521μ秒である。これにより、スピーカ側には246μ秒の猶予が与えられ、受信メッセージを調べ、767μ秒よりも前にそのACK/応答を開始する。
【００９４】
これらのメッセージタイミングを守った場合、同期喪失は発生しないであろう(ネットワークデバイスは、メッセージの開始と終わりがどこにあるかの追跡を不適切な形で失うことは決してない)。しかしながら、メッセージアドレスおよびベリファイヤバイトを調べて、受信したすべてのメッセージが有効であることを確認すべきである。さらに、メッセージの終わりを識別するのに十分に長いネットワークアイドル時間が検出された場合、4バイト長よりも短い部分受信メッセージを削除し、再同期をとらなければならない。
【００９５】
４．５  ソフトウェアドライバ
４．５．１  低レベル受信機
標準ハードウェアUART受信機は、雑音およびジッタ/スルー歪みの防止機能を備える。ハードウェアUARTが利用できない場合にソフトウェアでこの機能を近似するために、ビットバングド受信ルーチンが以下のように機能する。
【００９６】
1.同期が確認され、受信メッセージが予期できるようになった後、データ入力をエッジトリガ割り込みでアーミングされなければならない。
【００９７】
2.メッセージ第1のエッジが検出されると(第1のバイトの第1のスタートビット)、即座にさらに1〜2回リサンプリングを行って雑音を除去することによりデバウンスしなければならない(雑音は、通常のネットワークではきわめてまれなことであろうが)。有効であると分かった場合、自動リロードされる52.083μ秒タイムアウトにより駆動される状態マシンを実行し、できる限りビットセルの中心近くで次の10ビットをサンプリングしなければならない。
【００９８】
3.この状態マシンの第1の8段で、メッセージビットを収集する。8つのメッセージビットのそれぞれを、ビットセルの中心で1〜3回素早くサンプリングし、適切な値を格納しておく必要がある。
【００９９】
4.9番目のビット(ストップビット)に対するタイマー割り込みルーチンで、バスがアイドル(HIGHレベル)状態にあることを確認し、次のバイトのスタートビットに対しエッジトリガ割り込みをリアーミングしなければならない。
【０１００】
5.新しいバイトのスタートビットエッジが10番目の52.083μ秒の割り込みの前に検出された場合、10番目のタイマー割り込みをキャンセルして、前のように新しい着信バイトを組み立てる(このエッジを使用して、10ビットサンプリングエンジンのタイミングの再同期をとる)。しかし、10番目の52.083μ秒の割り込みが最初にタイムアウトになると、メッセージは終了する。それに応じて処理を進める。スレーブは、即座に、その応答の生成を開始することができる。
【０１０１】
４．５．２  マスターデバイスの送信/受信タイミング
いくつかの実際の例では、コンソール200は、ハードウェアUARTをスマートスピーカインターフェイスに割り当てている。以下の方式では、このUARTを管理することに関連する割り込みが最小限で済む。
【０１０２】
1.完了時にシステムに割り込みがかかるようにUARTを設定し、送信メッセージを一度に丸ごと(Nバイト)送信する。CS98200内の16バイトの最大UARTバッファよりも長いメッセージについては(まれ)、割り込みを使用して、可能な限り最大のブロック単位(最大16バイトまで)でメッセージをバラバラにして送信する。これは、バイト間に目立った遅延が入り込まないようにして実行すべきである。
【０１０３】
2.送信メッセージが終了したら、UART受信機を有効にし、1受信バイトの後に割り込みがかかるように設定する(最初の割り込みは、1.288m秒以内に発生すべきであるが、ただし、1.288m秒=767μ秒のReply Delay+520.83μ秒の第1のバイト長)。さらに、約1.34m秒以内にタイムアウトになるようにタイマー割り込みをアーミングする。
【０１０４】
3.最初の完全なバイトがスレーブから受信される前に1.34m秒のタイマー割り込みがタイムアウトした場合、スレーブはアクティブでないと想定して、次のスレーブのポーリングに進む。
【０１０５】
4.そうでない場合(スレーブが応答中の場合)、引き続き、受信バイト毎に割り込みをかける。その後のバイトは、520.83m秒毎に受信されなければならない。しかし、1.066m秒のSynchronization Delayがコンソールメッセージの前に使用されるため、1.066m秒タイムアウト(受信バイト毎にリセットされる)を使用して、スレーブメッセージの終わりを検出しなければならない。
【０１０６】
図10は、スピーカからの応答がある場合と、スピーカからの応答がない場合のメッセージシーケンスを示している。
【０１０７】
５．０  メッセージパケットの概要
メッセージパケットは、バスマスター(例えば、コンソール)またはスレーブ(例えば、スピーカ)により送信されたバイトの集合として定義される。メッセージパケットのすべてのビットは、バイトとバイトの間に割り込みまたは遅延を発生することなく、1つの連続バーストとして設定される。さまざまな長さのメッセージがサポートされている。いくつかの実装では、後述のHeader/Address/Argument/Verifier形式を使用する。
【０１０８】
５．１  Headerバイト(第1メッセージバイト)
バス202上のメッセージは、コンソール/マスターからであろうとスピーカ/スレーブからであろうと、1バイトのHeaderから始まる(これは、送信される第1のバイトである)。このHeaderのビット7は、予約されており、メッセージがコンソール200により送信されるのか、またはスピーカにより送信されるのかを示す。ビット7は、コンソールメッセージについては0に設定され、スピーカメッセージについては1に設定される。
【０１０９】
スタートビットとストップビットを含む完全なHeaderバイトの図が、図11に示されている。
【０１１０】
H7..H0(ビット7..0):8ビットのHeader識別子(後述のヘッダ定義を参照)。したがって、256個の別々のコマンドが可能である(コンソールからスピーカまで128、スピーカから戻ってコンソールまで128であるが、それはビット7で送信者を識別するからである)。
【０１１１】
DIR(ビット7):1ビットのMessage Direction Indicator(0=コンソール/マスターから送信、1=スピーカ/スレーブから送信)。
【０１１２】
５．２  Console Message Address Byte(第2メッセージバイト)
スマートスピーカメッセージについては、第2バイトはメッセージのアドレス指定を含む。Addressバイトの図が図12に示されている。
【０１１３】
R3..R0(ビット3..0):Room Number(0000〜1111b)。15個の一意的部屋が使用可能である(A〜Oで参照される)。0000b=RoomA。0001〜1110b=RoomB〜RoomO。1111b=ALL ROOMS、これはブロードキャストに使用される。
【０１１４】
Z3..Z0(ビット7..4):Zone Number(0000〜1111b)。15個の一意的なゾーンが使用可能である。それぞれのゾーンは、所望のオーディオストリームを識別するために使用できる。
【０１１５】
0000b=Zone1。0001〜1110b=Zone2〜Zone15。1111b=ALL ZONES、これは、コンソールメッセージによりスピーカがその入力ストリーム/ゾーン選択を変更すべきでない場合に使用される。
【０１１６】
アドレスバイトの例(スタート/ストップビットを無視する)は、Zone1、RoomA:00000000b。Zone2、RoomI:00011001b。
【０１１７】
Addressバイトに含まれるゾーン情報は、例えば、RFリモートコントロールから、コンソール200に通され、スピーカによって選択されたオーディオストリームを識別する。有効なオプションの例は、Zone1(0000b)、Zone2(0001b)、およびALL Zones(1111b)である。他のオプションも可能である。例えば、いくつかのオプションでは、それ独自の(独立の)オーディオストリームが用意されるそれぞれの部屋をサポートする。
【０１１８】
５．３  Speaker Message Addressバイト(第2メッセージバイト)
スピーカAddressバイトを使用することで、スピーカ応答で、スピーカがOFFであるか、またはLocal音源(その可能なもののうちの1つ)の受信を待っているか、またはコンソール200から送信されたストリームのうちの1つ(Zone1またはZone2)の受信を待っているかを示すことができる。このバイトの形式は、図13に示されている。
【０１１９】
R3..R0(ビット3..0):コンソール200について定義されているのと同じ:15個の使用可能な部屋のうちの1つを示すが、1111bはスピーカについては未定義である(スピーカはブロードキャストに応答しないからである)。
【０１２０】
Z3..Z0(ビット7..4):0000〜1101b:14個の可能なZonesのうちの1つを再生する(0010b=Zone1、0011b=Zone2など)。
1110b:ローカル音源を再生する。
1111b:OFF。現在、ローカルまたはネットワーク接続音源を再生していない。
【０１２１】
５．４  Argumentバイト
Addressバイトの後、メッセージを終了するVerifierバイトの前のところに、メッセージArgumentバイトが含まれる。ポーリングには、引数バイトが含まれない。いくつかのスマートスピーカメッセージは、Argumentバイトを1つしか含まないが、スピーカメッセージは、Argumentバイトをいくつでも含むことができる。さまざまなコマンドの中で使用されるArgumentバイトのメッセージ定義および詳細について以下で説明する。それぞれのArgumentバイトは、図14に示されている形式で送信される。
【０１２２】
A7..A0(ビット7..0):8ビットメッセージ引数。
【０１２３】
５．５  Verifierバイト(最後のメッセージバイト)
スマートスピーカメッセージの最終バイトは、Verifierバイトである。このバイトは、基本メッセージ情報が破損していないことを確認するために使用される。以下のメッセージ定義に示されているように、このバイトは、一般に、先行するすべてのメッセージバイトのソフトウェア排他OR(XOR)であるが、長いメッセージ形式では、これを使用して、Header/Addressのみを検証し、ローカルチェックサムなどをArgumentフィールド内に含めて、その大量のデータペイロードをより厳格に検証したい場合もある。このVerifierバイトの形式は、図15に示されている。
【０１２４】
V7..V0(ビット7..0):一般に、先行するすべてのメッセージバイトのXOR。
【０１２５】
６．０  交換のルール
「交換」は、コンソール200から特定のスピーカへのメッセージとその返信としてそのスピーカから送信される後続の応答の2つのバスメッセージの集まりとして定義される。このような交換を左右するルール群を以下に示す。
【０１２６】
６．１  マスターのみが自発的メッセージを生成する
コンソール200は、スマートスピーカバス202上のすべての通信のマスターである。例えば、コンソール200のみが、バス202上の自発的伝送を発生する。
【０１２７】
６．２  マスターは、進行中の交換に割り込みをかけない
コンソール/マスターによるメッセージ保留の重要度に関係なく、外へ向かう伝送は、新しい伝送を開始する前にすでに開始している交換サイクルが完了するまで待つ。コンソール200またはスピーカからの進行中のメッセージは割り込みされない。
【０１２８】
６．３  スレーブはそれにアドレス指定されたメッセージの直後にしか送信しない
スレーブ/スピーカは、それに対し特にアドレス指定されたコンソールメッセージの直後にしか送信できない(例えば、コンソールブロードキャストの後に送信するスレーブはない)。このルールは、スピーカメッセージの保留がどれだけ重要であろうと、適用される。スピーカが上流で通信を送り返せるタイミングのよい機会を十分保証できるように頻繁に、メッセージ(例えば、ポーリング)をそれぞれのスピーカに送信するのはコンソールの役目である。
【０１２９】
６．４  スレーブはそれにアドレス指定されたメッセージに応答する
スピーカがOFFでない限り(応答がオプションの場合)、スレーブ/スピーカは、何らかの形の返信メッセージでそれにアドレス指定されたコンソールメッセージに応答する(既定の応答は、目下のところスレーブに通信すべき重要なものが何もない状況ではPoll_Replyである)。応答は、許容可能な遅延期間(例えば、767μ秒)以内に生成される。
【０１３０】
スピーカは、以下のメッセージタイプのうちのどれか1つでコンソールメッセージに応答することができる。
【０１３１】
・  Poll_Replyメッセージ(4バイト)。これは、既定のスピーカ応答であり、さらに高い優先度の応答が送信できる(クエリ応答を含めて)のではない限りすべてのポーリング、コマンド、およびクエリの後に使用される。
【０１３２】
・  PASS_KEY_CODEメッセージ(メッセージ定義を参照)。
【０１３３】
・  DOWNLOAD_INFORMATIONメッセージ(メッセージ定義を参照)。
【０１３４】
６．５  スレーブは現在保留中の最高優先度の情報で応答する
スピーカ/スレーブでは、コンソール200に送り返す機会が到来したときに複数のメッセージが保留になっている可能性がある。このような状況では、最高優先度のメッセージが送信されなければならない。可能なメッセージタイプの一般的ガイドラインは以下のとおりである。
【０１３５】
６．５．１  最高優先度:非ポーリングクエリ応答
コンソール200が特定のクエリメッセージ(「poll」以外-メッセージ定義を参照)をスピーカに送信した場合、スピーカはできる限り速やかに適切な応答を送信する。クエリ応答が組み立てられるまで低優先度の応答を送信できるが、いったん組み立てられると、送信キュー内で最高優先度を割り当てられる。
【０１３６】
６．５．２  中優先度:Pass_Key_Codeメッセージ
スピーカ/スレーブ製品(またはそのローカルリモートコントロール)上でいくつかのボタンが押されると、コンソール音源などに対する緊急の変更が必要になることがある。Pass_Key_Codeメッセージは、該当する押下をコンソール200に伝達するために以下で定義される。これらのメッセージは、スレーブの送信キュー内で中優先度を与えられなければならない(クエリ応答がキュー内で使用できる場合には保留にしなければならないが、ポーリング応答に優先する)。
【０１３７】
６．５．３  中優先度:Download_Informationメッセージ
Download_Informationメッセージは、スピーカ/スレーブがデータのブロックをコンソール200に伝達できるように以下で定義される。このデータは、通常、スレーブ(例えば、現在のAM/FM局)上で再生されるローカル音源に関係する情報を表すことが期待される。このようなメッセージは、中優先度を与えられ、これはPass_Key_Codeメッセージと同じである。これらは、したがって、Pass_Key_CodeメッセージとともにFIFO内にバッファリングされなければならず、ポーリング応答に優先するが、他のすべての特定のクエリ応答がキュー内にある場合には保留になる。
【０１３８】
６．５．４  最低優先度:ポーリング応答
他のスピーカメッセージが送信Smart Speakerキュー内にない場合に、Poll_Reply(メッセージ定義を参照)と呼ばれる既定の応答が送信されなければならない。この応答は、応答の他のクラスよりも重要度が低いとみなされる、スピーカのオン/オフ状態およびその音量レベルに関する基本情報のみを含む。
【０１３９】
６．６  マスターはすべてのスピーカを連続的にポーリングするが、低優先度としてである
スピーカが上流方向に情報をコンソール200へタイミングよく送信できるようにするため、ポーリングメッセージが送信され、これは、スピーカステータスの変更に気づく機会として利用される。コンソールメッセージの場合と同様、スピーカは、オプションにより、上述のメッセージタイプのどれかでのポーリングに応答することができる。コンソールのポーリングサイクルのタイミングに関する詳細を以下で説明する。一般的には、これらのポーリングは連続的に送信されるが、コンソールの送信キュー内に利用可能な高い優先度のメッセージが入っていない場合のみである。
【０１４０】
６．７  マスターは現在保留中の最高優先度メッセージを送信する
スレーブの場合と同様に、コンソール/マスター送信メッセージは優先度を割り当てられる。優先度の高いメッセージは、以下のように低い優先度のメッセージよりも優先される。
【０１４１】
６．７．１  最高優先度:非ポーリングクエリおよび制御メッセージ
クエリまたは制御メッセージが特定のスピーカに送信される必要がある場合、最高優先度を与えられる。メッセージ定義を参照。
【０１４２】
６．７．２  中優先度:Pass_Key_Codeメッセージ
コンソール200は、コンソールによって使用されていないRFコマンドをスピーカに直接通すことができる。以下で定義される、Pass_Key_Codeはこのために使用される。このようなメッセージは、クエリよりも低い優先度を持つが、ポーリングには優先度が高い。Pass_Key_Codeメッセージが保留になっている場合、ポーリングサイクルは割り込みがかかり、(進行中の交換が完了した後)、Pass_Key_Codeメッセージが送信され、その後ポーリングは再開できる。
【０１４３】
６．７．３  中優先度:Download_Informationメッセージ
コンソール200はDownload_Informationメッセージ(メッセージ定義を参照)を使用して、データの大きなブロックをスピーカにダウンロードすることができる。これは、スピーカアプリケーションコードなどを更新する場合に使用することができる。これらのメッセージに対する優先度は、クエリよりも低いが、ポーリングよりも高い。Pass_Key_Codeメッセージの場合と同様、ポーリングサイクルは一時的に割り込みがかけられ、保留中のDownload_Informationメッセージを送信する。
【０１４４】
６．７．４  最低優先度:ポーリング
スピーカポーリングは、最低優先度を割り当てられ、コンソール200が送信すべき重要性の高い情報がない間に送信されるメッセージの連続サイクルを表すべきである。これらのポーリングを送信することにより、それぞれのスピーカは、上流に向かってメッセージをコンソール200に送信する定期的機会がそれぞれのスピーカに対し保証される。
【０１４５】
６．８  クエリ交換時に1つのスピーカのみがポーリングされる
コンソール200とスピーカとの間の完全なクエリ交換は以下のようにして実行される。
【０１４６】
1.クエリを送信する必要がある場合、コンソール200は、通常のポーリングサイクルに割り込みをかけ(進行中の交換が完了した後)、所望のクエリを適切なスピーカに即座に送信する。
【０１４７】
2.スピーカは、可能ならば、767μ秒以内にその応答を送信する。可能でなければ、767μ秒以内にPOLL_RESPONSEメッセージで応答する。
【０１４８】
3.コンソール200は、他のすべてのスピーカをポーリングすることを差し控え、その代わりに、このスピーカのみを6m秒おきにポーリングする。スピーカは、クエリ応答の用意が整うまでPOLL_RESPONSEメッセージで応答する。用意ができたら、所望のクエリ応答で応答する。
【０１４９】
4.所望のクエリ応答を受信した後、コンソール200は、すべてのスピーカに対する通常のポーリングサイクルを再開する。代替えとして、スピーカが全く応答できない場合、またはOFFとして応答する場合、通常ポーリングは、高水準のソフトウェアの裁量により再開することもできる。
【０１５０】
６．８  メインルームの外で使用されるコマンドの全リスト
「メインルーム」内のスピーカは、後述のメッセージ定義を使用する。メインルームの外のスピーカは、例えば、音量大/小、ミュート/ミュート解除、およびオン/オフといった限られた制御メッセージのみを使用できる。他のすべての特定のコントロールは、リモートコントロールコマンドを透過的にコンソールからスピーカに(Pass_Key_Codeコマンドを使用して)受け渡すことにより処理することができるが、ただし、それらが正常に解釈される場合に限る。
【０１５１】
以下に、非メインルームスピーカにより受信できるコマンドのリストを示す。メッセージの構成の詳細については、以下のメッセージ定義を参照されたい。
【０１５２】
６．８．１  POLLおよびPOLL REPLYメッセージ(ヘッダ0x00/0x80)
ポーリングは、最低優先度メッセージであり、ポーリングサイクルによる決定に従いコンソール200によりすべてのスピーカに連続的に送信される。すべてのスピーカのON/OFF、Local/Network、および音量/ミュートステータスを監視するほかに、スピーカからコンソール200にメッセージを頻繁に送信する機会を与えるため、コンソール200により使用される。高い優先度のメッセージを送信する必要がある場合に割り込みが発生する。スピーカは、通常、Poll Replyで応答するが、保留中のものがあればより高い優先度の応答を置き換える。
【０１５３】
６．８．２  ON/OFFメッセージ(ヘッダ0x01)
このメッセージは、スピーカをONまたはOFFにするためにコンソール200により使用することができる。スピーカは、さらに、いくつもの異なるパススルーされたRFリモートボタンを受け取った後、またはローカルのIRリモートからコマンドを受け取った後にオンになりうる。これらの場合、ポーリングは、電源オンを検出するために使用される。
【０１５４】
６．８．３  PASS_KEY_CODEメッセージ(ヘッダ0x0D/0x8D)
このメッセージは、スピーカ特有のRFリモートコントロールコマンドを通すためにコンソール200により(ヘッダ0x0Dを使用して)使用されることができる。コンソール200は、これらのコマンドを全く解釈しえない。ヘッダ0x8Dを使用することで、スピーカは、ボタン押下を上流に向かってコンソール200に送り返すことができる。
【０１５５】
６．８．４  SET_MAIN_ATTENUATIONメッセージ(ヘッダ0x02)
コンソール200は、Mute Allイベントに対する応答として、MuteおよびReturn_to_Last_Volume引数をブロードキャストとして使用できる。
【０１５６】
６．８．５  QUERY_SPEAKER_INFOメッセージ(ヘッダ0x0B)
このメッセージは、取り付けられているさまざまなスピーカを判別するためにコンソール200により使用される。コンソール200は、さらに、Query_Main_AttenuationおよびQuery_Download_Info_Status引数を使用することもできる。
【０１５７】
６．８．６  DOWNLOAD_INFORMATIONメッセージ(ヘッダ0x0A/0x8A)
このメッセージ(ヘッダ0x0A)は、コンソール200ステータス情報をスピーカにプッシュする場合に使用するか、または他のデータブロックをスピーカに送信する場合に使用することができる(場合によっては、アプリケーションコードの更新など)。ヘッダ0x8Aを使用することにより、スピーカはこのメッセージタイプを利用して、データのブロックをコンソールにアップロードすることができる(例えば、表示する音源関連データ)。
【０１５８】
７．０  ポーリングサイクル
７．１  概要
ポーリングに対する標準的な応答では、そのオン/オフ状態、ローカル/ネットワーク聴取モード、ミュート状態、および音量レベルに関する基本的なスピーカステータス情報を供給することができる。スピーカは、標準ポーリング応答に対する高い優先度のメッセージ(保留の場合)を置き換える機能を持ち、これにより、重要なボタン押下およびデータのブロックを上流に向かってコンソール200に転送する機会を与える。
【０１５９】
ネットワークに接続されているスピーカは、長時間にわたってオフになっている場合がある。オフの場合、スピーカは、キーストロークでオンになった場合を検出するために時折ポーリングするだけでよい。しかし、接続され、かつオンにされているスピーカは、上流に向かってコンソール200に送信されるメッセージの適切な応答時間を保証するために高速なポーリングが実行されなければならない。そこで、これらの必要条件を満たし、ONのスピーカの個数が増えたときに予測可能な形で、ただし急激にでなくデグレードするようにパフォーマンスが制御されるポーリングサイクルについて説明する。
【０１６０】
7.2 ポーリングサイクルのタイミングの詳細
ポーリングプロセスでは、15個の可能なスピーカのすべてを2つのリスト、つまり、現在ONのスピーカと、NOT ONスピーカ(オフまたは切断されている)に編成する。コンソールは、まず、現在ONのスピーカリストのすべてのメンバ(最大15まで、順番に)をポーリングし、その後、NOT ONリスト(もしあれば)の単一メンバをポーリングする。これは、ポーリングサイクルの1サブサイクルを表す。その後、サブサイクルは(割り込みなしで)繰り返すが、その際に、NOT ONリストの次のメンバを除くONスピーカの同じリストを(循環ラウンドロビン方式で)使用する。
【０１６１】
例えば、スピーカAのみがONの場合、全ポーリングサイクルは以下のようになる。
【０１６２】
AB、AC、AD、AE、AF、AG、AH、AI、AJ、AK、AL、AM、AN、AO、その後、これは、割り込みなしで繰り返す。全部で14のサブクラス。
【０１６３】
1サブサイクル〜11ミリ秒。全サイクル〜153ミリ秒。
【０１６４】
スピーカCおよびGのみがONであるとわかっている場合、ポーリングサイクルは以下のようになる。
【０１６５】
CGA、CGB、CGD、CGE、CGF、CGH、CGI、CGJ、CGK、CGL、CGM、CGN、CGO、その後、これは繰り返す。13サブサイクル。
【０１６６】
1サブサイクル〜16ミリ秒。全サイクル〜214ミリ秒。
【０１６７】
すべてのスピーカがONであった場合、ポーリングサイクルは以下のようになる。
【０１６８】
ABCDEFGHIJKLMNO、その後、これは繰り返す。15サブサイクル。
【０１６９】
1サブサイクル=全サイクル〜82ミリ秒。この結果、スピーカからコンソールまでのメッセージの待ち時間は最長となる。
【０１７０】
すべてのスピーカがNOT ONであった場合、ポーリングサイクルはすべてONの場合と同じになる。15サブサイクル。
【０１７１】
最長の全サイクルは、7個のスピーカONで、残りNOT ONである。
【０１７２】
1サブサイクル〜44ミリ秒。全サイクル〜351ミリ秒。これは、スピーカがONになるのを識別する最長の待ち時間を持つ。
【０１７３】
ポーリングサイクルのそれぞれのサブサイクルが完了すると、ONスピーカおよびNOT ONスピーカのリストは、ポーリング応答に基づいて更新されなければならない。最後のサブサイクルでONとして応答した、すでにNOT ONであるスピーカは、即座に、ONリストに移行しなければならない。OFFとして応答した、または5サブサイクルの間に一斉に応答できなかった、すべてのすでにONであるスピーカは、NOT ONリストに移動されなければならない。コンソールのリセット後、ポーリングが最初に開始したときに、NOT ONリスト内のすべてのスピーカが開始する。
【０１７４】
【表７】
0005383775.tif 000008
【０１７５】
７．３  標準的なポーリングおよび応答メッセージバイト
コンソールまたはスピーカに、送信する高い優先度のメッセージがない限り、システムは、既定で、以下のような形式のメッセージを使用してポーリングサイクルに入る。
【０１７６】
Console Poll (3バイト):
第1の(Header)バイト:0x00 (POLLメッセージ)。
第2の(Address)バイト:現在の通常プロトコルによる。
第3の(Verifier)バイト:現在の通常プロトコルによる。
【０１７７】
Speaker Poll Reply (4バイト):
第1の(Header)バイト:0x80 (POLL REPLY)。
第2の(Address)バイト:オン/オフ/ローカル/ネットワークステータスを含む、スピーカのアドレスバイト。
第3の(Argument)バイト:以下のように音量/ミュートステータスになる:
引数詳細:
ビット6..0:現在の通常プロトコルによる、スピーカのMain Attenuationレベル。
ビット7:ミュート状態:1=ミュート。0=ミュートしていない。
第4の(Verifier)バイト:現在の通常プロトコルによる。
【０１７８】
７．４  PASS_KEY_CODEメッセージを応答として使用する(Header 0x8D)
コンソールメッセージの後では真であるが、この(4バイト)メッセージは、送信できる場合に、コンソールPOLLメッセージの後に、SPEAKER_INFO応答(0x8C)の代わりに返される。Argumentバイトは、コンソールを制御することを意図されている256個の可能なボタンのうちの1つに関連付けられたキーコードを含む。注意:IR/RFリモートに対する既存のキーコードは、可能ならば使用されなければならない。
【０１７９】
7.5 DOWNLOAD_INFORMATIONメッセージ(0x8A)を応答として使用する
この(Nバイト)の応答は、送信できる場合には、ポーリングを含む、コンソールメッセージの後に、SPEAKER_INFO応答(Ox8C)の代わりに返される。Argument/Dataバイトは、コンソール向けの何らかの種類のデータ、高水準のコマンド、またはクエリ(すべて現在未定義)を含むことも可能である。これは、リモートコントロールに表示するためローカル音源関連のデータをコンソールに送信する場合に使用できる。さらに、これにより、スピーカは音源変更などを直接指令したり、またはローカルディスプレイ(再生中のチューナステーションなど)に対するゾーン/音源特有のステータス情報を要求することも、概念的には可能である。
【０１８０】
８．０  高レベルのスピーカ制御問題
８．１  マスター/スレーブ構成
与えられたバス上にマスターが1つだけある。バスMasterは、バスがIdle状態である限り(現在進行中のすべてのメッセージおよび応答が送信を開始する前に完了できる)、また後述のメッセージタイミング詳細に留意する限り、いつでも送信を開始できる。
【０１８１】
スピーカは、コンソールによって送信されたメッセージの後でないと送信しない。しかし、後述のように、コンソールメッセージは、スピーカが送信を開始するためのちょうどよい機会として使用することができる。
【０１８２】
８．２  部屋のアドレス指定は一意である
ネットワークに追加される新しいスピーカは、ネットワークに接続する前に、一意的な4ビットRoom Address(RoomAからRoomOまで、スピーカを動作させることが意図されているリモートコントロールと一致する)を適切に設定しておく。
【０１８３】
８．３   Zone1およびZone2に対する別々の物理的バスの管理
コンソール200は、2つの別々の物理的スマートスピーカバス(Speaker Outputコネクタ毎に1つ)を備える。Zone1およびZone2オーディオストリームは、Zone2 Speaker Data信号のように、Zone2 Speaker Outputコネクタ上で使用可能である。RoomBからRoomOスピーカは、そのプラグをZone2 Speaker Outputコネクタに差し込み、Zone2 Speaker Data信号を使用して制御することができる。
【０１８４】
８．４  スピーカ制御モード
Master ModeおよびPass-Through Modeという、スピーカを制御する2つの異なるモードを使用できる、Smart Speakerメッセージが定義される。Master Modeコマンドを使用すると、制御ユニット(例えば、コンソール)はすべてのクリティカルなスピーカパラメータを追跡し、適宜、それらのパラメータを絶対値(引数)としてスピーカに送信することができる。Pass-Through Modeでは、インテリジェント機能の低い制御ユニット(IR/Smart Speakerプロトコルブリッジ程度の単純さ)でも、リモートコントロールメッセージを効果的にスピーカに直接受け渡すことができる。このモードでは、スピーカは、クリティカルなパラメータ(ミュート前の最後の音量レベルなど)を追跡する。
【０１８５】
Master Modeを介してネットワーク接続スピーカを制御することを望んでいるコンソールでは、制御すべきスピーカのそれぞれのタイプの利用可能な特徴(コントロールのタイプおよび範囲など)を記述したテーブルを保持する。
【０１８６】
８．５  新しいスピーカの検出
電源投入(ハードウェアリセット)後、ネットワーク接続スピーカは、OFF STATE(ミュート状態)に入り、ハードウェアを最低電流状態にする必要がある。この状態では、ネットワークとインターフェイスする役割を持つハードウェアのみが動作している。スピーカは、(最低でも) Poll Messages、Query_Speaker_Info Messages、さらにON/OFF Messagesを受信し、それに応答できる。
【０１８７】
コンソールは、可能なすべてのスピーカRoom Addressesを連続的にポーリングするので、Smart Speakerバスに新規追加されたスピーカは、ポーリングに応答し始めるとすぐに検出されることができる。新しいスピーカが検出されたら、コンソールは、Query_Speaker_Infoメッセージを送信して、そのタイプを識別しなければならない。
【０１８８】
８．６  ネットワーク接続スピーカの電源オン
ネットワーク接続スピーカにPollまたはQuery_Speaker_Infoメッセージ以外のコマンド送信する前に、まず、ON/OFF Messageを使用してオンにしなければならない。これにより、スピーカのハードウェアは完全に動作するようになる。コンソール200は、この電源オンプロセスが完了できるように適宜遅延すべきである。それぞれのネットワーク接続スピーカに対する電源オン遅延を記述するテーブルが用意されていない場合、コンソール200では、既定の遅延時間として1秒を使用しなければならない。
【０１８９】
８．７  ボーリングによるスピーカステータスの変化の検出
このポーリング過程で、スピーカの応答のAddress Byteのビット7..4は、オン/オフステータスに関する情報だけでなく、以下のように、再生している音源(Zone1、Zone2、またはそれ自体のローカル音源)に関する情報も含む。
【０１９０】
Z3..Z0(ビット7..4):0000-1101b:14個の可能なZonesのうちの1つを再生する(0010b=Zone1、0011b=Zone2など)。
1110b:ローカル音源を再生する。
1111b:OFF。現在、ローカルまたはネットワーク接続音源を再生していない。
【０１９１】
これらのビットを監視することにより、以下の重要なステータス変化が生じた場合を検出することができる。
【０１９２】
８．７．１  スピーカのオン/オフ
スピーカは、ユニット自体のボタンを使って、またはそのIRリモートコントロールを介して、またはその重要性を理解することなくコンソールに単純にパススルーするリモートコントロールコマンドを介して、オン、オフすることも可能である。Address Z3..Z0ビットを使用することにより、コンソール200はそれぞれのスピーカのオン/オフ状態を監視することができる。これにより、コンソール200は、例えば、すべてのスピーカがオフの場合に電源オフにすることができる。
【０１９３】
８．７．２  スピーカの音源変更
同様に、スピーカは、コンソール200がそれと予期することなく、Zone1とZone2(またはローカルの音源)を切り替えることができる。同じAddressビットを監視することにより、コンソール200は、そのような変更を検出し、適切な処置を講じることができる(適切なオーディオ経路を電源オン/オフするなど)。
【０１９４】
8.8 スピーカストリームの切り替えの管理
スピーカは、コンソールからZone1またはZone2ネットワーク接続アナログ出力のいずれかを選択する機能を持つことができる。スピーカは、すべてのコンソールPass_Key_Codeメッセージ(Header 0x0D)およびOn/Offメッセージ(Header 0x01)のAddressバイトのZoneビットに反応することにより自動的にこの選択を行う。これらのメッセージは、RFリモートコントロール上のボタン押下の直接的結果としてスピーカに送信され、したがって、Zoneビットはリモートからメッセージを受け取ったとおり正確にセットされる(ただし、これらのビットは、リモートからスピーカに直接渡される)。On/Offメッセージは、ここでは、コンソールがすべてのリモートコントロールの音源ボタン押下(AM/FM、AUX、CD/DVDなど)に対する応答としてそのメッセージを送信し、その場合On/Offメッセージにより、音源が選択されたときにネットワーク接続スピーカはONおよびミュート解除の両方の状態になる。Pass_Key_Codeメッセージがローカル音源を再生するスピーカに送信されても、Localモードからスピーカが切り替わることはない。
Pass_Key_CodeメッセージがOn/OFFボタン引数とともにスピーカに渡されると、最後に再生された音源(NetworkまたはLocalのいずれか)でスピーカは電源オンになる。この場合にスピーカ側でネットワーク接続ストリーム/ゾーンを再生することを選択した場合、メッセージAddressで示されるストリームを選択する(最後に再生されたストリームとは反対に)。
【０１９５】
９．０  メッセージ定義
９．１  早見表
【０１９６】
【表８】
0005383775.tif 000009
【０１９７】
【表９】
0005383775.tif 000010
【０１９８】
９．２  コンソールにより送信されるメッセージ
以下のメッセージは、コンソール200により送信することができるメッセージ定義集の例である。
【０１９９】
９．２．１  POLLメッセージ(Header 0x00)
送信側:コンソール
総バイト数: 3
キュー優先度:低
【０２００】
Poll Messageは、現在定義されている唯一の3バイトメッセージである。そのAddressバイトの4個の最上位ビットで、スピーカで再生する適切なオーディオZoneを識別する。4個の最下位ビットで、(スピーカのDIPスイッチで設定されたRoom Numberで)ポーリングされるスピーカを識別する。
【０２０１】
Argumentは必要ないので、使われず、ネットワーク帯域幅が節約される。
【０２０２】
Pollメッセージは、Poll Response情報を取得し、スピーカに他の重要なメッセージを渡す通常の機会を与えるために、実際には、単純なクエリ形式で送信される。
【０２０３】
【表１０】
0005383775.tif 000011
【０２０４】
９．２．２  ON/OFFメッセージ(Header 0x0l)
送信側:コンソール
総バイト数: 4
キュー優先度:高
【０２０５】
ON/OFF Messageは、オーディオ再生の準備のため完全電源オンにするか、またはセッションの後電源をオフにするようアドレス指定されたSmart Speaker(s)に通知する。注意:このコマンドは、リモート上の音源ボタンが押されたときにコンソールにより使用され、これにより、スピーカの完全電源オン、ミュート解除、所望のネットワーク入力ストリームの選択を行うようにできる。
【０２０６】
【表１１】
0005383775.tif 000012
【０２０７】
スピーカの電源レールなどがミュート解除できるようになる前に(または、場合によっては、スピーカが他のコマンドを受け付けることができるようになるまで)整定するのにある程度の時間を要することが予想される。オンになった後、システムは、この問題に対し以下の3つの方法で対処することができる。
【０２０８】
1.コンソールからスピーカに対し準備完了しているか問い合わせしてから(QUERY SPEAKER STATUSコマンド、ON/OFF Status引数を使用して)、スピーカモード、減衰レベルなどを構成するよう指令することができる。
【０２０９】
2.スピーカは、ミュート解除の準備が整うまでSET SPEAKER MODEなどの後続のコマンドに応答しないことを単に選択することができる。
【０２１０】
3.コンソールは、On/Offメッセージの送信から後続のメッセージの送信までの間に遅延(通常は約1秒)を設定することができる。
【０２１１】
９．２．３  SET MAIN ATTENUATIONメッセージ(Header 0x02)
送信側:コンソール
総バイト数: 4
キュー優先度:高
【０２１２】
Set Main Attenuationメッセージで、アドレス指定されたSmart Speaker(s)にそのマスター音量設定を示されているレベルに変更するよう指令する。注意:引数は、減衰のdBで表された新しいレベルを含み、0dBはスピーカの最大音量を表す。スピーカの利用可能なダイナミックレンジは、Query Speaker Info (Speaker Type)応答を通じて渡される。
【０２１３】
【表１２】
0005383775.tif 000013
0005383775.tif 000014
【０２１４】
９．２．４  SET SECONDARY LEVELSメッセージ(Header 0x03)
送信側:コンソール
総バイト数: 4
キュー優先度:高
【０２１５】
【表１３】
0005383775.tif 000015
【０２１６】
９．２．５  SET EQ TYPE/TONE LEVELSメッセージ(Header 0x04)
送信側:コンソール
総バイト数: 4
キュー優先度:高
【０２１７】
【表１４】
0005383775.tif 000016
【０２１８】
９．２．６  SET SPEAKER MODEメッセージ(Header 0x05)
送信側:コンソール
総バイト数: 4
キュー優先度:高
【０２１９】
【表１５】
0005383775.tif 000017
【０２２０】
９．２．７  CONTROL EFFECTSメッセージ(Header 0x06)
送信側:コンソール
総バイト数: 4
キュー優先度:高
【０２２１】
【表１６】
0005383775.tif 000018
【０２２２】
９．２．８  SELECT AUDIO INPUTメッセージ(Header 0x07)
【０２２３】
送信側:コンソール
総バイト数: 4
キュー優先度:高
【０２２４】
【表１７】
0005383775.tif 000019
【０２２５】
９．２．９  SELECT DECOMPRESSORメッセージ(Header 0x08)
送信側:コンソール
総バイト数: 4
キュー優先度:高
【０２２６】
【表１８】
0005383775.tif 000020
【０２２７】
９．２．１０  SELECT POST PROCESSINGメッセージ(Header 0x09)
送信側:コンソール
総バイト数: 4
キュー優先度:高
【０２２８】
【表１９】
0005383775.tif 000021
【０２２９】
９．２．１１  DOWNLOAD INFORMATIONメッセージ(Header 0x0A)
送信側:コンソール
総バイト数: 5-255
キュー優先度:中
【０２３０】
DOWNLOAD_INFORMATIONメッセージは、Smart Speakerパケット自体を介して最大250バイトまでのデータをスピーカに送信できる形式を持ち、ペイロードは好きなように定義することができる(ローカルチェックサムなどを含む)。スピーカVFDに直接書き込む、またはコンソールステータス(再生されている新しい音源、新しいトラック/局など)の変更をアナウンスする、このメッセージタイプの変種を定義することも可能である。
【０２３１】
【表２０】
0005383775.tif 000022
【０２３２】
９．２．１２  QUERY SPEAKER INFOメッセージ(Header 0x0B)
送信側:コンソール
総バイト数: 4
キュー優先度:高
【０２３３】
【表２１】
0005383775.tif 000023
【０２３４】
９．２．１３  PASS KEY CODEメッセージ(Header 0x0D)
送信側:コンソール
総バイト数: 4
キュー優先度:中
【０２３５】
Pass Key Codeメッセージは、この場合、RFリモートコントロールボタンの押下をスピーカにパススルーするためにコンソールにより使用される。Argumentバイトは、RFリモートコントロールから受け取ったとおり正確にキーコードバイトを含んでいなければならない。
【０２３６】
【表２２】
0005383775.tif 000024
【０２３７】
９．３  スピーカによって送信されるメッセージ
以下は、スピーカ(ネットワークスレーブ)により送信されることが許されているメッセージの例である。
【０２３８】
９．３．１  POLL REPLYメッセージ(Header 0x80)
送信側:スピーカ
総バイト数: 4
キュー優先度:低
【０２３９】
【表２３】
0005383775.tif 000025
【０２４０】
９．３．２  DOWNLOAD INFORMATIONメッセージ(Header 0x8A)
送信側:スピーカ
総バイト数: 5-255
キュー優先度:中
【０２４１】
【表２４】
0005383775.tif 000026
【０２４２】
９．３．３  QUERY SPEAKER INFO REPLYメッセージ(Header 0x8C)
送信側:スピーカ
総バイト数: 4
キュー優先度:高
【０２４３】
【表２５】
0005383775.tif 000027
0005383775.tif 000028
0005383775.tif 000029
【０２４４】
９．３．４  PASS KEY CODEメッセージ(Header 0x8D)
送信側:スピーカ
総バイト数: 4
キュー優先度:中
【０２４５】
Pass Key Codeメッセージは、この場合、ローカルスピーカボタン押下を上流のコンソールに送信するためにスピーカにより使用される。Argumentバイトは、スピーカのローカルIRリモートコントロールから受け取ったとおり正確にキーコードバイトを含んでいなければならない。
【０２４６】
【表２６】
0005383775.tif 000030
【０２４７】
１０．０  無線デバイス
無線デバイスを含むオーディオネットワーク制御システムの実施例では、無線デバイスは、無線チャネルを通じて送信されるメッセージの完全性に関する責任を負う。これは、コンソールから下流に向かってスピーカに送信されるメッセージ(「ダウンリンク」)とともに、それに対する応答として送り返されるメッセージ(「バックリンク」)に適用される。合意されているレベルのロバスト性を保証するために、トランシーバにより付加的な誤り防止/訂正機能が追加される。
【０２４８】
コンソールからのポーリングは、無線リンクを介しては送信されない。その代わりに、無線スレーブが、それに接続されているスピーカをローカルでポーリングし、20ミリ秒毎に1回無線マスターに応答を送信する。無線マスターは、それらの応答をバッファリングし、ローカルで、適切なポーリングに対する応答としてそれらをコンソールに受け渡す。以下で詳細を述べる。既定の応答(Header 0x80)も、場合によってはクエリ応答がバックリンクを介して返されるまで、コンソールからスピーカへの他のすべての(つまり、より高い優先度の)メッセージに対する応答として無線マスターにより生成される。
【０２４９】
スレーブデバイスでは、スピーカにはコンソールに接続されているのと「十分同じ」であるように見えるSmart Speakerインターフェイスを実装している。これは、コンソールと同様の方法でスピーカをポーリングすること、このポーリングに割り込みをかけて下流メッセージを即座にスピーカに渡すこと、およびすべてのポーリング応答情報を組み立てて、バックリンクを介してコンソールに送信することを含む。Slaveのポーリングは、1つのWireless Slaveがすべてのネットワーク接続スピーカ専用に割り当てられるというトポロジ的な利点があれば、いくぶん簡素化される。
【０２５０】
１０．１  スレーブのローカルポーリングサイクル
コンソールにより生成されるポーリングはSlavesに送信されないため、それぞれのSlaveは、その関連するスピーカを自律的に識別し、ローカルポーリングサイクルを管理する。Wireless Slavesは、接続されている単一スピーカをポーリングするだけでよい-他のスピーカに対してローカルポーリングは不要である。接続されているスピーカのRoom Codeを判別するために、Wireless Slaveは、次のようにして、コンソール内に実装されるポーリングサイクルのより単純なバージョンを設定する。
【０２５１】
1.Wireless Slaveは、応答のあるスピーカが見つかるまで可能なすべてのスピーカを連続的にポーリングする。
【０２５２】
2.その後、Wireless Slaveは、20ミリ秒の速さでそのスピーカのみをポーリングする。
【０２５３】
3.スピーカが応答を停止した場合、無線マスターは、応答スピーカが見つかるまで(新しいRoom Codeでありうる)可能なすべてのスピーカのポーリングを再び開始する。
【０２５４】
20ミリ秒のバックリンク期間毎にそれに間に合うように1回のボーリング応答を確実に組み立てるために、SlaveによりWireless Slaveのローカルポーリング期間を同期させ、ポーリング交換がそれぞれのバックリンクメッセージの送信直前に実行されるようにする(約6ミリ秒早く開始し、バックリンクメッセージに含む応答を組み立てられるように時間に余裕を持たせる)。したがって、スピーカ高優先度メッセージ(ローカルボタン押下など)は、Slaveから無線マスターへの送信(初回)の機会が得られるまでに最大約20ミリ秒の待ち時間を被る。
【０２５５】
１０．２  ローカルポーリングに対するコンソールメッセージの優先度
すでに概要を述べたように、コンソールメッセージの送出は、スピーカからポーリング情報を取り出すことよりも優先度が高い。したがって、Slaveが接続されているスピーカ向けのメッセージをコンソールから受信すると(例えば、PASS_KEY_CODEメッセージ)、メッセージは、ローカルポーリングサイクルのタイミングに関係なく、スピーカに即座にパススルーされなければならない。
【０２５６】
１０．３  スレーブのローカル再試行ルール
それぞれのSlaveは、再試行が使用されなければならない2つの状況を管理する必要がある。
【０２５７】
・  Slaveのローカルスピーカにパススルーされたメッセージに対しスピーカによる応答が行えない場合。
【０２５８】
・  バックリンクを介してSlaveにより(スピーカから)コンソールに送信されたメッセージが無線マスターにより正常に受信されない場合(例えば、スピーカからのPASS_KEY_CODEメッセージ)。
【０２５９】
第1の場合、Slaveは、スピーカへのコンソールのメッセージの即時再試行をローカルで管理する。1回の再試行のみが必須として定義される。ここでもまた、これは、この再試行がスピーカのスケジュールされたローカルポーリングに干渉する場合に受け入れ可能である。
【０２６０】
第2の場合は、バックリンクを介して試行されたメッセージ転送の直後のWirelessマスターからSlaveへのある種の形態のフィードバックを想定する。このようなフィードバックは、次のWireless 20ミリ秒ポーリングサイクルのときに含めるように定義されなければならない。実際に、これは、Wirelessマスターからそれぞれの影響を受けるSlaveへのRequest for Retryの形をとらなければならない。SlaveがこのRequest for Retryを確認した場合、バックリンクを介して情報送信する次の機会に、もう一度、最後のスピーカメッセージの再送に有利になるようにWirelessマスターにポーリング情報を送信することを差し控えなければならない。この再試行メカニズムは、Wirelessマスターにメッセージを届けるために必要なだけ続けることが可能であり、Wirelessマスターの支配下になければならない。ここでは、100ミリ秒(5回の試行)がリミットとして適切である。スピーカポーリングは、再試行状況を通じて続行することができ、これにより、スピーカポーリング情報を更新し(バッファリングではなく上書き)、メッセージを(小さな)キューにバッファリングして、バックリンクを介して送信する次の機会を待つことができる。
【０２６１】
１０．６  Wirelessマスターの一般的な役目
Wireless Masterは、説明されているように、スピーカ/Slavesから受信されたすべてのメッセージおよびポーリング情報による適切な時間内での応答により、実際には、そのスピーカ群にハード配線されているとコンソールに「思いこませる」ことにより、コンソールポーリングプロトコルの条件を満たす。後述のようにいくつかの特定の役目にはこれが欠けている。
【０２６２】
１０．６．１  ローカルで使用するようにスピーカのポーリング応答をバッファリングする
Wireless Masterは、スピーカからの高い優先度のメッセージが保留になっていない場合に、すべての接続スピーカについて、すべてのコンソールメッセージに対する応答としてPoll_Reply (0x80)メッセージを送信する。これらのPoll_Repliesを生成するために、Slavesのローカルポーリングサイクルから得られるバックリンクメッセージをバッファリングし、この情報を使用して、タイミングの制約条件の範囲内で適切な応答をフォーマットする。
【０２６３】
ポーリング情報は同じ状態変数の進行中の更新を表すので、それぞれのスピーカに対するポーリングステータスバッファは、メッセージ1つ分の深さしかなく、さらに新しいデータがスピーカから取り出される毎に絶えず更新される。Wirelessマスターは、与えられたスピーカから無効なポーリング応答データを受信した場合(無効なチェックサムなど)、Wirelessマスターはバッファ内に格納されている(古い)データを使用して、コンソールに応答することになる。Wirelessマスターが5秒以内に与えられたスピーカから有効なポーリング応答情報を受信できない場合、Wirelessマスターはそのスピーカに関連付けられているポーリングステータスバッファを空にし、コンソールによりポーリングされたときに差し控えていた応答を開始する。ONスピーカなどのリストからそのスピーカを削除することはコンソール側の役目である。
【０２６４】
１０．６．２  ポーリング応答の代わりに高優先度スピーカメッセージを使用する
前のセクションで説明したように、スピーカは、コンソールメッセージに対し、保留になっている最高優先度戻りメッセージで応答する(Poll Repliesが既定値として使用される場合)。したがって、これをシミュレートするために、Wireless Masterは、Poll_Replyよりも優先度の高いメッセージが与えられたスピーカからいつ保留になったのかを識別し、そのスピーカに対する次のコンソールメッセージの後に、このメッセージを既定値のPoll_Replyの代わりに使用する。中優先度と高優先度のメッセージが保留になっている場合、高優先度メッセージが最初に送信されなければならない。
【０２６５】
これらの高優先度メッセージをコンソールに渡しても、それぞれのスピーカに対するポーリングステータスバッファを破損しない。高優先度メッセージがコンソールに渡された後、WirelessマスターはPoll_Replyメッセージでの応答に戻らなければならない。
【０２６６】
１０．６．３  高優先度コンソールメッセージの役目
すでに述べたように、Wireless Masterは、すべてのコンソールメッセージに応答する。これは、コンソールメッセージの優先度に関係なく成立する(メッセージ定義を参照)。応答は、すでに説明されている767μ秒のウィンドウの範囲内で開始する。コンソールにいったん応答すると、Wirelessサブシステムでは、高い信頼性の下で中または高優先度コンソールメッセージをスピーカに送出する役割を持つが(再試行の管理を含む)、なぜかというと、コンソール側では、これ以降、それらのメッセージはスピーカによって受信されたとみなし、より高いレベルで再試行を管理できなくなる場合があるからである。
【０２６７】
１０．６．４  クエリ交換時の役目
前のセクションで説明したように、コンソールは、特定のスピーカにクエリを送信すると、応答が返されるまで他のスピーカのポーリングを停止する。その代わりに、応答が保留中であるスピーカを連続してポーリングする。このような状況では、Wireless Masterは、以下のいずれかが生じるまでコンソールのポーリングに対する応答を単に続けるだけである。
【０２６８】
1.コンソール側で、他のスピーカのポーリングをあきらめて、また再開するか、または
【０２６９】
2.クエリ応答が所望のスピーカから抜けてくる。Wirelessマスターは、これに、ポーリング応答よりも高い優先度を与え、したがって、それを次の有効なポーリングに対する応答としてコンソールに転送すべきである。
【０２７０】
１０．６．５  スレーブへの再試行の要求
Wirelessバックリンクはダウンリンクよりも信頼性が劣る場合があるため、Slaveからの高優先度メッセージはWirelessマスターに破損した状態で到着する可能性がある。このような状況では、Wirelessマスターは、メッセージが無傷で転送されるまでSlaveに再試行を継続的に要求することができる。
【０２７１】
他の実施形態は、請求項の範囲内に収まる。
【符号の説明】
【０２７２】
100…オーディオネットワーク制御システム
110…マスターデバイス
112A…スレーブデバイス
112A〜112D…スレーブデバイス
112Bおよび112C…スレーブデバイス
112D〜112F…スレーブデバイス
120…第1の部屋
122…第2の部屋
124…第3の部屋
130…マスターデバイス用のリモートコントロール
132…スレーブデバイス用のリモートコントロール
140…通信プロトコル
200…コンソール
202…制御データバス
204…オーディオインターフェイス
206…Turn On信号
208…ネットワーク接続スレーブデバイス
600…導電性シェル
【図１Ａ】
0005383775.tif 000031
【図１Ｂ】
0005383775.tif 000032
【図２】
0005383775.tif 000033
【図３】
0005383775.tif 000034
【図４】
0005383775.tif 000035
【図５Ａ】
0005383775.tif 000036
【図５Ｂ】
0005383775.tif 000037
【図６】
0005383775.tif 000038
【図７】
0005383775.tif 000039
【図８】
0005383775.tif 000040
【図９】
0005383775.tif 000041
【図１０】
0005383775.tif 000042
【図１１】
0005383775.tif 000043
【図１２】
0005383775.tif 000044
【図１３】
0005383775.tif 000045
【図１４】
0005383775.tif 000046
【図１５】
0005383775.tif 000047