艦長日誌・私的記録 DS9

　TA1101を使ったデジタルアンプを，リビングのAirTunes（AirMacExpressにはオーディオ出力端子が付いており，iTunesから音楽を飛ばせるのです）専用アンプとして使っています。

　半年前の引っ越し時には，オリジナル設計の6V6シングルアンプを使っていました。スピーカはパイオニアのPE-101Aに専用エンクロージャLE-101Aです。このスピーカが大変に良い音をしていまして，いつ音を出しても「おっ」と手を止め，ついつい聴き入ってします。

　6V6シングルは2W+2W程度と低出力で，PE-101Aにはちと厳しいところではありますが，PE-101Aとの組み合わせで負帰還量を「自分が最も心地よいと思う」量に調整したものです。こういう調整の仕方は私は普段はしないのですが，たまには感性でチューニングってのもやってみようかと思った次第です。

　そんな訳で，この組み合わせはかなり気に入った音を出すのですが，いかんせん消費電力と発熱が大きいことが致命的で，今年の夏は特に稼働させるのが不可能なレベルでした。

　また，私だけが使うのではなく，嫁さんも使うものになったわけですが，電源スイッチの切り忘れが頻発し，危険だったという事も気になっていました。そこで半導体アンプ，特に効率の良いデジタルアンプに置き換えてしまおうと考えたのですが，いちから設計して作るのは大変なので，安易にケース加工済みのキットでも買ってこようと思っていました。

　けど，この手のキットというのは，ありそうでない，という感じでして，ちょうど手頃なものが見当たりません。共立電子で売られていたキットに目を付けていたのですが，入荷未定で品切れ。

　やむなく，10年ほど前に手に入れたトライパスのTA1101の評価ボードを引っ張り出して来ました。トライパスはすでに存在しないメーカーですが，デジタルアンプを一気にHi-Fi用途に耐えうるものに押し上げ，高い効率と音質の両立に成功したメーカーです。多くの製品に組み込まれ，キットにもよく使われていたもので，デジタルアンプが使い物になることを証明した功績は多大だと思います。

　その初期の製品がTA1101で，BTL，10W+10Wのものです。放熱器も必要ないくらいに効率が高く，特性上も十分Hi-Fiに耐えます。PowerMacG4に採用されたことで世に知られることになったICですが，どういうわけだか，この純正評価基板が，私の手元にありました・・・

　経緯は覚えていませんが，確実に動作する基板があるのですから，使わない手はありません。ところが，手頃なケースがありません。40度近い猛暑でアキバに出かける気も起きず，やむなくCD-Rの50枚スピンドルケースに組み込み，ちゃんとしたケースを買うまでのつなぎとしました。

　先月末，大阪に戻った時，日本橋でケース一式を調達してきたのですが，そのケースがアイデアルのCL140であることは，先日も書いたとおりです。

　その穴開け加工を昨日の昼過ぎ，急に思い立って始めたところ，18時頃には完成し，実用に供することが出来ました。

　電源はACスイッチング式のACアダプタを使いますが，これまではちょうどいい手持ちがなく，12V-1Aのものを使っていました。今度は大阪から持ち帰った，12V-2.5Aのものです。これでフルパワーもいけるでしょう。なお，このACアダプタ，HPのハンドヘルドPCである，Jorunada720に付属していたものです。

　このCL140というケースは，フロントパネルがスモークアクリルとアルミの二重になっていて，7セグメントLEDなどのディスプレイを組み込むことを念頭においたケースです。ひさしが出っ張っていることも，それらしいデザインです。

　綺麗なモスグリーンで塗装された丈夫な鉄製のケースで，大きさも手頃，形もかわいらしく，仕上がりが楽しみではありました。一緒に買ってきたつまみも，大きさやデザインが良くて楽しみです。さすがLEX製，昔はどこのパーツ屋でも買えましたが，今はちょっと探さないと買えません。

　しかし，フロントパネルは思案しました。アンプですから，光り物といえばパイロットランプくらいしかありません。アクリル板など必要ありませんが，これがないとパネルが随分と奥に引っ込んでしまいますから，やはりこれはアクリルを使う事を考えたいところです。

　問題はナットを挟むだけの隙間が，アクリル板とアルミ板の間に出来るかどうかです。ボリュームのナットは大きな穴を開けて表面に出てきてもつまみで隠れるからいいとし，スイッチは普通のトグルスイッチですから，なっとを表に出すのは格好が悪いです。まあ，1mmや1.5mmくらいの隙間ならなんとかなるだろうと，いい加減なのりで加工開始です。

　リアパネルにスピーカ端子，RCAジャック，ACアダプタのジャックを取り付けます。フロントは3mm径のLED，電源スイッチに2連ボリュームを付けるだけです。あとはTA1101基板の固定穴を4つ開ければ出来上がり。アクリル板は現物あわせとし，アルミパネルに重ねて位置決めをし，ボリュームとスイッチの穴を割れないように慎重に開けます。

