Pregúntele a La-Tecnologia: ¿Son frecuentes los saltos en el NRF24l01 +?

Vimos muchos trucos con los módulos de radio nRF24l01 + 2.4 GHz. Los pedacitos se rompen mucho para el macho. Debido a que las radios pueden cambiar de frecuencia con relativa rapidez, [Shubham Paul] decidió aprovechar esta función para crear un canal de comunicación de salto de frecuencia rudimentario.

El código es increíblemente simple. Tanto el transmisor como el receptor simplemente escanean hacia arriba y hacia abajo a través de los canales definidos. Dado que las velocidades de reloj de cualquier par de Arduine probablemente difieran ligeramente, no es de extrañar que las radios finalmente se sincronicen. Ahora mismo, como solución rápida, [Shubham] usa resincronización de puerto serie: ambos están conectados a la misma computadora, y él solo les dice que ingresen por el mismo canal. Esa no es una solución terriblemente satisfactoria. (¡Pero es un gran comienzo!)

Mantener dos radios que intercambian continuamente canales sincronizados no es una tarea fácil, pero podría ser más fácil aprovechar el modo de reconocimiento del nRF. Si el retraso entre un mensaje de acuse de recibo enviado y uno recibido fuera constante, estos eventos (uno en TX y otro en RX) podrían usarse para resincronizar los dos ciclos de salto. Todo esto probablemente necesitaría más tiempo de resolución de lo que obtendría con un microprocesador que usa código Arduino, pero sería posible con temporizadores de hardware. Pero esto es pura especulación. Miramos a nuestro alrededor brevemente y no encontramos demostraciones de trabajo.

