HIDマウスを作る -- その2

WCA-009で作るBluetoohマウスのソフト編です。まずはWCA-009の設定から。

SET BT BDADDR 00:07:80:4b:bb:ca
SET BT NAME WT32-A
SET BT CLASS 000580
SET BT IDENT BT:47 f000 4.0.0 Bluegiga iWRAP
SET BT LAP 9e8b33
SET BT PAGEMODE 4 2000 1
SET BT PAIR 04:0c:ce:e2:9c:f7 94666d1b9b40cf2e9b139e402ef1787f
SET BT POWER 4 4 4
SET BT ROLE 0 f 7d00
SET BT SNIFF 0 20 1 8
SET BT SSP 3 0
SET BT MTU 667
SET CONTROL AUDIO INTERNAL INTERNAL
SET CONTROL BAUD 115200,8n1
SET CONTROL CD 00 0
SET CONTROL CODEC SBC JOINT_STEREO 44100 0
SET CONTROL ECHO 5
SET CONTROL ESCAPE 43 00 1
SET CONTROL GAIN 8 8
SET CONTROL MICBIAS b 0
SET CONTROL MSC DTE 00 00 00 00 00 00
SET CONTROL PREAMP 1 1
SET CONTROL READY 00
SET CONTROL VREGEN 1 00
SET PROFILE HID HID
SET

iWRAP4では、HIDデバイスとしてキーボード、マウス、あるいはその複合でバイスを作ることができますが、基本的な機能のデバイスしか実現できません。詳細を説明したドキュメントが無いのですが、例えばマウスではボタン３つの基本的なマウス機能を提供するだけで、ホイール機能は実現できないようですし、キーボードについてもLEDによるロック状態表示を持たせることはできません。このあたりの機能がちゃんと追加されたWT32用のiWRAP5βが提供されるのを待っているのですが、まだ連絡が入りません。そこで今回の実験では、iWRAP4をつかってX, Y座標の変化のみをレポートすることで、画面上でマウスカーソルの表示が移動することを確認するこ実験を行ってみました。

WT32のApplication Noteの説明のとおりに、Raw形式でMouse reportを出力してみたのですが、マウスカーソルは全く動いてくれませんでした。WT32に対して送信したASCII文字はBTキーボード入力として認識されるので、Raw形式で送信しているMouse reportが正しく認識されていないようです。そこで、Mouse reportの出力形式を次のように修正してやると、マウスカーソルが動くようになりました。

0xa1	0x02	buttons	x-step	y-step

ジョイスティックの傾け具合に応じて、レポートで出力するXとYの変位の大きさを変化させるのですが、大きな値を出すとマウスカーソルが大きく飛んでしまいます。違和感無く使えるようにするためには、レポートの送信間隔とともに調整してやる必要がありそうです。

こんなことをやっているうちに、注文してあったヌンチャクアダプタが届いてしまいました。今後のHDIの実験にはヌンチャクを使うようにしてやろうかと思います。

HIDマウスを作る

先日iWRAP5 βのHIDがちゃんと動かないことがわかってガッカリさせられたのですが、そうとわかるといよいよもってHID機能を試してみたくなりました。これまでHIDキーボードを簡単に試したことはあっても、HIDマウスを試したことはなかったので、iWRAP4でこれを試してみることにしました。ハードと基本ソフトを準備しておけば、パッチが出た時にすぐに試してみることができますし。実験材料を探していたところ、千石でSparkfunのアナログジョイスティックを扱っていたので、購入。SAM3-H256とつないでみました。




購入してから気がついたのですが、このスティックの押しボタンは、スティックがセンター位置にある状態でないとうまく押せないのですね。ボタンひとつの疑似マウスに仕立てようと思っていたのですが、この仕組みだとドラッグ操作ができないことになってしまいます。うーん、イマイチだなぁ。他の人はどうしているかと思って調べてみると、Wiiのヌンチャクを使うのが定番のようですね。もっと早くに気がつけば良かった。今回はこのスティクを使うことにして、ヌンチャク用アダプタを買っておくことにしました。

