先日、CAT支援システムを通して和文電信でラグチューをしていたのですが、その際、お相手頂いていたJF0RRHさんにYoutubeにそのときの動画をアップして頂きました。
 ところがその動画を見て愕然! 自分が送信しているはずの符号に聞こえていないところがあるのです。具体的には、「イ」が「ム」になっていたり、「”(濁点)」が「ヘ」になっていたりするのです。つまり、先頭の短点が消える場面があるんですね。
 これじゃあ暗記受信は無理ですよねぇ。ただ、自分でモニターしている限りそのような符号は出していないはず。ってことは、なんか電気系のどこかで鈍ったところがある?
 ということで、まずは回路を見直し、そののち、ソフト系を見直そうということにしたわけです。
 で、回路ですが、こういうのはメーカーのリグがどうなっているのかってところから見直す必要がありますので、これを調べてみました。
 調べ方ですが、ヨーロッパで各種リグの資料を配布しているサイトがありますので、そこからサービスマニュアルをダウンロードして、キー入力部の回路図を抽出してやろうっていうようにしました。
 なお、回路図の上ではパスコンがパラレルについているところなど、「電気的に意味あるか?」ってところがありますが、そういうところでは基板を跨いでつながっていたりするので、そういう部分では点線で信号線が基板を跨いでいることが分かるように表記してあります。
 結局キー入力回路って、
(1) 高周波の回り込みをできるだけ遮断すること、
(2) 高周波の回り込み対策のためにパラレルにいれるべきコンデンサの放電をどの程度まで速められるのか?
 という相反する目的をどういうバランスで達成するかに尽きると思うのですが、調べた回路では、それぞれメーカのエンジニアの思想がまる分かりするので、面白いところであります。

=======
A社のリグ
=======

では、まずA社のV/U機から。

 このリグでは、電鍵端子直後にはパラレルに高周波用のパスコンが入っていません。代わりにフェライトビーズ(以下、「FB」と書きます。)が入れられているようです。また、この信号線は、47kΩでプルアップされている一方、放電時(つまり、キーダウン時)には、1kΩを通して、CPU側に付けられた100pFのパスコンからの放電を行うようになっていました。まぁ、100pFとはいえ、このリグが扱う最低周波数(144MHz)でのリアクタンスは、11Ω。1kΩがシリーズに入るんで、回り込み対策にはなっているんですかね。FBを初段に配置しているのは、この会社のものだけですね。(後述するB社のものにもFBは挿入されていますが、初段ではないです。)

・-・-・・

 次に同じA社のHFの普及機です。

 このリグでは、FBを介しているものの、パスコンは0.01μFと結構大きめのものがはいっています。送信できる最低周波数は1.8MHzなので、このリアクタンスは、8Ω。お?V/U機とコンパラオーダ。このあたりに落ち着くようにする設計指針なんでしょうか。
 ただ・・・あれれ?電鍵グランドに0Ω。なんかあったときに、ここで電流制限しようっていう魂胆だったのかもしれません。設計者が悩んだところだったんじゃないかと思ったり、思わなかったり。^^;

・-・-・・

 次に同じA社のHFの高級機です。但し、フラグシップモデルではない方です。



 FBを多用していますね。あと、パスコンは0.01μFと普及機と同じ大きさのものが使われています。瞬間電流を抑えようということだと思うのですが、コイルがシリーズに入っていて、電流制限をしているようです。流石上級機ですね。結構コダワリを感じます。でも・・・えーっと、もしかして、キーイングエッジで、ヒゲのような160kHzの信号が数波出ちゃうかな? ^^;

=======
B社のリグ
=======


 次はB社(中級)HF機です。


 こちらは電鍵にパラレルにパスコンを挿入するタイプ。ですから、コンデンサに充電された電荷は電鍵押下時に一気に流れ出すタイプです。FBも入っていません。ただ、そのパスコンは、0.001μF。言い換えれば1000pFです。ん~、この値をどう評価するかなんですけど、とりあえず、HFですので、最低送信周波数は1.8MHz。そのときのリアクタンスは、88Ω。まぁ、そのあとに半導体内に流れ込むためには、10kΩを介するので、それに比べれば極小ということになるのかもしれません。加えて、CPU入力前になんか、シュミットトリガで一旦受けるようになっています。これでごみ処理をしようという考え方なんでしょうね。あと電鍵接続端直後のパスコンも.01μFにしたかったけど、いきなり電鍵でショートさせるのには気が引ける・・・だから0.001μFっていう感じにしたのかなぁと思ったり、思わなかったり。^^;

・-・-・・
 では、同じ会社のフラグシップモデルではどうか?


 これは普及機とは全然違いますねぇ。いやぁ、きめ細かい配慮がされた回路ですよね。基板を跨いでキーの信号線が配線されるからというのもあるとは思いますが、シュミットトリガで一旦受けることはするものの、LPFが一段追加されたような感じになっています。そして電鍵に近い方のLPFは0.01μFとちょっと大きめのコンデンサではあるものの、このパスコンを巡って、電鍵でショートさせるときには100Ωの抵抗を噛んでいて、電鍵を保護しようという配慮が見られます。立ち上がりを速めるべくプルアップ抵抗は2.2kΩと比較的低抵抗が入れられています。結構短い時定数となっていますね。

・-・-・・

最後にB社の廉価版モデルを見てみます。

 ん~、極めてシンプルですよね。やはり廉価版ということで部品点数を抑えているのでしょう。フラグシップモデルとは異なり、コンデンサは1000pF、CPUに入力するところで1kΩの抵抗をシリーズに噛ましているだけで、シュミットトリガも噛ませていません。この回路図にだけCPU名を記しておきましたが、これはあとでCPUのマニュアルを引きやすくするためです。で、このCPUはルネサスのCPUで、ハードウエアマニュアルを見ると、プログラムによってCPU内部にプルアップ抵抗を接続することができるようになっています。当然ですが、この機能を使っているものと思われます。一番シンプルではあるのですが、電鍵を接続するなら短めの配線で、多少長く引き回すならシールド線を使った配線で、若しくはパッチンコアなどを多用するなどして、配線ホット側に余計な回り込みが起きないように注意した方がよいかもしれません。

=======
C社のリグ
=======

次はC社のリグです。C社は最近HFのリグの発表が少ないので、ちょっと古いリグのものも含めてみてみます。

まずは、UHFのモービル機です。モービル機といっても、精力的なリグで、オールモード対応になっています。

 上の回路図には表していませんが、このCW用電鍵は差込口に妙な工夫がされていて、受け側ジャックはステレオタイプのものが使われています。そして、グランドに近い側のホット端子とグランドとがショートすることによって電鍵が接続されたものと認識するようになっています。ですから、電鍵を接続するためのプラグは、ステレオプラグではなく、モノラルのプラグを使う必要があります。どうしてもステレオプラグを使うなら、グランドに近い側のホット端子とグランドとをショートさせてやる必要があります。
 バリバリのアナログ回路ですよね。初段に抵抗内蔵型のトランジスタを使ってるので・・・深追いは止めときます。^^;

・-・-・・

次もC社の製品で、概ね42年程前のオールソリッドステートのコンパクトHF機です。


 こちらもアナログ機ですが、割と可愛い回路です。でも、電鍵に直接パスコンを入れるわけではなく、220Ωの抵抗をシリーズに介した回路になっています。ただ、入力の能動部品はトランジスタなので、ほぼ時定数がそのまま遅れ時間になるデジタル系とは異なり、プルアップ抵抗の一端がトランジスタがONとなる閾値のベース電圧より下がると送信状態になりますよね。まぁ、でもそんな感じでした。

