- 試験方法
- WSJT-Xチューン・モード試験
- AFP-FSK Transceiver送信と13TR-FT8受信
- Message送信試験
- 付録：レガシーRaspberry Pi 3B 再立ち上げの覚え書き
試験方法
FT8等のFSKモードのあい路の１つは、送信電波の品質チェックが難しい点を挙げられると思います。SSB帯域外は従来のスプリアス確認で間に合いますが、オーディオ帯域内の品質、特にオーディオ高調波を見逃すと他局に混信を与えてしまう可能性があります。WSJT-Xは「疑似スプリット」まで用意し、送信電波の品質確保に注力していることが分かります。
AFP-FSK Transceiverは原理的にオーディオ高調波を生じないはずですが、ソフトウェアの実装に依存して意図しない動作をしないか予め確認しておく必要があります。試験システムの系統図を下記に示します。前記受信試験の13TR-FT8とAFP-FSK Transceiverを入れ替えるだけです。Dummy Loadにつなげて送信した際の近接場漏洩電磁波を評価します。漏洩電磁波の強度を試験用最小限にするため、AFP-FSK Transceiverの電源は12VDCとしました。
WSJT-Xチューン・モード試験
500Hz チューン
まず、WSJT-Xチューン・モードを試しました。指定したTx周波数のAUDIO信号をWSJT-XがAFP-FSK Transceiverに入力してくれます。Tx周波数を500Hzに設定してチューンをクリックしました。
一般論では、混合器等の非線形素子によって低周波の500Hzから発生したオーディオ高調波（1k、1.5k、2k、2.5k、3kHz）は狭帯域フィルタ（＜3kHz）を掻い潜って送信されてしまうリスクが高くなります。
しかし、AFP-FSK Transceiverからはオーディオ高調波に由来するRF高調波が一切出ていないことが確認できました。AUDIO周波数と搬送波周波数の混合はAFP-FSK演算の中で単なるスカラ値の加算として行われているため、原理的にRF高調波は出ません。その原理的帰結が念のため確認されたことになります。
気付き
送信開始時に周波数が少し右にシフトしています。周波数軸を拡大して、チューンを複数回試行した結果を下記に示します。
間違いなく、右に約10Hzのシフトが繰り返し再現されています。WSJT-Xのチューン・モードの処理に依存しているのか、あるいはFSKの周波数遷移時の高調波を防止するWSJT-Xのフィルタ処理の副作用か、あるいはAFP-FSK TransceiverのAUDIO周波数計測の移動平均処理の遅れか、・・・原因は今のところ不明です。
AFP-FSK Transceiver送信と13TR-FT8受信
400Hz、1kHz、2kHz、4kHz AUDIO信号
WaveGenから400Hz、1kHz、2kHz、4kHzのAUDIO信号をAFP-FSK Transceiverに入力しました。AFP-FSK Transceiverがダミーロードに送信した電力からの漏洩電磁波をSDRplayで受信した結果を下記に示します。WaveGenの指示通り、周波数がシフトしていることが分かります。
この時、13TR-FT8が受信した漏洩電磁波のWSJT-Xワイドグラフを下記に示します。目視ですが、周波数シフトはSDRplayの受信結果と一致します。若干左にずれているのは、13TR-FT8の前記校正結果と一致します。
なお、AFP-FSK Transceiverはオーディーオ出力の帯域が許す限り可聴域を超えた4kHzでも送信可能ですが、国内で許可されるHFバンドの狭帯域データ・モードとするためには3kHz以下（副搬送波は2.95kHz以下）に制限する必要があります。
気付き
Windowsのオーディオ関係のAPIは、以下の順に進化してきたようです。
- MME（Multi-Media Extensions）
- Direct Sound
- ASIO（Audio Stream Input Output）（他社規格）
- WASAPI（Windows Audio Session API）
WaveGenの再生デバイス設定では、MMEを使用し、オプションの「EXTENSIBLEを使う」にチェックを入れていました。ヘルプでは「多チャンネル多ビット長対応の拡張フォーマットである WAVE_FORMAT_EXTENSIBLE 形式でデバイスをオープン」となっています。
この設定で13TR-FT8は動作していましたが、AFP-FSK Transceiverは送信ON/OFFが頻繁に切り替わるなど動作が不安定になり送信周波数も安定しませんでした。「EXTENSIBLEを使う」のチェックを外すと安定になりました。USBサウンドカードとの不整合が発生し、おそらくAUDIO信号が間欠的になっていたと現象から推定されます。アナログの13TR-FT8の方がこの点ではロバストでした。ディジタルのAFP-FSK Transceiverは過敏だったようです。
Message送信試験
SDRplay受信
次に、User messageの送信試験として、WSJT-XからAFP-FSK Transceiverに、1kHz副搬送波に対するCQメッセージのModulationを指示しました。SDRplayによるModulation漏洩電磁波の受信結果を下記に示します。
SDRplayのRefresh rateを最大にしてコントラストを調整すると、ウオーター・フォールに8-GFSK変調波が浮かび上がってきました。7,075kHzからの占有周波数帯域幅が50Hzであることが確認できます。この中に「CQ」が隠されているはずです。
上側のFFTスペクトルは瞬時周波数スペクトルを示している訳ではありません。40mバンドに対するSDRunoのFFTの仕様は、データ長65,536点、サンプリング周波数333,333Hz、平均回数3回です。FFTが対象にする時系列データ区間は0.59秒になります。FT8の送信速度は6.25-baudであることから、0.59秒には3.7回の周波数遷移が含まれていると思われます。これにより、前記チューン・モードよりも幅の広いスペクトルになります。
50dBcより下には、お椀形状のスペクトルが占有周波数帯域幅50Hzの外側に広がっていることが確認できます。さらに、お椀の左右外側にも50dBc以下のスプリアスが見えます。このスペクトルがどこから来るのか、必然なのか、意図しない漏洩なのかはまだ不明です。
FT8プロトコルの深耕
AFP-FSK Transceiverのようなシンプルなトランシーバによって従来にも増して遠方と交信できる秘密は、FT8のプロトコルの中に隠されているはずです。FT8がこれだけ普及しても、プロトコルの分かり易い解説は流布が少ないようです。Taylor博士らの比較的新しい文献*1が見つかりましたので、Message送受信のベースにあるFT8プロトコルの概要を調べました。
FEC: forward error correction
LDPC: Low Density Parity Check
CRC: Cyclic Redundancy Check
GFSK: Gaussian Frequency-Shift Keying
BP: Belief Propagation
OSD: Ordered Statistics Decoding
AP: a priori
プロトコルに盛り込まれた多くの技術は、惑星探査機の通信技術で実績があるようです。FT8の生い立ちを考えると、納得の行く話です。
一番の特徴はMessageの内容が約束事で固められている点と思います。これによって誤り訂正を施し易くなるとともに、無味乾燥の印象を与えることがあるようです。Taylor博士らの工夫が随所に盛り込まれていることに反比例して、ユーザの工夫点や運用スキルを入れる余地が小さくなり、運用体験も一様化され、無味乾燥となってしまうのかもしれません。自らの工夫点を入れて、WSJT-Xに代わるソフトウェアを作るのは自由なようですが、敷居は遥かに高くなります。
送信174-bitの中の97-bit（56%）は誤り訂正用符号です。通信の信頼性を上げる基本はレポート交換時のように2回繰り返すことですから、bit数が2倍に膨れていても驚くことではないのかもしれません。デジタルの恩恵により、2回繰り返すよりも大幅に信頼性が上がっているはずです。
13TR-FT8受信
AFP-FSK Transceiverが正しくMessageを送信しているかどうかを試験するためには、送信Messageを受信してデコードする必要があります。AFP-FSK Transceiver送信用のWSJT-Xと、13TR-FT8受信用のWSJT-Xの2系統が必要になります。そこで、ジャンク箱に眠っていたRaspberry Pi 3Bを発掘して送信系に用いることにしました。（レガシーRaspberry Pi 3Bを立ち上げるに際に、何も調査せずに試行錯誤をしたところ時間を浪費してしまったため、立ち上げの記録を付録に残します。）
Messageの送受信を検証する試験システムの構成と写真を下記に示します。
CQメッセージを送受信した試験結果を下記に示します。Raspberry Pi 3B上のWSJT-XにてエンコードされたCQメッセージがAFP-FSK Transceiverから送信され、そのCQメッセージは13TR-FT8で受信され、Windows PC上のWSJT-Xにて正しくデコードされました。
気付きとして、受信信号のワイドグラフを見ると、左下に舌状のスペクトルが出ています。前記チューン・モード試験で気付いた現象と同様に、送信開始時点の周波数が正しく送信されていないか、あるいは受信されていない可能性があります。
気付きとSDRplayによる目視デコード
CQメッセージ送信開始時点の頭出しに注意して、再びSDRplayで変調信号を受信しました。今回は、Bias-TをOFFにして余分な漏洩電磁波を拾わないように注意しました。13TR-FT8をケースに入れた効果と相まって、前回のようなお椀形状の外乱スペクトルは影を潜めました。
先に調べたFT8のプロトコル仕様から、エンコード・トーン・シンボルの頭には同期用の7トーンのCostas array（3,1,4,0,6,5,2）が付加されているはずです。周波数シフトを目で追うと、「3,1,4,0,6,5」トーンまでは確認できますが、トーン「2」が約30Hz右にオフセットしたと仮定しないと辻褄が合いません。Tx周波数が2.000kHzであったことと、占有周波数帯域幅50Hzを考慮すると、逆に「3,1,4,0,6,5」トーンまでは本来より左にオフセットしていたと考えられ、これが舌状スペクトルの正体と思われます。
Costas arrayの次は、3-bitのMessage Type（Std Msg Type=001）か、28-bitの無指定CQメッセージ（0000000000000000000000000010）が来るはずです。どちらが先に来るかは、前述のプロトコル解説書には記載が無いようでした。3bitsを束ねたトーン・シンボルは、Message Type（1）もしくはCQメッセージ（000000001..）になります。Message Typeが先に来るとすると、目視デコードが間違っていたことになり、舌状スペクトルの解釈も怪しくなります。逆に、CQメッセージが先に来るとすると、目視デコードは正しく、舌状スペクトルの解釈も正しくなります。
FT8プロトコルの机上エンコード
WSJT-Xのマニュアルを見ても、Message Typeがメッセージの前に付くのか、あるいは後ろに付くのか分かりません。しかし、マニュアルに次の記述がありました。
Additional utility programs jt4code, jt9code, and jt65code let you explore the conversion of user-level messages into channel symbols or “tone numbers,” and back again.
（また、ユーティリティプログラムjt4code、jt9code、jt65codeにより、ユーザーレベルのメッセージをチャンネル記号や「トーン番号」に変換したり、また元に戻したりすることができます。）
残念ながら、ft8codeユーティリティは無いようですが、マニュアルの改訂を失念しているのかもしれません。ダメ元で打ってみると幸いにもUsageが出てきました。「トーン番号」への変換機能はft8code.exeでもサポートされているようです。
CQメッセージのエンコード結果を下記に示します。緑がメッセージ、青がFEC符号、赤が「トーン番号」です。
赤の「トーン番号」の"Sync"は7トーンのCostas array（3,1,4,0,6,5,2）です。その次は（000000001..）なので、CQメッセージです。緑のメッセージの最後は（001）bitsであり、Message Type（Std Msg Type=001）を表していると思われます。Source encodeの要の1つであるMessage Typeが語尾に付くことが確認されました。
これにより、SDRplayの目視エンコードが正しいことが確認され、舌状スペクトルの原因がAFP-FSK Transceiverの周波数計測遅れ等によるオフセットにあるのではないかという仮説が濃厚になりました。
しかし、30Hzぐらいの出だしのオフセットの影響を受けずにデコードできている結果から、FT8のロバスト性に改めて感服する次第です。同期用のCostas arrayを前、中、後の3ヵ所に配置した効果でしょう。
残された課題
- 送信開始時点の周波数オフセットの原因究明（例えば、移動平均処理の影響？）
- バンド・モジュール追加によるHFオールバンド化
追記（2022/07/02）
課題１の送信開始時点の周波数オフセットの原因究明のためにコードを熟読しましたが、初期の周波数が10～30Hz程度低くなる原因は見当たりませんでした。オーディオ周波数の計測において、重み付き移動平均の計算をしている箇所はありますが、計算値をリップルの判定に用いているだけであり、オーディオ周波数の計測に反映されることはないようです。FT8のAFP-FSK計算だけでなく、強制送信試験ピンによる単純搬送波出力の際にも初期周波数の低下が見られるため、別の所に原因があると考えるのが妥当です。
次に仮説を立てたのは、PLLシンセサイザーMS5351MのPLLの周波数ロック遅延です。チャージポンプの時定数等は分からないのですが、PLLリセットコマンドをMS5351Mに送信すると負帰還動作を始め、幾何かの遅延は生じる可能性があります。PLLリセットコマンドで受信音に雑音が入るという話もWeb上に見られます。
FT8のFSKチャネルのシンボル送信速度は6.25baudであるため、周波数がずれているCostas arrayの最初の6トーンの送信時間は約1秒（0.96 sec）です。PLLのロックに1秒かかるのは遅いような気がしますが、30Hzは7MHzに対して4ppm程度なのでチャージポンプのチャージに時間がかかるのでしょうか。
AFP-FSK TrasceiverのPLLシンセサイザーの制御コードは、PLLリセットを頻繁に発生させないように注意深く組まれているようです。PLLの後段の分周器設定に乖離が発生しない範囲の周波数変更については、PLLリセットを回避するコードになっています。試算してみると、40mバンドにおいて、0～1kHzの副搬送波変更に対してPLLリセットなし、1.5kHzに変更する時にPLLリセットが発生し、1.5～3kHzの変更に対してPLLリセットなしとなりました。FT8送信中の50Hz範囲の周波数シフトでPLLリセットが発生することはなさそうです。今回の同じTx周波数に対する送信試験で舌状の周波数ずれが繰り返し見られたのは、PLLリセットが原因ではなかったことになります。
振り出しに戻ってしまいました。Clock信号を止めないでQCXのようにゲート制御する方法を試してみたいところですが、改良が大掛かりになってしまいそうです。
付録：レガシーRaspberry Pi 3B 再立ち上げの覚え書き
今回の試験のために、2016年頃に触っていたRaspberry Pi 3Bをジャックボックスから引っ張り出して再立ち上げしました。何も調査せずに試行錯誤をしたところ時間を浪費してしまったため、再立ち上げの記録を付録に残します。
回顧のRaspbian
まず、当時のOS（Raspbian）のセキュリティを向上するためにupdateやupgradeを繰り返しましたが、404エラーが多発してパッチが当てられません。どうやら、パッチファイルが既にサーバから撤去されている模様。
調べると、Raspberry Pi OSは最新版と1つ前のLegacy版しかサポートされないことが分かりました。
最新版のBullseye
素直に最新版のRaspberry Pi OSを焼き直すことにしました。公式のSDカード作成ツールImagerのトップに表示される現時点の最新版は通称「Bullseye」でした。何も考えずに「Bullseye」を書き込み、時間を掛けて初期設定を行いました。これが無駄な徒労でした。
現時点のWSJT-XのRaspberry Pi用コンパイル済みパッケージは、一つ前のLegacy版の通称「Buster」用しかありませんでした。一応「Bullseye」へのインストールをトライしましたが、どうにもこうにも多数のlib***のバージョンが不適合でインストールできませんでした。ソースからコンパイルするのもRaspberry Pi 3Bには荷が重そうです。
Legacy版のBuster
ここも素直にImagerの下の階層の中にある「Buster」を焼き直し、初期設定をやり直しました。「Buster」を焼き直した甲斐あって、WSJT-Xはトラブル無く簡単にインストールできました。
その他
次にTime.isを見ると「あなたの時計はちょうどぴったりです」と表示。Raspberry PiはRTCを持っていないはずですが、インターネットに接続して時間が経てば自動的に時計を合わせてくれるようです。
USBオーディオカードは、（１）廉価版と、（２）96kHzに対応した高級版？の2種類を保有しています。（２）高級版は、Raspberry Pi 用のドライバが無く、上手く立ち上がりませんでした。IQ信号用に96kHz対応カードを準備していたのですが、オーディオ用は44.1kHzで十分です。（１）廉価版は、プルダウンリストに表示される名前がWindowsより多く特定が厄介でしたが、何とかつながりました。
*1:Steve Franke, Bill Somerville and Joe Taylor, "The FT4 and FT8 Communication Protocols - Motivation and design of the digital modes FT4 and FT8, and some details of how they are implemented in WSJT-X", QEX July/August 2020（https://physics.princeton.edu/pulsar/k1jt/FT4_FT8_QEX.pdf）
