Class 3

きょうは、これまで実は何度か画面ダンプでは示してきたものの、一度もちゃんと説明したことがなかったClass 3問題について触れておくことにします。この問題は、iWRAP4からiWRAP5にアップグレードしたり、SET RESETコマンドにより設定を初期化した後にinfoコマンドを使って確認することができます。




注意しないと見逃してしまうかもしれませんが、Bluetoothのバージョンが3.0になっているのはいいのですが、Class 3になってしまっています。Bluetooth製品としては、普通Class 1とClass 2が市販されており、Class 3製品というのは耳にしないと思います。なぜなら出力が小さくて電波飛ばないからです。Class 2が「10m程度」と言われているのに対してClass 3では「1m程度」しか飛ばないので、通常の製品でわざわざこの出力を選択することもないためです。

この問題は、次に示すように、SET BT POWERコマンドを使って明示的に送信電力を指定することで解決できます。




いろいろと設定をいじっていると、設定をいったんクリアすることが時折あるのですが、ついつい送信電力を設定しなおすのを忘れてしまいます。

送受話器を流用してみる

今年からいよいよMTMがMaker Fair Tokyoに格上げされて開催されるようですね。会場が日本科学未来館というのが個人的には遠くて辛いところですが、前向きに検討したいところです。これまでのMTMは入場無料だったこともあり、性別年齢を問わずにいろいろな人が見に来ていたのが出展する側としてはとても面白かったのですが、その雰囲気が失われないように望みたいものです。18歳以下は半額と考慮されているようなので、大丈夫かな？

さて、出展を考えるとなるとそのためのネタを考えねばなりません。これまでは、昨年デモしたBlueSAMにMMA8452Qを追加しようかと思っていたのですが、外見からは昨年と同じにしか見えないし、何かしら新しいネタを考えた方が良さそうな気がしてきました。WCA-009の販売促進の絶好の機会でもありますので、当然これを使ったネタでなければなりません。そこで基本構想を固める準備実験として、こんなもんこさえてみました。




はい、昨年製作したWCA-009を使ったBluetoothスピーカ・ボードを改造したものです。昨年はスピーカをつなげることを想定していましたが、これを家庭用電話機の送受話器をつなげるように改造してみました。マイク関係回路は昨年のトラ技9月号と同じような回路なんですが、バイアス用のレギュレータを使わずにダイオードの順方向電圧降下を利用して約2.7Vを作ってみました。

これまでは、HFPの実験/デモをするのにパソコン用のヘッドセットを使っていたのですが、なんか普通すぎでイマイチ面白くありません。MTM/Maker Fairのようなイベントでは、どれだけ来客の目にとまり、気を引くことができるかが重要です。そしてわかり易いものの方が多くの観衆の興味を引けるんじゃないかと思います。そこで、電話として使うことだし、家庭用電話機の送受話器部分を使えるようにしてみたというわけです。もちろんウケ狙いも意識していますけど。

	サンワダイレクト iPhone受話器 iPhone4S iPhone4 iPad2 iPad 対応 ホワイト 400-HS028W
	サンワダイレクト
	サンワダイレクト

	ELECOM XPERIA用電話スタンド ブラック MPA-PSX001BK
	エレコム
	エレコム

スマホ用には、上のような製品がいくつか出ているようですが、これのBluetooth版といったとろです。もちろんiPhone/AndroidだけでなくBluetoothが使えればいいのでiPodやガラケーともつなげて使えます。

電話機の送受話器部分ですが、どうやらどのメーカの製品も4極4芯のケーブルで本体とつなげられているようです。4芯のうち外側2本が送話器マイク、内側2本が受話器スピーカーにつながっているというのが配線仕様となっている模様。そこで、外側の2本はアンプを使わずにWT32の左チャンネル出力に直接接続。受話器のように耳元にあてるのであれば、外付けアンプ無しでも充分な音が出せます。RJジャックの手持ちがなかったので、近場の家電量販店でカールコードを買ってきて半田付けしました。スピーカ/マイクとも極性があるわけですが、スピーカの極性は無視できます。一方、送話器部分にはコンデンサマイクが使われており、バイアス電圧をかける必要があるのですが、2本の端子のうちのどちらがプラス側なのかわかりません。自宅にあった電話機2台の送受話器を試してみたのですが、極性が逆になっていました。ふつう自社製の電話機本体にしかつながりませんので、極性を含めた端子割り当てまでは共通化されていないんでしょうか？　今回は実際につなげて動作確認をとりながら半田付けしましたが、受話器の種類を選ばずに接続可能とするためには極性反転スイッチを付けた方が良さそうです。

