2021年6月27日日曜日

CW Keyer JG1CCL内田さん版(2) 筐体に入れる

 内田さんからの依頼は、試作と動作確認だったのですが、バラックのままでは、ジャンクボックスの肥しにしかならないので、筐体を作って収めてやろうと考えたら、元々が、CW decoder/keyerの為にデザインされた基板なので、単体のKeyerとして筐体に入れようとすると、micorUSBコネクタの位置がちょっと塩梅悪い(これだけケースの横から出ることになる)ので、FT234xでは塩梅が悪く、MCP2221Aと秋月の「USBmicroBコネクターパネル取付キット」の組み合わせに変更することにしました(基板はFT234XかCH340互換のMCP2221Aのどちらか一つを選択できるようになっている)。

あ、チョンボ! FT234xでないと、USB接続したソフトがWinKeyとして認識してくれないので、この選択はありませんね(MCP2221Aに置き換えて認識して貰えなかったので、気が付きましたーおバカさんでした)。

ただ、FT234xが基板直付けでmicroUSB Bコネクタが横から出ているので、秋月のmicroUSB Bコネクタのパネル取り付けキットを加工して、FT234xモジュールをパネルの方に取り付けて、ジャンパー線で基板と繋ぐようにしました。


 1)FT234xをパネルに取り付けるように改造

秋月のmicorUSB Bパネル取り付けキットの基板から表面実装のmicorUSB Bコネクタを外す(左ー>右)



コネクタを外した基板を裏返して(表面実装用の配線面が見えない側に)FT234xモジュールを取り付ける。FT234xモジュールにジャンパーピンを立て、コネクタを外した基板の後部のジャンパーピン用穴(6p)の真ん中4pに半田付け。ジャンパーピンとコネクタの位置関係が同じなので、同じ位置になります。

その後、パネル取り付け用のL金具を半田付けして出来上がり。 

FT234xモジュールのパネル取り付けキットを作ってくれると、こんな事しなくて済むんですけどね~。


2)で、筐体は? いろいろ探しても適当なものが見つからず、結局はアクリル板で自作することに、、、。

 基板の大きさをベースに2tのアクリル板で筐体を作ってみました。105x75x50とちょっと大きめになってしまいましたが、基板を流用しているのでしかたないですね。 アクリル樹脂接着剤を最初は付属のスポイトで接着部に付けていましたが、これはダメですね。 ボチャッと大量に接着剤が流れて、周りが汚れてしまいます。 胡麻化すのに、クリアのアクリル板を紙やすりで削って、スモーク調にしました。

 小型のインジェクタでやってみたら、注射の時と同じで中の空気を押し出してやると、少量が注入量を細かく制御でき、接着部分に毛細管現象でうまく広がり綺麗に接着出来ました。

 ジャンパーピンとジャンパーケーブルの大きさが結構寸法に影響を与えますね。 特にジャンパー線の折り曲げで最低1mmの余裕が必要でした。基板と背面の距離がちょっと足りなくて、4台制御できる仕様は、3台に変更。

後は、シールドは全くなく、結構ジャンパー線が内部で引き回されているので、電磁波バンバンの環境では誤動作するかも、、、。

 特に使う予定は無いのですが、バラックだとジャンクボックスの滓になってしまうので、一応格好をつけましたが、ラベルの印字などの予定は無し。 シャックのお飾り!!
 

 

2021年6月24日木曜日

朝からLogger32でローテータの制御が出来ない!

 「あれ、地図にアンテナの方向が出てこない?」と気が付いて、USBのコネクタを繋いだり、外したり。 でも、解決しない! 制御のためにJA5AUCのRTC-59を使っているのですが、USBのコネクタ(四角形っぽい方)の接触があまり良くなく、何度かトラブったことがあったので、そのあたりを中心に弄っても埒が明かず、Logger32でなくBGARTCを使って、なんどか接続の確認をしているうちにBGARTCでは繋がるようになってしまいました。 しかし、まだLogger32のRotorからは繋がらない! 何故だろう?

あちこち抜いたり挿したり、3時間近く悪戦苦闘してしまいましたが、後味の悪い(結論の出ない)状態。

で、色々弄っているうちに気が付きました。 [Radio]の選択が外れていました。 Flex6500を設定しているので、これを選択[open]して解決。 

