力不足

W-SIMソケットとLPC2388をつなぐ配線ができたので、通信試験を開始。ATコマンドを打って、OKが返ってくることが確認できたので、続いてW-SIMを音声通話用に初期化するコマンドを送信。これに対しても予期した応答が返ってきて、いい感じだと思ったのですが。。。

なんと、初期化コマンドを送信後、およそ7秒するとMCUにリセットがかかってしまいます。何度やっても同じ。確実に再現することができ、およそ7秒でリセットしてしまいます。何かメッセージを受信しているわけではないので、受信処理の問題ではないハズです。DCDやRIといったモデム信号の状態変化によて割り込みがかかっているのかもしれないと考え、調べてみましたが、そういうわけでも無いようです。試しに契約の切れた古いW-SIMに挿し換えてみると、なんとリセットはかかりません。しかし、契約が切れているので、このW-SIMでは発呼も着呼もできず、動作確認作業を進めることもできません。

ふと、思い出したのがW-SIMは意外と電流を消費することです。以前、USB電話機をつないだ時には、着信に応答して通話を開始するとリセットがかかってしまうという問題に遭遇し、結局ACアダプタによる給電に切り替えたことがあります。今回は、LPC2388基板上のレギュレータで生成した3.3Vで、W-SIMとLCDを動かしていますが、この電流が不足しているのかもしれません。そこで、LCDを外してみたのですが、症状は改善されず、やはりリセットかかります。しょうがないのでW-SIMを3.3Vで動かすのはやめて、USBからの5Vを使うように変更したところ、ようやくと問題解消しました。MP3プレーヤでは、同じレギュレータでLCDだけでなく、CODECやFMチューナ、そしてBluetoothまで動かしていたのですが、どうやらW-SIMを動かすには力不足だったようです。

初期化コマンド投入後、しばらくしてリセットしてしまうのにも、それなりの理由があるのでしょう。契約切れのW-SIMで問題が発生しないところをみると、端末の認証を終えて、位置登録をしようとする際に電圧降下が発生してリセットがかかっているのでしょうか。もっとも、契約切れのW-SIMとはファームのバージョンが異なっていたので、そこに動作の違いがあるのかもしれませんが。。

新たな実験ボード

次のプロジェクトに向けての作業を開始しました。MP3プレーヤとW-SIMを組み合わせてBluetooth化することを目標とします。MP3プレーヤではA2DP, W-SIM通話ではHFPを使うことになるのですが、そもそもこのふたつを組み合わせてちゃんと動く条件を確認する作業が必要となるので、まずはその段階を目指して実験ボードを用意することにしました。

しばらく悩んでいたのですが、SAM3のチップがまだ入手できないこともあり、MCUにはLPC2388を使うことにしました。MP3のソフトがそのまま流用できますし、ハードもわずかな変更で済ませることができます。今回はBluetoothを使うことをメインに考えて、CODECチップは載せないことにします。また、FMチューナも省略。主要モジュールをいつもの秋月基板に並べてみました。



W-SIM部分には、先日プリント基板を作成した際に一緒に面付けした基板を使用しました。LCDの下からソケットが顔をのぞかせている部分には、同じく先日作成したWT32用基板を載せるつもりです。とりあえず、主要ソケットをハンダ付けして、配線を開始したところです。

NS001Uを開いてみた

先週、W-SIMのIF_SEL信号はUARTとUSBのインタフェース切替え信号だろうとの情報をいただいたので、手持ちのNS001Uを開いてみました。以前、DDを購入した時には即日分解してみたのですが、NS001UについてはどうせUSB変換チップが入っているだけだろうと思い、中を覗いてみたことはありませんでした。

ケースは小さなネジで止めてあるだけなので、時計ドライバで簡単に開けることができました。



フューズらしきもの1点、ダイオード2点、大きめの抵抗らしきもの1点。保護用のパーツだけで、単純にUSB端子がW-SIMソケットにつながっているだけなのかとも思いましたが。。。

裏返して見ると、予想に反して結構な数の部品が。。。やたらと、RCがある印象を受けます。



