nRF24L01

[Democrito]

Hola,

En este hilo vamos a tratar el nRF24L01, y para comenzar vamos a tratar el receptor desde una FPGA. El emisor todavía no está diseñado, así que de momento esta parte se encargará un Arduino.

Hace muchos años traté este transceptor desde un PIC con una libería prestada y yo en aquel tiempo era completamente "novel" (novato) y en todos los sentidos. En aquella época no había mucha información, y menos todavía con aplicaciones desde los microcontroladores PIC. De hecho me terminé pasando a Arduino, porque para hacer cualquer cosa, y con tan escasa información, tenías que tener una curva de apredizaje bastante elevada.

Los nRF24L01 son muy, pero que muy puñeteros y os explico por qué (puedes tener todo bien y fallar). Cuando lees las características dice que es de ultrabajo consumo, entonces uno piensa que con poca corriente ya puede funcionar. Y es cierto que consume poca corriente, pero hay momentos de tiempos muy muy cortos, que necesita mucha corriente. Entonces, de lo primero que has de olvidarte es de alimentar al transceptor desde un Arduino o una FPGA. Has de pensar en alimentarlo con una fuente que dé más de 250 mA (a 3.3V). Arduino y muchas FPGA que son compatibles con 3.3V llevan un regulador de tensión que como mucho te dará 50 mA. Haré mucho énfasis en la corriente de alimentación en todo este hilo, porque si no se cumple ese requisito, verás fallos intermitentes, es decir, todo estará bien, pero falla, o en ocasiones falla. Tienes que conseguirte 3.3V con más de 250 mA de corriente, de otro modo tendrás problemas. En otro post os hablaré más sobre esto. Tuve la suerte, de que cuando comencé a conocer este transceptor, lo alimentaba con una fuente de PC, tomando los 3.3V de ella, y todo iba como esperas. Pero como el proyecto que estaba haciendo era para el mundo real (no sólo experimentar), fue ahí cuando comenzaron los problemas. Diseñé un brújula digital, que iba a ir en un barco pesquero. La brújula era un encoder digital y desde el mástil tenía que enviar vía radio (a través del nRF24L01) a la cabina de mando el dato de la posición y un motor de pasos indicar la posición (el cliente lo quería con visualización analógica). Al cambiar de fuente, es decir, poner cualquier regulador de tensión de 3.3V comenzaron los problemas. Hasta que al final, al poner un regulador de tensión como dios manda, todo fue bien. Usé una especie de 7805 pero que en vez de 5V daba 3.3V (no recuerdo bien los detalles porque fue hace muchos años)

Moraleja: Si quieres que todo te funcione bien con estos transceptores, lo primero de todo es fabricarte o buscar una buena fuente de 3.3V para alimentar a los nRF24L01.

Los nRF24L01 son capaces de recibir información y enviarla. su funcionamiento es "half duplex", esto significa que funciona como un "walky talky", es decir, puede enviar y recibir, pero no a la vez.

Para comenzar sólo vamos a tratar este tema desde el punto de vista de emisor y receptor. Se puede hacer que tengan ambas funciones, pero no al mismo tiempo y para ello se necesita un protocolo, es decir, algo que arbitre para ponerse de acuerdo, para poder hacer que pueda emitir y recibir la información que queramos y evitar colisiones. Una caracterísica que tiene los nRF24L01 es que aunque sólo reciba, también emite, pero esto queda por debajo del usuario medio. Cuando el receptor recibe información, cuando termina de hacerlo emite al emisor si le ha llegado algo, es una forma de asegurar la información. Todo esto está disponible para el usuario, pero no para quien maneja una librería, o en un diseño en FPGA. Todo esto lo veremos en post más avanzados.

Presentación del receptor:

Adjunto un receptor para FPGA, aprovecha todo el ancho de banda, es decir, puede recibir 32 bytes de un golpe. Como todavía no tengo diseñado el emisor, pondré como ejemplo un emisor desde Arduino.

El receptor está configurado para recibir a 250 Kb/s, es la frecuencia de configuración más baja y la razón de ello es que cuanta más baja es esta tasa más distancia cubre. Puede funcionar a 2 Mb/s, 1 Mb/s y 250 Kb/s. Pero no es la frecuencia que emite o recibe, sino la tasa de transferencia de datos. La frecuencia real va en el orden de 2.4GHz (de ahí que en su nombre contenga el número "24", y en realidad es 2.4) hasta 2.5GHz.

Cuando hablemos de canal estaremos hablando de la frecuencia que estamos usando (no de tasa de transferencia), que en este caso es zona wifi porque esa zona es la legal para el wifi y experimentos.

El canal que usa el receptor FPGA es el canal "4C", o en decimal 76. Tomé este canal porque es el que usa por defecto la librería más famosa en Arduino, que se llama "TMRh20". En el ejemplo que adjunto esto no se puede cambiar, pero en el futuro haré que esto se pueda modificar.

Por otra parte, cuando tienes definido el canal, luego hay que defiir la dirección. Esto se debe a que puede haber múltiples receptores (o emisores), pero pueden tener direcciones distintas si quieres enviar algo concreto a uno de ellos en específico. En el ejemplo que adjunto, la dirección es "000001" en ASCII (es decir, un valor de 0 a 255 que se repite 6 veces). Son 6 bytes. En realidad como máximo vas a poder comunicarte con 32 transceptores distintos (es decir, especificando a uno de ellos), aunque en teoría sería con 127, pero es en teoría. Lo ideal es que de una direción a otra, haya la mayor diferencia posible, para evitar errores. Como ya habrás deducido con sólo 5 bits podemos deducir una dirección, sin embargo se usa 6 bytes para aumentar la seguridad de que al que le llega la información es a quien se le especificó. De esto ahora no has de preocuparte, pero es buen que sepas que en los ejemplos que adjunto (FPGA y Arduino) la dirección es "000001" en ASCII, y el canal usado es "4C" en hexadecimal.

Ejemplo prueba:

Adjunto un ejemplo práctico, donde un Arduino envía información y un receptor desde una FPGA recibe los datos.

Está claro que lo que envíe el emisor, luego lo recibirá el receptor. El código que adjunto para Arduino te parecerá extraño y es debido a que uso el SPI de forma directa, es decir, manejo de forma voluntaria el pin CE y CS, y especifico exáctamente los bytes que quiero enviar a través del comando "SPI.transfer". Lo hice de esta manera porque luego todo esto lo tenía que traducir a instrucciones para FPGA (lleva un pequeño microcontrolador que se maneja con lenguaje máquina). Lo importante del código es donde sale esto:

Es ahí la zona del programa donde especifico lo que quiero enviar. En este caso es el contaje de un contador que cuenta desde 0 hasta 255 (y vuelta a comenzar) y se repite para los 32 bytes que envíe. En post futuros pondré otros ejemplos, incluido el serial.

Este es el ejemplo más básico que se me ha ocurrido, la cuestión ahora mismo es que si haces la prueba lo puedas replicar.

Veamos ahora el diseño FPGA desde Icestudio:

Se ve raro porque tiene 32 bytes de salida, aunque sólo vamos a comprobar lo que sale por "q0" (puedes probarlo con cualquier otra de las salidas, todas salen lo mismo) y lo enviamos a los ocho leds, este caso, de la Ahambra. Se verá el contaje en binario de los leds. Si lo ves, es que te funciona.

Para hacer esta prueba, os adjunto un pinout del nRF24L01 y lo tengáis a mano para luego hacer las conexiones.

Es visto desde arriba.