実際に動かしてみると、通話時にマイクにキーンというノイズが載ってしまいます。やっぱりバイアス電圧生成にはレギュレータ使った方が良いようです。相手側音声の聴取にはまったく問題ありませんが、着信応答や切断操作ができるフックがあるわけではないので、そこんとこはスイッチ使う必要があります。あとは、着信音鳴らすためのスピーカが無いことが大きな問題でしょうか。着信音の生成はWT32で行えるのですが、その着信音は受話器から流れてしまいます。着信が入ったらスピーカを鳴らして、応答したらスピーカ動作を止めることが望ましいのですが、そこまでやるとなるとマイコン使って制御したくなります。

送受話器が使えることは確認できたので、次のステップとして、スピーカとRJジャックを付けてもう少し実用的にしてみようかと思います。

	トランジスタ技術 (Transistor Gijutsu) 2011年 09月号 [雑誌]
	CQ出版
	CQ出版

iWRAP 5.0リリース

長らくベータが続いていたiWRAP 5.0ですが、先週 火曜日にRC6が出たと思ったら、続いて金曜には正式リリースとなったようです。User Guideも 5.0.0用が公開されましたが、Application Noteの更新はまだこれからのようです。そんな事情もあっってか、先週はなんの公式アナウンスもありませんでした。そろそろ正式にアナウンスがあるでしょう。

さて、iWRAP 5.0ですが、これまでのiWRAP 4.0とは大きくことなる点がいくつかあります。そのおもだったものを列挙しておくことにします。

• ライセンスキーが必要となった
  なんといっても一番大きな違いがコレ。ライセンスキーが無いと、ファームウェア自体は動き始めるものの無線部分が動作しないため電波の送受信ができません。ライセンスキーはsupport@bluegiga.comに連絡すればもらえますので、これを新たに用意されたlicenseコマンドを使って入力してやります。
• 複数のファームウェアイメージから用途に応じて選択
  以前にも紹介したことがありますが、オーディオ送信側(A2DP source/HFP AGW)か受信側(A2DP sink/HFP HF unit)かに応じて使用するイメージを選択する必要があります。コードが大きくなってフラッシュに入りきらなくなったのでしょう。
• iAPサポートは別イメージ
  同様にAppleのiAPに対応するファームも別イメージとして提供されます。ただしイメージの提供を受けるにはAppleのMFIプログラムに参加していることが条件ですので、一般アマチュアユーザには関係の無いところです。iAPを実際に使うためには、MFIに参加したうえでAppleから認証チップを購入して接続する必要があります。Appleってこういうライセンスビジネスもしっかりしていますよね。
• HDPはWT32ではサポートされない
  これもサイズが原因でしょうか。ちょっと残念。

ライセンスキーの入力には、licenseコマンドを使う以外にも、PSTOOLをつかったり Serial DFUで指定する方法もあるようですが、licenseコマンドを使うのが一番簡単なようです。

iOS5とHFP 1.6

Android 4.0でHFP 1.6がサポートされていないことがわかってガッカリしていましたが、今頃になってiOS5がHFP 1.6に対応していることを知りました。いままでもどこかで情報を目にしていたのかもしれませんが、iWRAP5側が対応していなかったため気に留めていなかったのかもしれません。

カミさんのiPod Touchを使ってつなげてみるとこうなりました。

余分なメッセージが出ないように、WT32側ではHFPのみをイネーブルしています。iOS5ではFaceTimeが Bluetooth対応したために、Bluetooth接続するとHFP接続ができます。

HFP 1.6らしいところは、最初のHFPのイベントメッセージが HFP 0 CODEC NEGOTIATIONとなっていることでわかります。これまではHFP 1.5だったので使用できるCODECはCVSDだけだったのですが、両者がHFP 1.6対応になったことでCVSDとmSBCをネゴして使えることを示すようになったようです。しかしながら実際にFaceTimeで着信を入れてみるとCODECとしてはCVSDが使われてしまいます。うーん、残念。残念ながらiWRAP5とiPod Touech側のどちらが悪いのか調べるすべを知りません。あるいはFaceTimeがそもそも16K音声対応していない可能性もあるかもしれませんね。

