GNU　Radioをいじっていたのが、もう、１年も前になってしまうのですね。なんだかよくわからないままに、モジュールを繋ぎ合わせてシグナルフローを作っていましたが、SSBがらみのアナログな回路シミュレーションが終わったところで、懐古趣味的な、真空管リニアアンプの工作に走っていったので、それ以来、GNU　Radioはずっとほおりだしていました。

　その後、真空管にも飽きたので、またＧＮＵ　Ｒａｄｉｏに戻って、簡単なデジタル通信をシミュレートしてみたいとネットを漁っていました。しかし、それらしきフローグラフはたくさんあるのですが、動作の概略しか書いてなくて、本家のマニュアルを見ても、パラメータの設定をどうしていいのかわからないことだらけです。なので、まずは習うより慣れろとばかりに再度いじりだしたのですが、この難題（＝パラメータと動作の詳細がようわからん！）を克服することができずに、いまだにさまよい続けています（苦笑）。

　ま、時間がかかってもいいから、シミュレーションと、Hack　RF One　やRedpitayaを繋いだ実験を通じて、少しでもデジタル通信に馴染めたらいいなと思っています。ただ、やってることは、現実世界では３０年以上前に実用化された通信方式の「真似」ですから、なんら新しいことはありません。あくまで、自分の勉強のメモレベルということになりましょうかね。

　ということで、まずはデジタル変調を体験してみることにします。ＧＮＵ　Ｒａｄｉｏには変調のためのたくさんの種類のモジュールがあるのですが、ここでは代表的なConstellation　Modulatorを使うことにします。この変調器はBPSK、QPSK、８PSK、16QAMが同じモジュールで実現できて便利です。これらのパラメータはConstellation　Object　という、変調器と関連付けられたモジュール内で設定されます。

　この変調器の出力のスペクトラムと、Constellationを見て見ましょう。例はQPSKです。

変調波生成シグナルフロー　




ＱＰＳＫスペクトラム
Ｅｘ　ＢＷ＝１

　まずは、これが本当にちゃんとした変調スペクトラムなのかを見て見ましょう。ランダムな信号でPSK変調を行った場合、そのスペクトラムはSin(x)/ｘの形になることが知られています。この時のスペクトラムの最初のヌル点は、ベースバンドでは+/-シンボルレートになります。ここで、今回の変調器の例では４サンプル/シンボルですから、サンプリングレートが３２ｋｂｐｓであれば、シンボルレートは８ｋsymbol/sになります。これをスペクトラムで比較すると、ちょうどヌル点が８ｋHzあたりになるので、シミュレーションが正しく行われていることがわかります。

　さて、この時の信号ダイヤグラム（Constellarion）を見ておきましょう。以降使うことになるので、通信路シミュレーションのブロックを追加しておきます。

通信チャネルをシミュレートするシグナルフロー




ＱＰＳＫのコンステレーション
4samples/symbol




ＱＰＳＫのコンステレーション
16samples/symbol

　通信路シミュレーションのブロックですが、ここでは何もしていません。そのまま、信号をスルーしていると考えてください。

　さて、上図ですが、サンプル/シンボル数を大きくしていくと、コンステレーションは当然のごとく信号空間の振幅位相値を細かくトレースするようになります。これが４サンプル/シンボルだと、殆ど信号空間の４つのポイント、すなわち入力データ２ビット分をＱＰＳＫ変調の振幅・位相にマッピングした「４点」の周りに見ることができます。実は、これ、変調モジュールの中にルートナイキストフィルタが実装されていて、この帯域がＥｘ　ＢＷというパラメータで決めるようになっています。このフィルタの応答のため、信号空間上、ばらけて見えるようです。サンプル/シンボルの値を大きくしてやれば、サンプル点移行の軌跡が見られます。それが、上の右の図というわけです。ここらあたりまでは、直観でなんとかわかりますね。

　このモジュールは後でも触れますが、ベースバンド信号に熱雑音と周波数オフセットあるいはマルチパスのために受ける帯域内周波数変化を与えてしまうものと考えてください。まずは、熱雑音のようなフラットノイズを与えてみます。与えたノイズの多寡によって、スペクトラムのC/Nが変化することが見て取れます（与えた電圧振幅と見えてるC/Nの関係がわかればなぁ・・・・・）。

　この時のベースバンド信号はどのようになっているでしょうか？アナログ信号のように、「ノイズっぽく」見えるのでしょうか？ここで、変調信号のI/Q成分（複素信号）を実数信号に戻して、オシロスコープで見て見ることにします。また、同時に先のコンステレーションも一緒に見て見ましょう。