　組み付けて見ると，意外にぱちっとおさまります。大体勢いで始めた加工では失敗をするものなのですが，昨日は失敗らしい失敗もなく，気分良く加工を終えることができました。

　欲を言えば，電源スイッチの位置がやや低く，LEDの位置がやや高い気がするという感じでしょうか。ま，ひさしがあるだけ印象も違ってきますので，あまり細かいことにこだわることはしないでおきましょう。

　さて，肝心の音ですが，iTunesが圧縮オーディオであることもあってか，どうもざらつく印象です。電源ラインは10000uFの電源コンデンサを付けてありますが，もともとそんなに良い電源でもないでしょうから，音の悪さはACアダプタのせいかも知れません。

　ただ，スピーカの良さには，やっぱり「おっ」と手を止めてしまいます。

　TA1101は低発熱で，出力も小さなものですので，特に放熱を考えなくても構いませんし，ケースに密封しても平気です。こうして，誰にでも扱えるお手頃アンプが1つ出来て，うちのリビングに，ちょこんと座ることになりました。

　音質の改善だなんだといじり回すのも1つですが，私としては余計なことをせず，このまま使おうかなと思います。

　先日，日本橋のシリコンハウス共立で購入した，ストロベリーリナックスのL/Cメーターキットを作ってみたわけですが，その感想をば。

　Ver2になってからも結構な時間が経っている定番キットですので，その感想なぞ誰ももう期待しないと思いますが，遠慮せず書いてみます。

・キット？
　書き込み済みのAVR，LCDもCR類も揃っていて，ガラエポの両面基板にハンダ付けするだけのキットですから，とても気楽ですし楽しく製作できます。スイッチも基板上にハンダ付けするので，ケースに入れなければ使えないというものではなく，私のようにものぐさでケースに入れるのを億劫がる人でも，さっと使える実用キットだと思います。

・回路図？
　キットとして致命的というか，もはや言語道断なのは，回路図がないことです。AVRのソフトを公開せよ，といってるのではないですよ。純粋に，キットで回路図がないのは話にならない，ということです。
　なにか公開できない秘密でもあるんでしょうか。Ver1では公開されていたそうですから，別にストロベリーリナックスが意地悪をしているような感じではなさそうです。
　しかし，回路図がないと壊れた時に修理も難しくなりますし，実はキットの組み立ての段階でも，間違わずに部品を取り付ける重要な情報になります。
　それに，キットというのは，改造して性能アップを行ったり，使いやすくするということが日常的に行われるものですが，回路図がないと，それも難しくなってしまいます。
　どこが性能に影響するのか，なにか精度を左右するのか，その部品はどういう働きをするのか，そういうことが回路図には出ています。初学者が勉強になるのはキットのそういう所が優れているからですし，電子工作を実体配線図だけでやり遂げたところで，あまり意味がないのではないかと思います。
　私は，この事実で，ストロベリーリナックスという会社に，ちょっと疑問を感じるようになりました。

・説明書？
　苦言を呈してばかりですが，なにせ説明書が読みにくく，よく読んでもいまひとつピンときません。ボタンは4つありますが，なぜ4つのボタンを用意したのか，4つのボタンにはどういう機能をアサインしたのかが体系的に書かれておらず，校正時にはこうしろ，コントラスト調整はこうしろ，ゼロ調整はこうしろと，機能を軸に説明をしてあるのですね。
　それでもいいのですが，結局使わないスイッチがあると，これってなんのスイッチだ，と言うことなるわけで，それを解決することも説明書の役割です。いかにも理系の人が書いたという感じがする説明書という印象で，悪意はないのですが，褒められたものではないでしょう。

・性能？
　誤差は1%と大々的にいってはいますが，誤差1%をキープできるのは，コンデンサでは10pFから0.01uFくらいまでです。もちろん，小さい方に浮遊容量由来の誤差があるのはわかりますが，フィルムコンデンサやセラミックコンデンサでも1uFを越えるものが普通に手に入る昨今，0.01uFくらいまでしかダメというのは，ちょっと厳しいです。
　さらに致命的（致命的な話ばかりですみません）なのは，0.01uFから0.1uFだと，誤差が3%くらいになると書かれているのです。
　いや，3%になるのは仕方がありません。しかし，問題は，1%をうたった測定器が，あるところで3%，それ以上の誤差を持つ事を書いてしまっていることです。では，1.2%はどこのあたりから，1.8%はどのあたりから，と，表示されている値をどこまで信じていいのか，わからなくなってしまうのです。
　これなら，1%を維持できる容量はどこからどこまで，3%ならどこからどこまで，と書くべきであり，この製品のように0.01uFから0.1uFで3%程度，では，あんまりだと思うのです。
　これを少し深読みして，0.01uFまでなら1%，0.1uFまでは3%と判断してもよいのですが，なら0.03uFならどうなのか，0.082uFならどうなのか，3%程度というのはどういうことなのか，使う人の想像力に任されてしまいます。測定器を名乗るなら，これはダメです。
　それと，0.47uFのコンデンサを測定してみたのですが，0.26uFと半分ほどの値を示しました。説明書には誤差が大きくて使えないとあるので文句は言えませんが，未知の値を測定するのに，倍近く異なる値を平気な顔をして表示するというのは，ちょっと不親切かなという感じもします。いや，これは使う人が気をつければよいということにしておきましょう。
　なお，インダクタはなかなか良さそうです。測定範囲は0.1uHから10mHですので，普通に使うものは十分測定可能ですし，コンデンサのようにテスタに測定機能があるわけではありませんので，この際コンデンサの容量計はオマケで，インダクタンスメーターとして割り切って使うべきだと思います。

