wwvのデータ信号を日本で受信する設備は無いのでwwvsimをmanjaro linux側で実行させて
オリジナルのrefclockの動作をPC98で再生してみます
→ビットが1の経緯
epoch+11:13055.419252 13094.406783_1136.021777　信号が減衰しない　差が39

zer　13094 - 13055 => 39
one 11919
bit = 11919 - 39
2 -13337.
1 11880.
0 -11643.
?時?2分
ゼロは-11,000以下　いちは11,000以上 ブレは計算ミスに
#ntpd #refclock

jjyエミュレータの9:35をデコードしたログ。計算できていません、、

rsec bit-1302261.873522 2
rsec bit119405.032988 3

wwv4 4 0365 195 4654 5572 6 0 6 count:0 29704 2.9
0?分

rsec bit229111.309777 6

rsec bit-1463341.111422 8

wwv4 9 0345 195 4654 5572 10 8 4 count:0 76716 1.7
08分
ログは省いたけど28時となる
#ntpd #refclock

wwv_qrzのかわりに800miriseconds無信号のスキャンをするjjy_qrzを作成するには 以下は(コパイロットが考えた)Cのコードと仕様

チャットGPTに訊ねたら関数１つまるごと作ってくれます。はぇー #ntpd #jjy #refclock #epoch

ミルズ教授のエポックをAIは即理解したようです。

wwvの送信　refclock wwv.c_refclockのプログラムソースで実装している数値テーブル　jjyの送信 https://web.mit.edu/freebsd/head/contrib/ntp/ntpd/refclock_wwv.c https://www.nist.gov/pml/time-and-frequency-division/time-distribution/radio-station-wwv jjyではUnweightedが 1

比較してみました
信号をリファレンスクロックドライバーはどう取り出しているか、
jjyではどう変更するのか
→lpfは不要に　信号の継続する時間でマーカーかデータかを仕分けする
→→jjyの0秒マーカー200msec.がデータ(500/800msec.)より短く、見切りで判定してしまわないか動作を観察します。絵で描いてモニターしてみよう　Cでかかれたデータ分析部分をいまだに理解していません！コメントはいっぱい差し込まれているがほぼ学術論文
#ntpd #refclock #epoch #ってなんですか

enter mixer_set デバイス受付の入りをかくにん ioctl grpM writeモードを指定する　oooo4Dxyの分岐に到達したのをかくにん MIXER_LINEはオリジナルのサーバーならそのまま動作するとして、 Linuxでは、というよりCS4231サウンド処理部ではMIXER_LINE3に修正すると反応するようになります。 alsaドライバーのCS4231でやるのでは、 また少し異なる管理方法なのとpc98特有の修正をいれる必要が あり。それほど大きくは違わないですけどいまの時代に必要かな

PC98内のサウンドデバイスが/dev/audioでレコーディング出来るうえ
Solaris と同じμLawフォーマットが使えるのは僥倖だ！とまでは良かったのです
一秒毎にioコールしているのに(メッセージはカーネルドライバー側に埋めこんだ)何も起こらない
agcを働かせるには MIXER_入力デバイス　を特定する必要がありました。マイク端子はPC98のフリーウェア界隈ではaux2と呼ばれるものなので
agc line2
と1行　/etc/ntp.audio　を作ります　#ntpd #pc98 #refclock