・-・-・・

最後もC社のリグで、分類的には高級機ですが、フラグシップモデルではない方です。



これにはちょっと驚きですが、電鍵入力回路を巡って、ホット側・グランド側の双方にコイルが実装されています。信号線には都合3つのコンデンサが使われていて、基板間・外部入力部ともに高周波を落とそうという心意気を感じました。


==========
言いたかったこと
==========


 ここまで9つのリグの電鍵入力回路を見てきましたが、とにかく言えるのは、各社ともこの端子には電鍵が直につながることを想定していることです。たとえば、あるリグでは47kΩでプルアップしているのに対し、別のリグでは2.2kΩでプルアップしていたりします。その差、20倍。このため、この端子に自作のエレキーなどを接続するときに、安易にデカい値のパスコンを入れちゃうと痛い目を見るよ! ということなのでした。
 でも、これって常識でしたかね? 自分はノリだけで、部品箱のなかから手に当たったコンデンサをパスコンとして取り付けるということをやってたもんですから。^^;

(注)各回路図はサービスマニュアルから手と目を使って読み取ったものですので、誤りがあるかもしれません。というか誤りがあると思います。あまり記事の細部を信じないようにお願いします。これらの回路図を使って生じた不都合について、私は責任は負いません。
本記事の回路図について、別バージョンのものを掲載してました。改めて掲載しなおしました。(2026/3/22)

 病人の看病という家庭の事情で(!?)、ブログ・無線活動に低アクティビティな日々が続きましたが、ここにきてやっと時間がとれるようになってきました。なわけで、ここいらでまた趣味の製作活動を復活させようかと思っております。

 でもって、復活第一弾は、DitDahChat用インターフェース(730Hzサイドトーン付)の製作としました。
(いつも通りですが、この回路はPCに繋いで使うもののため、最悪の場合、PCを壊す可能性があります。これを製作して起きたどんな不具合・事故にも私は一切責任を負いませんので、予めご承知おきください。)

1.DitDahChatとは?
 今更説明する必要はないと思いますが、DitDahChat(以下、「DDC」と言います。)とは、ネット上で電信の交信ができるPCアプリケーションです。今ではCWの入門訓練場とかアパマンハムの拠り所とかになっていると思います。
 DDCについては設計者のJI1JDIさんが自ら「CQ Ham Radio」の2025年7月号、第90頁~第95頁に詳しくご説明になっていますので、そちらを参照されるとよろしいかと思います。

2.DDCにおける電鍵接続
 この記事の中でも「シリアルインターフェース」を介して電鍵を接続することができる旨の紹介があります。このシリアルインターフェースは、PCのUSBに接続するRS-232C変換ケーブルを用い、RS-232C側のCTSとDTRとを電鍵で短絡することで、PC上のアプリに電鍵押下を伝えようとするものです。

3.DDCの生のモニター機能を使ったときの問題点
 もっとも、ここでちょっと問題が残ります。というのは、キー押下をしてからPC上のアプリがサイドトーンを発するまで、数十mSの遅れが生じるのです。これは、私が以前に作ったF2Aジェネレータでも生じました。おそらくWindows OSが周辺機器の状態チェックに要する応答時間なのだと思います。
 この遅れ時間は、17WPM(凡そ85CPM)あたりの短点時間とコンパラオーダになってくるので、特にエレキーなどを使うと、まともに打てなくなってしまうのです。
 このため、エレキーを接続してDDCを運用されている局は皆さんPCのサイドトーンを使わずに、エレキーに備わっているサイドトーンモニターを用いられているようです。しかし、主として縦振れ電鍵や、(エレバグを使う場合等を除き)バグキーを用いられている局の場合には、このような手立てがなく、遅れ時間のあるサイドトーンを使わざるを得なくなっていました。

4.このインターフェースが目指すところ
 自分の場合、凡そ22WPM位までは縦振りキーを使います。このため、このインターフェースが必要となりました。
 このインターフェース回路を使えば、
(1) 電鍵押下の入力を、USBを経由してDDCアプリに伝えることができるとともに、
(2) 電鍵押下時のサイドトーンを発生させる、
 ことができるようになります。これを使えばサイドトーンは、PCのOSを介する前に発生させることができるため、時間遅れが殆どなく、快適にキー押下をモニターすることができるようになります。
 なお、USBを経由してDDCアプリに伝えるために、本インターフェース装置はキーボードを模して、電鍵ONのときに上矢印のキーコードをPCに伝達するようにしました。USBでいうHIDクラスです。つまり、本インターフェース装置をPCに接続すると、PCは新たなキーボードが繋がったと認識します。そして、電鍵が押下されるとキーボードから上矢印キーが押されたように振る舞うわけです。このため、PCには本インターフェース装置動作のための特別なデバイスドライバは不要なのです。

5.回路の説明
 回路は、以下の図の通りです。
回路図

(「回路図」の文字をクリックするとPDFがダウンロードできます。)

 この回路は極めて単純なもので、ただPIC16F1454と、そのPWM出力を3段のRCによるLPFを噛ませて低周波増幅部に接続しただけです。あと、結果として意味はなかったのですが、バスパワーとセルフパワーの自動切換をするようになっています。

・CPUについて
 PIC16F1454はPICの中では標準的な8ビットのCPUですが、なぜだかUSBのハードウエアインターフェースを搭載しています。今日時点で秋月では、一個290円で販売されている入手しやすいCPUです。

・LPF
 また、このCPUはPWM信号を発生させることができるため、これを低周波発振器として流用しています。勿論、PWM信号は方形波なので、そのまま低周波増幅すると堅い音になってしまいます。そこで、RCのLPFを3段噛ませまて、Duty Cycle50%の方形波がもつ3倍・5倍などの高調波を低減させ、比較的円やかな(!?)サイドトーン発生器にしてみました。

・低周波増幅部
 あと、低周波増幅部にはTA7368Pを用いました。このICは20年くらい前に部品箱ストック用にゲットしたものす。東芝では生産を終了したみたいなのですが、今でも秋月ではセカンドソース品が販売されていますので、作りやすいかと思います。
 低周波増幅用ICとしてはNJM2073などもありますが、2073は発振しやすいので、今回はそれを避けるために安定度の高いTA7368Pを用いました。

・バスパワー/セルフパワー切替
 バスパワー/セルフパワー切替には、P-ch MOSFETと、ショットキーバリアダイオードによるダイオードスイッチとで実現しています。まぁ、「実現」といってますけど、大した回路じゃなくて、原則としてバスパワーで動作しますが、外部電源を接続するとその電圧でバスパワーからの電流をMOSFETが遮断して、外部電源の方からの電流が支配するという方式をとりました。ただ、電圧によっては逆流する可能性もあるので、これをダイオードスイッチ(1S4)で、流れをぶった切ってやったわけです。
 実際に作ってみると(いや、計算上も・・^^;)、あまりセルフパワーにする必要はなかったのですが、USBケーブルを接続しなくても、電源が繋がっていたらサイドトーンをモニターできるようになるので、まぁ、あっても損はないかな?と思います。