アイパターン
Noise Voltage=0
EX BW＝0.35



　周波数スペクトラム
Noise Voltage=0
EX BW＝0.35




アイパターン
Noise Voltage=0.1
EX BW＝0.35




周波数スペクトラム
Noise Voltage=0.1
EX BW＝0.35




アイパターン
Noise Voltage=0.2
EX BW＝0.35




周波数スペクトラム（平均化）
Noise Voltage=0.2
EX BW＝0.35

　上記のオシロスコープの図形は俗に「アイパターン」あるいは「アイダイヤグラム」と呼ばれているようです。ノイズが少ない時には信号軌跡がノイズによって擾乱されないので、「波形はお目目が開いたように見える」かららしいです。これが、ノイズの付加とともに、信号波形が乱れて「お目目をつぶったように？」なっていきます。

　この表示をさせるためには、WX GUIでないとできないようで、このSinkのパラメータのPersistencyを最大にしてやると、このアイパターンに見える表示ができるようです。QT GUIだとTime sinkにそんなパラメータが無い（ように見える）ので、このアイパターンは見えません。なぜ、アイパターンに触れたかというと、この目の開き具合が、デジタル復調時の「正確さ＝エラーの無さ」を現すからです。では、どのくらい目が開けば、エラーレートはいくらか？なんていう興味深い話につながるのですが、ここではこれ以上は触れません。

　で、ノイズを印加したときのコンステレーションですが、ノイズがホワイトノイズであれば、シンボルポイントをランダムにかき回すような動きになります。ホワイトノイズの瞬時振幅が信号に加わることでシンボル点の振幅/位相を乱すということになります。当然、ノイズが多くなれば、確固としたシンボル点がわからなくなるほどにコンステレーションが乱れます。これだと、この後に復調器をもってきても、とっても復調できるような気がしませんね。

　そこで、フィルタをかまして信号純度を上げてやりましょう。この機能がPolyphase　Clock　Syncです。

Ｐｏｌｙｐｈａｓｅ　Ｃｌｏｃｋ　Ｓｙｎｃでノイズ除去するシグナルフロー

　この出力を観察すると、熱雑音を印加して、乱れたコンステレーションを綺麗にしてくれる様子がわかります。

Ｎｏｉｓｅ　Ｖｏｌｔａｇｅ＝0の時の改善効果
左：変調出力　右：Ｐｏｌｙｐｈａｓｅ　Ｃｌｏｃｋ　Ｓｙｎｃ追加後
ブラウザの表示幅を広げて比較してみてください
また、前記のアイパターンとスペクトラムとの対比も楽しんでください




Ｎｏｉｓｅ　Ｖｏｌｔａｇｅ＝0.1の時の改善効果
左：変調出力　右：Ｐｏｌｙｐｈａｓｅ　Ｃｌｏｃｋ　Ｓｙｎｃ追加後
ブラウザの表示幅を広げて比較してみてください
また、前記のアイパターンとスペクトラムとの対比も楽しんでください

　と、このようにクリーンアップできることがわかりました。

　さて、実際には熱雑音やら、または送受信機が独立であることによって生じる周波数オフセット、さらにはマルチパスによる周波数選択性による帯域内振幅変化といった、信号伝送にとっては「外乱」になる要素がありますが、これらをGNU　Radioでシミュレートします。先のモジュールには、この３つの外乱を作り出す機能がありますが、熱雑音に関しては、すでに示しました。次は周波数オフセットに関してみていきましょう。

　これも、パラメータ設定で周波数のオフセットができます。ちなみに3.2ｋHzオフセットさせた場合のスペクトラムを見て見ましょう。当然のごとく信号スペクトラムが3.2ｋHz移動します。これは周波数オフセット値を０．１とした時で、サンプルレートの１/１０に相当するようです。

周波数オフセット時のスペクトラム
ΔＦ＝3.2ｋＨｚ（＝サンプルレート*0.1）

この時のコンステレーションは以下のようになります。

周波数オフセット時のコンステレーション
ΔＦ＝3.2ｋＨｚ（サンプルレート*0.1）

　QPSK信号が周波数オフセットを受けると、いままで、四角の頂点付近にとどまっていたコンステレーションが、なんだか原点を中心とした「輪っか状」になってしまいます。これはどういうことかというと、QPSKは４つの位相の状態で、おのおのの「点」が２ビットのデータを現します。この時、信号が周波数オフセットを受けると、その周波数分だけ（＝時間あたりの位相変化なので）一定方向に回り始めてしまいます。なので、表示上では「輪っか状」のコンステレーションは、一定速度（周波数オフセットに相当する）で原点の周りの回転に「乗っかって」、信号の位相情報を伝えているということになります。

