久しぶりのパソコン自作：VGAエラーとなる？

15年ぶり位になるかも知れないがマザーボードを買ってパソコンを自作する事にした。事の発端はJTDXをソースからコンパイルして構築するのにUbuntuが必要となった事と、手持ちの部品：ケース、電源がそのまま使えそうな事だ。で、マザーボード（Asus Prime H610M-A D4)、 CPU(Intel CORE i5-12400F LGA1700)、メモリ：16GBを購入して取りあえずMBをケースに取り付け、電源接続で通電するが、、、画面が表示されない。MBには今風なのでHDMI,VGAのVideoI/F や Audio、ネットワーク等が当然On Board で搭載されている。疑う事無くMBのHDMIとモニタを接続して通電しているのだが、「信号無し」との表示がされる。ネット等で調べた所ブザーチェックが有効との事でスピーカーを接続した所「長音＋短音3回が発生」これはVGAエラーとの事。ますますわからなくなる：VGAってオンボードだよね？ブザー音からCPU、メモリは正常と判断出来る。VGAエラーって？と随分悩んだ。で、改めてCPUのスペックを見ると「Core i5 12400Fは内蔵グラフィック無しです」とある。うん？？　グラフィック無し？　MBにコネクタが有ってもCPUがグラフィックサポート無しだと画面表示されないと言う事かも知れないと推測。安価なグラフィックボードを購入して接続した所、無事画面が表示されてUbuntuインストール完了となった。これ、どっかに書いといて欲しかったなあ。結構むだな時間を費やする事となった。PCの様子を貼っておく。

Windows版ログソフト Swisslog V5 & LogHX3

 いつも書いている様に私のPCはmacで、ログソフトはRunLogNG を使っている。この環境には満足しているのだが、如何せん 周りでmacを使っているのは私位で大半はWindowsを使っている（当たり前か？）知り合いの何人かはDX専門でOnAir している為か国産のログソフトでは些か不便をしいられていると言う事で「何か良いソフトないの？」と聞かれていた。「そのうち。。。」とお茶を濁すのも限界なので思い切ってレビューする事にした訳である。ログを選ぶ条件としては

　１．単体でJTDXからのQSOをロギング出来る

　２．単体でLOTW、eQSLと連携できる

　３．JTDXでクリックした時点で、相手局と交信済みか否か、相手局の

　　　LOTW等への対応はどうかが解る

　４．他のログソフトやJTDXにADIFからのインポートが可能である事

として、候補に挙げたのが　Swisslog ,  LogHX である。Logger32 も有るのだが以前に触って挫折したのと、LOTW関連の I/F が弱そうなので今回は省いた。

まず、両方のソフトに対して行う作業としては

　１）JTDXからADIFファイルをインポートしてログとする

　２）Lotw,  eQSL と同期して最新の状態を再現出来るかどうかの確認

　３）JTDXからのQSOをログとして取り込めるか、確認

　４）その他使いやすさを評価

＜LogHX３＞

　ロシア製のログソフトで、ヘルプもマニュアルURLもロシア語。まあ、翻訳機能で何とかなるのでそのあたりは気にしない。インストール＆起動も問題は無い。評価は

　①　JTDXログのインポートは問題なし

　②　Lotwからの読み込みでは期待した動作にならない（私の使い方が悪いのかも）

　③　eQSLの読み込みも期待通りにならない。（フィールド指定が違うのか？）

　④　②、③共機能の説明がよくわからない（Sync Import のメニュー等）

　⑤　画面構成はわかり易い。個々の画面は独立しているが、view機能で各画面の

　　　サイズ、位置が保管出来ていつでも呼び出せる（これは便利）

　⑥　直感的に解り易い構成で、得られる情報はRumLogに近い

その他、画面の表示、操作性は概ね良好であるが、LOTWとの連携がやや怪しい。

QSOしたデータを一端ADIFファイルに落としてアップロードするらしく操作がちょっと面倒。断っておくが、私は通常RunLogを使ってLOTW、eQSLへデータを保存しているのでこれが壊れると非常に困る事になる。それで、今回、Lotw eQSL　へのアップロード検証はちょっと躊躇いがちに実施しているのでそのあたりは勘弁してほしい。