USBコネクタに直結というわけではないことはわかりましたが、それ以上の究明については断念。老眼の身には、こういう小さい部品の番号を読み取るのはかなりつらいので。とりあえず、U2は終端ならびにフィルタ用のデバイスだと想像しますが、U1, U5はなんだろう。いちおうIF_SEL端子をテスタであたってみると、Hレベルになっています。DDではLだったので、確かに違いはあるようです。

USBとして使うには思いのほか部品数が必要なように見えるので、「やはりマイコン工作には、これまでどうりUARTにつなぐのが一番簡単だな」というのがきょうの結論です。

進まぬ世代交代

近頃、Netduinoが話題のようです。この間までは、FEZ Dominoが占めていたARM版Arduinoのポジションをめぐっての競合というところでしょうか。

Netduinoはその安さもあって注目されています。使用されているのがATMELのAT91SAM7X512で、このチップだけで2000円ほどしてしまうのに、このボードは35ドルと激安。たしかにボードとしては安いわけですが、それでもMCUの性能を考えれば、やはりCortex M3のSTBeeの方が魅力的でしょう。AT91SAM7X512の値段が高いのは、古いARM7ベースのチップという要素が大きいですよね。FEZ DominoはLPC2388で、こちらもARM7ベースです。どちらも比較的新しい製品なので、Cortex M3で作った方が安くできるような気もするんですが、ARM7を選択しているそれなりの理由があるように思われます。勝手に想像してみるに、内蔵RAMの大きさが関係しているのでしょうか？

LPC2388は基本64KBのRAMに加えて、Ethernet RAM, USB RAMの空間があり、合計すると96KBになります。AT91SAM7X512は、128KBのRAMを持っており、このサイズはSAM7シリーズ中での最大RAM容量になっています。一方、多くのCortex M3のMCUでは内蔵RAMは64KB程度です。その64KBも内部的にふたつの空間に分けられていることも多く、非連続だったりします。.NET Microで扱うに際しては、連続で容量が多い方が管理も容易で、ユーザプログラムにも多くのRAMを割り当て易いのではないでしょうか。

さて自分を振り返ってみても、なかなかCortex M3に移行できずにいます。今年はSAM3UやSAM3Sを使ってみるつもりでいたのですが、どちらもいまだにサンプリングの状態で、なかなか入手できるようになりません。この調子だとSAM3AやSAM3Xはいったい何時になるんだろうと気を揉んでいます。そうこうしているうちに、「携帯できる電話機」で使用しているAT91SAM7A3がMature Device扱いに変更され、Not recommended for new designsと記されるようになってしまいました。オイオイ、引退させるなら世代交代のための代替製品(SAM3A?)を用意してからにしてくれよ!!

そんなわけで、次のプロジェクトではSAM3は使えそうもありません。代りに何を使おうか思案中。LPC2368かLPC2369でも使おうかとも思い、マニュアルを改めて読んでみると、SD/MMCインターフェースが無いことに今頃気が付きました。やっぱり、手持ちのLPC2388付録基板を使うのがてっとり早いかなぁ。

W-SIMのPCM信号について

W-SIMの信号については、そのピン番号と信号名がWCMのページで公開されています。おそらく通信関係の知識をおもちの方であれば、これらの名前をみるだけでおおよその意味が理解できると思われます。しかしながら、通信関係の知識が無いと、特に音声関連の信号にはなじみが無いと思われます。そこで、今回の記事ではW-SIMを使うための、各ピンの扱いについて簡単に説明してみたいと思います。


まず、誰にでも理解できるのがVcc とGNDです。わたしは、Vcc = 3.3Vで使っていますが、仕様としては5Vまでの電圧で使えるようです。

TXD, RXD, RTS, CTSの4本は、RS232Cを知っている方ならご存知のとおりのシリアル通信制御用の信号です。W-SIMの信号名はホスト側から見た信号に合わせてつけられていますので、それぞれの信号をマイコン側の同じ名前の端子に直結すれば通信できます。例えば、W-SIMのTXD信号(1番ピン)は、マイコン側のUART(あるいはUSART)の送信端子につないでやります。すなわち、TXD信号は入力信号であることに注意してください。他の端子も同様です。

