まだ、もう少しありますがコンディションも良くないので早々に店じまいモードで、LoTw,Clublogの集計結果、、、、。
Covid-19でDXPeditionも少なかったこともありますが、過去5年間のモード別QSOを見るとDigital(FT8)が多いことに驚きますね！ JTAlertでバンドワッチが出来るので、どうしても主たるモードになってしまいます。
11,12日と30mのFT8で20~22Zに4U1UNが結構強く入感していて、バンド中4U1UNを呼ぶ局で埋まっているような状況。 その上、QRMなのか4U1UNが返してきても、RR73/73が受け取れないためか、何度もR-xxを送り続けてQSOが成立していない！ この時間帯EUも聞こえているので、滅茶苦茶に混んでいて、二進も三進も行かないように見える。
ご近所の局はすんなりQSO出来たのに、私メは1時間以上呼んでもバツ！ 「アンテナおかしいんかな？ 」なんて、ダイポールであることを忘れて、イライラ。
結局できなかったので、 昼間4U1UNに「30mで良く入っているけど、バンドが貴局を呼ぶJAで埋まっているし、QRMで中々QSOが成立していなくて、非効率だから10131KhzでFT8のF/Hしたらいかがですか？」ってメールしてみました。
で、言い出しっぺなので、今朝は30mを目を凝らしてみていましたが、バンドコンディションが良くなかった所為か、全然ダメで、メールの効果も無い？
取り敢えずは、dxsummit.fiで4U1UNを検索してみたら、「あ～、ちゃんと言う事は聞いてくれたみたい」。
4U1UNだけでなく、珍だと自覚している局は積極的に F/Hモード使ってくれると助かりますが、、、。F/Hの周波数も、バンド毎に3つ位あると、もっと使う局が増えるかもしれません。
あとは、コンディションと、彼らのオペレーション時間と、私の運だけ！ 今年中に出来れば御の字ですが、、、。 （何故か40mのCWしかないんですよ。 UNの建物の開いている時間の問題なのかな？）
>> 40m CWでのQSO log見てみたら、昨年の12月12日のQSOでした。 この位の時期（短期）限定でしか出ていないのかな？ dxsummit.fiで見ても12日が最後になっています、、、シュン、、、、
今朝７MhzのFT8でFS4WBSが出ていて、調子に乗って呼んでいたらトラップが死んでしまい、急遽QRT。 天気も良いので、アンテナ降ろしてトラップを昔の物に交換することにしました。 （前の奴はQが少し低いので、多分大丈夫だろうと期待して、、、）
で、80mの片側のエレメントだけ130cm伸ばして、一応3バンド内のＳＷＲは問題の無い所に追い込みました。
トラップの故障の原因は、Ｃに使用している同軸の心線と外皮の間で放電してしまう事により、絶縁体のＰＥが溶けることによるのですが、放電部位は心線の先端と外皮の先端という事ではなく、防水に自己融着テープを巻きつけ、外皮を剥いた絶縁体(PE)の途中まで巻き付けていたりすると、その界面の所で放電が起こるようです。 多分、外皮を剥いた絶縁体(PE)を外皮を剥いた根元から先端まで一様に誘電率の一定のテープで覆ってやる必要がある、のだと思いますが、要確認。 何れ実験して、とは思うのですが、、、、。
現在の寸法図；
各バンドのSWR； 30m/40m/80mの順。（右下の図は無視してください、トラップの調整に使っていたS21がそのまま残っていました。）
朝のお勤めで、5時前にPCの電源入れたら、起動せず！ 修復モードで再起動させるもダメ！ で、例によってデータファイルを失う事に！
「そうだ、HDCopyでフルバックアップが取ってあった」と気が付いて、バックアップファイルから起動させると、「お、立ち上がった！でも10月19日までタイムスリップ！」 復活させるのは気が重いな～、と思っていましたが、MSのOneDriveにバックアップが取ってある物が幾つかあったので、データの修復はLogger32だけで済んだみたい（ほんとはもっとたくさんあるんかもしれませんが、、）。 eQSLにアップロードしてあったQSOファイルをダウンロードして、必要な部分だけ切り出してadiファイルにして、Logger32でimport。 これで、QSOデータの復元は一部出来ましたが、これではrcvdRSTがブランク！ これは仕方ないか、、
それで、原因は何かと想像するに、boot時に書き込み・読み込み？が出来ません！とのエラーでrebootしているので、windows11に掛かるUEFIの設定をdisableして、再起動できるようになっています。
Windows11への移行に必要かと思い、「おまかせPremium引っ越し」なる物を購入していたのですが、突然の不具合には対応できずに、こいつの出番は無く、結構なデータを失う羽目になってしまいました。 そう、「修復」等という甘い言葉は無視して、最初からフルバックアップの他のSSDから起動させればよかったのですが、、、。
何度でも同じことを繰り返しているようで、癪に障りますが、落ちたり再起動するタイミングが分からない以上、また同じことを繰り返す事になるんでしょうね。 せいぜい頻繁にHDCopyでフルバックアップをとっておくのと、データの復元が難しい時系列データなどのファイルはOneDriveに入れておく事ぐらいしかできませんね～。
2年ほど前（コロナ禍前）に、いなかのPCが調子悪かったので、今回余っているAsusのMBとGraphicBoardを持って行って差し替えてみましたが、起動せず。 電源が入れども、起動直後に再起動を繰り返す！ 「うん、昔あったな？ ひょっとして電源？」 家を出る前にATX電源の余分を持って来ようか思案したのですが、「重たいので」止めたのでした。
で、結果、PCを動かすことが出来ず！ 次回来るときにATX電源を持参することにしました。 ATX電源って結構コンデンサの劣化なのか、時間が経つと「ダメ」になることがありますね～。
2φの銅線で60φ位のトラップを作って使用していましたが、気の所為かコンディションか、気に入らない（受信が悪いように思われて）ので、昔の4φのアルミ線のトラップに変更してみました。 巻き芯を115φの塩ビ管にして上げてみたのですが、流石にちょっと重たい感（7Mhzトラップで430gr位） があったので、ヘリの塩ビだけを残して、中の方は中空（2mmのアクリル板に自在ブッシュを張り付けた物を渡す）にして100gr程重量を落としたものに変更して、最終調整しました。 ついでに、エレメントの長さなど測れるところは測り直して、後日の為の記録とします。
最終的なエレメントの長さ；
トラップを都合4回ほど変更して、その都度エレメントの調整をした為に、80mの部分のエレメントの長さが、今までと少し違っているように みえますが、これが現在の実測データ。
nanoVNAによるVSWRの値
EZNECのVSWRシミュレーション（合わない！）
LoadsのCの値を同軸の長さで指定しても全く合わないので、共振点が実態に合うようにCの値を増やして(～10pF)、30/40mの共振点を合わせてみましたが、80mは200Khz程高い所にあるようにシミュレートされました。Cの追加量は、周りとの迷容量を考えれば「こんなもんかな？」です。
計測点が違うので参考までに30/40mの給電点インピーダンス (左から実測、nanoVNAのs1pデータから給電ケーブル長補正した給電点でのインピーダンス、 シミュレーションの値）
40m: 31.7-j6.08 33.1 - j1.2 38.75+j14.7
30m: 42.9+j3.75 38.9 - j1.6 42.11+j0.5319
上の塩ビ芯コイルでは重たいので、左の様に、真ん中を空芯として、アクリル板と巻き線ガイド用の自在ブッシュを張り付けた物を渡して、接着剤で固定。
尚、線を巻いているときは、強く線を張るのでアクリルでは耐えられず、後で取り外せるようにスリットを入れた塩ビパイプの切れ端を入れて巻いています（下の写真）。
接着剤が余計なところに付着して悪戯しないように、離形シートとしてポリエチレンの袋を使用しています（右）。
予備に作成した、出来上がりのコイル、これで20μH位あります。
追加） 備忘録に、今回使用した塩ビとアクリルの接着、及びアクリルとナイロン（自在ブッシュ）との接着には下の2つの接着剤を使いました。
５BWASが始まってすぐに「アジアで最初！」を狙って始めましたが、それから50年、未だにあと2つ（80:RI, 10:ID)で止まってしまっていますが、東京 のコールでは、FT8のお陰で4年程でここ迄来ました。
遥50年前、US CQのCallbook片手に、兎に角Wを無差別にやりまくって、特定の州のめぼしい局にはメールを送ってスケジュールをお願いして、、、。
今では、JTAlertが勝手に必要な州の局見つけてアラート出してくれるし、QSLもLoTｗでconfirmできるし、昔のことを考えると申し訳ないくらいにラクチン。
静岡での5BWASと東京での5BWAS(8BWAS)、来年には完成させたいものですが、どうなるか？
J5HKT, 3DA0RU, 3DA0WWを皮切りにペディションが始まりました（終わった）が、SNも上がってきて高い周波数のコンディションもマズマス。 で、昔からのcfm見てみると、結構cfm出来ていないものがありますので、この機にChallenge用に穴の開いているところを埋めようと、必要なバンドのワッチを続けています。
J5は10/12mが出来ませんでした。残念。
で、7P8RU(3DA0RUのグループ）のオペレーションが始まったので、QSLの状況を見ると、40/20/10m以外が無い事に気が付きました。
Clublogで確認。
7P8RUに気を取られていてCQ WWの3A3Aを無視していましたが、今日はQRV確認できず、しまった！と悔やんでいます。
HD8Rも出ていますので、80mでのQSOを狙って出来れば、Galapagosも終了。
一昨日は、朝の12mのコンディションが良く、USのStatesをかなりこなすことが出来ましたが、 今朝はそれほど良くありませんでしたね。 まだ日によって安定していませんね。
しかし、FT8様様で、WSJT-ｘ見ていて、クリックすれば即どのバンドでも 送信できるのですが、、ＣＷやPhoneはそうは行かず、ちゃんと送信したいバンドのＴＸボタン押さないとその周波数で送信できない！ 暫くは、気が付かずに、ちっとも呼んでも答えて貰えず、落ち込んでいました。 ついでに、Phoneの時はDAXボタンoffにしておかないと音が出ない！（Flex 6000の話です）
うーん、かなり腕が錆びついていて、楽なＦＴ８生活を反省。
市販のアンテナは、無調整でもほとんど問題なく希望の周波数に同調しており、ほんとに簡単ですね。 他のアンテナに対しても、特に影響も無く、全て正常に稼働し、また、タワーの昇降時の音が大分静かになったのはありがたい。
全部のアンテナの同調点をシャックからnanoVNAで確認してみましたが、案の定80mダイポールは、温度かテンションか少し伸びて同調点が下がってましたので、20cm(15cm+5cm)程切り詰めて、3.53Mhzに中心周波数が来るように微調整。
備忘録として、本日のnanovna-saverの測定データ（80,40,30,6m)を添付。
2～3年前秋月にコパルのSPG27-1101が安価で出ていたので、使い道も考えずに纏め買いして、ジャンクボックスの肥しになっていました。 で、バタフライバリコンでこれを使ってリモートで、と当然考え、これのドライバをESP8266とDRV8835で作ってみました。
SPG27のスペックシートを見ると12Vでの動作が出ていたので、つい「12Vで動かす必要がある」と思い込んでいましたが、DRV8835のVMmaxが12Vです。 気にしないで、12V加えていましたが、 突然動かなくなって、ESP8266もUSB入力を受け付けなくなってしまうものが幾つか出てきました（壊れている！）。
壊れそうなところは無いので、最初原因が分からず色々考えていましたが、DRV8835のVM maxが一番怪しい！という事で、電圧を5V位まで落としてみましたが、StepperMotorはちゃんと動いてくれます（トルクが少し落ちているかもしれませんが）。 また、動かなくなることも今のところないようなので、結論として、12Vが拙かった！
ちょっとした勘違いで、可愛そうなESP8288とDRV8835を幾つかお見送りしてしまいました。Amen...
SPG27-1101は基本ステップ角度3°で、これに5:1のギアでMLAのバタフライバリコンを動かしています（0.6°/step)が、100pF程度のバタフライバリコンだと、まだ粗い感じがあります。
マルチバンドのMLAの場合は、多分、固定コンデンサと小容量のバタフライバリコンの組み合わせ、等を考える必要があるのでしょうね。 この時、固定コンデンサの切り替えをリレーで行うとすると数十Aの高周波電流を許容するリレーをどうするか？が問題になりそう。
備忘録としてfritzingのBreadboardとPCBのコピー、それにsketchを添付しておきます。
// For use of DRV8835+SPG27-1101
// Author Ken Yamada, JA2IYJ
// WeMos D1 mini
// Date: 2019 July 3rd. V0.5 Initial version.
// July 11th V1.0 Zero_sensor added and bandled to the workable protype hardware.
// 2020 Nov. 11 v2.0 MAX_sensor added.
// 2021 Apr. 23 Modified for Butterfly Capacitor ... No need of Max/Min Stopper.
// 2021 May. 19 EEPROM.write/read/commit added to set initial and current Position.
// 2021 Sept. 3 Changed Up/Dwn/Init pin to reflect PCB alignment. Motor runs at 5V.
// Above 11V, DRV8835 might die and kills ESP8266 too.
//
#include <Stepper.h>
#include <EEPROM.h>
#include <ESP8266WiFi.h>
#define EEPROM_SIZE 2 // sizeof(int)=2 byte.
#define TRUE 1
#define FALSE 0
#define MOTOR_1 16 //15 DRV8825のピン配置に合わせて変更 5/22
#define MOTOR_2 14 //12
#define MOTOR_3 12 //13
#define MOTOR_4 13 //14
// digital address それぞれをボタンにアサイン
#define UP_BUTTON 0 // 黄色
#define DOWN_BUTTON 4 // 白
#define INIT_BUTTON 2 // Position 0 setting (GPIO16 has a built-in pull-down resistor.)
#define STEPS_PER_REV 120 // SPG27-1101 specification
#define MAX_POS 155 // 90deg/3deg step, 5:1 gear = 30 x 5 + α
// stepPerRotate は素のモーターの一回転当たりのstep数の様です（ギアの事汎用では顧慮できないもんね）
//const int stepsPerRotate = 20;// SPG20-1332ス テップ数 = 480 ギア比1:24 hence 20
const int stepsPerRotate = 12;// SPG27-1101 ステップ数 = 120 ギア比1:5 hence 24 でも12でないと動かない！ 何故？
int curPosition;
int initPosition;
boolean toggle1 = FALSE;
boolean toggle2 = FALSE;
Stepper myStepper(stepsPerRotate, MOTOR_1, MOTOR_2, MOTOR_3, MOTOR_4);
void setup(){
Serial.begin(115200);
Serial.println("\n Setup ...");
// WiFiを使用しないので、省電力化の為に下の3行
WiFi.mode(WIFI_OFF);
WiFi.forceSleepBegin();
delay(1);
//EPROM.begin(EEPROM_SIZE);
//initPosition = EEPROM.read(0);
//curPosition = initPosition;
Serial.print("\n curPosition = ");
Serial.println( curPosition );
pinMode(UP_BUTTON, INPUT_PULLUP); // 手動制御用のUp/Down ボタン High
pinMode(DOWN_BUTTON, INPUT_PULLUP); // 手動制御用のUp/Down ボタン High
pinMode(INIT_BUTTON, INPUT_PULLUP); // One time.
myStepper.setSpeed(2000); // 2500位まではOKの様です。
//myStepper.setSpeed(50); // make it slow
Serial.println("\n End of Setup ...");
}
void loop(){
Serial.println(" Start Loop ---");
// 初期設定の時に容量最大値の位置を0に設定する。
#if 0
if( digitalRead(INIT_BUTTON) == LOW) {
EEPROM.begin(EEPROM_SIZE);
EEPROM.write(0, 0);
EEPROM.commit();
Serial.println( " Wrote EEPROM -> 0 ");
delay(500);
}
#endif
// Up button
if( digitalRead(UP_BUTTON) == LOW ){
Serial.println("Up button 1");
// while( digitalRead(UP_BUTTON) == LOW && toggle1 == TRUE && curPosition < MAX_POS){
while( digitalRead(UP_BUTTON) == LOW ){
myStepper.step(1);
curPosition++;
yield(); // Soft WDT reset が出ない様にするため。
delay(50);
}
}
// Down button
if ( digitalRead(DOWN_BUTTON) == LOW ){
Serial.println("Down button 1");
// while( digitalRead(DOWN_BUTTON) == LOW && toggle2 == TRUE && curPosition > 0 ){
while( digitalRead(DOWN_BUTTON) == LOW ){
myStepper.step(-1);
curPosition--;
yield(); // Soft WDT reset が出ない様にするため。
delay(50);
}
}
stopMotor();
#if 0
if (curPosition != initPosition ){
EEPROM.write(0, curPosition);
EEPROM.commit();
initPosition = curPosition;
Serial.print( "Save curPosition = ");
Serial.println( curPosition );
}
delay(10);
#endif
Serial.println(" End of Main loop ...");
delay(10);
}
void stopMotor() {
digitalWrite(MOTOR_1, LOW);
digitalWrite(MOTOR_2, LOW);
digitalWrite(MOTOR_3, LOW);
digitalWrite(MOTOR_4, LOW);
}
#if 0
int moveAbsPos2(long pos){
if (pos < maxPosition) {
myStepper.step(currentPosition - pos);
currentPosition = pos;
} else {
return -1;
}
}
int incrementPosBy(long pos){
if (currentPosition + pos < maxPosition) {
myStepper.step(pos);
currentPosition = currentPosition+pos;
} else {
return -1;
}
}
int decrementPosby(long pos){
if (currentPosition - pos > 0 ){
myStepper.step(-pos);
currentPosition = currentPosition - pos;
} else {
return -1;
}
}
#endif
MLAはQが高くないと効率が上がらない。 Qが高くなるとループには大きな電流が流れる。 「うん？ 自作のバリコンって大丈夫？」等と思いながら、バタフライバリコンを調子に乗って大量試作していました。（バタフライバリコンなら、摺動部からの配線ーローターからのーが必要ないので、特殊な事をしなくても抵抗値を低く出来る）。
結果「あいやー！ 酷いね」。何も考えずに、ユニクロ（鉄、ユニクロームメッキ）やステンレスのM5ボルトとステンレスナットを使用していましたが、ステンレスは最悪の組み合わせでした。
アルミボルト、アルミナット にすると目を見張るような改善が見られました。 また、締め付け強度やナットの材質の影響が大きい為か、大容量（プレートの数が多い、距離が長い）だから抵抗が大きい、という結果にはなりませんでした。
何も考えずに、使っていたステンレスが電気的には鬼門だったことに些か驚いています。
1m角ループのMLAを作ってみましたが、JR1OAO中島氏の言われている、Ct,Cmの値と大きく違うので、中島氏の所へ持ち込み確認して頂いたところ、4隅の接続点に使用したL金具が
我が家の室内で、実験をしてみると、やっているうちにCt,Cmの値が何故か昔の状態に戻るような感じになってくる。 定電流電源の持ち合わせが無いので、ループ全体の抵抗を測るわけにもゆかないので、ループのQをループアンテナの動作確認の指標とすることにして、手持ちのnanoVNAを使って、どうやったらQを簡単に計測できるかググってみました。 S11を使ってQを測定する方法については、いくつかレポートがありましたが、ココにnanoVNAを使った方法についての議論がまとまっていました。
「if you measure Z11 using S11 then the Q is given by fc/ BW where BW is taken between |Z|/Sqrt(2) points on your frequency plot. Or alternatively taken between +/- 45 degrees on the phase plot.(tuckvk3cca)」
Q ＝ fo/BW foは中心周波数でBWは
という事のようなので、実際にnanovna-saverで表示させて、１～３まで、使用できるか検証してみました。 （図では、VSWRで求めた周波数の点を、夫々のグラフ上で結び縦軸上の値を見やすくしてみました）
結論から言えば、左の図の左下のVSWRで確認する方法が、簡単かと思われます。
２の方法は上右の図のように、相当する周波数の値が読み難い。
３の方法は、phaseが急激に変化するので、+/-45°をグラフ上特定することが難しい（そもそも中心周波数で0°になっていない？）
ということで、VSWR=2.618の点を利用するのが最も簡単だという結論に至りました。 但し、2.618という値が視認できるためにはScan範囲がかなり小さくないとダメなので、中心周波数とScan幅を絞ってゆく作業が必要になります。
当然の話ですが、Markerで夫々の点をポイントし、左の表示の周波数の値から計算する必要があります。
で、左の数字を見ていたら、Quality factorというのがあり？？ MLA48のdiscussion roomでQしてみたら、藤井さんから、 Impedance 50.4+j760mΩから Q = 0.76/50.4 =... ということでした。 正直な話、これってQ ってQ(uestion)が湧いてきますが、、。
2.618については QRP RXが当該のページで下のように説明していました。
”The magic value VSWR = 2.618 can be found from this equation:
内田さんからの依頼は、試作と動作確認だったのですが、バラックのままでは、ジャンクボックスの肥しにしかならないので、筐体を作って収めてやろうと考えたら、元々が、CW decoder/keyerの為にデザインされた基板なので、単体のKeyerとして筐体に入れようとすると、micorUSBコネクタの位置がちょっと塩梅悪い（これだけケースの横から出ることになる）ので、FT234ｘでは塩梅が悪く、MCP2221Aと秋月の「ＵＳＢｍｉｃｒｏＢコネクターパネル取付キット」の組み合わせに変更することにしました（基板はFT234XかCH340互換のMCP2221Aのどちらか一つを選択できるようになっている）。
あ、チョンボ！ FT234ｘでないと、ＵＳＢ接続したソフトがWinKeyとして認識してくれないので、この選択はありませんね(MCP2221Aに置き換えて認識して貰えなかったので、気が付きましたーおバカさんでした）。
ただ、FT234xが基板直付けでmicroUSB Bコネクタが横から出ているので、秋月のmicroUSB Bコネクタのパネル取り付けキットを加工して、FT234xモジュールをパネルの方に取り付けて、ジャンパー線で基板と繋ぐようにしました。
１）FT234ｘをパネルに取り付けるように改造
秋月のmicorUSB Bパネル取り付けキットの基板から表面実装のmicorUSB Bコネクタを外す（左ー＞右）
FT234xモジュールのパネル取り付けキットを作ってくれると、こんな事しなくて済むんですけどね～。
２）で、筐体は？ いろいろ探しても適当なものが見つからず、結局はアクリル板で自作することに、、、。
小型のインジェクタでやってみたら、注射の時と同じで中の空気を押し出してやると、少量が注入量を細かく制御でき、接着部分に毛細管現象でうまく広がり綺麗に接着出来ました。
後は、シールドは全くなく、結構ジャンパー線が内部で引き回されているので、電磁波バンバンの環境では誤動作するかも、、、。
「あれ、地図にアンテナの方向が出てこない？」と気が付いて、USBのコネクタを繋いだり、外したり。 でも、解決しない！ 制御のためにJA5AUCのRTC-59を使っているのですが、USBのコネクタ（四角形っぽい方）の接触があまり良くなく、何度かトラブったことがあったので、そのあたりを中心に弄っても埒が明かず、Logger32でなくBGARTCを使って、なんどか接続の確認をしているうちにBGARTCでは繋がるようになってしまいました。 しかし、まだLogger32のRotorからは繋がらない！ 何故だろう？
あちこち抜いたり挿したり、3時間近く悪戦苦闘してしまいましたが、後味の悪い（結論の出ない）状態。
Logger32の窓の一番下に、設定内容が表示されており（青だと接続、赤だと非接続）、これを見れば一発で分かるのですが、一度設定すると、電源切っても、立ち上げると直前の状態で立ち上がるので、 つい忘れてしまいます。 お騒がせでした。
横浜みどりクラブのJG1CCL内田さんが、雑誌原稿用にチェコのCW Decoder, CW Keyerを参考に国産版を作成されていて、 WinKeyer2との互換性の確認のために、私のところでCW Keyerを試作してみました。
ArduinoIDEはいつもESP8266の書き込みに使用しているので、ArduinoNanoEveryでの使用の為の設定など、ちょっと不安がありましたが、特に問題なく書き込みが出来ました。 使用したsketchは、K3NGのものでweb上にも、色々書き込みがありますが、「おーっ、デカい」。 ちょっと全部を読むのは断念。 なんかあれば、適宜つまみ食いすることに、、、。 内田さん、ご苦労様です。
Logger32のCW Keyのモジュールはcom port番号が一桁しか拾ってきてくれないので、Windows10のデバイスマネージャー、ポート、、、、で空いている一桁のポート番号を強制的に割り当ててやる必要がありました。
FreeBSDのZFS(raidz1)に使用している3TBのHDDが壊れていて、ファイルシステムがdegradedを出していたので、今回はSSDに交換することにしました。 交換対象のHDDより小さいSSDを使ったらどうなる？って言うより3TBは無くて4TBになり、少々高価なので、試に2TBを入れてみましたが、案の定 too small ....と受け付けてくれません。 （当たり前か、、、）
やむを得ず4TBのSSDを購入して、インストール。 （４TBのHDDって選択もあったのですけど、何故かSSD買ってしまったので、とんだ散財）
ZFSでのHDDの交換については、以前ここに記載したのでそれをそのまま踏襲。 「実に簡単」 resilveringに小一時間掛かって無事終了。 と言っても、故障中も、交換中もサーバーは通常通り動いているので、ユーザーには何の影響もありません。
何か月か前に、誤って消したファイルの復活にもZFSが役立ったし、ほんとにファイルシステムの信頼性が高くて、安心して使用できます。 Sun Microsystems 様に感謝感謝。
久しぶりに写真の整理をしていて、DataServer(FreeBSD)に放り込んでいた写真を、撮影した年代日付毎のフォルダに入れてゆく作業をしていました。
Windows10からFreeBSDの共有フォルダが見えるようにしてある(Samba3)ので、操作はWindows上のexplorerから行っていました。 で、2020,2019,2018と降りて行った際に、間違って整理し終えた2018年のフォルダをうっかり消してしまって、真っ青！ これは、ゴミ箱からの復帰は有り得ませんし、クラウドにもこのファイルは上げていないし、、、。
あ、ひょっとして、ZFSファイルなので、定期的にsnapshotを取っていたのではなかっただろうか？ と、サーバーにアクセスして；
 |
| Crontabの内容（一部） |
# zfs list -r -t snapshot -o name,creation zroot/usr/home
NAME CREATION
zroot/usr/home@zfs-auto-snap_monthly-2020-06-01-00h28 月 6月 1 0:28 2020
zroot/usr/home@zfs-auto-snap_monthly-2020-07-01-00h28 水 7月 1 0:28 2020
zroot/usr/home@zfs-auto-snap_monthly-2020-08-01-00h28 土 8月 1 0:28 2020
zroot/usr/home@zfs-auto-snap_monthly-2020-09-01-00h28 火 9月 1 0:28 2020
zroot/usr/home@zfs-auto-snap_monthly-2020-10-01-00h28 木 10月 1 0:28 2020
zroot/usr/home@zfs-auto-snap_monthly-2020-11-01-00h28 日 11月 1 0:28 2020
zroot/usr/home@zfs-auto-snap_monthly-2020-12-01-00h28 火 12月 1 0:28 2020
zroot/usr/home@zfs-auto-snap_monthly-2021-01-01-00h28 金 1月 1 0:28 2021
zroot/usr/home@zfs-auto-snap_monthly-2021-02-01-00h28 月 2月 1 0:28 2021
zroot/usr/home@zfs-auto-snap_monthly-2021-03-01-00h28 月 3月 1 0:28 2021
zroot/usr/home@zfs-auto-snap_monthly-2021-04-01-00h28 木 4月 1 0:28 2021
zroot/usr/home@zfs-auto-snap_weekly-2021-04-18-00h14 日 4月 18 0:14 2021
zroot/usr/home@zfs-auto-snap_weekly-2021-04-25-00h14 日 4月 25 0:14 2021
zroot/usr/home@zfs-auto-snap_monthly-2021-05-01-00h28 土 5月 1 0:29 2021
zroot/usr/home@zfs-auto-snap_weekly-2021-05-02-00h14 日 5月 2 0:14 2021
zroot/usr/home@zfs-auto-snap_daily-2021-05-04-00h07 火 5月 4 0:07 2021
zroot/usr/home@zfs-auto-snap_daily-2021-05-05-00h07 水 5月 5 0:07 2021
zroot/usr/home@zfs-auto-snap_daily-2021-05-06-00h07 木 5月 6 0:07 2021
zroot/usr/home@zfs-auto-snap_daily-2021-05-07-00h07 金 5月 7 0:07 2021
zroot/usr/home@zfs-auto-snap_daily-2021-05-08-00h07 土 5月 8 0:07 2021
zroot/usr/home@zfs-auto-snap_daily-2021-05-09-00h07 日 5月 9 0:07 2021
zroot/usr/home@zfs-auto-snap_weekly-2021-05-09-00h14 日 5月 9 0:14 2021
zroot/usr/home@zfs-auto-snap_hourly-2021-05-09-14h00 日 5月 9 14:00 2021
zroot/usr/home@zfs-auto-snap_hourly-2021-05-09-15h00 日 5月 9 15:00 2021
zroot/usr/home@zfs-auto-snap_hourly-2021-05-09-16h00 日 5月 9 16:00 2021
zroot/usr/home@zfs-auto-snap_hourly-2021-05-09-17h00 日 5月 9 17:00 2021
zroot/usr/home@zfs-auto-snap_hourly-2021-05-09-18h00 日 5月 9 18:00 2021
zroot/usr/home@zfs-auto-snap_hourly-2021-05-09-19h00 日 5月 9 19:00 2021
zroot/usr/home@zfs-auto-snap_hourly-2021-05-09-20h00 日 5月 9 20:00 2021
zroot/usr/home@zfs-auto-snap_hourly-2021-05-09-21h00 日 5月 9 21:00 2021
zroot/usr/home@zfs-auto-snap_hourly-2021-05-09-22h00 日 5月 9 22:00 2021
zroot/usr/home@zfs-auto-snap_hourly-2021-05-09-23h00 日 5月 9 23:00 2021
zroot/usr/home@zfs-auto-snap_hourly-2021-05-10-00h00 月 5月 10 0:00 2021
で、早速作業を始める前の時間のsnapshotを適用
# zfs rollback -r zroot/usr/home@zfs-auto-snap_hourly-2021-05-10-09h00
数分で終了したので、Windowsのexplorerで確認すると、在りました！
あー、良かった。 二時間ほどの作業は無駄になりましたが、無くならなくてよかった。何の気なしに、cron に設定しておいたsnapshotに救われました。
ZFS様様です。 今度HDDからSSDに替えてスピード上げてやろう！
WSJTXは自分のHomeDirectoryのAppDataの下にwsjtxのプログラムディレクトリにALL.TXTという名前で、起動している間の全ての受信データ（左側の窓の内容）が保存されています（
時々、消してやらないと、とんでもなく大きく成長する）。
抽出ソフトは、正規表現の復習にと、perlを使ってみました。 もう20年ほど弄ってないので、苦労しましたが、脳の活性化には良い勉強です。 正規表現が少々甘いこともありますが、全員がプロトコルに従った内容だけを更新しているわけでは無いので、かなりのゴミを含み、RDBに入れてから、ゴミ掃除が必要です。 2019年11月から、主に30/40/80mのデータが64,059,176件（取り切っていないゴミも含めて）入っています。 RDBでないと処理は無理ですね。
これで、自分が欲しい局が、過去に出ていた時間（自分のリグで受信していたにも拘らず更新できなかった、或いは呼んでも答えて貰えなかった）を把握することが出来るようになりました。
ここまで来ると、「SN、黒点数と信号強度の関係は？」とか興味が湧いてきます。 で、SNのデータを探してみるとSILSO に1818年からのデータがありました。 月一度のupdateのようで、今の時点で4月30日までのデータが入手できましたので、これも抽出ツールをperlで組んでRDBに入れてみました（csvファイルと記載がありますが、コンマ区切りではなくセミコロン区切りでした）。
wsjtxlogとsunspotnrの二つのテーブルを結合すれば、その日の特定の局の信号強度と黒点数が表示されるようになり、コンディションの推測など今後の利用が期待できるかもしれません。 （二つのテーブルは粒度が違う、wsjtxlogは分単位、SILSOのデータは日単位、ので少々SQLを細工する必要があり、viewを作ったうえで結合させています）
今のところ、Unixにアクセスしてsql書いて必要なデータを取得しているだけですが、抽出の切り口が絞られてくれば、WEB上でグラフ化することもこれからの課題です。
下は、SQLによるデータ表示例（9G5FIの30mバンドの状況一部）；
countは一時間に何回受信したかの数量（多い方が安定していた？）
max/min/avgは信号強度dBのその時間内の最大・最小・平均の値
SNと信号強度には関連はなさそう、、、。
SNが高いと聞こえている時間が長い？