ハードウェアはいたって簡単。WT32をシリアルでつないで、ジョイスティックのVRをSAM3S4BのADCにつないだだけ。ボタンはいまのところ未接続。これだけなので、SAM3S4Bをつかうまでもなく、安価なAVRとかで用が足りるわけですが、AVR用の書き込み器も持っていない自分にとってはSAM3-H256が一番使いやすくて手頃な実験用マイコンボードです。実験目的ならSAM3S4Aでもだいたいの用が足りるし、USBコネクタはミニBにしたいという気持ちもあるので、自分の実験用に基板を作っておくのも悪くないと考え始めています。

バグ出し

先日、iWRAP5のBATTコマンドの動作でしばらくはまりましたが、後ほど確認してみるとリリースノートのKnown Problemにはこの問題は書かれていませんでした。ベータのリリースからしばらく時間もかかっているので、すでに既知となっている問題だろうと思いつつも、基本的なコマンドがちゃんと動いていないという状況に若干の不安を覚えて一応レポートを送っておきました。翌日すぐに返事があり、やはり既知だったとのこと。

BluegigaではTech Forumからβ版を配布していますが、新しいビルドを作成してもForumにはアップしてくれないようです。Forumとはいってもユーザ相互の情報交換の場が用意されているわけでもないので、他のユーザがどんなバグを見つけているかもわかりません。そんなわけで、見つけたバグは片っ端から報告しておいた方が良さそうです。今週はHIDプロファイルが全く動かなくなってしまっているというバグに遭遇。メモリ不足のエラーが出ます。

set profile hid d 80 100 0 en 409 BT Mouse
hid set 3c 05010902a1010901a1008501050919012903150025019503750181020501093815f1250f9501750581060501093009311581257f750895028106c0c0

reset

!!! THIS IS BETA RELEASE AND MAY BE USED FOR EVALUATION PURPOSES ONLY !!!

WRAP THOR AI (5.0.0 build 518)
Copyright (c) 2003-2012 Bluegiga Technologies Inc.
:ERROR:NOMEM
READY.
hid get
NOMEM 0

この問題はまだ報告がなかった様子。WT11やWT41など他のモデルではちゃんと動いており、問題が発生するのはWT32だけだったようです。他のモデルとちがってWT32ではHFP/A2DPをサポートするために、メモリの消費量が多くなっており、このようなメモリ不足が発生する危険性が高いようです。HIDがちゃんと動くようになったら、ジョイスティックを試してみようかと目論んでいます。

同時２通話の接続

WCA-009が搭載するWT32の特徴のひとつに、複数のデバイスと複数のBluetooth接続をおこなえるマルチリンク、マルチポイント接続機能があります。単に複数のリンクを扱うだけであれば、音楽プレーヤと接続して用いるBluetoothヘッドフォンのような用途ではステレオ音声のリンクを扱うために必須の機能でもあります。これに加えて、携帯電話の通話にも使うためには、音楽プレーヤと携帯電話の双方とペアリングを行い、同時にA2DP/AVRCPとHFPの接続を保持できる必要があります。

このように複数のデバイスと異なるプロファイルで接続することが可能なのですが、複数のデバイスと同一のプロファイルで接続することもできます。例えば、携帯電話を２つ接続することもできます。

list
LIST 2
LIST 0 CONNECTED HFP 667 0 0 71 8d 8d 5c:9a:d8:c4:49:5f 3 INCOMING SNIFF SLAVE ENCRYPTED 0
LIST 1 CONNECTED HFP 667 0 0 34 8d 8d 00:16:97:25:9f:48 3 INCOMING SNIFF MASTER ENCRYPTED 0

上の例のように２つの携帯をつなげたとしても、WT32の音声インタフェースはひとつしかありませんので、通常は片方の端末としか通話はできません。片方の端末で通話中に、もう片方の端末に着信があったとしたならば、着信を拒否しないといけないわけですが、着信を受けてしまったらどうなるんでしょうか？実際に試してみました。

