- リンクを取得
- ×
- メール
- 他のアプリ
こんにちはドルフィンシステム福島です。
早いものでもう9月。
暑さも大分和らぎ、夜は虫の音も聞こえるようになりました。
ｰｰｰｰｰｰｰｰｰｰ NI Days 2018 : 2018 / 10 / 5 (金) ｰｰｰｰｰｰｰｰｰｰ
NIDaysは「LabVIEW」を中心としたNIプラットフォームベースアプローチを活用した、最新システムや業界動向などを紹介するイベントです
今年はドルフィンシステム福島が講演をいたします。
技術セッション
トラック D : 半導体 ・ ワイヤレステクノロジー
2018 / 10 / 05 : 13:00～
D-1 「年間11本のSDR開発案件を「たった2人」でこなすドルフィンシステムのSDR活用術」
株式会社ドルフィンシステム 取締役 福島幹雄
ぜひお申し込みを！
ｰｰｰｰｰｰｰｰｰｰ NI Days 2018 : 2018 / 10 / 5 (金) ｰｰｰｰｰｰｰｰｰｰ
USRP Bシリーズ
USRPにはBシリーズと呼ばれるUSB接続のUSRPがあります。
開発元のEttus からはB200/B210という製品が販売されており、ほぼ同型がNIからUSRP-2900/2901として販売されています。
USRP-RIO等と比べあまり利用される機会は少ないのですが、USBケーブル1本で接続できて手軽に信号の入出力が出来るのでそれなりに使い勝手は良いです。
ですが、Bシリーズ最大の問題点はIQデータ落ちが発生しやすいということ。
USRP-RIOの場合、USRPとPCの間はPXIeバスでデータをやり取りします。
PXIeバスはDMA転送されるため、データ転送はハードウェアレベルで保証されます。
(もちろんバスが混み合っていたり、 転送するデータ量がバスの容量を超えていたり、受信側のソフトの動作が遅すぎたら駄目ですが)
対してBシリーズは、USBバルク転送を行うのでユーザプログラムがIQデータを受け取る必要があります。つまりUSRP BシリーズからIQデータを取得するプログラムは確実にIQデータを受信しなければなりません。またCPUパワーを消費するプログラム(突然動作するウイルスチェックなど)が動作すると、その瞬間にデータ落ちが発生します。
OSはユーザが気づかないところで動作する事があり、これに影響を受けやすいのが安定性にかけるのがUSRP Bシリーズです。
ですので、USRP Bシリーズはリアルタイム性が必要とされるアプリケーションにはなかなか使いにくいUSRPです。
USRP B200でPLLロックエラーが発生
前置きが長くなりましたが、ここから本題です。
この間、間欠受信のアプリケーションがありB200を採用して色々調査していたところ、問題が発生しました。
何故かIQデータを受信する際にPLLロックが出来ないというエラーが発生したのです。
今回はこの問題に対処したいと思います。
エラーコード : -1074118625
niUSRP Initiate.vi<ERR>The reference clock PLL did not lock within the allotted time.
受信を開始するとPLLエラー
USRP Bシリーズは、NI-USRPドライバに対応しているのでNI-USRPサンプルが動作します。
今回は単純にデータを受信し続ける、
- niUSRP EX Rx Continuous Async.vi
を使いました。
以下のようにデバイス名を入力し、受信を開始すると時間軸のI/Qデータとスペクトラムが表示されます。
ですが、何度か繰り返していると、PLLエラーが発生します。
エラーの発生条件ですが、ノートPCで実行したときはIQレートを上げると発生する頻度が高くなりました。1Mspsではエラーは起きませんでしたが、10Mspsを超えると発生しだし正常だったのは10回中3回でした。
別のデスクトップPCで実行した際は、1Mspsでもエラーが発生し10回中1回だけ正常という有様です。
エラーの発生箇所は、niUSRP Initiate.viと呼ばれる、I/Qデータ取得開始する関数です。
niUSRP EX Rx Finite Sync.viは問題なし
色々試してみましたが、埒があきません。
そこで、
- niUSRP EX Rx Finite Sync.vi
という「1回だけデータを受信して終了する」動作を行うサンプルVIを実行してみると、あっけなく実行できました。
I/Qレートを上げても問題は発生しません。
違いはどこなのか？
エラーが発生しているのはniUSRP Initialte.vi関数なので、それ以前の処理がエラーに関係してそうです。
違いを見てみるとエラーが発生していない方は、受信タイミングやリファレンスクロックの設定などを行っていることが分かります。
エラーがない方の処理
エラーがある方の処理
この処理の違いがエラーの発生有無を分けています。
そこで「エラーがない方の処理をエラーがある方にコピペして動作を確認する」という原始的な手段で、原因を探しました。
まとめ
結局のところ、プロパティノードを使用して"Reference Frequency Source"を明示的に指定すれば、PLLロックエラーは発生しませんでした。
普段USRPに外部リファレンスクロックを与える以外は、デフォルトの値 "Internal"で実行するので改めて設定を行うことはありません。
ですが、USRP Bシリーズの場合、"Reference Frequency Source"を明示的に設定しておかないと、USRP Bシリーズはソースリファレンスクロックが分からなくなってしまう（？）ようです。
エラーが発生しなくなったサンプルVI
私たちドルフィンシステムでは、今回ご紹介したように色々と試行錯誤を行いながら、ドキュメントには表れてこないエラーなどが発生しても解消に向けて取り組んでいます。これらの取り組みの成果を公開しSDRに携わる方々の生産性が向上できれば幸いです。
以上、ドルフィンシステム福島でした。
ｰｰｰｰｰｰｰｰｰｰ NI Days 2018 : 2018 / 10 / 5 (金) ｰｰｰｰｰｰｰｰｰｰ
NIDaysは「LabVIEW」を中心としたNIプラットフォームベースアプローチを活用した、最新システムや業界動向などを紹介するイベントです
今年はドルフィンシステム福島が講演をいたします。
技術セッション
トラック D : 半導体 ・ ワイヤレステクノロジー
2018 / 10 / 05 : 13:00～
D-1 「年間11本のSDR開発案件を「たった2人」でこなすドルフィンシステムのSDR活用術」
株式会社ドルフィンシステム 取締役 福島幹雄
ぜひお申し込みを！
ｰｰｰｰｰｰｰｰｰｰ NI Days 2018 : 2018 / 10 / 5 (金) ｰｰｰｰｰｰｰｰｰｰ
コメント
コメントを投稿