Logger32の窓の一番下に、設定内容が表示されており(青だと接続、赤だと非接続)、これを見れば一発で分かるのですが、一度設定すると、電源切っても、立ち上げると直前の状態で立ち上がるので、 つい忘れてしまいます。 お騒がせでした。





 


2021年6月22日火曜日

CW Keyer - JG1CCL内田さん版

横浜みどりクラブのJG1CCL内田さんが、雑誌原稿用にチェコのCW Decoder, CW Keyerを参考に国産版を作成されていて、 WinKeyer2との互換性の確認のために、私のところでCW Keyerを試作してみました。 

Arduino Nano Everyを使ったCW Keyerを指示通りにFT243xでUSBポートとの接続を行い、普段使用しているWinKeyer2の替わりにLogger32に接続して同等の動作をするのか検証してみました。

結論から言えば、Did/Dahのweight調節など、全て問題なく同等に動作することが確認でいました。 当然?

ArduinoIDEはいつもESP8266の書き込みに使用しているので、ArduinoNanoEveryでの使用の為の設定など、ちょっと不安がありましたが、特に問題なく書き込みが出来ました。 使用したsketchは、K3NGのものでweb上にも、色々書き込みがありますが、「おーっ、デカい」。 ちょっと全部を読むのは断念。 なんかあれば、適宜つまみ食いすることに、、、。 内田さん、ご苦労様です。

Logger32のCW Keyのモジュールはcom port番号が一桁しか拾ってきてくれないので、Windows10のデバイスマネージャー、ポート、、、、で空いている一桁のポート番号を強制的に割り当ててやる必要がありました。


 


 

2021年5月30日日曜日

FreeBSDサーバーのHDDが壊れている!

FreeBSDのZFS(raidz1)に使用している3TBのHDDが壊れていて、ファイルシステムがdegradedを出していたので、今回はSSDに交換することにしました。 交換対象のHDDより小さいSSDを使ったらどうなる?って言うより3TBは無くて4TBになり、少々高価なので、試に2TBを入れてみましたが、案の定 too small ....と受け付けてくれません。 (当たり前か、、、)

やむを得ず4TBのSSDを購入して、インストール。 (4TBのHDDって選択もあったのですけど、何故かSSD買ってしまったので、とんだ散財)

ZFSでのHDDの交換については、以前ここに記載したのでそれをそのまま踏襲。 「実に簡単」 resilveringに小一時間掛かって無事終了。 と言っても、故障中も、交換中もサーバーは通常通り動いているので、ユーザーには何の影響もありません。

何か月か前に、誤って消したファイルの復活にもZFSが役立ったし、ほんとにファイルシステムの信頼性が高くて、安心して使用できます。 Sun Microsystems 様に感謝感謝。




2021年5月10日月曜日

ZFS に救われた! FreeBSD data server

 久しぶりに写真の整理をしていて、DataServer(FreeBSD)に放り込んでいた写真を、撮影した年代日付毎のフォルダに入れてゆく作業をしていました。 

Windows10からFreeBSDの共有フォルダが見えるようにしてある(Samba3)ので、操作はWindows上のexplorerから行っていました。 で、2020,2019,2018と降りて行った際に、間違って整理し終えた2018年のフォルダをうっかり消してしまって、真っ青! これは、ゴミ箱からの復帰は有り得ませんし、クラウドにもこのファイルは上げていないし、、、。 

あ、ひょっとして、ZFSファイルなので、定期的にsnapshotを取っていたのではなかっただろうか? と、サーバーにアクセスして;

Crontabの内容(一部)
zfs list -r -t snapshot -o name,creation zroot/home (Windowsとの共有は/usr/homeの下にあるので)としたらやったね! 在りました。 月単位、週単位、日単位、時間単位の4段階でsnapshotを自動作成していました。 cronに設定したら、後は自動なので忘れちゃうのが問題かな?

# 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に替えてスピード上げてやろう! 


 

2021年5月8日土曜日

WSJTXのログの利用

WSJTXは自分のHomeDirectoryのAppDataの下にwsjtxのプログラムディレクトリにALL.TXTという名前で、起動している間の全ての受信データ(左側の窓の内容)が保存されています(
時々、消してやらないと、とんでもなく大きく成長する)。 

これを利用すれば、過去に見落としていた珍局の出現時間とかが調べられるのではないか?と思い立ち、ALL.TXTから必要なデータを抽出してRDB(postgresql)に保存することにしました。 

