RS-HFIQ（14）Quisk IQバランス校正（２）

日乗

WRTC開催記念局

先々月の話になってしまいましたが、正月1月6日にNYPに参加していたところ、WRTC 2022開催記念国内局の強力な電波が飛び込んできました。

当時はまだ認知度が高くなかったためかパイルになっておらず、CQを連呼している状態だったため、40m QCX+ 5Wと室内モービルホイップの組み合わせによるQRPでも1回で取ってもらえました。ワッチが重要であるという教訓でしょうか。

そのWRTC 2022開催記念局の運用期間が終了し、eQSLとAwardがHamAwardからダウンロード可能になっていました。（QSLはeQSL.ccからもダウンロード可能でした。）

The eQSL (left) and award (right) for the amateur radio station commemorating WRTC 2022.

HamAwardからダウンロードしたeQSLは単なる画像ではなく、eQSLのQRコードを読み取ると、左図のようにクラウド上でQSOが証明される仕組みになっています。

右図のAwardは、40m CWでの1回のQSO（10点）だけなので、順位15,009位の参加賞です。クラウドサービスによって、万単位の参加賞も瞬時に発行できるようになったということですね。

ただし、HamAwardからのダウンロードのハードルは高く、QRZ.comのメールアドレスを認証段階で使用するため、QRZ.comへの登録が必要です。また、保有する3つのブラウザの中の2つではセキュリティの関係で上手くダウンロードできませんでした。発行の複雑な仕組みがセキュリティにひかかるのでしょうか。

Raspberry Pi 400 の進捗

Raspberry Pi 400用のディスプレイを組み立てました。

7.9" high resolution (1536 x 2048) IGZO LCD panel set for Raspberry Pi 400.

秋月の7.9インチ高精細（1536 x 2048）IGZO液晶パネルセットと組み立てケースです。変則的な解像度ですが、Raspberry Pi OSのScreen ConfigurationメニューからHDMI1への出力を選択して回転方向を変更したところ、問題なく表示できました。組立マニュアルに指示があるConfig.txtの編集を行う必要はありませんでした。Raspberry Pi OSも進化しているようです。

Pi 400はオーディオジャックを省略していますが、代わりに奢った2式のHDMIがディスプレイデータに加えてオーディオデータも出力します。液晶パネルセットは3.5mmオーディオ出力ジャックも備えます。これでようやくQuiskのモニタ音を聞くことが出来るようになりました。

ここで気づきがありました。スピーカアンプをRS-HFIQの後方の横に置いたところ、ケーブルをつないでいないのに大きなノック音を拾いました。USBからの5V供給のみで、13.8Vを供給していない状態でも発生します。RS-HFIQの後方のディジタル系統からノイズが放射されているようです。

本題です。今回は、IQバランス校正機能がQuiskにどのように実装されているかを調査しました。まず、ベースになっている理論を確認します。

IQバランス校正の理論

実装のベースになっている理論式を2003年発表の下記参考文献から拾いました。Webで検索すると、引用の多い基本文献であることが分かります。

Ellingson, S.W. Correcting IQ Imbalance in Direct Conversion Receivers; Virginia Polytechnic Institute and State University: Virginia, VA, USA, 2003; pp. 25–32.

校正式を（１）式の形に置くと、In-Phase信号に仮定した振幅誤差αと、Quadrature信号に仮定した位相誤差ψを同定することにより、（２）式が得られます。

直観的には、校正式は対角行列になるイメージがありましたが、回転する信号から位相誤差を分離する際に三角関数の加法定理を使うため、位相の校正には回転する正弦（In-Phase）と余弦（Quadrature）の両方が必要になります。

QuiskのIQバランス校正機能実装の調査

IQバランス校正データ

校正データは他の状態データ一式と共にQuisk初期化ファイル./quisk_init.jsonに保存され、Quisk起動時に毎回読み込まれます。Quisk終了時には毎回上書きされるようなので、適宜バックアップを取った方が安心かもしれません。

「bandAmplPhase」という名称の辞書型の校正データの構造を下記に示します。今回、試験作成した校正データを例に示しています。

Data structure of IQ balance calibration.

Pythonの辞書型とリスト型を入れ子にした複雑なデータ構造を取ります。なお、辞書型は名前で要素にアクセスし、リスト型はインデックスで要素にアクセスします。データ構造の解読結果は以下の通りです。

最初のVersion情報は、古い実装バージョンと整合を取るためのものではないかと思います。

その後に、バンド別の辞書型データが並びます、上図では40mバンドの例のみを示しています。

各バンドは、受信（QSD）用のIQバランス校正データの辞書と、送信（QSE）用のIQバランス校正データの辞書を含みます。上図では受信「rx」用の辞書の例のみを示しています。

受信用もしくは送信用のIQバランス校正データの辞書は、任意の数の校正点VFO周波数（LO周波数）データのリストを含みます。上図ではVFO＝7.020000MHzの例のみを示しています。

校正点VFO周波数（LO周波数）データのリストには、さらに任意の数の校正点データセットのリストが付属します。上図は4つの校正点データセットのリストを示しています。校正点データセットのリストの要素は、①オフセット周波数、②振幅校正パラメータ（α）、③位相校正パラメータ（ψ）の3つです。

IQバランス校正GUIのボタンとコールバック関数

IQバランス校正パネルの各GUIボタンのコールバック関数の役割を調べました。

GUI buttons on the IQ balance calibration screen.

1. Save - コールバック関数：OnBtnSave()
   校正データをファイルに保存するボタンと思いましたが、ファイルへの保存はこの時点では行いません。校正データは、Quisk終了時に他の状態データ一式と共に ./quisk_init.json に保存されます。このコールバック関数では、グローバル変数のbandAmplPhase辞書への校正データの登録とソートを校正点毎に逐次行います。
   
   
2. Destroy VFO - コールバック関数：OnBtnDestroyVFO()
   現在のVFO（LO）周波数の校正データのみを破棄します。
   
   
3. Destroy ALL - コールバック関数：OnBtnDestroyALL()
   現在のバンドの校正データを全て破棄します。過去のデータもQuisk立ち上げ時に読み込まれています。破棄してからQuiskを閉じると、過去のデータも破棄した状態が新たに保存されるため注意が必要です。
   
   
4. Finished - コールバック関数：OnBtnFinished()
   校正データをQuiskにセットして、IQバランス校正パネルを閉じます。
   
   
5. Help - コールバック関数：OnBtnHelp()

　　下記内容のヘルプを表示します。

The "VFO" is the frequency at the center of the graph screen. The Rx or Tx frequency is the offset from the VFO.Adjust the VFO and the frequency as desired.  Then adjust the sliders to minimize the image. Press "Save" when satisfied. To adjust the VFO, use the band Up/Down buttons, or right click the graph at the desired VFO. Adjustments must be made for both receive and transmit on each band. The maximum slider adjustment range can be changed on the radio Hardware screen.

The other buttons will delete the data for the current VFO, or for the whole band. For more information, press the main "Help" button, then "Documentation", then "SoftRock".

訳はこんな感じでしょうか。

「VFO」は、グラフ画面中央の周波数です。RxまたはTxの周波数は、VFOからのオフセットです。VFOと周波数を任意に調整します。次にスライダーを調節してイメージを最小化します。満足したら "Save "を押してください。VFOを調整するには、バンドのUp/Downボタンを使うか、希望のVFOのところでグラフを右クリックします。調整は、各バンドの受信と送信の両方で行う必要があります。スライダーの最大調整幅は、無線機ハードウェアの画面で変更することができます。

その他のボタンは、現在のVFOのデータ、またはバンド全体のデータを削除します。詳しくは、メインの「ヘルプ」ボタン、「ドキュメント」、「SoftRock」の順で押してください。

スライダー位置変更イベントに呼応した関数呼び出し関係

振幅と位相のスライダー位置変更イベントによってコールバックされる関数の呼び出し関係をまとめます。

Function call relationship for IQ balance change events.

Quiskの設定機能をまとめたConfig.pyファイルの中に、IQバランス校正ボタンのコールバック関数OnBtnPhase()が定義されています。この関数は校正ボタンのクリックによって、IQバランス校正クラスQAdjustPhase()をインスタンス化し、校正パネルを表示した後、ユーザーイベント待機状態になります。

スライダーの位置が変更されるとコールバック関数OnChange()が呼ばれ、その関数の中で振幅と位相の校正パラメータを更新設定するset_ampl_phase()関数が実行されます。

QuiskのC言語関数実装部分をまとめたquisk.cファイルの中で、Pythonのset_ampl_phase()関数はC言語のquisk_set_ampl_phase()関数に翻訳され、コールされます。

