こんにちはドルフィンシステムの笹生です。
今日は以前の記事「USRPのスパイクノイズ現象(1), (2) 」に続き USRP-2954等 X310系 USRP での不可解な現象についてお知らせです。
以前の記事では、弊社アプリと USRP-2954や USRP-2943 を用いたテスト中に、「正弦波受信中に数十秒に一度程度、スパイク状のノイズが観測される」という現象について紹介しました。アプリの不具合を疑いましたが、ドライバのサンプル単体でも現象が再現されることを確認したものの、原因はまだ特定できていないという段階でした。
今回の記事では上記の現象について NI に調査依頼した結果について連絡が参りましたのでご報告と考えうる対処案を紹介したいと思います。
USRP のスパイクノイズ現象の原因
さて、この USRP のスパイクノイズの原因ですが、NIから調査結果をいただきました。R&Dからの回答を原文のままご紹介します。
It sounds related to a known HW issue on the ADC (TI ADC) where it periodically has "bit flips" referred to as sparkle codes, thus if it is that problem we are unable to resolve it.
日本語訳としては「これは、スパークル コードと呼ばれる「ビット フリップ」が定期的に発生する ADC (TI ADC) の既知のハードウェアの問題に関連していると思われます。そのため、その問題である場合は解決できません。」
ということのようです。
R&Dとしても、完全に確定しているわけではないようですが、既知のハードウェアの問題である可能性は非常に高いと思われます。
対処可能なのか？
残念ながら回答にもあるようにもし既知のハードウェアの問題であれば根本的な解決はできないかもしれません。
しかしハードウェアの問題前提で何とか対処する方法はないのか考えてみました。
チャッピーさんと一緒に考えてみたところいろいろな案がある中で、ソフトウェア的、FPGA的に対処するには以下の方法がいいとなりました。
3) 残る bit flip を「検出して無害化」する（いちばん現実的）
ここが一番効きます。4096 (=2^12) が本当に 単独ビット反転なら、補正はかなり強力にできます。
A. FPGA での “ビットスクラバ（bit scrubber）” が最適解
基本アイデア：異常サンプルだけを検出して、
(1) そのビットを XOR で戻す か
(2) サンプルを補間（前後の平均/線形補間） か
(3) その1点をブランキング（0/前値保持）
に置き換えます。
誤補正を避ける「鉄板の検出ロジック」
単純に
x[n] XOR x[n-1] == (1<<12)だけだと、たまたま信号がそう変化した場合も拾います。
おすすめは 3点判定：
d1 = x[n] XOR x[n-1]
d2 = x[n] XOR x[n+1]d1 と d2 がどちらも (1<<12) のときだけ「真の bit flip」と認定
→x[n] = x[n] XOR (1<<12)で復元これだと、「真ん中だけがひっくり返っている」形にしか反応しないので、誤補正が激減します。
（I/Q それぞれで独立に適用できます）実装コスト：FPGA なら **数サンプル遅延（1～2）**で済むのに対し、効果は非常に大きいです。
B. ホスト（PC）側でやる場合の現実的な落とし所
リアルタイム性が不要なら、収録後に同じ 3点判定で修正できます。
リアルタイム処理でも、サンプルレートが高いと CPU で厳しいので、FPGA 側で前処理してから DMA が王道です。
ここにもあるように今回の事象ではどうも常に 4096 に相当するビットが反転するようなので、FPGA でその部分を監視するのが一番いいかもしれません。
IDL での開発であれば、こうした回路を受信側の入力直後に入れることで緩和される可能性は非常に高いです。（チャッピーの判定方法は名称かっこいいですがちょっと甘さがありそうなのでここは慎重に考えてみたいと思います）
まだ試していませんが、またこれも試したら報告したいと思います。
まとめ
現象の原因はわかったのですが、根本的な解決はできないということです。
とはいえ、緩和策を考えることができたので、後日試してみたいと思っています。
0 件のコメント :
コメントを投稿