SD-CARD Handler プログラムの解説（１）

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

・ー・ー・・

今月7日に公開しましたSD-CARD Handler for YAESU SYSTEM FUSION (α Ver.) Version 202406060818 版には
（１）画像の読み書き機能に加え、
（２）MESSAGEの読み書き機能、
（３）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 Boot３と呼ばれるフレームワークを使用しています。このためプログラムは多くのモジュールを抱きかかえることになるのですが、解説するのはフレームワーク以外のところだけにとどめます。
で、プログラムの構成は下図のようになっています。


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


・ー・ー・・

　これ、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パッケージでしょう。ここにある２つのファイル中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が最初の画面（５つのプレーン）を全て定義してある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 (α Ver.)

「SD-CARD Handler for YAESU SYSTEM FUSION Ⓡ」のダウンロードリンクはこちらのエントリに固定しておきます。
現在、(6/23に微妙に機能を追加した)2024/6/6版を掲載しています。

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ファイルの３つに分かれて記録されています。たとえば、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に挿着し、これに対して操作をすることになります。

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

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

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

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

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

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

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

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

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

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


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

ダウンロード
（１）　マニュアルは、こちらです。　（6/23に微妙に機能を追加した2024/6/6版）
（２）　JAVAのJARファイル(プログラム本体)は、こちらです。（6/23に微妙に機能を追加した2024/6/6 Version 202406060818-2 対応版です。）

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

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

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

変更履歴

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

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

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

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

2024.05.12
　（１）　QRコード機能を追加しました。
　（２）　マニュアルにQRコード機能に関する説明を追加しました。

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

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

2024.04.13
　GM動作時の画像交換に対応しました。

今年完成した自作ランキング

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

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

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

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

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

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

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

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

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

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

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


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

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


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

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

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


そんなわけでした。
では、皆さん、良いお年を～。^-^)ノ"

TW-4000の修理

　タッチ・キーヤーの前にもうひとつネタを書いておきます。

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

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


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

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

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

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

　更に他にも・・・。

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

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

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


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

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

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

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

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


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

FMラジオの製作

タッチキーヤーの記事の前に、ラジオの製作を。

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

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

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

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

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


SW
今回はモジュールが４つあります。
（１）mainプログラム
（２）I2Cモジュール　ヘッダーファイル　プログラム
（３）LCDモジュール　ヘッダーファイル　プログラム
（４）赤外リモコンモジュール　ヘッダーファイル　プログラム
（５）ロータリーエンコーダモジュール　ヘッダーファイル　プログラム

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

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

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

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

マイク分配器（SW編）

さて、一気に仕上げちゃいます。
マイク分配器のソフト編です。PIC16F886用です。他のCPUを使うなら、initialize()関数あたりを修正する必要があるでしょう。

マイク分配器について、ソフトでやることは、
（１）SM-50のPTT/UP/DOWN信号線のON/OFFを認識して、
（２）リグ切替ボタンのONを認識して、
（３）ずぅっと（１）（２）を監視しつつ、指示信号があったらその通りにリレーをガチャガチャ切り替える、送信する、UP/DOWNのパルスを作る、リグ切替ボタンの押圧を感知したら、出力先レジスタpresentTargetRig　を変更する、
ということの繰り返しだけです。
　ただ、それだけなのですが、一応、 SM-50のPTT/UP/DOWN信号線を監視する際、ヒステリシスをもったフィルタをプログラム上で実現します。こうすることで、プルアップ抵抗とコンデンサによるチャッタリング防止回路と概ね同等の処理を実現します。ただ、プルアップ抵抗だけは入っています。これは、U/D信号は470Ωを噛むか噛まないかでUp/Downを判定するために、ある程度正確な抵抗値が分かっていなければならず、PIC内のWeak-pull-up機能では安定が図れないからです。
　もっとも、フィルタ機能といっても、単に移動平均値を計算して、上限スレッショールド値、下限スレッショールド値を異なったものとしただけなんですけどね。^^;

　プログラムは、こちらにおいておきました。

