Como evitar interferências na comunicação sem fio?

Estou trabalhando no sistema de comunicação sem fio. Estamos usando cerca de 10 pares de transmissores e receptores. Estamos usando o microcontrolador atmega16 para codificação e decodificação pelas portas USART.

Agora somos capazes de transmitir os dados e receber os mesmos no final do receptor, mas há um grande problema quando encontramos os 2 dados do transmissor chegando ao mesmo tempo. O receptor não pode obtê-lo devido à interferência.

Suponha que um transmissor envie "SENDA" enquanto outro transmite "GETTS"; nesse momento, o receptor não pode receber dados adequados. Como todos os transmissores e receptores estão trabalhando na mesma frequência, esta interferência está ocorrendo. Como posso resolver esse problema?

Desenvolver um protocolo de comunicação de RF viável pode ser um exercício complicado, mas educacional. Alguns pontos adicionais a considerar além do que foi dito:

1. Em alguns equipamentos de rádio, é preciso muita energia para ouvir um sinal. Com muitos rádios, se não a maioria dos pequenos, escutar por um segundo consumirá mais energia do que transmitir por um milissegundo; em alguns rádios, ouvir milissegundos pode levar mais energia do que transmitir milissegundos. Se o consumo atual não é um problema, ouvir continuamente é muito mais simples do que ouvir de forma intermitente; se o consumo atual for um problema, pode ser necessário ouvir de forma intermitente. Provavelmente não é uma boa ideia até que você consiga avançar com um protocolo de escuta contínua.
2. Ouvir antes de transmitir pode ser "educado", mas não é nem de longe tão útil com RF quanto com, por exemplo, um cabo Ethernet. A sinalização Ethernet é projetada para que não apenas seja provável que um dispositivo que ouça antes de transmitir evite uma colisão, mas também seja projetado para que um dispositivo cuja transmissão colide com a de outro dispositivo seja praticamente garantido perceber. A transmissão de RF não oferece tal promessa. É perfeitamente possível que, quando P quiser transmitir para Q, algum outro dispositivo X que esteja mais próximo de Q do que P esteja transmitindo alto o suficiente para impedir que Q ouça a transmissão de P, mas não alto o suficiente para P perceber. A única maneira de P saber que Q pode não ter recebido sua transmissão é pelo fato de P não ouvir uma resposta de Q.
3. É importante ter cuidado com o problema de consenso - muito mais com RF do que com sinalização por fio. Se um P enviar para Q, é possível que Q ouça a transmissão de P e envie uma confirmação, mas P por várias razões não ouvirá essa confirmação. Portanto, é necessário ter muito cuidado para distinguir retransmissões de transmissões "novas".

   O problema de consenso pode ser especialmente irritante se alguém estiver tentando economizar energia desligando os receptores quando eles não são necessários. Suponha que dois P e Q devem se comunicar uma vez a cada 10 segundos, para que eles liguem e P envie um pacote a Q. Q recebe o pacote, envia seu reconhecimento e - sabendo que P não estará enviando nada por quase dez segundos, desliga. Se P não receber o reconhecimento de Q, ele retransmitirá; como Q está dormindo, no entanto, ele não ouvirá a retransmissão de P. Da perspectiva de Q, isso não importaria (ele já recebeu seus dados), mas significa que não importa quantas vezes P tente novamente, ele não terá como saber que Q recebeu seu pacote (pelo menos não até o próximo encontro em cerca de dez segundos).

4. É inteiramente possível ter uma situação em que o nó Q poderá receber transmissões de P, mas P não poderá receber transmissões de Q. Pode não ser possível se comunicar de maneira útil em tais cenários, mas pelo menos deve-se esforçar para evitar fazer algo desagradável (como P repetir repetidamente uma transmissão centenas de tentativas por segundo)

Como dito, um protocolo de comunicação de RF viável pode ser um exercício complicado. Ainda assim, eu espero que você provavelmente aprenda muito com a experiência.

Se você não estiver usando um protocolo padrão para isso, precisará criar e implementar um, por exemplo, um exemplo simples:

