BlueHAND

昨年より製作していたBlueHANDのデモ動画をこさえました。当初は、SAM3Sと家庭用電話機の"うわがわ"を流用したものをBlueHANDと呼び、LPC1114と電話機の受話器部分だけを使ったものをBlueHAND-Miniと呼んでいたのですが、LPC1114版の方ばかりに機能追加やバグ修正を施してきたので、こちらの方をBlueHANDプロジェクトとして整理することにしました。




動画ではペアリングから始まって、AVRCPを使った音楽再生の制御、HFPによる着信と発信の操作/動作を示しています。サイズと画質を調節してもらえれば、LCDの表示内容も確認することができるかと思います。


音楽再生中には、矢印表示が移動していきますが、これはA2DPが流れていることを示します。AVRCPを使ってpauseすると、しばらくしてからA2DPが止まります。

音はヘッドフォン端子につなげた外部アクティブスピーカーで出しています。

着信デモ中での音声は、CeVIOの音声キャラクターであるさとうささらさんです。連休前にリリースされたCeVIOを早速使ってみた次第です。CeVIOで作製した48KHz WAVファイルをMP3に変換/アップロードして、電話の向こう側で再生させています。その部分の仕掛けについては、そのうちに改めて説明記事を書こうかと思います。

Display + yes/no button

連休を使ってBlueHANDの動画を撮っているのですが、イザとなるともう少し手を加えてみたくなる箇所が出てきました。それが、SSP(Simple Secure Paring)の使い方です。これまでは、SSPを使ってのペアリングには Just worksというモードを使っていました。このモードだと例えばスマホからBluetoothデバイスを検索して、見つかったBlueHANDを選択するだけでPIN番号の入力やパスキー確認をすることなくペアリングが行えてしまいます。この機能はもともとマウスのような表示、キー入力機能を持たないデバイスを意識して用意されたものです。

BlueHANDはLCD表示器と電話キーパッドをもっていますので、スマホとBlueHANDの両方に同一のパスキーを表示して、両方のデバイス上でそれを確認してキーを押すことで、互いのデバイスを確認した上でペアリングさせることもできます。SSPではデバイスが持つ能力をいくつか想定していますが、これは "Display + yes/no button" という能力に相当します。この能力を使うように設定するには、WT32上では

SET BT SSP 1 1

という設定をしておきます。スマホ側からペアリング/接続操作をおこなうと、WT32には

SSP CONFIRM 0c:71:5d:10:85:1e 089944 ?

というようにパスキーの確認を要求するイベントが出力されますので、

SSP CONFIRM 0c:71:5d:10:85:1e OK

と応答してやることでキー確認を行います。この動作をBlueHAND上に反映させた様子が下の写真です。




両者の画面上に同じ６桁の数字 089944 が表示されました。スマホ側ではOKボタンを押し、BlueHAND側では0キーを押してペアリングを了承してやると、ペアリングが完了して接続されます。赤い*または#キーを押せば、ペアリングを拒否できます。このように接続する側/される側の両方のデバイスを操作する必要があるので手間がかかりますが、こうすることで互いを確認でき、悪意をもつなりすましデバイスと誤ってペアリング/接続してしまうことを防ぐことができます。

店開き

今年に入ってからWCA-009が売れずにいるので、販売促進のために売店を開きました。


クレジットカードで購入できるので、振込手数料節約にはなるでしょう。当方にとってはカードの決裁手数料分だけ赤字になりますが、しょうがないですね。せっかく店を開いたので、WCA-009以外のものも並べてあります。昨年から製作しているLPC1114FN28を実装できるボードが中心です。



基板だけだと秋葉で入手できない部品が多数あるので、パーツセットとしました。LPC1114FN28を含む全ての半導体と主要コネクタ類を含むパーツセットですが、細かな部品であるチップ抵抗やチップコンデンサ等は含まれていません。



パーツキットはヘッドフォンアンプとマイクアンプが0.5mmピッチの表面実装部品となりハンダ付けに苦労するので、一応組み立て/動作確認済みのボードも準備中。



BlueHANDとして動作させるためには上の写真左側のようにキーパッド部分を載せなければなりませんが、今のところキーパッド基板の販売は予定していません。

現在、一部パーツを手配中であるとともに、資料の準備中です。そのためWCA-009以外は売り切れ状態としてあります。準備ができしだい「在庫あり」にするつもりですが、手持ちのパーツの都合もあり当初は１、２セット程度しか用意できないと思います。

飯を喰うヤツ