抽出ソフトは、正規表現の復習にと、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が高いと聞こえている時間が長い?





2021年3月27日土曜日

バタフライバリコンの制作

銅パイプを使ったバリコンを制作してきましたが、間に噛ます誘電体の信頼性から、PTFE位しかなく、大きさが小さくならない、重量もそれなり、可動部が片側の端子となる(駆動距離分の配線処理)等から、4~5KV程度の耐圧の150pF位が自作の限界で、制作コストも安くなく、ジャンクの真空バリコンと同等にしかならないようで、限界を感じました。 

コンデンサを直列にすれば、耐圧を稼げますので、バタフライバリコンなら10KVは可能ではないかと、思い付き、最初は昔のミツミのポリバリコンのアイデアで、ローターとステーターの間に2mm厚のPTFEを挟み、PTFEのすべり摩擦を利用して、高容量、高耐圧のバリコンが出来ないか、ちょっと試してみました。

 これは、PTFEのすべり摩擦が、期待したほどではなく、複数枚のローターの位置を一定にすることが難しく(軸を四角形等にすればかのかもしれませんが、使用したM5の寸切りネジでは)、断念。  

MLA48へのアルミの切削加工場所の質問に、W6SI浅見さんから、「Etsyでステンレスの物を売っているよ」という情報を頂き、また、JF1IQQ下地さんから「トルコの局で、アルミの物も売っている」ということで、早速注文。 

10set(ローター10枚、ステーター20枚)18.7$で、国内外注よりは安かったのですが、輸送費がTNTで2千円余、と大量に購入しないと割高か? (先ほど見たら10% offになっていました)。

このTA1LSXの物はレーザーカッターで切り出しているとの事ですが、国内で同様の物を外注すると、真空コンデンサが何個も買えてしまいます。

いずれにせよ、TA1LSXの物が2週間ほどで到着したので、早速、M5の寸切りボルトと廣杉計器(下地さんからの情報)で入手した5/6mmのM5用アルミスペーサーで試作してみました。

6mmのスペーサーで、11setで7.8pF~50pF。 

5mmのスペーサー、12setで10pF~68pFという結果だったので、「22~3setで100pFいけるかな?」と足りない分は、公開されているTA1LSXの図面から自分でドリル/糸鋸/鑢で切り出して追加して制作してみました。

結果、6mmのスペーサーと22setで16.5pF~106pFという事になりました。 見た感じではローターとステーターのスペースは2.3~2.6mmは確保できているようなので、耐圧は10KV超はあると思われますが、後日JR1OAO氏の試験環境で確認してみようと思います。

当初、0.5mmのアルミとPTFEと5mmのスペーサーを計画して、材料が余ったので、0.5mmのアルミでTA1LSXのローターとステーターをドリル/糸鋸/鑢で切り出して、0.5mm,5mmスペーサーでも試作してみました。 

0.5mm厚のアルミはローターのシャフトとの直交を維持するのが難しく(簡単に曲がる)、耐圧的にちょっと不安がありますが、18setで10.6pF~96pFが試作出来ました。 後日合わせて耐圧試験をしてみることにします。

昔使っていた大型のバリコン
大昔使っていた杉原商会で購入した450pF x 2(9KV?)のバリコンではありませんが、ローターの重み?で位置が一定しないので、直接ノブを付けて手動は拙そうなので、ギア噛ましてステッピングモーターで駆動することを考え、今後は駆動部分の細工を検討。

エアバリコンのローター、ステーターは規格さえ決め量がまとまれば、多分アルミの打ち抜きで安価にできるのではないでしょうかね? 

因みに、ローター、ステーターを全てTA1LSXから調達して、必要な分のスペーサー、ナットのコストを足して、全体のコストを計算すると、10,207円となり、ローター、ステーターと送料で61%を占めていることが分かり、ローター、ステーターと送料のコストを何とか抑える必要が明確です。(送料が何とも無駄!)








30-40-80m Dipoleがオカシイ(続)

RI1FJLの40mでの交信のときおかしくて、エレメントの修正をして問題なく終わったと思っていたら、ここ2週間の雨天で、またチューンイングが取れなくなってしまった。 何故か30mがオカシイ! よくよく考えてみると、7Mhz用のトラップを軽量化の為に銅線からアルミ線に変更した 注)...