直接つなげればできること

今までできないと思い込んでいたことが、実はできるとわかったのでメモ。

欧米の一般的な端末では、ATコマンドでSMSを送信することができるのは知っていましたが、自分の端末ではできないのだと思っていました。いまさらながらですが、自分のGalaxy S3をUSBでMBAにつないでCDCで接続。ATコマンドを叩いてテキストモードに設定して、メッセージを入力してみたところ、ちゃんと送信できました。



メッセージを入力して、最後にCtrl-Zを入れてやると送信されます。
ただし、テキストモードだと日本語を送れるのかどうか不明。ターミナルソフトのエンコーディングを変えてみると、ATコマンドがエラーを返します。パケットモードを使えばいいのかな？パケットモードのフォーマットを調べて、コード変換処理をすれば、きっと送信できるのでしょう。

これまでもこのATコマンドを何度も試してはいたのですが、エラーが出るのでサポートされていないと思っていましたが、その原因はいつもBluetoothを使ってHFPで接続して、ATコマンドを叩いていたからでした。何のことはない、USBで直接つなげば使えるんじゃありませんか。直接接続とHFP接続ではできることが違っていたんですね。1年ものあいだ、こんなことに気がつかなかった自分のアホさかげんにあきれます。

フーン、そうかぁ。そうすると充電器に見せかけて、実は勝手にSMS送信してしまう「イタズラ・ガジェット」とかつくれちゃうわけですね。これだけじゃ単なるイタズラですが、充電器になんらかの付加機能を付けることはできそうですね。

RN-42-EK

秋月でRN-42-EKの販売が開始されたようです。ようやくと、認証取得済みモジュールがリーゾナブルな値段で買えるようになったんだなぁという印象を受けます。Mouserと変わりない値段で買えるというのもいかにも秋月らしくて、好ましいところ。

秋月にはMicrochipの代理店チャネルで入荷するんでしょうか。RN-42の開発元は Roving Networksですが、2112年に買収されてMirochipのグループ企業となっています。RN-42-EKのボードにはMicrochipの刻印が入っているのですが、ボード自体はやはりRoving Networkが買収前に設計を完了していたようです。秋月の写真でも、FTDIロゴが丸見えですから。

あいかわらず

1年ほど前にGalaxy S3とメディア・プレーヤという記事を書いたのですが、なぜかこの記事へのアクセスが絶えることがありません。S３もソフトウェアアップデートにより今ではAndroid 4.1.2になっていることだし、DoCoMoのメディア・プレーヤでもメタ・データが拾えるようになっているかもしれないと思い、久しぶりに動作確認してみました。

ダメです。なんにも変わっていません。Google提供の音楽プレーヤであれば問題なく動いてくれます。この1年の間にBlueZではAVRCPサポートも充実したようなので、Androidのアップデートによりメタデータ取得についても改善が確認できるのではないかと期待していたのですが、裏切られました。

I2C接続小型LCD

先週、秋月からピッチ変換基板付きのI2C液晶が発売になったので、買ってきました。2.5mmピッチで端子出ているので、試し組みしてみるには便利に使えそうです。



写真の右側は、以前Strawberry Linuxで買ったI2C液晶モジュール。サイズもコントローラも同じですが、色味が違っていました。

この秋月の新商品、意外なことに変換基板の説明/回路図がついていませんでした。モジュールの説明書の参考回路図とほぼ同じではありますが、秋月にしてはめずらしい。プルアップ抵抗も実装されており、ハンダジャンパで有効になるようになっています。

フィルター設計ツールを探す

SAM4Lにスペアナ表示機能を実装する作業を継続中。CMSIS-DSPの準備はできたので、実機での実装方法を検討します。CMSIS-DSPに用意されている機能を使ってスペアナ表示を実装するには、つぎの２つの方法が考えられます。

1. FFTを使う。ストレートな方法ですが、ライブラリには窓関数処理までは含まれていないので、自分で補う必要があります。FFTでは帯域を点数で均等に分割したバンド幅毎のレベルを得ることができますが、オーディオ信号では低域の変化が主ですので、FFT結果をそのままプロットしても山が左に寄った表示になってしまいます。オクターブバンドのような帯域毎に結果を整理してから、表示した方が良さそうです。
2. BPFを使う。表示するバントに対応するBFPを用意して、各帯域のレベルを調べる。従来のアナログ方式のスペアナ機能を、そのままデジタルに置き換える。

FFTを使うとなると、512点か1024点のFFTが必要ですね。このあいだIIRフィルタを使ったイコライザの動作確認をおこなったこともあり、今回はIIRでBPFを作ることでスペアナ表示してみることにします。

グライコの例では、Biquad IIRフィルタの係数はあらかじめMATLABで計算したものが使われていました。スペアナ用にBPFを用意するには、Biqud IIRフィルタの係数を求めてやらねばなりません。フリーのツールとかWebページとか探してみたのですが、なかなか気に入るものが見つけられません。とりあえずは、次の２つのツールで係数を求めて試してみようかと思います。