このquisk_set_ampl_phase()関数はオーディオ信号処理関数をまとめたsound.cファイルに定義されています。上図では受信経路の説明を示しています。Captureデバイス（サウンドカードのマイク入力）の構造体に、上記理論式（１）および（２）のIQバランス校正行列の要素を設定しています。変数AmPhAAAA、AmPhBBBB、AmPhCCCCが理論式（１）の行列要素A、B、Cにそれぞれ該当します。同時に、校正適用指示フラグdoAmplPhase をONに設定しています。また、位相校正データの単位をradに変換しているため、逆に元の単位はdeg（度）であることが分かります。RS-HFIQの実績では、分度器半目盛から1目盛り程度の補正は必要ということになります。

一方、ユーザイベント処理とは並列に、所定のサンプリング周期（= 44.8KHz x バッファサイズ）でオーディオ信号を読み込むquisk_read_sound()関数が実行されます。オーディオ信号を読み込んだ後に、校正適用指示フラグdoAmplPhaseがONであれば、correct_sample()関数をコールしています。correct_sample()関数は、複素数型のIQサンプルデータに対して上記理論式（２）の校正計算を適用しています。

以上で、校正式の設定と適用の関係が判明しました。

校正終了ボタンのイベントに呼応した関数呼び出し関係

 IQバランス校正時の校正式の設定と適用の関係は判明しましたが、通常運用時はどうしているのでしょうか。通常運用時は、離散的に設定した校正点で必ずしも運用する訳ではないことから、校正データの補間が必要になります。例えば、周波数はいつでも変更できてしまうため、校正終了時に既に周波数が校正点から変更されている可能性があります。そのため、校正を終了するFinishedボタンを押下した際に、必要に応じて校正データの補間処理が走ります。

Finishedボタンのコールバック関数OnBtnFinished()から呼ばれる関数の呼び出し関係を以下にまとめます。

Calibration data interpolation process at the end of IQ balance calibration.

OnBtnFinished()関数内では2つの関数をコールしています。校正データから振幅と位相の校正パラメータを取得するGetAmplPhase()関数と、振幅と位相の校正パラメータを更新設定するset_ampl_phase()関数です。後者の関数は前節で説明しました。

GetAmplPhase()関数は、Pythonで記述したquisk.pyの中のアプリクラスの関数として実装されています。大別すると、以下の2つの処理を行っています。（1）運用周波数近傍の校正データ探索、および（2）校正点データの線形補間です。

（1）運用周波数近傍の校正データ探索では、SearchFreqAmPh()関数を用いて、2段階の探索を行っています。（1-1）運用VFO周波数近傍の校正点VFO周波数の探索、および（1-2）校正点VFO周波数のオフセット周波数を含む校正データの探索です。Quisk SDRでは、VFO周波数の設定（連続可変、離散可変、あるいは固定）はハードウェアに依存します。IQバランスの校正を行ったVFO周波数で運用するとは限らないことから、まず（1-1）で運用VFO周波数近傍の校正点VFO周波数を探索しています。次に、見つかった校正点VFO周波数の中身を（1-2）で探索して、近傍の校正点オフセット周波数を含む校正点データセットを抽出しています。

CWの場合はオフセット周波数をトーン周波数と考えれば良いのですが、SDRの場合は一般的にトーン周波数を任意に変更できるようになっています。校正点とは異なるトーン周波数に変更するために、（2）校正点データの線形補間が必要になります。ここでは、（2-1）校正データの取得と（2-2）運用周波数における校正データの線形補間の2つの処理を行っています。上図では、運用オフセット周波数Freq0が校正点オフセット周波数freq2とfreq1の間にある場合の線形補間処理の例を示しています。他に、VFO周波数も異なる場合や、校正点周波数データが1つしかない場合等の多様な場合に対応するコードが実装されています。

IQバランス校正終了時を例にして校正データの補間処理を説明しましたが、周波数を変更する毎に校正データの補間による校正適用の処理が走ります。

QuiskのIQバランス校正のテスト

校正の試行

IQバランス校正の試行を行いました。前節のデータの構造の説明で示した校正データは、この試行で得た実データです。

受信周波数を7019500Hz（VFO＝7020000Hz、Offset＝-500Hz）とし、7020500HzのBIT信号を入力した場合のIQバランス校正前のイメージ信号を下記に示します。BIT信号に対して、イメージ抑圧は-38dBcに留まっています。

The image signal before IQ balance calibration when the receive frequency is set to 7019500 Hz (VFO = 7020000 Hz, Offset = -500 Hz) and a 7020500 Hz BIT signal is input.

IQバランス校正後のイメージ信号を下記に示します。イメージ信号はノイズフロアに到達し、-78dBc以下に抑圧されています。ここで、Saveボタンをクリックして校正データを登録します。

Image signal after IQ balance calibration when the receive frequency is set to 7019500 Hz (VFO = 7020000 Hz, Offset = -500 Hz) and a 7020500 Hz BIT signal is input.

続いて、受信周波数を7018500Hz（VFO＝7020000Hz、Offset＝-1500Hz）とし、7021500HzのBIT信号を入力した場合のIQバランス校正を行い、Saveしました。その結果を下記に示します。

Image signal after IQ balance calibration when the receive frequency is set to 7018500 Hz (VFO = 7020000 Hz, Offset = -1500 Hz) and a 7021500 Hz BIT signal is input.

サイドを反転し、受信周波数を7020500Hz（VFO＝7020000Hz、Offset＝500Hz）とし、7019500HzのBIT信号を入力した場合のIQバランス校正を行い、Saveしました。その結果を下記に示します。

Image signal after IQ balance calibration when the receive frequency is set to 7020500 Hz (VFO = 7020000 Hz, Offset = +500 Hz) and a 7019500 Hz BIT signal is input.

続いて、受信周波数を7021500Hz（VFO＝7020000Hz、Offset＝1500Hz）とし、7018500HzのBIT信号を入力した場合のIQバランス校正を行い、Saveしました。その結果を下記に示します。

Image signal after IQ balance calibration when the receive frequency is set to 7021500 Hz (VFO = 7020000 Hz, Offset = +1500 Hz) and a 7018500 Hz BIT signal is input.

今回のIQバランス校正の試行における校正点数は少ないのですが、気付きは以下の通りです。

• 振幅誤差（α）はVFO周波数に対してサイドが変わると符号が反転（LSB側が負でUSB側が正）
• 振幅誤差（α）はVFO周波数に近い方が値が大
• 位相誤差（ψ）はVFO周波数に対して両サイドで符号は正
• 位相誤差（ψ）はVFO周波数に近い方が値が大

校正の再現と補間効果の確認

Quiskを一旦閉じると、登録した校正データが初期化ファイル./quisk_init.jsonに保存されます。Quiskを再立ち上げすると、校正データがファイルから読み込まれてIQバランス校正が常に適用された状態になります。その確認を行いました。

まず、LSB側の校正点における再現性を確認しました。受信周波数を7019500Hz（VFO＝7020000Hz、Offset＝-500Hz）にした場合と、7018500Hz（VFO＝7020000Hz、Offset＝-1500Hz）にした場合のIQバランス校正の再現性を、それぞれ下記の上段と下段に示します。イメージ信号はノイズと区別がつきませんが、-70dBc以下に抑圧されています。

Reproducibility of IQ balance calibration when the receive frequency is set to 7019500 Hz (top row) and 7018500 Hz (bottom row).

次に、校正を行っていない受信周波数7018000Hz（VFO＝7020000Hz、Offset＝-1000Hz）における結果を下記に示します。校正パラメータの線形補間機能が働き、イメージ信号は-70dBc以下に抑圧されています。

Effect of the calibration interpolation function at a receive frequency of 7018000 Hz (VFO = 7020000 Hz, Offset = -1000 Hz) without IQ balance calibration.

続いて、USB側の校正点における再現性を確認しました。受信周波数を7020500Hz（VFO＝7020000Hz、Offset＝+500Hz）にした場合と、7021500Hz（VFO＝7020000Hz、Offset＝+1500Hz）にした場合のIQバランス校正の再現性を、それぞれ下記の上段と下段に示します。USB側のイメージ信号も-70dBc以下に抑圧されています。

Reproducibility of IQ balance calibration when the receive frequency is set to 7020500 Hz (top row) and 7021500 Hz (bottom row).

次に、USB側で校正を行っていない受信周波数7021000Hz（VFO＝7020000Hz、Offset＝+1000Hz）における結果を下記に示します。校正パラメータの線形補間機能が働いているはずですが、イメージ信号の抑圧は-50dBc以下に留まりました。

Effect of the calibration interpolation function at a receive frequency of 7021000 Hz (VFO = 7020000 Hz, Offset = +1000 Hz) without IQ balance calibration.

