Comment éviter les interférences dans les communications sans fil?

Je travaille sur un système de communication sans fil. Nous utilisons environ 10 paires d'émetteurs et de récepteurs. Nous utilisons le microcontrôleur atmega16 pour l'encodage et le décodage par les ports USART.

Maintenant, nous sommes en mesure de transmettre les données et de les recevoir du côté du récepteur, mais il y a un problème majeur, lorsque nous trouvons les 2 données d'émetteur venant en même temps. Le récepteur ne peut pas l'obtenir en raison d'interférences.

Supposons qu'un émetteur envoie "SENDA" en même temps qu'un autre émetteur envoie "GETTS", à ce moment le récepteur ne peut pas recevoir les données appropriées. Comme tous les émetteurs et récepteurs fonctionnent à la même fréquence, cette interférence se produit. Comment puis-je résoudre ce problème?

Le développement d'un protocole de communication RF réalisable est susceptible d'être un exercice délicat mais éducatif. Quelques points supplémentaires à considérer au-delà de ce qui a été dit:

1. Sur certains équipements radio, il faut beaucoup d'énergie pour écouter un signal. Avec beaucoup sinon la plupart des petites radios, écouter une seconde va prendre plus d'énergie que transmettre pendant une milliseconde; sur certaines radios, l'écoute pendant une milliseconde peut prendre plus d'énergie que la transmission pendant une milliseconde. Si la consommation actuelle n'est pas un problème, l'écoute continue est beaucoup plus simple que l'écoute intermittente; si la consommation actuelle est un problème, cependant, il peut être nécessaire d'écouter par intermittence. Ce n'est probablement pas une bonne idée tant que vous n'avez pas réussi à faire avancer les choses avec un protocole d'écoute continue.
2. L'écoute avant transmission peut être "polie", mais elle est loin d'être aussi utile avec RF qu'avec, par exemple, un câble Ethernet. La signalisation Ethernet est conçue de sorte que non seulement il est probable qu'un appareil qui écoute avant de transmettre évite généralement une collision, mais il est également conçu de sorte qu'un appareil dont la transmission entre en collision avec celle d'un autre appareil est pratiquement garanti de le remarquer. La transmission RF n'offre aucune promesse de ce genre. Il est tout à fait possible que lorsque P veut transmettre à Q, un autre appareil X qui est plus proche de Q que de P transmette suffisamment fort pour empêcher Q d'entendre la transmission de P, mais pas assez fort pour que P le remarque. La seule façon pour P de savoir que Q n'a peut-être pas reçu sa transmission est le fait que P n'entendra pas de réponse de Q.
3. Il est important de se méfier du problème du consensus - beaucoup plus avec la RF qu'avec la signalisation par fil. Si un P envoie à Q, il est possible que Q entende la transmission de P et envoie un accusé de réception, mais P, pour diverses raisons, n'entendra pas cet accusé de réception. Il faut donc faire très attention à distinguer les retransmissions des "nouvelles" transmissions.

   Le problème du consensus peut être particulièrement vexant si l'on essaie d'économiser de l'énergie en éteignant les récepteurs lorsqu'ils ne sont pas nécessaires. Supposons que deux P et Q sont censés communiquer une fois toutes les 10 secondes, donc ils se mettent sous tension et P envoie à Q un paquet. Q reçoit le paquet, envoie son accusé de réception et - sachant que P n'enverra rien pendant près de dix secondes, s'éteint. Si P ne reçoit pas la reconnaissance de Q, il retransmettra; puisque Q dort, cependant, il n'entendra pas la retransmission de P. Du point de vue de Q, cela n'aurait pas d'importance (il a déjà reçu ses données), mais cela signifie que peu importe le nombre de tentatives de P, il n'aura aucun moyen de savoir que Q a reçu son paquet (du moins pas avant le prochain rendez-vous dans environ dix secondes).

4. Il est tout à fait possible d'avoir une situation dans laquelle le nœud Q pourra recevoir des transmissions de P, mais P ne pourra pas recevoir de transmissions de Q. Il peut ne pas être possible de communiquer utilement dans de tels scénarios, mais il faut au moins s'efforcer pour éviter de faire quelque chose de désagréable (comme avoir P réessayer sans fin une transmission des centaines de tentatives par seconde)

Comme dit précédemment, un protocole de communication RF réalisable est susceptible d'être un exercice délicat. Pourtant, je m'attends à ce que vous appreniez probablement beaucoup de cette expérience.

