1か月ほど、悶々としたり試行錯誤がつづきました。結果として、「なんだ、そういうことか」というのもあれば、まだ、わからないこともあります。GNU Radio Companionで作成したフローの動作を確認するにあたって、以前の記事で書いたように、アナログ受信のフローについては放送波という確実な信号源が利用できます。アナログ送信については、受信機を利用できます。しかし、デジタル伝送の場合、地デジを別にすれば、身の回りに安定的な信号源はなく、結果、送受合わせてフローを作成し元通りに復調されているかどうかを確認することになります。海外の事例を見ても、SDRデバイスを用いずに、１つのフローの中で送受信を作成している場合が多いようです。
最初の画像はGNU Radio for Windows上で作成した4値PSK(QPSK)の送信から受信までのフローです。上半分が送信で下が受信。信号源はテキストファイルのバイト列です。左上のFile Sourceに始まってDPSK Modまでが送信部。左に折り返して、 左下にあるPolyPhase Clock SyncやCostas Loopあたりがクロックリカバリ機能で受信の肝です。その次のDPSK Demodが復調機能で、復調されたビットストリームを1ビットごとに１バイトのLSBに詰めて吐き出します。このことは実は機能ブロックの説明に書いてあるのですが、きちんと読んでいなかったため、最後までよくわからなかった点です。話がそれますが、ブロックの左右にある他ブロックとの接続用端子の色はデータ形式を示します。紫はバイトデータを示すのですが、1バイトに受信した8ビットを詰めるのかと思っていたのですが、そうでないようです。バイト列生成の処理を行った後、ファイルに書き込みます。パラメーターの設定はネット上の事例をベースに作成していますが、自分でも十分理解しているわけではありません。慣れないうちはカット＆トライ的なところもあるようです。
受信結果です。送信側では2行のテキストを繰り返して送出しています。冒頭、文字化けが見られます。立ち上がり、受信側のクロックが同期するまで時間がかかるためと思われます。まあ、無線区間のリンクが確立する前にファイル転送を開始しているわけで無理もありません。OSIモデル（懐かしいですね）の中間部のプロトコルを無視しているわけですから・・・。ただ、その後は文字化けはありません。BERテストを行えば良好な値になると思います。もっとも、ロジックだけの世界ですから、ここで文字化けを起こしているようでは先がありません。冒頭の文字化けですが、GNU RadioにはFEC(Forward Error Correction)ブロックもあるので、これを使えば解決するかもしれません。あるいはアプリケーション側で制御しなければならないのか・・・。
次は送受信双方に実際のSDRデバイスを用いてループテストを行います。以前の記事にあるAM変復調のループテストでは、1台のLinuxマシンに送受信双方のSDRデバイスを接続して処理しましたが、今回は送信と受信側で別のPCを用います。送信側はRed PitayaとLinuxマシン、受信側はHackRF OneとWindows PCです。双方を結ぶのは同軸ケーブル1本だけです。送信側フローを下に示します。ただし、下半分は検証のために加えた同一フロー内での受信用フローで、最初に掲げた送受信フローの受信部と本質的には同じものです。送受信周波数は21.2MHzです。
Red Pitayaから実際に送信されている高周波信号をスペアナで観測した結果です。占有帯域幅は10KHzぐらいです。帯域外ノイズはマイナス約40dBとなっています。さらに送り側のGNU Radio上での送信スペクトラム図も示します。帯域外雑音はGNU Radioの中の量子化雑音だと思います。よって両者のノイズレベルを比較することは意味がないと思いますが、帯域幅はほぼ理論値どおりかと思います。下のコンステレーションは、上記、検証のために加えた受信フローでの受信結果です。
下図は受信側のフローです。左下から始まります。AM変復調のループテスト時と同様、HackRF Oneで得た受信信号にLOを注入し、21.2MHzのゼロキャリア信号を得て、レートダウンし、そこから先は冒頭の送受信フローの受信側と同じです。
この先の受信処理ですが、コンステレーションを見るとゆらぎはありますが、明らかに4値PSKを受信しています。しかし、 残念ながら、ここから先はうまくいかないことが多く、文字化けを起こします。たまに上にある1つのフローの中で閉じて送受信処理した場合と同様、（冒頭を除けば）正常に受信する場合もあります。
たまにうまくデコードできることから、受信フローのロジックに問題はないはずです。受信側のフロー上での信号スペクトルを示します。レートダウン後のPolyPhase Clock Syncブロックへの入力前の信号です。ここではあえてフィルターの帯域幅を送信信号の帯域幅より広くしています。+/-5KHz前後で緩いスロープがあり、その内側は信号波だと思いますが、その外側でもノイズが観測されます。HackRF One側のS/N比が悪いのかもしれませんし、あるいは受信フローのデジメーションに問題があるのか。帯域外のノイズはフィルタで 取り除けますが、帯域内のノイズは取り除けません。ただ、文字化けが規則的であることから、ランダムノイズが原因ではないとも考えられます。差動位相変調(Differential PSK)を使っています。この程度のデジタル伝送ではS/Nが10~15dB確保できれば、BERは十分下がっていくようです。実は上の送受一体のフローでも、文字コードがANSIだとうまくいきますが、UTF-8だと全角文字が規則的な文字化けを起こします。したがって文字コードの問題かもしれません。片やLinux、片やWindowsです。冒頭にファイルヘッダを送っていると思いますが、文字コード情報がうまく伝わっていないのかもしれません。
デジタル復調の方はまだ不十分ですが、GNU Radio Companionを用いたアナログ・デジタル双方の変復調処理を体験できました。事例を参考にしながら進めてきましたが、ここから先は、デジタル信号処理の理論、GNU Radioの各ブロックの機能、SDRデバイスの振る舞いを的確に把握しないと進めないと感じています。
1年近くGNU Radioを集中的に取り上げてきましたが、いったんは一区切りかもしれません。カミングアウトになりますが、9月16日から20日まで米アラバマ州ハンツビルで開催されるGNU Radio Conference 2019に参加します。太平洋の向こう側で開催されるイベントにわざわざ出かけるのですから、それなりの予備知識をと思ってやっていました。が、帰って来ると、もっとのめり込むかもしれません。なお、この間、ショップは休業させていただきます。