　特に解説するようなことはありませんので、プログラム編はこの程度で。

　ということでマイク分配器の製作メモ。連載開始からちょっと時間がかかってしまったのですが、一応不具合点は出しきったかなと思いますので、これで終了します。

　次回は、タッチキーの製作あたりにしてみますか・・・。

マイク分配器（回路図編）

では、今回は回路図を挙げていきます。

制御部
まず、制御部分はこんな感じです。

　SM-50から来た制御線、つまり、PTTとUP/DOWNの制御線は、PIC16F886のRA0,RA1につないでいます。一応、過大入力制限のために、BAT43で保護しています。^^
　各リグ用のインターフェース回路（I/F）ではリレーを使い、これらはさすがにPICのドライブ能力では十分に動かせませんので、トランジスタドライバを入れてます。このドライバIC（TD62003APG）はベース抵抗が不要なので、PICに直付けできます。ただし、生産終了品だそうです。秋月には大量在庫があるようなので、しばらくは入手できると思います。
　リグの選択ボタンは、プルアップしたうえで、RA2につないでいます。
　制御部から各リグ用I/F回路にはPTT/UP/DOWNの３線がそれぞれつながっています。なお、パネル面にもPTT/UP/DOWNの状態がLED表示しますが、PICのピンが足りないわけではないので、特に各リグに延びるPTT/UP/DOWN線からダイオードで取り出すようなことをせず、RA3～5に割り当てました。

IC-9700用I/F
　続いてIC-9700用のインターフェース回路です。