list
LIST 3
LIST 0 CONNECTED HFP 667 0 0 101 8d 8d 5c:9a:d8:c4:49:5f 3 INCOMING ACTIVE SLAVE ENCRYPTED 0
LIST 1 CONNECTED HFP 667 0 0 64 8d 8d 00:16:97:25:9f:48 3 INCOMING SNIFF MASTER ENCRYPTED 0
LIST 2 CONNECTED SCO 5 5c:9a:d8:c4:49:5f INCOMING ACTIVE SLAVE ENCRYPTED
NO CARRIER 3 ERROR 11f HCI_ERROR_UNSPECIFIED
RING 3 00:16:97:25:9f:48 SCO
HFP 1 STATUS "callsetup" 1
HFP 1 RING
HFP 1 CALLERID "042XXXXXX0" "" 31
@1 answer
HFP 1 RING
HFP 1 CALLERID "042XXXXXX0" "" 31
HFP 1 STATUS "call" 1
HFP 1 STATUS "callsetup" 0

list
LIST 4
LIST 0 CONNECTED HFP 667 0 0 125 8d 8d 5c:9a:d8:c4:49:5f 3 INCOMING SNIFF SLAVE ENCRYPTED 0
LIST 1 CONNECTED HFP 667 0 0 88 8d 8d 00:16:97:25:9f:48 3 INCOMING ACTIVE MASTER ENCRYPTED 0
LIST 2 CONNECTED SCO 29 5c:9a:d8:c4:49:5f INCOMING SNIFF SLAVE ENCRYPTED
LIST 3 CONNECTED SCO 7 00:16:97:25:9f:48 INCOMING ACTIVE MASTER ENCRYPTED

着信にanswerコマンドで応答すると、ちゃんと音声パスのSCOリンクが新たに作られます。ところが、実際には2つ目の呼では音声通話はできません。相手側は無音状態になってしまいました。Bluetoothリンク上では音声が流れているハズなのですが、それをユーザに対して入出力するクチが無いために無音状態となってしまいます。

このように、複数の音声通話リンクは普通は扱えないのですが、iWRAPではこれを可能とするための仕掛けが用意されています。MULTISCO機能がそれで、SET CONTROL AUDIOコマンドで設定することがでできます。この機能を用いると、最初の通話にはステレオヘッドセットの左側のチャネルを割り当て、次の通話には右側のチャネルを割り当てるという仕掛けです。実際に試してみました。

set control audio internal internal multisco event
...
...
NO CARRIER 3 ERROR 11f HCI_ERROR_UNSPECIFIED
RING 3 00:16:97:25:9f:48 SCO
AUDIO ROUTE 3 SCO RIGHT
HFP 1 STATUS "callsetup" 1
HFP 1 RING
HFP 1 CALLERID "042XXXXX20" "" 31
@1 answer
HFP 1 RING
HFP 1 CALLERID "042XXXXX20" "" 31

HFP 1 STATUS "call" 1
AUDIO ROUTE 2 SCO LEFT
AUDIO ROUTE 3 SCO RIGHT
HFP 1 STATUS "callsetup" 0

list
LIST 4
LIST 0 CONNECTED HFP 667 0 0 55 8d 8d 5c:9a:d8:c4:49:5f 3 INCOMING SNIFF SLAVE ENCRYPTED 0
LIST 1 CONNECTED HFP 667 0 0 51 8d 8d 00:16:97:25:9f:48 3 INCOMING ACTIVE MASTER ENCRYPTED 0
LIST 2 CONNECTED SCO 33 5c:9a:d8:c4:49:5f INCOMING SNIFF SLAVE ENCRYPTED
LIST 3 CONNECTED SCO 20 00:16:97:25:9f:48 INCOMING ACTIVE MASTER ENCRYPTED

