09) Le domaine de la télémesure.

Domaine qui dans le cas d’utilisation d’une ligne Bluetooth dont la portée reste volontairement limitée reste d’une pertinence restreinte. En général il se limitera en télémesures à envoyer des paramètres importants mesurés sur un petit mobile robotisé et télécommandé par radio. Il est
donc peu probable que la NASA piratera ce didacticiel pour surveiller leur prochain rover envoyé sur Mars ! Pour expérimenter cette facette de la télécommunication, il faut modifier les deux logiciels et on utilisera P11_Esclave_F.ino et P12_Maitre_F.ino. Il nous reste à choisir quels seront les paramètres mesurés et avec quel capteur à installer sur l’unité de P11.

Capteur Température / Humidité DHT11.

Compte tenu de la variété considérable de capteurs en tous genres proposés dans le commerce en ligne, mon choix c’est porté sur le très populaire capteur DHT11 montré sur la Fig.32 constitué d’un senseur de température à base d’une thermistance à coefficient négatif de température et d’un capteur d’humidité résistif. Un microcontrôleur intégré s’occupe de faire les mesures, de les convertir pour les transmettre. Chaque module est calibré en usine et ses paramètres de calibration sont stockés dans la mémoire ROM du microcontrôleur local. Le DHT11
dialogue par une ligne série de type OneWire.

Caractéristiques techniques du capteur :

La Fig.31 donne le brochage du composant ainsi que celui du petit module en circuit imprimé. La Fig.32 indique comment établir la liaison avec une carte ARDUINO. La mise en oeuvre est facile car la bibliothèque DHT11.h est disponible dans <BIBLIOTHEQUES>. Elle se charge des protocoles de dialogue de type série. La ligne filaire peut faire jusqu’à 20 m de longueur entre le capteur et l’U.C. de traitement utilisée, dans ce cas il faut diminuer la valeur de R à 4,7kΩ. Le format des données série est de 40 bits.

DIALOGUE sur la ligne DATA.

Lorsque le P.C. envoie un signal de démarrage, le DHT11 passe du mode faible consommation électrique au fonctionnement en mode dialogue et envoie l’accusé de réception suivi des données.  Il repasse ensuite en mode veille jusqu’à la prochaine sollicitation.
1) Demander une mesure : Forcer l’état « 0 » durant 18 mS puis état « 1 » durant 40 μS.
2) Accusé de réception du DHT11 : Forcer l’état « 0 » durant 54 μS puis état « 1 » durant 80 μS.
3) Lecture des données : Les données suivent l’accusé de réception et sont codées dans une série de 40 bits sous forme de cinq valeurs de 8 bits chacune dont voici le format :

* En bleu clair l’état zéro forcé par le P.C. ou en réponse par le DHT11.
* En rose pâle l’état « 1 » maintenu par la résistance de forçage R. (Pull Up)
* En bleu épais la requête du P.C. et en violet fin la réponse du capteur.
Exemple de programme :
Le programme P10_Test_du_capteur.ino très détaillé exploite la bibliothèque DHT11.h et liste sur la ligne série (Boucle infinie » 2 secondes) le résultat des mesures par utilisation de la broche d’E/S binaire D5. Les caractéristiques du module sont données dans DHT11.pdf rangé comme les autres documents dans le dossier <BIBLIOTHEQUE>. La Fig.34 est une copie d’écran qui montre globalement ce que l’on obtient dans la fenêtre contextuelle du Moniteur de l’IDE initialisé à 57600baud. Comme dans tous mes démonstrateurs, dans la zone jaune le logiciel se présente sommairement. Puis dans la zone rose sont affichés dans une boucle infinie les trois paramètres mesurés. S’il s’agissait d’un petit robot mobile téléguidé, on mesurerait certainement la tension des accumulateurs de sa propulsion. Dans notre expérience simple, on se contente de mesurer la tension du +Vcc d’Arduino. Et puis suivent les deux valeurs typiques fournies par le DHT11. Il reste toutefois à envisager le cas des lectrices et des lecteurs qui ne disposent pas de tels capteurs et qui ne désirent pas en approvisionner. Peu importe, vous pourrez effectuer l’expérience sans la présence de ce dernier. Le logiciel traite ce cas et retourne l’information des deux exemples situés dans le zone verte. Ainsi tout le monde pourra participer.

