2018年5月31日木曜日

マッチドフィルタ/パルス圧縮/FFT相関




 上がマッチドフィルタ風、下がパルス圧縮風。
 受信信号と想定した正弦波は-1から+1の範囲を取る。ノイズと想定した疑似乱数は-1から+1の範囲を取る。

 マッチドフィルタ風は「ΔFが0なパルス圧縮」、つまり圧縮比が0のパルス圧縮と見ることができる。実際、上記のグラフはΔFの違いしか無い。

 マッチドフィルタでは近い範囲にエコーがあると判別ができない。パルス圧縮では十分に見分けることができる。

 レーダーの探知性能は送信出力とパルス幅の、いわゆる力積と呼ばれるもので、ざっくり言えばパルスの振幅とパルス幅の積がレーダー波のエネルギーになる。エネルギーが大きいほど遠距離の、あるいは小型な目標のエコーを拾うことができる(受信感度等は割愛)。
 この図ではマッチドフィルタもパルス圧縮も同じ振幅、同じパルス幅なので、どちらも探知性能としては同様。ただしパルス圧縮のほうが距離分解能が高い。また、パルス圧縮のほうが立ち上がり・立ち下がりが急峻であり、距離精度が改善する(目標のエコーが遠近方向に広がらずに表示される)。

***


 この図は、上がチャープ信号をFFT解析したもの、下はそれをIFFTに通したもの。

 FFT解析には下記ブログのソースコードを流用した。
 C#で画像処理 高速フーリエ変換(FFT)
 C#で画像処理 逆高速フーリエ変換(IFFT)

 FFT結果は凄まじいことになっているが、IFFTを通すとちゃんと元通りになる。

***


この図は、パルス圧縮の波形を単純な積で計算したものと、FFTを使って計算したものの比較。赤がfor2重ループで計算したもの、緑がFFTで計算したものだが、どちらも同じ結果になっている(最後の方が一致していないのはサンプル数の問題)。
 正弦波が±1なのに対し、ノイズが±5程度あるが、十分な強度としてパルスが見えており、狭い範囲にある2つのパルスを判別することができる。


 以下のページを参考にした
 離散フーリエ変換(3) - 畳み込み定理 - uhiaha888’s diary

 for2重ループは時間領域、FFTは周波数領域、というタイプなのかな?
 とある本によると、入力信号と基準波形をDFT計算し、その結果を乗算後に逆DFTに通す、というふうに書いてある。処理としては積をDFTに通せばいいらしい。
 それと、入力信号が1024サンプル、基準波形が128サンプル、といった場合、基準波形を1024サンプルになるようにゼロ埋めし、それらをFFT解析してから積をとり再びFFTに入れる、という処理になるらしい。
 また、次の入力信号の解析を行うときは、基準波形分の128サンプルの領域が重なるように処理する必要がありそうな気がする。とはいえ、これに関してはfor2重でも同じような問題が出てくるので、欠点と言えるほどではないかも。

 基準信号・入力信号ともにスペクトルの大部分が低周波領域に集中しているから、乗算を行うのは全体の2%程度で済んでいる(サンプリング周波数と目的の周波数の関係で変わるはず)。今回はサンプリング周波数とチャープ信号の中心周波数の比が200なので2%で済んでいるが、実際はこの比は20とかそれ未満の場合もあるだろうから、本来であればFFTのかなりの領域の積を取る必要があるはず。

 基本的にレーダーであれば基準信号がコロコロ変わることは少なく、近距離と遠距離で送信波を変える場合でも数種類で済むはず。ということは、基準波形のFFTは最初の1回行えば済むわけだから、データ解析のときは入力信号のFFTを行い、その積を再びFFTに入れる、という処理だけでいいはず。とはいえ、FFT2回分の計算量がどの程度になるのか。
 実際のレーダーでは50MサンプルくらいのFFT解析になるのかもしれない。とてつもない分量。

 非常にざっくりとした数値だけど、今回の16384ポイントの相関処理では、forだと220msec、FFTだと8msec程度で終わっている。かなり早い。

 入力信号、基準信号、出力波形は実部のみだが、入力信号と基準波形の結果、それとその積は虚部も必要になる。PCで処理するなら問題にならないデータ量だが、組み込み機器、特にワンチップマイコンで外付けRAMなしの場合は非常に厳しいと思う。
 必要なメモリは6x入力信号くらいか。入力信号が16384サンプルなら、必要なメモリは384KiB程度(float32の場合)。他に一時的なテーブルが必要になる。FFTのIN/OUTを16bitで計算するならその半分としても200KiB程度必要になる。
 STBeeF4miniだと100KiB程度しか使えないので、8192ポイント程度しかできないか? 8kポイントだと距離にして1.5m程度のゲート幅しか得られない。ただし8kポイントを取得するのに10msecかかるから、FFT2回が6msec程度で終わるなら結果を記録するメモリが足りる分だけ延々とサンプリングできる。


 まずはARMコアでFFTがどれくらい動くかを確かめる必要があるか。DSP_LibにFFTっぽいライブラリがあるけど、使ったことがないのでちゃんと動くかどうかをテストしなければ。それがちゃんと動けば、適当な値でFFTを通して処理時間を測って。十分に短い時間で処理できるならいろいろ遊べそうだ。
 FFTとかちゃんと動くなら、適当にパッケージの大きなF4を買ってきてSRAMを外においたほうが使いやすいかもしれない。
 別件でFFTがあると便利そうだと思ってる部分があるので、それも含めてFFTの評価は軽くやっておきたい。

0 件のコメント:

コメントを投稿