(ちょっとだけ番外)
 ハッキリ言って、バスパワー/セルフパワー切替回路と、CPUのRC5端子に接続した10kΩの抵抗とは、無駄です。それでもこれらの回路を入れたのは、この回路を作っている最中に悩まされたひとつの問題に起因します。これは、再現性なくバリバリという音が入ることがあるというものです。
 当初は、TA7368の異常発振?とか、USBのバスパワー不安定?とかと考えて、これらの対策としてこれらの回路を実装してみたのですが、一向に良くなりませんでした。
 再現性がないので気は進まなかったのですが、腰を据えてオシロスコープを当ててその原因を探ろうとすると、ものすごいバリバリ音になり・・・え?まだオシロを当ててないのに?・・・でも、なんか雑音が妙に大きくなった・・・と思ったら、胸ポケットに入れていたスマホがこの回路基板に近づいたわけでして・・・。で、体を基板から離したら、バリバリ音は小さくなりました。え”え”ぇ”~!!
 DDCは電波を出さないので、あまり回り込みとかを気にしていませんでした。このためケースはプラスチックにしたのですが、それでも一応、各ICには0.1μFのパスコンを噛ませてありました。
 ただ、確かにスマホは30dBm程度の送信機なんですよね~。それまでスマホのことなど全然気にしていなかったので、そりゃ雑音発生に再現性が無いってことになるわけです。
 そうはいっても、こんなに頻繁にスマホは何を通信してんだか?? 気持ちワルいですね~。

6.ソフトウエアの説明
6.1. プログラムからデバイスへの書き込み手順
プログラムはこちらです。このプログラムをデバイスに書き込むのは以下のような手順で行います。

ここで重要なのはダウンロードした「DDC_IF_1454.X.zip」の中のファイルを全て生成した空プロジェクトのフォルダ内に入れ込むことです。USBを動作させるために必要なプログラムはMLA(Microchip Libraries for Applications)から取り出して全てこの中に入れてあります。MLAでは各プログラムは多くのフォルダの階層を参照しているのですが、これらを全てひとつのフォルダにあることを前提として変更してあります。
 正しく配置できたら、プロジェクトウインドウ上には以下のように表示されるようになるはずです。


6.2. プログラムの説明
 プログラムの殆どがMLAのものであって、そこに何が書いてあるのか、私も読み込んでいません。hi
 よって、ここでは、DDCインターフェースとして必要なところだけを説明することにします。
 Cのプログラムといえば、まずはmain()ですよね。はい、PICのプログラムのエントリポイントもここになります。

・main(void)::main.c
 main(void)では、最初にUSBその他の必要な初期化がされています。ここはMLAのままです。次に、PWM部を初期化します(main.c 41行目~53行目) initPWM())。ここは本インターフェース装置でのオリジナルです。このようにすると、PWM信号として約730Hzの方形波が生成されるようになります。CPUのクロックはUSBを動作させるために変更することができないため、このクロックをそのまま利用している関係上、サイドトーンの周波数もこれ以上下げることができません。これより上げることはできますので、そこは好みで変更できます。
 で、PWMをRC5ピンから出すかどうかを指定するのが、
 PWM1CONbits.PWM1OE
の部分。キーが押されたときに、ここを1にセットすればRC5からPWM信号が出力され
、0にセットすれば、RC5からの出力が停止します。
 次に、
// Assign RA5 to Key Input.
OPTION_REGbits.nWPUEN = 0;
WPUAbits.WPUA5 = 1;
という部分で、電鍵入力ピンのRA5をPIC内部でのプルアップを指定しています(main.c 59行目~61行目)。
 テスターで見る限り、RA5をグランドレベルに落とすと、概ね100μAの電流が流れる程度のプルアップになっていました。PIC16F1454の規格表を見ると、25μA~300μAで典型値は140μAといなっています。概ねこの典型値に近い電流が流れていますね。(英文マニュアルp.351参照)

 次に、永久ループが書かれています。(main.c 66行目~86行目)
 そしてこの中に、APP_KeyboardTasks()を呼び出すところがあります。ここで、電鍵操作を処理するようにしています。

・APP_KeyboardTasks()::app_device_keyboard.c
 このメソッド(APP_KeyboardTasks())は app_device_keyboard.cのファイル中にあります(app_device_keyboard.c 312行目~471行目)。
 このメソッドは頻繁に永久ループ中から呼び出されますので、ここに電鍵操作関係の処理を入れればよいわけです。
 でもって、まずは、電鍵の押下状態を検出して、移動平均をとっています(app_device_keyboard.c 317行目~330行目)。移動平均をとるのはチャッタリング防止のためのLPFとして機能させるためです。そのためのカウンタが、filterCounter。そしてこのfilterCounterの値が上側閾値を超えたら電鍵が押されたこととして、filterStateに1をセット、下側閾値より落ちたら電鍵が離されたこととして、filterStateに0をセットしています。で、この値を見て、電鍵がONならPWM信号を出力し、OFFならPWM信号の出力を停止します(app_device_keyboard.c 332行目~343行目)。
 次に必要な処理は、電鍵がONのときに本インターフェースから連続的に上矢印のキーコードが出るようにすることです。
 これは、396行目~420行目に書かれています。上矢印のキーコードを出すには、
 inputReport.keys[0] = 0x52; (404行目)
としておけば、MLAの基本プログラムが処理してくれるようになっています。

 簡単ですが、こんなもんで動作するようになるんですね。

あ、写真とかも貼っておきます。

赤で囲ってあるところが、バスパワー/セルフパワーの切替部です。

外形はこんな感じです。中央の大きい筐体の方です。

実際にシャック内ではこんな感じで収まっています。

動作状況はこんな感じ(Xのエントリ)です。


大変ご無沙汰しております。JI1BXMです。

 身内の介護などで、バタバタしており、なかなか SD-CARD Handler for YAESU SYSTEM FUSION の方のVersionUpもできずにおりました。
 間もなく始まる Let's Enjoy C4FMコンテストでは、画像伝送だけでなく、メッセージ送受信についても得点が高くなるようですね。そんなときに、SD-CARD Handler for YAESU SYSTEM FUSION は便利なので、使っていただける方も居られるんじゃないかなと思っております。
 とはいえ、今迄の最新版は、ImageMagickの仕様変更などでちょっとした処置をしなければならなかったので、これを機会に、すべての補助プログラムの最新Versionに対応するようにいたしました。

 具体的には、
(1) openJDK -> 25.0.1 に対応
(2)ImageMagick -> 7.1.2-11 に対応
(3) フレームワークとして利用している Spring Boot -> 3.5.9 にVersionUp
という変更をしてあります。
 また、ImaqeMagickは従来 ZIPファイルで配布されていましたが、最新バージョンでは、7-ZIPと呼ばれるものに変更になりました。このため、マニュアルもそのように修正してあります。

 このプログラムでは、画像のほかに、Messageについても作成・閲覧ができるようになっていますので、Let's Enjoy C4FM Contestでも円滑な運用ができるんじゃないかなと思っております。

 ということで、プログラムとマニュアルのダウンロードは以下のとおりにすることができますので、参考にされてください。
 
 プログラム: https://drive.google.com/file/d/1Chlo3RHrT4lLJGPoxdvY8zzVesJavOvI/view?usp=sharing
 マニュアル:
https://drive.google.com/file/d/19Sg4w9xHwTOE-8TH_3X5c7p96Pw6ffNr/view?usp=sharing

 ほかに、BATファイルなどは、openJDKのバージョンにあわせて修正すればOKです。
 新年あけましておめでとうございます。本年もよろしくお願い致します。