理由は精査が必要ですが、下記の可能性を考えています。

• 線形補間が間に合わない非線形回路現象の発生
• 線形補間コードの不具合

ダイレクトコンバージョン方式のSDRでは、アナログ回路の均衡誤差を補償するために、IQバランス校正が必須であることが分かりました。製造ラインでこのような校正を行うことは煩雑で製造コストを押し上げてしまうため、SDR方式の市販無線機の大半が高速ADCやFPGAが必要なダイレクトサンプリング方式である理由を納得できました。

IQバランス校正は4次元パラメータ空間（VFO周波数、オフセット周波数、振幅校正パラメータ、位相校正パラメータ）の探索になるため、自動化したいところです。自動化を検討するためには、次にスペクトルデータの取得が必要です。QuiskではGUIにスペクトルを描画しているため、Pythonのどこかの変数に入っているのではないかと期待しています。

室内ロングワイヤーアンテナはSWR1.0の夢を見るか

結論

HF Low-Band（3.5MHz帯）からHF High-Band（28MHz帯）まで、加えて50MHz帯で、SWRは1.5以下の実用域に落ちました。バンドによってはSWR1.0を達成しました。

動機

アパマンハムには、安全性、景観適合性（ステルス性）、電波障害などのリスク要因があり、特にHFオールバンドでの運用を目指すとリスクが大きくなります。

近年は、カーボン釣り竿＋ATUの可能性が開拓され、アパマンハムにもHFオールバンド運用の道が切り開かれてきたように思われます。しかし、拙宅では釣り竿のリスク要因をクリアできません。

そこで、室内ロングワイヤー＋ATUの可能性を探ることにしました。室内モービルホイップでも多くを望まなければ交信は不可能ではないため、ロングワイヤーの可能性もゼロではないと考えた次第です。

実験システム

環境という最大の不確定要素を他の要素と切り分けるため、今回の実験資材は全て既製品で揃えました。

1. ロングワイヤーエレメント
   8m　（CQオーム、WAH-705）
2. ラジアル線
   5m×5本　（CQオーム、OHM-CGW55M）
3. ATU
   AH-705
4. トランシーバ & SWR測定器
   IC-705

一般的に集合住宅で最も眺望が良い部屋は居間です。光が差し込む窓が大きいということは、同じ電磁波の電波も飛びやすいのではないかと期待させます。そこで、拙宅では居間のダイニングテーブルへの宅内移動が運用スタイルになっています。ロングワイヤーエレメントは居間の窓に張り付けることにしました。

Installation of indoor long-wire antenna.

居間の窓が大きいと言っても、8mのロングワイヤーエレメントをそのまま展開する幅はありません。そこで、弛みを入れて5.5mを水平展開し、90度折り曲げて1.0m水平展開し、残りの1.5mをダイニングテーブル上のAH-705までの引き込み線としました。

窓には約1m間隔でアルミサッシの支柱が入っています。その支柱にワイヤーをガムテープで張り付けて仮設しました。室内仮設では、アンテナがアルミと鉄筋の籠の中に囚われているような形になりますが、波の性質を利用して滲み出てくれることを期待しました。

ラジアル線5本を散開すると宅内景観条例（不文律）にひかかるため、まとめて床に放置しました。床のフローリングは鉄筋と距離があるため、静電結合は期待できず、カウンターポイズには成り得ていないと思われます。

CQ誌2023年2月号掲載のJG1UNE小暮OMの寄稿「ATUの基礎知識とその活用法」には「ラジアル線を浮かせる」効能が述べられています。また、他の方のBlogにもラジアル線を浮かせることでSWRが下がったとの報告があります。フローリング床の効能は意外に大きいのかもしれません。逆に、下手に躯体アースに落とすと、電波の鳥籠に鍵が掛かってしまうかもしれません。

SWR測定

HF Low-Band（160/80/40/30m）

SWR measurement results for HF low band.

160mバンドには整合しませんでした。8mのロングワイヤーエレメントの仕様通りです。

80mバンドのSWRは1.3程度に落ち、実用域に整合しました。チューニングポイントに谷があるのではなく、周波数が高くなるとSWRが増加する比例関係があります。高めの周波数ポイントでチューニングするのが良いかもしれません。

40mバンドのSWRは1.1以下です。80mと同様に、周波数とSWRに比例関係があります。

30mバンドのSWRはポイント測定になってしまいました。こちらも1.1以下です。

HF High-Band（20/17/15/12/10m）and 6m

SWR measurement results for HF high band and 6m band.

20mバンドのSWRはチューニングポイントで1.1程度、最大でも1.2程度になりました。唯一、チューニングポイントでSWRが最小になる谷の様相を示しました。5mのラジアル線が1/4波長になるのは20mバンドです。その関係が作用しているのでしょうか。

17mバンドのSWRも1.2以下になりました。短縮率を考えると、8mのエレメントでは最も危険なバンドと思いますが、問題ありませんでした。Low-Bandとは逆に、周波数が高くなるとSWRが減少する負の比例関係になりました。低めの周波数ポイントでチューニングするのが良いかもしれません。

15mバンドのSWRも1.2以下になりました。17mバンドと同様に、周波数とSWRに負の比例関係があります。

12mバンドのSWRは1.4程度になりました。160mバンドより整合が難しいようです。それでも、SWR1.5以下の運用可能なレベルになっています。

10mバンドのSWRは1.0です。

6mバンドのSWRも1.0です。

SWR測定のまとめ

屋外で垂直にワイヤーを設置して良好なアースを確保した場合に、8mのロングワイヤーとATUの組み合わせにより、3.5MHz（80m）以上のHFバンドで整合可能という想定でした。

これに対して、室内で水平にワイヤーを架設し、丸めたラジアルを床に置いただけでも、3.5MHz（80m）以上のHFバンドで整合可能という結果になりました。期待以上です。

交信実績

インピーダンスのマッチングがアンテナの放射効率を保証してくれるわけではありません。放射効率を定量的に測定する手段は持ち合わせていないため、交信実績で評価することにしました。

アンテナ仮設からの4日間で行ったCW交信実績を下表に示します。運用は週末だけです。合計47QSOでした。タイミングよく後半の2日間にARRL DX CWコンテストがあったため、DXの交信実績が伸びました。JAの実績積み上げはALL JAコンテストを待つ必要がありそうです。

CW QSO results by band for 4 days with indoor long-wire antenna.

最下行のDX Zone 31はハワイです。アンテナを仮設した初日と翌日にCQを連呼していたARRL記念局W1AW/KH6と交信できました。2023年はVOTA（Volunteers On the Air）記念局として運用されているようです。初日が15mバンド、翌日が20mバンドです。自局の電波の弱さ（による相手局のコーピーミス）を上手くカバーする技量が無いため、交信が成立しているかどうか心配でしたが、LoTWでコンファームできました。それなりの強度の電波が飛んで行ってくれたようです。

Confirmed two QSOs by LoTW with ARRL memorial station W1AW/KH6 in Hawaii.

これで自信がつき、ハワイと交信できるなら西海岸とも・・・と思い、ARRL DX CWコンテストに初参加しました。DX Zone 3は北米西海岸、4は中部、5は東海岸です。

ARRL DX CWコンテストの結果を下記に示します。左のCTESTWINによる自己採点結果から、コピーミスマネージメントに失敗した分が減点されていくと思います。10Wのコンテストナンバーが珍しいのか何回か問い合わせを受けましたが、こちらの返答が正確に伝わっていないかもしれません。電波が弱いほどコピーミスマネージメントが重要と思いました。

右に交信数の時系列推移を示します。コンテスト初日は朝寝坊で出遅れましたが、翌日は早起きをして交信実績を積み上げました。北米に日が沈む昼で終了し、昼食に明け渡すためにダイニングテーブルから撤収しました。

Self-scoring for the ARRL DX CW contest.

残念ながら、DX Zone 5の北米東海岸の局とは交信できませんでした。パイルを避けてCQ連呼の局を呼ぶ運用スタイルですが、CQを出している東海岸の局を見つけられませんでした。五大湖の下のイリノイ州およびインディアナ州までは届いたのですが。

大圏地図（例えばCQ誌付録DX WORLD ATLAS pp.16-17）でショートパスを考えると、西海岸と東海岸で著しく距離が異なるという感じはしません。西海岸の局からは海面反射で届くのに対して、東海岸の局からは北米大陸、アラスカ、カムチャツカと地表反射で届くことが原因でしょうか。

コンテスト2日目の正午前に10mバンドでPT9（ブラジル）がRST579で強く入感しました。コンテスト参加局だったため、こちらから呼ぶことはできませんでしたが、交信の可能性を感じました。PT9を呼ぶWの局も聞こえていましたが、PT9には聞こえていないようでした。南米日没時のE層反射の不思議な伝搬を体験することができました。