　こうなると、もう、復調（＝位相状態の検出）どころではなく、この周波数変化分をキャンセルしてあげないといけません。このためには、昔からいろいろな手段があるようで、信号を４逓倍することで信号の位相変化を無くして周波数オフセットを検出したりとか（これＣ/Ｎが悪いと逓倍するので特性に難あり）、あるいはPLLを使ってオフセット周波数をキャンセルするCostａs　Loopが有名です。もちろんGNU　RadioでもCostas　Loopのモジュールが用意されていますので、このブロックを追加してみましょう。

Ｃｏｓｔａｓ　Ｌｏｏｐを追加したシグナルフロー

　この出力の様子を見ると、ぐるぐる回っていたコンステレーションが、もとの４ポイントに戻っていることがわかります。もちろんこれも程度問題で、Costus　Loopの処理能力は有限なので、ロックレンジを外れて周波数補正をすることはできません。

周波数オフセット時のＣｏｓｔａｓ　Ｌｏｏｐを通過後のコンステレーション
ΔＦ＝3.2ｋＨｚ（サンプルレート*0.1）

　長くなりました。今回はこのあたりで留めておきたいと思います。

＜そのⅡ：データ送受信＞　【2020.8.19】

　さて、モジュールの基本的な動作がわかったので、ＰＣ内シミュレーションだけでなく、「送受信装置」をつないで、実際にデータ伝送実験をしてみることにします。

　とその前に、ＰＣの増設というか、中古品をＬｉｎｕｘ化したので、ちょっとレポートしておきます。まずはデスクトップＰＣを落札しました。安部のジュウマンが残っていたので新品でもいいかな？とも思ったのですが、Ｌｉｎｕｘ専用機に新品はもったいないと思い、法人からの放出品で格安なものを手に入れています（実は、安倍のジュウマンで中古品を買っても、ＧＤＰは増えないので、それならもっと有効な他の用途に使おうと思ったわけで・・・・なわけないか（笑））。

　で、ブツはこれと同じ筐体です。中身がちょっと違うだけです。

ＣＰＵ：Ｃｏｒｅ　ｉ５-４５７０
メモリー：ＰＣ-16000の４ＧＢ（のちに既存機から６GＢを移植して１０GＢに増量）
ＨＤＤ：５００ＧＢ
ＯＳ：消去済み（クリーンフォーマット状態）

　というスペックで４６００円でした。スペック的には４～５年くらい前のミドルレンジという感じですかね。しかし、Ｌｉｎｕｘで使うには必要十分なスペックです。あとでＧＮＵ　Ｒａｄｉｏで処理スピードを測ってみると、今、使っている開発専用機（ｉ５-６５００）に比べて１０％くらいダウン程度で済んでいるので、まったく問題ないでしょう。以前のＣｅｌｅｒｏｎの２倍くらいのスピードですね。ま、いい買い物でした。もっともどれだけの期間使えるかは微妙なのでバックアップは万全にしておかないと。

　さて、本題です。いきなり以下にシグナルフローを出してしまいます。まずはＢＰＳＫで簡単にやっつけてみましょう。しかし、後になってみると簡単なシグナルフローも、ネットでパーツを拾ってきて動かしてみると、思ったように動かなかったり、なかなか手強いものがあります。

シグナルフロー図

　まずは全体の概要ですが、以下の通りです。

変調方式：ＢＰＳＫ
テスト信号：ベクトルソース（０/１の実データ列でここでは４０ビットのデータ）を繰り返し送信
送受信装置（ハード）：Ｒｅｄｐｉｔａｙａ-14（送受信をフルデュープレックスで使用）
誤り判定：送信変調データ列と受信復調データ列を比較して検出

　という感じで、これでほとんど説明が終わってしまうのですが、それでは不親切なので、もう少し追加しておきます（笑）。

　入力データですが、多くのシミュレーションではテキストや画像ファイルをソースに指定して、送信、受信後に同じファイルが生成できました・・・はい、おめでとうございます・・・・で終わるのですが、ここでは、通信路上でどんな波形になるのかを見たくて、0/1の定型データを採用してみました。