iPod TouchでFaceTimeを使う場合にはメールアドレスと紐づけて使いますが、Apple側では擬似的な電話番号を割り当てているらしく、CALLERIDとして見えるのが興味深いところです。でも、これではヘッドセット側ではメールアドレス表示できませんね。もう一つ気になるのは、HFP 0 STATUS "service" 0 となっていること。ネットワークサービスダウン状態なのに、いきなり着信入ってくるんですけど。。

MBAも先日 MacOS X 10.8 Mountain Lionに上げていたので、念のために確認してみました。同じくFaceTimeで着信いれてみました。

こちらはHFP接続した段階でCODECとしてCVSDが選択されてしまっています。確認しましたが、HFPのプロファイルバージョンは1.5のままでした。しかし、ちゃんと STATUS "service" 1が出ており網側サービスが利用可能なことが通知されています。ネットワークがAPPLEになっているのもちょっと面白いところです。しかしながら、着信入れても発信者番号の通知は出ていません。

Mountain LionになってさらにiOS5との統合が進んでいると言われていますが、Bluetoothに関してはまだまだ動作に細かな違いが残っているようです。

HFP-AGを使ううえでの注意点

いただいた質問に答えていると、自分でもとても勉強になるものです。今週はHFP-AGとして使う際の動作について質問を受けたのですが、自分の使っているヘッドセット(MW600)では経験したことのない問題が、使用する機種や設定によっては発生することを確認することができました。

HFP-AGとしての使用例については、もう２年ほど前にこの記事で触れています。MW600を使ううえでは、この設定で何の問題もないのですが、一般的にはこれでは２点ほど設定が足りません。

まずひとつは、statusコマンドによる網側サービスの状態通知です。WT32のHFP-AGが接続された状態では、WT32はHFPユニット側に対して何のネットワーク状態通知も出しません。そのため、ヘッドセットによっては網側サービスは利用できない状態であると解釈し、着呼や発呼の制御を受け付けないようです。この問題を避けるためには、HFP-AGの接続後HFP-AG側で

status service 1

コマンドを実行することで、明示的に網側サービスが利用可能であることをヘッドセット側に通知してやります。

もうひとつの問題は、呼び出し音の制御です。HFP-AG側でringコマンドを実行すると、WT32はすぐにHFPユニット側にSCOリンクを張りにいきます。これはHFP-AG側で生成する呼び出し音をHFPユニット側に送出することを可能とするためです。しかしながら、ユニット側では自分で呼び出し音を生成する機能をもっており、SCOリンクからの呼び出し音を流さないかもしれません。WM600ではそのように動作しました。これは、HFP-AG側が呼び出し音を生成することを明示的にユニット側に通知していないために生じます。呼び出し音送出を明示的に通知するためには、

+BSIR:1

コマンドをHFP-AG側で実行してやります。逆にインバンドでの呼び出し音送出ができない場合には、

+BSIR:0

を送出してやります。実際に+BSIR:1を実行してやるとWM600は自機での呼び出し音生成をしなくなりました。

ちなみにBluegigaのAP Noteでは、この通知は++BSIRとして説明されていますが、間違いです。元資料であるHFP 1.5を確認してみると、そちらでもタイポになっていましたので、そのままコピペしたために間違っているようです。ちなみに、HFP 1.6ではこのタイポは修正されていました。

PAGEMODEとペアリング

WCA-009を購入いただいた方から質問を受けたので、きょうはペアリングに関連してPAGEMODEとPIN番号の設定について説明しておくことにします。

Bluetoothでは接続に先立って、通常接続するデバイスを互いに認証しておく必要があります。その手順はペアリングと呼ばれ、片方の側(デバイスA)からもう片方(デバイスB)へ接続をおこなうために、つぎのような一連の手順を踏みます。

1. まずデバイスB側を他のデバイスから発見可能な状態に遷移させます。デバイスによってはペアリング受付可能状態とも呼ばれます。
2. デバイスA側からデバイスの検索をかけます。近隣にある自分とつながりそうなデバイスとその名前を見つけます。
3. 見つかったデバイスのリストのなかからデバイスBを選択して、ペアリングあるいは接続動作を試みます。
4. デバイスB側からPIN番号の要求を受けるので、デバイスBの持つPIN番号をデバイスA側で入力します。
5. ペアリングあるいは接続動作が終了します。
6. 必要に応じてデバイスB側の発見可能な状態を解除。