今後の課題

室内ロングワイヤーアンテナには十分なポテンシャルがあることが分かりました。ガムテープによる仮設ワイヤーは既に剥がれて脱落しかけているため、永続的な架設方法を考えたいと思います。

交信実績が無いバンドは、80m、12m、6mだけとなりました。6mバンドは開局時の思い出深いバンドです。当時はTR-1300（5W）と5エレ八木の組み合わせでしたが、ワイヤーアンテナとIC-705（10W）の組み合わせでどこまで交信できるか、夏場のEスポ時に期待したいと思います。

室内ロングワイヤーアンテナは安全性と景観適合性のリスクを100%クリアーしています。残るリスクは電波障害です。今のところ電気機器に問題は生じていませんが、コモンモード電流の測定などを検討したいと思います。

RS-HFIQ（13）Quisk IQバランス校正（１）

動機

RS-HFIQのBIT（内臓テスト）機能をQuiskに実装した動機はIQバランスの校正です。ダイレクトコンバージョン方式のSDRの場合は、送信も受信もアナログ回路の部品公差の管理だけでイメージ抑圧を達成するのは困難であり、IQバランスの校正が性能を左右します。

RS-HFIQの場合、アナログ回路の調整箇所はありません。IQバランスの校正はSDRソフトウェア側で対応する必要があります。ソフトウェアの方がアナログ回路よりも柔軟な校正ができるはずです。

QCX振り返り

ここで、IQバランスの校正を既に経験したQCX+ 5W CW transceiver kitを振り返るのも、アナログTransceiverとSDRの比較という観点で有益と思います。

QCX+ 5W CW transceiver kit

QRP Labs社のQCXはマイコン制御のアナログCW Transceiverですが、受信部にはQSD（直交検波器）を採用し、RF信号をAFトーン信号にダイレクトコンバージョンしています。受信IQオーディオ信号の合成によるイメージ抑圧は、オペアンプによるアナログ位相シフトと加算で実現しています。

Block diagram of QCX+ with IQ balance adjustment points commented in light blue.

位相シフタ回路には可変抵抗による2ヵ所の位相シフト調整箇所があり、CWフィルタ回路の加算入力部にも可変抵抗による振幅バランス調整箇所が設けられています。位相シフト調整箇所が2ヵ所設けられている理由は、オーディオ周波数の高域と低域の調整に対応するためです。

下記NA5Y局OMのYouTube（6:00頃から）にオシロスコープを用いたQCX（初期機種）のIQバランス校正のデモがあり、QCX+組立時に参考にさせて頂きました。

www.youtube.com

QCXのソフトウェアはQRP Labs社の非公開IPとなるため詳細は不明ですが、Si5351Aを活用したBIT機能が組み込まれており、マニュアルに従って操作すればIQバランスの校正を行うことが出来ました。もしBIT機能が無かったとしたら、イメージ抑圧の性能はかなり劣化したのではないかと想像されます。

QuiskのIQバランス校正

校正対象範囲

QCXで振り返ったように、IQバランスの校正はオーディオ周波数帯域の全域で行う必要があります。さらに、Quiskのドキュメント「Quadrature Mixer Corrections」には、各バンド個別にバンド周波数全域で行う必要がある旨の記載があります。

さすがに全域で校正データを隈なく収集することは困難なため、Quiskには校正線の補間機能が実装されているようです。要所を数点校正すればSaveしたデータから校正データを補間してくれるようです。

QCXの場合は高域と低域を調整すれば、アナログ回路の連続特性からオーディオ周波数全域の校正をカバーできました。一方、Quisk SDRはディジタル補間によって同様の全域校正を実現していることになります。

校正方法

受信模擬信号を生成可能なRS-HFIQ BIT機能の制御パネルをQuiskに実装したため、少なくとも受信部については自動校正が最終目標です。

一方、QuiskにはGUIのスライダを用いたIQバランス手動調整機能が提供されています。まず、その機能を用いて校正を試行し、感度を体感することにしました。

校正画面呼び出し

Procedure for opening the IQ balance calibration screen.

①Configボタンのクリック、②Configタブのクリック、③Rx Phase..ボタンのクリックで、受信IQバランス校正画面が開きます（下図参照）。送信IQバランス校正画面はその下のボタンで開きます。

USB側BIT信号注入

VFO（LO）= 7,020KHzに対してUSB側に7,021KHzのBIT信号を注入しました。IQバランス校正前の状態を下記に示します。

Image signal status before IQ balance calibration when a BIT signal of 7,021 KHz on the USB side is injected against VFO 7,020 KHz.

VFO = 7,020KHzを挟んで逆サイドのLSB側にイメージが認められ、その強度は約-40dBcになります。ノイズレベル-90dB（-70dBc）に対して十分大きな信号強度になります。

なお、第3高調波、第7高調波、第11高調波も認められます。これらはイメージを抑圧しても存在することから、イメージ信号の高調波ではないことが確認できました。Si5351Aが発生するBIT信号が矩形波であることに起因して、どこからか回り込んでいるのではいかと考えています。奇数次が全て発生していない理由は不明です。

上記画像の下側のパネルがIQバランス校正用画面です。スライダーが4本あり、全て中央位置に初期化されています。上から、（A1）振幅精密調整、（A2）振幅粗調整、（P1）位相精密調整、（P2）位相粗調整の各スライダーです。これらのスライダーを動かしてイメージ抑圧を図りました。

USB側BIT信号のLSB側イメージ抑圧の試行

（A2）振幅粗調整、（P2）位相粗調整、（A1）振幅精密調整、（P1）位相精密調整の順番にスライダーを操作してイメージ抑圧を図りました。合理的な校正GUIであることが体感できました。

Image signal status after IQ balance calibration when a BIT signal of 7,021 KHz on the USB side is injected against VFO 7,020 KHz.

イメージをノイズフロアから時々頭を出すレベル-85dB（-70dBc）にまで抑圧できました。振幅の補正量は-0.008030、位相の補正量は0.678354（単位不詳）でした。

高調波の強度は-50dBc以下ですが、イメージ信号の強度変化とは関係なく、そのままの強度で残っていることが確認できます。

LSB側BIT信号注入

そのままの状態で、VFO（LO）= 7,020KHzに対してLSB側に7,019KHzのBIT信号を注入しました。IQバランス校正前の状態を下記に示します。

Image signal status before IQ balance calibration when a BIT signal of 7,019 KHz on the LSB side is injected against VFO 7,020 KHz.

VFO = 7,020KHzを挟んで逆サイドのUSB側にイメージが認められ、その強度は約-32dBcになります。前記のLSB側のIQバランス校正はUSB側に対しては効果が無い、あるいは逆効果をもたらしていることになります。

LSB側BIT信号のUSB側イメージ抑圧の試行

Image signal status after IQ balance calibration when a BIT signal of 7,019 KHz on the LSB side is injected against VFO 7,020 KHz.

LSB側と同様に、USB側もイメージをノイズフロアから時々頭を出すレベル-85dB（-70dBc）にまで抑圧できました。振幅の補正量は0.022506（LSB側-0.008030）、位相の補正量は0.591768（LSB側0.678354）でした。

USB側の位相の補正量はLSB側に対して13%の違いに留まりますが、振幅の補正量は符号が逆転していることがわかります。1セットの補正量では両サイドに対応できないことが確認できました。

USB側BIT信号再注入

Image signal status after reverse side IQ balance calibration when a 7,021 KHz BIT signal is re-input on the USB side for a VFO of 7,020 KHz.

元に戻ってUSB側に7,021KHzにBIT信号を再注入すると、校正前よりも強度の大きい-36dBc（元は-40dBc）のイメージ信号が確認されました。振幅の補正量が望ましい値よりも逆側に調整されているためと思われます。

計画

以上の試行により、複数点でIQバランス校正を行い、各点で適切な校正を適用する必要があることが分かりました。

今後、Quiskの校正点記録方法、校正量補間方法を調査し、補間校正性能を評価したいと思います。

RS-HFIQ（12）Quisk（Linux版）設定（続）

Pi 400 SoC の追加調査

Raspberry Pi 400 は Pi 4Bと同じBroadcom社製SoCのBCM2711（Quad-core Cortex-A72 64-bit SoC）を搭載していますが、クロック周波数は異なっています。その理由は放熱板の有無と考えていたのですが、どうやら「Stepping level」が違うらしいということが分かりました。
「Stepping level」とは直訳では意味を捉え難い言葉ですが、意訳すると「露光マスク改訂番号」という意味合いになるようです。半導体ウェハ全面にステップ動作を反復して回路パターンを焼き付ける露光機をStepperと呼称していたことから来ているようです。ただし、現在の先端露光機は液浸Scanner、最先端露光機はEUV露光機ですので、言葉が時代に置いて行かれた感があります。プロセスルール28 nmとされるBCM2711はScannerで露光されていると推測します。