DTR, DCD, RIはちょっとなじみが薄いかもしれませんが、モデム制御用の信号です。マイコン側のUARTがモデム制御信号の端子を持っていれば、それらと直結してやることができます。マイコンにモデム制御機能がなければ、DTRをLにしてやれば、DCD, RIは未接続でもW-SIMを動かしてやることはできます。INS信号は、W-SIM側に電源が入っており、選択されていることを示す信号のようです。モデム制御信号のDSRと同じように扱えるようです。IF_SEL信号は、複数のW-SIMがある場合の選択信号のようなものではないかと想像しています。Lレベルにしてやる必要があります。

と、まぁ、ここまではマイコンを使っている人なら、ほとんどの人が何の問題もなく理解できるところだと思います。わかりにくいのは、音声PCM信号用の4つの信号の意味でしょう。PCMについては、音声や音楽のデジタル化の基本技術ですので、多くの方がご存じだと思うので、基礎的な説明はここでは省略します。電話用途では、人間の音声の帯域が4000Hzを上限として充分に表現できることから、8000Hzでサンプリングするのが標準となっています。国内のISDNあるいはひかり電話のようなデジタル回線上では、さらにサンプリングされた値を対数圧縮した、u-Law符号を用いて1サンプルを8ビットで表現しています。この結果、8 x 8000 = 64Kbpsの帯域で音声を送ることができます。この規格については国際標準であるG.711で定められていますので、もうちょっと勉強したい方はこちらを参照してください。

W-SIMでも上記のように8000Hzでサンプリングした8ビットu-Law符号によって音声データを表現しており、PCM信号の4つの端子を使ってその送受をおこないます。それぞれの信号は次のような意味となります。それぞれの内容の項が示すように、信号は適切なCODECを選択すれば、CODEC側の信号と直接接続することができるようになっています。

信号名	内容	意味
PCMCLK	PCM CODECクロック	コーデックに供給するデータシフトクロック
PCMSYNC	PCM CODEC同期信号	CODECに供給する8000Hzのフレーム同期信号
PCMIN	PCM CODECデータ入力	CODECのデータ入力端子に与える回線からの音声データ信号
PCMOUT	PCM CODECデータ出力	CODECのデータ出力端子から受け取り、回線へ出力する音声データ信号

CODECというのは、Coder/Decoderのふたつの言葉からなる合成語で、簡単なはなしがA/DとD/Aが一緒になった音声信号用のチップのことです。PCM信号のようなデジタル信号がつながった端子と、マイク/スピーカがつながったアナログ側端子の信号とを相互に変換してくれます。W-SIMを直接接続できる適切なコーデックを選択するための条件は次のようになります。

• W-SIMからのPCM信号はロング・フレーム形式となっているので、このフレーム形式をサポートしていること。
• W-SIMはPCMデータをu-Lawで送受するので、u-Law圧縮をサポートしていること。
• PCMCLKとして384KHzをサポートできること。
• CODECの動作に必要なクロックは、PCMCLKと非同期なクロックが利用できること。

W-SIMからのPCMデータはPCMCLKに同期して送られてきますが、PCMCLKは経験的に384KHzになっているようです。PCMCLKが384KHzであるのに対し、実際の音声データは64bps分しか使用しませんので、PCMOUT/PCMIN信号の有効部分の始まりを示すための情報が必要となり、そのための信号がPCMSYNCです。PCMSYNCはPCMCLKと同期しており、8000Hzでサンプリングされた音声データの位置を示すことから、その周波数も8000Hzとなります。PCM信号にはPCMSYNCとPCMOUT/PCMINの位置関係によっていくつかの種類がありますが、次に示すショート・フレーム同期とロング・フレーム同期が代表的な同期フォーマットであり、わたしの使っている青耳のW-SIMではロング・フレーム同期が使われています。ひょっとすると、機種によってはATコマンドによってフォーマットを選択することが可能なのかもしれませんが、未確認です。