画面を貼っておく。

LogHX3の画面

画面左上でコールサイン背景が橙色になっているのは、交信済み局である事を表す。ワールドマップの他にアジマスマップの表示出来るのでローテータの方向も解る。

＜Swisslog V5 ＞

　こちらはスイス製のソフトウェア。このソフトについてはEDC社の社長であられた、故木下重博氏（ JA8CCL）が日本語訳のマニュアルを公開されている。

" Swisslog EDC " で検索すればヒットするのでインストール等、詳細はこの文書を参照して頂きたい。木下氏はEDC社のサイトにこれ以外にも貴重な資料をアップされているので是非ご覧頂きたいと思う。（合掌）

　インストールマニュアルに従うとスムーズに作業が進行する。これを見ないでインストールした際、言語でEnglish"を指定したのに、メニューがスイス語で焦った。よく読むと次の段階で設定出来るとの事でひとまず安心といったところ。評価は

　①　JTDXログのインポートは問題なし

　②　Lotwからの読み込みも問題なし。RunLogと同じ状態が再現出来た！。

　③　eQSLの読み込みは期待通りにならない。Reciveフラグが反映されない

　　　これも使い方が悪いのか？新たなQSOでの実証はしていない

　④　画面構成はまあわかり易い。（これはLogHXの勝ち）デフォルトでは一つの画面

　　　に各画面が収納されるが、特定画面は外だし出来るようになったいる。

　⑥　知りうる情報はLogHXと変わりない。FT8のバンドマップがきれいに表示出来た

機能が多いので、何処かで設定した内容がどの機能に影響するのかが、良く解らない（単に勉強不足）画面表示の感触ではLogHXに軍配が上がるのだが、LOTWがきれいに反映された事が大きいのと、インストールマニュアルが有る事で、知り合いに勧めるならこちらかな。画面を貼っておく

SwisslogV5 の画面

Windows11 on M1 Mac, running ExperSDR3+JTDX158

最近、Parallesに入れたWindowsの調子が悪いので1から再インストールした。やり方を忘れていたので備忘の為、リンクを貼っておく

kb.parallels.com

で、ちょっと思いついたのが、このWindows11の上でWindows版のExpertSDR3 と JTDX158 が動作するかどうか。いくら何でも実用にはならないだろうと思いながら下記の環境で構築してみた。

　macOS.          Monterey 12.1

   Parallels.        DeskTop 17.1.1  for Mac

   Windows.      Windows 11 Pro Insider Preview  Version DEV

   EXpertSDR3. Ver 0.11.0, alph 

   JTDX             v2.2.158

結果はと言うと、それなりに動いた！無論、正確にデコード率等を検証したわけではないが、いつも使っているMAC版ExpertSDR3の画面と遜色なく表示しているし、jtdx からTCI経由でバンド変更や送信等の操作が可能になっている。MAC上で動いているRunLogNGに対してもTCP/IP経由でログデータが送れるのでこの環境で実運用する事も可能だと思う。まあ、実運用はしないにしてもWindows版での検証等には使えそう。因みにこの状態でCPU負荷は20％、メモリ使用量は12GB程度となっている。恐るべしM1チップ。

恐らくだが、今回のケースはネットワーク接続で完結している為可能のなったのだと思う。これがUSB接続だとこうはいかない。

Windows11 on M1 mac

JTDX 複数Instance運用時のログディレクトリ指定

前に書いた記事で複数のJTDXを立ち上げて運用する際に、JTDXのログは独立して持たせてRumLogにインポートすると言う事を書いたのだが、何とかこれを”シンボリックリンク”と言う手法を使って解決出来ないかと思い色々やってみたので備忘を兼ねて記録しておこうと思う。まず、2つのJTDXのログの格納場所だが

本家：　　/Users/h-okude/Library/Application\ Support/JTDX　

2つ目：　 /Users/h-okude/Library/Application\ Support/JTDX\ -\ sdr2   

となっている。（リグ名は”sdr2"）ここで注意する点はディレクトリの記述方法。上のディレクトリ：2つ目をFinderで表示させると