Quien lo pruebe, por favor, que lo comente. Cualquier duda o lo que sea, aquí estoy. 

Cuando alguien trata de explicar un proyecto, puede pasar desapercibido cosas importantes que el que trata de explicarse en ese momento no lo tiene presente, por eso es importante que cualquier duda sobre conexiones, interpretaciones, dudas, etc, se haga saber.

Por último decir, que antes de hacer este proyecto que adjunto, probéis los transceptores desde Arduino, cualquier ejemplo sencillo, y una vez que te funcione, entonces pasar a este que propongo aquí con emisor Arduino y receptor con FPGA. Esto lo comento porque es importante familiarizarse con este tema primero con algo que está muy probado y que a tí también te funciona, y luego ya saltamos a otro nivel de abstracción (también sencillo pero de otra naturaleza).

No hagáis caso a los comentarios que hago en el programa de Arduino, son cosas que iba cambiando y luego no modifiqué el comentario. Con tiempo ya iré corrigiendo y explicando con detalle todo lo que ahí hay. Lo mismo para el diseño en FPGA, pero en este caso, apenas hay comentarios.

Saludos.

[Democrito]

Una de las cosas que comento como anécdota en el post anterior es que fabriqué una brújula digital, me equivoqué, era una veleta digital (para saber desde dónde veía el viento).

[Democrito]

Si abres el circuito, verás que registro la salida (en este caso la salida "q0") a través de la patilla "done". Toda salida que quieras usar has de registrarla con un registro de 8 bits y validarlo con la patilla "done". Si conectas los leds directamente a la salida deseada, verás cosas raras porque detrás (dentro del circuito) hay 32 registros de 8 bits en modo de desplazamiento. No registré las 32 salidas porque no siempre se necesitan todas y complicaba innecesariamente el circuito. Todo lo que uses, regístralo con la patilla "done".

[Democrito]

Del pinout del transceptor hay un pin que no lo usamos en este proyecto, es el pin de interrupción "IRQ".

Sobre los problemas de alimentación, dejo un enlace que habla de ello y es corto de leer, está en inglés: https://arduinoinfo.mywikis.net/wiki/Nrf24L01-2.4GHz-HowTo#Power_Problems:

Recomiendo leer todo lo que en esa web comenta. La lástima es que está en "Comic Sans"...

Recuerda que, para que el emisor y receptor se entiendan, han de tener el mismo canal ( 'h4C en este proyecto ) y misma dirección (000001 en ASCII, que sería 30 30 30 30 30 31 en hexadecimal), si usas otro programa emisor tienen que tener esos dos parámetros como indico.

Si desde otro programa emisor envías texto, recuerda que quizás pueda terminar con los caracteres no imprimibles CR (13) LF (10), y que los "string" terminan con un carácter null, es decir, cero (\0).

[charli va]

Gracias Demócrito! trabajazo como siempre!

--
Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/81f9b1a2-e520-46fa-8d3c-15fd83e12505n%40googlegroups.com.

[flip113]

Democrito lo primero darte las gracias por iniciar este proyecto que me parece muy interesante, decirte que probe el proyecto y no me funciono. Los módulos Nrf24l01 que utilice los tengo probados con proyectos en Arduino y funcionan bien. Estoy utilizando la versión icestudio estable 0.10

Estaré al tanto de este hilo. 

[Democrito]

Hola Flip,

He vuelto a cargar los adjunto que puse ayer, y después he quitado la alimentación para asegurar que se quedaba sin configuración previa, y me sigue funcionando. Veo el contaje binario en los leds.

No se me ocurre cuál puede ser el fallo porque doy por hecho que lo habrás montado todo bien y alimentado correctamente. Ahora mismo no imagino qué puede ser. Prueba a intercambiar los transceptores, es decir, hacer un enroque, y sigue así y tienes otros, prueba con esos otros.

De momento no puedo decirte nada más. A ver si hay más gente que lo prueba y comenta su experiencia.

En estos día voy a mirar a programar otro programa para Arduino (como emisor), que sea más sencillo de manejar y se vea todo más claro.

Muchísimas gracias por probarlo!

Saludos.

[Democrito]

He probado una cosa. Se trata de cambiar la tasa de transferencia, de 250Kb/s a 1Mb/s. Tanto el transmisor como el receptor han de tener la misma tasa. Pues cuando modifico ese parámetro no me funciona, y debería hacerlo. Me ha dado por probar esto porque los nRF24L01 antiguos no se pueden configurar la tasa a 250Kb/s, sólo se puede elegir entre 1Mb/s y 2Mb/s.

La diferencia entre el transceptor antiguo y moderno es que en el chip, el antiguo pone "nRF24L01", y el moderno pone "nRF24L01+".

Ese plus (+) es lo que los diferencia.

Voy a ver si consigo saber qué es lo que pasa con la tasa de transferencia.

[flip113]

Hola Democrito los módulos que estoy usando son nRF24L01+, estoy observando que después de encender la FPGA como al minuto se encienden los led 0,2,4,6, después como a los dos minutos se encienden los led 1,3,4,5,6,7, después como al minuto se encienden todos los led, cada cierto tiempo va cambiando la secuencia de los led, si pulso el pulsador no hace nada en el momento de pulsarlo pero sigue cambiando la secuencia de los led cuando le da la gana, es como si faltara sincronización entre el emisor y el receptor.

[Democrito]

Ese tipo de errores suelen ser debido a problemas de alimentación y de esto tengo mucho que hablar. De todas formas (sea problema de alimentación o no) voy a re-escribir todo el código que lleva el pequeño micro en la FPGA, y por otra parte buscaré la forma más compatible y sencilla de configurar como emisor desde un Arduino. Cuando crea que ya he conseguido algo robusto os daré noticias.

Gracias por las pruebas, Flip. Y no te preocupes más de la cuenta, es un primer acercamiento, y corre por mi cuenta ver qué es lo que sucede. Cuando saque algo nuevo necesitaré que lo testees.

[flip113]

Ok Democrito, estaré al tanto

[Democrito]

Hola Flip,

Te vuelvo a adjuntar un circuito RX para Icestudio y un programa TX para Arduino. Esta vez al programa Arduino lo hago trabajar con una biblioteca.

Haz la prueba tal como está todo, ha de salir la cuenta en binario (0..255) repetida 32 veces en las salidas del circuito para Icestudio. Si te funciona, puedes hacer pruebas de distancia, en mi caso a 8 metros la señal llega perfectamente. Está configurado para una velocidad de transmisión de 1 MHz a la máxima potencia.

De momento la configuración no se puede tocar,  porque es fija para el receptor. Lo que quieras enviar desde el Arduino sí lo puedes tocar, es decir, los datos que quieras enviar al receptor.

El cableado se puede intuir, pero si tienes alguna duda sobre esto pregúntame. El cableado para la FPGA está claro porque viene etiquetado (creo que MISO y MOSI los he enrocado en esta ocasión, asegúrate de esto). Y el cableado para Arduino, yo uso un Arduino Nano, utilizo el pinout SPI hardware por defecto, con CE y CS en los pines 9 y 10 respectivamente (en el programa se ve eso). Cualquier duda me cuentas.

Saludos y gracias por las pruebas.

[Democrito]

He estado mirando las conexiones del Arduino Nano (es 100% compatible con Arduino UNO) con el transceptor y no son evidentes, entonces os dejo una imagen para que no haya confusión.

Las patillas MOSI, MISO y SCK son fijas y no se pueden cambiar de lugar, el hardware SPI del Arduino Nano funcionan en esos pines fijos. Las patillas CE y CSN sí las puedes modificar de lugar desde el programa que adjunté. En esta imagen CE y CSN están en el lugar tal y como lo configuré en el programa de Arduino.

Hoy he probado un módulo adaptador para los nRF24L01 y me ha encantado. Te ahorras tener que hacer cosas raras para conectarlo y lleva su propio regulador de tensión a 3.3V. Es decir, lo alimentas con 5V y el regulador lo convierte a 3.3V

Vale muchísimo la pena comprarlo porque el cableado se hace muy fácil y lleva un regulador de tensión que le dará la corriente necesaria (el regulador del Arduino o de la FPGA no valen, dan problemas intermitentes)

Saludos.

[Democrito]

Quería mostraros fotos de lo que tengo montado y explicar alguna cosas, pero parece ser que me quedado sin datos de alta velocidad y al ir tan lento lleva exceso de tiempo y ocurren cosas extrañas.

De todos modos os dejo con un vídeo del RX en funcionamiento, que no es gran cosa, sólo se ve contar en binario, pero es lo que recibe. Lleva incorporado el adaptador que os comenté antes, y como quería enchufarlo directamente a la FPGA, le añadí pines machos por la parte de abajo.

https://youtu.be/GdLhohr6IJM

[Democrito]

Os dejo con una imagen de lo que hay que hacer con el transceptor antes de ponerlo en funcionamiento. Así es como los tengo yo.

Se trata de soldarle un condensador electrólítico justo en los pines donde está la alimentación (recuerda que es de 3.3V, con 5 te lo cargas, sin embargo, las entradas y salidas son tolerantes a 5V, en esos pines no hay problema).

El valor del condensador electrolítico no es nada crítico, con uno de 10 uF ya es suficiente, pero si tiene más capacidad mejor (y hasta cierto punto).

Yo además los he envuelto en cinta de cobre adhesiva, pero esto es innecesario.

Si te fijas, uno de los transceptores de la foto tiene un condensador que es cerámico, de 100 nF; es insuficiente (comprobado).

No soldar un pequeño condensador electrolítico en los pines de alimentación (lo ideal es justo en esos pines, cuanto más lejos peor), te llevará a tener fallos de enlace intermitentes, muchos quebraderos de cabeza, y saber que todo está bien pero no funciona o hace cosas muy extrañas. Mucha gente no sabe esto y viven una verdadera frustración con estos transceptores.

Como muestra os dejo varios enlaces a fotos de otras personas que saben que para que el transceptor funcione correctamente hay que soldar un condensador electrolítico en el mismo transceptor.

1.) http://embedblog.eu/wp-content/uploads/2019/04/IMG_20190322_093906.jpg