ロング・フレーム同期


ショート・フレーム同期


ショート・フレーム同期ではフレーム同期信号(SYNC)の長さは１クロック分なのですが、ロング・フレーム同期ではデバイスによって異なっていたり、設定可能になっていたりするようです。どちらのフォーマットでも、1秒間に8000サンプルが送受されることに変わりはありません。受信の場合を例にとれば、受信できた8ビットのデータはu-Law圧縮されているので、まずこれを伸長してからD/A変換することでアナログ音声信号に変換することができます。CODECチップは、この処理をおこなってくれるわけです。

はじめてのプリント基板 -- 部品実装編

できあがってきたプリント基板にさっそく部品実装を始めてみると、次々とミスが見つかってきました。事前にパターンの確認をちゃんとしていれば、防げたミスばかりだったのですが。。。

まずは実装後のボード外観です。左側の電話機をつなげるためのSLICボードを載せる構成になっています。ほんとうはSLICボードの大きさに揃えたいところなんですが、そうするとフリーのEableで作成できる基板サイズを超えてしまいます。部品数はそれほど多くありませんが、コネクタを配置するためにスペースを必要としている感じです。最初はSDカード・コネクタも配置するつもりだったのですが、SDカードサイズにすると自動ルーティングでルーティングしきれずに手作業が必要になりそうだったので断念。マイクロSDコネクタにすればいいだけのことなんですが、ライブラリ作るのが面倒だったので省略という手抜きです。



部品の実装はセオリーどおり、背の低いものからハンダ付けしていくわけですが、まず最初にでくわした困難がSLICボードに供給する2.048MHzの発振器です。データ・シートの推奨ランドパターンのとおりに部品ライブラリを作成しておいたのですが、部品から外に出るランド部分がほとんどなく手ハンダには不便なパターンになっていました。後から思えば当然のことですが、リフローするのであればパターンをわざわざ部品よりひとまわり大きくする必要もないということですね。となりの8ピンのモジュールはSLICボードで使用する5Vを生成するためのDC-DCです。こちらは、8ピンDIPとのことだったので、安易に8ピンTTLのパッケージデータを使ってパターンを描きました。ところが実装に実装する段になって、幅が10mil広いことが判明。ガーン。幸いなことに左右に余裕があったので、モジュールの足を切ってかわりに錫メッキ線で足を作りなおしてどうにか切り抜けました。



ランドが小さすぎたのはW-SIMも同じでした。こちらも推奨パターンをもとに作ってました。こちらはハンダレベラーに少量追加したハンダを、取り付け金具部分を熱して溶かすことで対応。ちょっと強度的に弱い部分が残ってしまいましたが。。



ミニUSB端子は配置位置の考慮が足りませんでした。ハンダ付けした後で、実際にプラグを挿そうとしたら、プラグが基板に当たって充分に挿しこめないことに気が付きました。ヤスリで削って対応です。その左は電源スイッチ代りのジャンパ。ほんとはスライドSWにするつもりだったのですが、買い忘れ。そのとなりのLEDは充電中表示のためのものですが、こちらも電流制限抵抗を買い忘れて、いまだに機能していません。一番左のコネクタはデバック用のシリアルですが、お世話にならずに動かすことができたので未実装です。



裏側にはジャンパを2本飛ばすことになってしまいました。緑色のビニル線はLCD用のリセット信号を忘れたためですが、こちらはもともと配線図上での引き忘れが原因。もうひとつは、下側中央のコネクタの端子間を錫メッキ線でつないでいます。こちらは、コネクタの端子番号を間違えて配線図を作製していました。



どうにか基板のミスの対応を済ませて、ケースに入れようとしたとろでさらにもう一点。基板とLCDをつなぐフラット・ケーブル・コネクタがSLIC基板にあたってしまいました。またもや、ヤスリで基板を削ることに。。。



と、まぁ、こんな具合でトラブルの原因は確認不足ばかりなわけですが、確認すべき要点がわかっていなかったということもあり、その意味ではいい勉強になりました。