・バグ？
　ゼロ調整ですが，どういうわけだか電源を切っても保存されるべきなのに，保存されずにもどってしまいます。
　一度，コンデンサを付けたままゼロ調整を誤って行って，大きくずれたオフセットが記録されてしまい，戻せなくなってリセットをかけたのですが，どうもゼロ調整は2回連続で行わないと，記録されないっぽいです。バグですかね。

・結論？
　とりあえず，容量計はあまり信用できません。小容量品の測定には威力を発揮しそうですが，私のように高周波に無縁な人には，あまり必要性がないといえるでしょう。1000pFとか，1%精度で追い込む人なんかにはありがたいかも知れませんが，そんな回路の設計なんて，正しい設計なんですかね。
　インダクタンスの測定はとても便利に使えそうです。スイッチング電源を自作することがホビーストにも求められる時代になりましたが，そこで活躍するのがインダクタンスメーターでしょう。ジャンク品の流用，実測値の測定，手巻きで作るなどなど，テスタで代用できないだけに，貴重な測定器だといえそうです。

・おすすめできる？
　難しいですね，インダクタンスを測定したい人は，4600円の価値があります。コンデンサの容量測定をメインにするなら，買わない方がいいでしょう。もう4600円追加して，よいテスタを買いましょう。
　1000pFくらいを1%で測定したい極端なマニアは，すでにこんなの持っていると思いますので，今から買おうかどうか考えている人は，ちょっと考えた方がよいように思います。
　決して使いやすいわけではないし，回路図もない，実用機器を作るだけのキットで，しかし案外実用度が低いとくれば，残念ですが積極的にはおすすめ出来ないなというのが，私の結論です。

　ということで，もう作らなくてもいいかなあと思っていた容量計ですが，やっぱり作ろうと思います。

　先日，ここをご覧頂いているある方からメールを頂きました。

　内容は，GPS時計を作ったが動かない，なにか思いつくことはないか，ということでした。

　昨年末にAVRのtiny2313を使ってGPS時計を作り，その顛末をここに書いたのですが，私にしては珍しくソースも公開したので，自分も作ってみようと思って下さった方がいらっしゃったようです。

　最初に申し上げておかねばならないのですが，この日誌は自分のためのメモがわりなので，他の方が見て問題なく制作できるほどの情報を書いていません。今回のGPS時計にしても，実は回路図はどこにも書いていませんし，ソースの変更履歴もありません。さらに掲載した画面の写真は最新のソースのものではありません。

　ということで，誰もこんなの作ってみようと思わないだろうと，不親切きわまりない内容だったにもかかわらず，果敢にも実際に手を動かした方がいらっしゃるとは，ちょっと驚くと共に，申し訳ないなあという気がしました。

　頂いたメールは非常にシンプルで，「SATと20だけが表示されあとは何も出てこない」ということだけが書かれていました。

　うーん，正直なところ，これだけでは原因として思いつくことがあまりに多すぎて，ちょっと答えようがないなあ，と思っていたのですが，まず最初にピンと来たことを中心に答えることにしようと考えました。

　私のお返事は，

----
　その原因として，思いつくものを列挙します。
LCDに表示が出ているので，AVRとLCDは動作していると
仮定します。

　また，ソースは「GPS時計 - 完結編」にある
最新版（起動時にV1.33と出る）であるとします。

(1)GPSモジュールのボーレートを変更していない。
　購入直後の設定は9600bpsなので，これを
　19200bpsに設定する必要がある。（やりかたは
　ぐぐってください）

(2)AVRを外部発振で動かしていない。
　AVR側のボーレートは，内蔵発振では
　補正を入れないと正確にならず，受信出来ない。
　（最終版のV1.33では20MHzの外部発振でなくては
　　動きません）

(3)書き込み時のヒューズビットの設定ミス。
　特に外部発振の設定はヒューズビットで行うため
　適切な設定を行う必要がある。