以下はWeb上の二次情報からの受け売りです。
Pi 400 と Pi 4B は同じSoC（BCM2711）を採用していますが、チップに刻印されたモデル番号を確認すると前者は2711ZPKFSB06C0T、後者は2711ZPKFSB06B0Tであったことが報告されています。後尾の「C0」と「B0」が Stepping level（～露光マスク改訂番号）とされています。最初のアルファベットがベース（トランジスタ）レベルの改訂番号、次の数値がメタル（配線）レベルの改訂番号とのこと。つまり、初期の Pi 4B に対してPi 400 はベース（トランジスタ）レベルを改訂した露光マスクで製造したSoCを搭載していることになります。
改訂の中身が問題になりますが、幾つかある中に「Power gating」（Clock gatingとする説もあり）が挙げられていました。使用していない回路への電力供給（あるいはクロック供給）をOFFにする機能です。チップ発熱の主な要因にトランジスタの漏れ電流（ゲートをLowにしても流れる電流）がありますので、使用していない回路への電力供給（あるいはクロック供給）をOFFにすればそれだけ発熱が減り、熱設計が容易になり、クロック周波数を上げられることにつながります。
ただし、Power gatingには制御回路が必要になると思われるため、メタル（配線）レベルが改訂されていないことが腑に落ちません。元々組み込まれていたPower gating機能がベース（トランジスタ）レベルの不具合によって上手く機能していなかったのに対して、改訂後に機能するようになった・・・ということでしょうか。

改訂前のSoCは在庫が捌け次第に市場から姿を消すと思われます。既に、Pi 4Bの箱を開けたら「C0」が載っていたという報告もあるようです。Raspberry Pi の製品型番が同じであればクロック周波数は変わらないと思いますが、放熱対策が容易になることやオーバークロックへの余力が増す利点があるかと思います。

RS-HFIQ BIT制御パネルの改良

方針

Linux版QuiskでBIT（内臓テスト）制御パネルを開くとIQサンプリングが完全に停止するという気付きがありました。そこで、BIT制御パネルを開く関数を呼ぶ際に並列プロセスを立ち上げて、Quiskメインパネルと並列に動作させることにしました。

Pythonのプロセスベースの並列処理ライブラリmultiprocessingには、並列プロセスを起動する次の3種類の方法がサポートされています。

1. spawn： Windows と macOS で標準、Unixでも利用可
2. fork： Unixで標準
3. forkserver： Unixで利用可

子プロセスのクラッシュを引き起こす可能性に対して、spawnの方がforkより安全であるとされています。そこで最初にspawnを試しましたが、RS-HFIQを制御するhardwareオブジェクトを子プロセスに引数として渡す際にエラーが発生したため、使用を断念しました。昔憧れた（MS-DOSや初期のWindowsには並列プロセスを生成する仕組みが無かった・・・）Unix標準のforkを使用することにしました。

実装

BIT制御ボタンの押下イベントに呼応するコールバック関数を実装したwidgets_rshfiq.pyファイルを改良します。

ファイルの先頭で並列処理ライブラリmultiprocessingをインポートします。

from multiprocessing import Process

BottomWidgetsクラスのコールバック関数OnBtnRSHFIQを、並列処理プロセスを起動するように書き換えます。

## callback function of the added button to open RS-HFIQ control panel.
def OnBtnRSHFIQ(self, event):
    print('OnBtnRSHFIQ() called back with event', event)
    #lib_rshfiq.control_panel(self.hardware)
    ## Process-based parallelism --------------------------------------
    p = Process(target=lib_rshfiq.control_panel, args=(self.hardware,))
    p.start()
    p.join(timeout=1)

lib_rshfiq.control_panelがBIT制御パネル用に作成したクラスのコンストラクタ関数、self.hardwareがRS-HFIQ制御オブジェクトです。このオブジェクトがシリアルポートを開いて保有しているため、BIT制御パネル関数に渡すことが必須です。
並列処理Process関数は明示的に並列プロセス起動方法を指定しなければ、Linux環境ではディフォルトでforkシステムコールを採用します。これによってQuiskプロセスから並列分岐し、p.startでBIT制御プロセスを開始します。p.joinで引数のtimeout=1秒だけ親プロセスをブロックし、1秒後に並列動作を開始します。
p.joinは不要かもしれませんが安全弁です。オブジェクトのステータスを更新するバックグラウンド機構のために必要とされているようです。

結果

Quisk (Linux version) test scene.

Test results for parallel processing of the RS-HFIQ built-in test control panel.

目論見通り、BIT制御パネルを起動してもQuiskのサンプリングプロセスが途切れることは無くなりました。BIT制御設定も即座にQuiskのスペクトルに反映されます。Windows環境で共有ライブラリのOmni-Rigを使用した場合と同じパーフォーマンスになりました。
気付きがありました。Quiskパネルの最下段左の「RSHFIQ」ボタンは、以前はBIT制御パネルを閉じるまで押下状態を維持していました。しかし、今回はプロセスの並列化によって、p.joinで指定した1秒後に押下可能な状態に復帰します。実際、複数のBIT制御パネルを起動することが出来てしまいました。ここは排他処理の仕組みを入れるべきかもしれません。

Raspberry Pi OS の Task Manegerで調べると、２つのPythonプロセス（図中のPID=1989とPID=2004）が起動していました。前者が親プロセス（Quiskパネル）で、後者が子プロセス（BIT制御パネル）です。前者のCPU使用率は11%、後者はBIT設定の待機状態のため0%でした。他のプロセスを合わせた合計でも19%であり、シングルコアで賄える処理内容となっています。Power gatingの恩恵によって、シングルコアのみに電力を供給し、他の3つのコアへの電力を遮断して発熱を抑えているものと思います。
Pi 400の能力には余力があるため、WSJT-Xも起動してマルチコアを使用する様子を見てみたいところです。WSJT-XとQuiskの接続設定はこれからの課題です。

電鍵シリアル接続ケーブルの本組

工作

A1 CLUBの「CW HANDBOOK」（pp.52-53）に紹介のある「DitDah-ChatをやるためのUSBシリアル・ケーブルの作成方法」を参考に、電鍵をPC上のQuisk SDRに接続するためのシリアルケーブルを作成しました。

BOM（部品構成表）を下記に示します。全て通販A社でそろえたため、CW HANDBOOK記載の参考価格より割高になってしまいました。

BOM for serial cable assembly to connect CW keyer to Quisk SDR on PC.

部品選定で秀逸な点は、電鍵を接続する3.5mmステレオジャックがD-SUBハウジングケースのケーブル引き出し穴の奥にあるネジボスの間に上手く嵌合する点です。実際はネジボスの間隔が少し狭いので、ハウジングケースをネジ締結する時の仮組に力を要します。ステレオジャックが付くことにより、既存の電鍵ケーブルの抜き差しが可能になります。

Wiring and assembly in the housing.

D-SUBコネクタの裏面に小さいモールドで端子番号が振ってあるため、確認して間違えないようにします。ステレオジャックも同様ですが、Tip/Ring/Sleeveの配線はKeyer側の回路に合わせます。

D-SUBのメス側コネクタにはオス側のネジを受けるスペーサを付ける必要がありますが、D-SUBハウジングケースには付属していませんでした。オスーメス両側がネジになってしまうため、適切なスペーサを何かのついでに調達する必要があります。もっとも、ネジで嵌合しなくても金属部分の嵌合だけで、アマ仕様としては十分な締結保持強度が出ました。

設定

USBデバイスを検索すると、CH340が2件検索されました。この情報だけでは区別がつきません。

$ lsusb
・・・
Bus 001 Device 007: ID 1a86:7523 QinHeng Electronics CH340 serial converter
・・・
Bus 001 Device 005: ID 1a86:7523 QinHeng Electronics CH340 serial converter
・・・

Linuxカーネルが起動時に出力したメッセージを調べました。ポート番号ttyUSB0とttyUSB1が割り当てられていますが、ここでも区別がつきません。搭載チップが同じだと区別がつかないことが分かりました。Quiskが正常起動するかどうかによって、ポート番号が正しいかどうかを判断するしかなさそうです。