(この記事にある処置は、最新版のSD-CARD Handler for YAESU SYSTEM FUSION(Version 20251219以降)、ImageMagick(Verrsion ImageMagick-7.1.2-11以降)、openJDK(25.0.1以降)をインストールしてある場合には、不要です。)

 さて、https://ameblo.jp/chacha-oyaji2/entry-12845031960.html にあるSD-CARD Handler for YAESU SYSTEM FUSIONですが、このプログラムではImageMagickを使用して画像の変換を行っています。
 ところが、最新版のImageMagick(ImageMagick-7.1.1-43-portable-Q16-x64)では動作しないという連絡を頂きました。
 「なぜ?」と思い早速私もダウンロードして確認したところ・・・・SD-CARD Handlerで使用するプログラムである convertが含まれていませんでした。

で、changing logを見ますと・・・。
- `convert` sub-command is deprecated [`d67039e`](https://github.com/ImageMagick/ImageMagick/commit/d67039ed4ba75286208afd263b751c631a8e26a3)
 と書かれていました。わぁ!

 まぁ、これでは動かないはずですねぇ・・・。困ったもんです。

 なので、正式には次のバージョンアップで対処しますが、それまでは、緊急避難的に以下の操作を行ってみてください。私の環境ではこれで不具合を回避できました。

(1) ImageMagickの全プログラムが含まれるディレクトリに移動する。
 具体的には、例えば、
 cd C:\Users\ユーザー名\Programs\ImageMagick-7.1.1-43-portable-Q16-x64\

(2) magick.exe を コピーして、プログラム名をconvert.exeにします。
 具体的には、
 1) explorerで magick.exe にカーソルをあてて右クリック、更に「コピー(C)」を左クリック。
 2) explorerで空白部分で右クリック、更に「貼り付け(P)」を左クリック。すると、「magick - コピー.exe」が出来上がっているので、
 これを右クリック、「名称の変更(M)」を選択して、左クリック。
 3) これで名称が変えられるようになっていますので、この名称を「convert」に変更して、プログラム自体を「convert.exe」にする。

これで再度、SD-CARD HANDLERを動作させてみてください。

 では、また。

こちらのブログもかなり間があきてしまいましたね。ちゃんと生きてます。^^;

 さて、標記の件ですが、今月22日から来月26日にかけて行われる「Let’s Enjoy C4FMコンテスト」についてのお知らせがJK1MVF高田OMのHPに掲載されています。
 今回の「Let’s Enjoy C4FMコンテスト」は、C4FMでのQSOで得点できるのに加え、画像の交換を行うことで+2点が加点されるそうです。
 この「画像の交換」の意味ですが、相互に画像をやりとりするという意味だそうです。
 たとえば、A局とB局との間のQSOであれば、
(1) A局からB局への画像送信に加え、
(2) B局からA局への画像送信を行い、
両者をそれぞれの局で受信できて、初めて+2点ということになるということです。
 この趣旨は、C4FMでの画像通信を活性化させたいからということだそうです。このあたり、JK2PLQさんが主催者側に確認されたそうです。