(4)配線ミス。
　GPSモジュールのピン配置は？
　GPSモジュールの信号レベルは？
　GPSモジュールは動作している？
　単純な配線ミスは？
----

　としました。

　ピンと来たというのは(1)もしくは(2)の話で，表示も出ていることからAVRは動作しているし，通信が出来ていない時にこの症状になることは私も経験しているので，この2つを確かめてもらおうということにしたのです。

　とりわけ(1)は，GPSモジュールに手を入れて，ボーレートをデフォルトの9600bpsから19200bpsにしないといけないことを詳しく書いていなかったので，可能性は低くないと思いました。

　(2)も実際に実験したのですが，内蔵発振器でクロックを用意する場合，その周波数は結構ずれるため，正確なボーレートになってくれません。それでAVRライタを使ってある領域に書き込まれている補正値を読み出し，その値を周波数補正レジスタに書き込んで8MHzを作る事が必要になります。

　私が実験したというのは，あるチップで有効な補正値を別のチップに書き込んだらどうなるかだったのですが，予想通りボーレートも狂ってしまい，受信が出来なくなりました。結構面倒な話なので，私はUARTを使う場合には外部に発振子を用意しようと，この時から考えるようになりました。

　(3)は今回の現象を直接引き起こすか確証はないのですが，私の思うAVRの欠点の1つだと思うことでもあるので，書いておきました。

　AVRもマイコンですから，ソースをコンパイルしバイナリを生成し，これをライタで書き込むことで動くようになります。ただ，AVRの場合それだけではだめで，書き込み時にライタによってヒューズビットを設定しなければなりません。

　私が嫌だなと思うのは，ヒューズビットの設定をファイルに保存しておけないことです。ソースもバイナリも保存できるので残しておけますが，ヒューズビットはメモで残すか，テキストファイルで残すかした上で，ライタにいちいち設定しないといけなかったりします。（なにかいい方法があるのかも知れませんが，ライタによらない共通のフォーマットで保存出来なければ意味がありません）

　しかも，ヒューズビットの設定をあやまって，外部発振子を使わずに外部発振モード設定にしてしまうと，ISPでの書き込みが出来なくなってしまいます。ごく普通に使われているライタはISPですので，それしか持っていない人にとって，復活の方法がないという恐ろしい状況がおこります。

　チップごとに設定が異なっていて，しかもマイコンが動作する前に設定をしないといけないような部分があって，そこをヒューズビットにするという考え方は普通だと思いますが，それならそれでAVRstudioでヒューズビットの設定を行う事にし，バイナリと一緒にヒューズビットの設定ファイルを生成して，ライタはそれらをただ書き込むだけ，と言うふうにしてくれた方がよかったと思います。

　まあ，そんなことを言っていても仕方がありませんが，とにかくヒューズビットは回路によっても変わってくるので，作った方に再確認をしてもらうしかありません。

　翌日，お返事を頂きました。

　無事に動いたという事です。よかったよかった。

　原因は，GPSモジュールのボーレートを変更していなかったことにあったとのこと。私の勘もなかなかのものです。

　一緒に，正常に動作した状態の写真も送って下さいました。LCDは秋月あたりでよく売られているものをお使いのようですが，私はデジットで買った大きめのものを使っているので，同じ画面が小さい液晶で表示されたものを見るのは当然初めてです。

　こうしてみると，自分が作った覚えのないものが，同じように動いているのを見るというのは，なんだか不思議な感覚になります。自分が手を動かして作ったものは，やっぱり強い記憶に残りますから，写真を見てもなんとも思わないのですが，自分が作っていないものが同じ動作をしているのをみると，「あれこんなのいつの間に作ったのかな」という感じになるのです。

　もしかすると，突然「あなたの子よ」と子供の写真を見せられたら，こんな気分になるのでしょうか。

　私は，自分の電子工作は，自分が楽しかったらそれでいいという動機でやっていることなので，積極的に他の方に作って頂こうなどと思ったことはありませんから，今回のことは意外だったなと思うのと，こんなものでも興味をもって作ってみようと思って下さった事が，素直にうれしいと思いました。

　余談ですが，エレキジャックのNo.16に，私も使ったGPSモジュールであるGT-720Fを使って，GPS時計を作った例が記事として出ているようです。

　なぜかある領域でブームになってるニキシー管を使っているのも売りのようですが，私が疑問なのは，GT-720Fのような1PPS出力がないモジュールを使っておきながら，正確とか原子時計レベルとかいっていいものなのかな，ということです。

　GT-720Fというモジュールは，1/10秒や1/100秒の桁がゼロになっている時刻にだけ，時刻情報を送信してくるというわけではありません。

　つまり，12時12分12秒00という時刻情報が送られて来るとは限らず，12時12分12秒99といった，1/10秒や1/100秒の桁が0以外の時刻情報を送ってくることがあるということです。