Le démonstrateur P11_Esclave_F.ino.

Contrairement au programme Maître, il fonctionne à la cadence maximale possible. Bien que ce soit uniquement pour le plaisir d’aborder ici la gestion précise du temps, le programme Maître sera chargé de cadencer les cycles de mesurages à exactement une seconde d’intervalle entre chaque groupe de données. Pour que l’on puisse facilement établir la connexion, puis procéder aux échanges des données, le démonstrateur est agencé comme présenté sur la Fig.35 où l’on peut constater que chaque groupe de mesures procèdera par systématiquement trois alternats même si sur le démonstrateur le capteur DHT11 n’est pas présent. On remarque en particulier plusieurs fois la présence du caractère ‘@‘. Il signifie qu’avant d’envoyer l’ACcusé de Réception, on réalise un délai de 20mS. En effet, par principe l’Esclave est en attente d’une consigne. Dès que cette dernière arrive, il réalise le plus rapidement possible l’action prévue. Mais avant de répondre au maître, il faut systématiquement attendre durant un délai à déterminer, pour être certain que le Maître a eu le temps de repasser en écoute. Comme les UART sont en duplex, il serait probablement possible de s’en passer, Mais personnellement je trouve plus prudent de toujours attendre un peu. La valeur choisie est de 20mS et définie dans une directive en tête de programme. Pour ma part, dans tous mes logiciels on trouve des directives qui doivent pouvoir être changées facilement en cours de développement. C’est la raison pour laquelle elles sont en tête du logiciel et facilement repérables par une remarque du type //@@@@@@@@@@@@@@@@@@@@@@@@.
La première action que fait le programme, c’est de se placer à l’écoute du Maître pour attendre une consigne Bluetooth. Son analyseur syntaxique est réduit à la plus simple expression. Il se contente en 1 de vérifier que le premier caractère de la chaîne reçue est un ‘S‘. Tant que ce n’est pas le cas il repassera immédiatement à l’écoute. Dès que ce caractère sera reconnu, il préviendra le Maître en 2 qu’il passe en mode mesurages. Puis immédiatement repasse en écoute en 3 pour attendre que le Maître lui donne l’ordre de procéder à un groupe de mesures. Dès qu’un texte est reçu, comme on a choisi de n’envoyer que la lettre ‘X‘ pour écourter les durées de communication, sans se préoccuper du contenu de l’ordre le programme procède en 4 aux diverses mesures. Puis, chaque groupe de données va se traiter par trois alternats. Dans tous les cas, le premier en 5 consiste à envoyer la valeur de la tension, et comme à chaque transmission, passer à l’écoute en 6. C’est à ce stade que deux cas sont possibles. Soit en 7 le capteur est en place. Alors en 8 c’est la valeur de la Température qui est transmise et nouveau passage à l’écoute en 9. Puis envoie de l’Hygrométrie en 10 et retour à l’écoute en 3 pour débuter un nouveau cycle. Si en 7 le capteur DHT11 n’est pas installé, le mesurage retourne une Erreur égale à 1. Du coup en A on prévient par un ACR Erreur et attente en B de la consigne pour envoyer la dernière donnée. C’est en C que l’on réitère Erreur pour reprendre le prochain cycle en 3.

Le démonstrateur P12_Maitre_F.ino.

Vous avez parfaitement compris que tout le monde pourra se prêter à cette expérimentation avec le minimum d’investissement en matériel. Si vous ne possédez ni le capteur DHT11 ni l’écran OLED, le programme fonctionnera en télémesures et ne transmettra que la valeur du +Vcc d’Arduino. Du reste vous avez la trame. Donc vous pouvez utiliser d’autres capteurs et remplacer les routines de mesurage par vos procédures. (Et éventuellement adapter les affichages.)