　これを、Ｃｏｎｓｔｅｌｌａｔｉｏｎ　Ｍｏｄｕｌａｔｏｒのバイト入力に適合するようにパッケージ化して、さらに速度調整のＴｈｒｏｔｔｏｌをかませて、変調器入力に放りこみます。このＣｏｎｓｔｅｌｌａｔｉｏｎ　Ｍｏｄｕｌａｔｏｒの出力は複素表現になっているので、もう、ここではＩ/Ｑ信号になります。ＢＰＳＫ変調なので、Ｉｍａｇｅ成分は変化せず、Ｒｅａｌだけが入力に対応して変化することになります。

　次に、サンプリングレートを５倍して、Ｒｅｄｐｉｔａｙａの都合のいいレートに合わせて入力します。なお、Ｒｅｄｐｉｔａｙａのサンプリングレートは１．２５Ｍｓｐｓまで可能です。なお、Ｒｅｄｐｉｔａｙａ（Ｓｉｎｋ）のＰＴＴは１にしておかないと信号が出ません。

　以上で送信側のフローは終わりです。ここからはＴＸ端子に設定したキャリア周波数の実信号のスペクトラムが得られます。キャリア周波数は冗談で７ＭＨｚにしています（笑）。

　ＲｅｄｐｉｔａｙａのＴＸとＲＸは同軸ケーブルで直結しています。ＴＸ、ＲＸにアンテナをつければ、実際に電波として空間を伝搬させることができて、シミュレーションでいうところの「Ｃｈａｎｎｅｌ　Ｍｏｄｅｌ」を実際に体験できます。ま、ここでは、そのあたりの検討は後回しにして、まずはデータ復調にまでもっていきましょう。

　シグナルフローの左下にＲｅｄｐｉｔａｙａ（Ｓｏｕｒｃｅ）がありますが、これが受信機になります。出力はベースバンドのＩ/Ｑ信号で、これのサンプリングレートを１００ｋｓｐｓまで下げて、Ｐｏｌｙｐｈａｓｅ　Ｃｌｏｃｋ　Ｓｙｎｃでクロック抽出して、Ｓ/Ｎを上げてＣｏｎｓｔｅｌｌａｔｉｏｎ　ＤｅｃｏｄｅｒとＤｉｆｆｅｒｅｎｔｉａｌ　ＤｅｃｏｄｅｒでＢＰＳＫ復調と差動デコード（送信では変調器のブロック内で差動エンコードしてあるので）して復調完成です。

　さて、送ったデータが正しく再生できたかを見るにはどうしたらいいでしょうか？ここでは超簡単な方法で見てみましょう。それは、単純に送信データを、それ以降の復調までにかかる処理遅延時間だけずらして、復調データと比較してみる方法です。フローグラフの右側の中段付近にＳｕｂｔｒａｃｔ（＝引き算）のブロックが見えますが、これがそれで、送信データはＤｅｌａｙ　ブロックで遅延した信号を復調データから差っ引きます。もし、データ列が同じであれば、この出力はきっかりゼロになるはずです。入力されるデータが異なると、Ｓｕｂｔｒａｃｔブロックの出力は+/-1の値をとります。

　次に実際の動作を見ていくことにしましょう。

　入力データ列は

1,0,1,1,0,1,1,0,0,0,1,1,0,0,1,0,0,1,1,0,0,0,0,1,1,1,0,0,1,1,0,1,0,1,0,0,1,1,0,0

　としました。0/1のアンバランスがあると、受信クロック抽出に影響がありそうなので、そこは少し考慮しました。ただし、特徴的なパターン（0の４連続とか）がないと、復調したとき、正しいか「目で」見極めるのは困難なので、適度にバランスを偏らせてあります。これでＢＰＳＫ変調されると、以下のようなＩ/Ｑ信号が得られます。ＢＰＳＫ変調なのでベースバンド信号のＩｍａｇｅ成分はゼロでＲｅａｌ成分のみの変動になります。

ＰＳＫ変調器出力（Ｉ/Ｑ）




ＰＳＫ変調器出力スペクトラム

　なお、この時のスペクトラムを上に示します。１００ｋｓｐｓで８samples/symbolなので、１２．５ｋＨｚ近辺に浅いですがヌル点が見えます。

　受信側ですが、Ｒｅｄｐｉｔａｙａの受信機の出力は以下の通りで、これはＴＸ入力と同じようなＩ/Ｑ信号で、Ｉｍａｇｅ信号の変化は検出されていません。なので、ＢＰＳＫのベースバンドＩ/Ｑ信号であることがわかります。（ただし、ＰＰＣＳのロック具合によってはイメージ成分が出てしまうこともあるようです。このあたりは、動作が不明なので今は深入りしません）