Si vous n'utilisez pas de protocole standard pour cela, vous devrez en concevoir et en implémenter un, par exemple un exemple simple:

• avant de transmettre, un nœud doit écouter pour vérifier que le canal est libre
• si après avoir transmis un message aucun accusé de réception n'est reçu, le nœud devrait attendre une période de temps aléatoire, puis réessayer, jusqu'à un certain nombre maximum de tentatives

Donc, ce qui se passe, c'est que vous essayez d'abord d'éviter le "brouillage" en écoutant d'abord, puis si un bourrage se produit toujours, vous le détectez via un manque d'acquittement du nœud récepteur, puis réessayez après un délai aléatoire - les deux émetteurs de brouillage utiliser différents retards aléatoires, minimisant les risques de deuxième collision.

Voici deux options courantes

1) Implémentez un algorithme Listen Before Talk (LBT), qui vérifie s'il y a une transmission en cours avant de démarrer le vôtre, et si oui, recule pendant un certain temps. La période doit contenir une longueur fixe et une longueur aléatoire afin qu'elles ne reculent pas toutes pendant la même période. De nombreux protocoles radio standard incluent cette procédure, voir ETSI EN 300-220-1.

2) Mettre en œuvre un système de balise où les transmissions sont chronométrées à partir de la balise. Chaque émetteur a son propre créneau temporel. Vous devez normalement utiliser des numéros de série dans les appareils pour déterminer leur emplacement et disposer d'un système pour déterminer qui envoie la balise. Étant donné que cela dépend de tous les émetteurs ayant un emplacement différent, ce n'est pas une bonne idée de laisser à l'utilisateur d'identifier de manière unique tous les émetteurs, sauf si vous avez une procédure solide pour cela.

Si je comprends bien des commentaires, etc., l'alimentation n'est pas un problème, mais la vitesse de communication l'est. Voici donc ma suggestion de protocole.

Numérotez tous les nœuds, 0..n-1. Faites savoir à chaque nœud de quel numéro il s'agit. Le nœud 0 sera le maître.

Toutes les 15 ms, le nœud 0 envoie un message: "0HELO".
1 ms plus tard, le nœud 1 envoie un message: "1DATA".
1 ms plus tard, le nœud 2 envoie un message: "2NICE".
1 ms plus tard, le nœud 3 envoie un message: "3". (Ce nœud n'a rien à dire)
1 ms plus tard, le nœud 4 envoie un message: "2CATS".
...
1 ms plus tard, le nœud 9 envoie un message: "9MICE".
Il y a ensuite une pause de 5 ms.

Les nœuds envoient toujours leurs messages dans leurs créneaux horaires corrects, même s'ils n'ont rien à dire. De cette façon, vous êtes assuré d'un taux de communication de 66 Hz, sans collision.

La communication RF avec plusieurs émetteurs asynchrones est un problème délicat. Beaucoup de réflexion et d'ingénierie ont été consacrées aux normes 802.11 et 802.15 pour contourner ces problèmes. Si vous devez demander ici, vous devez vous en tenir au matériel standard qui met en œuvre l'une de ces normes.

Notez que bien que les deux soient utiles et représentent beaucoup de conception soignée, généralement toute application réelle devra toujours implémenter une pile de protocoles au-dessus de ces normes. Ce serait WiFi et TCP au-dessus de 802.11 et Zigbee ou WiWi de Microchip ou d'autres au-dessus de 802.15.

Encore une fois, la conception d'un réseau radio multipoint est bien loin de votre ligue si vous posez des questions aussi fondamentales ici. Vous passerez juste beaucoup de temps et les choses ne fonctionneront pas toujours correctement.

Le choix entre 802.11 et 802.15 dépend principalement de vos besoins en bande passante et en portée et en puissance disponible. Le 802.15 est plus petit, une puissance inférieure, une bande passante inférieure et une plage plus petite. Avec le bon logiciel de niveau supérieur, un périphérique 802.15 peut fonctionner longtemps à partir des batteries, alors que ce n'est généralement pas le cas pour le 802.11.

Je suis d'accord avec l'écoute avant de parler et le système de balise. Mais si vous souhaitez utiliser un seul canal pour transmettre des données en même temps, vous pouvez utiliser la technique de modulation à spectre étalé à séquence directe (DSSS). Cela pourrait vous aider à éviter les interférences.

Mais pour cela, vous devrez peut-être acheter une puce qui le met en œuvre, par exemple Xbee (basé sur Zigbee). Si vous ne pouvez pas changer votre émetteur, vous devez vous en tenir aux autres réponses.