Bitácora - tomasdozo/TDPII-F3 GitHub Wiki

Lunes 22/8

  • Entrega de materiales:
    • 2 módulos nRF24L01+ PA/LNA
    • 2 adaptadores nRF24L01+
    • 2 Arduino UNO
    • 2 cables USB-A a USB-B

Domingo 28/8

  • Creación Plan de Proyecto
  • Se consideran necesarios para la realización del proyecto los siguientes elementos faltantes:
    • 2 placas de alimentación Mb102
    • 1 cable adaptador de batería 9V plug Dc.
    • 1 pila 9V
    • 1 fuente de alimentación 12V 700mA
    • 1 módulo de temperatura y humedad DHT22
    • 1 display LCD 1602A

Lunes 12/9

  • Evaluación del Plan de Proyecto
    • Utilizar fuentes de alimentación en ambas placas, en lugar de utilizar la pila en una de éstas
    • Descartar LCD para mostrar los datos y utilizar el monitor serial en su lugar
  • Luego de esta evaluación la lista de materiales faltantes quedaría asi:
    • 2 placas de alimentación
    • 2 fuentes de alimentación 12V 700mA
    • 1 módulo de temperatura y humedad DHT22

Martes 20/9

  • Pruebas iniciales:
    • Instalación del entorno de desarrollo Arduino IDE
    • Pruebas básicas de la placa Arduino UNO utilizando el monitor serial
    • Investigación de librería RF24
  • Actualización de la lista de materiales faltantes:
    • 2 placas de alimentación
    • 2 fuentes de alimentación 12V 700mA
    • 1 módulo de temperatura y humedad DHT22
    • múltiples cables para interconexiones de los dispositivos
    • 2 proto boards
  • Consideramos oportuno reconsiderar la utilización del display LCD para mostrar los datos y de esta forma poder independizarnos de la necesidad de una computadora

Jueves 22/9 (Prof. con permiso de acceso a partir de la fecha)

  • Sobre lo que registraron como

"Descartar LCD para mostrar los datos y utilizar el monitor serial en su lugar"

Sean cuidadosos en la lectura de la evaluación, y por las dudas confirmen/consulten personalmente lo que entienden de la evaluación. Más específicamente lo que les fue enviado es

"Por ahora descartamos el LCD y usaremos el monitor serie para el inicio de las pruebas del software y librerías. Pensando en una "estación base" como la que plantean en el Plan de Proyecto (que me parece factible sin problemas) lo más lógico sería recolectar los datos en la PC conectada al Arduino y luego procesar de la forma que sea. Les explico esto en clase para aclarar bien y luego lo vuelcan al proyecto."

Es decir: ni está descartado absolutamente el uso del LCD ni consultaron en clase al respecto, para que les pueda explicar en detalle y puedan repreguntar en caso de ser necesario. No explicaré por este medio sino que insisto en que conversemos en persona para no usar más tiempo ni retrasar el desarrollo por esto que en este momento del desarrollo es un detalle menor.

Esto también a corto plazo descarta lo que pusieron como