Ｒｅｄｐｉｔａｙａ出力（Ｉ/Ｑ）

　これから、クロック同期のためのＰｏｌｙｐｈａｓｅ　Ｃｌｏｃｋ　Ｓｙｎｃ モジュールを通過させて、クロック同期と帯域制限をおこなって、ＢＰＳＫデコーダ、差動デコーダを通過させてば、めでたく復調が可能になります。

ＰＳＫ復調出力

　この図で、ドットは復調されたビット列を示しています。このグラフではドットのみ示してラインでつなげるような表示はしていません。これは、Ｔｉｍｅ　ＳｉｎＫのＣｏｎｆｉｇを開くと、表示方法のオプションがありますので、いろいろいじって変化を楽しんでみてください。

　このドットは復調ビットを示しているので、先に示した変調器への入力データ列と同じにならないと正しく復調されたとは言えません。ちょっと比較してみてください。同じになるように目を凝らしてみてください。

　さて、この比較をするのに、先の図でＳｕｂｔｒａｃｔモジュールがありました。送信データのＤｅｌａｙはＱＴ　ＧＵＩ　Ｒａｎｇｅで可変できるように設定していますので、動作中にＤｅｌａｙ量をいじって様子を見ます。以下の図はＤｅｌａｙ＝２０の場合のＳｕｂｔｒａｃｔモジュールの出力です。表示が０のところが一致したビットなので、このままではＤｅｌａｙ量が適正ではありません。

Ｄｅｌａｙ＝２０の時のエラーの様子

これが、Ｄｅｌａｙ＝２１とすると

Ｄｅｌａｙ＝２１の時のエラーの様子

　ぴったりゼロが続くので、完全に入力の送信/受信データが一致したことがわかります。

　但し、このｄｅｌａｙは曲者で、Ｐｌｙｐｈａｓｅ　Ｃｌｏｃｋ　Ｓｙｎｃモジュールのロック具合によって値が変動します。なので、Ｒａｎｇｅで手動変更ができるようにしてあります。

　おまけと言ってはなんですが、この場合のコンステレーションとＳｕｂｔｒａｃｔ　モジュールの出力データを１０２４個集めて、その分布を見たのが下図です。０以外のデータが一つもないので、誤りはないという状況がわかります。

エラー＝０の時のエラーパルスカウント（上）と復調コンステレーション（下）

　ここで、ちょっといたずらして、Ｒｅｄｐｉｔａｙａの送受信ケーブルを外してしまいましょう。当然、信号が無くなるので、復調信号のコンステレーションは乱れて、結果、一致データの分布は５１２個しか一致しない＝まったく復調していない状態となります。

アンテナ入力を引っこ抜いたとき（笑）のエラーパルスカウント（上）と復調コンステレーション（下）

　このヒストグラム機能をうまく使えば、誤り率を測ることができるような気がしています。（注：Ｅｒｒｏｒ　Ｒａｔｅ　なるモジュールもありそうなので、そっちのほうがが適正かな？）。本来はＴＲＸをつなぐ同軸に、ＡＴＴとか挿入して、横軸をＣ/Ｎ（Ｅｂ/Ｎｏ）に誤り率を測れれば、パーフェクトですが。

　以上、見てきたように、シミュレーションと実際の送受信機（Ｒｅｄｐｉｔａｙａ）を結んで、実験じみたことが机上でできるのは面白いことですね。それも、各モジュールの入出力の様子を観測できるので、初心者が動作を理解しながら学習するのに大変に便利です。もしかすると、昨今の大学生はこんなシミュレーションで勉強するのかなぁ？

＜そのⅢ　ファイル転送とＱＰＳＫ変調＞　【2020.9.4】


　前回は「ナマ」データの通信をRedpitayaを用いて行いました。今回は応用問題として、まずは、テキストファイルを伝送してみましょう。

　いつもの如く、いきなりシグナルフローを提示します。NETにあるいろいろな例を参考にして、それを改変していますので、明確なリファレンスが示せなくなっていますが、商業利用するような話ではないので、そこはご容赦いただきたく思います。なお、ネットから引っ張ったフローグラフに明確な著作権保持の表示は無かったと思いますので、参考までに。

シグナルフローグラフ

　さて、動作の概略を見ていくことにしましょう。

