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


12

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?


4
Quel type de circuit radio se trouve entre votre UART et l'antenne?
jpc

Réponses:


14

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.


8

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.


2
Une limitation majeure de la prévention des collisions est qu'il n'y a aucune garantie que les émetteurs potentiels seront à portée de réception l'un de l'autre, même s'ils sont tous les deux à portée de réception de leur cible.
supercat

1
L'évitement des collisions n'apporte qu'une amélioration de l'utilisation des canaux. Vous devez encore faire des remerciements et des retransmissions. La clé est d'attendre un temps aléatoire avant de retransmettre.
David Schwartz

La chose la plus importante est que cela fonctionne en temps réel et c'est aussi une communication à sens unique. donc si nous le faisons dans les 2 sens, cela fera plus d'interférences. :(
user934070

OK - ça ne sera jamais robuste ou fiable alors - vous pouvez écouter avant de transmettre mais en dehors de cela, vous n'aurez jamais aucune garantie qu'une transmission a bien été reçue.
Paul R

4

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.


Soit dit en passant, je pense que la deuxième partie pourrait tirer parti de l'AMRC s'ils savent que la plupart des stations n'auront normalement pas besoin de transmettre.
Kortuk

1
@Kortuk: J'avais l'impression que l'un des avantages de CDMA est que - si le récepteur peut être synchronisé avec l'expéditeur - le nombre d'erreurs sur les bits augmentera à mesure que le nombre d'émetteurs simultanés augmentera, mais sinon, n'est pas un "brouillage" en tant que tel.
supercat

@supercat, j'ai l'impression que tout le monde alloue des plages horaires au hasard. La plupart des émetteurs ne parlent qu'occasionnellement, de sorte que les chances de parler deux en même temps sont très faibles, mais cela se produit parfois et apparaît à ce stade comme un petit nombre d'erreurs binaires. Avec l'entrelacement et l'ECC général, vous pouvez presque ignorer cela. Cela dit, tout le monde a des intervalles de temps prédéterminés basés sur un générateur de nombres aléatoires pour s'assurer que deux émetteurs ne partagent pas le même espace en permanence et ne se rencontrent qu'occasionnellement. Je peux demander à quelqu'un qui sait avec certitude et les faire sonner.
Kortuk

1
@Kortuk: C'est ce que je pensais que CDMA voulait dire, mais un certain nombre de sources, y compris la page Wikipedia, suggèrent qu'il se réfère à la modulation à une vitesse supérieure au débit binaire; si l'émetteur inverse son signal selon un train de bits pseudo-aléatoire, et que le récepteur fait de même et filtre ensuite le signal résultant, le signal d'origine peut être récupéré. Les approches basées sur un créneau temporel pseudo-aléatoire sont utiles, mais je ne pense pas que CDMA soit le bon terme. La plus grande difficulté avec de telles approches est la coordination. Je souhaite vraiment qu'il y ait un signal horaire haute résolution largement disponible.
supercat

1
@Kortuk: WWV fonctionne en quelque sorte pour synchroniser les horloges et les montres numériques, mais il faut une minute pour envoyer un signal horaire. Ce serait tellement plus agréable s'il y avait des émissions de temps largement déployées qui pouvaient être lues en 10 ms ou moins et étaient garanties d'être dans une certaine petite tolérance de l'heure WWV dans le Colorado (ce qui signifie qu'à un endroit à 1 000 miles de distance, le relais localement relayé les diffusions temporelles devraient en fait entraîner le WWV d'environ 5 ms).
supercat

3

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.


2

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.


2
Tout dépend de l'application. C'est en effet assez difficile mais en même temps, beaucoup peut être appris de l'exercice. Et les choses qu'il apprendra sont des lois universelles et non des détails spécifiques à la mise en œuvre.
jpc

9
«sortir de votre ligue» est un peu dur. Ils sont un peu dépassés, et j'ai vu des gens dans ce genre de poste perdre un an sur ce type de problème ... mais cela ne signifie pas qu'ils ne peuvent pas prendre conseil et le faire fonctionner. Comme l'a dit jpc, le succès ici pourrait signifier un bond significatif dans la compréhension. S'ils étaient un de mes employés avec cette question (et je pouvais me permettre le temps pour la leçon), je les encouragerais et j'espère qu'ils apprendraient quelque chose.
darron

3
C'est un mauvais service lorsque les gens viennent sur ce site à la recherche de réponses pour en savoir plus sur un problème et le résoudre et qu'ils laissent de force (par des votes positifs) une solution qu'ils ne demandaient pas ou ne pouvaient pas utiliser.
Joel B

1
@JoelB upvotes ne force pas l'acceptation d'une réponse.
Chris Stratton

1

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.


Merci beaucoup pour vos suggestions. Mais, en fait, notre problème majeur est que notre système fonctionne en temps réel, donc quand et d'où nous recevrons un signal est totalement imprévisible. Permettez-moi de l'expliquer plus en détail. en fait, tous les émetteurs et récepteurs sont placés en fonction de leur portée, c'est-à-dire que leur portée est de 100 mètres, puis tous sont présents à l'intérieur de 50 mètres, donc tout signal provenant d'un émetteur peut atteindre chaque nœud et de nouveau, tout signal peut arriver à tout moment. alors comment pouvons-nous résoudre ce problème ,, ..
user934070

@ User934070 Les systèmes de téléphonie cellulaire et le wifi utilisent généralement un spectre étalé d'une sorte ou au moins des technologies qui suivent les mêmes concepts de base. Les téléphones portables et les ordinateurs portables sont exactement comme vous le décrivez "quand et d'où nous recevrons un signal est totalement imprévisible"
Kellenjb
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.