Xperia arcとPBAP - その2

先週うまくつなげられなかったXperia arcのPBAPですが、問題解決。ちゃんとWT32ともつなげられました。

原因は、クライアント側からXperia へPBAPで接続した際に、Xperia側のAndroidは接続要求の承認を求めていたのに、そのことにわたしが気づかなかったためです。実際のところ、何かの承認が必要になるだろうと思ってはいたので、画面は見ていたつもりだったのにもかかわらず、その要求に気付かなかったのです。不注意といえば不注意だったのですが、わたしは画面の真ん中にジャーンという具合に大きく承認要求が出てくることを期待していました。ところが、実際にはAndroidは画面上部の電池残量等を表示しているステータスライン上に、PBAPの要求が来ていることを文字でひかえめに表示していたのでした。そのため、わたしはこの事実に全く気が付かなかったという次第です。この表示が出たら、ステータスラインの部分をタッチしてさらに下に引っ張り出すようなアクション(きっとナントカいう呼称がついているんでしょうけど)をすると、承認をすることができます。しかし、こんな操作とてもじゃないけど思いつきません。わたしは Xperiaのユーザに教わりました。おそらくAndroid流の操作のひとつなんでしょう。人に教わるか、本で読むとかしないと使い方わかりませんね。本屋にスマホの使い方を説明するムックが並んでいる理由が、いまさらながらに理解できました。

WT32との接続の様子はこんな↓です。



callを使ってWT32側から接続しにいき、CONNECTがでるところまでは先週も動いていました。PBAPの接続承認をして、はじめてOBEX READYの応答が返ってきます。この状態になると、pbapコマンドを入れることで、電話帳へのアクセスができるようです。ただ、WT32のPBAPコマンドの説明が、実際の動作と一致しないのです。マニュアルの記述間違いかもしれません。またの機会に、さらに調査してみる必要がありそうです。

BlueSAMにおける主従関係

Bluetoothがらみプロジェクトの度に考慮をせまられるのが、どのデバイスをI2S/PCMのマスターにしてクロック供給の任を負うかの検討です。途中まで作業を進めたドッチーモ・ジャケットにおいては次のようになっていました。

• 無通話、無再生時には、SAM7SがPCMマスター。8000Hzのサンプリング周波数でPCMクロックを生成。
• W-SIM通話時には、W-SIMがPCMマスター。
• HFP通話時には、WT32がPCMマスター。
• A2DP(音楽)再生時には、WT32がI2Sマスター。

いずれの場合もCODECがスレーブなのですが、マスターとなるデバイスを74HC157を用いて選択するとともに、CODECを再初期化するという処理をおこなっていました。オーディオ信号形式も、PCM形式(HFP/W-SIM使用時)だったりI2S形式(A2DP再生時)だったりするので、SAM7S/WT32の出力する形式に一致するようにCODECの設定が正しく変化するように注意する必要もありました。

BlueSAMにおいてはW-SIMを使わないため、必要な組み合わせも減り単純化できます。

• 無通話/無再生時を含む全ての場合において、CODECがI2Sマスター。
• HFP通話時は、サンプリング周波数8000Hz。
• A2DP再生時はサンプリング周波数44.1KHz。

無通話の状態でも、着呼の際に着信音を鳴らしたり、発呼の際に接続中音/呼出音をならしたりする仕事をCODECにやらせたいので、これらに関連する呼制御信号が入った時には、必要に応じてCODECの再初期化が必要となります。

CODECとして使用しているTLV320AIC3254は、リセット後のディフォルトではI2Sスレーブの設定ですが、設定でマスタ側にもできますしPLLを設定することで、クロック周波数も柔軟にプログラムできます。

CODECの初期化をおこなう際には、CODECをいったんリセットして全ての設定をやりなおし、SAM3Sのフラッシュに入れてあるminiDSPのコードをダウンロードしてやります。この際にどうしても、ちょっと「プチッ」というノイズが入ってしまいます。ちゃんと再初期化処理が動いていることが、耳で確認できるわけですが、これを利点と考えるのは自分が「作る側の人」であるからであって、ユーザの立場からみれば単なるノイズです。レジスタの設定で、少しはノイズを小さくできたようなのですが、それもまだ改善の余地がありそうです。

