El sensor DHT21 / AM2301 no mide la humedad

Estoy tratando de usar un DHT21 con un Lamobo R1 , también conocido como Banana PI R1 para leer la temperatura y la humedad, con Armbian/Jessie y un kernel 4.5.2. Un Lamobo R1 es básicamente una placa A20 compatible con raspberry pi, con un bus raspberry pi 2 compatible invertido.

Lo configuré en GPIO5, pin raspberry compatible 24, WirinPi 5, pin físico 18, según una tabla aquí , más los pines GND y +5V.

Traté de leer la temperatura y la humedad con y sin la resistencia recomendada. Si bien la lectura de la temperatura es buena, y también está corroborada por un sensor DS18b20 conectado a GPIO2, la humedad siempre está al 99,9 %.

He instalado la biblioteca compatible con WiringPi del repositorio de WiringBP.

Sin embargo, al usar, por ejemplo , DHT21-AM2301 o lol_dht22 , siempre obtuve la salida de humedad como 99.9% o 99.90%.

Un módulo kernel personalizado para este chip, am2301 , simplemente cuelga la máquina.

Lo que he encontrado hasta ahora es:

  • Parece funcionar con Raspberry y Arduino;
  • El DHT21 es muy sensible a los tiempos, incluso en la frambuesa original;
  • Algunas personas informaron que solo funcionaba en GPIO1 y GPIO2 en la frambuesa original, mientras que los otros GPIO tenían una latencia mucho mayor;
  • Hay una configuración de hardware mucho más complicada para conectarlo a un I2C, en la que no estoy particularmente interesado;
  • Algunas personas también teorizan que solo funciona con el kernel 3;
  • El Lamobo R1 parece tener un bus pin pullup por defecto;
  • Las lecturas se pueden realizar solo cada segundo debido a las limitaciones del conjunto de chips;
  • La implementación física del bus R1 en comparación con el rpi me permite arreglármelas sin la resistencia;
  • El límite del cable parece ser de 25 m, y hay historias anecdóticas de personas que alcanzan los 60 m con cable UTP. El mío no mide más de 20 cm;
  • No puede exponerse a la luz solar directa debido a que mantiene el equilibrio químico;
  • Dicho equilibrio químico se degrada con el tiempo (¿2-3 años?).

¿Alguien tiene algo más que agregar?

Notas adicionales según comentarios:

  • La humedad viene primero que la temperatura;
  • Como @ChrisStratton teorizó correctamente, los bits de humedad son todos 1;
  • Ya probé dos sensores DHT21 con los mismos resultados.

la salida de

gpio readall

es

+----------+-Rev3-+------+--------+------+-------+  
| wiringPi | GPIO | Phys | Name   | Mode | Value |  
+----------+------+------+--------+------+-------+  
|      0   |  17  |  11  | GPIO 0 | IN   | Low   |  
|      1   |  18  |  12  | GPIO 1 | IN   | High  |  
|      2   |  27  |  13  | GPIO 2 | IN   | Low   |  
|      3   |  22  |  15  | GPIO 3 | IN   | Low   |  
|      4   |  23  |  16  | GPIO 4 | IN   | Low   |  
|      5   |  24  |  18  | GPIO 5 | OUT  | High  |  
|      6   |  25  |  22  | GPIO 6 | IN   | Low   |  
|      7   |   4  |   7  | GPIO 7 | IN   | Low   |  
|      8   |   2  |   3  | SDA    | ALT5 | High  |  
|      9   |   3  |   5  | SCL    | ALT5 | High  |  
|     10   |   8  |  24  | CE0    | IN   | Low   |  
|     11   |   7  |  26  | CE1    | IN   | Low   |  
|     12   |  10  |  19  | MOSI   | ALT5 | Low   |  
|     13   |   9  |  21  | MISO   | ALT5 | Low   |  
|     14   |  11  |  23  | SCLK   | ALT5 | Low   |  
|     15   |  14  |   8  | TxD    | ALT0 | Low   |  
|     16   |  15  |  10  | RxD    | ALT0 | Low   |  
|     17   |  28  |   3  | GPIO 8 | IN   | Low   |  
|     18   |  29  |   4  | GPIO 9 | ALT4 | Low   |  
|     19   |  30  |   5  | GPIO10 | OUT  | High  |  
|     20   |  31  |   6  | GPIO11 | ALT4 | Low   |  
+----------+------+------+--------+------+-------+  

r1foto

