最後は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日に出来ているようだ。バンド切り替えのロジックを考える。JJY地震によって福島原発で発生したトラブルによっておおたかどや送信所が停波したので、ここ茨城では標準電波を受信しながらのデバッグが難しくなってしまった。秋月で売っているJJYシミュレータは高いし、あまり複雑なハードを今から作るほど、手持ちの部品も気力もない。何か良いモノないかなーと検索していたところhttp://www.starstonesoft.com/JJY_Simulator.htmとても良いソフトをフリーで公開していただいているHPを見つけた。13.33kHzをPCで出して、その3倍高調波(39.99kHz)を電波時計で捉えてやろう...というモノのようだ。前に作って、PC用として常用していた自作のD級アンプにループコイル(ただの巻いた線だが)を接続してソフトを起動してみた。音量を上げていくと、...おお、受信しているぞ。動いていたのは数十秒。受信しなくなってしまった。アンプを確認すると、どうやら終段を飛ばしてしまったようでFETとゲートドライバ共に死んでしまっていた。しまった...仕方ないので、球アンプに移行して再開。アンプは片チャネルしか使わないので、残りのチャネルにiPodを繋いで、曲を聴きながら快適にデバッグが出来る。🙂やっと実験環境が回復したので、停波したあとつらつらと書きためていたコードのデバッグ。いくつかミスはあったが、そう致命的なバグもなく動いてくれた。mSecパリティが合わない問題も解決したみたい。これで年月日時分秒(mSecも)全て揃った。正常系はこんな所にして、後は異常系を作り込もうか。JJY>おおたかどや山標準電波送信所(40kHz)は停波中です>3月12日19時46分、福島原発に伴う避難命令に従い>おおたかどや山送信所は停波措置を取りました。>復旧の見込みは未定です。>利用者の皆様にはご迷惑をおかけしますが>ご理解のほどお願い申し上げます。http://jjy.nict.go.jp/との事だ。災害時だし、仕方ないよね。JJY前回までで、3つの状態(M,0,1)のパルス幅を定義出来た。今回はそれを使ってビット列の評価を行うところ。60秒で60bit(1pps)のデータを受け、それが1データとなる。データはビットシフトを使って最下位ビットに判定結果を入れる方向で実装してみた。表現される状態が2より多いため、2値で表現する事が出来ない。そのため、64bit幅(longlong)の変数を2本用意してビット方向に同期させている。0の条件:”1′′or”0′′と、2つの変数で、それぞれ1/0のもつ意味が異なる。MKRの方はマーカ(M/Pn)が”有る所”を”1′′にする。DATは、データの”1′′が有る所を”1′′にしている。データ”0′′は、MKRが”1′′ではなく、かつDATが”0′′の所...という事だ。マーカの来る位置というのは既知なので、全60bitの中でマーカが来るはずの所全てを満足する条件をMKRからひたすら探す。条件に合うタイミングで、DATを取り出すと、既知のデータが取り出せる。取り出した結果がこれ。mSec“Zero!!”というのが、マーカ照合が通った所。これは正分(0秒)を示していて、ここから次のデータが始まる。始まりを検出というよりは、終わりを検出しているので分データはリアルタイムと比較すると1分過ぎた値を示している。時データと、分データにはパリティがあり、パリティの照合を行った上でデータとして採用する事にしている。全データをデコードして表示してみようと思う。JJY統計処理を行うにあたって、そもそもどんな品位のデータが来るのか知るために、数時間の間データを取ってみた。(n=21691)前記事の0秒時刻ズレは累積誤差なので、今回の評価には影響しない。受信部の都合だと思うけど、マーカ(M)は若干パルス幅が長くなる傾向が見える。中央値から±100mSec程度の所に大部分のパルスが来る勘定だ。Max(900mSec),Min(700mSec)この辺りにしきい値を置いてみたいと思う。今回はこの部分の作業。今まで、ATtiny2313A環境で進めていたんですが、RAM容量が足りな過ぎて統計部分の実装が出来なくて、仕方なくATmega88Pで作ったブレッドボードにJJY受信パルスを引き入れてデバッグする事に。実際に基板に載せる石は、ATmega168P辺りになりそう。(安いから)このデバッグ環境移植によって、PCのモニタが点くとJJYの受信が出来なかった状況が改善。シリアルも接続できて、デバッグがラクになった。左側に有るのが受信部。黄線で繋がった基板(中央)がATmega88P。今まで、デバッガでブレークしてそれらしい値に見えていたパルス幅やパルスの立ち上がりが来るタイミングをシリアルで出力して記録出来るので今まで気がつかなかった悩みが。10mSec毎にカウントアップするタイマを見て、JJYパルスのエッジを検出してパルスのエッジがタイマ上どこに来ているのかを調べているのだけどエッジが来る(タイマ上での)時刻が、じわじわ進んでいる。...いや、結構どんどん進んでる。左側の、少しずつ減っている値が、エッジを検出した時のタイマ値。18.43200MHzだと仮定しているシステムクロックが、実際は結構ズレているという事なのだけど、どうしようかねぇ。-110306追加1秒毎に受信されるパルス幅を9時間ほど連続で記録してみた。記録したデータを元に、内部時計とJJYとの偏差をグラフ化してみたら、約2.4kHzくらいクロックが想定よりも速いっぽい感じ。昨夜進んでいるように見えていたのは正解だったかも。横軸はリアル時間(秒)、縦軸がシステム時間(10ミリ秒)。ここまでずれちゃうとダメだけど、ある程度のズレは時計の内部処理の一環として補正していかなくちゃな。補正を試してみたが...これは補正が効きすぎ。原発クロックから、ハードウェアタイマの方で分周を掛けているのだけど、その分周比が大きすぎて設定値を1動かしただけで過剰補正になっちゃう。分周比を落として、内部カウンタのカウント値を大きくする方向でプログラムをいじってみよう。今後のアップデートで対応を考えたいと思います。この製品を購入しました。ポートとして使えます。あれば電源のみの方が都合が良いかも知れませんね。ご連絡いただき有り難うございます。