$ dmesg
・・・
[    9.789245] usbcore: registered new interface driver ch341
[    9.789346] usbserial: USB Serial support registered for ch341-uart
・・・
[    9.789471] ch341 1-1.2.1:1.0: ch341-uart converter detected
[    9.843337] usb 1-1.2.1: ch341-uart converter now attached to ttyUSB0
・・・
[    9.843637] ch341 1-1.2.3:1.0: ch341-uart converter detected
[    9.853426] ch341-uart ttyUSB1: break control not supported, using simulated break
[    9.853676] usb 1-1.2.3: ch341-uart converter now attached to ttyUSB1
・・・

実は最初は、ttyUSB0がCW Key接続、ttyUSB1がRS-HFIQ接続になっていたため、ハブのポート位置を差し換えました。上記は差し換え後の状態です。ハブの物理的ポート位置と論理的ポート番号の間の法則は見いだせていません。経験上、法則は無いように見えます。

CW Key接続のポートttyUSB1について「break control not supported, using simulated break」と表示されている点が気になります。

試験

Windows版と同様にLinux版QuiskのCW設定を行い、USBシリアルのハンドシェイク信号のDTR-CTS間のループバックのON/OFF試験を行いました。結論として、Quiskは反応しませんでした。

落穂拾い

Windows版で実績のあるFTDI USBシリアル変換アダプター Rev.2 （スイッチサイエンス）に換えたところ、問題なく動作しました。Linux版Quiskの設定に問題はないことが切り分けられました。
こちらのUARTチップはFT231Xです。CH340（ch341-uart converter）チップのドライバのサポートに問題があるのでしょうか。同じチップを採用したRS-HFIQのAruduino Nanoとは問題なく通信できています。複数のCH340チップを同時には扱えないとなると厄介です。
上記メッセージ「break control not supported, using simulated break」を検索すると、同じ問題に直面した複数の人がいることが分かりました。Windowsでは問題なくてもLinuxで顕現することもあるようです。複数の異なる要因で当該メッセージが出る様子であり、簡単には要因を切り分けられそうにないことが分かりました。FTDI USBシリアル変換アダプタを使うことが簡単な解決方法になりそうです。

RS-HFIQ（11）Quisk（Linux版）設定

前回に引き続きRaspberry Pi 400上でQuiskを立ち上げます。

追加インストール

Linux標準装備のテキストエジッタだけでは心許ないため、Pi 400にVisual Studio Code（VSCode）をインストールしました。下記コマンドで簡単にインストールできました。

sudo apt install code

また、Windows PC上のVSCodeにRemote-SSH拡張を導入し、Pi 400のファイルを遠隔編集できるようにしました。VSCodeにこのような拡張機能があるとは知りませんでした。当面は、Pi 400ネイティブのVSCodeに出番は無いかもしれません。

Visual Studio Code on a Windows PC with SSH connection to Raspberry Pi 400.

Quiskのハードウェア設定

RS-HFIQ用ハードウェアファイルの転送

Pi 400にインストールしたQuiskのフォルダに、Windows PC上で検討してきたRS-HFIQ用のハードウェアファイルをまとめたフォルダを転送し、Linuxに適合させる修正を加えます。
フォルダrshfiqの中身は以下の3つのファイルです。

1. hardware_rshfiq.py：　RFフロントエンドのLOやPTTを制御するRS-HFIQ向け専用のCAT関数群
2. widgets_rshfiq.py：　RS-HFIQ専用のQuisk GUI拡張（内臓テスト機能用GUI）
3. lib_rshfiq.py：　内臓テスト機能用ライブラリ

USBデバイスの探索

RS-HFIQのシリアルCATおよびIQオーディオ信号はUSBでPi 400に接続します。Quiskに接続先を設定するためには、それらデバイスの番号あるいは名前を事前に調べる必要があります。

lsusb
ターミナル ウィンドウを起動して、まず、USBデバイスを検索しました。

$ lsusb
Bus 002 Device 002: ID 2109:0817 VIA Labs, Inc. USB3.0 Hub             
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 04d9:0007 Holtek Semiconductor, Inc. Raspberry Pi Internal Keyboard
Bus 001 Device 006: ID 1a86:7523 QinHeng Electronics CH340 serial converter
Bus 001 Device 005: ID 0d8c:8810 C-Media Electronics, Inc. USB Advanced Audio Device
Bus 001 Device 003: ID 2109:2817 VIA Labs, Inc. USB2.0 Hub             
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Pi 400内部の接続デバイスも、外部の接続デバイスも、論理的（電気的）には区別が無いため混在して出力されます。
Bus 002がUSB3.0、Bus 001がUSB2.0のようです。RS-HFIQ関連のUSB接続をまとめた外部ハブをPi 400のUSB3.0ポートに物理的に挿入したのですが、USB2.0のデバイスしかないためか論理的接続先はBus 001のUSB2.0になっているようです。
Bus 001のUSB2.0のデバイスはHubを除くと、下記の3つです。

1. Device 004：　Holtek Semiconductor, Inc. Raspberry Pi Internal Keyboard
2. Device 005：　C-Media Electronics, Inc. USB Advanced Audio Device
3. Device 006：　QinHeng Electronics CH340 serial converter

USB Sound CardにはHobbyPCB社推奨のStarTech社ICUSBAUDIO2Dを使用しています。StarTech社ホームページの技術仕様から、搭載しているチップセットは「Cmedia CM6533」であることが確認できます。Device 005は、StarTech社の名前ではなくUSBオーディオチップメーカの台湾C-Media社の名前で検索されていますが、USB Sound Cardと見て間違いないでしょう。問い合わせに応答するのは機器ではなくその中のチップになるため、搭載されているチップを把握しておく必要があります。
一方、RS-HFIQのコントローラであるArduino Nanoが搭載しているUSBチップは、ホームページの回路図からはFT232RLとなっていますが、検索したデバイスの中にFT232RLはありません。おそらく、RS-HFIQのArduino NanoはFT232RLの代わりにCH340を搭載した互換品なのでしょう。RS-HFIQのUSBシリアルデバイスはDevice 006と見て間違いないと思われます。
ちなみに、同じHobbyPCB社から先日購入したIQ KeyerのArduino Nanoのパッケージに添付されたバーコードを検索したところ、互換品のGeekcreit社のATmega328P Nano V3 Moduleが検索されたため、RS-HFIQも同様の互換品を採用しているものと推定されます。

dmesg
ここでdmesgにより、Linuxカーネルが起動時に出力したメッセージからRS-HFIQと接続するシリアルポート番号を調べます。

$ dmesg
（前略）
[   11.760118] usbcore: registered new interface driver usbserial_generic
[   11.760223] usbserial: USB Serial support registered for generic
[   11.772218] usbcore: registered new interface driver ch341
[   11.772305] usbserial: USB Serial support registered for ch341-uart
[   11.772448] ch341 1-1.2.3:1.0: ch341-uart converter detected
[   11.788004] usb 1-1.2.3: ch341-uart converter now attached to ttyUSB0
（後略）

usbserialとしてch341-uart converterが検出され、シリアルポート番号ttyUSB0が振られたことが確認できます。hardware_rshfiq.pyファイルのシリアルポート番号をttyUSB0に変更します。

serialport.port = "/dev/ttyUSB0"

これで、シリアルポートオープン試行のtry - except例外処理をクリアーして、Quiskが立ち上がるようになります。ここからは、Quisk上でのSound設定に移ります。

オーディオデバイスの探索

LinuxのSoundの扱いには不慣れです。LinuxのようなOSは、ユーザーアプリの1つが直接ハードウェアにアクセスすることを良しとしないため、デバイスドライバもしくはオーディオサーバを介してアクセスることになります。Quiskは、PulseAudio、PortAudio、または ALSA を使用してサウンド カードにアクセスできるとのこと。至れり尽くせりですが、選択肢の多さは初心者には混乱の元でもあります。

aplay -l
まず、再生デバイスのリストを検索しました。

