「RS-HFIQ」スレッド
Keith's SDRのフロントエンドとして調達しておいたRS-HFIQ（HobbyPCB）の立ち上げに着手しました。RS-HFIQはPC（Windows PCやRaspberry Pi等）上で稼働するSDRソフトウェアのフロントエンドとしても使用できるため、「Teensy」スレッド（特定の話題の総体）とは別に「RS-HFIQ」スレッドを立てることにしました。下記既報をスレッドの（１）として本報告を（２）とします。
RS-HFIQのケース封入
RS-HFIQは部品実装済みの完成基板で供給されるため、専用ケースに封入するだけで済みます。
必要な作業は以下の通りです。
パネル化粧
ケース本体はアルミですが、前後のパネルはPCBで作られています。塗装されていないパネルのエッジ部を黒マジックで塗ります。エッジ部に加えて、穴の切断部にも塗ると見栄えが良いとのこと。
LED導光部品の光漏れ対策
4つのインジケータ（PWR、USB、TX、CLIP）のLEDはSMDタイプのため、PCB上方に向かって発光することになります。そこで、発光を90度曲げて正面パネルに導く透明プラスチック製の導光パイプをPCBに取り付けます。左右に光が漏れて隣の導光パイプに入らないように、導光パイプの左右側面を黒マジックで塗ります。
電源スイッチの組み立て
背面パネルに取り付ける電源スイッチに2ピンソケットの付いたリード線をはんだ付けし、ソケットをPCB上の電源ジャンパに圧入します。ソケットのガイドをニッパで切り落としても、横向きのジャンパピンよりソケット穴の方が高いため、ジャンパピンを曲げながら圧入することになりました。
ケース封入
PCBをスライドレール付きのアルミケースに入れ、前後のPCBパネルをねじで締結して完成です。終段FETにはPCB上下にヒートシンクが付いており、ケースに熱を逃がす等の対策は特に取られていません。そのためPCBの封入は簡単ですが、以下の注意が必要でした。
アルミケースのねじ穴にめねじ加工はありませんでした。ねじ自身のねじ山でめねじ山を塑性成形させながらねじ込むセルフタップになっています。最初の塑性成形にトルクが要ることと切りくずが出ることから、PCBを入れる前に8か所のねじを仮締結してめねじを切っておいた方が良いようです。
導光パイプの左右位置はPCBに設けられた挿入穴で決まりますが、導光パイプ底部が着座するまでは圧入できない穴公差になっているようでした。導光パイプの上下傾斜は前パネルの穴に挿入して決めることになります。
以上で完成です。上完成写真のパネル化粧に使用したマジックインクの箱はスケール比較用です。
ここにきて、USBコネクタがMini-Bであることに気付きました。家中を探し回ってなんとかType-A～Micro-Bケーブルを1本見つけました。周辺機器側のUSBコネクタはフォームファクタが小さい方が望ましいということで、4x1端子の平型Type-Aを2階建て2x2端子にしたType-Bを作って、さらにフォームファクタを小さくするためにMini-Bを作って、さらにさらに小さくするためにMicro-Bを作ったようです。電気特性は同じなのに形状の違う規格を3種類も作ったらユーザ視点ではケーブル貧乏になってしまい、もはや「Universal」ではないと思うのですが・・・。
PC接続テスト
RS-HFIQを用いたSDR実現方法
RS-HFIQはダイレクトコンバージョン方式のSDRを構成するRFフロントエンドであり、RS-HFIQを用いたSDRの実現方法として以下の3案を考えています。
（a）Stand-alone SDR
本命のKeth's SDRをバックエンドに使用します。Keth's SDRのTeensyをUSBホストにしてRS-HFIQを制御します。
公開されているArduino NanoのソースコードからRS-HFIQ側の通信プロトコルを調べる必要がありますが、Mike OMから既にKeth's SDRに実装済みとの連絡を頂いています。Keth's SDR（Mike OM版）をDebugディレクティブでコンパイルすると、Serial通信にRS-HFIQ制御Debug用のインタプリタが表示されることを確認済みです。
Keth's SDRとRS-HFIQの不具合を切り分けるために、Keth's SDRと接続する前にRS-HFIQの動作確認を下記(b)案で行いたいと考えています。
（b）SDR on PC
SoundカードでIQ信号をサンプリングして、Windows PC上のSDRソフトをバックエンドに使用します。
RS-HFIQがサポートしているSDRソフトはHDSDR一択になっています。HDSDRはWindows版限定、ソースコードが公開されていない等の制約があり、学びの対象としては良い選択とは言えません。
（c）SDR on Single Board Computer
SoundカードでIQ信号をサンプリングして、Linux Single Board Computer（Raspberry Pi）上のSDRソフトをバックエンドに使用します。
Windowsの他にLinuxに対応しているSDRソフトとして、Quiskが見つかりました。QuiskはPythonおよびCで開発されており、なんとPyPi repositoryからpipでインストールできるようです。RS-HFIQ用のhardware descriptionもGitHubに見つかりました。
なお、(b)案が実現すれば(c)案はいらないように見えますが、集合住宅環境からの要請があります。集合住宅で電波的環境が最も良い部屋は一般的にリビングになります。しかし、リビングで無線業務ができるのは家人が留守の時に限られます。そこで、家庭内リモート環境を安価に実現する(c)案が所望されます。
（b）HDSDR on Windows PCによるテスト
Windows PC上のHDSDRソフトウェアを用いたRS-HFIQテストシステムの構成を下記に示します。
RS-HFIQのホームページで示されている標準構成？とほぼ同じです。Sound Cardには推奨されているStarTeck社のICUSBAUDIO2Dを使用しました。
USBマイクはジャンク箱の中の物（サンワサプライMM-MCUSB16）を臨時で接続しました。これがHDSDRに嫌われ、ダミーロードTXテストができませんでした。USB PnP Audio Deviceという名称のデバイスドライバーがWindowsによって自動割り付けされますが、HDSDR上でサウンドデバイス選択をすると「ドライバーが有りません」旨のエラーメッセージが出てTXをイネーブルにできません。HDSDRおよびOmni-Rigのバージョンを最新にしても同じでした。
StarTeck社のMic入力を指定すればTXも動作しましたが、受信ノイズ信号の再帰循環送信系になり発散しそうです。実際、CLIPのLEDが赤々と点灯しました。なお、HDSDRの最新バージョンではUSBデバイスの循環指定をチェックしているらしく、TXをイネーブルにできないようになっています。
CLIPのLEDが何を指すのかの説明は見つかりませんでした。Aruduino Nanoのスケッチを調べると、アナログ入力1の値を上限しきい値と比較して点灯させています。上限しきい値は周波数バンド毎に若干異なる値が設定されており、一見、周波数に対する系統性はないようです。回路図を追うと、アナログ入力1（AR_A1）は終段FETのドレイン電圧のAC波高値を蓄電して抵抗分圧した値を測定していることが分かりました。TXレベル過多を知らせる仕組みのようです。終段入力信号もBPFを通過させる回路仕様のため、周波数バンド毎に異なる上限しきい値はBPFのゲインの違いを反映しているのかもしれません。TXレベル検知はCLIPのLEDを点灯させる以外は何もしていません。CLIP有無の返信コマンドは備えているため、SDR側でCLIPをサポートする必要があるようですが、HDSDRはサポートしていないようです。
試行錯誤した結果、TXテストを諦め、RXテストの構成にしてHDSDRを稼働させた際のGUI画面を下記に示します。ANTにはダミロードを接続しているため、RX信号は内部あるいは外来のノイズと思われます。
AF信号を拡大すると、50Hzと60Hzのベースノイズとその高調波が重畳していることが分かりました。RBWは0.1Hzまで下げられるため、精度高くノイズ周波数を同定可能です。
中央のキャリア周辺は、RS-HFIQ内部のPLLシンセサイザ周辺から発生するノイズと思われます。
50Hzノイズは、RS-HFIQに13.8Vを供給しているスイッチング電源、あるいはPC電源からの回り込みと思われます。13.8Vスイッチング電源をOFFにしても50Hzノイズは観測されたため、PC電源からの回り込みの可能性が濃厚です。Arduino NanoのUSBケーブルには2回巻きのコアが付いていますが、それぐらいでは役不足か、あるいはSound Cardの方から回り込んでいるのかもしれません。
60Hzノイズの出所は不明です。QTHは富士川（静岡県）以東です。出力を60Hzに統一した関西系インバータがQTH周辺にあるのでしょうか。翌日のテストでは60Hzノイズは消えていました。
RS-HFIQのホームページをトレースすれば簡単にテストできると思ったのですが、やはりPCのサウンド周りで躓きました。日を改めてIQバランス等のテストを継続したいと思います。