• antes de transmitir, um nó deve ouvir para verificar se o canal está livre
• se, depois de transmitir uma mensagem, nenhuma confirmação for recebida, o nó deverá aguardar um período aleatório e tentar novamente, até um número máximo de tentativas

Então, o que acontece é que você primeiro tenta evitar "obstruções" ouvindo primeiro; se um bloqueio ainda ocorrer, você detecta isso por falta de reconhecimento do nó receptor e tenta novamente após um atraso aleatório - os dois transmissores obstruídos use atrasos aleatórios diferentes, minimizando a chance de uma segunda colisão.

Aqui estão duas opções comuns

1) Implemente um algoritmo Listen Before Talk (LBT), que verifica se há transmissão em andamento antes de iniciar a sua própria e, nesse caso, recua por um período de tempo. O período deve conter um comprimento fixo e um comprimento aleatório, para que eles não recuem todos pelo mesmo período. Muitos protocolos de rádio padrão incluem esse procedimento, consulte ETSI EN 300-220-1.

2) Implemente um sistema de farol onde as transmissões são cronometradas a partir do farol. Cada transmissor recebe seu próprio slot de tempo. Você normalmente usaria números de série nos dispositivos para determinar seu slot e teria um sistema para determinar quem envia o farol. Como isso depende de todos os transmissores com um slot diferente, não é uma boa ideia deixar para o usuário identificar exclusivamente todos os transmissores, a menos que você tenha um procedimento sólido para isso.

Pelo que entendi pelos comentários, etc, o poder não é um problema, mas a velocidade da comunicação. Então, aqui está minha sugestão para um protocolo.

Numere todos os nós, 0..n-1. Informe a cada nó qual é o número. O nó 0 será o mestre.

A cada 15 ms, o nó 0 envia uma mensagem: "0HELO".
1 ms depois, o nó 1 envia uma mensagem: "1DATA".
1 ms depois, o nó 2 envia uma mensagem: "2NICE".
1 ms depois, o nó 3 envia uma mensagem: "3". (Este nó não tem nada a dizer)
1ms depois, o nó 4 envia uma mensagem: "2CATS".
...
1ms depois, o nó 9 envia uma mensagem: "9MICE".
Depois, há uma pausa de 5ms.

Os nós sempre enviam suas mensagens nos horários corretos, mesmo que não tenham nada a dizer. Dessa forma, você tem taxa de comunicação garantida de 66Hz, sem colisões.

A comunicação de RF com vários transmissores assíncronos é um problema complicado. Muita reflexão e engenharia foram adotadas nos padrões 802.11 e 802.15 para contornar esses problemas. Se você precisar perguntar aqui, deve manter o hardware de prateleira que implementa um desses padrões.

Observe que, embora ambos sejam úteis e representem muito design cuidadoso, geralmente qualquer aplicativo real ainda precisará implementar uma pilha de protocolos acima desses padrões. Seriam WiFi e TCP acima de 802.11 e WiWi da Zigbee ou Microchip ou alguns outros acima de 802.15.

Mais uma vez, projetar uma rede de rádio multiponto está fora do seu alcance, se você estiver fazendo perguntas básicas aqui. Você passará muito tempo e as coisas nem sempre funcionarão corretamente.

A escolha de 802.11 versus 802.15 depende principalmente dos requisitos de largura de banda e alcance e energia disponível. 802.15 é menor, menor potência, menor largura de banda e menor alcance. Com o software de nível superior certo, um dispositivo 802.15 pode funcionar por muito tempo com baterias, enquanto isso geralmente não é verdade para 802.11.

Eu concordo em ouvir antes de falar e no sistema de beacon. Mas se você quiser usar um único canal para transmitir dados ao mesmo tempo, poderá usar a técnica de modulação por espectro de propagação de sequência direta (DSSS). Isso pode ajudar a evitar interferências.

Mas para isso, talvez você precise comprar um chip que o implemente, por exemplo, Xbee (baseado em Zigbee). Se você não pode trocar o seu transmissor, deve seguir as outras respostas.