横断歩道での一時停止は善意ではなく義務 (Powered by WordPress)
「この周波数お使いですか」「混信妨害与えますか」を，コールサイン送出なしに送信することが，いつの間にか「正しい運用」になってしまっているようですが，IDを付さない電波の送信は違法です．使ってなければこの後CQを出して当然IDも送出しますが，「使ってます」と言われたら，IDを送信しないまま他の周波数にQSYする(この周波数からは消える)ことになります．
「この周波数お使いですか，こちらはJE1SGH」となんで言わないんでしょう．たしかに，コールサインまでいうと長いですが，「…お使いですか」の後，一旦短く受信を挟めば良いだけのことです．
そもそも，使っているか確認するための電波の送信ってのは，法令的には決まりはないはずで，混信がないと確証が得られるまで聞くのが本来です．
世の中おかしな局がいるのは解ります．だから，お使いですかって念の為送信するわけですが，IDなしの送信では，自分もおかしな局になってしまいます．
現在，メインのWSであるMac mini，唯一のノートであるMacbook，サブのWSであるSlackwareの動くデスクトップ，それぞれに仮想環境があり，それぞれにDebianがインストールしてあります．
なぜDebianかというと，Ubuntuみたいに独自性に突っ走ることのないオーソドックスなLinux distroであり，デスクトップがSlackwareと共通で気に入っているKDEであるからです．
で，何に使ってるのといわれると，特に具体的な用途はないんです😓 まあ，Slackwareに自力でGNU Radioをインストールするのに疲れたので，パッケージングソフトで簡単にGNU Radioをインストール&アップトゥデートできるということが唯一の具体的な用途かも知れません．
しかし，GNU Radioに対する関心もかなり低下して，GNU Radioで何をやるのと言われると明確に回答できません😓 逆に明確な目標・目的がないからこそ3つもの仮想マシンを維持しているわけです．
その，3つの無駄にディスク容量を食う仮想マシンのうち，一番実用性が高いと思われるSlackware下のKVMで動かしているDebianを壊してしまいました．
どのように壊してしまったかというと，よく思い出せないのです．いつもと違う古いKernelで，Slackwareを起動してしまい，その状態でディスクエラーが出る（なぜ?）のに，仮想マシンを起動してしまったような気がします．しかし，Kernelのバージョンが古いから問題だったのか，このWS自体久しぶりに起動し，ハードウェアに何か不具合が生じていた為なのか，その辺り解りません．
たしかなことは，当該の仮想マシンであるDebianを起動しても正常に起動せず，ブート時にfsckをマニュアルでかけろとメッセージが出て止まってしまうようになったことです．そのインストラクション通りにfsckをかけてから再起動したらログイン画面は出るようになったのですが，そこでパスワードを入れても，またログイン画面に戻ってしまいます．Xか何か肝心なところが壊れているのかも知れません．
どのように直そうか迷いましたが，結局，昔，「別所」のWSで動かしていたDebianの仮想マシンをコピーして済ませました．古いけど，Debian 9 (Buster)なので，update & upgradeで最新の状態にできました．
今回は，upgradeした状態のスナップショットをとっておきました．仮想マシンはバックアップをとらないので，安定した状況のスナップショットをひとつ残しておくのは重要ですね．
さて，復活したDebianで何をしますかね😓
ログの原簿であるLog200のデータにある交信レコードをup-to-dateにしているメインのデータベースであるMariaDB (MySQLコンパチブル)のデータと照合して，MariaDBに欠落しているレコードがないか，を確認するプロジェクトですが，照合スクリプトの最終形が吐き出したエラー分について手で確認をしました．
MariaDBとの照合は，日付，時刻（±5分のマージン）とコールサインで検索しました．参考の為に，モードの違いについても，検索してヒットしたレコードと原簿のレコードについて照合して，違う場合はwarningとしました．
原簿にある7万9千レコード全部について照合するのに，190分ほどかかりました．そのうちほとんどがMariaDBが占めていて，PerlのCPU占有は30秒余りです．
その結果，モードの違いまでも含めると，540ありました．検索条件が違うので(4)の293件より多くなっています．
このうちwarning扱いのモードの違いをのぞいたエラーは，128件で，手作業で照合しました．
ほとんどが，コールサインの間違いです．もらったQSLカードで修正したものがほとんどです．また，時刻の違いも何件かありました．時刻は，PCの時計データを取り込むようにしていますが，そのPCが仮想マシンのため，仮想マシンが再起動した直後に時刻データが不正確であった可能性があります（これは仮想マシンの特定のバージョンにより含まれているバグです）．可能性は低いとはいえ，自分が間違っている可能性もあり，間違っているのは自分か相手か断定できません．しかし，もらったQSLカードに返信の形で発行するQSLカードは相手の時刻に合わせた方が無難なので，ほとんどのケースで相手に合わせて修正してます．
完全な漏れは，先に判明したUR2FEO局の2交信分の他は，8N2SEA/2局との1交信のみでした．いずれも追加済です．思っていたよりうんと少ないレベルなので，安心しました．
これで，少なくとも原簿であるLog200に記録されている交信は全てメインの交信データベースにあるという状態にできました．
ただし，多くはない思いますが，原簿に漏れている交信もあるはずです．それらについてはどうしようもないです．QSLカードが届いて，該当する交信レコードがないときはこっそり追加するしかありません😓
最初のバージョンでは，日付とコールサインとモードが一致するという条件にしました．レコードが完璧に抜け落ちていたのは，2QSOのみで，それがいずれもUR2FEO局です．全くの偶然か，そのコールサインだけひっかかるような原因があるか，当時のLog200からMySQLにexportするスクリプトは残っていないので，全く探りようがありません．
この段階で，レコードの不一致があったものは，293件です．全レコード数は，7万9千件ほどなので，0.37%です．先日発表された，東京の新コロナの抗体保有者とコンパラです😓
目だったレコードの不一致は，モードの不一致です．50MHz帯の交信のSSBとCWが入れ替わっていることが多いです．周波数からモードを自動的に決める機能が，50MHzではあだとなっています．交信相手からQSLカードをもらって，気づいて修正しているところが多いです．
MariaDB(かつてはMySQL)のデータは修正しますが，オリジナルのログデータは修正しないことにしているのでこの不整合が発生します．
考えてみれば，ログソフトからMariaDBに取り込むときの漏れを問題にしているので，モードの不一致はドントケアーとします（警告だけ出すようにします）．
その代わりに，時刻を±5分のマージンで絞ることにしました．この制限を付けても，全体の処理時間はほとんど変わりません．
そんな感じで何度か試行錯誤して練ってきたほぼ最終版を今走らせています．一度走らせると3時間待たないと結果が出ないので，試行錯誤のサイクルは長いです．
今日は少し元気なので，課題に😓実質的に着手しました．
とりあえず今日のところの成果物は，日付とモードとコールサイン指定して，検索して，もし結果が返らなかったら”die”する，つまり最初に未登録のデータを見つけたらそこまででおしまいというプリミティブなものです．
作業的には元のスクリプトから削除するのが大部分となりました．
走らせたところ，3時間ちょっとで終了です．Perlの実行時間はなんとそのうちの33.7秒で，ほとんどはmysqldの所要時間です．
topからも，そこら辺が解ります．
まだ，dieしなければ，何にも返ってこない仕様なので，これだけではスクリプトが正しいかどうか解りません．また，日付とモードとコールサインだけで指定しているので，コンテストなどだと，複数レコードが返ってくるはずなので，そこら辺を表示するように改良したいと思います．