Dans la mesure où l’afficheur est de type graphique, il m’a semblé incontournable d’exploiter cette caractéristique. C’est la raison pour laquelle, pour « faire joujou » on va, en bas du cadre affiché, émuler une représentation analogique de l’hygrométrie, la valeur pouvant se représenter entre zéro et cent pour cent. Il est évident que sur une application réelle, c’est le paramètre le plus critique qui serait représenté sous cette forme. Quand le Maître est mis sous tension, il attend un ACR = « OK » arrivant de l’Esclave quand il lui envoie la lettre ‘S‘. Tant que le dialogue n’est pas établi, OLED affiche la page de la Fig.36 pour attester de cet état sans que l’on soit forcément raccordé à un ordinateur pour utiliser le Moniteur de l’IDE. Puis, le dialogue étant établi, c’est l’écran de la Fig.37 qui sera affiché, alors que si le capteur DHT11 n’est pas branché, la page de la Fig.38 nous en avertira. On remarque sur cette dernière que s’il y a erreur, le ruban analogique n’est pas affiché.ous avez parfaitement compris que tout le monde pourra se prêter à cette expérimentation avec le minimum d’investissement en matériel. Si vous ne possédez ni le capteur DHT11 ni l’écran OLED, le programme fonctionnera en télémesures et ne transmettra que la valeur du +Vcc d’Arduino. Du reste vous avez la trame. Donc vous pouvez utiliser d’autres capteurs et remplacer les routines de mesurage par vos procédures. (Et éventuellement adapter les affichages.)
ans la mesure où l’afficheur est de type graphique, il m’a semblé incontournable d’exploiter cette caractéristique. C’est la raison pour laquelle, pour « faire joujou » on va, en bas du cadre affiché, émuler une représentation analogique de l’hygrométrie, la valeur pouvant se représenter entre zéro et cent pour cent. Il est évident que sur une application réelle, c’est le paramètre le plus critique qui serait représenté sous cette forme. Quand le Maître est mis sous tension, il attend un ACR = « OK » arrivant de l’Esclave quand il lui envoie la lettre ‘S’. Tant que le dialogue n’est pas établi, OLED affiche la page de la Fig.36 pour attester de cet état sans que l’on soit forcément raccordé à un ordinateur pour utiliser le Moniteur de l’IDE. Puis, le dialogue étant établi, c’est l’écran de la Fig.37 qui sera affiché, alors que si le capteur DHT11 n’est pas branché, la page de la Fig.38 nous en avertira. On remarque sur cette dernière que s’il y a erreur, le ruban analogique n’est pas affiché.

Bien qu’en observation de la page écran de la Fig.37 nous lisions du texte, dans la pratique ce dernier est constitué d’une chaîne de caractères. Chaque lettre chiffre ou ponctuation est construit graphiquement en allumant ou en éteignant des PIXELs, Pour faciliter le travail des programmeurs, la bibliothèque <U8glib> est disponible avec une kyrielle de polices de caractères de tailles différentes. Dans nos démonstrateurs c’est u8g.setFont(u8g_font_6x10) qui est installée. Les caractères sont inscrits dans des matrices de 5 colonnes par 7 lignes soit 35 PIXELs. C’est une taille suffisamment grande pour rester esthétique, et suffisamment petite pour pouvoir afficher un grand nombre de caractères sur un écran. Un petit problème se pose : Les accentués. Il est possible qu’ils existent, pour le savoir il serait facile d’écrire un programme qui teste les 255 possibilités d’un char. Toutefois ce n’est pas du tout l’approche privilégiée, car elle oblige à afficher le texte en trois instructions. Au final ce n’est pas rentable. La technique utilisée ici consiste à ajouter au ‘e‘ deux PIXELs pour former l’accent. Cette façon de procéder n’est rentable que si le texte est fixe à l’écran pour ne pas avoir à changer les coordonnées des points lumineux.