先週はわずかながらLPC1114が消費する電流を低減することを試みましたが、実際にはマイコンなんかよりWT32の方がはるかに電流を消費します。したがって、まずはこちらの方の消費電流を削減することの方がよっぽど重要です。

WT32のデータシートには消費電流についてはあまり詳しく説明されていないのですが、100mA程度は必要であるとされています。当然のことながら、アクティブに電波を送受している時と、単にスタンバイしている時では消費電流も大きく違うであろうことは容易に想像できます。そんなことを思っていたところ、BluegigaのForumに新たな情報が登録されているのを見つけました。このデータはWT11iの数字ですが、WT32においても同じような傾向を示すだろうと思われます。iWRAPではsleepコマンドを使ってsleep状態に遷移させることができるのですが、それでもピーク時には結構な電流が流れるのですね。しかもpagemodeによってずいぶんと値が異なります。この数字を見ても、他のデバイスから発見可能とするためにinquiryに応答するように設定すると、消費電流が大きいことが良くわかります。通常は、pagemodeを２として使い、しかもsleepさせておくことが望ましいでしょう。

autopair と autocall

Maker Faireの時もそうでしたが、Bluetoothのデモのために観客の方に携帯やスマホを使ってBluetoothでの接続を頼むと、少なからぬ方々から、「Bluetooth使ったことないから、どうやるのか良くわからない」という返答があります。Bluetoothという言葉は知っていて、設定メニューの中にそういう項目があるのもわかっているけど、実際には使ったことがないという方がまだまだ多いようです。

今回はそんな客層を相手にデモするのに便利に使えそうな機能として、iWRAP5から新たに加わったautopairを紹介することにします。autopairは既存のペアリング情報情報が無い場合に、inquiryをかけてみて、見つかったデバイスに対してWT32側からペアリングをかけるという機能です。ペアリングができたら、さらにautocall機能を使ってWT32側から接続をかけることもできます。したがって、相手にはBluetoothの電源を入れてデバイス名を公開してもらいさえすれば、後の操作はこちらから行ってデモを進行できることになります。

実際にAndroidでやってみると端末側の動きは次のようになります。



まず、最初の状態です。スマホ側のBluetoothの電源を入れて検索がかかるとWT32が見えてきます (WT32側がデバイス名公開する設定にしているため)。



通常でしたら、ここでWT32をタッチして接続してもらうわけですが、今回はデバイスを公開してもらうことにします。



しばらく待っているといつの間にかペアリングが済んで、表示が「接続可能なデバイス」から「登録済みデバイス」に変化します。(ここまでがautopair機能の働き)



そして、つづいてWT32でautocall機能が動いて接続要求が来るので、写真のようにその確認メッセージが表示されます。「はい」でこれを許すと接続完了。



WT32側の設定は次のとおり。

ポイントとしては、

• 接続相手を限定するために、paircountを１にしておく。
• 初期状態ではペアリング情報を全て消しておく。
• 上記設定では、ペアリングができたらautocallが動いてHFPでの接続を張りにいく。
• HFPが張れたことをCDの設定でPIO7(0x80)に反映させる。
• bindでPIO7の立ち上がりを検出して、HFPにAT+CNUMを送る。５秒間のディレイを置いているのは、端末側での接続受付確認作業に要する時間を待つため。
• 接続が切れたらペアリング情報を消去しておく。

WT32側の動きにともなうメッセージは次のようになります。

ここでは電話番号を調べてみましたが、電話発呼するとかもできますね。
同じ要領でHFPの代わりにA2DP/AVRCPを張ると、音楽プレーヤの再生を勝手に開始するなんてデモもできます。機会があったら、次はこれをやってみたいな。

SPP経由で設定変更

先月、muxコードを使うことでWT32のイベントメッセージをSPP接続したリンクに出力できることを記事にしました。これだけではWT32とのやりとりが片方向でしたので、さらにチョット手を加えて双方向化、SSP経由でWT32のコマンドも入力できるようにしてみました。PCからSPP経由で WT32に ATコマンドを送り、その応答であるOKが表示されるまでの経過を図示すると下図のようになります。

• muxモードでは、WT32が出力するメッセージには、つねにリンク番号がついている。Bluetooth接続を経由して受信したデータには、そのリンク番号。WT32が出力するイベントメッセージには、リンク番号として255が使用される。この例では、SPPのリンク番号は０であると想定する。
• マイコンでは、0番リンクからのデータはSPP経由で入力されたWT32コマンドであると解釈。そこで、受信した文字列 at を、WT32の制御リンクである255番リンクに送り返す。
• WT32はATコマンドを実行し、その応答である OK を制御リンク255番を使って返す。
• マイコンでは、制御リンクからのメッセージを全てSPPのリンクに出力する。
• 結果として、OK応答がPCに伝わる。

