圧電スピーカを追加

電話機TF-08のキーパッドとフックスイッチも配線完了。そしてベル音用に圧電スピーカを載せてみました。



試しに鳴らしてみると音量が小さい印象。システムは3Vで動かしているので、電圧が低いのがいけないんでしょう。というわけで、手持ちのLTC1144を使って圧電スピーカに加わる電圧を倍にあげてみました。少しは大きくなったような気もしますが、期待したほどの効果はなくガッカリ。



キーパッド部分は5X4のマトリックスになっています。フックスイッチを加えて、合計10ポートを使用しています。キーパッドの上部には左右にLEDが配置されており、オフフックや着信時に点灯、明滅させることができますが、こいつはまだ未配線。

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ジャックの配線はできたので、ソフト入れてアンプの動作確認に進むことにします。

2.0mm --> 2.5mm ピッチ変換

ここのところまとまった時間をとることができないので、ちっとも工作の方が進んでいません。秋月A基板に受話器上部を載せることを決めたまのの、キーバットのケーブルが2mmピッチになっていました。線をばらせばユニバーサル基板に簡単にハンダ付けできますが、配線変更がしょうじたりすると面倒なので、ソケットをつかってつなぐことにしました。Aitendoなら2.0mmと2.5mmの変換基板があるだろうと思って探したら、やっぱりありました。



20x2ピン用なのですが、切るのも面倒なので、そのまま使用。





Aitendoはピッチ変換基板の種類がずいぶんと増えたようで、助かりますね。ただし、生産数が多くないので、在庫が切れるとどのくらい待たされるのか全くわからないのが不安です。おまけに、生産ロット毎に基板の色だけでなく寸法まで変わったりするし。

iWRAP5.0.1

10月10日付けでBluegigaがiWRP5の正式発表をしています。この事実には気がついていたのですが、5.0.0のコードはずいぶんと前にリリースされていたので気にも留めていませんでした。きょう改めてサポートを覗いたら、更新が追いついていなかったドキュメンとが更新されたとともに5.0.1がリリースされていました。

早速ダウンロードしてみるも、リリースノートが無いために5.0.0からどういうバグが修正されたのかについては言及無し。正式アナウンス時には5.0.1になっていたわけなので、5.0.0は無かったことにしたくらいに致命的なバグがあったといということかな? 簡単に調べてみるも、わたしが9月に報告しておいたVOLコマンドに関わるバグはまだ修正されていなかった。残念。

気がつくといつのまにかzendeskを動かし始めている様子。今後は、こいつでバグ報告すればいいかな。Forumもできたようですが、Feature requestの受付けはしても、ユーザ間の情報交換の場としての準備はできていないようです。

妄想から実現へのはじめの一歩

先月手持ちの電話機の中を覗いて以来、中身を入れ替えてBluetooth化してみたいという妄想に駆られていました。しかしながら、この決められたスペースの中に綺麗に部品を収めるためにはキチンとプリント基板をこさえねばなりません。１枚の基板できれいに作ろうと思うと、Eagle無償版のサイズ制限を超えてしまいます。2枚に分けるのも一案ではありますが、１枚もの基板をつくるよりも手間が増えるだけです。妄想を現実化するためには、きちんと回路の設計をすまさなきゃいけませんが、おおよそのイメージがあるだけなんで、やはりまずはプロトタイプを作成して動作確認をしておきたいところです。

どうしようか、いろいろ思い悩むばかりでちっとも手が動かずにいたのですが、ようやくと方策を決めました。初心に立ち返って、秋月A基板に組むことにします。いままで受話器ケースの中に組み込むという考えにとらわれていましたが、受話器ケースは上下２つの部分に分けると、その上側はちょうどA基板の上にネジどめできることに気がつきました。さっそくキーパッドケーブルがつながっているフラットケーブルを下部基板から切り離して、ケースを上下ふたつに分離。



A基板の上に上部を載せると基板からはみ出て見えますが、固定用ネジ穴のついた足はちょうど基板上に乗っています。



うん。これなら左側の空きスペースにWCA-009、マイコン等の部品を載せて仕上げることができそうです。



下部基板からは、フックスイッチを取り外して、A基板に載せかえることにします。まだ半田付けしてませんけど。キーパッド下にも充分なスペースが空いていますが、ここに受話器下部にあった圧電スピーカをもってこようかと思います。

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接続してはいけません。(笑)

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コマンドを使って明示的に送信電力を指定することで解決できます。




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

Arducam

ここのところCMOSカメラはeBayのelectronics_leeというお店で買っているのですが、ここの新製品でArducamを知りました。

CMOSカメラのシールドなのですが、今後OV7670に加えてより解像度の大きいOmnivisionのカメラやAptinaのカメラをサポート予定としているので、今後の動きをウォッチしておこうかと。CMOSカメラのモジュールは信号の種類はほとんど同じなので、ピン配置と電圧が同じならば、差し替えて使うことができます。このシールド用にサポートするモジュールであれば、それらの問題がクリアされているはずですし、サンプルのソフトを見ればカメラの初期化手順を自分で調べなくても済むので、期待して見守っていこうかと。。

このボードの説明を読むと、なにやらCPLDを積んではいるようですがRAMはないようです。そのため、LCDのGRAMをフレームバッファとして使い、これを読み出してSDカードに保存するとのこと。この方式ではカメラの解像度が高くても意味ないんですが、そこんところはどう解決されるのでしょうか？AVRをつかってQVGA画像(320x240)を使って保存すると10秒かかるというのもねぇ。。AVRじゃなくてMapleやChipkitで使えるようにすることで逃げをうつようですが。

そして、もうひとつ気になったのはレンズについて。ズームできるのはおもしろそうですが、もはや基板はレンズに支えてもらうことになるようです。

SAM3Sをつなげる

先日作成したWCA-009ボードにSAM3Sのボードをつなげてみました。



マイコンボード側にはタクトスイッチを１つだけ付けましたが、これはフックスイッチ用のつもり。このボタン操作で着信応答や切断操作をします。



シリアルでWT32とつなぎ簡単な処理しかしないつもりなので、高機能なマイコンである必要はないのですが、結局SAM3Sを使うことに。ほんとうはSAM3Nを使ってみようかと思ったのですが、値段も入手性もSAM3Sとたいして変わらないようなので。トラ技付録のLPC1114を使ってみようかとも思ったのですが、ちょっと実験するにはやはり使い慣れたSAM3Sの方が作業が早いので、しばらくはこれで。

この用途ではUSB使わなくてもいいので、SAM3Sは水晶無しで内蔵RC発信器の12Mzで動作させてみることにします。実は、SAM3Sには水晶がつながっていないとちゃんと動かないパーツがあるというバグがあるのですが、どうやらこのチップは問題なく動作してくれるようです。