それでは、これらの手順と対応するWT32の設定ならびに操作について説明していくことにします。最初に自分を他のBluetoothデバイスから発見可能な状態にせねばなりません。この設定は SET BT PAGEMODEコマンドでおこないます。WT32のディフォルトでは、

SET BT PAGEMODE 4 2000 1

となっています。この設定では、Bluetooth接続がない状態ではWT32は他のデバイスから発見可能な状態にありますが、接続ができると発見できない状態になります。単一デバイスとの接続であれば、ユーザにペアリング受付可能モードを意識させない都合の良いモード設定というところでしょうか。ただし、この設定ではいったんひとつのデバイスと接続されると、他のデバイスからの接続は受付ないようになります。したがって、音楽プレーヤと接続した状態で、携帯ともつなげようとしてもつながらないという問題が発生します。

SET BT PAGEMODE 3 2000 1

という設定に変更してやれば、常時発見可能/接続可能な状態になります。Bluetooth用語で言えば、Inquiry scanとpage scanの両方を行う状態です。しかし、この状態では常時見え見えの状態なので、セキュリティや消費電力の観点からは必ずしも好ましい状態ではありません。そこで、いったんペアリングができれば、以後は

SET BT PAGEMODE 2 2000 1

に設定変更するのが好ましい使い方と言えます。Bluetooth用語で言えば、Inquiry scanは行わないが、page scanは行うという設定です。この状態では発見はできませんが、すでにペアリングを終えBluetooth Device Addressを知っているデバイスからの接続受付は可能だからです。

近隣デバイスを検索するには、inquiryコマンドを用います。

このコマンドで近隣で発見可能なデバイスのBluetooth Address(BD ADDR)とそのClass of Device(COD)を知ることができます。またnameオプションを指定することで、対応するデバイス名を調べることができます。上述のように他のデバイスからのinquiryの要求を受け付けるためには、PAGEMODEを適切に設定しておく必要があります。CODの設定は、SET BT CLASSコマンドで設定することができます。装置によってはCODでフィルタをかけることで、特定のクラスに属するデバイスのみを検索して表示するものがあります。このような場合には、PAGEMODE設定で発見可能になっていても、CODが適切に設定されていないと発見してもらえないという現象が発生しますので、注意が必要です。

ペアリングには自動的にPIN番号を生成するSSP(Simple Secure Pairing)という機能も用意されていますが、ここでは静的にPIN番号を設定する方法について紹介しておきます。具体的には、

SET BT AUTH * 1234

とすることでPIN番号として1234を指定することができます。次に示すようにこの設定は、相手側から送られる自分のPIN番号確認にも使われますし、相手側に対して送出するPIN番号としても使われます。

• ヘッドセットのようなデバイスを作る場合には、この設定だけで充分です。スマホやパソコンからデバイスの登録をおこなうと、PIN番号を聞かれますのでスマホ/パソコン側で設定した番号(ここの例では1234)を入力すればペアリングが完了します。
• 音楽プレーヤのような装置を作る場合には、検索して見つけた相手デバイスに対してペアリング操作を行う必要があります。

  PAIR bdaddr

  とすることで指定したアドレスのデバイスとペアリングすることができます。この際に必要となるピン番号にはSET BT AUTHで指定してある番号が使用されます。
• PAIRコマンドを用いて明示的にペアリングをおこなわなくても、CALLコマンドを使って相手側に接続を試みると、必要であれば自動的にペアリングをおこなってくれます。この時にもSET BT AUTHで指定したピン番号が使用されます。

それでは、ペアリング操作の実例を示しておきましょう。まずは、PAIRコマンドを使う例から。SET BT AUTHの設定がない状態でPAIRコマンドを発行しても相手に伝えるPIN番号情報がないので失敗します。SET BT AUTHでPIN番号設定してからPAIRコマンドを出すことで、ペアリングに成功しています。


次の例では、CALLコマンドで接続する際に自動的にペアリングできることを示しています。SET BT PAIR *でいったん全てのペアリングを解除しているのですが、その後のCALLコマンドで接続できているのは自動的にペアリング動作が行われているためです。