2つ目：　/Users/h-okude/Library/Application Support/JTDX - sdr2

となるが、コマンドラインではスペースはデリミタとして認識されるのでシェルに書く場合などは上記の記述となる。

＜設定方法＞

1．2つ目のJTDXを起動すると自動的にディレクトリ（リグ名：sdr2とすると）

　 /Users/h-okude/Library/Application\ Support/JTDX\ -\ sdr2　が作成される

2．シンボリックリンクを作成する場合、同じ名前が有ると作成出来ないのでまず、1．の

　　ディレクトリを削除する

3．下記コマンドで本家のログディレクトリのリンクを名前を変えて作成する

　　ln -s /Users/h-okude/Library/Application\ Support/JTDX  /Users/h- okude/Library/Application\ Support/JTDX\ -\ sdr2

4．リンク　 /Users/h-okude/Library/Application\ Support/JTDX\ -\ sdr2が

　　作成された事を確認する

5．2つ目のJTDXを起動する

6．ファイル→ログディレクトリを開くで本家のログが見えている事を確認する

以上で、JTDXを複数インスタンスで運用する場合、JTDXとしてもログを1つで運用出来る事になる？？と思う。ホントかどうか少し時間を掛けて運用してみる。追記：この様な構成でJTDXを2つ起動し、2つ目のJTDXで交信した結果、RumLogにも正常に登録された。

JTDX v2.2.158 for M1 MAX CPU

macOS用のJTDXがアップデートされていた。M1 MAX cpu対応との事でその他には変更が無い様なのだが、取りあえず使って見た結果はOK。変わりなく動いている。M1チップだけでは無くMAXまでサポートするとは、開発陣には頭が下がる思いである。例によってテクニカルフォーラムのメールは飛び交っていて、中でも多かったのが「みんなのリグでCAT不具合があったら使っている無線機のメーカーと型番を教えてくれ」との書き込みに「私は。。、、、」みたいな書き込みが多数見られる。この分では159のリリースも近いかも知れない

JTDX v2.2.158 リリース

　JTDXだが、年末に157がリリースされたと思ったら早くも158がリリースされている。157のリリース後、フォーラムでは様々な不具合書き込みが有ったので早急に不具合解消されたであろうバージョンをリリースしたのかも知れない。しかしながら、158に関してもやはり多くの不具合書き込みが発生している。（主な投稿は添付参照）

　157の不具合：ローカル局の例で言うとCATコントロールが効かない状態だった。無線機の再起動等やってみたがうまく行かなかったので結局156に戻した。

因みに私が使っているM1 mac 用のjtdx: v2.2.158-32A は今の所不具合無く動いている。

macOSへのインストールは前の記事と同様にWindowsPCでダウンロードしたファイルをMacにインストールする事で解決される。

参考までに158での改善点を下記しておく

- TCI：ESDRが起動しない場合、正しいエラーメッセージを使用するようにしました。

- TCI：TCI接続を閉じる際のガードタイムを長くしました。

- TCI：最初の信号送信時にオーディオスパイクが発生しないようにしました。

- TCI: ESDR側からの変更に対するVFOBチェックを追加しました。

- libhamlibのサポートをスタティックからダイナミックに変更しました。

- pttのポート共有はHamlibのデフォルトで有効になっており、Hamlib initでjsonファイルを読み込むことで変更可能

- Linux OS: WSJT-Xのインストールとの互換性を保つため、パッケージインストールのプレフィックスを/usrから/usr/localに変更しました。

- logQSO TCP/UDPメッセージにSTATION_CALLSIGNとMY_GRIDSQUARE ADIFフィールドを追加、4/6/8char GRIDをサポート。

- コンフィギュレーションで壊れたGRIDを受け付けないように、GRIDコンフィギュレーション設定のエラーメッセージボックスを追加しました。

- CQ USA方向への対応を追加

- 高速なAMD Ryzen CPUでのレースコンディションを防ぐため、自動変数型の使用を避ける。

- 73/RR73メッセージのUDP返信メッセージ処理時のバグを修正、「CQと73メッセージ」オプションを追加

- プレフィックス<->グリッドのマッピングを一部変更

