ここにはかなり良い状況があります。あまり問題なく目標を達成できるはずです。変調のクラス全体を排除するような記述は見当たらない(たとえば、位相シフトキーイング、周波数シフトキーイングなど)。適切なフォーマットの選択に入るいくつかの要因は次のとおりです。
- 必要なスペクトル効率(使用可能な帯域幅と比較して必要なデータスループットの大きさ)
- 受信機の複雑さの要件(通常、システムの最も複雑な部分です)
- 実装の開発にどの程度の労力を費やして取り組むか。
- アプリケーションに固有のその他の状況(たとえば、一端または両端のタイミング精度が低い、既知の干渉、またはチャネル応答が悪い場合)
それで、あなたのシステムのためにこれらを一つずつチェックすることで、いくつかのガイドラインを思いつくことができます:
最大の制約は、チャネル応答(サウンドカードの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)信号を生成します(多くの場合、複素ベースバンド信号として表されます)。
- 一致したフィルタリング:送信機で使用されるパルス形状に一致するフィルターにベースバンド信号を渡します(矩形パルスで回避できる可能性があります)。
- タイミング同期:シンボル遷移に対応する時間を特定して追跡します。これは、シンボル時間を法とするマッチドフィルター出力のピーク位置を追跡することで実行できます。
- ビットスライシング:シンボルサンプル時間で一致したフィルター出力をハードビット決定に変換
- シリアル化:シンボルごとに複数のビットを正しい順序で書き出すようにしてください!
これは複雑なプロセスのように聞こえるかもしれませんが、このような単純な状況でさえ実用的な受信機を構築することは非常にわかりやすい場合があります。残したことが他にある場合はコメントしてください。