ワイヤレス通信の干渉を避ける方法は？

私は無線通信システムに取り組んでいます。約10組の送信機と受信機を使用しています。USARTポートによるエンコードとデコードにatmega16マイクロコントローラーを使用しています。

これで、データを送信し、受信機側で同じデータを受信できますが、同時に送信される2つの送信機データを見つける際に大きな問題があります。レシーバーは干渉のために取得できません。

一方の送信機が「SENDA」を送信する一方で、別の送信機が「GETTS」を送信すると、その時点で受信機は適切なデータを受信できません。すべての送信機と受信機が同じ周波数で動作しているため、この干渉が発生しています。この問題を解決するにはどうすればよいですか？

実行可能なRF通信プロトコルを開発することは、トリッキーですが、教育的な運動になりがちです。言われたこと以外に考慮すべきいくつかの追加ポイント：

1. 一部の無線ハードウェアでは、信号をリッスンするには多くの電力が必要です。ほとんどではないにしても多くの小さな無線では、1秒間待機することは1秒間送信するよりも多くのエネルギーを消費します。一部の無線では、1 ミリ秒の受信は1ミリ秒の送信よりも多くのエネルギーを必要とする場合があります。消費電流が問題にならない場合は、断続的に聞くよりも継続的に聞く方がはるかに簡単です。ただし、消費電流が問題になる場合は、断続的に聴く必要があります。連続リスニングプロトコルで何かを達成するまで、おそらく良い考えではありません。
2. Listen-before-transmitは「丁寧」かもしれませんが、たとえばイーサネットケーブルのようにRFで使用するほど便利ではありません。イーサネットシグナリングは、送信前にリッスンするデバイスが通常衝突を回避する可能性が高いように設計されているだけでなく、送信が他のデバイスと衝突するデバイスが実質的に通知されることが保証されるように設計されています。RF送信はそのような約束を提供しません。PがQに送信したい場合、PよりもQに近い他のデバイスXが、QがPの送信を聞くのを防ぐのに十分な音量で送信しますが、Pが気付くのに十分な音量ではない可能性があります。Qが送信を受信して​​いない可能性があることをPが知る唯一の方法は、PがQからの応答を受け取らないという事実によるものです。
3. コンセンサスの問題に注意することが重要です。ワイヤシグナリングよりもRFの方がはるかに重要です。PがQに送信する場合、QはPの送信を受信して​​確認応答を送信する可能性がありますが、Pはさまざまな理由でその確認応答を受信しません。したがって、再送信と「新しい」送信を区別するために非常に注意する必要があります。

   必要のないときに受信機の電源を切ることでエネルギーを節約しようとする場合、コンセンサスの問題は特に厄介です。2つのPとQが10秒に1回通信することになっていると仮定すると、電源が入り、PはQにパケットを送信します。Qはパケットを受信し、確認応答を送信します。Pが10秒間ほとんど何も送信しないことを認識して、電源を切ります。PがQの確認を受け取らない場合、彼は再送信します。ただし、Qはスリープしているため、Pの再送信は聞こえません。Qの観点からは、それは重要ではありません（彼は既にデータを受け取っています）が、Pが何度再試行しても、Qがパケットを受け取ったことを知る方法はありません（少なくとも次のランデブーまでは） 10秒）。

4. ノードQがPからの送信を受信できる状況になることは完全に可能ですが、PはQからの送信を受信できません。このようなシナリオでは有効に通信できない場合がありますが、少なくとも努力する必要があります不快なこと（Pが毎秒数百回の再試行を無限に再試行するなど）を行わないようにするため

前述のように、実行可能なRF通信プロトコルは、扱いにくい作業になりがちです。それでも、私はあなたがおそらく経験から多くを学ぶことを期待しています。

このために標準プロトコルを使用していない場合は、たとえば簡単な例のように、設計して実装する必要があります。

• 送信する前に、ノードはチャネルが空いていることを確認するためにリッスンする必要があります
• メッセージを送信した後、受信確認が受信されない場合、ノードはランダムな期間待機してから、最大再試行回数まで再試行する必要があります

したがって、最初にリスニングすることで「ジャミング」を回避しようとします。それでもジャムが発生する場合は、受信ノードからの確認応答がないことでこれを検出し、ランダムな遅延の後に再試行します。異なるランダム遅延を使用して、2回目の衝突の可能性を最小限にします。

ここに2つの一般的なオプションがあります

1）Listen Before Talk（LBT）アルゴリズムを実装します。これは、自分で開始する前に進行中の送信があるかどうかを確認し、もしそうであれば、一定期間バックオフします。同じ期間にすべてが後退しないように、期間には固定長とランダム長を含める必要があります。多くの標準無線プロトコルにはこの手順が含まれています。ETSIEN 300-220-1を参照してください。

2）ビーコンから送信のタイミングが取られるビーコンシステムを実装します。各送信機は、独自のタイミングスロットを取得します。通常、デバイスのシリアル番号を使用してスロットを決定し、ビーコンを送信するユーザーを決定するシステムを使用します。これは異なるスロットを持つすべてのトランスミッターに依存するため、確実な手順がない限り、すべてのトランスミッターを一意に識別するためにユーザーに任せるのは得策ではありません。

コメントなどからわかるように、電力は問題ではありませんが、通信速度は問題です。だから、ここに私のプロトコルの提案があります。

すべてのノード、0..n-1に番号を付けます。各ノードに、その番号を知らせます。ノード0がマスターになります。

ノード0は15msごとにメッセージ「0HELO」を送信します。
1ミリ秒後、ノード1はメッセージ「1DATA」を送信します。
1ミリ秒後、ノード2はメッセージ「2NICE」を送信します。
1ms後、ノード3はメッセージ「3」を送信します。（このノードには何も言うことはありません）
1ms後、ノード4はメッセージ「2CATS」を送信します。
...
1ms後、ノード9はメッセージ「9MICE」を送信します。
その後、5msの休止があります。

ノードは、たとえ何も言わなくても、常に正しいタイムスロットでメッセージを送信します。このようにして、衝突なしで66Hzの通信速度が保証されます。

複数の非同期送信機とのRF通信は、扱いにくい問題です。これらの問題を回避するために、多くの思考とエンジニアリングが802.11および802.15標準に組み込まれました。ここで質問する必要がある場合は、これらの標準のいずれかを実装する市販のハードウェアに固執する必要があります。

両方とも有用であり、多くの注意深い設計を表していますが、一般に、実際のアプリケーションではこれらの標準を超えるプロトコルスタックを実装する必要があります。これは、802.11を超えるWiFiとTCP、およびZigbeeまたはMicrochipのWiWiまたは802.15を超える他のデバイスです。

繰り返しますが、マルチポイント無線ネットワークの設計は、ここでそのような基本的な質問をしているなら、リーグから抜け出す方法です。あなたは多くの時間を費やすだけで、物事はまだ正しく動作しません。

802.11と802.15の選択は、主に帯域幅と範囲の要件、および利用可能な電力に依存します。802.15はより小さく、より低い電力、より低い帯域幅、およびより狭い範囲です。適切な高レベルのソフトウェアを使用すると、802.15デバイスはバッテリーで長時間実行できますが、802.11では一般的にそうではありません。

話す前に聞くことと、ビーコンシステムに同意します。ただし、同時にデータを送信するために単一のチャネルを使用する場合は、直接シーケンススペクトラム拡散（DSSS）変調技術を使用できます。これにより、干渉を回避できます。

ただし、このためには、Xbee（Zigbeeベース）など、それを実装するチップを購入する必要があるかもしれません。送信機を変更できない場合は、他の回答に固執する必要があります。