2,) https://content.instructables.com/FFM/XQLR/IRF7SEL1/FFMXQLRIRF7SEL1.jpg

3.) https://i.stack.imgur.com/WQW4o.png

4.) https://circuitdigest.com/sites/default/files/inlineimages/u3/nRF24L01-Module.jpg

5.) https://i.stack.imgur.com/zeVvp.jpg

6.) https://www.14core.com/wp-content/uploads/2015/06/14Core_NRF24l021-011.jpg

7.) https://user-images.githubusercontent.com/71942715/99291319-509aa300-2848-11eb-995e-fd2829ba9829.png

[Democrito]

El pin IRQ no se utiliza en este proyecto. Ese pin sirve para crear una interrupción en el microcontrolador o FPGA y avisar de que han llegado datos. En la FPGA (RX), se comprueba continuamente si han llegado datos a través del SPI.

Si todo está bien configurado, se le envía 0xFF y te responde con el valor del registro de estado. Cuando el registro de estado es 0x42, entonces es que hay datos para leer y es entonces cuando los toma y los pone a la salida.

[flip113]

Hola Democrito, acabo de llagar de vacaciones, nada mas que pueda hago las pruebas y te comento. Un saludo

[Alfredo Carmona Mirats]

Excelente información, ...esos pequeños detalles, hacen la diferencia entre un buen montaje y la frustración que desasosiega ....continuamente.

Gracias.🙏🏼

--

Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/d66af539-8683-46ad-a93c-9bf4c5c89f24n%40googlegroups.com.

[charli va]

Muy buenas Demócrito!, he pedido unos y me llegan esta semana, en cuanto los tenga lo pruebo y te cuento.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CA%2BMbFFaG3HY2V278VKa%2BF5WdiS5G79H7cKqSpZXgG0JauvBs7w%40mail.gmail.com.

[Democrito]

Perfecto Carlos! En cuanto alguien me diga que le funciona me pondré hacer que el receptor pueda ser configurable y terminado eso comenzar a diseñar el emisor FPGA.

[Democrito]

Para añadir la biblioteca del nRF24L01 a Arduino, tenéis que tomar esta: https://github.com/nRF24/RF24

Le dais a la pestaña verde que pone "Code" y luego escogéis la opción "Donwload ZIP", una vez descargada, desde el IDE de Arduino añadís la biblioteca.

[Democrito]

Os dejo con unas imágenes y una breve descripción:

A la izquierda el adaptador para el nRF24L01, que facilita las conexiones y aparte se le puede alimentar con 5V, luego un regulador de tensión lo pasa a 3.3V

A la derecha el mismo adaptador, pero le soldé unos pines macho por debajo para poder conectarlo a la Alhambra directamente.

Aquí lo vemos pinchado en la Alhambra.

Lo mismo pero con el transceptor puesto y alimentado.

Otra vista más pero de lado.

En lo pines de arriba los estoy aprovechando para conectar el analizador lógico. Los "cocodrilos" de enchanche son estos y van muy bien.

Otro pinout para identificar el patillaje del transceptor, aunque si usas el adaptador no te será necesario porque viene serigrafiado.

Fin.

[Jo mo]

Ola Democrito,

Gracias for all this detailed information and pictures !

i can not resist to order an nrF24L01, too and try all this !!

Have a nice evening!

[Democrito]

Hello Joaquim!

The more people try it the better.

A hug and good night!

[flip113]

Hola Democrito, hice las pruebas y me funcionan los dos ejemplos que pusiste, eres un crack

Dejo el video de pruebahttps://drive.google.com/file/d/1Ixbnz_frvtL2cs5rLkntYR9Sfn-2F7zw/view?usp=sharing

[Democrito]

Perfecto Flip! y muchísimas gracias por esta prueba.

Por cierto Flip, no me deja ver el vídeo, me sale que pida acceso, te he enviado una petición.

Estos días me pondré a diseñar para que el receptor pueda ser configurable, y terminada esa parte comezaré el diseño del emisor (el emisor tendrá más "miga" que el receptor).

Ayer hice una prueba de distancia, configurado a 250KB/s, y como ya comenté, dentro de un hogar puede llegar hasta unos 8 metros (en mi caso es un pasillo y luego habitación). Después me fui a campo abierto y me salía una distancia de 20 metros. Para que los datos puedan ser fiables (en el sentido de llegar, no de corromperse) hay que evitar la distancia límite. Lo medí todo con un metro muy largo que tengo. Las pruebas siempre las he hecho alejado del suelo, poniendo el emisor y receptor en una mesa o silla, o aprovechando la repisa de una ventana. 

Trataré de documentar este mismo fin de semana todo en Github, porque está toda la información importante desperdigada entre posts.

Saludos!

[Democrito]

Adjunto un ejemplo más guapo que acabo de hacer en plan rápido.

Se trata de que el emisor (Arduino TX) le envíe al receptor (FPGA RX) una cadena de texto y una cuenta numérica, y se visualice a través de un terminal serie.