　入力はFile Sourceブロックで、これは、PC内の指定ディレクトリにおいたテキストファイルとしました。中身の文章は意味のない文字列で（文章考えるのが面倒だったので）、繰り返し送信しています。この出力を見るとバイト指定なので、０〜２５６の数値が出てきます。これにプリアンブル信号を付加して、Constellation　Modulatorが理解できるデータ列に変換してBPSK変調されます。

入力<データ信号

　これ以降は、前回のシミュレーションと同じようなものなのですが、基本は前回と同じなのですが、少し実験をしています。

　その１ですが、DCオフセットキャンセルです。変調側で変調スペクトラムの中心周波数を10kHzオフセットさせて、復調側では-10kHzして、スペクトラムをもとに戻しています。シミュレーションと言っても実機を使う場合、DCオフセットや低域通過特性の影響で、特性が悪化するのを防ぐ効果が期待されます。シグナルフロー上は、変調側のMultiply 10kHzSignal source、復調側のMultiply、-10ｋHｚSignal Source、Low Pass Filterがその要素です。実際の様子を以下に示します。

オフセットされた変調スペクトラム（Redpitaya入力前）




復調してもとに周波数オフセットを戻されたスペクトラム（ＬＰＦ後）

　あとは、もうおなじみになったPolyphase Clock Sync、Costas Loopを通って、BPSK復調、差動デコード、ファイルに書き込むためのデコードを経て、ファイル書き込みが可能になります。各ブロックの入出力は「どんな信号がながれているのか」わかるようにモニターを置いています。

　さて、肝心のファイル伝送ですが、入力のファイルとRedpiytayaを介して伝送されたファイルは以下のようなものです。送信側は繰り返し送っているので、受信されたデータは繰り返し上書き記録されています。

送信ファイル（左）と受信ファイル（右）

送信ファイルは繰り返し送信で、受信ファイルは連続上書き

　これをみると、しっかりデータ伝送ができていることがわかると思います。ただし、受信されたデータを見ると、最初の送信時には、データの頭が欠落してしまい、途中から再生されていますね。送信データは何度も繰り返して送るので、以降は正常に受信されています。

　ここで、いつものごとく送信データストリームと受信データストリームの比較をしてみましょう。File Sourceの出力（送信）データ とFile Sinkの入力（受信）データを比較するモジュールがシグナルフローの右下にあります。この送受信データを比較したのが、下の図です。

送受信データの比較

時間方向の揺らぎが大きく完全一致のタイミングのキャプチャーが至難
これでも送受信データが一致していることはわかる

　この図だと受信データがずれて見えますが、送受信データは同じ形に再生されていることがわかります。実は、これ、受信データのタイミングが変動しているようで、受信データ波形が「スライディング」しています。なので、ぴたっと一致して、一本線に見えるタイミングをキャプチャーするのが難しかったので、こんな形で示しています。受信波形がスライディングする要因は、よくわかりませんが、Redpitayaから信号が出力されて以降、いろいろなモジュールを通過するので、これが影響しているのかもしれません。

　もっとも、復調信号が「時間的に」ずれているだけで、誤って復調されているのではないので（誤っていたらファイル転送時にエラーが起きる）、まぁ「よし」としたいと思います。


　次に、今度はQPSKに移りましょう。変調が変わるので、まずはGNURadio上でのシミュレーションとして、次回にでもRedpitayaを繋ぐことにします。まずは、確実な動作を期待して、GNURadio本家のTutorialからシグナルフローをもらってきました（というか、本家を参考にして自分で構築しました）。それに、例のごとく誤り検出のブロックを加えたのが下記のフローです。

ＱＰＳＫ伝送系のシグナルフロー

　動作の概要は本家の説明にあるので（英語ですが読みやすいので）、ここでは簡単に留めます。信号源はTutorialにあるとおり、ランダムな信号で、この信号レベル次範囲は、バイト表示で０〜２５５までです。Constellation Modulatorのバイト入力はこの形がデファクトのようです。なので、ビット列に変換するにはUnpack K BitsというモジュールでK=8としてやって、バイトデータをビット列に変換する必要があります。

　今回は、復調データとの比較はビット列で行いました。これは復調回路がビット列を生成するようにTutorialの例では構成されていたからです。

　Constellation Modulatorのパラメータ（object)もTutorialの通りです。QPSKですので、2ビットごとに、4つの位相にマッピングしたあと、ルートナイキストフィルタ（変調器モジュールに内蔵）を通過させて、ベースバンドのIQ信号を得ます。このあと、速度制限のThrottleを介したあとは、いつものPPCS,Costasを通ってQPSKの復調になります。この復調のビットマッピングもTutorialそのままです。オリジナルからは、Channel Model とCMA Equalizerを外してあります。完全に復調できたら、これらのモジュール加えて、特性変化の勉強を楽しむのもいいでしょうね。