インタラクティブなペアリング
さて、上記の方法ではSET BT AUTHコマンドを使うことで、PIN番号を固定的に指定しています。しかし、オーディオ・プレーヤに複数のヘッドホンをペアリング登録したいような場合には、デバイス毎にPIN番号が異なっている可能性があります。このような用途では、コマンドで固定的にPIN番号を指定するのではなく、ペアリング操作時にインタラクティブに番号を指定できた方が便利です。WT32でもそのための機能が用意されています。以下に、その例を示します。

• まず、SET CONTROL CONFIGコマンドで bit 11をセットすることにより、認証要求のイベントを表示するように設定しておきます。
• すると、PAIRやCALLコマンドを出したときに、AUTHイベントが表示されるようになります。
• AUTHコマンドを使って、相手側のPIN番号を返してやります。
• SET CONTROL CONFIGコマンドでビット7がセットされていれば、ペアリング成功時にはPAIRイベントが表示されます。

上の例では1回目のピン番号の入力をわざと間違えてみました。その結果として、PAIRコマンドが失敗したことを示すイベントが出ていることに注意してください。正しいPIN番号を入れるためには、例のようにPAIRコマンドからやり直す必要があります。もちろん、CALLコマンドを使った場合にも同じようにAUTHコマンドでPINを入力することができます。

期待と現実

先週、Android 4.0でHFP 1.6がサポートされていないことを確認して、ガッカリさせられましたが、Galaxy S3のHFP関連ではAT+CCLKコマンドもサポートされていないことも確認。なんとATI0コマンドすらサポートされていない!!??

すでにこのブログでも何度かとりあげていますが、このコマンドがサポートされていれば電話機側からdate/timeを取得して自機側の時計を設定することができます。これまでに何種類かの携帯電話やAndroidスマホと接続を試したことがありますが、いまだに iPhone/iPad touch以外でこのコマンドをサポートする端末に出会えていません。Galaxyくらいにグローバルな端末だったらサポートされているだろうと期待を抱いていたのですが、現実はそんなに甘くありませんでした。せっかく端末買ったのに、WT32の機能デモに活用できないではありませんか!! 現状であれば、Bluetoothデモ用にはiPhoneがベストな端末ですね。Jerry Beanに期待しようかな？でも、期待はずれに終わるかな。

6月にはiWRAP5も正式リリースの予定だったのですが、こちらも遅れているようです。今週、iWRAP5.0.0 rc1がリリースされて、正式リリースまではあと少しのようです。さて、このiWRAP5ですが、当初の計画とはちょっと違ってきてしまった部分もあるようです。

• PIOにつなげたスイッチの長押しが検出できる計画だったが、実装取りやめになった。
• WT32ではHDPはサポートされないことになった。

βコードでHIDが動かない問題を見つけて報告してあるのですが、アチラでは修正したと言っているのに、こちら側では修正を確認できずちっとも動きません。どうしてむこうでは問題が再現しないのか、不思議なくらい。もともとメモリが不足気味のWT32ですので、HIDのサポートも打ち切りにならないかとヒヤヒヤしています。

Galaxy S3とメディア・プレーヤ

ひとさまから遅れること何年かにして、ようやくとスマホデビューしました。購入した端末は累積販売台数1000万台とかで話題のGalaxy S3 SC-06Dです。この端末、Android 4.0対応しているだけでなく、Samsungが独自にAVRCP 1.3に対応しているらしいとの情報があったために選択しました。iPhone以外でAVRCP 1.3機能がまっとうに使える数少ない端末であると見込んで購入したのにもかかわらず、曲名等のメタデータをWM600やBlueSAM上で表示できないという問題に遭遇しました。きょうは、その顛末の報告です。

まずは、現在のAndroidにおけるAVRCPプロファイルサポートに関する背景を簡単にまとめておきましょう。AndroidはLinuxベースであり、そのBluetooth機能についてはBlueZプロジェクトの成果を取り入れたものがベースとなっています。このブログ記事の説明によれば現行の4.0 ICSで使用されているBlueZのバージョンは4.94であり、そのAVRCPサポートはプロファイルバージョン1.0のようです。AndroidにおいてAVRCP 1.3がサポートされるのは、次の4.1 Jerry Beanになるようです。しかしながら、これは素のAndroid環境を用いた場合の話であり、自分で機能強化を行えばもちろん4.0 ICS(あるいはそれ以前の版)でもAVRCP 1.3対応することは可能となります。実際にシャープ製の端末では、IS01のころからAVRCP 1.3対応しているようですし、世の中には勝手ROMでAVRCP 1.3対応しているものもあるようです。