- /AコールサインでマウントアトスをDXCCで認識できるようにしました。

- rigctlcom-jtdxアプリケーションの追加

- メッセージパッキングとFFTに最近のWSJT-Xのパッチを適用した

- FT8デコーダー: デコーダーの開始が遅いオプションをデコーダーの開始が早いオプションに変更しました。

  これは、受信したオーディオフレーム数が少ない状態でデコーダーを開始するため、低SNR信号が少なくなる可能性があります。

  音声データが不完全なため、デコードされない。SWLモードでは、Early Start of Decoderは適用されません。

- MYCALLが空で、DXCallウィンドウに非標準のコールサインがある場合、FT8デコーダーのクラッシュを防止する。

- FT8デコーダ。標準MyCallと標準DXCallの組み合わせでAPマスクの使用ポリシーを変更しました。

  このようなQSOにおける平均遅延を減らし、着信のデコードの感度を向上させました。

- FT8デコーダー 標準的なマイコールで着信をデコードする際のAPマスクのバグを修正しました。

  および非標準DXコールサインでのDXコール検索において

- FT8 decoder: APマスクのその他の変更点

- FT8 Decoder: 誤デコードのフィルタリングに関するいくつかのバグを修正

- FT8 デコーダー：偽デコード、着信に AP タイプ 2 フィルタを追加しました。[MyCall ?］を追加しました。

- FT8 デコーダー: 誤った AP タイプ 2/3 デコードにチェックするための SNR 閾値を撤回 [MyCall ?］ [MyCall DXCall ?］

- ALLCALL7とLoTWリストの更新（20211229時点）、big cty.dat（20211225時点

JTDX 2.2.158のビルドは、Hamlibの共有ライブラリで作られています。

このようなアプローチにより、WindowsおよびLinux OSでは、JTDXを再構築することなく、Hamlibの最新パッチを適用することができます。Windowsでは、libhamlib-4.dllを置き換えることで、Hamlibパッチを適用することができます

JTDXフォーラムからのメール

ExpertSDR3 (Ver 0.11.0 Alph)リリース ＆ EDC社廃業 etc

昨日（12/28）EESDR3 の新バージョン 0.11.0 がリリースされた。大きな変更は無いがこんな所が修正されている。

　1．メインパネルにバンド、変調形式がバー形式で表示出来る

　2．TCIでのCWマクロの操作性を改善

　3．TX.PROCモジュールごとに設定可能なVOXを追加

　4．ボイスレコーダーの追加

　5．パノラマでのスポット表示に関する設定を追加

　　　スポット数は50～200個、スパンは3分～20分まで設定可能

　6．拡張TCI機能の追加

こんな所かな。1．のパネルにバンドと形式を表示出来るのはFT8以外でオペレーションする場合に便利だと思う。6．はより多くのTCIーIFを持ったソフトとの連動を可能にしている様だ。何より先週、フォーラムに「来週11をリリースするよ」とアナウンスがあって。実現された事が嬉しい！。ますます正式版が楽しみで、しばらくワクワク楽しめそう。無論、M1 Mac でもちゃんと動いていますよ。Rosetta 2経由ですけれど

　私がSunSDR2DXを購入したEDC社：エレクトロデザイン（株）が今年7月に廃業を公表されたらしい。先日、ふと同社のサイトを見て驚いた。何でも代表取締役社長の木下重博氏（JA8CCL）が急逝された故との事。この木下さんの名前に記憶があり過去メールを辿ると、SunSDR2DXを購入した際に、EESDR2とSunSDR2DX：ファームバージョンの不一致が原因で起こる不具合があり、その時に対応して下さったのが木下さんだった。とても丁寧にサポート頂き短期間で不具合は解消されこのリグは今も快調に動いている。その時は”丁寧はサポートのお兄さん”と思っていたのだがまさか社長自らサポートして下さっていたとは。感謝である。今更ではあるが木下さんのご冥福をお祈り申し上げます。

　EDC社が廃業した結果、国内でExpert社の製品を扱うのは1社になってしまった。まあ、グルーバルな時代だから海外から調達するのも良いけれどちと寂しい気持ちにはなるなあ。