"Per aspera ad astra" es una frase en latín que usé en otro proyecto también como test, que viene a significar "Por el camino difícil hacia las estrellas". A la frase le he añadido una cuenta numérica. Ahora vosotros podéis cambiar todo esto y sustituirlo por lo que más os guste.

Subes el código de Arduino a Arduino, el ICE a la FPGA, y dentro de Icestudio abres el terminal serie y debe de aparecer el texto y cuenta numérica.

En el circuito veréis que he añadido una puerta Not de 5 bits, y es porque ha de leer el texto al revés para que salga bien.

[flip113]

He probado el ultimo ejemplo con el terminal serie y funciona perfecto, gran trabajo, esto va viento en popa.

[Democrito]

Perfecto!

[Democrito]

Ya he sintetizado todo el proyecto (lo realizado hasta ahora) en GitHub, a modo de micro-tutorial:

https://github.com/Democrito/repositorios/tree/master/radio/nRF24L01

Si alguien trata de montar este proyecto, por favor, id ahí, todo lo que hay aquí está desperdigado o es confuso. Y por confusión puede ser, por ejemplo, que los pines MISO y MOSI lo he ido cambiando de pines en la FPGA, es decir, si alguien pensaba que ya tenía el circuito montado, faltaba fijarse en este detalle y cambiar de lugar esos pines.

Los dos proyectos que verás en los ZIPs los probé antes de subirlos a GitHub. Funcionan muy bien.

En el micro-tutorial hago énfasis en lo de poner un electrolítico en la misma PCB del transceptor, y que hay que conseguir una fuente de 3.3V aparte que dé la suficiente corriente (más de 250mA).

En realidad no es un micro-tutorial, sino más bien una especie de setup para poner a funcionar el arduino y la fpga con el transceptor.

Saludos

[Democrito]

Acabo de probar el receptor en una Icestick, y funciona perfectamente. Se deduce que en FPGAs con reloj de 12MHz no debería de haber problemas. Adjunto circuito, he usado los pines "TRn", en el PMOD no se puede conectar (hubiera sido perfecto poder hacerlo) debido a la disposición de los pines de alimentación.

[Democrito]

En la Icestick me encontré que tenía que habilitar el puerto serie (VCP), esto creo que sólo sucede en Windows.

Vuelvo a adjuntar el proyecto para la Icestick, ya que antes sólo adjunté el receptor, faltaba el emisor para arduino.

Una vez que esté todo en marcha abres el terminal serie de Icestudio y has de ver una frase en latín con una cuenta numérica.

[charli va]

Buenas a todos! he hecho las pruebas con dos parejas de módulos distintos (2 normales y 2 de más potencia), adjunto las imágenes, una del módulo normal con el condensador sugerido por Demócrito y el de mayor potencia también con el mismo condensandor.

No puedo enviar vídeo porque tengo un problema con el móvil y no he podido grabarlo pero ha ido todo fantástico, tengo que comprarme un arduino nano pra probarlo pero en el uno ha ido todo fenomenal (quiero estos días migrar el ejemplo a una raspberry pico que estoy trabajando con ese chip y me gusta mucho, de e esto en cuanto lo tenga te haré un pull request).

Así que nada confirmarte que todo ha ido perfecto y adjunto por si alguno le interesa  la imagen del módulo de mayor potencia.

En las pruebas que he hecho con el módulo normal, me llega a unos 10 metros en interior, con alguna puerta cerrada entre medias y en exterior he conseguido llegar a unos 20.  