Intentar hacer bit-bang en un bus serie desde un software de aplicación bajo un sistema operativo multitarea puede ser difícil, ya que es difícil lograr una sincronización precisa. Por lo general, sería mejor delegar la tarea a un motor de hardware (como el bloque I2C, aunque este chip no es I2C nativo) o un controlador de modo kernel. La depuración del controlador del kernel podría ser un proyecto digno: obtenga printk y vea qué está sucediendo. También es posible que desee utilizar un alcance en la línea de datos. En muchos casos, un analizador lógico económico basado en cy7c68013 ayudará, pero esta señal podría tener problemas analógicos que necesitan un osciloscopio.
Si te desesperas y solo quieres resultados, podrías usar una MCU barata como delegado para leer el sensor y luego informar a la placa Linux integrada a través de UART, I2C, SPI, lo que sea; esto también te brinda un punto fácil de compatibilidad. para cambiar los sistemas a ambos lados de, un solo punto para cualquier conversión de voltaje necesaria, etc.
También puede intentar trabajar hacia atrás a través del código y ver qué tipo de patrón de bits sin procesar del sensor sería responsable de una supuesta humedad del 99%. Los patrones como todos unos o ceros son altamente sospechosos como problemas de comunicación.
@ChrisStratton De hecho, he seguido el código. Dato interesante, la humedad es lo primero y la temperatura lo último. Parece ser una situación de todos, de hecho. Estaré probando en los próximos días otro DHT21 para ver si por casualidad es un dispositivo roto o algún problema de tiempo. También conozco a Lamobo como bus pullup de forma predeterminada... tal vez una línea de código o alguna configuración. primero intentará con otro DHT21.

Respuestas (3)

Según la hoja de datos , los tiempos de DHT21 son más cortos con 3,3 V y más largos con 5 V. Lo cambié de 5V a 3.3V y ahora lee la humedad correctamente. Parece que mientras que en el Arduino lo tiene a 5V, el lado del software/rutinas para el banana pi y la frambuesa asumen que está conectado a 3.3V.

Del software mencionado en la pregunta, el más rápido parece ser lol_dht22. Estoy usando una versión ligeramente modificada (por mí mismo), que crea archivos en /var/run aproximadamente cada 9-10 segundos para alimentar rpimonitor .

temperatura

Como @ChrisStratton dice correctamente, este método de sondeo/sondeo de bits es muy propenso a errores, especialmente cuando se ejecuta en la tierra del usuario.

La suma de verificación de protocolo simple implementada por DHT21 claramente no es lo suficientemente fuerte como para eliminar la mayoría de los errores/picos (y hay muchos). Tuve que agregar rutinas de corrección de software simples para ignorar los valores fuera de lugar, e incluso entonces hay picos.

El código para leer los sensores DHT11/DHT21/DHT22 está en mi github https://github.com/ruyrybeyro/rdht .

grafico

También tenía dudas sobre si tendría que tocar la configuración del árbol de dispositivos R1, como hice para configurar el protocolo 1Wire con otro sensor de temperatura. No fue necesario.

Como nota adicional, se debe tener cuidado al seguir ciegamente los esquemas en línea. Mientras que el bus Arduino opera a +5V, raspberry y compatibles operan a +3V; aunque aparentemente no es el caso del DHT21 (resalto aparentemente porque el bus R1 es más resistente que el bus rpi), la alimentación aleatoria de dispositivos/sensores de +5 V conectados a un bus rpi puede ser potencialmente perjudicial para su SBC.

La(s) temperatura(s) medida(s) también parece(n) ser consistentemente más alta(s) +2 Celsius de lo que debería ser, y estas inconsistencias de temperatura son reportadas por muchos otros que usan dispositivos DHT21.

Me alegra saber que tuvo cierto éxito, sin embargo, en general, continuaría con la precaución de no tratar de hacer algo con requisitos de tiempo específicos del código de modo de usuario que está sujeto a retrasos variables detrás de escena. Corre el riesgo de un sistema que falla parte del tiempo, o uno que puede fallar sustancialmente cuando cambia algo aparentemente no relacionado; por ejemplo, podría no funcionar en una red con una gran cantidad de paquetes de transmisión que el kernel debe considerar.
@ChrisStratton Gracias por todas las ideas y por su tiempo.
posiblemente esta biblioteca también pueda ayudar: github.com/RobTillaart/DHTNEW especialmente con el bloqueo de ESP32

La lectura de humedad es del 99,9 % cuando alimenta el sensor con 5 V. Prueba a alimentarlo con 3,3V y funcionará. Probé un circuito con una MCU en 5V y solo cuando el AM2301 está en 3,3V, funciona como se esperaba.

Eso es lo que dice mi propia respuesta en el primer párrafo. Puede haber más, depende de las características del sensor, el equipo y cuánto se carga la CPU con este método de lectura.

Creo que el problema principal no es sobre el voltaje de la fuente de alimentación o cualquier resistencia adicional. El principal problema es el tiempo de retraso. los documentos dicen

  • El período de recolección debe ser: >1.7 segundos.

entonces, si agrega un tiempo de retraso de 5000 ms, mi problema se solucionó. He probado con dht21

Gracias, soy consciente del tiempo de espera entre consultas. Además de eso, los tiempos varían con el voltaje y algunas API están codificadas con tiempos fijos. Ese era uno de los problemas.