• DSP Link
  フィルタの次数を指定することで、Biquadを複数つなげたフィルタを設計してくれる。係数を固定小数点形式で出力する機能も用意されており、量子化ビット数を15あるいは31と指定することでq15_t, q31_tの値を得ることができる。
• PurePath Studio GDE
  TIのCODEC用のデザインツールですが、その中にBiquadのGUI設計機能が含まれています。GUIでは複数段のBiquadから構成されるBPFを直接デザインすることはできませんが、各段とも同じ中心周波数/バンド幅のBPFを複数段つなげてみようかと思います。係数はXMLファイルに書き出すことができますが、浮動小数点形式なので自分で固定小数点に変換してやります。

Biquad一段でもBPFは作れますが、急峻なフィルタ特性を得ることはできません。2段にすれば、まずまずだと思いますが、計算量も倍になるので実際に試してみるつもりです。スペアナ表示といっても正確な測定機能をめざすわけではなく、あくまでも音楽再生時のギミックなので、「それらしく」動くことが目標です。

在庫補充

本日発売の「トランジスタ技術８月号」にBlueHANDの製作記事を寄稿させていただきました。書きたいことはいろいろとあったのですが、ページ数の都合もありソフトウェア部分についての説明が足りなかったかなと反省しております。

	トランジスタ技術 2013年 08月号 [雑誌]
	CQ出版
	CQ出版

トラ技の発売に合わせて売店には実験セットを４セットほど用意していたのですが、今月になって続けて注文が入ったために気がつくと残り2セットになってしまいました。補充作業を開始したところ、3.5mmのオーディオジャックの在庫が無くなっていることに気がつきました。慌てて手配したので、今週中には5セットほど補充できる予定。やはり、秋葉で簡単に入手できるパーツで組むべきだったか。。。

CMSIS-DSPのグライコを試す - その2

前回の記事では、CMSIS-DSPの例としてあげられているグライコを実際に走らせてみて、実時間でのオーディオ信号処理をやってみました。サンプルのとおりだと、およそ35MHzのクロック速度が必要なことがわかりましたが、もともとのプログラムはCortex-M4, M3, M0のいずれでも動作するようになっています。Cortex-M4/M3であれば、Biquad IIRフィルター処理には高速版のAPIを使うことができるので、こちらを使うようにプログラムを変更してみました。具体的には、arm_biquad_cascade_df1_q31( ) の代わりに arm_biquad_cascade_df1_fast_q31( ) を使うように変更するだけです。こちらを使うと、演算精度は犠牲になるものの、実行速度は速くなるハズだったのですが。。。



Fast版を使うと40MHz越えです。予想に反してfast版のAPIを使うと遅くなっちゃいました。どうして? 　8ビットとか16ビットの演算であれば、Cortex-M4のSIMD命令を使って複数の乗算や加算を並行実行できますが、32ビットだとその恩恵を受けることができないからでしょうか？でも、これは早くならない理由にはなっても、遅くなる理由は別にあるはずですね。生成されたコードをobjdumpして調べれば原因調査可能ですが、Cortex-M4のアセンブラ勉強しなくてはならないので、そこまでの深追いは断念。せっかくなので、別の場所をいじってみます。

グライコのサンプルは、５つのバンドを５つのフィルターを通して処理していますが、低域の２つのフィルタにおいてはノイズを軽減するために32x64ビットの演算をするarm_biquad_cas_df1_32x64_q31を使用しています。通常版が内部的には64ビットでの演算をおこなっても状態変数には32ビットしか保存しないのに対して、こちらのAPIでは状態変数も64ビットで保存しているので32x64ビットの乗算が必要となり、時間がかかります。この部分を通常版のarm_biquad_cascade_df1_q31( ) に置き換えれば、演算精度が失われ音質は悪くなるでしょうが、時間は短縮できるはずです。

Fast版を使うのはやめて、32x32ビット演算に変更。効果てきめん。10MHzから15MHz程度で間に合うようになりました。これならステレオ処理もできるじゃんと喜びましたが、副作用も顕著。最低域の100Hz以下のバンドはゲインを付けると全く使い物にならなくなってしまいました。量子化誤差の影響でフィルタ動作が安定領域から逸脱したということかな。うーん、IIRフィルタは難しい。

CMSIS-DSPのグライコを試す

SAM4LにつなげたSPI LCDでスペクトル表示を行うべく、その手段を調査中です。まずは、以前から使ってみようと思っていたCMSISに含まれるDSP Software Libraryを準備すべく最新版のCMSISをダウンロード。ドキュメント一式も中に含まれています。これまでも、CMSIS-COREの部分のAPIを使ってはいたのですが、CrossWorksのCPUサポートパッケージの中に含まれているものを使っていただけだったので、CMSIS一式をちゃんと見てみるのは初めてになります。

今回はDSP Libraryの部分を使ってみたいので、CMSIS-DSPの部分に目を通します。このライブラリ、Cortex-M3, M4だけでなくM0やM0+までサポートするようにできているのですね。SAM4LはCortex-M4なので、マクロARM_MATH_CM4を定義して、コンパイルしてやります。FPUが使える場合には__FPU_PESENT = 1 とすれば良いのですが、SAM4LはFPU無しなのでこれは必要無し。

