PCサウンドカードの出力を介してデジタルデータを送信するのに適したデジタル変調方式


8

アクセス可能な出力周辺機器がオーディオインターフェイスのみであるコンピュータシステムから、以上でデータストリームを出力する必要があります。このインタフェースは、合理的なスペック、有する96  kHzのサンプリングレートと24 - ビット分解能が、出力段は、AC結合です。使用できる出力チャネルは1つだけです。良い仮定は、それが1  dB未満の減衰で4  Hzから40  kHzの通過帯域を持つバンドパスフィルターのように動作することです。また、SNR は90  dBです。エミッタに他の複雑さの制約はありません。40 kbit/s96 kHz24bit4 Hz40 kHz1 dB90 dB

エミッターとレシーバーを接続しているケーブルに追加のノイズ/減衰はありません。

レシーバーは、 Cortex-M3 MCUを備えた組み込みシステムです。必要に応じて、同様のオーディオ取得パフォーマンスを想定できます。追加の専用復調チップ(このような低周波数にそのようなものが存在する場合)はオプションになる可能性があります。120 MHz

  • この状況にはどのデジタル変調方式が適していますか?
  • ホイールの再発明を妨げるコードライブラリ(ソフトウェア定義のラジオライブラリ?)はすでにありますか?
  • 私がインスピレーションを探すことができる同様の制約を持つ既存のアプリケーションはありますか?

スピーカーを通過しないと思いますか?
ジム・クレイ

いいえ、サウンドカード出力とレシーバー間のケーブルを短くするだけです。
ピシェネット2012年

回答:


8

ここにはかなり良い状況があります。あまり問題なく目標を達成できるはずです。変調のクラス全体を排除するような記述は見当たらない(たとえば、位相シフトキーイング周波数シフトキーイングなど)。適切なフォーマットの選択に入るいくつかの要因は次のとおりです。

  • 必要なスペクトル効率(使用可能な帯域幅と比較して必要なデータスループットの大きさ)
  • 受信機の複雑さの要件(通常、システムの最も複雑な部分です)
  • 実装の開発にどの程度の労力を費やして取り組むか。
  • アプリケーションに固有のその他の状況(たとえば、一端または両端のタイミング精度が低い、既知の干渉、またはチャネル応答が悪い場合)

それで、あなたのシステムのためにこれらを一つずつチェックすることで、いくつかのガイドラインを思いつくことができます:

  • 最大の制約は、チャネル応答(サウンドカードのDACによって制限される)のようです。40 kHzの片側帯域幅を利用できる場合、シンボルレートはそれよりやや低い値に制限されます。1秒あたり少なくとも40キロビットのターゲットデータレートの場合、シンボルごとに複数のビットを送信するスキームが必要です。

  • 組み込みプラットフォームに他の多くの機能が搭載されていない場合、最新の120 MHz ARMプロセッサは、数十キロビット/秒の範囲のほとんどすべてのフォーマットの復調を簡単に処理できるはずです。

    具体的にはどのモデルで実行しているかはわかりませんが、最近の多くのプロセッサは、オンボードADCとメモリおよび割り込みサブシステムを非常に緊密に統合しているため、(手動のCPU介入なしで)指定した入力信号を自動的にサンプリングできますレートし、サンプルをオンボードメモリに保存し、特定のサイズのサンプルブロックを処理できる場合にのみプロセッサ割り込みをトリガーします。少なくとも一部のAtmelデバイスがこの種の機能を提供していることを知っています。私は過去に彼らとうまく成功したことがあります。

  • EbN0

  • 特別な事情がある限り、このシステムではほとんど何も期待できません。PC側の発振器の精度はかなり良好であると予想します(最低限の水晶で制御されているため、50 ppm程度の範囲にあります。他のより正確なソースを使用して発振器を校正すると、おそらくはるかに良くなります。 )。埋め込み側も同じである可能性があります。クロック源として水晶発振器を使用していると思います。両端がケーブルで接続されているので、ノートの干渉がないと仮定します。

したがって、これらすべてをまとめて1つの推奨にまとめると、おそらく24キロシンボル/秒で直交位相シフトキーイング(QPSK)アプローチのパスを開始します。シンボルあたり2ビットで、これは48キロビット/秒のデータレートを生成します。これは要件を超えています。この特定のレートにより、実装が少し簡単になります。出力DACは96 kHzで実行されているため、これによりシンボルごとに4つのサンプルが生成されます(シンボル時間ごとに整数のサンプル数で実行する方が常に簡単です)。可能であれば、埋め込み側を同じ96 kHzレートでサンプリングするように設計しようと思います。これにより、リソース不足のエンドでリサンプリングを行う必要がなくなります。