はじめてのプリント基板 -- 製造依頼編

先日書いたようにGadget1 R2での出展に際して、「携帯できる電話機」のプリント基板を作製しました。プリント基板を作るなんて、じつに30何年ぶりかです。昔はレトラセットのインレタ(インスタント・レタリング)を使ってDIPランドパターンを転写、1mm～2.5mmくらいのレトラテープを引きまわしてパターンを作成、エッチングしてデジタル時計を作ったりしましたっけ。7490, 7492, 7447という当時の定番組み合わせです。8ビットマイコンの時代にはワイア・ラッピングで配線していたのですが、その後電子工作からはずっと離れていました。数年前にマイコン工作に復帰してからは、Eagleを使って回路図を描いてはいるものの、基板(ボード)を起こすのは今回が初めてです。そこで、事前チェックをしっかりやってくれて、初心者にも親切そうなP板.comさんに基板の製造を依頼することにしました。

まずはEagleでのboard作成ですが、時間がなかったこともあって、ほぼ自動ルーティング任せで済ませました。というか、手作業でルーティングするだけの技能も無いのですが。Eagleで使うデザインルールは、以前はP板からダウンロードできたと思うのですが、見つけることができなかったので、chakiさんのサイトからp-ban_min-0.130mm.druを拾ってきて使わせていただきました。Auto routingの際には Routing Gridを0.25mmに設定。こうしないと、0.5mmピッチのピンの中央部分からパターンを引いてくれないのですね。しばらく悩みました。

ガーバデータの作成手順については、P板.comにその手順が説明されていたので、それにしたがってデータを作製して、製造依頼。ほんとうは、ビューアを使って慎重にパターンの確認をしなければならないところですが、面倒だし、どのみちちゃんと確認できる自信もありません。製造ルールに合わない部分やおかしなところがないかは、P板さんも確認してくださるようなので、自分ではほとんど確認せずにP板さんまかせにしてしまいました。すると、データ提出の翌日にサポート担当の方から電話とメールが入り、次のようなご指摘を受けました。

1. ドリルの位置とパターンの位置が一致していない箇所が3か所ある。
2. ドリル不要と思われる箇所が２箇所ある。
3. 不自然なパターンになっている箇所があるので確認して欲しい。

確認してみると、いずれも指摘されたとおりで、1, 2については自動配線されたパターンを手作業で修正した際に、ドリルデータが更新されていなかったのが原因でした。3は自動配線結果が不自然なパターンとなっただけで、間違いはありませんでした。1, 2については、わたしがガーバデータを再提出するまでもなく、P板さんの方で修正データを準備してくださいました。そのため、わたしはその結果を確認して、製造に入ることを承認するだけで良かったので時間の節約にもなりました。ホント、大助かりでした!!

そんなこんなで、およそ1週間後にできあがってきた基板がこれ↓です。



ついでなんで、W-SIMソケットとWT-32のBreakout board用のパターンも用意して3種を面付けしてもらいました。メイン基板のサイズはフリーのEagleで作成できる最大サイズの100mm X 80mmです。面付けしてVカットを入れてもらったため、費用はおよそ3万円。1枚でも5枚でも値段変わらないので5枚製造してもらいました。

P板さんの確認のおかげてここまでは順調に進んできたのですが、実際に部品を配置、配線してみると考慮、確認不足が次々と露見してきました。その件については、また別の記事で。

Gadget1 R2

遅くなりましたが、「8/7のGadget1 R2に出展してきました」報告です。当日は、午前中約束があったので、11時半に入場して昼休みからの展示開始というスロー・スタート。ほとんど展示会場にしかいなかったので、セッションの状況を知らなかったのですが、どうやら参加者の方も午前中は少なかったらしいので、実際のところ昼開始で良かったのかもしれません。

「Blog読んでます」とおっしゃってくれた方が何人かいらっしゃいまして、それが何よりも嬉しかったですね。以前、1回だけ秋葉での会合に参加してデモしたことがあるのですが、大勢の方々の前でW-SIMジャケットを展示するのは今回が初めてのことでした。また、当日は夕方のLTの時間でもプレゼンの機会をいただいたので、この↓内容でお話しさせていただきました。持ち時間5分で喋れたのは9枚目の5号機の紹介まで。6号機の構想については喋れなかったので、ここで公開ということにします。