さて、DSP libraryにはexampleもいくつか含まれているのですが、そのひとつとしてグライコ(Graphic Audio Equalizer Example)が用意されています。Exampleでは、あらかじめ用意されたオーディオデータをグライコ処理を通して、その結果を確認するというものになっていますが、処理の中心部分は5つのバンドに対応する ５本の 4次のBiquad IIRフィルターを通すというものになっています。演算処理には固定小数点形式であるq31_tを使っているので、このサンプルをほとんどそのままSAM4Lで動かしてみることにしました。Exampleの説明文中では明記されていませんが、周波数特性のグラフを見ると44.1KHzサンプリング用に設計されたフィルターであることが読み取れますので、Biquadフィルターの係数はそのまま流用することができます。

現在、音楽の再生処理はDMAを使って128サンプル毎にIISCで取り込んで、そのままABDACBに送っています。そこで、そのまま送るのではなく、イコライザー処理に対応するIIRフィルターを通した結果を送るようにしてやれば、イコライザーを通した結果を実際に耳で聞くことができます。まずは、試しに左チャンネルだけイコライザを通して、右チャンネルはそのまま再生することにしてみました。

結果、クロック24MHzでは動きませんでした。イコライザーのフィルタ処理は、128サンプル毎に行いますが、当然のことながら、次の128サンプルの受信が完了する前までに終了させねばなりません。44.1KHzサンプリングなので、128/44100 = 0.0029となりおよそ3msで処理を終えねばならないのですが、処理速度が足りずに間に合いません。しょうがないので、一気に48MHzにクロックを上げてみると、ちゃんと動くようになりました。FREQMを使って調べてみると....


となり、およそ38MHzのCPUクロック速度を必要としていることがわかります。FREQMでのクロック数計測には7.6msほどかかりますので、この間に2回はDMA終了割り込みに伴いイコライザー処理が走ります。そのため、FREQMの計測結果は、イコライザー処理によるCPU負荷に応じて変化します。SAM4Lでは48MHzがクロックの上限なので、とてもじゃないけどステレオ処理には力不足であることがわかります。

今のところ、サンプルのコードをそのまま持ってきただけなので、イコライザーのゲイン設定は固定となっていますが、イコライザーを通すと音が変わることが良くわかります。ちょっと手を加えればCLIからバンド毎にゲインを設定できるようになるので、やってみようかな。また、DSP LibraryのBiquad IIRフィルタには、高速処理が可能なAPIも用意されているので、そちらを使うようにプログラムを修正してみるつもりです。

音声パス切り替え

Bluetoothヘッドセットの利用経験の無い方にBlueHANDをデモすると、しばしば見られる行動がひとつあります。それは、「Bluetooth接続したので、こちらのBlueHANDで着信応答や、発信ができます。」と説明しても、実際に着信が入ると先に鳴動する携帯やスマホので思わず応答してしまうという条件反射的とも言える行動です。

もちろん、携帯側でも応答はできます。ところが、次の段階で困った状況が発生します。「もしもし?」と話しかけても相手の声は聞こえません。なぜなら、相手側の音声は、HFPで接続されたヘッドセット側に流れており、携帯側では音声再生されないからです。こういう時に、どう対処すればいいかというと、慌てずに音声パスをBluetoothハンドセット側から携帯側に切り替えればいいのです。通話中の操作メニューや画面に切り替え法が用意されているハズです。例えば、Galaxy S3では下図のように「ヘッドセット」のタッチボタンが表示されています。図の状態はボタン表示が緑色になっており、ヘッドセット側が有効になっていることを示しています。ボタンを押せば、音声は端末側に切り替わり、ボタン表示はグレーに変化します。



上記は携帯端末側での操作でしたが、音声パス切り替えはヘッドセットデバイス側でも操作可能であるべきです。実際、HFPの仕様書では必須項目となっていますので、この機能をもたないヘッドセットがあるとしたら、それはHFPに準拠していないことになります。それでは、これらの機能をWT32を使って実現するには、具体的にはどのようにすれば良いでしょうか？

まず、HF側であるWT32が音声パスをもっている状態から, AGである携帯側に音声パスを転送する手順ですが、これは極めて単純明快です。音声パスである、SCOリンクをクローズすればいいだけです。

closeコマンドでクローズしたのは、音声パスであるSCOコネクションでありHFPリンクではないので、HFP接続や呼が切れてしまうことはありません。次に、WT32側に切り戻す方法ですが、こちらは

というようにsco openコマンドを用います。ここで引数として指定している番号はHFPのリンク番号になります。このコマンドは、AG側に対して音声パスを開くように要求を出し、その結果としてAG側からSCOリンクが張られてきます。

SCO OPENコマンドについては、iWRAPのマニュアルにもちゃんと記載されているのですが、どのような局面で使われるかという説明に欠けています。わたしは、音声パスを切り替えるにはどうすれば良いかを考えてみて、SCO OPENコマンドが使えるのではないかと思いつきました。最初から、マニュアルで上記のような例を明示してもらえれば、わかりやすいのですが。。