Galaxyの場合も同様にSamsungが独自にAVRCP 1.3に対応しているらしく、こちらの記事によればGalaxy S2でメタデータの送信ができているとの報告があります。この情報からわたしはS３においても当然同様の機能がサポートされているに違いないと確信したわけです。このようにベンダーが独自に機能拡張をおこなっている場合には、ベンダーが提供するMedia Playerを使用しないとその機能は利用できない可能性があります。他の評判のいいプレーヤがあっても、端末ベンダが提供する拡張APIに対応していなければメタデータ送信はできないからです。

ここからは実証編です。まずはAVRCPのプロファイル・バージョンを確認してみます。別のUbuntuマシン上からsdptoolを使ってSC-06DのSDP情報をbrowseしてみた結果です。

Browsing 0C:71:5D:10:85:1E ...
Service RecHandle: 0x10000
Service Class ID List:
  "PnP Information" (0x1200)
Profile Descriptor List:
  "PnP Information" (0x1200)
    Version: 0x0102

Service Name: Audio Source
Service RecHandle: 0x10001
Service Class ID List:
  "Audio Source" (0x110a)
Protocol Descriptor List:
  "L2CAP" (0x0100)
    PSM: 25
  "AVDTP" (0x0019)
    uint16: 0x102
Profile Descriptor List:
  "Advanced Audio" (0x110d)
    Version: 0x0102

Service Name: AVRCP TG
Service RecHandle: 0x10002
Service Class ID List:
  "AV Remote Target" (0x110c)
Protocol Descriptor List:
  "L2CAP" (0x0100)
    PSM: 23
  "AVCTP" (0x0017)
    uint16: 0x103
Profile Descriptor List:
  "AV Remote" (0x110e)
    Version: 0x0103

Service Name: Voice Gateway
Service RecHandle: 0x10003
Service Class ID List:
  "Headset Audio Gateway" (0x1112)
  "Generic Audio" (0x1203)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 11
Profile Descriptor List:
  "Headset" (0x1108)
    Version: 0x0102

Service Name: OBEX Object Push
Service RecHandle: 0x10004
Service Class ID List:
  "OBEX Object Push" (0x1105)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 12
  "OBEX" (0x0008)
Profile Descriptor List:
  "OBEX Object Push" (0x1105)
    Version: 0x0100

Service Name: OBEX Phonebook Access Server
Service RecHandle: 0x10005
Service Class ID List:
  "Phonebook Access - PSE" (0x112f)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 19
  "OBEX" (0x0008)
Profile Descriptor List:
  "Phonebook Access" (0x1130)
    Version: 0x0100

Service Name: Voice Gateway
Service RecHandle: 0x10006
Service Class ID List:
  "Handsfree Audio Gateway" (0x111f)
  "Generic Audio" (0x1203)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 10
Profile Descriptor List:
  "Handsfree" (0x111e)
    Version: 0x0105

AVRCP Protocol Descriptor内のVersionが0x0103になっていることから、バージョン1.3になっていることが確認できます。Androidのアプリケーション管理で実行中プロセスを見てみると....



明らかにSC-06DではSamsung独自のAVRCPサービスが走っていますので、このサービスがAVRCP 1.3に関連した機能を提供している可能性があります。Samsungが提供するプレーヤでは、このサービスを介してメタデータを送信することができるのではないかと推測されます。

ところが実際にSC-06Dにインストールされている「メディアプレイヤー」を使ってWT32でAVRCPの動作を確認してみると。。



メタデータを要求しても、拒否されてしまいます。場合によっては、拒否はされなくてもデータとしてヌル文字列が返される場合もあるようです。orz


この「メディアプレイヤー」ですが確認してみると、上図のようにDoCoMo提供になっています。Samsungの純正プレイヤーだと思っていなのですが、違ったようです。あるいは、実際の開発はSamsungだけど開発費DoCoMo持ちのためドコモ提供になっているだけ？いずれにしても、動作検証はDoCoMoの責任ですよね。このメディアプレイヤーがちゃんとメタデータ送信に対応できていないんじゃないでしょうか？　良く見てみるとSC-06Dにはもうひとつ音符アイコンに「音楽」と記したアプリが用意されており、こちらもプレイヤーになっているようです。




こちらのプレイヤーを使うと正常にメタデータが送信されるようになりました。