SET CONTROL AUDIOコマンドにEVENTパラメータを付けておくことで、チャネル割り当て状況が表示されるようになりました。が、しかし。。。やっぱりふたつめの通話は無音状態になってしまいました。マニュアルには、「この機能は実験的な実装であり、ちゃんと動かないかもしれない」と明記されています。なんらかの条件によって、動く場合もあれば動かない場合もあるということなのだと推測しますが、その条件については全く触れられていません。iWRAP5 betaでも動作確認してみましたが、２通話評価する以前に、２通話目への応答ができませんでした。まだまだ、問題山積の様子。うーん、残念ですが、今回の実験はここまで。

なお、ことなるデバイスと複数のA2DP接続をおこなうこともできますが、やはり双方のデバイスからストリートを同時に流されると音が途切れるという不具合が生じてしまいます。片側のストリームを止めてから、もう片側のストリームを流すように制御してやる必要があるようです。

電圧表示であわてる

WT32をLiPo電池動作できるようにしたので、iWRAP5での動作確認を始めたのですが、さっそくつまずきました。BATTコマンドを使って電池の電圧を調べると、とても低く表示されます。



最初は、いつの間にかLiPo電池を過放電させてしまったのかと焦りましたが、どうやらそういうわけでは無い様子。テスタで電圧を確認すると4V以上あるのにもかかわらず、BATTコマンドでの表示は3V以下。電源関連の配線をどこか間違えたかとも考えて、確認するも問題無し。

確認のためにファームをiWRAP4に戻してみると、BATTコマンドは期待したとおりに4V以上の値を表示しました。どうやら、iWRAP5の不具合のようです。

再製作

WT32の実験ボードを再度製作しました。このボードは昨年のトラ技９月号で紹介したボードと同じようにヘッドフォンアンプとしてTPA6132A2をつないだものです。記事で紹介したボードは、WCA-009と一緒に部品一式を欲しいという方がいらっしゃったので、ボードごと売ってしまいました。それいらいアンプのついた実験ボードが無い状態だったのですが、やはりHFP/A2DPの実験をするにはアンプが無いと不便なので再度製作することにしました。







昨年のボードと異なる点がいくつかあります。

1. LEDを追加。写真ではわかりにくいですが、GPIOにつないだLEDをふたつと、充電状況を示すLEDの合計３つのLEDを持たせました。充電状況表示LEDはWCA-009の下側に配置されています。
   
2. USBシリアル変換器をCP2102に変更。自分で使うものなので、eBayで安くかったモジュールを使用。秋月のFT232モジュールに比べて小さいのも気に入ったので。
   
3. LiPo電池動作に変更。USBつなげて設定。USBはずしても、限定された機能を提供するだけであれば、スタンドアロンで動作できます。
   
4. QFN変換基板は無用に大きいので、カットして使用。

ほとんど手持ちの部品で作ったので、オーディオジャックとして微妙に大きさの違うもの２つが並ぶことになっちゃいました。基板にはまだスペースが空いていますので、タクトスイッチをつけるつもりですが、実験用のマイコンも載せようか思案中。16ピンのSAM3とかあればいいのになぁ。

さて、動作確認しようと思ってMac Book Airにつなげてショック受けました。CP2102のドライバは、silabsからダウンロードしてインストールしたんですが、Mac Book Airでは動かないのです。調べてみると、ドライバのインストール時に64bitドライバを選択してやるべきだったらしい。そんなカスタマイズが必要とは知らず、ディフォルトでインストールすると32bitドライバが動こうとするようです。再度、インストール作業をやり直したところ、ドライバは動き始めているようなのですが、途中でタイムアウトエラーが発生してしまいます。しょうがないので、Win 7の仮想マシン立ち上げて動作確認しました。こんな罠があるなんて思ってもいませんでした。うーん、不便だなぁ。

久しぶりにPBAPを試す

先週記事にしたようにiWRAP 5.0のβが始まったので、わたしもアップデートしてみました。まずは、infoの出力から。