　だから，単純に受信データのうち，1秒から上の桁を表示するだけでは，最悪1秒近いズレを発生させてしまうことになります。

　そりゃそうですね，GT-720Fは，12時12分12秒99の時点で「12時12分12秒99ですよ」と時刻情報を送信しているに過ぎませんから，受けた側がそれを勝手に12時12分12秒と表示したら，約1秒ずれますわね。私はここで，随分苦労しました。

　エレキジャックには最近愛想を尽かしてしまっているので買っておらず詳細は分からないのですが，ちょっとだけ気になってサポートページにあるソースを見ると，特別な処理は行っておらず，1/10秒以下を単純に切り捨てて表示させ，結果的に最大1秒のズレを発生させる可能性があります。

　もちろん，私がやったような方法で1/10秒以下を考慮しても，1PPS出力がなければGPS衛星に搭載される原子時計に同期したパルスを手に入れられませんから，12時12分12秒00になってから12時12分12秒00と送信されたデータを受信して表示をしているようでは，どうしたって遅れが生じます。これはGT-720Fを使う限り避けようがありません。

　なのに，原子時計レベルの正確な時計だ，というのはかなり無理があるように思います。私がおかしいのかなあ？

　みんな，電波時計なんかと比較しないんでしょうか・・・作りっぱなしで比較もせず，GPSで得られる時刻情報は原子時計レベルなのだという知識だけで，盲目的に自分の作った時計も正確だと信じちゃうのでしょうか。

　さて，同じ電子回路の設計技術を持つ者でも，量産品を設計するプロと，アマチュアとの間には大きな差があります。プロは1000個や10000個を「同じように」「効率よく」作る事を前提として設計を行う事になります。アマチュアは1つ動けばそれでいいので，極端な話，全部の抵抗を可変抵抗にしても別に構いません。

　こうした差から生まれる決定的な違いは，プロは記録を残すことも仕事と考えていることです。自分がいなくなっても同じものが作れるようにするには，詳細な記録がなくてはなりません。それが回路図であり，ソースコードであり，履歴であり，各種のドキュメントです。

　アマチュアはこういったものをあまり積極的に残しません。プロは，残すだけではなく，誰が見ても同じ結果になるように，決まったフォーマットで残す事を求められます。

　仕事なんだから当たり前なのですが，何が言いたいかというと，アマチュアも，しっかりしたドキュメントを残すべきだということです。私もGPS時計について，自宅にはちゃんとした資料を残しています。

　最近，電子工作を楽しむ方が増えているようです。それはとてもよい事ですし，長年楽しんでいる私にとっても心強いものがありますが，設計，製作，測定，考察，というプロセスをきちんと踏んで，それらをきちんと記録して残しておくことを特におすすめしておきたいと思います。

　必ず次に繋がりますし，飛躍的にその人の技術力を高めます。なにより，後で読み返したら面白いですよ。

　とくにオーディオマニアでアンプなどを自作する人に言いたいのですが，地に響く低音とか伸びのある高域とか静寂が身を包むとか躍動感あふれるとか艶やかなボーカルとか，そんなことを「作った結果」として誇らしげに言ってるだけじゃ，ダメですよ。

　GPS時計ですが，その後も毎日のように検討を続けていました。

　GPSを使って時刻情報を得ていながら，1秒近くずれるというのはもはや言語道断といえて，何とかなるならしてみたいし，駄目な場合でも駄目な理由を理解してからあきらめたいと思ったからです。

　さて，前回，UARTのボーレートを38400ボーにするということと，使っていないセンテンスは送出させないようにしたこと，それと1秒に1回だったデータの送信周期を1秒に2回にしたことで対応を図ったが，あまり良い結果が得られなかったことを書きました。最大で1秒弱の遅れは解消されず，遅れる時間も長かったり短かったりとバラツキがみられます。

　そして，根本的にGPS本来の精度の時計を作るなら，GPSモジュールから1PPSの信号を得なければどうにもならない，ということもはっきりしました。ここまでが前回までのお話です。

　一般論としてですが，どうもGPSモジュールから出てくる時刻情報は，実際の時刻よりも少しだけ進んでいるのが普通のようです。少しだけ進んだ時刻をマイコンが取り込み，その後やってくる1PPSの信号で表示を更新することで，GPS本来の精度の時計が実現出来るというわけです。

　今回使っているGT-720Fというモジュールはこの1PPSの信号が出ていませんので，そもそもGPS時計を作るのに適していないモジュールを選んでいることになります。

　それに，これまでいじった結果として感じるのですが，少し進んだ時刻が出ているかどうかもあやしいです。

　ということで，1PPSがないと正確な時計を作る事が出来ないなら，GT-720Fから1PPSの信号を引っ張り出せないか，と考えました。

　幸いないことに，GT-720Fで使われているベースバンドチップは，Venus621LPというもので，1PPS信号の出力を持つLSIです。きっと，モジュールのどこかに1PPS信号が出ているに違いないと考えました。