サウンドカードDACが採用するDCノッチの問題を回避するには、QPSK信号を24 kHzのキャリアに変調します。次に、変調された信号のスペクトルにはDCでヌルがあり、ノッチと一致します。ノッチがまったく問題にならない可能性があります(特に、提案されているように本当に幅がほんの数Hzの場合)。その場合、キャリア変調を完全にバイパスして、ベースバンドでのみ機能するさらに単純なスキームでうまくいく可能性があります。

QPSKは、送信機と受信機の両方で単純であるため、適切な選択です。SNRでは、直交振幅変調(QAM)のようなより複雑なスキームを使用してスペクトル効率を高めることができますが、PSK信号の一定エンベローププロパティは、受信機の複雑さの観点から魅力的です。注意として、将来的にシンボルあたりより多くのビットが必要になった場合は、8または16-PSKのような高次のPSKコンスタレーションに移行できます。ただし、これらは、QAMコンスタレーションと比較した場合、ビット誤り率のパフォーマンスの観点からは最適ではありません。

ライブラリの実装に関して言えば、特に組み込みプラットフォームの場合、あなたが立ち寄って行くことができるものは何も知りません。レシーバーの実装は、ハードウェアインターフェイスとある程度結びついている可能性があります。復調器に必要なさまざまなステップのいくつかの既存の実装を見つけることができる場合がありますが、プラットフォームで適切に機能するように、見つけたものを少なくとも微調整する必要があります。GNUラジオあなただけの信号処理動作を、多くの異なる通信のC ++実装を見たい場合はプロジェクトが見た目に良い場所であり、それもあなたのPC車載送信機を実装するための有用な枠組みをもたらすかもしれません。要約すると、受信者が実行する必要がある高レベルの手順には、次のものが含まれます。

  • ゼロ以外のキャリア周波数が使用された場合:

    • 周波数同期:送信機と受信機の間の発振器の不一致によるキャリア周波数オフセットを特定して追跡します(多くの場合、その周波数オフセットは時間とともにほぼ一定です)
    • キャリア復調:信号をベースバンドに変換し、2つの同相および直交(I / Q)信号を生成します(多くの場合、複素ベースバンド信号として表されます)。
  • 一致したフィルタリング:送信機で使用されるパルス形状に一致するフィルターにベースバンド信号を渡します(矩形パルスで回避できる可能性があります)。
  • タイミング同期:シンボル遷移に対応する時間を特定して追跡します。これは、シンボル時間を法とするマッチドフィルター出力のピーク位置を追跡することで実行できます。
  • ビットスライシング:シンボルサンプル時間で一致したフィルター出力をハードビット決定に変換
  • シリアル化:シンボルごとに複数のビットを正しい順序で書き出すようにしてください!

これは複雑なプロセスのように聞こえるかもしれませんが、このような単純な状況でさえ実用的な受信機を構築することは非常にわかりやすい場合があります。残したことが他にある場合はコメントしてください。


ポインタをありがとう!シミュレーションでうまく機能するものがあり、実際のプラットフォームに移植します。私はQPSKから始めて、256-QAMでどれだけまでプッシュできるかを見ました。256-QAMは、外部オーディオコーデックではなく、MCUに組み込まれているSAR DACを使用するだけで期待できる種類のノイズに強いようです。私はこれにDMAを使用するので、RAMのバッファーを直接埋めて、一度に16サンプルのブロックでデータを処理します。最も難しいのは、ローカルのQ / I信号を調整することでした。私はプロトコルに定期的な同期シーケンスを追加して、その上でpi / 2 incertudeを解決しました。
ピシェネット2012年

106

また、QAM(または振幅変調を含むその他のスキーム)を使用している場合、私の回答の最後にリストに追加する別の主要なブロックがあります。ある種のゲイン制御メカニズムが必要になります。基本的に、各シンボル値の決定領域を配置する平面内の場所を決定する必要があります。1つのアプローチは、自動ゲイン制御ループを使用して信号の平均電力を特定の値に強制し、その平均電力レベルに応じて決定領域を構造化することです。
Jason R
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.