Con el módulo extendido en casa me ha cubierto toda la casa sin problemas (máxima distancia yo creo que ha sido de unos 15 metros, pero en exterior he llegado hasta los 95m sin pérdidas.

Muchas gracias Demócrito, este es un tema muy interesante a ver si entre todos podemos darle cuerpo.

Un abrazo!

--

Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/d01dbf82-f6c1-4f32-8ba9-acbf154294bcn%40googlegroups.com.

[Democrito]

Muchísimas gracias por hacer las pruebas Carlos!!!

Esto que voy a comentar ahora no es para ti, que sé que lo sabes, sino para quien lea este post y no lo sepa: Arduino Nano y UNO son lo mismo, sólo cambia en tamaño del PCB, llevan el mismo microcontrolador, por tanto las entradas/salidas son idénticas.

La necesidad del condensador creo que es debido a que lo he configurado todo a la potencia máxima (existen 4 niveles de potencia). Si se configurase a potencia mínima creo que no haría falta ponerlos, sólo cubriría la distancia de estar los dos muy cerca, en plan experimentar. He pensado en que la potencia siempre sea máxima porque facilita la configuración, pero si alguien quiere que esta parte se pueda configurar, por favor, que lo diga.

Dentro del nRF24L01 hay unos registros de configuración. El registro 0x26 tiene dos bits para configurar la potencia, y en ese mismo registro también se configura la tasa de transferencia vía radio (250Kb/s, 1Mb/s y 2Mb/s). Este es el registro:

Los bits 2:1 se encargan de la potencia.

Los bits (por separado) bit3 y bit5, de la tasa de transferencia. Tal que así:

bit5 = 0; bit3 = 0  ------------------> 1Mb/s

bit5 = 0; bit3= 1   ------------------> 2Mb/s

bit5 = 1; bit3 = 0  -------------------> 250Kb/s

El bit0, aunque ponga "Obsolete" en realidad tiene uso. Sirve para activar los "nRF24L01+PA+LNA" (como uno de los que has mostrado en foto), es decir, los que llevan la extensión en el PCB para darle más potencia y sensibilidad. Por tanto, siempre ha de estar a 1, ya que los transceptores menos potentes, les da igual esa parte (siemplemente no la tienen).

En Arduino, estas dos instrucciones manejan el mismo registro (0x26) :

radio.setDataRate(RF24_250KBPS);

radio.setPALevel(RF24_PA_MAX);

Sobre el "PR", queda mucho por hacer antes de convertir esto en algo oficial, es sólo un protipo de puesta en marcha. Por ejemplo, el SPI no va a 3MHz (no le cambié el dibujo al módulo) está un poco por debajo de 1MHz y se debe a que le tuve que modificar los tiempos de nivel alto y bajo del SCK, y a la señal MOSI le tuve que hacer una cosa para que se mantuviera en alto y sólo cambiar justo cuando va a enviar los datos (esto también es así con el protocolo I2C).

Me queda por añadir que pueda ser configurable el canal, la dirección y la tasa de transferencia, y si me decís que añada la potencia, entonces también lo haría.

Mi idea es terminar el receptor (que sea configurable) y optimizarlo porque ahora mismo es lento. Luego crear un módulo emisor (será un pelín más complicado que el receptor, ya lo ví cuando lo desgrané con Arduino). Y si todo va bien, tener un módulo que pueda ser emisor y receptor al mismo tiempo, pero para este tipo de comunicación será necesario un protocolo.

Nada más que añadir por el momento, y de nuevo, muchas gracias por las pruebas Carlos!

Un fuerte abrazo!

[charli va]

Gracias a ti por el currazo! tenía esto pendiente desde hace eones y has dado un super empujón para ponerlo en marcha, en cuanto pueda miraré bien el circuito para si veo algo que se peuda mejorar decírtelo y como os digo entre todos podemos crear un módulo muy interesante y con muchas aplicaciones.

--
Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/448a9fd0-fc3c-47f9-8a52-4c5a4ef14524n%40googlegroups.com.

[Democrito]

He estado optimizando el receptor todo lo que he podido. En las versiones que he adjuntado hasta ahora, iba con los pies de plomo y lo tenía muy limitado. Antes, el SPI tenía un clock de unos 900KHz, ahora ya funciona a 3MHz.

También he eliminado las temporizaciones de 100us (estas temporizaciones las hacía con programación) de los bytes SPI que separaban unos de otros.

Total, que ahora ya va a toda pastilla.

He registrado todas las salidas. Me di cuenta en que según como se aplique este proyecto podría dar problemas, que aunque yo avise de que hay que hacerlo (aunque no siempre es necesario), el que usa el módulo no tiene por qué saber esto. Así que por seguridad, todas las salidas están registradas. El problema de hacer esto es que ha aumentado considerablemente el consumo de LCs (unos 340 más que antes), por tanto no cabe por ejemplo en una Icestick.

Si no me encuentro demasiados problemas, creo que en menos de una semana ya tendremos un RX completo.

Saludos.

[Democrito]

Adjunto la versión mejorada que comenté en el anterior post.

[charli va]

Ando con líos de Icestudio y no me he podido poner a tope con esto pero lo probaré lo antes que pueda, mil gracias por el empujón! Este finde creo que podré ponerme a ello, ya te contaré.

El vie, 4 ago 2023 a las 19:30, Democrito (<spo...@gmail.com>) escribió:

Adjunto la versión mejorada que comenté en el anterior post.

--
Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/626d6bbf-fc65-46d6-9fff-2861393bcf9fn%40googlegroups.com.

[Democrito]

Carlos, no te preocupres por probarlo, a la vista no se nota nada (a nivel humano), es eficiencia y velocidad interna. Lo que sí necesitaré que probéis es cuando saque el modelo configurable, que creo que lo tendré para antes de la madrugada del lunes.

[Democrito]

Ya tengo el RX terminado, rápido y configurable.

El nuevo receptor y dos ejemplos, están en mi GitHub: https://github.com/Democrito/repositorios/tree/master/radio/nRF24L01

Ahí está la documentación general. Los que ya habéis leído ese tutorial, he añadido esta parte en el mismo:

https://github.com/Democrito/repositorios/tree/master/radio/nRF24L01#configuraciones

Para los que no conozcan GitHub, adjunto un zip con el proyecto en este post.

Saludos.

Os dejo con una canción que viene a cuento en plan "Tal día como hoy":

.https://www.youtube.com/watch?v=-vMBp6iUJzk

[Democrito]

Como siempre me pasa, se me olvida adjuntar... Aquí están.

[flip113]

Buen trabajo, hice pruebas cambiando el canal, la dirección y la velocidad, va fenómeno.

Un saludo, me pongo en modo escucha.

[Democrito]

Genial Flip, y muchísimas gracias por las pruebas.

Las actualizaciones siempre las hago en GitHub, de otro modo en cada post tendría que estar avisando. Esto lo comento porque con respecto al último adjunto que hice le he hecho cambios, aunque no afecta al funcionamiento en sí, pero he reordenado las cajas de configuración y en el circuito que se visualiza el conteo con los leds, me di cuenta que no estaba actualizado el SPI a 3MHZ, ahora todo eso está corregido, en el sentido de optimizado.

Creo que estos enlaces permiten hacer descarga directa de lo último que he actualizado: (parece ser que con los ZIP permite hacer esto)

* https://github.com/Democrito/repositorios/raw/master/radio/nRF24L01/RF24_Leds.zip

*  https://github.com/Democrito/repositorios/raw/master/radio/nRF24L01/RF24_Serial.zip

Y de nuevo, muchísimas gracias por las pruebas Flip!

[Democrito]

Hola,

Acabo de conseguir hacer funcionar un emisor FPGA con el nRF24L01.

El montaje que he hecho es de un emidor FPGA y un receptor Arduino. En el emisor FPGA hago que se repita 32 veces la cuenta de un número del 0 al 9, con intervalo de unos 500ms. Y el receptor lo muestra. Pongo un gif animado como muestra.

Era la manera más sencilla que se me ocurrió para hacer un test de funcionamiento inicial.

Adjunto el proyecto por si alguien está motivado a probarlo. De momento, está en plan "sucio". En estos días lo iré puliendo y trataré de poner ejemplos de comunicación de FPGA a Arduino, y de FPGA a FPGA. Este emisor cabe perfectamente es una Icestick.

Saludos.

[charli va]

Un gran avance Demócrito!

--

Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/1198e7cf-672a-4cfa-afbd-438d6b0882a9n%40googlegroups.com.

[Democrito]

Doy por finalizado el proyecto/tutorial. Acabo de añadir dos ejemplos, uno entre dos FPGAs y otro entre dos Arduinos. De esta forma se completa todas las combinaciones:

https://github.com/Democrito/repositorios/blob/master/radio/nRF24L01/readme.md#puesta-en-marcha

Por cierto Carlos, cuando me comentaste lo del PR todavía no tenía pulido los módulos, cuando quieras será bienvenido! Ahora hay emisor y receptor con FPGA. Y como bien decías, el poder enviar o recibir datos a distancia es mucho más útil de lo que a priori podamos pensar.

Ahora me voy a poner con otro proyecto más humilde, pero que a algunos les puede ser útil. Ya os contaré.

Saludos!

[charli va]

Mil gracias Demócrito! este finde intentaré probarlo, ando ahora con varios lios "interesantes" que pronto os contaré y que me tienen super focus.

Lo dicho amigo muchas gracias!!

--

Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/d0c8f83c-cdee-47c4-8d11-423376fb79f3n%40googlegroups.com.

[Jo mo]

Again muchas Gracias Democrito,

I will test those nRF blocks, when i will get my order (scheduled for mid October or maybe earlier, who knows )

I saw that you used your ATTO processor !

I may try to use ATTO soon for playing a bit with a Nextion screen (which  communicates trough his serial UART port) !

I ordered that Nextion screen (i need one for two DIY projects (an SMD oven and a plasma THC )

have a nice week !

[Democrito]

Joaquin,

I didn't know what "THC" was, I looked it up on the Internet and it seemed very interesting. It has PID control and that topic interests me a lot. Perhaps in October I will return to that project to apply it to keeping the distance of an "actuator" constant. On the other hand, the inverse of a THC would be a  shock absorber ...

At the moment I have only used PID control to position a DC motor with linear encoder, I documented it here.

Happy day and see you soon!

[Jo mo]

Hola Democrito,

Yes, THC is interesting in plasma cutting because sometimes the metal sheet is bended by the heat of the cutting! and as the torch is cutting only at 1 mm above the sheet, a deformation of that sheet can induce a contact between the torch and the sheet. this will make the sheet moving (because usually, the metal sheet is just lying on his support ( not fixed, can cause problems due to dilatation of metal))

In plasma cutting the arcing voltage (around 80 V) is "proportional" to the distance from the torch to the metal sheet!

So all we have to do is measure that voltage and use a PID to keep it constant (around 80V) by increasing or decreasing the z axis position of the torch!

For my plasma cutter i will just re-use the arduino PID code made by HaleDesign!

 I am not sure to have understood your sentence: "On the other hand, the inverse of a THC would be a  shock absorber " ?

Do you mean bring down the torch up to the contact with the metal sheet than lift by de desired cutting heigth? 

This will be ok, but just for each start of a cut! then if the height changes (too much) during thaht cut, we will have a problem !

Thanks and have a nice week end !

[Democrito]

Sorry Joaquim, I didn't explain the context about "shock absorber" or "damping", I was referring, for example, to the suspension of a car, as the opposite effect.

Maintaining a constant height, as well as its opposite effect, is what I found very interesting. Perhaps in the near future, I will try to experiment with this, but instead of using stepper motors, I would like to use a DC motor. In my case, it's just about experimenting and learning in case I ever wanted to solve something similar in the real world.

Thank you for your explanation. Have a fantastic weekend!

[charli va]

Wow Joaquim!! your toys are awesome!!! tell us your progress with it, that is very interesting tools.

--
Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/0a24065e-0f37-48d0-a483-d2d205b34b29n%40googlegroups.com.

[Jo mo]

Thanks Democrito, i understood!

In fact:

-with "shock absorber" the distance between the body of the car and the mean height of the road (mean on around 1 m of road) is kept constatant!

- and without "shock absorber"(the opposite)it is the distance between the body of the car and every cm of the road bellow the car which is kept constant!

And actually, with my plasma cutter i am somehow in the situation of "with shock absorber" with the problem that some times, i am hitting the end of the play on the "shock absorber" So this why i prefer to remove the shock absorber and feel all the little variations of the road

Yes Charly, there is a blue pill. ( order online our pre-designed metal sheets) !

and the red pill (make everything yourself ), i hesitate a little bit, and choose freedom against a higher quality cutting :-) . 

And also with the same machine but turning it upside down, i can do milling of wood and plastics ...

a little video

Big Hug and sorry for my quite off topic posts !

[Jo mo]

hello guys

I could test the configuration: TX arduino (emisor_test_text.ino)  ---> RX ecp5 fpga ( RX24_test_Serial.ice modified for my ecp5)

Comments on the journey:

1 - A shame :-p, i did not yet managed to code in verilog a pull-up for the ecp5, so for now, i did it on hardware, (see red arrow in picture)

 remark: i will try modifying the pinout.json file for my board. There we have the option to choose the pullup mode for every pin, but it will not be an ideal solution!

2 - As Democrito reminded me, i added the 10uF capacitors on the voltage adapters.

3 - in the first try,i got some unstable communication. my problem seem to be that i was powering both voltage adapters with the same voltage source (pink cable).
   after powering the adapter on the arduino side with the 5V of the arduino, everything was stable!  Maybe a bad grounding problem?!

Conclusion, In the end it works beautifully!

Gracias again Democrito

[Jo mo]

For the pull-up in ecp5, 

i just found a block from Benitos in his file  Megadrive_ECP5_test.ice

i will test it and add it to the IceIO collection !

[Democrito]

Hello Joaquim,

I think you have used an old version of the circuit. I removed the pull-up entry in the following versions. I leave you a link where the latest version is, and there is also the emitter and receiver for FPGA (it does not need Arduinos, I did the tests with two Alhambra IIs that I have). I'll give you a direct download link, and then the general information:

FPGA RX and FPGA TX: https://github.com/Democrito/repositorios/raw/master/radio/nRF24L01/FPGA_TX-FPGA_RX.zip

General Information: https://github.com/Democrito/repositorios/tree/master/radio/nRF24L01

Thank you very much for doing the tests and showing some photos!

A hug!

[vidal orellana]

Estimados buenas tardes;

con su permiso una consulta como puede ser posible una comunicacion con esos componentes hasta 1000 metros de distancia.

Gracias.

--

Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/b91666ab-ef63-4ada-a05a-74dbc5c2bce1n%40googlegroups.com.

[Jo mo]

Ola oswaldo,

your question is a bit wide open :-)

