nrf24l01 +, shockburst mejorado con dos "maestros"

Navega tus respuestas
4

Quiero conectar una Raspberry Pi a un dispositivo basado en ARM MCU de mano que contiene una pantalla y algunos botones para mostrar la información de los comandos Pi y transmitir. Quiero usar nrf24l01 + transceptores de 2.4GHz para eso.

Estoy pensando en 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 auto-ack y, por lo tanto, podría liberarme de la gestión manual de ack, que 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 primario y que un dispositivo sea un transmisor primario, y solo este ú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 provocan la necesidad de una transmisión de datos.

He estado leyendo y básicamente hay tres soluciones posibles para este problema:

  1. 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 continuo en el aire, lo que es malo para los dispositivos alimentados por batería. Además, el PRX todavía 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.

  2. Configura 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?

  3. Ditch Enhanced Shock Burst y crea un protocolo propio. La solución menos favorecida, ya que implica más trabajo y carga más 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 resolviste. Especialmente me gustaría saber si hay problemas con la posibilidad dos.

    
pregunta jan

2 respuestas

2

La segunda opción es en realidad muy común. Esencialmente, el PRX y el PTX pueden ser por transmisión. Ambos deben estar en modo rx la mayor parte del tiempo, y cuando necesite transmitir algo, primero debe mirar el bit de estado que le indica si hay o no una señal presente en su canal. Si no la hay, configura la dirección de envío, configura la dirección de acuse de recibo y dispara. Si lo hay, vuelve al modo rx y tiene un período de tiempo de espera.

Su primera opción parece ser que describe un protocolo de red de balizamiento. Como ha observado, esto tiene el inconveniente de un tráfico continuo y un mayor consumo de energía. Sin embargo, es realmente la única forma de garantizar la comunicación si algo es sensible al tiempo.

    
respondido por el NickHalden
1

Su primera opción le permite al maestro controlar el acceso a las ondas aéreas: 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 cada vez que tengan algo esperando para enviar al maestro, y requiere que el maestro realice una encuesta "con la frecuencia suficiente".

(Supongo que con "paquete de respuesta" probablemente te refieres 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 ser solicitado por el Maestro).

Para algunas redes de sensores donde las transmisiones son menos comunes, es útil usar algo más como tu segunda opción. La escucha 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 infrecuentes para ser aceptables, y algunas veces las lecturas de los sensores no son críticas (si envía la temperatura cada 5 minutos, por lo general no es crítico perder algunas actualizaciones).

Por lo tanto, las opciones principales se dividen en opciones "maestra temporizada" 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 está enviando una gran cantidad de datos (controlando las luces navideñas), uso el primero y dejo que el maestro busque datos de los esclavos a su conveniencia. En una red de sensores, estoy pensando en utilizar la segunda dinámica, en gran parte para permitir que los nodos esclavos del sensor duerman la mayor parte del tiempo.

    
respondido por el Zeph

Lea otras preguntas en las etiquetas

¿Es importante determinar el tipo de soldadura utilizada en una placa y, de ser así, cómo? ¿Usos de inversores en este circuito?