同僚が開発した GNU ラジオ アプリケーションの Web フロント エンドを開発しています。
2 つのブロックの出力に接続している TCP クライアントがありますがTCP Sink、データのエンコードが期待どおりではありません。
1 つTCP Sinkは複雑なデータを送信し、もう 1 つは float データを送信しています。
各 4 バイトのチャンクをfloat32値として読み取ることにより、クライアントでデータをデコードしています。サーバーとクライアントはどちらもリトルエンディアン システムですが、(GNU RadioEndian Swapブロックを使用して、またクライアントで手動で) バイト スワッピングも試しましたが、データはまだ正しくありません。実際には、バイトオーダーの不一致がないことを確認すると、さらに悪化します。
適切な GUI 要素を使用して GNU Radio Companion でフロー グラフを実行すると、プロットが正しく表示されます。データ値は、0 から 10 の間で期待どおりに表示されます。
ただし、クライアントでデコードされる値は一般に 0.00xxxxx 前後であり、プロットは GNU Radio で見られるような単純なトーンではなく、ノイズのように見えます。手動で 1000 を掛けてデータをスケーリングしても、ノイズのように見えます。
短いので GNU Radio でプレ D パスについて説明しますが、ポスト D パスでも同じ問題が見られます。ここでは aWBFM Receiveと aRational Resamplerが追加され、その後にThrottleブロックが続き、次にTCP Sinkフロート データを送信するブロックが続きます。
File Source (Output Type: complex, vector length: 1) =>
Throttle (vector length: 1) =>
Low Pass Filter (FIR Type: Complex->Complex (Decimating)) =>
Throttle (vector length: 1) =>
TCP Sink (input type: complex, vector length: 1).
これは、ストリーム パラメーターを指定する正しい方法のようです (実際、ストリーム アイテムと一致しない変更を行うと Companion はエラーを表示します) が、ストリームの反対側でデータを正しくデコードする方法が見つかりません。