1

USRP N210 から FFT データをキャプチャしてプロットする小さな GNU Radio プログラムを作成しました。

GUI (matplotlib と wxpython) がロックされないようにするために、GUI がアイドル状態であると報告した後にのみフローグラフを実行しています。

この種のタイミングを行うために、GNU ラジオ チュートリアルで紹介されている非フローグラフ中心のアプローチを使用しています。

基本的に、次のようなメイン ループがあります (疑似コード)。

topblock.set_usrp_freq()
while True:
    topblock.run()
    data = topblock.vector_sink.data()
    thread-safe call to plot data
    wait for gui.EVT_IDLE
    topblock.skiphead.reset()
    topblock.head.reset()

フローグラフは基本的に次のようになります。

self.connect(usrp, skiphead, stream_to_vector, head, fft, c2mag_sq, stats, volts_to_dBm, vector_sink)
# skiphead is modified to be resettable like head

同様のパラメーターを使用すると、実行したときに表示されるものと同じことが期待されますuhd_fft -f 700M -s 10e6uhd_fft 正常に見える

私のmatplotlibプロットからの出力は、非常に顕著なLOを除いて、最初は非常に似ています。私はコードをたどってみましたが、uhd_fftLOオフセットを行っているのが見えないので、最初の質問はQです. LOを発音させるループ? ここに画像の説明を入力

編集:極端なLOは、フローグラフが「run()」されるたびに発生する電圧スパイクの副産物であることを確認しました。LO に下げるためにドロップする必要があるサンプルの数は、私のフォローアップ投稿の時間データで確認できます: Python からの単純な GNU ラジオ フローグラフを使用する場合の USRP からの電圧パルス

2 回目の実行後、uhd_fft では絶対に起こらない奇妙なデータが定期的にプロットされます。ブロックを使用してフローグラフを実行するたびに数千のサンプルをダンプすることでこれを解消できますskipheadが、2 番目の質問は次のとおりです。戻った? uhd_fftフローグラフ中心のプロセスを使用しており、この問題はありません。 ここに画像の説明を入力

私の直感では、フローグラフを中心としないアプリを実行する場合、チュートリアルには記載されていないいくつかの注意事項があります。

4

0 に答える 0