Même problème pour le petit cercle de « °C« . Il serait possible de faire tracer un cercle de rayon deux PIXELs. Mais cette technique n’est pas du tout rentable, car il faut faire appel aux procédures de tracé de cercles qui sont gloutonnes en octets de programme. Aussi, c’est encore en allumant quatre mosaïques que l’on contourne la difficulté. Comme on peut l’observer sur la Fig.39 le nombre de groupe de mesures effectué est représenté avec sept chiffres significatifs sans déborder du cadre. Déjà pour atteindre la valeur de la Fig.39 l’appareil a fonctionné 24 heures sur 24 durant un peu plus de quinze jours … sans coupure secteur ! Durant ce test de fiabilité je me suis contenté de passer l’afficheur en veille pour économiser son écran. La broche D8 était utilisée en entrée binaire pour tester un bouton poussoir. Elle fonctionnait en bascule OUI/NON pouvant réveiller ou rendormir OLED à ma guise. Les deux unités étaient en autonome sur petits adaptateurs Secteur/USB. L’expérience à prouvé que lorsque le dialogue est synchronisé, la liaison est d’une très grande fiabilité. Si vous désirez pousser le bouchon encore plus loin, comme le plus grand nombre sans débordement sur le cadre correspond à 9999999 secondes, il vous faudra patienter durant 9999999 / 3600 / 24 soit 115,7 jours. Personnellement je n’ai pas la patience …

Subtilité de programmation.

S‘il est un domaine de la programmation dans lequel j’éprouve très souvent de réelles difficultés, c’est celui du format de représentation des nombres. Bien entendu, il existe les fonctions de conversion de chaîne de caractères en nombre pouvant servir à des calculs. Par exemple on peut se servir des instructions atoi, atof etc. Mais elles s’appliquent sur des chaines de caractères. Hors dans notre cas, la température ou l’hygrométrie sont reçus dans des tableaux de char. Hors pour pouvoir tracer analogiquement la valeur de l’hygrométrie, il faut en disposer sous la forme d’un byte compris entre 0 et 100. La fonction atoi ne s’applique que sur les chaînes de caractères, pas sur les tableaux de caractères ASCII. Bref, il faut se débrouiller pour assurer la transposition. Dans P12 on trouve Valeur_H = ((byte(Hygrometrie[0])-48) * 10) + (byte(Hygrometrie[1])-48) qui risque fort de vous laisser perplexe. Il me semble donc judicieux de la décortiquer. On va raisonner sur l’exemple de la Fig.39 pour avoir deux chiffres significatifs en hygrométrie. Considérons en Fig.40 le contenu actuel du tableau qui en réception des mesures sert à mémoriser la valeur de l’hygrométrie en vue de son traitement. C’est un tableau de char, donc chaque cellule contient un caractère codé en ASCII. En violet on retrouve les deux chiffres ‘6‘ et ‘4‘. En gris clair un résidu de l’ACR Erreur qui a été réceptionné à un moment de l’expérience. Dans la pratique ce tableau n’est jamais effacé. On se contente d’y mémoriser les textes reçus dans l’ACR relatif à l’hygrométrie, c’est à dire la dernière valeur transmise pour le groupe. Attention, en regardant ce tableau, instinctivement on va penser à la valeur 64. Mais le ‘6‘ et le ‘4‘ ne sont pas des nombres, ce sont des chiffres. C’est une différence fondamentale que l’on a facilement tendance à oublier. Hors un chiffre n’est qu’un caractère d’imprimerie. On le différencie de la ponctuation ou des lettres par de nom de chiffre. Hors on ne peut pas faire des calculs avec des caractères d’imprimerie. Par exemple ‘A‘ + ‘B‘ n’a pas de sens. Donc, si on confond les deux, pas le langage C qui ne code pas du tout les caractères et les nombre de la même façon. Donc si vous tentez Valeur_H = ‘6‘ + ‘4‘ le compilateur ne l’acceptera pas.

La suite est ICI.