このようにWT32とLPC1114の間のやりとりは倍増してしまいますが、ワイヤレスでWT32の動作をモニタできるだけでなく、その設定変更までできるのは、なかなか便利です。これまではWT32の設定変更が必要になると、他の実験基板にWT32を載せ代えたり、ボード上のジャンパ設定を変更して外部シリアルにつなぎかえて作業をしていましたが、もうその必要もなくなりました。

muxモード

WT32の大きな特徴は、SPPだけでなくA2DPやHFPのようなオーディオ関連プロファイルをサポートするとともに、これらを同時に接続できることにあります。BlueHANDでは通話にはHFPを使っていますが、以前の記事にも書いたようにLPC1114FN28ではデバック用に使えるポートが無いので、SPPを使ってHFPを始めとする他のプロファイルの動作状況を外部からモニタできるようにしてみます。接続イメージはこのようになります。



スマホ/携帯とはHFP/A2DP/AVRCPで接続する一方で、PCとはSPPでBluetooth接続します。HFPの動作によって生じたイベントメッセージをマイコンでひろって、それをSPPで送信してやればPCから他のプロファイルの動作をモニタリングできることになります。しかしながら、WT32にもシリアルポートはひとつしかありません。送信するデータをどちらのリンクに送るか、あるいは受信したデータがどちらのリンクから来たものかを区別できないと、複数の接続を使い分けることができません。このような要求に対応するために用意されているのがmuxモードです。

muxモードではWT32とやりとりする通信のフォーマットが、無手順ではなく、独自のフレーム形式に変わります。各フレームには送信先/送信元のリンク番号が入っていますので、これで複数の通信路を区別して送受信をおこなうことができるようになります。この例では、異なるプロファイルを使っていますが、別々のデバイスと複数のSPP接続を張るような使い方も可能です。フレーム形式とはいっても、HDLCのようにビットインサートが必要なわけでもなく、PPPの非同期HDLCのようなエスケープ処理の必要もないフラグ・バイトとLength prefixがついただけのとても簡単な形式なので、簡単にエンコード/デコードすることができます。

このLPC1114FN28を使ったユニットはBlueHAND-Miniという名前にしましたので、Mac OS Xからペアリングをおこなうと、その名前のついた TTYデバイスが作成され、これを使って接続することができます。screenコマンドを使うのであれば、....



接続後、スマホとBlueHAND-Miniをつなげてみると、screenコマンドの画面ではつぎのようにWT32の出力するイベントをモニタすることができるようになりました。もちろん、LPC1114からのデバック・メッセージを出力させることも可能です。



ワイヤレスで動きがモニタできるので、とっても便利になりました。

TS472 - その2

前回の記事で追加したTS472ですが、簡単なソフトを用意して動作確認できました。結果はとても良好。綺麗に音声をひろってくれて、ノイズも乗りません。




WT32内蔵のプリアンプ(20dB)は有効にしたままです。TS472で20dB上げていますので合計40dBになりますが、電話機TF-08の受話器では、これでちょうどいい音量になっている感じです。

TS472

少しずつではありますが、電話機ハンドセットをBluetooth化するプロジェクト(BlueHAND)を進行中。Maker Faire Tokyoにもこのプロジェクトで申し込んであるので、そろそろちゃんと動くものを作らないといけません。まずは、秋月A基板に基本パーツを配置してみました。




WT32のアナログ入力には、マイク用に20dBのプリアンプが内蔵されています。ヘッドセットを使う分には、マイクが口元近くにあるので、このプリアンプで充分な音量を得ることができました。受話器(ハンドセット)のように口元から少し距離が離れる場合には、さらにゲインを上げてやる必要があります。WT32内蔵のCODEC機能でも入力ゲイン調節できますが、これまでの実験ではノイズが増えてしまい、あまり良い結果を得られませんでした。そこで、今回は外付けのマイクアンプとしてTS472を投入。これでゲイン稼ぐとともにバイアス電圧供給することにします。

24ピンQFNなので、先日aitendoで買っておいた変換基板を使用。aitendoのQFN変換基板は以前は青かったのですが、色が赤に変わったとともに、ムダに高さや幅があったのが改善されて、ひとまわり小さくなったようです。それでもこの24ピン変換基板は、もう少し幅を狭くしてくれてもいいでしょう。そもそも、TS472にはNCの端子が10ピンもあるのも変換基板が大きくなってしまう原因になっているのですが。。