from a theoritical point of view , i am not an RF electronics experts. so i asqued your question to bingchat (free gpt4):

"

El módulo de radio NRF24L01 es un transceptor de radio de bajo costo y bajo consumo de energía que utiliza la banda ISM de 2.4 GHz. La distancia máxima de comunicación entre dos módulos NRF24L01 depende de varios factores, como la potencia de transmisión, la sensibilidad del receptor, la calidad de la antena y el entorno en el que se utilizan los módulos. En general, se puede esperar una distancia máxima de comunicación de alrededor de 100 metros en condiciones ideales. Sin embargo, algunos usuarios han informado que han logrado alcanzar distancias de hasta 1 km utilizando módulos NRF24L01 con antenas personalizadas y amplificadores de potencia.

Es importante tener en cuenta que el uso de amplificadores de potencia puede estar sujeto a regulaciones locales y nacionales, por lo que es importante verificar las regulaciones antes de utilizar amplificadores de potencia con módulos NRF24L01.

Espero que esto ayude. Hágamelo saber si tiene alguna otra pregunta."

From a practical point of view  my experience is quite limited with those module (i started two play with them 2 days ago). i can say that they are easy to use because there is a ton of DIY turorials, video about those nRF24L01

Ola oswaldo,

your question is a bit wide open :-)

from a theoritical point of view , i am not an RF electronics experts. so i quickly asqued your question to bingchat (free gpt4):
"

El módulo de radio NRF24L01 es un transceptor de radio de bajo costo y bajo consumo de energía que utiliza la banda ISM de 2.4 GHz. La distancia máxima de comunicación entre dos módulos NRF24L01 depende de varios factores, como la potencia de transmisión, la sensibilidad del receptor, la calidad de la antena y el entorno en el que se utilizan los módulos. En general, se puede esperar una distancia máxima de comunicación de alrededor de 100 metros en condiciones ideales. Sin embargo, algunos usuarios han informado que han logrado alcanzar distancias de hasta 1 km utilizando módulos NRF24L01 con antenas personalizadas y amplificadores de potencia.

Es importante tener en cuenta que el uso de amplificadores de potencia puede estar sujeto a regulaciones locales y nacionales, por lo que es importante verificar las regulaciones antes de utilizar amplificadores de potencia con módulos NRF24L01.

Espero que esto ayude. Hágamelo saber si tiene alguna otra pregunta."

From a practical point of view ,

My experience is quite limited with those module (i started two play with them 2 days ago). i can just say that they are quite easy to use with arduinos and fpga (thanks to Democrito).

Also, to help there is a ton of DIY turorials, video about those nRF24L01 on the web.

- A guy testing his nrf across his 1.4  km bike ride with multiple combinations of antenas and nrf24l 01 modules!
- Same guy playing with his nrFs to distances up to 14km (using a special yagy antena )

- And finally, same guy playing up to 30km

Sorry for that 50% human responses, i am starting my human to cyborg transition ;-)

Have a nice Sunday !

[Democrito]

Para complementar lo que decía Joaquim, añado estas imágenes gráficas:

Dejo un vídeo en español puesto en un momento concreto que también habla de la misma persona de los vídeos que te puso Joaquim:

https://www.youtube.com/watch?v=8YIy0IyV4c4&t=590s

Opcionalmente puedes verlo entero.

Saludos.

[charli va]

// In English bellow 

Como comenta Demócrito y Joaquim, hay dos módulos, estos son los que yo estoy utilizando , que son la referencia que ha indicado Demócrito.

En mis pruebas, con el pequeño, cubro entorno 7-10 metros en interior (no lo he probado en exterior) y con el grande con antena, lo he probado en exterior y he llegado a unos 95-100m .

Tengo pendiente probar a más larga distancia, porque realmente en los 100 me paré porque  donde lo hice no podía avanzar mucho más allá y realmente a los 100 llegaba sin problemas, la distancia en exterior también dependerá de si hay visión entre las antenas, obstáculos y el tipo de antenas.

Eso sí, muy importante, añadir los condensadores que indicó Demócrito, sin ellos, ambas placas ofrecen bastante mal rendimiento (inestabilidad en las comunicaciones).

// ENGLISH