　マイクと電源はホット側・コールド側ともにリレーで断続するようにしてあります。また、デジタル系はフォトインタラプタで・・・と行きたかったのですが、マイク分配器の製作（トラブル(・ω・`)）に記したとおり、IC-9700がUPを認識してくれなかったので、ここもリレー（RLY9、RLY10）でON/OFFするようにしました。図面では"Photo Interruptor #2"に当たるところもそのままにしてありますが、図中にも書いてあるとおり「PI2は実装しない」ことにします。
　
FTDX10用I/F
　続いて、FTDX10用のインターフェース回路です。

　FTDX10では、UP/DOWNを図下右のようにするとUP/DOWNとして認識されるようです。もちろん、DOWNピン、UPピンをそれぞれON/OFFしてもUP/DOWNとして認識されるのですが、既に「FTDX10に接続するマイクの中身？」で指摘したように将来的にどう変更さるかわからないので、FTM-300Dのマイクでも使われているような回路にしてみました。その他はIC-9700用と同じです。
　SM-50ではなくHM-219マイクを使ったときのために、マイクオーディオラインに電源を供給する必要があります。この電源回路をこの回路図に含めてあります。（読みにくくてすいません。）
　また、電源・アンテナ・各種ケーブルの引き回しなどによって何が起こるか想像しきれなかったので、いろいろなところにグランドレベルについてのバイパス回路をつけてあります。通常は図中JMP6をCLOSEに、JMP5をOPENにして使うことを想定しています。本機の電源によってはハム音などが出るかもしれないとの不安があったので、JMP5を使ってリグのデジタルグランドと本機のデジタルグランドとを接続できるようにしてあります。おそらく大抵の場合、RLY５，RLY6、RLY7、RLY8のグランドラインの接続も不要だと思います。あくまでも実験用ということで。
　当局の環境で実際に運用してみると、これらの危惧は無用でした。^^;

TR-851・TW-4000用I/F
2023/12/24　回路図を修正しました。
　続いてTR-851・TW-4000用のインターフェース回路です。

　ここは素直に、UPピン、DOWNピンにそれぞれの信号を送るだけです。
　もっともTR-851/TW-4000が他のリグと違うことは、リグからの電源供給がない点です。そのため、マイク（SM-50）への電源供給は本機内部の電源を使うことになります。
　なお、マイクに供給する内部電源と外部電源の切替用リレーRL7は、TR-851/TW-4000を選択したときには、このリレーが常にONするようになっています。
[回路図修正のポイント]
　修理が完了したTW-4000を使っていて、グランドの扱いが間違っていたことに気づきました。内部電源を使用するときに、内部電源とリグとの接続のうち直流的に短絡させるべきは、デジタルグランドではなく、アナロググランドですよね。なぜか思い違いをしていました。当初デジタルグランドと接続させようとしていたために、マイク端子から電源が得られないTR-851/TW-4000では、icomのマイクに電源を供給できませんでした。TW-4000だけ別の電源系統を使っていたため、このことに気づきました。つまり、設計上はTR-851/TW-4000を接続すると、特別な操作を必要とすることなく内部の電源がマイクのアナログ系に供給されるべきところ、これが供給されていませんでした。
　まぁ、回路図を細かく分割したために見通しが悪くなっていたわけですが、それにしても、これに気づかないとは・・・。
　ということで、当初の回路からの修正点は、
（１）　他のリグのデジタルグランドを常にグランドに接続しないように、JMP8を設けて切断した。
（２）　C-GNDへの接続は、JMP7でマイク・グランドに接続するようにした。
というところです。なお、接続ポイントは、JMP1図面上部側の端子にするべきなのでしょうが、基板上の配線の都合上、JMP1図面下部側の端子にしてあります。

FTM-300D用I/F
　続いて、FTM-300D用のインターフェース回路です。

　FTM-300Dの場合、アナロググランドとデジタルグランドが共通になっていることが特徴です。本機内ではデジタルとアナログを分けている都合上、直流的にはショートさせることになるものの、一応気休め程度ではありますが、両者間にフェライトビーズを噛ませてあります。UP/DOWNの回路については、FTDX10と同じものになっています。

電源部
　最後に電源部の回路図です。

　何の変哲もない三端子レギュレータの回路ですが、ひとつだけ触れおきたいのは、電源入力部にシリーズに入れてあるダイオードの存在です。この目的は逆流防止です。
　本機は３つの電源を切り替えて使うことができるのですが、３つの電源が全く同じ電圧なら問題ないのですが、それぞれが異なっていることが考えられます。
　最初に高い電圧の電源に接続していたところから低い電源の電圧に切り替える場面を想定します。すると、切り替えたとき、三端子レギュレータ入力部分にあるコンデンサから電源の方に逆流する可能性があるわけです。これを危惧して入力初段に逆流防止ダイオードを入れたわけです。

　そんなところで、今回はここまでということで。
　次回はソフト編ってことで、マイク分配器の製作メモは終わりたいと思っております。

マイク分配器の製作（設計編その３）

さて、IC-9700を分配対象としたときの不具合も解消できたので、続きを書いていきます。
　でも、その前に・・・・。

（１）　マイク分配器を使うとっていう話
　このマイク分配器を使ってシャックを整理すると、こんな感じになりますというのをご紹介。上下に複数段を持つ棚にリグを配置すると、上段のリグのマイク線が下段のリグのパネル前に垂れてしまい邪魔になるものですが、マイク分配器を使うとすっきりします。



　なお、ADNISさんも、マイクセレクタをAK-8Sとして製品化しておられます。
ただ、この使用例２を見ると、「ご使用の無線機専用のマイクロホンが、接続する２台の無線機にご使用できることをご確認ください。同じ無線機メーカーであっても機種が違った場合、ご使用できないことがあります。」と書いてあって、これは推測ですが、マイク端子の８本の線を独立にスイッチングするだけになっているように思います。
　このため、モジュラージャックを採るFTDX10やFTM-300Dなどには変換アダプタを用いれば接続できないとまではいえないのですが、UP/DOWNなどの信号については互換性は採れないことになります。

（２）　ブロックダイアグラムの検討

　さて、マイク分配器の基本仕様は既に「マイク分配器の製作（設計編その２）」で書いたとおりです。
　デスクトップ用マイクとして選んだSM-50のup/downは、リグから出てくるマイク制御線と制御グランド線との間をショートするか、470Ωの抵抗を介して接続するか、で指示するようになっています。
　よって、PICで内蔵されているA/Dを使って、これを検出することになるわけです。
　どのリグを対象にするとしても、この点については、
FTDX10に接続するマイクの中身？
で紹介したとおりです。

　さて、具体的なマイク分配器のHWを検討する前に、各リグに対してどのような構成をとればよいのかという点を検討します。
　PICでSM-50の信号を処理する以上、まずはこれをPICで受ける必要があります。
　どのリグにつなぐとしても、この点は共通するわけです。

　では、電源をどうするか？
　この点、
1)　デジタル系は、フォトカプラやリレーでグランドを分離することが可能。
2)　アナログ系は、できるだけリグから供給される電源をそのまま利用したい。
2-2)　とはいえ、TR-851やTW-4000は、リグから電源が供給されていない。
　ということを考慮して、対象リグごとにどうするのが望ましいかと考えると・・・・。

　リグから電源が供給されている場合、マイクのアナログ回路にはこの電源をできるだけ供給したいところです。もっとも、マイクにSM-50ではなくハンドマイクを使う場合を考慮すると、アナログラインに電源を重畳する必要があるわけです。
　そうなると、重畳する電源に何を使うか・・・。
　いろいろ考えると、場面によってリグの電源を使うのがよいことと、独立した電源を使った方がよいこととがあり得ると思うようになりました。
　では、そのような仕様にした場合、各リグにはどう接続していけばよいのか・・・。

IC-9700とFTDX10の場合

　IC-9700とFTDX10とは以下のような強い共通点があります。

1)　マイク用電源がリグから供給されていること
2)　マイクアナログ信号線のグランドと、PTT/UP/DOWN用デジタル線のグランドとが独立していること

　この点を考慮すると、以下のようなブロックダイアを候補としました。



　ところが、これを実際に作りこんでみると、あれ？マイクラインに内部電源をマイクアナログ電源としたときに、グランドが離れて供給できない・・・。気づかない私が悪かった・・・。^^;
　そんなわけで、内部電源のときには直流的なグランドを共通にするような配線を作って、以下のようにしてみました。



　簡単に各部を説明していきます。

（A) ICOM MIC
　左側のブロック「ICOM MIC」はマイクそのものです。SM-50を原則的に使用しますが、HM-219(IC-9700に付属のマイク)も使えるようにします。
　SM-50はリグから供給される電源を内蔵マイクアンプの電源としますが、HM-219では、マイクオーディオ信号に重畳された電源をコンデンサマイクの電源とするようになっています。このため、マイク端子には、マイクオーディオ信号に電源を重畳するとともに、独立して電源も供給しなければなりません。

（B）セレクタ
　セレクタは、マイクから来たアナログ信号を特定したリグに接続する手段です。
　信号の独立性を確保するため、２回路のリレーを用います。また、リグによっては、マイクオーディオ信号線に電源を重畳するものとしないもととがあるために、セレクタからリグに直流電流が供給されないようにしなければなりません。

（Ｃ）重畳電源
　既に上述したとおり、HM-219(IC-9700に付属のマイク)では、マイクオーディオ信号に重畳された電源をコンデンサマイクの電源とするようになっていますので、これに対応するために、重畳電源を設けます。もっとも、SM-50は別電源で動くので、この重畳電源は不要なのですが、マイクオーディオ線が内部でコンデンサでカップリングしてあるので、特にSM-50のときであっても、重畳電源の供給を止める必要はありません。

（D)　セレクタ/スイッチャ
これは、リグから来た電源とマイクの＋８V供給ピンとを接続・切断するスイッチング手段です。２回路のリレーを用います。リグは複数を対象とするので、操作対象とするリグへの接続以外は、切断状態にしておくことで、アナログ系の独立性を確保できるようになります。

（E)　ISOLATOR
　アイソレータは、後述する制御用CPUから得られたPTT/UP/DOWNの信号（0V-5Vでスイングする信号）を各リグと接続するために電気的に分離します。前回のトラブルに対応するため、IC-9700ではリレーを、他のリグではフォトアイソレータ（TLP222GA）を用いることにします。つまり、ひとつのリグに対してPTT/UP/DOWNの３つのスイッチング手段が用意される必要があるわけです。

（F)　I/F
　インターフェースは、ISOLATORのスイッチング信号を使って各リグに合った信号形式の信号に変換します。つまり、IC-9700/FTDX10/TR-851D/FTM-300Dの４種類のインターフェースを実装することになります。
　どのようなインターフェース回路にするかは、各リグに接続するマイクの信号をエミュレートすることになります。あるリグ（FTM-300DとかFTDX10とか）は２本の信号線に異なる抵抗を接続することになりますし、あるリグ(TR-851D)はそのまま、またあるリグ(IC-9700)はマイクキー入力ピン（マイク端子の３番）とPTTのGNDピン（マイク端子の６番）とを０Ωで接続するかショートするか抵抗を介して接続することになります。

（G）PS for CTRL
"Power Supply for Control"のことです。先に決めた仕様通り、３種類の別電源のうちからロータリースイッチで選択するようになっています。

（H)　制御用CPU
　制御用CPUの主たる作業は、
A）　リグ選択指示（操作パネル右側のボタン。下写真参照。）を監視して、指示があったときには、現在対象として選択しているリグを次の順に定められたリグに替えていくこと。

B）　マイクのPTTの押下を監視して、押されたときには、現在対象としているリグのPTTをONにすること。
C）　マイクのUP/DOWNの押下を監視して、押されたときには、現在対象としているリグのUP/DOWNをそれぞれONにすること。
　となります。他にも、
D）　選択されたリグが何なのかを示すLEDを点灯させること。
E）　PTT/UP/DOWNが押されていることを示すLEDを点灯すること。
　を行います。

TR-851D(/TW-4000)の場合

　この場合、リグからの電源供給がないために、内部電源を使うしかないわけです。
　そうすると、こんな感じになると思います。
　


　でもって、やはり、制御系（PTT/UP/DOWN）とマイクアナログ系に重畳する電源とのグランドレベルを直流的につなげる必要があるので、



　というようにすればよいと思います。

最後に、FTM-300Dの場合

　FTM-300Dはリグから電源は供給されますが、なぜか、マイクアナログ信号線のグランドと、PTT/UP/DOWN用デジタル線のグランドとが共通していて独立していません。
　よって、このあたりを含めて基本構成は、



　こんな感じにする必要があります。
　ただ、ハンドマイクへの電源共有は必要なので、そのためにはマイクラインへの重畳電源のためのグランドを直流的に接続するために、



　こんな感じにするのがよいかなと思います。

　ってなわけで、これらをCPUで選択制御していくことになるわけです。

（３）　懸念される問題点

　やはり、各リグに伸びるグランドのアイソレーションでした。
　ここは思い切って、リレーを積極的に使うことにしました。ただ、デジタル系だけはフォトインタラプタを使えるので、スペースについては気が楽です。
　と言いながら、寒くなってきたら、不具合がでた（マイク分配器の製作（トラブル(・ω・`)））ので、結局、IC-9700にだけは、フォトインタラプタではなく、アナログ系・デジタル系ともにリレーを使うことになりました。
　そのほかのところは、設計で狙ったとおりの状況で動いています。