βであることの警告が目を引きますが、内容を見るといつのまにやらBluetooth version が 3.0になっています。ファームのアップデートに際しては、注意することがひとつできました。機能の追加によりファームのサイズが大きくなったために、WT32では用途に応じて２種類のファームが用意されるようになりました。具体的には音声を受ける側(HFP unit, A2DP sink)のデバイスを作るのか、あるいは音声を送る側(HFP Audio Gateway, A2DP source)のデバイスを作るのかに応じて、適切な方のファームウェアイメージを選択する必要があります。

iWRAP 5.0ではApple のiAPや、HDPをサポートする機能が標準ファームウェアの一部として提供されるようになったために、ファームウェアサイズの増大を招き、このような解決策をとるにいたったようです。ちなみにiAPの方は、AppleのMFiプログラムに参加してライセンスを受けているユーザにしか利用することはできません。参加費用を払って技術資料を入手したうえで、さらにiAPを使う際に必要となる認証用のチップをAppleから購入して、製造販売する製品に組み込む必要があるようです。このチップはI2Cでつなぐらしいのですが、WT32ではGPIOピンのうちの２つの端子がI2C端子として機能することで、このチップを接続することができます。WCA-009ではGPIO端子も全て使用可能となっていますので、iAP対応デバイスの開発試験に使用することも可能なわけですが、個人では手の出しようがありません。

一方のHDPは体重計、血圧計、脈拍計といった機器を接続するためのプロファイルですが、対応する計器を持っていないので試してみることができません。以前、タニタがBluetooth対応の体重計を出しているとのことで確認してみましたが、SPPでした。ひょっとしたら、健康診断のような業務用用途には対応機器が売られているのでしょうか？個人用に安価に買えるものがあれば、実験してみたいものです。

こんなわけで、iWRAP 5.0で強化された機能を試す機会はなかなか訪れないのですが、久しぶりにAndroid端末を使ってみる機会があったので、久しぶりにPBAPの動作を確認してみました。以前調べた時にはマニュアルの説明と動作が違うと理解していたのですが、それはマニュアルの表記がわかりにくかったために、内容を誤って解釈していたためでした。わたしの質問を受けて、iWRAP 5.0のマニュアルでは、PBAPコマンド部分の説明の一部が修正されたようです。

さて、今回つないでみたのは Android 2.3.4搭載のF12C. わたしの電話番号を連絡先に登録しておいて、着信を受けた後で、PBAPで着信履歴を調べてみました。



PBAPコマンドの最初の引数 01 で電話機内の着信履歴にアクセスすることを指示。つづく 1 0のふたつの引数で履歴先頭からひとつ読み出しを指定。最後の 0 1では、全ての内容をVcard 3.0形式で出力のハズだったのですが、どういうわけか 2.1形式で返答が返ってきました。単純に電話帳をダンプする場合には、Vcard 3.0で出力できるので、端末側が対応できていないのでしょうか？
FNならびにN属性は名前を表しているのですが、QUOTEされた16進表示になってしまっているので読みにくくなっていますが、デコードすれば "506 sirius"となっています。この部分も Vcard 3.0で返してくれれば、UTF8で読み出せるハズなのですが。。。

いいかげんに自分でスマホ買えばいいようなもんですが、こういう結果を見るにつけ事前の確認をとっておきたくなります。HFP 1.6を試すうえでも、Android 4.0が必要ですしね。

iWRAP 5.0 β始まる

iWRAP 5.0のβが先週からダウンロード可能になっていたようです。何のアナウンスもないので、先ほどTech Forumを覗いてみて初めて気がつきました。当初の予定では12月中にβ開始と聞いていたので、２ヶ月遅れくらいでしょうか。そうすると正式リリースは夏近くになるかもしれません。

HIDの機能強化とHFP 1.6対応が目玉というところでしょうか。HIDはレポートディスクリプタを設定してやらねばならないようで、ちょっと使い方が難しそう。HFP 1.6は通話音質向上をもたらす機能ですが、対応端末をもっていないことには意味がありません。Androidだと 4.0 ICSがHFP 1.6対応のようですから、そのうちには動作確認実験する機会が巡ってくるかもしれません。まだマニュルに目を通しているだけですが、そのうちにファームも上げて使い始めようかと思います。