As Demócrito and Joaquim mention, there are two modules, which are the ones I am using and are the reference Demócrito indicated.

In my tests, with the small one, I cover about 7-10 meters indoors (I haven't tested it outdoors), and with the larger one with an antenna, I tested it outdoors and reached around 95-100 meters.

I still need to test it at a longer distance because I stopped at 100 meters because I couldn't go much further where I was, and it was reaching 100 meters without any issues. The outdoor range will also depend on whether there is line of sight between the antennas, obstacles, and the type of antennas used.

However, it's very important to add the capacitors that Demócrito mentioned; without them, both boards offer poor performance (thanks Demócrito for this great tip).

--

Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/788461b7-caec-4188-98e5-3029454fb2ben%40googlegroups.com.

[flip113]

Hola Democrito, hice las pruebas y funciona perfecto, me falto hacer la prueba entra dos FPGA por que solo tengo una. Felicitarte y darte las gracias por el gran trabajo que has hecho, eres un máquina.

[vidal orellana]

Estimados buenos Días.

Saludos y felicitaciones por sus bonitos proyectos.

Tengo una consulta y con su permiso paso a plantear.

Con estos transductores es posible enviar una señal de internet para ampliar la cobertura como lo hacen los AP.

Mil gracias por sus respuestas.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/1e1c1ea9-5ad4-4f57-ad59-04245e85c1e6n%40googlegroups.com.

[Democrito]

Flip: Un placer! y muchísimas gracias por probarlo!

oswaldo: No lo sé, creo que directamente no, sin embago hay proyectos orientados en ese sentido en Arduino. Echa un ojo a este GitHub:

https://github.com/nRF24

y en especial, a este enlace: https://github.com/nRF24/RF24Gateway

[vidal orellana]

Estimado.

Muchas gracias, así lo haré .

--

Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/a81f06ec-9c04-4389-b7bf-e686fd5e62ccn%40googlegroups.com.

[Jesus Arias]

Hola Demócrito,

¡Qué acertado estabas con el tema de la alimentación del nRF24L01! Definitivamente hay que olvidarse de alimentarlo desde un regulador conmutado.

Alimentado con los 3.3V de una Raspberry-pico es incapaz de recibir datos a tan solo 10cm del emisor. La cosa mejora mucho si se alimenta desde un LDO y se pone un condensador de desacoplo grande, o mejor aún, también una autoinducción en serie con la alimentación (100uF y 22uH dan buenos resultados)

El problema está en el receptor. En transmisión no se necesita una alimentación limpia. (en mis prototipos transmito datos sin ACK y los papeles de emisor y receptor están bien definidos)

Lo que no esperaba es que la recepción fuese tan mala (inexistente) como para ni siquiera poder probar el software con el emisor a poca distancia. 0x1F4A9 para Nordic ;)

Saludos

El jueves, 13 de julio de 2023 a las 3:18:57 UTC+2, Democrito escribió:

Hola,

En este hilo vamos a tratar el nRF24L01, y para comenzar vamos a tratar el receptor desde una FPGA. El emisor todavía no está diseñado, así que de momento esta parte se encargará un Arduino.

Hace muchos años traté este transceptor desde un PIC con una libería prestada y yo en aquel tiempo era completamente "novel" (novato) y en todos los sentidos. En aquella época no había mucha información, y menos todavía con aplicaciones desde los microcontroladores PIC. De hecho me terminé pasando a Arduino, porque para hacer cualquer cosa, y con tan escasa información, tenías que tener una curva de apredizaje bastante elevada.

Los nRF24L01 son muy, pero que muy puñeteros y os explico por qué (puedes tener todo bien y fallar). Cuando lees las características dice que es de ultrabajo consumo, entonces uno piensa que con poca corriente ya puede funcionar. Y es cierto que consume poca corriente, pero hay momentos de tiempos muy muy cortos, que necesita mucha corriente. Entonces, de lo primero que has de olvidarte es de alimentar al transceptor desde un Arduino o una FPGA. Has de pensar en alimentarlo con una fuente que dé más de 250 mA (a 3.3V). Arduino y muchas FPGA que son compatibles con 3.3V llevan un regulador de tensión que como mucho te dará 50 mA. Haré mucho énfasis en la corriente de alimentación en todo este hilo, porque si no se cumple ese requisito, verás fallos intermitentes, es decir, todo estará bien, pero falla, o en ocasiones falla. Tienes que conseguirte 3.3V con más de 250 mA de corriente, de otro modo tendrás problemas. En otro post os hablaré más sobre esto. Tuve la suerte, de que cuando comencé a conocer este transceptor, lo alimentaba con una fuente de PC, tomando los 3.3V de ella, y todo iba como esperas. Pero como el proyecto que estaba haciendo era para el mundo real (no sólo experimentar), fue ahí cuando comenzaron los problemas. Diseñé un brújula digital, que iba a ir en un barco pesquero. La brújula era un encoder digital y desde el mástil tenía que enviar vía radio (a través del nRF24L01) a la cabina de mando el dato de la posición y un motor de pasos indicar la posición (el cliente lo quería con visualización analógica). Al cambiar de fuente, es decir, poner cualquier regulador de tensión de 3.3V comenzaron los problemas. Hasta que al final, al poner un regulador de tensión como dios manda, todo fue bien. Usé una especie de 7805 pero que en vez de 5V daba 3.3V (no recuerdo bien los detalles porque fue hace muchos años)

Moraleja: Si quieres que todo te funcione bien con estos transceptores, lo primero de todo es fabricarte o buscar una buena fuente de 3.3V para alimentar a los nRF24L01.

Los nRF24L01 son capaces de recibir información y enviarla. su funcionamiento es "half duplex", esto significa que funciona como un "walky talky", es decir, puede enviar y recibir, pero no a la vez.

Para comenzar sólo vamos a tratar este tema desde el punto de vista de emisor y receptor. Se puede hacer que tengan ambas funciones, pero no al mismo tiempo y para ello se necesita un protocolo, es decir, algo que arbitre para ponerse de acuerdo, para poder hacer que pueda emitir y recibir la información que queramos y evitar colisiones. Una caracterísica que tiene los nRF24L01 es que aunque sólo reciba, también emite, pero esto queda por debajo del usuario medio. Cuando el receptor recibe información, cuando termina de hacerlo emite al emisor si le ha llegado algo, es una forma de asegurar la información. Todo esto está disponible para el usuario, pero no para quien maneja una librería, o en un diseño en FPGA. Todo esto lo veremos en post más avanzados.

Presentación del receptor:

Adjunto un receptor para FPGA, aprovecha todo el ancho de banda, es decir, puede recibir 32 bytes de un golpe. Como todavía no tengo diseñado el emisor, pondré como ejemplo un emisor desde Arduino.

El receptor está configurado para recibir a 250 Kb/s, es la frecuencia de configuración más baja y la razón de ello es que cuanta más baja es esta tasa más distancia cubre. Puede funcionar a 2 Mb/s, 1 Mb/s y 250 Kb/s. Pero no es la frecuencia que emite o recibe, sino la tasa de transferencia de datos. La frecuencia real va en el orden de 2.4GHz (de ahí que en su nombre contenga el número "24", y en realidad es 2.4) hasta 2.5GHz.

Cuando hablemos de canal estaremos hablando de la frecuencia que estamos usando (no de tasa de transferencia), que en este caso es zona wifi porque esa zona es la legal para el wifi y experimentos.