CODECに関しては、まだ解決できていない問題が2点残されています。

1. 高音にノイズが載る。A2DPでの音楽再生時に高音の部分にノイズが載る。なにやら促音が強調されて聞こえる。
2. コンパイル時に-O1で最適化するとスペアナ表示がおかしくなる。

1の問題については、CODECの設定を見直すもいまだ原因わからず。単なる気のせいかもしれませんが、ナビスイッチを付けた後あたりから、音が悪くなったようにも思えます。配線や電源に関連するノイズが影響しているのかもしれません。

2の問題は必ずしも最適化のせいではないかもしれません。どこかにバグがあってメモリを壊しており、その副作用がスペアナ表示に現れているだけかもしれません。プログラムに手を加えてコード長が変化すると、この症状が出たり/消えたりするので、むしろその可能性が高いかもしれません。

Xperia arcとPBAP

スマホを代表する機種のひとつであるXperia arc (SO-01C)に触れる機会を得たので、WT32との接続実験をおこなってみました。HFPやA2DP/AVRCPでつながるのは当然なのですが、残念な点がふたつ。

1. HFP接続においてAT+CCLK?がサポートされていない。
2. AVRCP 1.3対応していない。

AT+CCLK?は、日時を取得するためのATコマンドです。この機能があれば、携帯電話から取得した日時をBlueSAM側の時計に反映することができます。iPhoneにはこの機能が備わっているのですが、これまでにわたしが試すことのできた他の携帯電話ではこの機能がサポートされていませんでした。古い機種ばかりで、いまどきの機種を試せていなかったのでXperia arcには期待していたのですが。。

AVRCP 1.3に対応していないので、曲名情報が取得できません。iPhoneと同じ。これってAndroidの世界では常識？ IS01/IS03では対応していたんですけど、これはシャープさんが頑張ってくれたということでしょうか。

そしてXperia arcで試したみたかったもうひとつのBluetooth機能がPBAPです。PBAPは電話帳へアクセスするためのプロファイルですが知名度は低いのではないでしょうか。iPhoneは対応しており、(Google検索の結果からは)PBAPに対応したカーナビとつなげて使われることが多いように見受けられます。近頃のAndroid端末はいずれもPBAP対応を謳っているようで、Xperia arcもその一例です。BlueSAM側にはダイアルとか電話帳とか用意しなくても、PBAPでスマホの電話帳にアクセスして電話番号を取得して発信したり、着信時の際に発信者番号から名前を逆引きしたりできるのではないかと目論んでいるのです。

期待に胸を膨らませてWT32からXperia arcにPBAPでつないでみると、リンクは張れました。ところが、電話帳の検索とかダウンロードとかが一切できません。Xperiaのマニュアルを読んでも、PBAPの使い方の説明なんて皆無です。単にPBAPに対応していると書いてあるだけ。ちゃんと動かないのは、WT32側の問題なのかもしれませんが、わたしはPBAP対応のカーナビを持っていないし(そもそも車の免許すら持ってないし)、比較対象する装置を持ち合わせていません。PBAPをサポートする手ごろなBluetoothデバイスはないだろうかと探して見つけたのがコレ↓です。

	バッファローコクヨサプライ Bluetooth USBアダプター 3.0+EDR対応 class2 ブラック BSHSBD04BK
	クリエーター情報なし
	バッファローコクヨサプライ

バッファローの新しめのUSBドングルです。サポートするプロファイルにPBAPと書いてあったので購入。仕様には単にPBAPと書いてあるだけでそれがPSE側なのかPCE側なのかあるいは両方サポートされているのかすらわかりません。もっともWT32はPCE側、Xperia arcはPSE側をサポートしているので、どちらか片方あればなんらかの実験はできるので買ってみました。以前購入したドングルには東芝のBluetoothスタックのソフトが付属していましたが、今回購入のドングルにはMotororaのソフトが付属しており、そこでPBAPのPCE側がサポートされていることがわかりました。

実際にこのモトローラのスタックを使ってXperia arcにつないでみると、次のような画面が現れました。