　そこで背面のシールドケースをあけ，1PPS信号を探したのですが，結論からいうと見つかりませんでした。Venus621はBGAパッケージのLSIですから，端子から直接信号を取り出せません。基板上のどこかに出してくれていることを期待したのですが，スルーホールや抵抗などの部品をすべてあたっても，1PPSの出ている箇所を見つけることができませんでした。

　ならば，と衛星をつかまえたことを示すLEDはどうだろう，と考えました。GT-720Fは，衛星をつかまえていない時はLEDが点灯，つかまえると一定間隔で点滅します。

　このLEDの点滅が1PPSに同期しているなら，1PPS信号として使えるでしょう。いい所に気が付いたと思ったのですが，残念ながら全く同期しておらず，無関係でした。この段階で，GT-720Fから1PPS信号を得る事はあきらめ，外したシールドケースを元に戻しました。寂しいですね。

　ここに至って，1秒近く遅れる，という人間の感覚でもばれてしまうズレを，せめて意識しないで済む程度にする，という消極的な方法しかなくなってしまいました。

　そのためには，前回も書きましたが，何らかの理由でずれた時刻が送られて来ても，更新周期を早めて表示を頻繁に行うのが有利です。周期が短いほど，ずれた時刻の表示が正しい時刻になるまでの時間が短くなります。

　そこで，GT-720Fの設定ツールを使って，更新周期を設定可能な最大である1秒間に10回に設定しました。

　また，ボーレートを19200ボーに下げました。これは，38400ボーに上げたところで数msしか高速化されませんし，96バイトとバッファサイズを大きくしてまでこのボーレートで受け取るのは無駄で，64バイトのバッファで受信可能な19200ボーが最適という判断です。

　前回書きましたが，バッファを64バイトにすれば，リングバッファの実現が条件分岐ではなく，ANDによるマスクという処理だけで可能となります。これは処理速度にもコードサイズにも有利です。

　さらに，LCDへのデータ転送タイミングには十分すぎる時間を確保してあったのですが，これを大幅に切り詰めました。LCDへの転送クロック周期はスペックでは500nsから1000ns程度なのに，2msと2000倍も長くとってありました。動作は確実でしょうが，処理時間の大半はLCDへの転送にかかっていたことになります。

　試したところ，確かに見た目のズレはかなり軽減されています。しかし，そのズレ方は一定ではなく，1/10秒くらい遅れているときもあれば，ほとんどずれていない時もあります。

　この違いはなんだろう・・・はっきりしないと，時計として全く信用できません。

　この疑問は，GPSモジュールの吐き出すセンテンスを直接PCで見た時に氷解しました。

　実は，GPGGAにしてもGPRMCにしても，時刻情報として

133227.999

　というデータが，13時32分28秒の段階で送り出されていることがあるようなのです。

　27.999秒というのは，もうほとんど28秒なのですが，1/10秒以下を無視してしまうと，27秒と表示されてしまいます。

　もし，1秒間に1度の更新周期なら，次のデータは28.999秒となり，実際の時刻である29秒との表示のズレは，またしても1秒出てきてしまいます。こうして，GPSモジュールが何かのきっかけでxx.999ではなく，xx.000を出してくれるようになるまで，この1秒の遅れは続きます。

　もし1秒間に2回の更新を行う場合，送られて来るデータは

133227.999 133228.500 132228.999 133229.500

　という順番で出てくる事になり，ズレは0.5秒まで軽減されます。とはいえ，0.5秒のズレはばれてしまいますね。

　さらに，もしなんらかの理由で，

133228.000 133229.000

　という形で送られて来るようになると，.xxxを無視して表示すれば，ほとんどずれることなく表示が出来る事になります。

　さらに調べていくと，.xxxの部分は一定ではなくばらつくこと，バラツキの大きさによって遅れる時間が変わることも分かりました。

　これが，表示時刻が不規則に遅れる理由でした。

　少し実験をします。PCで.999というデータが出ていることを確認した上で，実機の表示を1/10秒まで表示させてみました。すると秒の桁が，

11.1 -> 11.2 -> 11.3 ... -> 11.8 -> 11.9 -> 11.9 -> 12.1 -> 12.2 ...

　という具合に変化します。1/10秒にゼロが表示されないことと，1秒の桁は11.9では変わらず12.1で変わるので，実際の時刻よりも1/10秒遅れているのがよくわかります。

　また，PCで.000で揃ったデータが出ている状態で同様に確認すると，ほとんど同時に表示も変化するようになります。これではっきりしました。

　そこで，暫定的に.999になったら秒のデータに1を加えるという簡易的な方法を試してみたところ，表示は概ねずれることなく更新されるようになったのですが，

18.8 -> 18.9 -> 19.0 -> 19.1 ... 19.8 -> 19.9 -> 1:.0 -> 20.1 ...

