Quiero conectar una Raspberry Pi a un dispositivo portátil basado en MCU ARM que contiene una pantalla y algunos botones para mostrar información de la Pi y transmitir comandos. Quiero usar transceptores nrf24l01+ 2.4GHz para eso.
Estoy reflexionando sobre cómo configurar el enlace de comunicaciones y, especialmente, si usar o no Enhanced Shock Burst (ESB). ESB es muy práctico ya que es compatible con el reconocimiento automático y, por lo tanto, podría liberarme de la gestión del reconocimiento manual, lo cual es una molestia, especialmente en el dispositivo basado en MCU. Sin embargo, por lo que he entendido de las hojas de datos, ESB requiere que un dispositivo sea un receptor principal y un dispositivo sea un transmisor principal y solo el último inicia una nueva transmisión, aunque el primero puede transmitir datos en su respuesta. En mi caso, esto es problemático porque ambos dispositivos reciben eventos externos que desencadenan la necesidad de una transmisión de datos.
He estado leyendo y básicamente hay tres posibles soluciones a este problema:
Configure un dispositivo como PTX y otro como PRX y haga que el PTX envíe mensajes vacíos para que el PRX tenga la oportunidad de enviar sus datos en un paquete de respuesta. Esto parece ser hecho por algunos proyectos. Veo la desventaja de tener tráfico en el aire continuamente, lo cual es malo para los dispositivos que funcionan con baterías. Además, el PRX aún necesita algo de búfer para almacenar los mensajes hasta que llegue una transmisión y el mensaje se pueda enviar en el acuse de recibo.
Configure ambos dispositivos como PRX. Si un dispositivo necesita transmitir un mensaje, cambia a la función PTX y transmite el mensaje. La ventaja es que no hay tráfico continuo en el aire y ambos dispositivos pueden transmitir los mensajes según sea necesario. Sin embargo, no encontré que esto se esté haciendo en ninguna parte. Entonces, me pregunto si esto es posible o si hay otras advertencias con esta solución.
Deshazte de Enhanced Shock Burst y haz tu propio protocolo. La solución menos favorecida, ya que implica más trabajo y pone más carga en el controlador. La función de retransmisión automática suena muy bien y sería una pena desperdiciar este potencial.
Así que me pregunto si alguien ya tuvo este problema y cómo lo resolvió. Me gustaría saber especialmente si hay problemas con la posibilidad dos.
La segunda opción es en realidad muy común. Esencialmente, PRX y PTX pueden ser por transmisión. Ambos deberían estar en modo rx la mayor parte del tiempo, y cuando necesite transmitir algo, primero miraría el bit de estado que le indica si hay o no una señal presente en su canal. Si no lo hay, configura la dirección de envío y establece su dirección de reconocimiento y dispara. Si lo hay, vuelva al modo rx y tenga un período de tiempo de espera.
Su primera opción parece estar describiendo un protocolo de red de balizamiento. Como observó, esto tiene la desventaja de un tráfico continuo y un mayor uso de energía. Sin embargo, es realmente la única forma en que puede garantizar la comunicación si algo es sensible al tiempo.
Su primera opción permite que el maestro controle el acceso a las ondas de radio: los esclavos solo transmitirán cuando el maestro se lo indique. Esto puede ser bueno en situaciones de alto uso para evitar colisiones, pero requiere que los esclavos permanezcan encendidos al menos siempre que tengan algo esperando para enviar al maestro, y requiere que el maestro sondee "con la suficiente frecuencia".
(Supongo que por "paquete de respuesta" probablemente se refiere a un paquete ACK con carga útil, aunque se puede implementar la misma dinámica descrita anteriormente si el esclavo cambia manualmente brevemente al modo PTX para enviar el paquete de respuesta poco después de que el Maestro lo solicite) .
Para algunas redes de sensores donde las transmisiones son menos comunes, es útil usar algo más parecido a su segunda opción. Escuchar antes de enviar no es 100% confiable por varias razones, por lo que puede haber colisiones, pero con poco tráfico pueden ser lo suficientemente poco comunes como para ser aceptables y, a veces, las lecturas del sensor no son críticas (si envía la temperatura cada 5 minutos, es por lo general, no es crítico perderse algunas actualizaciones).
Por lo tanto, las opciones principales se dividen en opciones de "tiempo maestro" y "transmisión asíncrona" (su tercera opción de "protocolo propio" también tendría que decidir sobre una de estas). Y cada uno tiene su nicho. En un diseño en el que el maestro envía una gran cantidad de datos (controlando las luces navideñas), utilizo el primero y dejo que el maestro sondee los datos de los esclavos según le convenga. En una red de sensores, estoy pensando en usar la segunda dinámica, en gran medida para permitir que los nodos esclavos del sensor duerman la mayor parte del tiempo.
erik kaplun