DHT11 et picaxes
Les DHT11 sont des capteurs d'humidité et de température. Ils équipent, entre autres, certains modules Arduino.
Ils utilisent une liaison "One Wire", mais le protocole MaxDetect est totalement différent et incompatible avec le protocole "Dallas" des commandes OWin et Owout des Picaxes.
Téléchargement datasheet DHT11
Les données sont donc constituées de "bits" de longueurs variables de 27µs pour un "0" et de 70µs pour un "1", espacés par des intervals de 50µs.
On lit ceci dans la datasheet:
Data consists of decimal and integral parts. A complete data transmission is
40bit, and the sensor sends higher data bit first.
Data format:
8bit integral RH data + 8bit decimal RH data + 8bit integral T data + 8bit decimal T data + 8bit check sum. If the data transmission is right, the check-sum should be the last 8bit of "8bit integral RH data + 8bit decimal RH data + 8bit integral T data + 8bit decimal T data".
La datasheet du grand frère, le DHT22 (RHT03) est un peu plus précise:
Téléchargement datasheet DHT22:
On peut lire la même phrase, mais il y a un exemple:
Example: MCU has received 40 bits data from RHT03 as
0000 0010 1000 1100 0000 0001 0101 1111 1110 1110
16 bits RH data 16 bits T data check sum
Check sum=0000 0010+1000 1100+0000 0001+0101 1111=1110 1110
RH= (0000 0010 1000 1100)/10=65.2%RH
T=(0000 0001 0101 1111)/10=35.1
When highest bit of temperature is 1, it means the temperature is below 0 degree Celsius.
Example:
1000 0000 0110 0101, T= minus 10.1
16 bits T data
en résumé:
Les 16 premiers bits représentent la valeur de l'humidité exprimée en dizièmes:
%0000 0010 1000 1100= 652
652 /10 = 65,2 % d'humidité relative
Les 16 suivants la température en dizième de °C avec "1" en tête si cette valeur est négative.
Reste à lire et différencier ces données avec un picaxe.
Les picaxes sont simples à programmer et à utiliser, le revers de la médaille est une exécution beaucoup plus lente que l'assembleur des pics d'origine.
syntaxe utilisée:
ptr=60
pulsin C.1 , 1 ,@ptrinc
(32 lignes identiques)
pulsin C.1 , 1 ,@ptrinc
Les mesures lues sont stockées en mémoires pointées par l'indexe ptr. L'incrémentation est automatique.
En attendant les capteurs, il faut aussi se bricoler un générateur de séquence de 32 bits identiques à celles du DHT11 (la séquence est limitée aux 32 bits de données).
Un 555 en astable génère des créneaux de longueur variable, de 5 à 70µs.
Ce générateur est bloqué ou débloqué par un monostable, le temps necessaire à la production de 32 bits de même longueur, 25 ou 70 µs. Une impulsion de départ est aussi envoyée au programme de lecture pour synchronisation. |  |
Essai avec un picaxe 20X2 à 64MHz.
On envoie un beau train de 32 bits, courts ou longs dans une suite de 32 pulsin, on lit ensuite les valeurs des longueurs enregistrées et on s'apperçoit assez vite que cela ne fonctionne pas.
En effet, seules les 16 premières mémoires ont enregistré une valeur, les 16 autres sont vides. Les pulsin n'ont pas eu le temps d'enregistrer deux bits successifs mais seulement un sur deux.
L'interval de 50µs est trop court.
Avec le générateur, il suffit d'allonger ce temps à 60 µs pour que les 32 bits soient lus normalement.
Une solution est de modifier les impulsions générées par le DHT11 en allongeant l'interval au détriment des niveaux hauts au moyen d'un monostable de 65µs, déclenché par les fronts descendants.
Après le passage par le monostable (ne555), le signal est inversé, le plus simple est de paramètrer pulsin pour lui faire mesurer les niveaux bas.
Il faut aussi activer le DHT11 par un signal start, niveau bas d'au moins 18ms.
Ce qui est fait par un pulsout sur un autre port, à travers une diode 1n4148.
A la réception des DHT11, un premier décodage basé sur l'exemple du DHT22 ne donne pas de résultats cohérents.
L'explication vient en visualisant le signal envoyé par le capteur .
Ce signal est en rouge sur ce diagramme, on reconnait la fin du signal start envoyé par le 20X2, le premier créneau de 80µs du DHT11 ensuite, un premier octet de données lisible facilement:
00111011 = 59 :c'est la valeur de l'humidité relative.
Le second octet est composé de 8 "0"
Le troisième donne 22, la température
Le quatrième :de nouveau, 8 "0"
Le cinquième est bien la somme du premier et du troisième.
En relisant la doc, c'est logique. Les résolutions du DHT11 sont de 1°C pour la température et 1% pour le taux d'humidité. Il n'y a donc pas de partie décimale.
Ces données en rouge ne sont pas lisibles par le 20X2.
En bleu, les modifications apportées par le monostable à 65µs.
Une petite adaptation du décodage.
Résultat : enfin quelque chose de cohérent !
Le schéma du circuit utilisé pour cet essai:
.
Le programme associé est en téléchargement ICI
Le même avec un check sum en plus et des erreurs en moins ICI