SD CARD HANDLER FOR YAESU SYSTEM FUSIONについて

 現行のC4FM機で画像を送受信できるものは、FTMシリーズ、ハンディ機FTシリーズのD型機などがありますが、FTMシリーズであっても自分がPCで作った画像を直接リグに送り込めるのはFTM-500だけになっています。FTM-500登場前のリグでは、受けた画像を転送することはできますが、原則としてカメラ付きスピーカーマイクMH-85A11Uを使って撮像した画像を送信することができるのみとなっています。これが、YAESU社の画像通信のシナリオです。
 ただこのままでは、FTM-500登場前のリグを使ってLet’s Enjoy C4FMコンテストで高得点を狙うことは難しいのではないかと思われます。この点、当局開発の「SD CARD HANDLER FOR YAESU SYSTEM FUSION 」(https://ameblo.jp/chacha-oyaji2/entry-12845031960.html)を使えば、カメラ付きスピーカーマイク無しにPCで作った画像をSD-CARDを介してリグから送信できるようになります。コンテストに参加される方は、利用をご検討頂ければと思います。ダウンロードは、このページの下の方にリンクがあります。
 このソフトは未だにα-Versionですが、当局の環境では今のところ、半年ほど使っていてPCにダメージを与える事象は起きていません。もっとも、使用される際には、ダメージがあっても問題にならないPCを使うなど、自己責任でお願い致します。
※ なお、これらスナップショット機能を備えたリグでも、SD-CARDが挿入されていないと画像を記録しておくことはできません。更に、同じSD-CARDであっても、32GBまでのSDHCまでが対象で、SDXCやSDUC規格のSD-CARDは使えないようです。

コンテストでのシナリオ


 「画像を交換が主」であり、かつ「コンテスト」ということになると、画像交換が効率的に行えるようにする必要があるでしょう。
 ここで、自分は次のようなシナリオを採ろうかと思っています。

(1) 原則として、CQは画像で送信する。

 原則として、中にCQと書かれている画像を送信して、呼出を受けることにします。このために「CQ画像(!?)」を準備する必要があるかと思います。
 もちろん、受信側が画像伝送に対応していなければ意味がないので、画像でのCQの後に音声でのCQを出すなど、の必要があるかと思います。

(2) CQを出している局を呼び出すときは原則として音声で呼び出す。

 CQを出している局を呼び出すときは原則として音声で呼び出すことにします。これは、相手局が画像伝送に対応していない可能性があるからです。相手局が受信できることを確認してから画像を送信するということになると思います。

画像交換をしたときには、その画像をEXCELのログに記録するなどの必要があるようです。
このあたり、12月10日に公開されるそうなので、それを待ちたいと思います。

ー・・ーーー
 こんにちは。ご無沙汰しております。
 SD-CARD Handler for YAESU SYSTEM FUSION (α Ver.)のエントリでは結構頻繁にバージョンアップ情報を更新していたのですが、独立のエントリとしては久しぶりのアップになってしまいました。

・ー・ー・・

今月7日に公開しましたSD-CARD Handler for YAESU SYSTEM FUSION (α Ver.) Version 202406060818 版には
(1)画像の読み書き機能に加え、
(2)MESSAGEの読み書き機能、
(3)VOICEの読み出し機能
を実装しました。これでやっと「SD-CARD Handler for YAESU SYSTEM FUSION」と呼べるものになったと思います。このため、元の名称「SD-CARD Handler(仮) for YAESU SYSTEM FUSION (α Ver.)」から「(仮)」の文字を削除しました。hi
 また、プログラム自体も大幅に修正しましたので、それまでのプログラムとは構成も異なっています。
 この時点でやっと、全体的なプログラムの構造が定まったと思いますので、このエントリから暫くは「プログラム」について解説をしていきたいと思います。殆どが備忘録になるかと思いますが、SD-CARD Handlerを自分仕様に変更される方の参考になれば幸いです。
 なお、現在のVersionは202406060818-2としてありますが、これはMessageについても消去扱いのものを表示させるかさせないかという選択肢をつけたものとなっただけです。

・ー・ー・・

本プログラムは、Spring Boot3と呼ばれるフレームワークを使用しています。このためプログラムは多くのモジュールを抱きかかえることになるのですが、解説するのはフレームワーク以外のところだけにとどめます。
で、プログラムの構成は下図のようになっています。


続いて、ブラウザに表示するためのテンプレートの構成は下図のようになっています。


・ー・ー・・

 これ、Spring Boot3フレームワークの上に乗っかってるので、ただのクラスファイルの羅列に見えますよね~。main()を探しても、そこからどのように動いているのかが、皆目チンプンカンプンになってしまいます。
 フレームワークについて触れると長くなるので、ここではまずは要点だけを挙げます。

・ー・ー・・

 javaにしろCにしろ、プログラムのエントリポイントはあります。
 javaの場合、public void static main() がこれです。プログラム中にひとつしかないので、staticなんですよね。
 で、これは、net.dialectech.springCoreパッケージ中、のYsfSdCardHandlerApplication.javaファイル中にあります。このファイルには、public の YsfSdCardHandlerApplicationクラスがあって、この中にpublic static void main(String[] args)という行があり、ここがプログラムのエントリポイントになります。
 この中で、
SpringApplication.run(YsfSdCardHandlerApplication.class, args);
 という行があり、ここがSpring Bootの制御を始めさせるところになっています。
 そのあとは、ちょっとモジョモジョ~なところ(実はデバッグ用の設定があって、デバッグモードで動作させると、SD-CARD以外のところにエントリを設けることができるようにしてあります。そういう処理をするところが含まれています。)と、ブラウザをキックするところが記述されています。

 というわけで、フレームワークの入り口についてはこの程度にして、次に、プログラム本体についての概要に触れていきます。

・ー・ー・・

 Spring Bootの場合、クラスの頭に「@Controller」と書いてあるものを、フレームワークは拾ってくれます。つまり、WEBリクエストに直接応答するところにもこの記述がされていれば拾ってくれるわけです。具体的にどのように紐づけるのかは、フレームワークが勝手にやっていますので、プログラマはそこまで気にしなくてもよいようになっています。
 で、ブラウザからのリクエストについての応答についてですが、たとえば画像プレーンでいうと、パッケージnet.dialectech.ftmSdCardHandler.actions中のCHandlerImageActionクラスが担当しています。で、各メソッドの頭につけてある「@RequestMapping」というのが、ひとつひとつのリクエストに応答する処理関数(メソッド)となっています。
たとえば、SD-CARD中の完全削除を担当するメソッドはブラウザから「deleteImageCompletely」というリクエストを飛ばしますが、これはactDataDeleteImageCompletely(~)というメソッドが処理をするようになっています。
 自分の場合、リクエストに対する応答メソッドの名称は、すべてactData~というように統一していますので、こういう名称のものは全てブラウザからのリクエストに応答するものとなっています。
 あと特徴的なのは、net.dialectech.ftmSdCardHandler.supporters.fileSystemパッケージでしょう。ここにある2つのファイル中CYsfFileSystemクラスは、シングルトンにしてあって、SD-CARDの書き込み・読み出しを担当しています。その名の通り、File Systemのラッパーみたいな感じです。
 もうひとつの、CYsfFileSystemCorePartクラスはCYsfFileSystemクラスの基礎となっているクラスですが、これは、SD-CARDに限らず、バンクの処理もできるようになっています。言い換えれば、バンクもSD-CARDも同体系のファイルシステムとしてアクセスできるようにしてあって、SD-CARDのみを特別扱いしたという感じにしてあるんです。
 他には、同じパッケージ中にあるCYsfCodeConverterは例のヤエス特殊文字コード体系(!?)の変換を扱うクラスです。このクラスは共通にどの操作でも使うものですので、singleton扱いにしてあります。まぁ、staticでもよかったんですが、まぁSingletonの方が若干安心できるっちゅうか、なんちゅうか・・・。
 あとは、net.dialectech.ftmSdCardHandler.dataパッケージ中に各DIRの構造に対応する論理データ~binaryの変換なんかを含んでデータ構造を定義してあります。
・・・・とまぁ、こんな感じで大枠を作ってあります。
 こんなところでした。ちなみに、webブラウザで表示される側は、プロジェクトのsrc/main/resources/template/pages配下に収めてあります。このなかのbase.htmlが最初の画面(5つのプレーン)を全て定義してあるThymeleafファイルになっています。
 ザクっとこんな感じでした。^^;

次回からは、もうちょっと中身に踏み込むつもりです。


・ー・ー・・
「SD-CARD Handler for YAESU SYSTEM FUSION Ⓡ」のダウンロードリンクは、ブログエントリSD-CARD Handler for YAESU SYSTEM FUSION (α Ver.)の記事の中に固定してあります。現在、2024/6/6版を掲載しています。なおインストールにより、乃至プログラムを動作させたために生じた損害について、私は責を負いません。その他の注意事項は上記エントリに記載してあります。
「SD-CARD Handler for YAESU SYSTEM FUSION Ⓡ」のダウンロードリンクはこちらのエントリに固定しておきます。
・ 現在、2025/12/19版について掲載しています。

SD-CARD Handler(仮) for YAESU SYSTEM FUSIONⓇとは?
 「SD-CARD Handler(仮) for YAESU SYSTEM FUSIONⓇ」(以下、単に「本プログラム」といいます。)は、Windows PC上で動作し、FTM-300D,FT-5DなどのYAESU SYSTEM FUSIONで用いられるSD-CARDに対してPCから画像情報を記録して、リグからその画像を送信できるようにするプログラムです。

この図にあるように、YAESU SYSTEM FUSIONでは、SD-CARDを介してリグで送信する画像・受信した画像をPCで読み込むことができるようになっています。
しかし、最近対応が施されたFTM-500を除き、現時点では未だPCで任意に作成した画像をリグに読み込ませるような手段が提供されていません。
本プログラムは、PCで作った画像・PCに記録してある画像をSD-CARDに記録させます。これにより、PCで作成した画像をリグから送信できるようになります。

1.2. なぜ、本プログラムを作ることにしたのか?

1.2.1. 付随情報の記録の要請
YAESU SYSTEM FUSIONⓇを基礎とする八重洲無線さんの製品群は、SD-CARD中のPHOTOというフォルダ配下に画像情報を記録しています。
ところが、ここに記録される情報は画像「情報」だけで、「無線機で管理する」ための情報が含まれていません。
管理情報は、QSOLOGフォルダの下に記録されていて、画像情報ごとに多くの付随情報が含まれています。付随情報は、QSOPCTDIR.dat、QSOPCTFAT.dat、並びに管理情報を管理する(!?)QSOMNG.datファイルの3つに分かれて記録されています。たとえば、QSOPCTDIR.datには、ひとつひとつの画像について、
・その画像が撮られた位置情報、
・記録された日時、受信した日時、送信した日時、
・送信を成功したか、失敗したか、また、受信したのちにあらためてリグ上に表示したかどうか、
・PHOTOフォルダ中に記録されているファイル名、
・宛先呼出符号、
・自局呼出符号、
などが記録されています。また、QSOPCTFAT.dirには、その画像をリグが操作対象としうるのか、どうかに関する情報(具体的にはリグ上でリスト表示される対象なのか、消去
されたものなのかに関する情報)が記録されています。
よって、PCで作成した画像をリグで操作可能にするためには、単にPHOTOフォルダに記録するだけでは足らず、このような付随情報も併せて記録する必要があります。
本プログラムを用いれば、このような付随情報も含めて操作するので、PCで作った画像でも、容易に送信できるようになります。

1.2.2. ファイル管理の困難さと削除の不十分さの解消
YAESU SYSTEM FUSIONⓇを採るFTM-300・FT-5Dでは、記録してある画像情報を送信するたびに、新たな管理情報が生成されるようになっています。おそらく他のリグでも同様だと思われます。しかし、このような情報は画像検索時には不要だと感じます。このため、操作性を維持するために、送信後の情報を削除することも多いかと思います。
ところが、この「削除」処理が曲者で、QSOPCTFAT.dat内に削除のマークを付けるだけです。言い換えれば、QSOPCTDIR.dat内の個別情報もPHOTOフォルダ内のファイル自体も削除しないわけです。これでは削除を繰り返したとしても、ゴミがたまっていくだけになります。これがただ溜まるだけならよいのですが、リグ上で送信する画像を選択する操作において、削除したところでは、次の候補を表示する時間が長くなっていき、操作の快適さが低下してしまっています。

1.2.3. 機能を検討するうえで参酌すべき事項
 以上説明したように、本プログラムはリグに挿着するSD-CARDをリグから抜き出してPCに挿着し、これに対して操作をすることになります。

 これだけ見る限りでは結構単純なソフトでも機能するはずです。
 しかし、現実にこの機能を実装して運用してみると、他に様々な機能が必要だと感じるようになります。たとえば、
(1)話題によって異なる画像群を用意しておきたいが、そのためには、どういう操作の下でどういう機能が実現すればよいのか、
(2)MOUNT忘れ等の操作ミスなどに対してどうプログラムは応答すべきか?
などは設計思想にも影響することですし、実際に運用してみなければ分からないことです。
 また、リグによっては画像20個毎にブロック化されていて、送信する画像もこのブロックの中から選択できるようになっていたり(FT-5Dの場合)、このようなブロック化が全くさせておらず、全画像が平らな一階層に展開されていたり(FTM-300Dの場合)、します。
 このような異機種による取り扱いの違いによっても、操作感に影響しないような仕様にすることも勘案しなければならないでしょう。

 ってなわけで、とりあえず、アルファバージョンのものを公開しておきます。

注意事項
注意事項です。
(1) 本プログラムはPC内部のストレージに直接アクセスします。よってSD-CARD以外のドライブを指定するとそのドライブが破壊される可能性があります。A、B,Cドライブはアクセスできないようにしてありますが、他のドライブを接続しているPCでは十分に注意が必要です。

(2)あと、まだ検証はしていませんが、Spring Boot を用いているので、もしかしたら、ネットにつながっていないPCですと、XMLのタイプ宣言を読み込めずに動作しな
い可能性もあります。(この点、検証していません。)

(3)プログラムはjavaで、JAVAの処理系で最新のものを使います。また、ImageMagickというプログラムも使用します。

(4)プログラムはまだアルファバージョンです。何が起こっても不思議ではありません。 インストールしたために生じた損害について私は責任を負わないこととします。また、本プログラムを実行して何らかの損害が生じても、私は責任を負わないものとします。インストールしてPCに異常が起こっても問題にならないようなPCを利用することをお勧めします。
 なお、隠しコマンドとして、SD-CARD以外のドライブであっても、SD-CARDをシミュレートできるようにするプログラムが未だ入っています。設定等によっては、
PC上の既存のデータ等を失う恐れがありますので、この点十分、ご留意いただければと思います。

(5)これによって書き込んだSD-CARDを用いると、リグで画像送信後にリグの電源がSHUT-DOWNしたりしますが、これはカメラマイクを使っても起こる現象です。その点は気にしないことにしています。

(6) 今後、マニュアル・プログラムともに、変更していくことになるかと思います。

(7) 当局へのお問い合わせにはお答えしないことを原則と致します。GitHub上のソースコードを理解して頂いて、ご自分にあった仕様にして頂ければと思います。

 インストールの仕方などはマニュアルに書いておきました。
 正常に動作すると、プログラムを走らせるとブラウザが開きます。このブラウザを通してSD-CARDにアクセスします。


まぁ、そんなこんなであります。

ダウンロード
(1) マニュアルは、こちらです。 (2025/12/19版)
(2) JAVAのJARファイル(プログラム本体)は、こちらです。(2025/12/19版)

ダウンロードの際、「このファイルのウイルス スキャンを実行できません。
技術的な問題が発生しています。このまま「ysfSDCardHandler.jar」(29M)をダウンロードしてもよろしいですか?」と表示されるときには、「このままダウンロード」というボタンをクリックしてください。

なお、マニュアルの11頁に「本プログラムは java の version21 で実行することを前提としてコンパイルしてあります。」と書いてあります。え?25じゃないの?ってことなんですが、記載は間違いないです。つまり、java21の環境のままでも実行できるということです。無理に25にする必要はないということです。

ソースコードは、githubの、こちらにあります。

(20251219. ブラウザが立ち上がり、正しく設定をしたにも拘わらず、SD-CARDに画像を書き込めない場合には、Imagemagickのディレクトリで"magick"をCLIで実行してみてください。そこで、「VCOMP140.dllがないためプログラムが開始できません」というエラーが表示される場合には、MicrosoftのDownload Centerから、「Visual Studio 2015 の Visual C++ 再頒布可能パッケージ」をダウンロードして、これをインストールしてみてください。)

変更履歴

2025.12.19
(1) ImageMagickのVersion 7.1.2-11-portable-Q16-x64に対応させました。
 最新の記事に記載しましたが、現時点(2025/12/19)での、ImageMagick最新版、openJDK最新版に対応するとともに、フレームワークとして利用している Spring Boot3のバージョンを最新版3.5.9に置き換えました。
(2) なお、openJDKは25.0.2での動作に対応させましたが、java21以上でなら何でもOKです。

2025.01.11
(1) ImageMagickのVersion 7.1.1-43-portable-Q16-x64に対応させました。
 前述の通り、ImageMagickのVersion 7.1.1-43-portable-Q16-x64をインストールしても、本プログラムが動作しません。これは、従来版に含まれていたconvert.exeが廃止になり、magick.exeに統合されたからです。この部分について対応版を作成しました。これにともない、バージョン番号を202501110912にしました。

2024.06.23
(1) MESSAGEの疑似消去表示・非表示機能を追加しました
 202406060818版ではMESSAGEの「消去扱い」にしたものでも表示させていましたが、これを他のプレーンでの同機能と同じく、「消去扱い」にしたメッセージの表示・非表示を選択できるようにしました。これにともない、バージョン番号は202406060818-2にしました。

2024.06.07
(1) MESSAGE機能を追加しました。
 MESSAGE機能では、MESSAGEのSD-CARDからの読み込み、と新規メッセージの書き込みに対応しています。勿論、メッセージの見做し削除(表示上は「削除扱い」としてあります。)と完全削除機能は備えています。但し、メッセージは記録していることが意味あると思われるので、修正機能は実装しませんでした。
 なお、新規メッセージは、YAESU SYSTEM FUSIONでの拡張文字コードを利用しているために、IMAGEのDESCRIPTIONと同じく使用可能な文字に制限があります。詳細はマニュアルに記載してあります。
(2) VOICE機能を追加しました。
 VOICE機能では、RIGが録音した音声をPCで再生できます。勿論、見做し削除(表示上は「削除扱い」としてあります。)と完全削除機能は備えています。また、ファイル名の修正機能も備えました。ただし、ファイル名はWindowsシステムと共有するので、YSF拡張文字コードを使えません。よって、修正できる文字は、半角英数文字と、一定の特殊文字だけに限られます。
(3) IMAGE(PHOTO)が256個を超えたときに生じる不具合の対策をしました。
(4) QRコードが含まれる画像からそのQRコードを抽出できたとき、含まれるURL/EMAIL全てのリンクについてボタンを表示してJUMPできるようにしました。
(5) 上記(1)(2)については、マニュアルに追記してあります。

2024.05.17
 (1) 画像の付随情報(DIRエントリ)内の記述(DESCRIPTION)について、カタカナ表示をサポートしました。なお、入力可能な文字種について、操作時に参照可能となるようにHELPボタンを追加してあります。
 (2) QRコードの誤り訂正能力を「QRコード入力」ダイアログボックスで4段階で指定操作できるように操作部を追加しました。
 (3) マニュアルも修正してあります。

2024.05.15
 (1) QRコードを解析してメアド・URLを抽出するとともに、その内容から、ブラウザ・メーラをキックする機能を追加しました。
 (2) 画像の付随情報(DIRエントリ)内の記述(DESCRIPTION)を任意に変更する機能を追加しました。
 (3) マニュアルに追加機能に関する説明を追加しました。なお、前回と異なる部分については、目次に黄色のマーカを付けてあります。

2024.05.12
 (1) QRコード機能を追加しました。
 (2) マニュアルにQRコード機能に関する説明を追加しました。

2024.05.04
 挿入文字に引用符などの特殊文字が含まれる際に生じる不具合を回避しました。

2024.04.20
(1) ImageMagick動作に先立ち、存否確認を追加しました。これによって、設定ミスの発見を早めると思います。
(2) 一度に複数の画像をアップロードする際の総容量を、総計300MBまで拡張しました。なお、1画像については、50MBが制限値です。
(3) 標準最大容量の設定項目を「対象設定タブ」に追加しました。
(4) (3)に合わせて、マニュアルを修正しました。

2024.04.13
 GM動作時の画像交換に対応しました。
 年も押し迫ってきました。今日も朝から年賀状の文面・イラスト作成作業をしています。ただ、ブログの方もちゃんと書かないと・・・。

 ってなわけで、年末のブログネタとして、有用度からみる、今年完成した自作品ランキングとかを書いてみようかと思っております。ランク外のものも数多くありますが。。^^;

第8位 Wires-X用Portable Analog Node I/F
 HRI-200に接続する「なんちゃって無線機」。いや、ただマイクアンプとAFアンプだけを要素とするもので、これで直接Wires-Xに音声を流し、また、受けることができます。ただ、AnalogNodeとして機能するだけです。

 これは、後に作ったWires-X用エコーバックノードに全ての機能を実装したので、不要となりました。VUメータ付きだったので、結構見た感じが楽しめました。^^;

第7位 マイクとリグ間に挿入するUP/DOWNパルスジェネレータ
 TW-4000の修理をする前でもマイクのUP/DOWNボタンは完動だったので、ロータリーエンコーダの操作によってUP/DOWNパルスを生成する装置を作りました。修理までの緊急避難用のグッズです。

 TW-4000の修理が終わったらやはり不要となり、今となっては邪魔でしかないという・・・。^O^)""
 ただ、このとき作ったロータリーエンコーダのハンドラ・ライブラリは今年作ったFMラジオに活かされてます。^^;

