cronos雑記

待ちに待った新基板がFusionPCBから届いた。
トラッキング情報を監視してて、近所の郵便局に
着荷したタイミングで窓口受け取りに成功。

今回はシルクを青にしてみた。
基板厚は1.0mmを指定したが、今回初めて厚さ指定が守られた
基板が作られたような気がする。 感慨深い。

早速、本日早朝にデバイスのハンダ付けを行ってみる。
ATmega168PA-MMH。0.45mmピッチのQFNパッケージだ。
位置決めはシビア(特に回転方向が)だが、ハンダ付け自体は
とても楽に終わった。 20秒掛かってないと思う。

このデバイス、パッケージ中央裏にExposedPadが有るので
基板裏側からスルーホールを通じてハンダ付けしてやる必要がある。
1枚目の写真を見ると、デバイスの裏側にそれ用の穴がある事が分かる。

今日は早めに帰って続きを進めよう。

前回の試作で起こした基板で開発してきて
概ね課題を解決したので基板の改版を出した。
変更点はマイコンの種類とJJY受信用ICの置き換え。
…全部じゃないの (汗

元々はtiny2313を使っていたのだけど、RAMが足りず
結局mega168を使う事に。でも価格差はあまり無いんだよね。
もうちょっとRAMが大きいラインナップがmega系にあれば良いのに。

また、元々は原発振にセラロックを使っていて
周波数偏差が大きくて時刻誤差が出たのでオシレータに置き換えた。

レシーバICも、TEMICのU4226BからNPCのSM9501AVに変更。
U4226Bの時はバンド切り替えのためにアナログスイッチを
外付けで載せたり、フィルタが2ペア必要だったりと
サイズもそうなのだけど、高い回路になってしまっていた。
デバイスを変更する事で、かなり受信感度を改善する事が出来た。

これが改版後の板。
13x50mmに全機能を入れた。
このモジュールは、定期的にJJY局(茨城と九州にある)の
時刻信号を受信して内部時計を同期、シリアルポートから
時刻要求を受けた時の時刻を西暦～秒まで返すというもの。

あと1～2週間前後で板が来るはず。
無事動いてくれると良いんだけど…。

　ここ2週間ほど、PC側の時計とJJY時計との間で誤差が出ていて
その原因がはっきりしなくて悩んでいた。

症状は、JJY時計の時刻が2秒あたり200mSec前後づつ遅れていくというもの。

タイマ割り込み処理内で行っているJJYに同期する処理が重く
(約600mSec掛かる)、この処理時間によって計時時間に誤差が出る懸念もある。

また、タイマ割り込みで計時ルーチンを呼んでおり、次の割り込みまでの間に
処理が完結しなければ、時計が遅れていく事も考えられる。

前者は、割り込み処理内で行う処理を最低限(1mSecでサンプリングして
パルス幅評価をする部分)にして、後でゆっくりやって良い処理
(受信データから時刻を抽出したりする部分とか。)は追い出した。

前者をFixしても遅れる現象は変化せず。
もしかして現状でも割り込み処理内の処理時間が1mSecを越えているのか？
…と思い、後者をつつく。

割り込み処理の末尾で、ポートを反転させる処理を入れ
1mSec幅でH/Lするかオシロでチェックしてみた。
特に脱調する事もなく、ちゃんと1mSec幅でH/Lしている事が確認出来た。

となると、もう遅れる要素は考えられない。
有るとしたら繰り上がりをミスっているとか、その辺だ。
でも繰り上がりは間違っていない。うーん。

ふと思い立って、机の隅に置いてあった卓上時計(デジタル)と
PCの時計を30秒程度にらめっこしてみた。
…進んでる。PCの時計。ほんとにどんどん進む。

卓上時計を神様にしてJJY時計との誤差を見たら、2時間経っても数十mSec。
今までPCの時計は正しいものだと思って、自作のプログラムを疑っていたんだが…。

2週間無駄にしたと思うか、正しい事を確認出来て安心出来たと思うか。
先を急がなくちゃ。

余談。
今使ってるATmega88Pは、RAMの容量が1kByteと大きいのだけども
統計とかやりはじめるとRAMをたくさん喰うので
配列にRAMを喰われたくないのだ。

AVRは、どうやらconstで書いてもRAM上に展開されるコードになるようで
ちっともRAMの使用量が減ってくれない。

ググってみたら、どうやらPROGMEMというのを使うらしい。

★ PROGMEM使用 ————————————————

1
2
3

#include <avr/pgmspace.h>		// PROGMEM使用
unsigned int PROGMEM MonthDays[]
= { 0, 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 };

AVR Memory Usage
—————-
Device: atmega88p

Program:    4776 bytes (58.3% Full)
(.text + .data + .bootloader)

Data:        746 bytes (72.9% Full)
(.data + .bss + .noinit)

★PROGMEM不使用 ————————————————

1
2

const unsigned int MonthDays[]
= { 0, 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 };

AVR Memory Usage
—————-
Device: atmega88p

Program:    4768 bytes (58.2% Full)
(.text + .data + .bootloader)

Data:        772 bytes (75.4% Full)
(.data + .bss + .noinit)

—————————————————————-
うん、まぁ、こんな感じ。
結構減るよね。

今日は結構ToDoを消化する事ができた。
目玉は、受信データの正常判定だろうか。
今まではJJY信号と一緒にやってくるパリティのチェックだけ
やっている状況だったのだけど、たまに変なデータが来て
パリティチェックを通ってしまう(2bit化ければパリティで
正常性を判定出来ないのだ)事例が見られて、受信データの
健全性を担保する何かを実装する必要があった。

・確率分布を取ってピークサーチ
・パリティチェックだけ

ネットで他の作者によって提案されているJJY時計のうち
ソースが公開されているものは、概ねこの2つだったように思う。
前者は(私に)荷が重い、後者はデータの健全性を担保出来ない
という事で、何かラクに実装出来てそれなりに効果が期待出来る
ノイズ除去の方法は無いか　と思って思いついたのが
複数回のデータ受信によって、n回同じデータが取得出来れば
確からしいデータだろう。　という方法(n連一致)だ。
今回はサンプル数(n)を3にして、同じ値が3つ連続すれば
正しい値であるとして採用するロジックにしてみた。

今の所は正しい値のみを引いてくれているように見える。

今まではJJYの受信パルスを評価する機能に掛かりっきりで
ユーザI/Fの方に手が回っていなかったのだが
今回、入出力仕様案として策定したI/F仕様案を若干修正して
コマンド入力、データ出力のフォーマットを作り込んだ。

時刻、年月日の表示は勿論だが、JJYに同期した後の時刻なのか
そうではないのか、受信したのであればどちらの周波数なのか。
その辺りが1つのデータを見る事で分かるようにしたつもりだ。

★同期してないとき
*,0000/00/00_00:00:03.913*

★40kHzで同期
4,2011/03/18_18:18:04.983*

★60kHzで同期
6,2011/03/18_18:21:08.652*

先頭の1文字が、現在のJJY時計の状態。
*は未同期、4は40kHzに同期済み、6は60kHzに同期済み　だ。
その後は分かるね。 最後はmSec単位の秒時刻。

…と、ここまで作り込んできて今更気がついた事があった。
時→日の連携を作り込んでおらず、非常に長い1日となっていた。
せっかく、JJYからの受信データに含まれる通算日を
グレゴリオ暦に置き換える処理を作ったのだから、活用したい。

日付変更時に、バックグラウンドで管理している”通算日”に
インクリメントし、年月日を再構成するのだ。
以下結果。

★日付変更
4,2011/03/18_23:59:58.814*
4,2011/03/18_23:59:59.782*
4,2011/03/19_00:00:00.767*
4,2011/03/19_00:00:06.115*

きちんと18日から19日に出来ているようだ。

今日のまとめ。↓

★やったこと
・受信データの正常判定(3連一致)実装
・JJY同期 / 内部時計モード遷移実装
・出力フォーマットを仕様通りに
・入力コマンドを追加(40/60kHz周波数指定での強制受信を追加)

★ToDo
・再同期処理
・受信バンド切り替えのロジックを考える。

地震によって福島原発で発生したトラブルによって
おおたかどや送信所が停波したので、ここ茨城では
標準電波を受信しながらのデバッグが難しくなってしまった。

秋月で売っているJJYシミュレータは高いし、あまり複雑なハードを
今から作るほど、手持ちの部品も気力もない。
何か良いモノないかなーと検索していたところ
http://www.starstonesoft.com/JJY_Simulator.htm
とても良いソフトをフリーで公開していただいているHPを見つけた。
どうやら、13.33kHzをPCで出して、その3倍高調波(39.99kHz)を
電波時計で捉えてやろう…というモノのようだ。

ちょっと前に作って、PC用として常用していた
自作のD級アンプにループコイル(ただの巻いた線だが)を接続して
ソフトを起動してみた。
音量を上げていくと、…おお、受信しているぞ。
と、動いていたのは数十秒。全く受信しなくなってしまった。

アンプを確認すると、どうやら終段を飛ばしてしまったようで
FETとゲートドライバ共に死んでしまっていた。しまった…
仕方ないので、球アンプに移行して再開。

アンプは片チャネルしか使わないので、残りのチャネルに
iPodを繋いで、曲を聴きながら快適にデバッグが出来る。快適 🙂

やっと実験環境が回復したので、停波したあとつらつらと
書きためていたコードのデバッグ。
いくつかミスはあったが、そう致命的なバグもなく動いてくれた。

54 , 175 mSec
Hour Parity(PA1) OK
MinParity: 1
Minute Parity(PA2) OK
YEAR_DIFF : (20)11
DAY_DIFF : 76
Zero!! ———————
TIME : 2011/03/17 21:03:01.000
42 , 165 mSec

パリティが合わない問題も解決したみたい。
これで年月日時分秒(mSecも)全て揃った。

正常系はこんな所にして、後は異常系を作り込もうか。

>おおたかどや山標準電波送信所(40kHz)は停波中です
>3月12日19時46分、福島原発に伴う避難命令に従い
>おおたかどや山送信所は停波措置を取りました。
>復旧の見込みは未定です。
>利用者の皆様にはご迷惑をおかけしますが
>ご理解のほどお願い申し上げます。
URL : http://jjy.nict.go.jp/

との事だ。 災害時だし、仕方ないよね。

前回までで、3つの状態(M,0,1)のパルス幅を定義出来た。
今回はそれを使ってビット列の評価を行うところ。

60秒で60bit(1pps)のデータを受け、それが1データとなる。
データはビットシフトを使って最下位ビットに判定結果を入れる方向で
実装してみた。

表現される状態が2より多いため、2値で表現する事が出来ない。
そのため、64bit幅(longlong)の変数を2本用意して
ビット方向に同期させている。

longlong JJY_DAT … 1の条件:”1″ , 0の条件:”0″or”M”
longlong JJY_MKR … 1の条件:”M” , 0の条件:”1″or”0″

と、2つの変数で、それぞれ1/0のもつ意味が異なる。
MKRの方はマーカ(M/Pn)が”有る所”を”1″にする。
DATは、データの”1″が有る所を”1″にしている。
つまり、データ”0″は、MKRが”1″ではなく、かつDATが”0″の所
…という事だ。

マーカの来る位置というのは既知なので、全60bitの中で
マーカが来るはずの所全てを満足する条件をMKRからひたすら探す。
条件に合うタイミングで、DATを取り出すと、既知のデータが
取り出せる。　と、こういう訳だ。

取り出した結果がこれ。

>33 , 779 mSec
>19 , 218 mSec
>Zero!! ——————— (23:18分ジャスト)
>Minute Parity(PA2) OK
>Minute : 17
>9 , 245 mSec
>978 , 808 mSec

“Zero!!”というのが、マーカ照合が通った所。
これは正分(0秒)を示していて、ここから次のデータが始まる。
始まりを検出というよりは、終わりを検出しているので
分データはリアルタイムと比較すると1分過ぎた値を示している。

時データと、分データにはパリティがあり、パリティの照合を
行った上でデータとして採用する事にしている。

取り敢えず、分の取得が出来たので、年、日、時、分、曜日の
全データをデコードして表示してみようと思う。

統計処理を行うにあたって、そもそもどんな品位のデータが来るのか
知るために、数時間の間データを取ってみた。(n=21691)

前記事の0秒時刻ズレは累積誤差なので、今回の評価には影響しない。
一応仕様では、200mSec(M) , 500mSec(1) 800mSec(0) という事になっている。
恐らく受信部の都合だと思うけど、マーカ(M)は若干パルス幅が長くなる傾向が見える。

中央値から±100mSec程度の所に大部分のパルスが来る勘定だ。
この結果から
200mSec(M) : Max(350mSec),Min(150mSec)
500mSec(1) : Max(600mSec),Min(400mSec)
800mSec(0) : Max(900mSec),Min(700mSec)
この辺りにしきい値を置いてみたいと思う。

>1. 1ppsで来るJJYタイムベースと、FW上の1ppsタイマの同期
今回はこの部分の作業。
今まで、ATtiny2313A環境で進めていたんですが、RAM容量が足りな過ぎて
統計部分の実装が出来なくて、仕方なくATmega88Pで作ったブレッドボードに
JJY受信パルスを引き入れてデバッグする事に。

実際に基板に載せる石は、ATmega168P辺りになりそう。(安いから)

このデバッグ環境移植によって、PCのモニタが点くとJJYの受信が出来なかった
状況が改善。シリアルも接続できて、デバッグがラクになった。

左側に有るのが受信部。黄線で繋がった基板(中央)がATmega88P。右がデバッガ。

今まで、デバッガでブレークしてそれらしい値に見えていたパルス幅や
パルスの立ち上がりが来るタイミングをシリアルで出力して記録出来るので
今まで気がつかなかった悩みが。

10mSec毎にカウントアップするタイマを見て、JJYパルスのエッジを検出して
パルスのエッジがタイマ上どこに来ているのかを調べているのだけど
エッジが来る(タイマ上での)時刻が、じわじわ進んでいる。
…いや、結構どんどん進んでる。

左側の、少しずつ減っている値が、エッジを検出した時のタイマ値。
18.43200MHzだと仮定しているシステムクロックが、実際は結構ズレている
という事なのだけど、どうしようかねぇ。オシレータでも使うか…？

//—————————————————-
110306追加

1秒毎に受信されるパルス幅を9時間ほど連続で記録してみた。
記録したデータを元に、内部時計とJJYとの偏差を
グラフ化してみたら、約2.4kHzくらいクロックが想定よりも
速いっぽい感じ。昨夜進んでいるように見えていたのは正解だったかも。

横軸はリアル時間(秒)、縦軸がシステム時間(10ミリ秒)。
ここまでずれちゃうとダメだけど、ある程度のズレは
時計の内部処理の一環として補正していかなくちゃな。

補正を試してみたが…

これは補正が効きすぎ。原発クロックから、ハードウェアタイマの方で
分周を掛けているのだけど、その分周比が大きすぎて設定値を1動かした
だけで過剰補正になっちゃう。

分周比を落として、内部カウンタのカウント値を大きくする方向で
プログラムをいじってみよう。