　次回は、回路の詳細あたりに触れたいと思います。

マイク分配器の製作（トラブル回避は原始的に）

　ってなわけで、前回書いたIC-9700で特有のトラブルですが・・・。
　TLP222G-2のON抵抗がIC-9700のON判断のギリギリの点だったようです。
　具体的には、IC-9700の電源をONにした後はUPキーを認識しないものの、しばらくすると、正常動作をするようになります。おそらく、A/D内部の状況が安定すると、25Ω程度のON抵抗でもUPキーが押されたものと認識できるようになるのでしょうね。
　流石にこれでは使い勝手が悪いので、ここはON抵抗の低下を図ってみることにしたわけです。
　で、最初にやってみたのが、TLP504Aへの変更。さすがに、出力側がバイポーラトランジスタなら、ON抵抗も小さいだろうということで、手持ちのフォトインタラプタにTLP504Aがあったので、これに差し替えようというわけです。
　ただ、TLP222GとTLP504Aとはピン配置が違う。ってなわけで、下駄基板を挟んでみることにして・・・。

　これで大丈夫だと思ったら・・・。あららUPボタンを押してもDOWNボタンを押してもDOWNする・・・。(・ω・｀)
　もっと内部抵抗が高かったという・・・。^^;
　でも、なんで？ってことで特性表を見てみた。