日本語文字列の送信も問題ないようです。SonyのWM600とつないでもちゃんと曲名が表示されます。つまり、ドコモ純正の「メディアプレイヤー」がダメダメじゃん!! というオチだったのです。


このようにAVRCPを使うアプリの機能仕様は、残念ながらAndroidのバージョンだけでは判断できません。Androidは共通プラットフォーム機能を提供してはいますが、各ベンダは差別化のためにサービスやライブラリのレベルで機能仕様を強化して、それに対応したアプリを用意しているかもしれません。これら３つの層が正しく協調動作してくれないと期待した機能を提供してくれないことになります。ドコモ純正プレーヤは、良くできたSamsungの下位層をちゃんと使いこなせていない悪いお手本になっていたようです。次のJBでは、すべての層がGoogle提供のもので統一されることにより、このような問題が無くなれば良いのですが。。。

	SONY ソニーエリクソン Bluetoothワイヤレスヘッドセットマイク付き ブラック MW600/B
	ソニー
	ソニー

2012-07-03 10:52:30 追記
「音楽」と表示されるプレイヤーアプリはGoogle標準プレイヤーなのですね。つまり標準プレイヤーだとAVRCP 1.3に対応できて、DoCoMo純正プレイヤーでは対応できていないという当初予想とは真逆の結果になっているようです。APIの仕組みの都合でしょうか。
AvrcpServiceSamsungは、プレイヤーから受信したメタデータをキャッシュしており、Bluetooth経由での要求があった際にそのデータを送信しているようです。そのため、最後に標準プレイヤーで再生した曲のデータを保持しており、そのあとでDoCoMo純正プレーヤーで再生をすると、キャッシュされていたデータを送信します。そのため、純正プレイヤーを使用していると再生されている曲とは違うメタデータが表示され、しかも曲送りをしてもデータが変化しないという症状を引き起こすこととなります。

ヌンチャクでGoogle Earthする -- デモ編

前回記事の続きです。今度は実際の動作を。



WCA-009を使ってBluetooth化されたヌンチャクを実際にGoogle Earthで使ってみました。今回のデモでは、Mac Book AirでMac版のGoogle Earthを使っていますが、Windows版でも全く同じように使えます。せっかくなので大画面で見てみようということで、Mac Book AirをHDMIでテレビと接続してみました。使用した変換ケーブルはこれです。

	ELECOM miniDisplayPort変換アダプタ forAPPLE HDMI ホワイト AD-MDPHDMIWH
	エレコム
	エレコム

前回記事に書いたように、ヌンチャクの動作にはマウス・モードとナビ・モードのふたつがありますが、デモ動画で見せているのはナビ・モードの方だけです。やっていることは単純にスティックや本体が一定以上傾いたならば、対応するキーボードのコードにマッピングしてHIDレポートを出力しているだけです。傾き具体に応じてキーのリピートレートを変えるというような処理は一切なし。それでも、結構楽しめます。普段ノートPCしか使わない人なので、大画面で見る事がそもそも新鮮で楽しめます。

無線化されていますので、実際に使用する際にはMacはテレビのそばにおいたままで離れた位置からヌンチャクでの操作がおこなえます。なかなかいい感じですが、やはりマウス・モードとナビ・モードの切り替えがちょっと煩わしいです。使い心地改善のためには、ズーム操作に必要な傾斜はもう少し調整した方が良さそうです。

ヌンチャクでGoogle Earthする -- 準備編

さてWCA-009(WT32)を使えばヌンチャクをBluetooth HDIマウス/キーボード化することは簡単にできます。今回製作したボードの構成は次のようになっています。



マイコンのソフトでは、I2Cでヌンチャクからのデータを読み取り、その内容に応じて適切な疑似マウス/キーボードのイベントをHIDのレポート形式で送信してやるだけです。マイコンからはUARTを使ってデータを送信してやれば、あとはWT32がBluetooth無線化してくれます。パソコン側では、Windows XP, Windows 7, MacOSいずれもBluetooth HIDのドライバはあらかじめ用意されていますので、追加でドライバをインストール必要もありません。

それでは実際にどのようなアプリを使うかですが、わたしがやってみたかったのはGoogle Earthです。PC向けゲームソフトとか持っていないので、他にジョイスティックがあれば便利そうなアプリを思いつかないだけのことなのですけど。老眼と乱視の影響かゲームのような動きの激しい画面を見続けていると、酔ってしまい頭痛が襲ってきます。時には気持ち悪くなって横になりたくなるくらいです。これが眼精疲労ってやつでしょうか? Google Earthでも20分くらい遊んでいると頭痛がしてくるので要注意です。

