非職業的技師の覚え書き

JK1EJPの技術的検討事項を中心に記録を残します。

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: WindowsmacOS で標準、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で調べると、2つの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シリアル変換アダプタを使うことが簡単な解決方法になりそうです。