　これでもダメなの？？　本当にUPキー認識の閾値を小さく採ってあるのね・・。　まぁ、そのうちこういう下駄基板は必要になるだろうから、いいけど・・。^^;）

　ってなわけで、次に考えるのはトランジスタスイッチですが、アイソレーションのことを考えると、なんだか面倒くさい。他のリグからのアイソレーションのためには、トランジスタ駆動のにIC-9700側の電源を使用することになります。確かに、9700のマイク端子からは8Vの供給があります。よって、これを使えばできなくはないのですが、ん～、なんか正攻法過ぎて面白くない。^Ｏ^）
　そんなこんなで、結局設計当初に考えていた、「全部をリレーでセパレーション！」というコンセプトをIC-9700に限って実装しようと考えました。
　で、こうなりました。

　青い枠で囲ったところが、もともとTLP222G-2があったところ。これに並列して、赤い枠で囲ったリレーを増設しただけです。リレー駆動のためにはトランジスタ（2SC1815）を使ったのですが、リレー自体がアイソレーションをしてくれるので、リレー駆動用の電源には、マイク分配器の制御系に使っている５Ｖを使用できます。なもんで、これでＯＮ抵抗を略０Ωにすることができたわけです。
　ＵＰ／ＤＯＷＮボタンを押すと、カチカチいうのが結構良い感じです。
　まぁ、そんな感じで、略回路は確定しましたかね・・。
　ってなけで、次回のエントリからマイク分配器の内部について触れていきまぁす。

