Made by Susutawari>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動かした
だけで過剰補正になっちゃう。
分周比を落として、内部カウンタのカウント値を大きくする方向で
プログラムをいじってみよう。
FWのクロックを調整するのではなく、パルスの立ち上がりから立ち下がりまでの時間を計測して3種類の信号を判別するのではどうでしょうか？
3種類のパルスはそれぞれ300msもの開きがあるので、10ms毎に割り込みを発生させてその時の波形のHigh/Lowを記録してHighの回数で判別する。±何回かの変動を許すようにする事もできますし、1波形（1秒）毎にカウンタをクリアするのでFWのクロックの精度もさほどいらないと思います。あり得ないくらいの短いイリーガルパルスも簡単に除去できます。
アナログ比較器による捕獲起動を使用すればもっと厳密に計測できますが、そこまでは必要ないかと…。
コメント有り難うございます。
>10ms毎に割り込みを発生させてその時の波形のHigh/Lowを記録してHighの回数で判別する。
そう、今はまさにその方法で実装しています。
記事中のターミナル表示(二桁mSecとなっていますがx10して
お読みください)のパルス幅はそうして測定しているものです。
パルス幅の測定精度を問題にしている訳ではなくて
JJYの受信パルスエッジを検出して、JJY由来のエッジに
内部時計を同期させる処理を想定していて、正確に1.00secであれば
エッジ同期だけで5分、10分後も内部時計の正秒がJJYのエッジを
捉えている事を期待出来るのですが、この内部時計の1秒が
例えば0.98秒だったりすると数分毎に同期を掛けないと
せっかくJJYに同期したのにどんどん時刻がずれていってしまうな。
…と思っていたのでした。
なるほど、時計側のクロック合わせだったのですね。
そうなると、何処まで正確性を追求するかという全体仕様のあり方
しだいですね。
水晶振動子だと相当悪くて週に1秒くらいの誤差でしょうか？
周囲温度にも依存しますが。普通の時計として使うなら、1日に1～2回JJYで補正できれば良いと妥協するのも手です。