¿Cómo evitar interferencias en la comunicación inalámbrica?

Estoy trabajando en un sistema de comunicación inalámbrico. Estamos utilizando alrededor de 10 pares de transmisores y receptores. Estamos utilizando el microcontrolador atmega16 para codificar y decodificar por puertos USART.

Ahora podemos transmitir los datos y recibirlos en el extremo del receptor, pero hay un problema importante cuando encontramos que los 2 datos del transmisor llegan al mismo tiempo. El receptor no puede obtenerlo debido a interferencia.

Supongamos que un transmisor envía "SENDA" mientras que otro transmisor envía "GETTS", en ese momento el receptor no puede recibir los datos adecuados. Como todos los transmisores y receptores funcionan en la misma frecuencia, esta interferencia está ocurriendo. ¿Cómo puedo resolver este problema?

El desarrollo de un protocolo de comunicaciones de RF viable puede ser un ejercicio difícil pero educativo. Algunos puntos adicionales a considerar más allá de lo que se ha dicho:

1. En algunos equipos de radio, se necesita mucha potencia para escuchar una señal. Con muchas, si no la mayoría de las radios pequeñas, escuchar por un segundo requerirá más energía que transmitir por un milisegundo; En algunas radios, escuchar un milisegundo puede requerir más energía que transmitir durante un milisegundo. Si el consumo actual no es un problema, escuchar continuamente es mucho más simple que escuchar de forma intermitente; si el consumo actual es un problema, sin embargo, puede ser necesario escuchar de forma intermitente. Probablemente no sea una buena idea hasta que haya logrado poner en marcha algo con un protocolo de escucha continua.
2. Escuchar antes de transmitir puede ser "educado", pero no es tan útil con RF como con, por ejemplo, un cable Ethernet. La señalización de Ethernet está diseñada para que no solo sea probable que un dispositivo que escucha antes de transmitir evite una colisión, sino que también está diseñado para que un dispositivo cuya transmisión colisiona con la de otro dispositivo esté prácticamente garantizado de darse cuenta. La transmisión RF no ofrece tal promesa. Es completamente posible que cuando P quiera transmitir a Q, algún otro dispositivo X que esté más cerca de Q que a P esté transmitiendo lo suficientemente alto como para evitar que Q escuche la transmisión de P, pero no lo suficientemente fuerte como para que P lo note. La única forma en que P sabrá que Q podría no haber recibido su transmisión es por el hecho de que P no escuchará una respuesta de Q.
3. Es importante tener cuidado con el problema del consenso, mucho más con RF que con señalización por cable. Si una P envía a Q, es posible que Q escuche la transmisión de P y envíe un acuse de recibo, pero P por varias razones no escuchará ese acuse de recibo. Por lo tanto, es necesario tener mucho cuidado para distinguir las retransmisiones de las transmisiones "nuevas".

   El problema del consenso puede ser especialmente molesto si uno está tratando de ahorrar energía apagando los receptores cuando no son necesarios. Suponga que se supone que dos P y Q se comunican una vez cada 10 segundos, de modo que se encienden y P envía a Q un paquete. Q recibe el paquete, envía su acuse de recibo y, sabiendo que P no enviará nada durante casi diez segundos, se apaga. Si P no recibe el reconocimiento de Q, retransmitirá; Sin embargo, dado que Q está dormido, no escuchará la retransmisión de P. Desde la perspectiva de Q, eso no importaría (ya recibió sus datos), pero significa que no importa cuántas veces P vuelva a intentarlo, no tendrá forma de saber que Q recibió su paquete (al menos no hasta la próxima cita sobre diez segundos).

4. Es completamente posible tener una situación en la que el nodo Q pueda recibir transmisiones de P, pero P no podrá recibir transmisiones de Q. Puede que no sea posible comunicarse de manera útil en tales escenarios, pero al menos uno debería esforzarse para evitar hacer algo desagradable (como hacer que P vuelva a intentar una transmisión sin cesar cientos de intentos por segundo)

Como se dijo, un protocolo de comunicaciones de RF viable puede ser un ejercicio complicado. Aún así, espero que probablemente aprendas mucho de la experiencia.

Si no está utilizando un protocolo estándar para esto, deberá diseñar e implementar uno, por ejemplo, un ejemplo simple:

