前回は、WAVをMP3に変換するためのWindows用ソフトを作りました。今回はファイルの中から外へ出て、実際の電波を相手にしてみます。
作るのは、SDR（Software Defined Radio）、ソフトウェアで信号処理を行う無線のソフトです。名前は「AF-SDR」にしました。
受信に使う、RTL-SDR BlogのUSBドングル（V3）です。PCに挿し、アンテナから入った電波をデータとして渡します。この小さな受信機の先を、AIに作らせます。
これまでのゲームやWindows用ツールは、遊んだり使ったりすれば出来を判断できました。SDRは、FFTやI/Qといった言葉が普通に出てくる分野です。ある程度の専門知識が要るソフトを、AIにどこまで任せられるのか。このシリーズでは、それを試します。
開発の仕事自体は長くしてきましたが、今回もコードは書かず、指示と確認だけで進めます。詳しい背景は「私とAIコーディング」にまとめています。
といっても、最初から多機能な受信ソフトを作るつもりで仕様を並べたわけではありません。まずは手元の受信機をつないで、その周辺の電波がグラフで動いて見えるところまで。音を出すことさえ、初回の対象から外しました。
ところが、動いたものを触ると、次に欲しいものが出てきます。時間の変化も見たい。グラフをクリックして周波数を変えたい。受信条件も自分で調整したい。
今回は、最小構成の1.0.0から、そうした注文を重ねた1.4.0までの記録です。
※Codexは、ファイルの作成やコードの実装・テストなどをAIに任せられるOpenAIの開発ツールです。使用環境や相談と実装の使い分けは、準備編にまとめています。
受信機が動くことは、先に確かめておく
受信機は、冒頭の写真のドングルです。まず既存の受信ソフト「SDR#（SDRSharp）」で動かしました。久しぶりの起動でしたが、受信できました。電波の入りがよいとは言えないものの、ハードウェアが動くことは確認できています。
この準備は、AIへ頼む範囲を絞るためでもあります。これから作るソフトで何も表示されなかったとき、受信機やドライバの問題から疑うのでは、話が広がりすぎます。
RTL-SDR用のDLLと、その呼び出し方を確認できるソース一式も用意しました。CodexにはC#・.NET・WinForms・x64という開発環境と、使うDLLを指定しています。Windowsの画面を持つソフトとして作ってもらいます。
一方、スペクトラムを作る具体的な信号処理方法は指定しませんでした。
最初の注文には「実装しないもの」も書いた
初回に欲しかったのは、受信機への接続、中心周波数の入力、実際の受信データの取得、そしてスペクトラム表示です。スペクトラムは、どの周波数にどれくらいの強さの信号があるかを見るグラフです。
依頼文には、あえて次のように書きました。
現段階では以下は実装しない。
- ウォーターフォール
- AM/FM等の復調
- 音声出力
- デジタル信号の処理
まずは「受信したものが見える」だけで十分です。そこが動くかを見てから、先を考えることにしました。
Codexが返してきた初回版は、受信したI/Qデータを4096点のFFTで処理して表示するものでした。I/Qは信号を二つの成分で表したデータ、FFTはそこから周波数ごとの成分を取り出す計算です。ここでは「受信機から来た数値を、周波数のグラフにする処理」くらいで読み進めてください。
ログに表示された作業時間は4分43秒。コードだけでなく、起動できる実行ファイルと検証結果まで返ってきました。ただし、Codexの報告は「実機での受信表示は未確認」です。
そこで、こちらで起動して接続します。ビルドや手元でできる検証まではCodex、実際の電波で確かめるのはこちら。この分担は、シリーズの最後まで続きます。
最初のAF-SDRです。周波数の入力欄とスペクトラムがあり、まだウォーターフォールも音声の操作もありません。
問題なく動きました。こちらが用意した受信機からデータを取り、画面が更新されています。
受信機を扱うソフトでも、まず動くところまで文章で頼めました。この時点で、次の注文を出したくなりました。
動いたら、時間の変化も見たくなった
次にCodexへ渡した指示は、実機での確認報告から始まっています。
スペクトラム表示が実機で正常に動作することを確認した。 次にウォーターフォール表示を追加する。 あわせてスペクトラム上でマウスカーソルが指している周波数を確認できるようにし、その位置を操作して中心周波数として設定できるようにする。
ウォーターフォールは、信号の強さを色にして、時間の経過に沿って並べる表示です。その瞬間のグラフに加えて、少し前からどう変わったかも見られます。
1.1.0では、画面の下にその表示が付きました。スペクトラムにマウスを置けば周波数が分かり、左クリックすると、その位置を受信の中心にできます。
最新の信号が上に入り、過去の表示が下へ流れます。グラフは眺めるだけでなく、周波数を選ぶ操作面にもなりました。
ただ、周波数を変えるたびに受信をいったん停止して再開するなど、使い勝手には気になるところもありました。
当時の私の評価は、「指示したことは仕事してる」です。そのあたりの操作感までは、まだ注文していません。まず追加された機能を確かめて、次へ進みました。
「78,400,000」より「78.4M」と入力したい
実際に周波数を変えていると、Hz単位の長い数字を毎回入力するのが気になります。78.4 MHzなら、「78.4M」で済ませたい。
そこで、次のような入力を受け付けるように頼みました。
78.4M → 78,400,000 Hz
8400k → 8,400,000 Hz
100M → 100,000,000 Hz
500k → 500,000 Hz
1.2.0では、この入力が通るようになりました。不正な文字を入れたときには受信を止めず、入力の問題として扱います。
「78.4Mを解釈した。及第点。」というのが、そのときの感想です。
ただ、この版は「78.4M」を受け付けたあと、欄の表示は「78,400,000」に整えます。入力できることと、入力後にどう見せるかは別の注文でした。
受信条件を触れると、ぐっとそれらしくなる
次は、サンプルレート、RFゲイン、表示帯域を追加しました。
サンプルレートは受信データを取り込む速さで、扱う周波数の幅にも関係します。RFゲインは受信側の増幅の設定。表示帯域は、取り込んだ範囲のうち画面に見せる幅です。
この三つを選べるようになった1.3.0は、だいぶそれらしくなりました。
取り込む帯域のうち、中心付近の100 kHzを拡大して見ています。表示帯域だけを変える場合は受信を止めず、ウォーターフォールの過去の表示も同じ幅で描き直します。
ここで感心したのは、RFゲインの候補の作り方でした。Codexは接続したドングルから設定可能な値の一覧を取得し、選択肢にしています。さらに、設定した値を読み戻して確認する処理も入っていました。
「手動の場合はRTL-SDRで設定可能なゲインを選択できるように」とは頼みましたが、APIをどう呼び、どう確かめるかまでは指定していません。その部分が実装として埋まってきたわけです。
FFT点数を増やしても、画面の速さが変わらない？
受信条件を触れるようになると、今度は4096点固定のFFTも変えてみたくなりました。
同じサンプルレートなら、FFT点数を増やすと周波数を区切る間隔が細かくなります。表示を拡大する操作とは別に、計算する細かさも選びたくなったのです。
実用的な候補をドロップダウンにするよう頼むと、1.4.0では1024、2048、4096、8192、16384点が選べるようになりました。
実機で切り替えてみても、画面の更新速度は概ね一定です。そこで、機能の追加をいったん止めました。
ここではコードを変更しないこと。
と断ったうえで、受信したデータをどのようにFFTへ渡し、窓関数や平均化を使っているか、なぜ点数を変えても画面の速さがあまり変わらないかを説明してもらいました。
動いているのは分かった。でも、この見え方はどういう処理の結果なのか。
Codexの説明で、画面更新はFFTの実行とは別の40 ms間隔のタイマーで行い、その時点の最新結果を表示していることが分かりました。FFTを1回計算するたびに、画面も1回描き直しているわけではありません。
また、Hann窓というFFT入力の端を滑らかにする処理と、周波数ごとのパワーをならす平均化も、すでに入っていました。こちらは種類や係数を指定していません。最初に任せた「適切な方法」の中で、Codexが選んでいた処理です。
一方、処理が追いつかないときは古い受信ブロックを捨てる構成でした。画面が滑らかに動くことだけでは、受信したすべてのデータを処理できているとは言えません。実際にどれだけ捨てたかを数える機能も、この版にはありませんでした。この時点では、画面で見る用途には十分と判断して先へ進みました。
欲しい画面はできています。ただ、表示の意味を知るには、何を計算して見せているのかを聞く必要がありました。
電波が見えるようになった。では、音も聞きたい
最初は接続してスペクトラムを表示するだけだった画面に、時間の変化、クリック操作、入力の省略、受信条件、FFT点数の選択が加わりました。
まとめて完成仕様を渡したのではありません。動いたことを確かめ、その画面を触ってから、次の注文を出しています。私の側も、最初からすべての操作や内部処理を決めていたわけではありませんでした。
ここまで来ると、画面に見えているFM放送を聞いてみたくなります。
次に出した要求は、これでした。
次の段階として、FM放送を受信して音声を聞けるようにする。
初回に「実装しない」と書いた音声出力へ進みます。次回は、AF-SDRが実際にラジオとして鳴り始めてからの話です。
ソース一式と最新バイナリー
AF-SDRとAF-SignalGeneratorのソース一式、現在の公開版はGitHubから利用できます。この記事は制作当時の記録で、最新バイナリーの内容とは異なる場合があります。導入条件と起動方法は最終回の配布案内をご覧ください。
コメント