"Consideramos oportuno reconsiderar la utilización del display LCD para mostrar los datos y de esta forma poder independizarnos de la necesidad de una computadora"

  • Si Dios quiere para el lunes 26/9 les llevo los materiales para entregar en mano:
    • 1 placa de alimentación
    • 1 fuente de alimentación
    • (Recuérdenme que les explique en clase la idea de usar una sola placa-fuente para luego completar)
    • 1 módulo de temperatura y humedad DHT11 (https://components101.com/sensors/dht11-temperature-sensor)
    • cables para interconexiones de los dispositivos (posiblemente no tenga suficientes)

Al resto lo conversamos en clase.

Viernes 23/9 (Prof.)

  • Sobre la biblioteca/librería
    • Recuerden que se debe evitar la instalación en el IDE y debe quedar como parte del proyecto del IDE
    • Documentar la url de la cual la obtienen y la documentación usada para iniciar los experimentos (url del tutorial o video o ...)

Lunes 26/9

  • Entrega de materiales:
    • 1 placa de alimentación
    • 1 fuente de alimentación 12V 700mA
    • 1 módulo de temperatura y humedad DHT11
    • algunos cables para interconexiones de los dispositivos

Martes 4/10 (Prof.)

  • Recuerden que, tal como comentamos en clase, los avances/tareas realizadas deben volcarse en la bitácora para que el informe de avance (en particular, el informe de avance de octubre) sea un resumen técnico justificado que se derive de la bitácora y no sea un "documento ad hoc" de la entrega requerida.

Martes 4/10

Martes 11/10

  • Comunicación NRF:
    • Se llevó a cabo la comunicación de los Arduino mediante los módulos NRF
    • Se transmite la información obtenida del sensor en una de las placas a la otra

Lunes 17/10 (Prof.)

  • No se ha entregado el informe de avance de Octubre.
  • No hay código fuente disponible del proyecto.
  • Falta documentación específica:
    • Sobre la/las bibliotecas: no está claro mucho más que "RF24", recuerden que suelen haber muchos sitios, muchas versiones, pongan de manera explícita la URL desde la que obtienen las bibliotecas y dejen una copia de la biblioteca usada como parte de su proyecto en github. Les fue explicado que las bibliotecas/código suele cambiar de versiones y sin mantener compatibilidad con lo ya desarrollado.
    • Debe quedar explícita la versión usada en cada prueba, para poder verificar/experimentar de manera consistente de acuerdo a lo que documentan.
  • Recuerden que las fallas deben documentarse de manera específica, normalmente es dificil recordar cuál es la falla si no se pone qué se hizo y el resultado fallido (ej: mensaje de error o falta de respuesta de un determinado hardware).
  • Deben como mínimo indicar la interconexión/conexión esquemática de los módulos y el resultado de los experimentos/pruebas realizadas, asociados al código fuente/proyecto del IDE de Arduino utilizado.

Martes 25/10

  • Realización del informe de avance de octubre.
  • Correcciones y consideraciones luego de la evaluación del informe:
    • Descartado por completo el uso del LCD para mostrar la información en el receptor, se utilizará el monitor Serial para mostrar los datos recopilados.
    • No se utilizarán protoboards en el proyecto final, estas se utilizan provisoriamente durante en desarrollo para facilitar las conexiones.
    • El arduino será alimentado con 12V, no con 5V, desde la fuente provista.
    • Incorporar ejemplos en los que se basa el código escrito en el informe.
    • Reconsiderar la librería que se utiliza para el manejo del sesor DHT.
    • La comunicación mediante los NRF funciona solo con la incorporación de uno de los archivos de la libería RF24, 'RF24.h', 'nRF24L01.h' no es necesario.

Viernes 28/10

  • La utilización de la librería 'RF24' tiene múltiples dependencias que complicaron la inclusión de la misma dentro del proyecto, y no en el IDE, por lo que este punto aún no ha podido ser resuelto.
  • La librería utilizada para el manejo del DHT sí parece funcionar importada dentor del proyecto.

Lunes 31/10 (Prof.)

  • Informe de avance entregado y evaluado.
  • Falta documentar avances y resumen de pruebas en esta bitácora.
  • En clase definiremos tareas a realizar en el corto plazo.

Lunes 31/10

  • Se intentó probar el funcionamiento de los dispositivos en clase pero no se pudo llevar a cabo la comunicación.
  • Se pactó continuar realizando distintas pruebas ya que hasta este momento la comunicación había funcionado correctamente, como se puede ver en el video presentado.

Lunes 31/10 (Prof. explicado en clase)

image

  • Para el item 0), si necesitan cables, me avisan y se los puedo dar en mano si Dios quiere el miércoles 2/11 a las 17.
  • Para el item 3), crear una entrada en la bitácora con la URL de documentación de la función write utilizada y copiar las líneas de código que generan sucesivamente "Success"/"Error" para poder revisar a partir de esa información qué puede estar sucediendo.
  • Para cada experimento/prueba debe quedar el correspondiente video breve + el código completo de emisor y receptor. Esto es válido no solo para esta sucesión de pasos sino para lo que resta del desarrollo.

Miercoles 2/11 BLOQUEADOS

  • Se estuvo probando ambas placas solo con los transmisores
  • Se probo alimentandolas a traves del arduino y a traves de la fuente
  • Se rehizo el codigo a partir del codigo de ejemplo de la biblioteca
  • No se esta pudiendo hacer andar de vuelta los transmisores

Viernes 4/11 (Prof.)

  • En el repositorio está la misma versión de hace 14 días, entiendo que están usando otro código con el que están bloqueados. Por favor pongan una versión del código completa para el punto 1) de lo explicado en clase, es decir: transmisor y receptor sin nada del DHT. Para la secuencia de envío pueden dejar un delay de 1 segundo entre envíos y como dato a enviar solo un byte con un número de secuencia, para que el receptor pueda identificar qué recibió y qué no.
  • Por favor pongan también la referencia para documentar dónde obtuvieron la librería que están utilizando (ver comentario/pedido del 17/10).
  • Agreguen el o los sitios/páginas/tutoriales que utilizaron para empezar a trabajar.
  • Para todas las funciones que usen de la biblioteca: verifiquen cuáles retornan un código de error/funcionamiento y para todas ellas muestren el valor de retorno en el monitor serie, puede ser en términos de
    "<function> SUCCESS/FAILURE".
    En el código que actualmente está en el repositorio tienen (disculpas, no sé editar bien esta wiki...)
    if(radio.write(&text, sizeof(text))){
    //Serial.println("SUCCESS!");
    }
    else{
    //Serial.println("FAILURE!");
    }
    sería eso para cada función que tenga valor de retorno y sin comentar los "Serial.println.."