「データ同期」がPBAPを使って電話帳にアクセスして、その内容を吸い上げて、PIMファイルとしてバックアップ保存してくれるようです。バックアップボタンを押してみると、接続を開始した様子を示すものの、そのあとダンマリ。待つことしばしで、



ダメです!!バックアップできません。やっぱりXperia arc側でPBAPがちゃんと動いていないように思われます。なにしろAndroidなんて初めて触るので勝手がわかりませんが、何のメッセージも出ないし。設定とか調べてみると、Bluetoothの共有サービスとともにOPPとPBAPのサービスを担当するモジュールが起動されていることはわかりました。しかし、実際には電話帳にアクセスできません。想像するにPBAPのPSE側のプロトコルスタックは動いているものの、そのスタックを利用するアプリが動いていないように見受けられます。試しに連絡帳を開いた状態でアクセスしてもみましたが、結果は変わらず。動きません。

Androidでは、PBAPをサポートしていても、電話帳へのアクセスは提供していないということなんでしょうか？　アクセス許可の設定が、どこかで必要？ Xperiaの出荷時の構成では機能が不足しているんでしょうか？ Marketで何かアプリを探して、追加インストールしないといけないものなんでしょうか？ Android/Xperiaに詳しい方、教えてください!!

ちなみにPC側のモトローラ・スタックは、PBAPに対応してはいるものの、AVRCP 1.3には対応していないようです。どいつもこいつも一長一短ばかりだなぁ。

使いにくい

ナビ・スイッチの処理にリピート処理を追加するとともに、時計の設定画面を用意しました。

時計あるいはプレーヤの動作画面からNav1スイッチを長押しすることで、まずはメニュー画面に遷移します。



Nav1スイッチを廻すことで項目を選択。スイッチを押すとその画面に移動します。時計設定画面は↓



Nav1スイッチで、項目選択。Nav2スイッチで選択項目の値を変更するようにしてみたのですが、実際に触ってみると、コレが使いにくい! 2つのスイッチを操作する必要があるなんてダメダメでした。ひとつのスイッチから指を離さずに操作できる方が良さそうです。これで、日付と時刻は設定できるようになりましたが、電池動作させないといちいち設定するのが面倒なんで、実際には設定しそうにありません。

ナビ・スイッチへの機能割りあて

SAM3SのPIOを使うことで、チャタリング除去処理が不要になったナビ・スイッチですが、A2DP再生時には2つのナビスイッチ(Nav1とNav2)に次のように機能を割り当ててみました。

• Nav1 押すことでPlay/Pauseの切り替え。上下に廻すことで曲送り(forward)または前の曲(backward)へトラック変更。
• Nav2 押すことで機能選択。廻すことでレベル変更。

Nav2の方は機能スイッチとして働き、次の3つの機能をサポートしています。

1. 音量
2. 3D効果
3. スペアナグラフ表示形式変更

それぞれの機能を選択した場合の画面表示例を以下に並べておきます。スイッチの役割を画面右側に縦方向に表示していますが、これはchiakiさんのTimpyのアイデアを真似ています。



まずは初期画面です↑。最初は機能スイッチであるNav2スイッチは、音量調節として機能します。もちろん、上下に廻すことで音量が増減します。



音量表示の状態でNav2スイッチを押すと、Nav2の機能が3D効果調節に変わります↑。ほとんど同一の画面内容ですが、Nav2スイッチを上下することで効果の効き方が変化します。



さらにもう一度Nav2スイッチを押すと、スペアナ表示の形式を変化させることができます。と、言っても単に上下を変えているだけなんですが。。



トラックの変更と音量調整ができるだけで、かなりプレーヤらしくなってはきましたが、これだけではプレーヤ画面から抜け出せないので、メニューに移動するための手段として Nav1の長押しを割り当てています。現在、メニュー画面と時計設定画面も用意しているのですが、操作性の向上のためにリピート機能も欲しくなりました。そこで、現在これらの機能の実装中です。

ナビ・スイッチのつなげ方

BlueSAMではナビ・スイッチを2つ使っていますが、これらのスイッチは言うまでもなく、GPIO(ATMEL用語ではPIO)のポートにつながっています。



裏返すとこんなデタラメな配線が丸見え↑。長さもとらずにテキトーに線材を切って配線していたので、線がみんなたわんでいます。(^_^;)