Entonces, La-Tecnologia, ¿cómo sincronizarías de forma remota dos nRF24 de forma económica? ¿O es una idea loca? Podría ayudar a impulsar las transmisiones frente a la interferencia de la banda de 2,4 GHz. ¿Alguien ha implementado su propio esquema de salto de frecuencia para el nRF24l01 +?

  • Shrad dice:

    Haga que cada uno de ellos envíe una solicitud de omisión a su colega después de recibir una ... luego solo tiene que encontrar una manera de hacer que decidan quién comienza la primera ronda y cómo reiniciar cuando se pierde la sincronización ... tal vez ir volver al canal anterior si al otro no se le envió un acuse de recibo de la solicitud? Algunos experimentos divertidos para hacer allí ...

    • Shubham Paul dice:

      "Tal vez vuelva al canal anterior si el otro no envió un recurso compartido a la solicitud" ... Lo intenté antes, pero todavía "desincronizo" el problema

      • Shrad dice:

        Creo que la clave es que un módulo no puede saltar si aún no ha recibido la solicitud de salto de su colega ... el último estado bueno conocido siempre estará sincronizado y puede enviar una solicitud / acción de salto a un anillo . moda hasta que se hace un salto.
        Esto puede ser un poco confuso, pero tal vez pueda tener algunos consejos sobre topologías como anillo de señal y otras transmisiones de datos circulares como canal de fibra, etc.

        • Shubham Paul dice:

          Faros

        • Elliot Williams dice:

          Un problema con el salto-ack, como sugiere, es que la mitad de la razón general para saltar es omitir los canales defectuosos / de interferencia por los que no pasa nada. Si simplemente salta al stock, se queda atascado en los canales defectuosos.

          • Shubham Paul dice:

            Si claro. El hop-ack solo es adecuado para la sincronización. Implementaré la función espectral nativa del nrf para separar los canales malos de los buenos.

  • daid303 dice:

    Un bucle de bloqueo de fase resolvería el problema de la deriva. Si omitió una frecuencia y el otro lado aún no lo hizo, espere un poco más antes de omitir el siguiente salto. Si el otro lado salta antes que usted, espere un poco menos para el siguiente salto. Con esto, incluso puede sincronizar inicialmente, pero puede llevar algún tiempo.

    • Shubham Paul dice:

      Pero como lo averigua el lado rx / tx, ¿el lado opuesto saltó o no? esperar no puede ser una opción porque "el tiempo de espera cambia según la velocidad del reloj [& latencies] del procesador, que siempre es diferente y siempre hará que se sincronice, así que trato de omitir la función de reconocimiento automático, que me da un buen tiempo de sincronización, pero no 100% perfecto (tal vez 85)

      • Moryc dice:

        Un ch-side termina un mensaje con un byte de salto o sin salto, que también codifica el siguiente número de canal, después de ACK ambos cambian de canal. El lado Rx envía "¿estás ahí?" message, y después de un ACK del lado tx, espera el siguiente mensaje. Esto agregará mucha cabeza superior, pero mantendrá ambos lados sincronizados ...

        • Shubham Paul dice:

          Pensé en probar esto. Gracias

          • elektrobob dice:

            Comience con algo simple: conozca su secuencia de canales, use menos primero. RX siempre está esperando en el mismo canal. TX transmite en cada canal en orden, incluso si no se recibe ningún ACK. Algún día TX aterrizará y estará de acuerdo con RX. En ese momento, el RX marca su temporizador y sabe cuándo esperar al siguiente paquete. Pronto debería estar listo en modo RX.
            TX debe transmitir a intervalos precisos, use milis () para saber cuándo ha pasado dicho intervalo, p. 100 ms (comience con algo lo suficientemente grande, luego reduzca).

          • Shubham Paul dice:

            Sí, haría eso ... El canal de cambio es rápido probablemente alrededor de 200 microsegundos ...

          • hanelyp dice:

            Si ambos extremos conocen la secuencia de salto, pueden saltar sin un intercambio exitoso de paquetes, lo que es útil si una frecuencia en la secuencia tiene una interferencia particularmente mala. Si hay un margen de tiempo alrededor del salto de frecuencia, un receptor puede escuchar antes de que se espere un paquete, lo que le permite recibir un paquete si el transmisor está en su reloj un poco antes.

          • elektrobob dice:

            Normalmente se necesitan 130us para que el PLL se estabilice, pero como la gente ha notado, esto no está garantizado, a veces lleva el doble de tiempo.

  • Viejo dice:

    Eche un vistazo al tipo de Bluetooth, especialmente BLE. Todo está ahí para ver.

  • Vejestorio dice:

    Lo hice con otras radios. Es bastante sencillo. La primera parte que debe desarrollar es la sincronización del reloj. Dependiendo de qué tan rápido quiera saltar, el retraso entre paquetes y cuánto tiempo de visualización puede aceptar, esto puede ser banalmente simple (por ejemplo, calculadora de sincronización en rx) a complicado (modelos de reloj real, ...). Luego, omite ambos nodos a la vez con este reloj común.

    • Shubham Paul dice:

      Mira este. Gracias

  • tomkcook dice:

    Siempre existe el enfoque de "Tengo un martillo más grande que tú": dales ambos receptores GPS y sincronízalos con la hora del satélite. Haga que el número de canal actual sea el módulo 16 de la era UNIX y ni siquiera tendrá nuevos problemas.

    El costo es otro asunto, por supuesto ...

  • dassheep dice:

    Estos chips tienen varios tubos de escucha. Simplemente elija las pocas frecuencias entre las que desea saltar y escúchelas todas, luego simplemente haga el salto en el lado de la transmisión.

    • elektrobob dice:

      tienen 6 conductos, como en 6 direcciones desde las que pueden aceptar un paquete, no 6 receptores que pueden escuchar 6 frecuencias diferentes.

      • Erik Johnson dice:

        Y las direcciones pueden diferir solo en 1 byte

  • elektrobob dice:

    Definitivamente es posible hacer saltos de frecuencia con el NRF https://link.springer.com/chapter/10.1007/978-3-642-27329-2_101
    Sin embargo la implementación en este artículo es demasiado simple y no se tiene en cuenta que algunas veces no están garantizadas por la radio. En pocas palabras, el receptor puede tardar más en cambiarse que el transmisor. Una solución simple sería asegurarse de enviar un paquete cada vez que x sea lo suficientemente grande como para calcular algunos retrasos aleatorios.

    • Shubham Paul dice:

      Así es. Ese es mi problema exacto. Descubrí que, de hecho, el dispositivo rx cambia más rápido que el tx, mientras que el uso de una función automática acc ha mejorado la sincronización, pero no es perfecta.

  • invitado dice:

    Una cosa que hago con los contenedores de frecuencia es usar una referencia muy estable para el sintetizador y compartir la misma referencia con la MCU. Entonces, el error de frecuencia se refiere al error entre temporizadores en la MCU en un par RX / TX. El error de frecuencia se puede determinar mediante el algoritmo de corrección de compensación de CC. Esto puede ayudar con la sincronización. Sin embargo, la mejor manera de mantener la sincronización es tener una baliza maestra que sincronice el resto de la red. La estancia puede variar, pero 20 milisegundos parece un buen momento. Busque un protocolo aloha roto. Otra cosa que ayuda con la sincronización FHSS es hacer que los patrones de sincronización de cuadros para paquetes maestro-> esclavo sean diferentes de los paquetes esclavo-> maestro. Esto ayuda a reducir el intento de un esclavo de inspeccionar los paquetes de otro esclavo.

    • invitado dice:

      Un último comentario sobre esto. Si está interesado en implementar un contenedor de 900 MHz, también debería mirar TI CC1200. Esta pieza avanza años luz para este tipo de aplicaciones. Probablemente sea un poco más trabajo que el NRF24l01 para comenzar, pero vale la pena el esfuerzo. No, no trabajo para USTED.

      • elektrobob dice:

        También puede ver RFM69, que también es popular y sería mejor para saltos de frecuencia.

        • elektrobob dice:

          mejor que el NRF, no el CC1200.

          • Shubham Paul dice:

            ¿No es el rfm69 un receptor de radio de frecuencia única?

      • Shubham Paul dice:

        Gracias por el consejo. Planeo completar FH en el propio nrfs ​​porque tengo una fecha límite estricta. Sin embargo, CC1200 los probará muy bien más adelante.

      • Shubham Paul dice:

        Tengo algunos CC1100, aunque son bastante lentos para FH

      • Shubham Paul dice:

        Miré un poco CC1200 y encontré [http://www.ti.com/lit/an/swra482/swra482.pdf] que el tiempo de salto más rápido ("casi" tiempo de permanencia) es de 1,1 ms, que es muy lento en comparación con el tiempo de salto nrf 200us.

  • Sweeney dice:

    ¿Qué hay de mantener un ajuste firmado de 32 bits a la hora local? Empiece desde cero. Envíe los 16 bits bajos de tiempo + ajuste, más una diferencia con signo de 16 bits entre el tiempo ajustado y el tiempo recibido por el último paquete. Utilice la diferencia para corregir cualquier discrepancia en el tiempo establecido en cero (nota: no lo configure porque no sabe la hora a la que debe llegar el mensaje). Haga la corrección proporcional a la diferencia.
    Esto da como resultado que ambos relojes se disciplinarán entre sí a una hora acordada mutuamente. Puntos adicionales para desarrollar una deriva media y corregirlo automáticamente por adelantado.

    • Absolutamente automático dice:

      ¡NTP (Network Time Protocol) hace algo similar!

  • Ingeniero de Backwoods dice:

    El receptor debe poder escanear toda la lista de saltos durante el tiempo necesario para entregar el preámbulo; de lo contrario, siempre se perderá algunos paquetes. Me proyecta saltos de frecuencia y otros sistemas espectrales propagados para vivir.

    • Vejestorio dice:

      Este es solo el caso asumiendo que no hay sincronización entre TX y RX. De lo contrario, solo necesita saltar en ambos lados hasta que tenga buena suerte y mientras un paquete TX y RX se superponen. A partir de ese momento, salten juntos.

      • Scotty dice:

        Otro método es dejar de saltar del lado del esclavo (suponiendo que tenga una estadía corta y las balizas maestras pidan por cada salto). Espere a que pase el dueño. Con un recipiente rápido, esto suele suceder varias veces por segundo. Si no ve el maestro en unos pocos canales consecutivos (tal vez canales malos en ese momento), pruebe con el siguiente canal de la plantilla. Esto funciona * mucho * mejor que intentar tener suerte.

        • Vejestorio dice:

          No veo por qué saltar al RX empeoraría el sistema. En tu caso puede ocurrir que, como te des cuenta, el receptor esté en un canal incorrecto. Si el RX también salta con una secuencia diferente a la del TX, esta probabilidad se reduce en gran medida, pero no cambia la tasa de aciertos. En mi experiencia, muchas radios usan un patrón de salto RX lineal con una duración aproximadamente 2-3 veces mayor que la duración de la ranura al intentar sincronizar.

        • Shubham Paul dice:

          Si dejo de saltar por ambos lados, el gol de FH se pierde.

  • Trevor Clarke dice:

    Acabo de comprar 20 de estos para jugar este fin de semana. Planeo usar DH para obtener una clave común que pueda ingresar al cifrado ACTUAL en modo CTR para el flujo del canal. El último canal de cada bloque de 32 canales se utilizará para la sincronización. Por lo tanto, una unidad debe desincronizarlos para un máximo de 31 paquetes.

  • Ixbidie dice:

    Eche un vistazo a la especificación de Bluetooth. Usan un paquete de inicio maestro como punto de anclaje y luego temporizadores precisos para asegurarse de que se sincronizan. Luego tienen una deriva ... así que tienes que usar la transmisión como punto de anclaje de vez en cuando. Especificaciones de Bluetooth. incluso comienza con límites de tiempo flexibles y optimiza la conexión cuando es posible reduciendo las tolerancias tanto como sea posible.

    • Shubham Paul dice:

      Sí, esa es una forma más de volver a coronar.

  • Roberto dice:

    ¿Por qué no considerar los protocolos existentes? Hay muchos protocolos de transmisores RC con salto de frecuencia. Es un firmware alternativo para cualquier transmisor que tenga código para la mayoría de los receptores RC existentes. Para algunos protocolos solo necesita agregar un transmisor como estos Nrf24l01 +. Puede encontrar algunas ideas para un código de salto de frecuencia confiable.

    También utilizo Nrf24l01 + para algunos de mis robots y pienso en el protocolo de salto de frecuencia. Actualmente he programado un canal fijo para cada bot.
    http://www.thingiverse.com/thing:941033

    • Roberto dice:

      Encontré este documento y se me ocurrió una idea.
      http://www.ti.com/lit/an/swra077/swra077.pdf
      La forma de encontrar el transmisor suena bien. Solo espere un período de tiempo para saltar a través de todas las frecuencias escuchando en un canal y pruebe el siguiente canal. Si recibe algún paquete legal, lo sincroniza.

      Para mantenerse sincronizado, en cuanto a: el transmisor siempre enviará 10 paquetes con una frecuencia y el salto a la siguiente. Cada paquete contiene un contador y si el receptor ve el décimo paquete, también saltará a la siguiente frecuencia. Por seguridad, puede configurar un temporizador que adivine el siguiente salto, para asegurarse de que tiene algo de pérdida de paquetes y no obtiene el décimo paquete.
      Creo que este código no será muy complicado.

      • Shubham Paul dice:

        Gracias. Doctor hermoso.

      • Shubham Paul dice:

        Recibí uno más http://www.ti.com/lit/an/swra482/swra482.pdf

  • sonofthunderboanerges dice:

    Instale un sistema de reloj direccionable en cada unidad. Asegúrese de que todos los relojes estén configurados a la misma hora hasta el segundo. Podrías hacer esto con un Arduino simple. A cada hora durante el segundo 0, todas las unidades comienzan una nueva secuencia de saltos de saltos (reinicio completo) y cada salto se cronometra cada x segundo con el mismo Arduino en consecuencia. Todas las unidades tienen el mismo patrón de salto programado en Arduino. Siempre que el Arduino sea estable y preciso (sea lo que sea), el salto debe estar sincronizado. Sin embargo, si el patrón de saltos dura más de una hora, no obtendrá muchos saltos únicos cada hora (nota: también puedes ir más allá de cada hora). Pero eso se trata más de un problema de seguridad de interceptación de radio que no parece ser tan crítico en este caso.

    Tampoco critican que sean iguales hecho hora del día, como desde la WWV o el Observatorio Naval. Siempre que todos coincidan o se sincronicen con la configuración de hora de la unidad principal, está bien. Y "unidad maestra" puede ser un nombre inapropiado aquí, porque nadie realmente la necesita. Simplemente lo llamo así por simplicidad.

    Tampoco tienes que esperar la próxima hora para sincronizar. Simplemente escriba una rutina iniciada manualmente para el Arduino que le diga que reinicie completamente a la hora xx: xx: 00. Luego, lo vuelven a hacer cada hora desde entonces. Haga esto en todas las unidades que ya tengan sincronizados sus relojes principales.

  • Massimo dice:

    Si estás interesado:
    https://github.com/Max-62/nRF24L01-Frequency-Jumping-FHSS

    Saludos

  • brianx dice:

    Haga que un Arduino designado como esclavo solicite que el maestro envíe su valor micros () al inicio del esclavo. Luego, solicite periódicamente micros () al propietario. Cada desviación del reloj será clara en los cambios relativos a estos números. Con el segundo intercambio, puede comenzar a calcular la frecuencia con la que el módulo designado como esclavo debe aumentar o disminuir un valor microscópico. Para evitar el problema de los 71 minutos, agregue un contador de rodillos y use 64 bits para el tiempo de intercambio. Para evitar el problema del 584 milenio, piense un poco más en el interior de la caja. En el caso de que el cambio de hora del maestro sea negativo, suponga un reinicio y ponga en marcha el reloj, pero mantenga el factor correcto. Este método no funcionará de manera tan confiable para los Arduinos que están expuestos a cambios extremos de temperatura porque sus relojes no coincidirán por encima de la temperatura. En el caso de cambios extremos de temperatura, es posible que sea necesario aplicar una corrección adicional a corto plazo además de esta corrección. Al inicio, y si las frecuencias aún están inactivas, la recuperación es solo una cuestión de que el maestro salte a velocidad normal y el esclavo salte mucho más rápido hasta que se vuelvan a sincronizar. No sincronizado podría definirse como los saltos normales que no recuperan una señal después de atravesar todas las frecuencias permitidas. Si la sincronización no se recupera dentro del cuadrado del número de frecuencias permitidas, se debe suponer que el otro extremo está apagado y la exploración debe continuar pasivamente para evitar saturar el aire innecesariamente.

  • Phil_G dice:

    Muchas de las respuestas aquí hablan sobre la operación de sincronización y los métodos para sincronizar con precisión desde el transmisor y el receptor, pero no es necesario. Si el transmisor envía un paquete en cada canal exactamente cada 5ms, entonces el receptor usa cada paquete recibido para reiniciar el temporizador "próximo paquete esperado dentro de ...", digamos 6ms. Si no ve el siguiente paquete, salta de todos modos y espera 5 ms. Y de nuevo, si otro falla, manténgase sincronizado. Si varios fallan, el receptor se sienta en el canal base hasta que recibe un paquete, desde donde se sincroniza y salta nuevamente. Así que mi propio proyecto NRF24L01 FHSS R / C está configurado y funciona perfectamente 🙂

Fernando Román
Fernando Román

Deja una respuesta

Tu dirección de correo electrónico no será publicada.