マイク分配器の製作（トラブル(・ω・`)）

　えー、先々月まで気合を入れて書いていた「マイク分配器の製作」なんですが、FTDX10,TR-851D,TW-4000,FTM-300Dではどれも正常に動くんですが、ちょっと前から、なんだかIC-9700を接続先にしたときのみ、[UP]キーが効かないというトラブルが生じるようになりました。
　また更に最近では、たまに[down]も効かなくなったりします。急に寒くなってきたからなんですかねぇ。
　ただ、分配器を経ずに直接マイクをIC-9700に接続すると、問題なく動作します。

　ということは、これはもしかしてアイソレーションのために使っているTLP-222Gのオン抵抗に問題があるな？？？と原因を想定、これを実測すると確かに、25Ω。ちょっと大きいですかね。。。デバイスのカタログスペックでは、標準25Ω、最大35Ω、飽和状態ならば50Ωとなっているのでありました。

　この端子（IC-9700の取説p21-2参照、マイクキー入力）には、UP-DOWNのほか、外部キーパッドを接続することができるわけですが、そうだとしても、470Ω、1.5kΩ、3kΩ、5.2kΩ、9.9kΩとショート状態を認識するだけなので、25Ωくらい、多めに見てくれればいいと思うのですけれども、まぁそこは何か、設計者の意図があるのでしょう・・・。

　そうであるならば、バイポーラトランジスタスイッチに変更しよう！・・・・となるわけですが、できるだけ回路を複雑にしたくないので、現在のところ、出力側がＦＥＴではなくフォト（バイポーラ）トランジスタとなっているものに変更するか、はたまたアイソレーションも視野に入れたON抵抗の小さい回路を増設するか、などなどを検討しているのでありました。

　これで試して、不具合が生じない回路になったところで、また続きを書いていきたいと思っております。

　え～、別に死んだわけじゃないです。^O^)""

（おまけ）　タバコシバンムシ
　あ、シャックを襲ったタバコシバンムシの大群は、古くに貰った漢方薬の入った箱が原発巣だったというのは既に書いたとおりですが、これを廃棄したあとは、まだ一匹も見ておりません。
　そんなわけで、無線の方は再開しております。^^;