El canal que usa el receptor FPGA es el canal "4C", o en decimal 76. Tomé este canal porque es el que usa por defecto la librería más famosa en Arduino, que se llama "TMRh20". En el ejemplo que adjunto esto no se puede cambiar, pero en el futuro haré que esto se pueda modificar.

Por otra parte, cuando tienes definido el canal, luego hay que defiir la dirección. Esto se debe a que puede haber múltiples receptores (o emisores), pero pueden tener direcciones distintas si quieres enviar algo concreto a uno de ellos en específico. En el ejemplo que adjunto, la dirección es "000001" en ASCII (es decir, un valor de 0 a 255 que se repite 6 veces). Son 6 bytes. En realidad como máximo vas a poder comunicarte con 32 transceptores distintos (es decir, especificando a uno de ellos), aunque en teoría sería con 127, pero es en teoría. Lo ideal es que de una direción a otra, haya la mayor diferencia posible, para evitar errores. Como ya habrás deducido con sólo 5 bits podemos deducir una dirección, sin embargo se usa 6 bytes para aumentar la seguridad de que al que le llega la información es a quien se le especificó. De esto ahora no has de preocuparte, pero es buen que sepas que en los ejemplos que adjunto (FPGA y Arduino) la dirección es "000001" en ASCII, y el canal usado es "4C" en hexadecimal.

Ejemplo prueba:

Adjunto un ejemplo práctico, donde un Arduino envía información y un receptor desde una FPGA recibe los datos.

Está claro que lo que envíe el emisor, luego lo recibirá el receptor. El código que adjunto para Arduino te parecerá extraño y es debido a que uso el SPI de forma directa, es decir, manejo de forma voluntaria el pin CE y CS, y especifico exáctamente los bytes que quiero enviar a través del comando "SPI.transfer". Lo hice de esta manera porque luego todo esto lo tenía que traducir a instrucciones para FPGA (lleva un pequeño microcontrolador que se maneja con lenguaje máquina). Lo importante del código es donde sale esto:

Es ahí la zona del programa donde especifico lo que quiero enviar. En este caso es el contaje de un contador que cuenta desde 0 hasta 255 (y vuelta a comenzar) y se repite para los 32 bytes que envíe. En post futuros pondré otros ejemplos, incluido el serial.

Este es el ejemplo más básico que se me ha ocurrido, la cuestión ahora mismo es que si haces la prueba lo puedas replicar.

Veamos ahora el diseño FPGA desde Icestudio:

Se ve raro porque tiene 32 bytes de salida, aunque sólo vamos a comprobar lo que sale por "q0" (puedes probarlo con cualquier otra de las salidas, todas salen lo mismo) y lo enviamos a los ocho leds, este caso, de la Ahambra. Se verá el contaje en binario de los leds. Si lo ves, es que te funciona.

Para hacer esta prueba, os adjunto un pinout del nRF24L01 y lo tengáis a mano para luego hacer las conexiones.

Es visto desde arriba.

Quien lo pruebe, por favor, que lo comente. Cualquier duda o lo que sea, aquí estoy. 

Cuando alguien trata de explicar un proyecto, puede pasar desapercibido cosas importantes que el que trata de explicarse en ese momento no lo tiene presente, por eso es importante que cualquier duda sobre conexiones, interpretaciones, dudas, etc, se haga saber.

Por último decir, que antes de hacer este proyecto que adjunto, probéis los transceptores desde Arduino, cualquier ejemplo sencillo, y una vez que te funcione, entonces pasar a este que propongo aquí con emisor Arduino y receptor con FPGA. Esto lo comento porque es importante familiarizarse con este tema primero con algo que está muy probado y que a tí también te funciona, y luego ya saltamos a otro nivel de abstracción (también sencillo pero de otra naturaleza).

No hagáis caso a los comentarios que hago en el programa de Arduino, son cosas que iba cambiando y luego no modifiqué el comentario. Con tiempo ya iré corrigiendo y explicando con detalle todo lo que ahí hay. Lo mismo para el diseño en FPGA, pero en este caso, apenas hay comentarios.

Saludos.

[Democrito]

Así es Jesús, y especialmente cuando le pedimos que trabajen a la máxima potencia. Quizás si configuramos los transceptores a la mínima potencia, quizás no haya tanto problema. Pero claro, a la mínima potencia sólo serviría para distancias cortas.

El registro que se encarga de esto es el 0x26, y tiene una doble función. En ese registro se configura la potencia y la frecuencia máxima (2MHz, 1MHz ó 250KHz).

Aunque ahí ponga 0x06, es en realidad 0x26.

Por si no lo has visto, te dejo con la documentación que hice en GitHub y múltiples ejemplos:

https://github.com/Democrito/repositorios/tree/master/radio/nRF24L01

Ahí cuento muchos detalles y aclaro confusiones que tuve en el camino (en este hilo).

Por otra parte hay que tener cuidado con estar usando los viejos nRF24L01 (sin el plus '+'), esos no pueden funcionar a 250KHz (y que cubren mayor distancia). Hay que asegurarse de que en el chip ponga nRF24L01+ con una lupa de joyería por ejemplo.

Saludos!

[Jesus Arias]

Hola,

En mi caso la potencia seleccionada no va a afectar porque el módulo receptor nunca transmite ya que tengo desactivados los paquetes de ACK, los reintentos, y demás parafernalia (modo compatibilidad con nRF24L01 sin el '+'), así que la única fuente de ruido es el que llega por la alimentación.

Esta el la hoja donde se describe este modo:

Y esta es una foto de las pruebas (no FPGAs, sorry ;) A esta distancia la comunicación fallaba hasta que soldé el condensador electrolítico (y una autoinducción por la cara de debajo) El transmisor (izquierda) todavía tiene la alimentación de la Raspberry.

[charli va]

Que buena pinta tienen esas placas , aunque no tengan FPGA XD

Yo creo que aquí caben hilos de cualquier tema de los que nos gustan :)

Yo probé el módulo de Demócrito y sobre todo los modulitos con antena de más dbs funcionaron muy bien a bastantes metros.

Gracias a los dos!

--
Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/fa2774d2-20e7-4049-a560-0b80aa8dfaebn%40googlegroups.com.

[Jesus Arias]

Estas placas son un demostrador que habíamos ideado para ilustrar las comunicaciones digitales y tienen un poco de todo:

- Comunicaciones serie por cable de par trenzado, tipo LVDS.

- Comunicaciones ópticas. En lugar de fibra óptica hemos preferido usar un puntero láser, que aunque haya que apuntarlo manualmente al fotodiodo del receptor es más visual.

- Comunicaciones por radio. Aquí es donde entra el módulo nRF24L01+, lo que más lata me ha dado.

La idea es poder digitalizar audio del micrófono de un  manos-libres, mandar los datos a otra placa, y reproducir el audio en los auriculares (lo que añade algo de procesamiento de señal: filtrado, diezmado, interpolación). Alternativamente también se puede digitalizar la fuerza en un sensor de galgas extensiométricas (con un HX711). El micrófono ha sido algo problemático pues captaba un pitidito que también se colaba desde la alimentación. (moraleja: cualquier cosa analógica es un dolor de muelas. No me extraña que todo se haya vuelto digital ;)

Y para terminar de complicar las cosas en lugar de la raspberry-pico se podría conectar una placa tipo arduino con un ESP-32, la STEAMaker de Innova Didactic, aunque de esa parte yo no pensaba desarrollar nada ;)

[charli va]

La verdad es que suena muy interesante , os lo tenéis que estar pasando de cine!

ya nos irás contando!

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/f568fcbb-2004-4781-8f4d-da670df585e3n%40googlegroups.com.