Google Earthにはフライトシュミレーターの機能もあり、マウスやジョイスティックで操作することができるようになっています。しかし、慣れないわたしはうまく操縦できません。ゆっくりと動かして景色みたりするのであれば、普通にGoogle Earthを使うだけの方が良さそうです。

今回はジョイスティックではなくマウス/キーボードを疑似することになりますので、ヌンチャクの操作に応じて、適切なマウスあるいはキーボード操作に対応するHIDのレポートを出力する処理が必要となります。HIDの規格ではキーボードに対応するModifierやUsage IDが規定されていますので、キーの押下を表現するには対応するUsage IDを含むレポートを送出することになります。実際のヌンチャクの操作とGoogle Earthの動作の対応付けと、それに伴いHIDで送信する内容は、次のようにすることにしました。

まず、動作モードとしてマウス・モードとナビ・モードの２つを設けます。マウス・モードでは1ボタンのマウスの動作を疑似し、HIDマウスのレポートを生成/送信します。

ヌンチャク操作	マウス動作	HID動作
スティック上	カーソル上へ移動	Y-step(正)
スティック下	カーソル下へ移動	Y-step(負)
スティック左	カーソル左へ移動	X-step(負)
スティック右	カーソル右へ移動	X-step(正)
Zボタン	左ボタン	左ボタン
Cボタン	ナビ・モードに遷移	N/A

Cボタンを押すとモードが変わります。ナビ・モードではGoogle Earthの3Dナビゲーション制御に必要なキー操作を疑似するためのHIDキーボードのレポートを生成/送信します。

ヌンチャク操作	Google Earth動作	HID動作
スティック上	上へ移動	UpArrow (0x52)
スティック下	下へ移動	DownArrow (0x51)
スティック左	左へ移動	LeftArrow (0x50)
スティック右	右へ移動	RightArrow (0x4f)
Zボタン+スティック上	下に傾斜	Left Shift+UpArrow (0x52)
Zボタン+スティック下	上に傾斜	Left Shift+DownArrow (0x51)
Zボタン+スティック左	時計回りに回転	Left Shift+LeftArrow (0x50)
Zボタン+スティック右	反時計回りに回転	Left Shift+RightArrow (0x4f)
下へ傾ける	ズームイン	PageUp (0x4b)
上へ傾ける	ズームアウト	PageDown (0x4e)
Cボタン	マウスモードに遷移	N/A

ナビ・モードではキーボードを疑似しているので、上下左右の方向キーに対応するキーコードを生成することで移動はできても、斜め方向に移動することができないのが使いづらいところです。斜め移動のためには、マウスモードに遷移してグラブ動作(Zボタンを押しながらスティック操作)が必要となります。

こうして用意した疑似マウス/キーボードのデータは、つぎのフォーマットでWT32に送信してやることでBluetoothで無線化されます。

最初の0x9fで以降のデータがレポート形式で示されるRawデータであることを示します。その次のバイトはデータ長を示しています。0xa1の次の１バイトがマウスとキーボードを識別するレポートIDになっているようです。キーボードでは最大６つのキー状態変化を送信することができます。シフトキーの状態は、Modifierバイトの該当ビットで通知します。



上の写真ではWCA-009の下側にLEDが3つありますが、これらは現在の動作状況を表すのに用いています。

• 緑LED -- 未使用
• 赤色LED -- ナビ・モードで点灯
• 青色LED -- Bluetooth接続されると点灯

調べてみると同じような機能を提供できる製品としてはZeemoteというものがあるようです。ざっと見たところではSPPを使ってAndroidスマホでゲームする人を意識した様子。HIDも使えるので疑似マウス、キーボードもできるようですがあらかじめ用意された動作モードにはGoogle Earth向きのモードは無いように思われます。ジョイスティックを疑似するモードではSPPを使っておりHIDではないので、「PC用」と言わずに「スマホ用」としているのでしょうか？

	iBUFFALO Bluetooth2.1対応スマートフォン用ゲームコントローラーブルー/ブラック「ZeemoteJS1」 BSGPJS1
	バッファロー
	バッファロー

計画していた動作はできるようになりました。写真ではわかりにくいので、動画を用意するつもりです。