　オリジナルの変調、復調信号の比較信号を見ると、きっちりそれらが一致しているような図がなかったので、ここではその実験をしておきます。以下に各部の信号を参考に載せておきます。このなかで、Packet Decoder Out vs Raw Dataを見てください。変調信号（青）と復調信号（赤）がまったく重なって見えます。このときのDelay=50で、何度やっても再現性があります。PC内シミュレーションでは気持ちがいいですね。当然、それらの差分を取ったErrorの図も０に張り付きという状況になります。

入力データ（バイト表示）




変調スペクトラム（いつものｍ＝０．３５）




変調信号のコンステレーション




ＰＰＣＳ通過後のコンステレーション




送受信データの比較

赤（送信）と青（受信）データ波形は完全に一致してエラーは無し
ＰＣ内シミュレーションなので安定度は良好

　今回はこの辺にしておきましょうか。

＜そのⅣ　ＱＰＳＫ/１６ＱＡＭの伝送＞　【2020.9.22】

　のっけから少し寄り道ですが、この夏の間はずっとGNU Radioの記事を書いていたのですが、こちらを訪れる皆様の興味をあまり惹かないのか、アクセス数は普段の2割減というところまで減っています。ツイッターで、HPにアップしたよと報じても、一瞬でアクセスは低位安定に戻ります（笑）。なので、今回は2回に分けようかと思っていたネタを、一回にまとめて、また、あまり詳しくは記せずに、サクっとGNURadioシリーズを一旦終わらせることにします。ディジタル通信というと、こんなシミュレーションよりも、実際に通信のできるＦＴ-ｘ等のほうが、圧倒的に興味があるのもよくわかります。なので、このあとOFDMとかのますますよくわからないシミュレーション（FFT/IFFTの概念が要りますから、場合によっては１アマでも手に余るでしょう）を延々とこちらで書いても、ほとんどの方は興味が持てないでしょうから、あまり深入りはしないことにします。

　ということで、前回はQPSKのコンピュータシミュレーションでしたが、今回は例によってRedpitayaを繋いで動作をさせてみましょう。前回のGRCファイルの中で、ベースバンド部分のI/Q信号をRedpitayaに入力してあげればいいということになりますね。そのシグナルフローグラフを下記に示します。

Ｒｅｄｐｉｔａｙａを用いたＱＰＳＫによるデータ伝送フロー

　信号源は以前に用いた40ビットの0/1データです。QPSK変調後はDCオフセット除去のための周波数シフトを行った後にインターポーレーションを行って（〜1.25Msps)、RedpiyataのTX側のI/Q入力に突っ込みます。 受信側は、受信ベースバンドのIQ信号をデシメーションして50kspsにまで落として、周波数変換してLPFを通したあとに、いつものPPCS、Costas　Loopを通過させて、QPSK復調したあと、ビットストリームに並べなおして、もとのデータ列が再生されます。 結論を書くと、以下の図のように、Delayがあるポイントで見た目のエラーがゼロとなり（復調データに誤りはないが、送信データと比較するには、適度な処理遅延補正が必要）、しっかり送信データが再生されていることがわかります。

Ｒｅｄｐｉｔａｙａを用いたＱＰＳＫによるデータ伝送時のエラーフリーの様子

　参考までに、送信側のConstellationを以下に示します。４０ビット長で、ランダム性に難があるのか、なんだかサンプリングされるデータに偏りが見られます。もっとランダムな信号なら、一様に、４点近辺のまとまるのでしょうが。

送信コンステレーション

　一応、復調され、周波数変換されて、中心が0Hzに戻ったスペクトラムも以下に示します。

送信スペクトラム

　最後はQPSK復調モジュール（Constellation　Decoder）に入力される受信側のConstellationを以下に示します。PPCSを通しているので、４点近くに収束していますが、位相オフセットがどうにも補正できずに、コンステレーションが「回転して」しまっています。ただ、この程度ならば、信号空間距離？は十分取れているので、誤りは出ないでしょう。なぜ、回転してしまうのかの原因は、よくわかりませんでした。

受信コンステレーション

　さて、次はQAM（直交振幅変調）に進みましょう。BPSK,QPSKと段階を踏んで来たので、だいぶ見通しが開けて来ました。以下に本当に基本的なシグナルフローグラフを示します。まずは、変調信号を振幅位相マッピングを行って、１６の値に振り分けます。