ttyデバイス名

MacOS Xを使っていて気づいたことのメモ。

MacOS Xでは、USBのCDC対応デバイスをつなぐと、ttyデバイスが作られます。秋月USBシリアル変換モジュールをつないだ状態だとこんな感じ。

sirius506 ~$ ls /dev/tty.*
/dev/tty.Bluetooth-Modem        /dev/tty.usbserial-A800e3cf
/dev/tty.Bluetooth-PDA-Sync
sirius506 ~$ 

このデバイス名の番号ですが、USBデバイス側のDevice Descriptorからたどるシリアル番号情報を使っているようです。まぁ、ありがちな発想ですね。

さて、BluetoothのSPP対応デバイスとペアリングすると、同様にttyデバイスが作られます。WT32の場合は、初期設定でSPPがイネーブルされていますので、ペアリングすると次のようにデバイスが作られます。

sirius506 ~$ ls /dev/tty.*

/dev/tty.Bluetooth-Modem                /dev/tty.WT32-A-BluetoothSerialP

/dev/tty.Bluetooth-PDA-Sync             /dev/tty.usbserial-A800e3cf

sirius506 ~$

明らかに見覚えのある文字列が含まれているので、デバイス名を変更してみましょう。WT32で、つぎのコマンドを入力。

set bt name WCA-009

set profile spp SN117

reset

Bluetoothデバイスの登録操作をやり直してみると。。

sirius506 ~$ ls /dev/tty.*

/dev/tty.Bluetooth-Modem        /dev/tty.WCA-009-SN117

/dev/tty.Bluetooth-PDA-Sync     /dev/tty.usbserial-A800e3cf

sirius506 ~$ 

予想したとおりの名前がつきました。

SDPの違いは動作の違い

iWRAP4.0.1を導入して、すぐと気がついたことがあります。それは、やはりAVRCPに関する動作でした。今回の記事では、WCA-009を使って動作の違いを確認するとともに、その原因を探ってみることにしまいた。

まずは、どこが違ったのかの説明から。iWRAP4.0.0ではiPadからBluetoothの接続をおこなうと、次のようにWT32上にイベントが表示されました。

それが、iWRAP4.0.1ではこのようになります。

一目瞭然、iWRAP4.0.1ではA2DPだけでなく、AVRCPについても接続されています。本来、こうあって欲しかったのですが、iWRAP4.0.0ではA2DPはつながるものの、AVRCPはつながりませんでした。しょうがないので、callコマンドを使うことでWT32側からAVRCPのリンクを張っていました。どちらの場合も、iPad側はiOS 5.0ですので、この動作の違いが生じる要因はWT32側にあることになります。iPad側から接続手続きが始まっているので、AVRCPのプロトコル動作が原因では無いということもわかります。すると、原因はWT32が公開しているSDP情報の違いに起因していると推測することができます。

と、いうわけで、WT32が提供しているSDP情報を調べてみることにします。使うのはいつものようにLinux上のsdptoolです。まずは、iWRAP4.0.0の場合。

そして、こちらがiWRAP4.0.1の場合。

ほとんど同じような内容ですが、よく見るとiWRAP4.0.0ではA/V Controller ServiceにおいてService Class ID Listが含まれていなかったことがわかります。つまり、iPadではこのService Class IDを確認してAVRCP接続を起動するかどうかを判断していたのですね。実はiWRAP4.0.0を使った場合でも、AVRCPをtarget側に設定した時にはちゃんとService Class ID Listは出ていました。ですから、controller側でSerivice Class IDが出ていなかったのは、iWRAP4.0.0でのバグだったのですね。

iWRAP4.0.1でつないだ場合にAVRCP GET_CAPABILITIES_RSP REJというイベントが表示されていますが、この意味するところは、今のところ不明。avrcp pduコマンドをつかってGET_CAPABILITYを送ってみると、サポートするイベントはちゃんとひろうことができています。iWRAPのAVRCPスタックが自動的に何やらリクエストを送っているのでしょうが、それが何なのかはわかっていません。