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

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

1. En algunos equipos de radio, se necesita mucha energía para escuchar una señal. Con muchas, si no la mayoría de las radios pequeñas, escuchar un segundo va a requerir más energía que transmitir durante 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 un lote más simple que escuchar de manera 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 que algo funcione 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 de Ethernet. La señalización de Ethernet está diseñada para que no solo sea probable que un dispositivo que escucha antes de transmitir, por lo general evite una colisión, sino que también esté diseñado para que un dispositivo cuya transmisión colisione con la de otro dispositivo esté virtualmente garantizado de notarlo. La transmisión de 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 de P esté transmitiendo lo suficientemente alto como para evitar que Q escuche la transmisión de P, pero no lo suficiente como para que P lo note. La única forma en que P sabrá que Q podría no haber recibido su transmisión es porque P no escuchará una respuesta de Q.
3. Es importante tener cuidado con el problema del consenso, mucho más con RF que con la señalización por cable. Si una P se 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 oirá ese acuse de recibo. Por lo tanto, es necesario tener mucho cuidado para distinguir las retransmisiones de las "nuevas" transmisiones.

   El problema del consenso puede ser especialmente molesto si uno está tratando de ahorrar energía apagando los receptores cuando no son necesarios. Supongamos que se supone que dos P y Q se comunican una vez cada 10 segundos, por lo 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 obtiene el reconocimiento de Q, él retransmitirá; ya que Q está dormido, sin embargo, 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 los reintentos de P, no tendrá forma de saber que Q recibió su paquete (al menos no hasta la próxima cita). 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. Es posible que no sea posible comunicarse de manera útil en tales escenarios, pero uno debería al menos esforzarse por evitar hacer algo desagradable (como hacer que P vuelva a intentar una transmisión cientos de intentos por segundo)

Como se dijo, un protocolo de comunicaciones de RF viable puede ser un ejercicio difícil. Sin embargo, espero que aprendas mucho de la experiencia.

Si no estás usando un protocolo estándar para esto, entonces tendrás que 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 un 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 intentas evitar el "atasco" escuchando primero, luego, si todavía se produce un atasco, lo detectas a través de una falta de acuse de recibo del nodo receptor y luego lo intentas de nuevo después de un retraso aleatorio: los dos Los transmisores de interferencia usarán diferentes retardos aleatorios, minimizando la posibilidad de una segunda colisión.

Aquí hay dos opciones comunes

1) Implemente un algoritmo de escuchar antes de hablar (LBT), que verifica si hay una transmisión en curso antes de comenzar la suya, y si es así, se retira durante un período de tiempo. El período debe contener una longitud fija y una longitud aleatoria para que no todos se retiren durante el mismo período. Muchos protocolos de radio estándar incluyen este procedimiento, consulte ETSI EN 300-220-1.

2) Implementar un sistema de baliza donde las transmisiones se cronometren desde la baliza. Cada transmisor tiene su propia ranura de tiempo. Normalmente, usaría los 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 a todos los transmisores, a menos que tenga un procedimiento sólido para ello.

Como entiendo de los comentarios, etc., el poder no es un problema, pero la velocidad de comunicación 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 intervalos de tiempo correctos, incluso si no tienen nada que decir. De esta manera se le garantiza una velocidad de comunicación de 66Hz, sin colisiones.

La comunicación por RF con múltiples transmisores asíncronos es un problema complicado. Mucho pensamiento e ingeniería se adentraron en los estándares 802.11 y 802.15 para solucionar estos problemas. Si tiene que preguntar aquí, entonces debe quedarse con el hardware de estantes que implementa uno de estos estándares.

Tenga en cuenta que si bien ambos son útiles y representan mucho diseño cuidadoso, generalmente cualquier aplicación real 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 WiWi de Microchip o algunos otros por encima de 802.15.

Una vez más, el diseño de una red de radio multipunto está fuera de su alcance si está haciendo estas preguntas básicas aquí. Solo pasará mucho tiempo y las cosas no siempre funcionarán bien.

La elección de 802.11 en lugar de 802.15 depende principalmente de su ancho de banda y los requisitos de rango y la potencia disponible. 802.15 es más pequeño, con menor potencia, menor ancho de banda y menor alcance. Con el software de nivel superior correcto, un dispositivo 802.15 puede funcionar durante mucho tiempo con las baterías, mientras que generalmente no es así para 802.11.

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

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