第6位 タッチセンサー型スクイズキー
 パドルではなくタッチセンサーにするとコンパクトになって良いかな?と思って作ったものですが・・・。やはり操作パッドは本体にビルトインすべきだったかもしれません。加えて、自分のキータッチの癖もあって、まぁ使いにくいのなんのって・・。^^;

 このときCapacitive Sensing Moduleのハンドラ・ライブラリを作ったので、これは将来利用できる財産になったかも!?

第5位 Wires-X用エコーバックサーバ
 Wires-X回線から受けた音声信号を10秒を限度に記録してこれをそのまま返すサーバです。D-STARでのJK1ZRW Zのような感じですね。付加機能として、直接マイクからWires-Xに送出できるようにもしました。

 ただ、誰にも気づかれないので、使用率は限りなく0。いまのところ、Wires-X上のノードのモニター留まりになっています。^^; 結構真面目に作った割には有用度は低かったですね。

第4位 HFリグ用CAT支援システム
 この便利さに慣れると、これなしではFTDX10を使う気になれません。FTDX101程の使い勝手になるわけではないのですが、かなり使い勝手は良くなりました。


同率第2位 マイク分配器
 電源の選択によっては「思わぬグランドループでオーディオ系にハムが乗る」というトラブルを想定して、完全グランド分離を目指して作成した、マイク分配器です。やはり運用しているうちに、設定によっては、不思議なグランドループができていて、送信音にハムが乗ることを観測しました。完全グランド分離に原始的なリレーでガチャガチャ切り替える構成にし、また、複数の電源数からひとつを選択できるようにしたわけですが、これが奏功したのでした。

 これでシャックがかなりスッキリして、使いやすくなりました。