きょうの記事ではSAM3Sをつかうと、GPIOにつなげたスイッチの処理が簡単になるということを書きとめておこうと思います。

マイコンを使っての実験の第1歩がLEDチカチカ(Lチカ)であるとするならば、その第2歩2としてポピュラーなのが入力スイッチの状態検出でしょう。ここで問題となるのが、スイッチの機械的なチャタリングです。そのため、スイッチの状態変化を検知したならば、しばらく待って同一状態であることを確認してから初めてその時点で変化を確定するという処理がおこなわれます。一時的に状態変化がバタバタとする期間の変化を無視するためです。

SAM7やSAM3ではPIOポートの状態変化は、割り込みで検出することができます。SAM7では短期間の入力変化ノイズを除去するGlitch filterという機能がありましたが、このフィルタで除去できるのはマスター・クロック(MCK)の半分までの長さのノイズでした。MCKはメガHz単位なので、除去できるのはナノ秒単位であり、スイッチの機械的なチャタリング除去には使えないものでした。そのため、SAM7ではタイマーを利用して一定時間待った後に、状態を再確認するソフトウェア的処理が必要になっていました。

SAM3では新たにDebouncing filterという機能が追加されています。Glitch filterがMCKを使っていたのに対し、Deboucing filterでは32KHzのクロックを分周したクロックで、判定期間の長さを指定できるようになり、機械的なチャタリング除去に利用できるようになりました。チャタリング除去後に、状態変化を割り込みとして発生することができるので、ソフトウェア側ではチャタリング処理を全く考慮せずに良くなりました。加えて、割り込み発生条件として立ち上がり/立下りのエッジも指定することができますので、1)スイッチを押した時、2)スイッチを離した時, 3)押し/離しの両方というように割り込みを発生する条件も指定することができます。

このようにdebouncing filterを利用すれば、これまでチャタリング除去の処理のために用意していたタイマーやタスク/スレッド/割り込み処理を不要にすることができるので、便利です。今回のナビ・スイッチの処理でも、この機能を使ってみました。もっとも、スイッチの長押しとかオート・リピートとかの機能が欲しくなると、やはりタイマやタスクが必要となってきます。現在のわたしが、この段階なんですが。

今回はアクリルケースに入れた

トラ技オフ会では製作中のBlueSAMをケースに入れた状態でデモしたのですが、これまで写真を撮っている時間的余裕がなかったので、きょうはその姿を記録しておくことにします。オフ会でのプレゼンにはいちおう写真を入れたのですが、間に合わせて携帯で撮影した写真を使ったのでピンボケになっていました。

使用したケースは秋月のアクリルケースSK-16です。前回Bluetooth対応W-SIMジャケットを製作した際にはポリカーボネートのケースを使いましたが、加工に苦労したので、今回は時間もないこともあり加工が容易であるアクリルケースにしました。

まずは動作中の正面像から。WT32基板の下にはCODECであるTLV320AIC3254が隠れています。そしてLCD基板の下には、SAM3S4A, SPIフラッシュが隠れています。良く見るとLCDの左側に小さな穴が開いているのがおわかりいただけると思います。この穴はLCD基板の裏側からとりつけてあるシリコンデジタルマイク(SPM0405HD4H)で音を拾うために開けたものです。



WT32は昨年自作したヘッダー基板上に載せてありますが、現在開発してもらっている認証を取得する基板では、13x2ピンのヘッダーピンを左右に配置した合計52ピンとなる予定です。WT32のもつ50ピンをそのまま全て出してあるだけの単純な構成です。2ピン余ってしまいますが、これは秋月で買える13x2のソケットを使えるようにしたかったため。大きさよりも工作のしやすさと部品入手性を優先させることにしました。

LCD画面には曲名、スペアナ表示に加えて音量表示も出しています。音量は後述するナビ・スイッチで増減できます。他にも機能があるのですが、それについては、別の機会に。

画面最下部には時刻表示があるのですが、現時点では時刻設定機能が無いので、ブートからの経過時間表示になってしまっています。

ケース右側にはナビ・スイッチふたつ分の穴。大慌てでケース加工したので、穴位置がちょっとずれてしまいました。基板は秋月のスペーサで固定。LCD基板を積んだら、ほとんどギリギリで収まる高さになりました。ラッキー。