Viernes 4/11 (Prof.)

  • Buscando información de cómo interconectar los módulos encontré que las interconexiones no están detalladas en el informe sino en un .txt en una de las carpetas de uno de los .ino. Debería estar en el informe y para el repositorio de código es necesario que esa información o directamente se obtenga del informe o esté disponible para todos los .ino evitando que esté repetida, preferentemente.

Lunes 7/11 (Prof.)

  • Vi que pusieron otra página para bibliografía y no está mal, pero en cualquier caso mejor tener todo en la bitácora, para no tener que mirar múltiples páginas. Si quieren mantener esa y otras páginas, adelante, pero con copia en esta bitácora para tener un único lugar de referencia de toda la información para luego ser volcada al informe:
  • Tal como fue comentado, dejen una copia de las bibliotecas tal cual las bajaron de esas URLs para que luego los cambios en las mismas no afecten el funcionamiento del proyecto a futuro.
  • Vi que tienen una rama "basic_usage"... es necesario que documenten en esta bitácora si es el punto 1) de lo que conversamos en clase (imagen más arriba) o no, y si funciona o no. Si funciona, continuar con el resto de los puntos y con el proyecto en general. Si no funciona, el mensaje de error y/o el comportamiento erróneo que tienen.

Domingo 4/12

  • Se hicieron pruebas de campo con las placas, se realizaron mediciones a distintas distancias utilizando la potencia por defecto.
  • Resultados:
    • Las placas se comunican correctamente y los mensajes enviados por el transmisor son recibidos por el receptor cuando los dispositivos se encuentran en línea de visión y con las antenas apuntándose.
    • Hasta los 150 metros, los mensajes enviados eran recibidos casi en su totalidad por el receptor, a excepción de uno o dos mensajes (no más de dos mensajes contiguos) que se perdían en el camino.
    • A partir de los 200 metros ya se perdía una cantidad considerable de mensajes como para considerar una comunicación defectuosa.
  • Luego serán subidos los videos de dichas pruebas y adjuntado el enlace en esta bitácora.

Martes 6/12

  • Se corrigió el código existente en el repositorio, teniendo actualmente tres ramas actualizadas y funcionando:
    • nrf_simple_communication: Código que cuenta únicamente con lo necesario para la comunicación básica de los módulos NRF. Presenta varios comentarios por parte de ambos componentes en el monitor Serial a modo de monitoreo.
    • dht_nrf_communication: Código que cuenta con todo lo necesario para la comunicación de los módulos NRF, la lectura de la temperatura y la humedad por parte del transmisor y el envío de estos datos al receptor. Presenta varios comentarios por parte de ambos componentes en el monitor Serial a modo de monitoreo.
    • main: Código listo para producción, considerando el receptor conectado a una computadora y observando los mensajes en el monitor serial, y el transmisor conectado a una pila y sin posibilidad de imprimir en el monitor serial.
  • Todas las ramas mencionadas presentan la librería necesaria para el manejo de los módulos NRF incorporada dentro del proyecto, las dos últimas consideran que la/s librerías necesarias para el manejo del sensor DHT se encuentran incluidas en el IDE. Esto aún está sujeto a cambios si podemos incorporarla/s también en el proyecto al igual que la del NRF.

Videos pruebas de distancia

Videos

Martes 6/12 actualización

  • Se agregó una nueva rama change_dht11_library donde se modificó la biblioteca utilizada para la lectura de los datos del sensor DHT11. En ésta, se utiliza la biblioteca dht11 utilizada en los ejemplos provistos en la corrección por parte del profesor.
  • Al ser una biblioteca más simple, ya que cuenta solo con un archivo de código fuente y uno de cabecera, permite su incorporación dentro del proyecto, descartando la necesidad de incorporar las bibliotecas dentro del IDE como se hacía anteriormente con la de Adafruit.
  • Próximamente, este cambio será incorporado a la rama principal main.

Miércoles 7/12

  • Se actualizó la rama main para utilizar la nueva biblioteca mencionada anteriormente para el manejo del sensor DHT11.

Viernes 16/12

  • Se agregó una rama nrf_power donde se configura el nivel de potencia deseado para el transmisor.
    • Los niveles de potencia disponibles son:
      • RF24_PA_MIN: -18dBm
      • RF24_PA_LOW: -12dBm
      • RF24_PA_HIGH: -6dBM
      • RF24_PA_MAX: 0dBm
    • El nivel de potencia se setea mediante el monitor Serial, si no se ingresa ningún valor luego de un tiempo o se ingresa un valor érroneo, se utiliza la potencia por defecto que es la máxima RF24_PA_MAX (0dBm).
    • Principalmente se consultó la información disponible en la misma biblioteca RF24, pero también se consultó en foros de arduino que desarrollan esta funcionalidad más en profundidad, y en particular un ejemplo disponible en esta misma biblioteca: Getting Started.
⚠️ **GitHub.com Fallback** ⚠️