携帯できる電話機

さて、当日の展示では、今回新たに製作した箱を展示しました!!
memn0ckさんのこちらの記事も参照してください。



基本的なハードウェア構成は、ほとんど同じなのですが、思い切ってプリント基板を作って、電池もLiPonにすることで、わずかながらではありますが小型化を図ってみました。なにしろ、急遽作ることにしたのでP板.comからあがってきた基板を受け取ったのが、8月2日。先週は、この製作と動作確認、ソフトの一部変更でほとんどの時間を費やし、前日になってどうにか100円ショップで購入したハガキケースに収納。当日になって、電話機も少しでも小さくしようと思い立ち、出かけ際に家電量販店に立ち寄っていったというぐらいのドタバタです。そのため、ブログの記事どころか、プレゼンに新しい箱の写真を入れる余裕すらありませんでした。

Eagleでプリント基板を作るのは初めてだったので、失敗もいくつか。P板さんには、データ不備を指摘していただき助けられました。この点については別途、記事にしてみるつもりです。

当日は、kakoさんやmemn0ckさんにもお会いすることができました。また、午前中プレゼンをされたQualcomm Japanの山田社長ともお話しすることができました。「MTMにも出展せねば!!」という思いを強くした一日でした。

パルスダイアル対応

Gadeget1に向けて電話機ジャケットの体裁を整えていたら、パルス・ダイアルに対応していないことを思い出しました。使用している電話機は10PPS, 20PPS,トーンの選択ができるので、この際全部対応することにしました。

これまではトーン・ダイアルにしか対応していなかったので、10PPS, 20PPSに電話機の設定を変更すると、ダイアルした数に対応するOn-hook/off-hookのイベントが発生していました。このイベントの数をカウントすれば、パルスでダイアルされた数が判定できることになります。細かいことを言うと、パルス信号のメーク率の規定なんかもあるのですが、そんなもん判定しなくても実用上は何も困らないでしょうから気にしないことにします。On-hookを検出したら、一定時間待ってみてその間にoff-hookが検出たらパルス信号があったと判断することにします。タイムアウトが発生したら、ほんとうにOn-hookされたと判断します。

タイムアウト時間としては200msを設定。毎秒10パルスの10PPSのさらに倍の余裕をとってあります。そのため、10PPSと20PPSのどちらでもパルスダイアルを検出できます。ひさしぶりにパルスダイアルを使ってみると、次の桁をダイアルするのにずいぶんと待たなきゃならないので、えらい不便です。まぁ、好んでこれを使うことも無いわけですが、話のネタとして対応しているみたいなもんです。いちおう、これで黒電話をつなげることも可能となったハズです。

じつは、Gadget1に向けて大慌てでやっている作業があるのですが、その件についてはひと段落ついてから改めて報告したいと思います。

アラーム機能

電話機ジャケットにアラーム機能を追加しました。RTCであるPCF2127Aには、アラーム機能が用意されているので、これを使ってみた次第です。

まずはアラーム時刻の設定です。RTCに対してはI2Cでレジスタを設定するわけですが、電話機ジャケットが直接もつUIとしては電話機しかありません。そこで、設定用の特別な電話番号を用意して、それを使うことにします。今回は、99で始まる6桁の番号99HHMMをダイアルすることにしました。受話器をオフフックして、この番号をダイアルするとHH時MM分にアラームが設定されます。



LCDには設定時刻が表示され、受話器からはビジー音が流れるのでそのままオンフックします。アラーム時刻の表示が残ります。



アラーム時刻になるとRTCからの割り込みが発生し、電話機のベルが鳴ります。オフフックしてもビジー音が流れるだけです。



撮影した画像のなかから写りのいいものを選択したために、時刻表示とアラーム時刻が説明の順番と整合していなかったりしますが、だいたいこんな感じということでご容赦願います。