ナビ・スイッチの役割については、上側をモード変更、下側を機能変更のような役割で使うことをイメージしていますが、詳細は未定で今後つめていくつもり。現在のプレーヤでの割り当てについては、また別の記事で説明することにします。

そして、ケース下側にはUSBとヘッドフォン用のジャックの穴があります。見てのとおり、穴位置が好ましくない高さにきてしまったので、ケースの一部が割れてしまいました。もっと低いスペーサを買えば良かったのですが、手持ちで間に合わせたかったので。



USBコネクタもミニBにしたかったのですが、何かを作ろうと思ってBコネクタを付けたまま死蔵されていた基板を有効利用したかったという事情でこうなっています。プリント基板化する際には、ミニBにするつもりです。

昨夜お会いしたshintaさんには「ブログには基板裏側の写真も載せてよ!!」とのツッコミを頂戴しましたが、もちろん見せられるものなら見せているところですが、見せられないようなありさまになっているような次第です。今後リポ電池動作にするつもりでいるので、電池で汚い配線が少しでも隠せると思います。そうしたら裏側写真も掲載することにしましょう。

SAM3Sボード

どうやらOLIMEXからSAM3Sのボードが出てくるらしい。久しぶりにOLIMEXのtweetをチェックして気が付きました。早いとこ、Web pageも用意して欲しいものです。自分の好みとしてはJTAGソケットは外付けにしてしまって、ボード上にはコネクタを載せない方が使い勝手がいいのですが、OLIMEXだともれなくJTAGコネクタ付きになってしまいそうですね。早いとこPropoxにもSAM3Sボードを出して欲しいものです。

あれから1年近く経った

昨夜は「トラ技オフ会」に出席。デモとプレゼンをしてきました。なにしろ急ごしらえのハードとソフトだった上に、前夜は睡魔に負けてしまい、最後の追い込みもできないままに当日となってしまいました。そのため、デモの方は途中でハングしたり、突如画面が真っ白になったりするありさまではありましたが、なんとか曲再生中のスペクトル表示や、HFPを使っての通話デモを実施。現状については、改めて記事にしたいと思います。

参加者は最終的には、関係者を入れて20人程度だったでしょうか。だんだんと盛り上がってきて、皆さん軽食にはほとんど手もつけずに話し込んでいたようです。気が付けば10時になっていたので、わたしもその時点で引き揚げましたが、結局半数くらいの方としかお話しできなかったような気がします。

わたしは現在製作中のBluetoothヘッドフォンアダプタをBlueSAMと名付けて、その概要をプレゼンしました。

BlueSAM

このプレゼンを介して、初めて公表させていただいたのですが、今回のプロジェクトでも使用しているBluetoothモジュールであるWT32を電子工作愛好者のために販売する計画を進めています。振り返れば、WT32に触れてから1年近くが経過しておりますが、残念ながらこのモジュールは国内では一般向けには販売されていません。わたしは海外からの通販で購入していますが、そのままの状態では国内法規(電波法)で要求される証明を経ていないため、違法状態で使用していることになります。一般に技術適合基準(技適)と呼ばれる、電波法上で必要とされる技術基準に適合することが証明されてないからです。

この技適問題については、昨年も1度記事を書き、コメントも頂戴しました。その後も自分なりにトラ技の記事を参考にしたり、TELECが開催する無料講習会「2.4GHz帯　技適及び認証に関するミニ講習会」に参加したりして、どうすれば技適を通せるかについて調査、検討をしていました。その概要を整理すると次のようになります。

1. 適合を証明するための方法には、「技術適合証明」と「工事設計認証」の2種類がある。
2. 「技術適合証明」は1台毎に適合を証明するためのものであり、無線機1台毎に異なる証明番号が付与される。少量生産製品向け。
3. 「工事設計認証」は、同一の設計の無線機に対して、同一の証明番号が付与される。大量生産向け。
4. どちらの方法でも単に技術的データを提出するだけでなく、試験官の前で特性試験を実施する必要があり、そのための試験治具も必要。
5. 工事設計認証では、設計や製造段階での正当性がより強く求められるため、それを証明するための書類が必要。現実的にはISO9000の認証を持つものが申請あるいは製造する必要がある。