$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: vc4hdmi0 [vc4-hdmi-0], device 0: MAI PCM i2s-hifi-0 [MAI PCM i2s-hifi-0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: vc4hdmi1 [vc4-hdmi-1], device 0: MAI PCM i2s-hifi-0 [MAI PCM i2s-hifi-0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 2: Device [USB Advanced Audio Device], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 2: Device [USB Advanced Audio Device], device 1: USB Audio [USB Audio #1]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

Pi 400は映像と共に音声も扱えるHDMIポートを2つ備えているため、card 0とcard 1はHDMIになっています。ちなみに、Pi 400ではオーディオジャックが廃されているため、音声出力はHDMIを利用するか、Sound Cardを追加する必要があります。
card 2が2つあり、USB Advanced Audio Deviceの名前を持つの2つのデバイス（device 0とdevice 1）があります。これがUSB Sound Cardで、片方が入力デバイス、もう片方が出力デバイスと思いますが、この時点では割り付けは不明です。

arecord -l
次に、録音デバイスのリストを検索しました。

$ arecord -l
**** List of CAPTURE Hardware Devices ****
card 2: Device [USB Advanced Audio Device], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

マイク入力用（QSD用）のデバイスは、card 2のdevice 0であろうとの当たりが付きました。ヘッドフォン出力用（QSE用）のデバイスは、残るcard 2のdevice 1ということになります。

cat /proc/asound/cards
次に、cardsファイルの中身を調べました。

$ cat /proc/asound/cards
 0 [vc4hdmi0       ]: vc4-hdmi - vc4-hdmi-0
                      vc4-hdmi-0
 1 [vc4hdmi1       ]: vc4-hdmi - vc4-hdmi-1
                      vc4-hdmi-1
 2 [Device         ]: USB-Audio - USB Advanced Audio Device
                      Speed Dragon USB Advanced Audio Device at usb-0000:01:00.0-1.2.2, full speed

有用な追加情報は得られませんでした。

python portaudio.py
次に、Quiskに附属するユーティリティプログラムportaudio.pyを用いて、使用可能な PortAudio 名のリストを検索しました。

$ python portaudio.py
（前略）
Version 1246720
Version Text b'PortAudio V19.6.0-devel, revision 396fe4b6699ae929d3a685b3ef8a7e97396139a4'
NumDev 4
Device  0, host api b'ALSA'
    Name b'USB Advanced Audio Device: Audio (hw:2,0)'
    Max inputs 2,  Max outputs 2
Expression 'ret' failed in 'src/hostapi/alsa/pa_linux_alsa.c', line: 1812
    Speeds for 2-channel paInt32:   44100   48000 
Device  1, host api b'ALSA'
    Name b'USB Advanced Audio Device: Audio #1 (hw:2,1)'
    Max inputs 0,  Max outputs 2
    Speeds for 2-channel paInt32:   44100   48000 
Device  2, host api b'ALSA'
    Name b'pulse'
    Max inputs 32,  Max outputs 32
    Speeds for 2-channel paInt32:   44100   48000   96000   192000 
Device  3, host api b'ALSA'
    Name b'default'
    Max inputs 32,  Max outputs 32
    Speeds for 2-channel paInt32:   44100   48000   96000   192000 
Close 0

Device 1「USB Advanced Audio Device: Audio #1 (hw:2,1)」がステレオ出力（Max inputs 0, Max outputs 2）、すなわちヘッドフォン出力用（QSE用）のデバイスであることが確認できました。残念ながら、Speedsは48KHzまでとなっています。96KHzはWindowsしかサポートしていないのかもしれません。
また、Device 0「USB Advanced Audio Device: Audio (hw:2,0)」がステレオ入力（Max inputs 2, Max outputs 2）、すなわちマイク入力用（QSD用）のデバイスであることも確認できます。ただし、Device 0がステレオ出力も備えていることは謎です。エラーも出ているようです。
StarTech社ICUSBAUDIO2Dに搭載されるC-Media社CM6533チップのブロック図を下記に示します。

Block diagram of C-Media CM6533 chip in StarTech ICUSBAUDIO2D.

このチップは入力から出力へのパススルー経路を持っていることが分かります。もしかしたら、このパススルー経路によってDevice 0が出力も備えていると認識されているのかもしれません。

QuiskのHardware設定

Quisk → Config → *RS-HFIQ* → Hardware設定画面にて、Hardware file path に hardware_rshfiq.py ファイルのパスを設定し、Widget file path に widgets_rshfiq.py ファイルのパスを設定します。

Hardware settings for Quisk.

QuiskのSound設定

Quisk → Config → *RS-HFIQ* → Sound設定画面にて、I/Q Rx Sample Input として「alsa: USB Advanced Audio Device USB Audio (hw:2,0)」をプルダウンから選択します。
また、I/Q Tx Sample Output として「alsa: USB Advanced Audio Device USB Audio #1 (hw:2,1)」をプルダウンから選択します。
注意点として、Rateは48000から変更しないようにします。試しに98000に変更したところ、Quiskがハングアップし、プロセスのKillもできなくなりました。

Sound settings for Quisk.

RS-HFIQ内臓テスト機能による受信テスト

RS-HFIQ内臓テスト機能も問題なくPi 400上で制御できました。

LO - 1KHz

LO（= 7020KHz）に対して、-1KHzの内臓テスト信号BIT（= 7019KHz）を発生させ、Quiskで受信しました。Windows版と同様に、約-40dBc（= -20 + 60 dB）のイメージが発生することが確認できました。

Receive test by Quisk with RS-HFIQ built-in test function (for LO - 1KHz).

LO + 1KHz

LO（= 7020KHz）に対して、+1KHzの内臓テスト信号BIT（= 7021KHz）を発生させ、Quiskで受信しました。Windows版と同様に、約-40dBc（= -20 + 60 dB）のイメージが発生することが確認できました。

Receive test by Quisk with RS-HFIQ built-in test function (for LO + 1KHz).

気付き

Windows版QuiskではBIT（Built-In Test）制御パネルを開いた状態でも間欠的にI/Qサンプリングが並列稼働しましたが、Linux版QuiskでBIT制御パネルを開くとI/Qサンプリングが完全に停止しました。BIT制御パネルで内臓テスト機能の設定を行った後にパネルを閉じると、I/Qサンプリングを再開しました。サンプリングが停止しているのか、あるいはGUIの更新が停止しているだけなのかは不明です。モニタ音を出力できるようになれば明確になると思います。
Windows版Quisk（96KHzサンプリング）よりLinux版Quisk（48KHzサンプリング）の方がLOノイズが小さくなりました。RS-HFIQ内部のQSDの前段にLNAがあるため、アンテナ（ダミーロード）からLOノイズが放射されているとは考え難く、RS-HFIQの筐体あるいはケーブルから放射されていたLOノイズが配置の変化によって小さくなっただけではないかと考えています。
サンプリング周波数が影響したかどうかは不明です。ただし、バンド両端の角状のアーティファクトは消えました。その理由も不明です。また、48KHzサンプリングの帯域は24KHz幅（例えば7008～7032KHz）になるはずですが、約40KHz幅（例えば7000～7040KHz）の帯域の平坦なノイズフロアが表示されます。ノイズだけでなく、7020KHzのLOに対して7000KHzのBIT信号を注入すると、信号強度を損なうことなく表示します。謎は深まるばかりです・・・。

今回はLinux版Quiskの受信テストまで行いました。次回は送信テストに進みたいと思います。

RS-HFIQ（10）Quisk（Linux版）立ち上げ

Raspberry Pi 400の立ち上げ

大型のWindows Desktop PCをSDR運用のために使用するのは宅内移動運用の点で不自由なため、Raspberry Piへの移行に着手しました。Raspberry Pi 4Bは供給が回復基調にあるようですが、まだまだ品薄のためか値段も高目で推移しているようです。もっとも、値段が高いのは円安のためかもしれませんが・・・。
今回はキーボード一体型のPi 400を選択しました。

www.raspberrypi.com

Pi 400のSoC（System on a Chip）はQuad-core Cortex-A72 (ARM v8) 64-bit SoC @ 1.8GHzを採用し、Raspberry Piシリーズの中では最高速クロックの設定になっています。キーボード下の大面積放熱板（重量があります）によって熱設計に余裕があることも寄与していると思います。Pi 400のメモリは4GBで、Raspberry Pi 4Bの最大8GBよりは少ない設定になります。それでも、今まで使用していたRaspberry Pi 3Bの1GBより大幅に増えています。

ここでまたケーブル非互換のトラブルが発生しました。USBのみならず、HDMIコネクタにもmicro、mini、normalの3トリオが存在しています。Raspberry Pi 3Bはnormal-HDMIメスコネクタでしたが、Pi 400はmicro-HDMIメスコネクタの2連装になっています。Pi 400のスターターキットにはmicroオス / normalオスの変換ケーブルが付いていましたが、これではRaspberry Pi 3Bをディスプレイに接続していたnormalオス / VGAメスの変換ケーブルと接続できません。microオス / VGAメスの変換ケーブルか、microオス / normalメスの変換ケーブルが必要になります。年越し中断です。

下記ブランドの変換ケーブルが新年に着荷。1920 X 1200の解像度で問題なく表示できました。

MicroHDMI(male) / VGA(female) conversion adapter.

ところが、VNCでリモート接続すると、最大1920 X 1080までしかディスプレイ設定の解像度選択肢がありませんでした。横より縦の解像度を増やしたいのですが、致し方なしです。

Display at 1920 X 1080 resolution via VNC connection.

WSJT-Xの導入

QuiskはWSJT-Xをサポートしています。CWと共にFT8等のディジタルモードの導入を検討することにしました。
最新のRaspberry Pi OS（Debian version: 11 bullseye）にWSJT-Xを導入するために、Pi 400の性能向上を頼りにソースコードからのビルドを試みました。下記のWeb pageの手順をトレースしたところ、問題なくビルドできました。

linuxhint.com

手順をまとめると以下になります。

1. Packages Listの更新
2. 必要なライブラリのインストール
3. ビルド用フォルダのセットアップ
4. WSJT-X 2.5.4ソースコード（wsjtx-2.5.4.tgz）のダウンロード
5. tar（Tape Archive）書庫の展開
6. WSJT-X 2.5.4のビルド

ビルドの途中で席を外したため、正確な時間は測っていません（戻ってきたら終了していました・・・）が、体感的には30-60分程度でしょうか。Pi 400の消費リソースを時々チェックしたところ、コンパイル中のCPU占有率は25%程度でリンクの時だけ100%に跳ね上がることがある様子でした。コンパイル作業はシングルコアで実行し、ファイル操作が必要なリンク作業はマルチコアに作業が分散しているようでした。メモリは1GBも使用していない様子で余裕がありました。SDカードのアクセス時間がビルド速度を律速しているのではないかと推測しています。WebブラウザのChromium（ChromeのOSS版）の動作も遅いため、Pi 400の性能を引き出すためにはSDカードをSSDに換装する必要があるかも知れません。
実行ファイル「wsjtx」は/usr/local/binに作られます。ビルド直後はメニューに登録されていませんでしたが、再立ち上げするとSound & Videoメニューに登録されました。そこから右クリックでデスクトップにアイコンを配置することも可能です。

Successful build of WSJT-X on the Pi 400.

Quiskのインストール

最新のRaspberry Pi OS（Debian version: 11 bullseye）にWSJT-Xを導入できたことから、OSをダウングレードする必要がなくなりました。このままQuiskのインストールに進みます。
なお、Pi 400のスターターキットに附属するSDカードに書き込み済みのRaspberry Pi OS（Debian version: 11 bullseye）のPythonはディフォルトでPython3でしたので、インストール時に明示的にPython3を指定する必要はありませんでした。

Step 1: Install Required Libraries and Dependencies

Quiskのドキュメントに従い、下記のコマンドで必要なライブラリをインストールしました。

sudo apt-get install libfftw3-dev
sudo apt-get install libasound2-dev
sudo apt-get install portaudio19-dev
sudo apt-get install libpulse-dev
sudo apt-get install python3-dev
sudo apt-get install libpython3-dev
sudo apt-get install python3-wxgtk4.0
sudo apt-get install python3-usb
sudo apt-get install python3-setuptools
sudo apt-get install python3-pip

libfftw3-devライブラリ（Discrete fourier transform）はWSJT-Xのビルド時にインストールしています。他も大多数は最新版をインストール済みでした。実際にインストールが必要だったライブラリは下記の3つです。

• portaudio19-dev　（Portaudio sound library）
• python3-wxgtk4.0　（wxPython GUI library）
• python3-usb　（Python USB）

Step 2: Linux Source Installation

Quiskの学びの過程でCのソースコードにもアクセスする必要があるため、Quiskもソースコードからビルドしました。ソースファイルの書庫quisk-4.2.14.tar.gzをダウンロードして、下記コマンドでビルドしました。

cd ~/Downloads
tar zxf quisk-4.2.14.tar.gz
cd quisk-4.2.14
make quisk3

問題なくビルドが完了し、Pythonコードからコールする下記の共有ライブラリが作成されました。

_quisk.cpython-39-arm-linux-gnueabihf.so

Completion of Quisk build from source files.

Quisk起動

ディレクトリを移して起動テストを行いました。Windowsと同じ画面が立ち上がりましたが、細部の描写表現が少し異なるようです。

cd /home/amat/quisk
python quisk.py

Quisk (Linux version) startup.

今回はWSJT-XとQuiskのビルドまで実行しました。次回、設定に進みたいと思います。

RS-HFIQ（９）初荷 IQ Keyer

迎春

2023年元旦も雲一つない快晴で富士山が良く見えていました。

Mt. Fuji under clear skies on New Year's Day.

1年前の元旦を振り返ると、13TR-FT8トランシーバ の組立が完了し、保証願書を作成していた頃でした。これとAFP-FSK Transceiver Kitを通して、2022年はFT8の学びが進んだ年でした。
（とは言っても、FT8プロトコルの詳細については積み残しが残っています。新たな学習マテリアルの目星が付いたため、時期を見て再開したいと思います。）
jk1ejp.hatenablog.com

今年はダイレクトコンバージョン方式の送受信SDR（CW、FT8）の学びを完遂することが当面の目標です。非職業的活動（趣味）であることから、目標期日の設定が無いことが良いところです。

初荷

品物

HobbyPCB社のIQ Keyer（Kit）が届きました。SDRのCW送信用のIQオーディオ信号を生成するKeyerです。現在検討中のQuisk SDRおよびTeensy Keith's SDRにおけるCW送信方式のプランBとして購入しました。

Packaging.

Half-finished kit of the contents of the box.

部品はコネクタも含めてPCBにはんだ付けされていました。必要な残作業はAruduino Nanoのはんだ付けとケース組み立てぐらいのようです。ケースパネルとの寸法関係で、Aruduino NanoはPCBへの直付けが必要なようです。
PCBの手前のスペースが大きく空いており、メッセージメモリのボタンを追加できるようです。ケース（カナダ製でした）を決めてから、PCBを設計した結果かもしれません。

輸送実績

HobbyPCB社のホームページは、晩秋になっても長い夏季休暇による不在を表示していましたが、注文は受け付けているようでした。その後、夏季休暇の表示は消えましたが、バックオーダの処理に時間がかかっていたようです。12月下旬になって発送メールが届きました。
郵送オプションは不安がよぎるUSPS一択だったため、郵送グレードを上げて注文しました。やはり米国内輸送は3rdパーティのGlobalPostが担っていたようです。今回は住所の打ち間違いもなく、日本郵政からの注意付箋もありませんでした。「Kanagawa-Ken」が「Kanagawa-K」に短縮された軽微な変更しかありませんでした。住所印字システムが変わったのか、オペレータが習熟したのか、グレードによる輸送品質向上のためか、理由は不明です。

Transportation Results.

輸送経路を追跡すると、NEW YORKからATLANTAまでの北米航空輸送で6日を費やしていることが分かりました。大寒波到来で飛行機が飛んでいなかったのかもしれません。

動作原理

Quisk等のPC SDRとRS-HFIQの間に挿入するIQ Keyerの結線を下図に示します。

IQ Keyer operating principle.

Quiskから出力される送信IQオーディオ信号が、サウンドカードのHeadhoneジャックからRS-HFIQのIQ-IN TXジャックに結線されています（赤線）。IQ Keyerはこの結線の途中に挿入します。通常は、IQ Keyerは送信IQオーディオ信号をバイパスしているだけです。
キー入力があると、IQ Keyerはトーン周波数のIQオーディオ信号を生成して内部の絶縁トランス1次側に入力し、RS-HFIQへの送信IQオーディオ信号を絶縁トランス2次側出力にリレーで切り換えます。
同時に、PTT信号（CW OUT）も生成して、RS-HFIQのKEYジャックにつなげることで、RS-HFIQを送信状態に切り換えます。RS-HFIQのKEYジャックをKeyer入力として使用することは禁止されていますが、PTT入力としては使用できるようです。
IQ Keyerは信号生成タイミングだけをAruduino Nanoのタイマー割込みで制御し、PWM信号からアナログフィルタで正弦波信号を生成しているため、ゼロ遅延として訴求しているようです。

あい路

IQ Keyerにはサイドトーンの調整ノブが付いていますが、ボリューム調整用であり、サイドトーン周波数変更用ではありません。サイドトーンは700Hz（694.4 Hz）に固定されています。SDRにしてサイドトーン固定とは先祖帰りのような気がしますが、タイマー割込み180uS（5.55555 kHz）と密接に関係しているようです（5.55555 kHz / 8 updates/cycle = 694.4 Hz）。PWMクロックとタイマー割込みの整数比の関係を崩すとジッターが発生するとのこと。
サイドトーン周波数を低くする分には、PWMクロックを低くしてタイマー割込み周期を長くする方向に調整することになるため、できそうに思えますが整数比に関する詳細検討が必要です。
IQ Keyerを使用する場合は送信IQオーディオ信号線に乗せるサイドトーン周波数が固定されるため、Tune（同調周波数）に対するLO（SI5351A局部発振周波数）のオフセット同期調整を行うことができるように、Quiskのハードウェアファイルのプログラミングが必要になります。