フックスイッチとキーパッドはまだ未配線。アンプとRJジャックの配線はできたので、ソフト入れてアンプの動作確認に進むことにします。

HFP接続で電話番号を調べる

７月に「PAGEMODEとペアリング」で書いたように、WT32のディフォルトの設定ではデバイスが発見可能な状態に置かれています。最近のAndroidスマホでは、Bluetoothを発見可能な状態(公開した状態)に設定するにしても2分程度に時間が制限されています。セキュリティと消費電力抑制の両方の観点から好ましい振る舞いなのでしょう。もう、しばらく前のことになってしまいましたが、高木浩光氏がこれに関連した記事を書いておられたことを思い出しました。BDADDRから、みず知らずの人と何度も同じ電車に乗り合わせていることがわかるとか、面白い話です。今ではガラケーからスマホへのユーザ移行が進むにつれて、電車の中で見つけられるデバイス数も減っているんでしょうね、きっと。

高木氏の指摘もあって、いまではBluetoothは必要な時だけ発見可能な状態にして使えばいいものだということは、良く知られるところになったと思います。きょうはあまり知られていない(と思われる)HFP接続するだけで、電話番号を知られてしまうということについて書いておきます。1年以上前から、飲み会では何度かデモして見せたことがあるのですが、今まで記事にしたことがありませんでしたので。

まずは、WT32を使ってA2DP, AVRCP, HFPをイネーブルしておきます。こんな設定です。



iWRAP5ではディフォルトでSSPがイネーブルになっています。そのため、スマホからデバイス見つけて接続操作をすれば、PIN入力の必要もなく、簡単に接続できてしまいます。まずは、デバイス検索をかけて、



見つかったデバイスにタッチするだけで、ペアリングが始まります。スマホとWT32の双方ともSSPのJust Worksモードでの相手確認を許容していますので、PINコードを入力したり、画面表示内容を確認したりすることもなくペアリングができてしまいます。



そしてそのまま、ご丁寧なことに、あれよあれよという間に、見つかったプロファイルと自動的に接続までしてくれます。



WT32側からみるとこんなふうに動いています。



便利と言えば便利なんですが、ちょっとした危険も潜んでいます。今、あなたはお店でBluetooth対応のデバイスを選定中で、自分のスマホをつないで、プレーヤの中の曲を再生してみていると想定してみましょう。音楽再生の試験をするだけならば、A2DPとAVRCPをつなげば充分なのですが、上の例に示したようにスマホはデバイス側がHFP対応していれば、HFPも接続してくれちゃいます。以前、ガラケーを使っていた時には、プロファイル毎に接続や切断操作ができたのですが、Androidの標準機能にはそのような細かい接続操作機能は備わっていないようです。

まぁ、ほとんどの人はこれで不自由することはないんですが、重要なのは使っている本人は全く意識していないうちに複数のプロファル(HFP, A2DP, AVRCP)の接続ができてしまっているということです。WT32でLISTコマンドを実行すれば、４つのリンクができていることを確認することができます。



そして、ひとたびHFPでつながってしまうと、デバイス側からATコマンドを送信することによって、携帯端末側の状態情報を調べることが可能になります。その端的な例が AT+CNUMコマンドであり、端末はこのコマンドを受けるとその電話番号を返します。上の例では、実際にWT32を使ってHFPのリンクに対してAT+CNUMコマンドを送ってみた様子を示しています。端末によっては、電話帳にアクセス可能なATコマンドを用意しているかもしれませんが、そうすると電話帳まで抜き取ることが可能かもしれません。AT+CNUMコマンドは3GPP標準の基本的なATコマンドのひとつなので、どんな端末でもサポートされているようです。

このように、HFPをサポートするBluetooth機器は、その気になればAT+CNUMコマンドを使って接続した携帯端末の電話番号を調べて、その結果を収集することが可能なのです。明示的にHFPでの接続を頼むと怪しまれるかもしれませんが、音楽再生して欲しいとか写真ファイル送信して欲しいという理由で誘導することでBluetoothのペアリング操作を実行させてしまえば、それと知らぬ間にHFPまで接続させてアッという間に電話番号読み取りが終了してしまうのです。上記の例に示したように、Android携帯端末側でおこなった操作としては、デバイス検索をかけて、みつかったデバイス名にタッチしただけであり、それ以降ユーザには何の確認動作もおこなう機会が与えられませんでした。デバイス名にタッチしてから、およそ10秒後にはもう電話番号を読み取られているかもしれないのです。

こんなわけで、怪しげな自作Bluetoothデバイスとは、ペアリング/HFP接続してはいけません。(笑)