あくまでも個人の力だけでコトを進めるのであれば、制度的には「技術適合証明」の方がハードルが低いです。無線に詳しい知人のツテを辿るとかしていけば、経験者に出会えるかもしれません。ただし、この方法では1台毎の証明になり、申請台数に応じた費用が発生します。追加で増産すれば、再度審査を受ける必要も生じます。結果的に、1台あたりの審査費用が割高になります。

一方、「工事設計認証」では同一設計に対して、ひとつの証明/番号ですので、増産しても再審査は必要なく、すべての無線機に同一の証明番号シールを張れば済みます。そのためある程度台数がまとまれば、費用的にはこちらが有利となります。しかしながら、要求される提出書類は、もはや個人とかお友達の縁では処理しきれなくなります。製造品質も要求されるので、自分で起こしたPCBに手ハンダというわけにもいきません。ハードウェア的にはただのヘッダボードであり、極めて単純なものなのですが、それでもISO9000をもつ製造工場で生産してもらわないと、書類審査が通せません。

このようなわけでいたって単純な結論に達しました。「これは個人ではムリ!　絶対無理！!」申請書類の作成だけなら(TELECを含む)代行業者に頼めばお金で解決できますが、それでも必要な技術データをそろえたり、試験のための装置を準備するのは申請者の責任です。わたしのようシロートには、そのような知識や技術もありませんし、もとより申請代行だけにお金を費やすような余裕などあるわけがありません。わたしにできることは、ただひとつ。もう泣きつくしかありません。そこで、製造元であるBluegigaにコンタクト。大変ありがたいことに、日本におけるビジネス・パートナの某社を紹介していただきました。そして、震災の少し前に大森の某社を訪問して、社長のM氏と面談させていただくことができました。某社はすでにWT32を使用した製品の開発実績もお持ちであり、わたしの要望にも理解を示してくださり、ヘッダーボードの開発について検討していただくこととなりました。

そしてこの度、ヘッダーボードの価格と納期についての見通しがたったので、「トラ技オフ会」の場をお借りして発表させていただいきました。7月中に販売開始。9,800円でおわけする予定です。Sparkfunのこのボードが90ドルしますので、工事設計認証取得済みで、9,800円は大変お値打ちだと思います。これで儲けようなんて思っていないので、全く利益をとっていない値段です。そのため、当初は直接販売になると思います。販売委託とか、ネットショップを利用したりすると少なくとも10%程度の手数料がかかりますので、それがそのままわたしの赤字になってしまします。どうしても1万円を切る価格で個人愛好家のために提供したいので、直接販売にせざるを得ません。

詳細については販売開始時期が確定した時点で、再度当ブログでも案内したいと思います。質問等があれば、左のメッセージボタンを使ってわたしにメッセージを送ってください。もちろん、「今のうちから予約を入れておきたい」というのも大歓迎です。

操作用スイッチ

これまでデバック用コンソールからのコマンドで操作していましたが、そろそろ操作用のスイッチを付けないと不便になってきました。そこで、基板右上部分にSparkFunで買ったNavigation Switchを２つ配置しました。




これまでBreakoutの方は何度か使ったことがあるのですが、スイッチを単体で使うのは初めて。今回もBreakoutとスイッチ単体部品の両方を購入してあったのですが、breakoutの方を載せるだけのスペースが無くなってしまったので、やむを得ずに表面実装部品単体で使わざるをえなくなってしまった次第です。しかし、実際に基板に載せてみると、端子間隔は0.1"になっておりユニバーサル基板に無理なく載りました。基板の穴と端子位置には少し間ができてしまうのですが、ハンダをブリッジさせてやることで難なくつなげられることがわかりました。こんなに簡単なら、もっと早くに挑戦してみれば良かった。もうBreakoutを買うことはないでしょう。

スイッチを載せたものの、まだ未配線です。スイッチひとつあたり3端子なので、SAM3S4AのGPIOが6つ必要になるわけですが、まだどの端子を割り当てるかを決めていないのです。きょうはこれからケース加工作業を始めて、そのあとで配線しようかと思います。