ＰＣシミュレーションによる１６ＱＡＭデータ伝送

　いつもと同じように、まずはPC上で送受信をベースバンドで実現していきます。それができれば、その間にRedpitayaを挿入して、エラー検出でノーエラーになれば一丁上がりという話になりますね（笑）。今回はQAM　MOD/DEMOなんていう、そのものズバリのモジュールがあって、なんだか楽ちんです。バイトデータを突っ込むと信号空間上に１６ポイントにマッピングして、さらに差動符号化、Grayコード化、おまけにルートナイキストフィルタによる帯域制限まで実施してくれちまうのがQAM MODなるモジュールです。ここまでくると、中身を細かく見ようなんで気が起きなくなってしまいますが、ま、そういったファンクションが、このモジュールで実現できているということで、ここではこれ以上深入りはしません。 １６QAMになると、I/Qのいずれの「軸」においても４つの状態を取りえます。これが４☓４の状態で１６の値の分別をしているということになりますね。以下の図はQAM MOD出力のI/Qデータをサンプリングしたものです。ReがI、ImがQのデータと思ってください。

１６ＱＡＭ送信信号（Ｉ/Ｑ）

　青線（Real＝I）、赤線（Image＝Q）のいずれもよく見ると、振幅レベルで４段階の値を取ることが見て取れるでしょう。もちろん、フィルタリングの応答として、瞬時に４値を移動するわけではないのですが、-1.5付近、-0.40付近、+0.4付近、+1.5付近の値を取っていることが見えますね。この値のI/Qの組み合わせで１６の状態を表すのが１６QAMというわけです。

１６ＱＡＭ送信スペクトラム

　一応、スペクトラムも上記の如く示しておきます。 で、最後は、送受信データが一致しましたよという証拠を以下のように示します。

送受信データ一致の様子

　さて、１６QAMのデータ伝送がPC上でうまく行きましたから、次はお決まりのRedpitayaに放り込む作業が待っています。以下はそのシグナルフローです。

Ｒｅｄｐｉｔａｙａを用いた１６ＱＡＭ信号伝送のフロー

　いつもの如く、MOD-DEMOの間をぶった切って、ベースバンドI/Q信号で、Redpitayaにインターフェースすることにします。もちろん、インターポーレーション＆デシメーションはお約束で実施しますが。このあたりになってくると、何度も説明しているので、もう、シグナルフローを見れば、何をやっているかわかるようになるでしょう。

１６ＱＡＭ送信データ信号（Ｉ/Ｑ）

　以前と同じように１６QAM変調されたI/Q信号を上記に掲げておきます。

１６ＱＡＭ送信信号のコンステレーション

　この送信信号のコンステレーションが上の図です。帯域制限をかけている応答で、１６点にきっかり「点の如く」サンプリング値が集まるわけではないようで、なんとなーく4*4＝１６点の「あたり」にあるのがわかります。

１６ＱＡＭ送信スペクトラム

　上図は送信スペクトラムです。今回はDCオフセットのための周波数変換はやらないことにしました。変調方式が複雑化すると、あまりそれ以外の不確定要素で信号伝送が不確実になることを避けたいからです。 で、これをRedpitayaで受信してみたコンステレーションが以下の図です。

Ｒｅｄｐｉｔａｙａによる受信信号のコンステレーション

　これを見るに、以前のQPSK同様に、位相変化で少し反時計周りにローテーションしていますね。もし、QAM　Demoのモジュールが固定された位相（例えば0度）をもとに閾値判定しているとすると、このローテーションは致命的で、まったく復調できないように思えます。ところが、ここで事例を出したということは、次の図に示す如く、しっかり、送信データが復調できているので、このQAM DEMOのモジュールはある程度の位相回転に関しては補正できる機能が入っているのではないかと考えています。これは、正直のところ確証があるわけではないのですが、そうでも考えないと、エラーフリーになる理由が見当たりません。

送受信データの一致

　ということで、送受信データが一致している図を上に示します。DEMO　Outの表示は、送信データ(青）と受信復号データ（赤）が一致している様子が見て取れるでしょう。

　さて、BPSKに始まり16QAMにまでたどり着きましたが、いかがでしたでしょうか？本当は、エラーフリーの状態から、いろいろな外乱（ノイズ、干渉）を印加して、誤り率特性を見るとかやりたいのですが、それに関しては、バックグラウンドで実施し、ある程度意味のある結果がでたら、アップしたいと思います。