同率第2位 USBアイソレータ

 マイク分配器とともに同率2位なのは、USBアイソレータですね。これを使うことで、FT8のときでもPCのノイズをあまり気にしなくてもよくなりました。

第1位 リモコン制御FMラジオ
 リモコンで選局・音量調整ができるFM専用ラジオです。使用チップはKT-0913なのでAM受信も可能ですが、WIDE-FMもあることからAMは除外して、FM専用として、簡素化しました。
 アマチュア無線とは無関係ですが、生活必需品となってしまったので、これを有用度1位としました。^O^)""


そんなわけでした。
では、皆さん、良いお年を~。^-^)ノ"
 タッチ・キーヤーの前にもうひとつネタを書いておきます。

 1983年に購入した、TW-4000。もう40年も経つんですねぇ。

 自分はもう自家用車を持っていないせいか、最近では使用頻度が下がっているものの、このデザインは飾るだけでも価値がある逸品なんですよね。


 なのですが、昨年通電してみたところ、表示が滅茶苦茶。この不具合はバックアップバッテリが上がったためだろうからということでRESETで解消。
 ところが、メインダイヤルを回しても、UPの際に周波数が上がったり、上がらなかったり。どうやら通電直後は正常動作するものの、5分もしないうちに、この現象が出てくるようになりました。しばらく放置していたものの、やはり気になるわけです。
 そんなわけで、この現象はおそらくロータリー・エンコーダの接触不良。ってなわけで、エンコーダを分解して、接点をゴシゴシと洗浄。これで不具合は若干だけ解消したものの、まだまだ生じる状況。(ロジアナとかがあればそれでチェックするのだけれど、)仕方ないので、次には容量抜けするような場所、具体的にはロータリーエンコーダ出力を整形するところにあるフィルムコンデンサを積層セラミックコンデンサに交換。ところが、不具合は解消せず。
 ってことは、コントロール基板内の容量抜けだろうなということで、全部を分解するのが面倒だったので、そのまま放置しておりました。

 ところが、先日上の写真を撮るために通電してみたら・・・あらら、症状が重くなっている。
 ってなわけで、どうしようかなと思っていたところ、たまたま見たのが「たくてれ。」さんのこの動画
 そうかぁ・・・・コンデンサの液漏れかぁ・・・この時期のKENWOODの類似リグでこの現象があるならば、TW-400でもありうるな・・・だとすると、そのまま放置していると、腐食が進んで、取返しがつかなくなるな・・・ということで、重い腰を上げることにしたのでした。
 で、コントロールユニットを取り出してみたら・・・。

 おっと! ランドがなくなっているように見える! ここまで腐食が進んでいるとは・・・。