• antes de transmitir, un nodo debe escuchar para verificar que el canal esté libre
• si después de transmitir un mensaje no se recibe ningún acuse de recibo, el nodo debe esperar un período de tiempo aleatorio y luego volver a intentarlo, hasta un número máximo de reintentos

Entonces, lo que sucede es que primero intenta evitar el "atasco" al escuchar primero, luego, si todavía ocurre un atasco, lo detecta por falta de reconocimiento del nodo receptor y luego intenta nuevamente después de un retraso aleatorio: los dos transmisores de atasco use diferentes demoras aleatorias, minimizando la posibilidad de una segunda colisión.

Aquí hay dos opciones comunes

1) Implemente un algoritmo Listen Before Talk (LBT), que verifica si hay una transmisión en progreso antes de comenzar la suya, y si es así, retrocede por un período de tiempo. El período debe contener una longitud fija y una longitud aleatoria para que no retrocedan durante el mismo período. Muchos protocolos de radio estándar incluyen este procedimiento; consulte ETSI EN 300-220-1.

2) Implemente un sistema de baliza donde las transmisiones se cronometran desde la baliza. Cada transmisor tiene su propio intervalo de tiempo. Normalmente usaría números de serie en los dispositivos para determinar su ranura, y tendría un sistema para determinar quién envía la baliza. Dado que esto depende de que todos los transmisores tengan una ranura diferente, no es una buena idea dejar que el usuario identifique de forma única todos los transmisores, a menos que tenga un procedimiento sólido para esto.

Como entiendo por los comentarios, etc., el poder no es un problema, pero la velocidad de comunicación sí lo es. Entonces, aquí está mi sugerencia para un protocolo.

Numere todos los nodos, 0..n-1. Deje que cada nodo sepa qué número es. El nodo 0 será el maestro.

Cada 15 ms, el nodo 0 envía un mensaje: "0HELO".
1 ms después, el nodo 1 envía un mensaje: "1DATA".
1 ms después, el nodo 2 envía un mensaje: "2NICE".
1 ms después, el nodo 3 envía un mensaje: "3". (Este nodo no tiene nada que decir) 1
ms después, el nodo 4 envía un mensaje: "2CATS".
... 1
ms después, el nodo 9 envía un mensaje: "9MICE".
Luego hay una pausa de 5 ms.

Los nodos siempre envían sus mensajes en sus franjas horarias correctas, incluso si no tienen nada que decir. De esta manera, se garantiza una velocidad de comunicación de 66Hz, sin colisiones.

La comunicación de RF con múltiples transmisores asíncronos es un problema complicado. Se pensó mucho e ingenió los estándares 802.11 y 802.15 para solucionar estos problemas. Si tiene que preguntar aquí, debe apegarse al hardware estándar que implementa uno de estos estándares.

Tenga en cuenta que si bien ambos son útiles y representan un diseño cuidadoso, en general, cualquier aplicación real aún tendrá que implementar una pila de protocolos por encima de estos estándares. Esto sería WiFi y TCP por encima de 802.11 y Zigbee o Microchip's WiWi u otros por encima de 802.15.

Nuevamente, diseñar una red de radio multipunto está fuera de tu alcance si haces preguntas tan básicas aquí. Pasarás mucho tiempo y las cosas no siempre funcionarán bien.

La elección de 802.11 frente a 802.15 depende principalmente de sus requisitos de ancho de banda y rango y de la potencia disponible. 802.15 es más pequeño, menor potencia, menor ancho de banda y menor rango. Con el software adecuado de nivel superior, un dispositivo 802.15 puede funcionar mucho tiempo con baterías, mientras que eso generalmente no es cierto para 802.11.

Estoy de acuerdo con escuchar antes de hablar y el sistema de baliza. Pero si desea utilizar un solo canal para transmitir datos al mismo tiempo, puede utilizar la técnica de modulación de espectro extendido de secuencia directa (DSSS). Esto podría ayudarlo a evitar interferencias.

Pero para esto quizás necesite comprar un chip que lo implemente, por ejemplo Xbee (basado en Zigbee). Si no puede cambiar su transmisor, debe atenerse a las otras respuestas.