　という変則的な表示となり，見た目が非常に悪くなりました。キャラクタコードに1を加えただけの手抜きはダメで，やっぱり真面目にやるしかありません。

　そこで，さらに大幅な変更をします。日付はともかくとして，時刻だけはちゃんと処理する事にしましょう。日付は24時間に一度変化しますが，GPSからのデータの取得はは1秒おきですので，1秒だけ32日とか出てしまうことが考えられますが，まあいいでしょう。メモリも足りませんし。

　このため，これまで直接リングバッファの値を表示用の関数に渡していたものを，一度グローバル変数に取り込んで，文字列-から数値への変換，補正や表示を行う事にしました。

　あと，潜在的なバグとして日付の処理に問題があり，UTCで9日をJSTに変換するところでくだらないミスをしていたため，10日とならず，0:日と表示されていました。配列の宣言のミスで，暴走一歩手前だったことも白状します。お恥ずかしい。

　そうこうして出来た最終的なソースが，以下です。

続きを読む

　先日，MakeTokyoMeeting04を見学し，Maker達の熱意にずいぶん影響を受けたのですが，ともあれGPS Laboさんでわけて頂いた，GPS時計プログラムを書き込んだATtiny2313を生かさねばなりません。

　とにかく簡単に試せるという事で，MTM04の直後にGPSモジュールを秋月電子に手配を済ませてあり，翌週の土日から検討に入っています。

　LCDは昨年の今頃，大阪のデジットで入手した大型のLCDモジュールを使う事としましたが，予想通りあっさり動いてしまいました。

　元々，PICをアセンブラで使い慣れている私としては，個性の強いMSP430やPSoCならまだしも，個性の弱いAVRを今さら使うのもどうかなあ，と感じて試す気にならずにいました。

　ところが，GCCが使える（つまり無制限で優秀なCコンパイラが使える）ことと，tiny2313であれば秋月価格で1つ100円と圧倒的に安いことが私にとっては強烈な個性に見えて，軽く遊んでみることにしました。幸いライタは昨年のデジット詣の際に購入済みです。

　GCCが使えるという事から，プロセッサのアーキテクチャが無個性であることがうかがい知れるわけですが，逆にPICでは個性が強すぎてGCCをインプリ出来なかったわけですね。先日も話していたのですが，PICは「クセの強さをアセンブラで味わうマイコン」です。

　開発環境であるAVRstudioも使いやすいですし，tiny2313はちょっとメモリが少ないですが，最大20MIPSという高速処理と，レジスタと内部メモリが1クロックアクセス出来る事もあり，プログラムを作る上で速度低下に気をつけながらコードを書かずに済むため，コンパイラ任せでも精神的に随分楽です。

　わずか100円で20MIPS，豊富なI/OポートをCでグリグリ動かせますから，もうPIC18F84とはおさらばです。ということで，すっかり私はAVRのファンになってしまいました。

　AVRを使うと決めた以上，いろいろ試しておきたくなるのが人情というもので，USIという原始的なシリアルインターフェースモジュールを使ってSPIを実現する（8MHzのクロックで4MHzの転送クロックが出せます）プログラムや，LCD関連のライブラリをひと通り準備しました。

　これは，MacBookPro上にSunのVirtualBoxという仮想マシンを入れて，Windows環境が実現出来たことが随分大きいです。後日書こうと思っていますが，このVirtualBox，かなり出来がよいです。無償ですが，有償の仮想マシンを買う必要を全く感じません。

　余談ですが，x86には仮想マシンを実装するにはやや問題があり，普通に仮想マシンを実装しようとしてもパフォーマンスががた落ちになり，うまくいきません。有償の仮想マシンとして有名なVMwareはこの問題をうまく解決したソフトとして知られていますが，Core2Duoなど仮想マシンを前提とした新しいx86であれば，あまりおかしな事をしなくても仮想マシンをちゃんと実装出来ます。だから，無償の仮想マシンでもなんら問題はないというのが，私の考えだったりします。

　実際の所，VirtualBoxがどうやっているかはわかりませんが，仮想マシンを支援するハードウェアを使うかどうかのオプションがあるので，少なくともパフォーマンスへの貢献はあるのでしょう。

　話が逸れてしまいましたが，開発関連ツールはWindowsが前提なだけに，自宅にまともなWindows環境が手に入ったことはとても大きなことで，今回のAVRを楽しむことだって，その恩恵だと思います。

　それで，GPSクロックですが，どうもうまくありません。

　GPS Laboさんは，処理などに時間がかかり，表示された時刻が正確な時刻ではない，という話をされており，これをきちんと表示させるには1PPSの信号のあるGPSモジュールを使うしかない，といわれていました。

　実際，平気な顔をして1秒くらい表示が遅れています。いかにGPSが原子時計の精度を持っているといっても，表示が1秒もずれたら，正確な時計としては存在価値がありません。