ちなみに、これはランドの付近の腐食を除去したあとの写真です。でもって、ランドが完全に剥離していたわけではなく、表面がしっかり梨地状に腐食しています。でもって、腐食しているところは根深く、表面レジストをはがしてちょっと磨いただけでは梨地の凸部分の銅が現れるだけで、全体として梨地状は残るという状況です。
 ほかにも・・・。

 これも凄い。なんか、ダイオードの接続が怪しくなっている・・・と思いつつちょいと突いてみたら、あらぁ、完璧に剝がれて、ブラブラしている状態。 このダイオードは、リードをホールに差し込んで配線に接続するのではなく、ランドの上にリードを載せて半田を盛るようにして接続されています。そして、ダイオードのリードと基板ランドの間で腐食が進んでしまったために、浮いちゃった模様です。おそらくここが着いたり離れたりしたために、不具合が生じたり生じなかったりしたのでしょう。現象としては納得できました。

 更に他にも・・・。

 シグナルメータ用のLCDドライバICの足と基板ランドとの間に電解液が入り込んで腐食しているようです。かろうじてスルーホールで通電しているだけという感じになっていました。また、その後ろ側にあるコンデンサ(高周波パスのためのもの)のランドも腐食が進んでおりました。

 というわけで、コントロール基板(というか、LCDドライバ付近の基板)に乗っていた電解コンデンサは全て液漏れしていた模様です。
 交換のために、取り出したコンデンサはこちら。

 これではダメですよね~。
 というわけで、これらを全て交換(といっても容量の持ちあわせがなかったので、47μFのところは100μFにしてありますが・・・・)しました。
 加えて、リチウム電池は交換しやすいように、ケースを追加設置しました。
 ということで、腐食部分が完全に取りきれたような自信はないのですが、これ以上削ると、パターンが危ないことになるので、これで様子を見ることにしました。


 ってなわけで、これで完動とあいなりました。

 それにしても、所詮5Vのストレスしかないはずなのに、なぜデジタル系の電解コンデンサばかりが液漏れするのでしょうね? バックライトのための麦球の熱とかが影響してるんでしょうかねぇ???

 ちなみに、この時点でネット上を検索すると・・・・。

 あらら、ここって、TW-4000の持病のようですね。
 電解液が基板上でどのように漏れ拡がるかで、様々な現象が起こっているようですね。
 主にはSメータが動かないってのが多いようですが、自分のところのようにVFOの不良とか・・・。ただ、古いリグの場合、大抵はまずはバックアップバッテリの不良が支配的で、そのために表示がハチャメチャになってて、それを抑えるべくバッテリを交換する過程で、併せてこれら3つの電解コンを交換して正常動作に至る・・・っていう感じのようです。
 ただ、交換する部品はこれら3つの電解コンデンサに尽きているようですね。^^;

 ってなわけで、もう40年目となるTW-4000ですが、昨年新スプ確認保証を通したこともあるので、まだまだ現役として頑張ってもらうことにします。^-^)



追加(2023/12/19 09:04)
 久しぶりに長時間電源を入れていて感じたのですが、デジタル系の電解コンデンサばかりが液漏れしたのは、やはり麦球の影響なのかもしれません。パネル面に暖かさを感じます。つまり、内部では結構な温度に上がってるということですね。こりゃ、寿命を延ばすならば、LEDに交換すことも考えなければならないかもしれませんね。
 
 
タッチキーヤーの記事の前に、ラジオの製作を。

「ラジオはWIDE-FMの方に移行する。」というようなニュースを見かけるようになりましたので、FMラジオが部屋にひとつづつくらい欲しくなってきますよね。
 ただ、現代風のラジオ作りってことになると、SDRってことになるんでしょうね。
 ってなわけで、私も秋月電子でゲットしたKT0913を使って、FMラジオを作ってみました。
 仕様ですが、「この大きさなら持ち運びが簡単なので、リモコンは不要だろう。」と思っていたのですが、同じ部屋の中でも窓際が一番綺麗に聞こえるので、ラジオ本体はそこに置きたくなります。そうすると、やはりリモコン機能があった方が嬉しいわけです。
 ってなわけで、リモコン機能も付けてみました。動画はリモコンで動作させているところを示しています。

 で、作ってみたら・・・従来ながらの「ラジオ作り」という感じはしませんでした。これは、ただのマイコン工作ですね。
 高周波絡みのテクニックも使っていません。ご覧のようにデバッグのためにデバイス間の配線も長くしてありますが、そのまま使ってもトラブルは起きていません。気温・気圧・湿度記録器を作ったときと同じ感覚でした。
 プログラムも以前作ったLCDドライバ、I2Cドライバ、IRドライバを組み合わせて、これらを制御するプログラミングだけで済みましたので、仕様の試行錯誤も含めて1日程度で完成しました。自作ラジオが完成したときに味わう感動は少しもありませんでした。(・ω・`)

HWについて
さて、まずはHW。

 このラジオの構成ですが、フロントエンドにKT0913、制御にPIC16F1938、低周波増幅にNJM2073(回路図に番号入れるの忘れてる。^^;)、IRセンサにPL-IRM0101-3、LCDにSC1602の3.3Vバージョン、としました。また、IRセンサを意識して、同調と音量の調整はそれぞれロータリーエンコーダを使ってみました。
 見たまんまで、回路はなんの変哲もなく、ただ、各デバイスをPICにつなぎこんだだけです。高周波に特有のテクニックもありゃしません。^O^)""

 この程度の回路なのになぜPIC16F1938?
 これについては、この図を見ればわかります。
 操作部をできるだけ減らすことを裏目標にしましたので、実機デバッグを容易にしようということで、ICSP接続をすることにしました。また、KT0913はI2C接続を必須とするので、ここに他の割り当てをすることができません。
 また、LCDの駆動プログラムは4ビットのデータバスが必要なので、これはまとめてとっておきたいわけです。
 この条件を満たすCPUとして、とりあえず部品箱の中にあったのが1938だったのでありました。
 そんなわけで、ピン割り当ては以下の通りとなりました。


SW
今回はモジュールが4つあります。
(1)mainプログラム
(2)I2Cモジュール ヘッダーファイル プログラム
(3)LCDモジュール ヘッダーファイル プログラム
(4)赤外リモコンモジュール ヘッダーファイル プログラム
(5)ロータリーエンコーダモジュール ヘッダーファイル プログラム

まとめてダウンロードなんてする方は居られないと思いますが、こちらで

固定チャネルとVFOをどう割り振るか?
FMラジオという以上、100kHz単位で周波数を可変にしたいと思いますが、一方で、簡単に在京各局には簡単にアクセスしたいとも思うわけです。通常はメモリースイッチを設けて、固定チャネル・可変周波数の切り分けをするところだとは思うのですが、今回は、初期状態では固定チャネル、これらをロータリーエンコーダで選択していって更にその上に行こうとすると、76.0MHzから順に100kHzステップで上がっていくという手法を採りました。所詮、固定チャネルを使うのが殆どですし、リモコンもあるので、まぁ、これで良いかなと思っています。

使ったリモコン
使ったリモコンは、何年も前にベスト電器で買ったIRC-700D。いろんな会社のTVに使えるというものですが、機種コードを012で使うことにしています。
 このコード体系の下では、機種IDとして0x50が出てくるようになります。

まぁ、そんなところです。別にラジオを作らずとも、PICでのI2Cのアクセスの仕方とか、LCDのスクロールとか、ロータリーエンコーダの受け方とか、何かの参考になれば幸いです。^^;