　GPS Laboさんのソフトは，時刻情報の含まれているGPGGAセンテンスを割り込みで一気に80バイトのバッファに取り込み，その後文字列から時刻情報を抽出し，JSTに変換してLCDに転送する仕組みです。初期設定が終わったらひたすら空ループを回すのが，main()の中身だったりします。

　それはそれでいいのですが，割り込みは出来るだけ軽く，という考えからすると，時刻情報の抽出やJSTへの変換，LCD表示などはやはりmain()で処理したいところです。ごく普通に，UARTからの割り込みで1バイトをバッファに取り込む，という処理だけを割り込みで行うと，1センテンスの取り込み完了を待たずに続きの処理が出来る事になるので，表示のアップデートにかかる時間が短縮されて，表示の遅れが小さくなりそうです。

　そこで，UARTの練習も兼ねて，プログラムの書き直しをしてみることにしました。センテンスの処理を行って時刻情報を抽出する部分は流用させて頂きますが，それ以外は他の方のコードを参考にするか，自分で作るかします。

　UARTから受信割り込みがきたら，割り込み処理の関数で1バイトをリングバッファに取り込み，ライトポインタを進め，割り込みから復帰させます。

　main()ではループのなかで$をリングバッファからサーチし，以下に続くGPGGAが見つかったら，続けて取得した文字列をデコード，時刻情報を取り出しJSTに変換，LCDへの転送を行います。

　リングバッファは1センテンス分というより処理が間に合うだけという感じですので，当初は64バイトを確保しました。

　また，ついでにGPRMCセンテンスから日付情報も取得するようにしてみました。

　ところが，これでもやっぱり遅れます。考えてみると，UARTから80バイトを取り込むのにかかる時間は多くても100ms程度ですから，これをゼロにしても，1秒の遅れが解消されるわけではありません。なにが原因なんだろう・・・やっぱり1PPS出力がないとダメなのでしょうか。

　GPSモジュールとしては，MNEA-0183で送り出す測位情報を外部のマイコンで記録してくれることを期待しているわけですから，必要なのはその測位を行った時刻が正確であることです。リアルタイムで正確な時刻を吐き出すことはしていなくても当然です。だからGT-720Fを使う限りは，もう無理なのかなあと思ったのですが，あきらめずにもう少しだけ頑張ってみることにします。

　GT-720Fには，ボーレートを変更するためのツールがあります。9600bpsではなく，これを38400bpsにすれば1センテンスの受信にかかる時間が1/4に短縮されます。

　ということでいろいろツールをいじっていると，別の端子から専用のパルスを出すのとは違いますが，UARTへの出力を1秒で正確に出すことで1PPSが可能になったり，測位を1秒に2回とか4回といったように，測位周期を変えるたり出来ます。また，送り出すセンテンス種類を制限したり，それぞれの送信頻度を調整できたりします。

　タイムゾーンの設定が出来るとJSTへの変換もいらなくなるのでいいなと思ったのですが，設定を行っても反映されないようなのであきらめました。

　これらの設定をいろいろ試行錯誤したところ，AVR側の処理速度と受信バッファの大きさから，38400ボーでは取りこぼしが起きています。64バイトの受信バッファでは，あと数バイトたりない感じです。

　悔しいので，96バイトまで増やすことにしました。

　64バイトだと，リングバッファを実現するのに，リードポインタもライトポインタも0x3fでANDするだけでサイクリックに回せるのですが，96では真面目に96になったかどうかを判定し，真ならゼロにリセットという処理をせねばなりません。せっかくボーレートを上げても，処理が増える事で速度低下が起きるようなら本末転倒ですが，まあやるだけやってみます。

　また測位周期は1秒に1度から1秒に2度にします。これまでは1秒に1度しかGPGGAセンテンスが飛んでこず，よって1秒に1度しか表示が更新されないことになるので，表示のズレが1秒くらい出てきてしまうことは避けられないように思いました。

　しかし，1秒に2回にすれば，500msごとにGGAセンテンスが送られてきて，表示も1秒に2回更新されることになりますから，GPSモジュールが本当に1秒未満のズレで時刻を送ってこなければ，表示のズレは500ms以内に収まるはずです。

　さらに，処理を軽くするために，GPGGAとGPRMC以外のセンテンスの送信を停止し，さらに日付情報が欲しいだけのGPRMCセンテンスの送信頻度を10秒に一度にします。こうすると，GPGGAが運んでくる時刻情報が他のセンテンスに邪魔されず，1PPSを守って送られてくると考えたのです。

　また，AVRの処理速度を根本的に向上させるため，これまで内蔵クロック8MHzだったものを，外部クリスタルによる20MHz駆動としました。UARTのボーレートも正確になり，一石二鳥です。

　そんなこんなで，こんなコードになりました。

続きを読む