Contexte : Vous avez le privilège de posséder une véranda dans laquelle vous mangez la plus grande partie de l’été, et vous y confiez toutes vos belles plantes que vous entrez pour l’hiver. Comme vous habitez une région très chaude et sèche l’été, beaucoup sont des plantes grâces qui par nature détestent le gel hivernal. Un radiateur thermostaté est installé pour que la température ne descende jamais en dessous de +2°C. C’est automatique, et nous savons qu’une panne technique peut toujours survenir. Vous décidez que l’ENREGISTREUR va être promu au grade très envié de sentinelle. Installé avec les plantes, il vous alertera ou interviendra directement si la température descend en dessous de +5°C par exemple. Par ailleurs, autant bénéficier de la visualisation du petit afficheur graphique pour pouvoir consulter l’historique des dernières 24 heures écoulées, ou d’une période plus importante à votre convenance.
Mesurer des températures.
Autant mesurer la valeur de la CTN est aisé avec ARDUINO, autant la convertir en température relève d’un calcul plus délicat. La thermistance n’a pas un comportement linéaire et il importe dans la conversion d’utiliser une fonction de type logarithmique. C’est du reste la raison pour laquelle, le titre du chapitre Observer des températures utilise le mot » Observer » et non « Mesurer« .
Passer de la simple visualisation comme effectué dans l’expérience précédente à une mesure précise exprimant le résultat en degrés Celsius est une autre paire de manches. En termes de complexité logicielle on change d’échelle.
La Fig.111 illustre le propos selon lequel on trouvait dans le commerce une foule de petits modules qu’il suffit de brancher directement sur une carte Arduino pour développer de petites applications, voir des projets très élaborés.
Certains de ces petits circuits sont élémentaires et ne comportent que quelques composants. On peut citer celui en 1 qui supporte une LED tricolore avec trois résistances de limitation de courant. En 2 on retrouve la thermistance CTN avec sa résistance de polarisation. D’autres sont bien plus sophistiqués et intègrent dans leur boitier une intelligence embarquée, dont le processeur parfois très complexe dialogue avec le monde extérieur via une ligne de type I2C. C’est le cas pour 3 que nous allons utiliser pour mesurer des températures, et 4 qui résout à notre place la réelle difficulté de mesurer l’humidité de l’air ambiant. Vu le coût raisonnable de ce type de produit avec traitement numérique complexe intégré, tels que le circuit Dallas DS-18B20 situé en 3, il devient peu rentable de s’engager dans des programmes compliqués que l’on aura bien du mal à finaliser.
Fabriqué par Dallas Semiconductor, ce composant complexe utilise pour dialoguer avec un microcontrôleur, un bus nommé OneWire. OneWire est un bus conçu par Dallas Semiconductor qui permet de connecter en série, en parallèle ou en étoile des modules avec seulement deux fils : Un fil de données de type « collecteurs ouverts » et un fil de masse. (Voir la Fig.112) Similaire à I²C, il présente cependant des vitesses de transmission et un coût inférieurs. Il est généralement utilisé en domotique pour toute une famille d’applications, et notamment servir d’instruments de mesures météorologiques. Pour dialoguer avec les modules utilisant le bus OneWire, Dallas Semiconductor met à la disposition d’ARDUINO une bibliothèque spécifique nommée <OneWire.h> qu’il faut importer dans l’environnement de développement. Il faudra donc la rapatrier depuis Internet sur votre ordinateur, puis la déclarer dans les bibliothèques disponibles. Cette phase d’utilisation d’une librairie tierce a déjà été rencontrée durant les didacticiels, toutefois pour vous faciliter les choses elle est explicitée dans le prochain chapitre.
Caractéristiques du capteur de température de DALLAS :
La documentation complète avec les protocoles de dialogue est bien entendu téléchargeable en ligne, on va se contenter dans ce chapitre à ne lister que celles dont on a besoin pour utiliser le petit module dont la Fig.112 explicite les branchements à effectuer et la Fig.113 précise le brochage du circuit intégré spécialisé qui ne comporte que trois broches. La résistance qui force le niveau haut sur la ligne est présente sur le petit module. On y trouve également une petite LED rouge qui s’illumine à chaque fois que la ligne de dialogue est sollicitée témoignant ainsi du fonctionnement.
• Interface OneWire® avec une seule broche pour le port de communication.
• Chaque composant dispose d’un code d’identification de 64 bits stocké dans la ROM de la « puce électronique ».
• Pas besoin de composants externes mis à part R.
• Source de courant comprise entre 3Vcc et 5.5Vcc.
• Mesures des températures comprises entre -55 °C et +125 °C.
• Précision ± 0,5°C entre -10 °C à +85 °C.
• Résolution définie par l’utilisateur entre 9 et 12 bits.
• Temps de conversion 750mS maximum pour 12 bits.
Mise en œuvre du circuit DALLAS DS-18B20.
Avec seulement trois broches à brancher sur le petit connecteur HE14, les initiatives pour l’électronicien sont réduites à peau de chagrin, et ce d’autant plus que deux d’entre elles sont dédiées au +Vcc et à GND. Vu que le circuit accepte entre 3Vcc et 5,5Vcc, alimenter avec les ressources de PICOSYNTHÉ ne va pas nous donner la migraine. Quand à la troisième broche, elle doit convoler avec une Entrée/Sortie binaire, et en F.E. il n’est reste qu’une seule. Alors la relier à D12 coule de source. Il reste maintenant à « décortiquer » les contraintes logicielles. Le programme démonstrateur extrait du logiciel complet P36 pour ne contenir que les variables et les subroutines du noyau est nommé P37_Mesure_des_temperatures.ino faisant preuve une fois encore de beaucoup d’originalité. Pas de menu, pour gagner du temps il s’ouvre directement sur la fonction ENREGISTREUR avec un délai entre deux échantillonnages provisoirement réduit à une seconde. On voit ainsi rapidement évoluer les informations sur le petit écran OLED. La première contrainte réside dans la déclaration : #include <OneWire.h>
Commencer par télécharger cette bibliothèque dont une description en Français est téléchargeable ici.
Puis, cliquer sur l’onglet Croquis suivi de Importer bibliothèque .... Pour toute bibliothèque tierce ne faisant pas partie des librairies par défaut de l’IDE, on complète par Ajouter bibliothèque ... et on indique enfin le chemin qui sur le disque dur de votre ordinateur conduit au dossier dédié.
Ce n’est qu’une déclaration, une adresse. Vous pouvez compiler le programme, s’il ne fait appel à aucune des procédures d'<OneWire.h> sa taille n’augmentera pas d’un seul kopeck. Pour se faire une idée comptable, au fur et à mesure du développement de P37_Mesure_des_temperatures.ino un bilan était effectué lors des compilations. À la première séquence d’instructions mettant en cause l’instance du DS-18B20, la taille a enflé brusquement de plus d’un kilo-octet. Rien de bien neuf dans ce constat, nous savons que le compilateur importe l’intégralité d’une bibliothèque dès l’appel à l’une quelconque de ses procédures, y compris si toutes les autres demeureront inutilisées. C’est un peu du gaspillage, et surtout le prix à payer pour économiser les heures de développement par paquets de dix.
Première évolution du logiciel initial : Avant de couvrir l’écran de l’enregistrement par défaut, le programme demande si l’on configure en station météo. C’est la LED jaune du bas qui clignote, incitant à répondre non, vous épargnant un RESET. En effet, si un capteur de type DS-18B20 n’est pas correctement branché, un BIP BIP BIP particulièrement pénible va piailler indéfiniment … sauf si réalisant cet oubli vous connectez correctement le capteur idoine. Un texte confirme sa détection, avec attente d’une touche pour ouvrir la fonction d’enregistrement. (Pour confirmer vous pouvez cliquer sur l’un quelconque des deux boutons poussoir du clavier.) Si vous avez opté pour la station météo, les deux lettres A et B repérant les deux voies sont remplacées respectivement par T pour la température et % qui dans le démonstrateur sert à afficher la valeur numérique mémorisée dans la RAM.
Quelques détails et choix logiciels.
Seules les fonctions de base de la bibliothèque seront invoquées. Il ne s’agit pas dans ces lignes d’une thèse exhaustive sur le DS-18B20, au contraire. Nous allons au plus court débroussailler le terrain pour vous démontrer à quel point trois fils sont suffisant pour élargir substantiellement les possibilités de PICOSYNTHÉ. (Trois fils et du logiciel ça va sans dire !) Notre petite centrale météo n’est pas un thermomètre, peu importe les températures négatives 
puisqu’elles sont hors de question dans le contexte envisagé. Par ailleurs, la déviation verticale de l’enregistreur est « graduée » fondamentalement entre 0 et 5. Aussi, dans ce contexte particulier, pour minimiser la taille du code, on impose verticalement une plage de températures allant de zéro à +50°C et l’on oublie les valeurs négatives. Le croquis sera ainsi simplifié, critère incontournable pour éventuellement le loger dans le programme complet « définitif ».
Fastidieuse à n’en pas douter serait la description ligne à ligne des instructions relatives au composant DS-18B20. Dans la procédure void Traitement_specifique_voie_A() sont rassemblées toutes les lignes relatives à l’exploitation du capteur de température. Copieusement agrémentées de commentaires, vous n’aurez je crois aucune difficulté à établir le lien avec les instructions données dans les notices d’application. Seules deux ou trois instructions particulières seront mentionnées dans ce chapitre :
Dialoguant par conception avec une Entrée/Sortie binaire du microcontrôleur, la ligne « OneWire » se doit d’être connectée à la seule broche de cette nature qui reste disponible sur PICOSYNTHÉ. Il tombe sous le sens que Entrée / Sortie logique du petit circuit imprimé sera pontée sur D12 disponible en F.E. C’est exactement ce qui était fait en (1) cette ligne ayant ensuite été changée en remarque. Le programme exploitant D12 fonctionne sans problème. Cependant, nous avons ainsi consommé la seule broche binaire restant disponible. Envisageant le futur, si un autre module de type I2C ou OneWire était mis en service, nous n’aurions plus d’E/S binaire disponible. (On va anticiper.)
– Mais si gros malin, les broches Analogiques sont également binaires, il t’en reste deux !
– OUPS, mais il a raison Totoche, si la bibliothèque l’accepte, on peut tenter le coup.
C’est ainsi que la ligne (1) a été masquée en remarque, et remplacée par la ligne (2) dans laquelle on désigne pour le dialogue la broche identifiée par 18 qui dans l’IDE désigne l’entrée Analogique repérée A4 par convention. Le dialogue s’établit sans rechigner, à condition naturellement de penser à déplacer le fil de liaison. Vous pouvez aussi tenter 19 pour A5 avec également le succès mérité.
Quand le programme interroge le capteur, il télécharge les neuf octets de données de la RAM de ce dernier. Durant cet échange d’informations, la petite LED rouge du module commercial s’illumine. Les neuf octets de données sont mémorisés dans le tableau de type byte identifié par data.
La ligne (1) annonce que les diverses instructions qui suivent vont traiter les données issues du capteur. Ce dernier à envoyé dans les premiers octets la valeur binaire de la température. En ligne (2) le premier traitement consiste à forcer à « 0 » le bit de signe. Ainsi on simplifie le traitement en « oubliant » ce détail, choix qui n’est pas sans conséquence, car, de manière classique si la température devient négative, le bit de signe va passer à « 1 » et la grandeur sera exprimée en complément à deux. Voyons ce qui en découle :
TITANIC version DALLAS.
Pour quantifier et décrypter le comportement du couple Capteur/Traitement informatique, nous allons déchaîner une véritable tempête dans un verre d’eau. Accrochez-vous, ça va secouer ! Mis en scène par la fameuse entreprise de production Arduiwood®, le célèbre navire DS-18B20 en 2 dans l’océan glacial 
de la Fig.115, navigue vers son tragique destin. Protégé par sa coque en film plastique, bien au chaud dans le sachet réputé parfaitement étanche 1, il est plongé dans une eau infestée d’icebergs 3. Ces derniers dérivent de la glace qui inexorablement pollue le congélateur familial dont la température est ajustée pour -24°C. Le but de cette expérience fabuleuse consiste à faire descendre la température du capteur à zéro, ou mieux, une valeur un peu négative, et ce pour voir comment vont en découler les données. Bernique, l’expérience « foire » lamentablement. On touille, on tritouille malaxivement la glace, rien à faire. La Fig.116 en témoigne : La température reste résolument à +3,56°C, et pas moyen de descendre en dessous. Pourtant nous étions prévenus, la physique élémentaire est formelle : En phase fondante, quelle que soit la température des glaçons, une eau non salée reste à 0°C constant tant que tout le mélange hétérogène « solides / liquides » 
n’est pas entièrement transformé en eau. C’est tellement vrai que le célèbre Professeur Celsius en a défini sa référence thermique ZÉRO bien connue !
Face à ce cuisant échec, il a fallu se résoudre à munir le capteur de fils bien plus longs pour pouvoir le mettre bien au chaud dans le congélateur. Vous pouvez laisser les fils courts, mais alors c’est PICOSYNTHÉ qui devra également aller dans le froid sibérien et porte fermée il sera délicat de lire les informations sur OLED !
– Victoire, la température dégringole enfin !
Pour pouvoir interpréter correctement les informations présentes sur l’écran de la Fig.117 il importe impérativement d’avoir un minimum d’informations relatives au comportement du programme démonstrateur. En particulier, la déviation verticale repérée par les six petits segments bleus à droite sera obtenue pour des températures variant entre 0°C pour le tiret du bas et +50°C pour celui du haut. L’interprétation est alors élémentaire. Durant la période 1, le capteur est à l’extérieur dans la buanderie. Comme il y fait moins chaud que dans le laboratoire, le capteur baisse lentement en température. La progression évolue entre environ 22°C et 19°C. Puis, en 2 le petit module est enfermé dans le congélateur. Rapidement, en 3, la température chute de façon linéaire. Les informations dans le cadre orange se comportent de la façon suivante :
Comportement du programme pour afficher les températures.
Par opposition à la trace graphique qui présente un historique de l’évolution, dont on extrait les valeurs en interpolant mentalement la hauteur de la trace par rapport aux graduations latérales, le petit cadre orange donne des grandeurs chiffrées pour ceux qui aiment bien les nombres. Pour comprendre les choix informatiques qui ont conduit au code source, il faut se replacer dans le contexte. La précision garantie n’est que de ± 0,5°C entre -10 °C à +85 °C. Cette information incite fortement à ne pas afficher les fractions de °C. D’un autre coté, il ne faut pas confondre précision et définition, ou si vous préférez finesse à détecter de faibles variations de valeur. Quand on prend en compte les informations des notices d’application, on note qu’en mode 12 Bits, la résolution est de 0,0625°C soit moins d’un dixième de degré Celsius. On est alors bien tenté d’afficher avec un chiffre significatif après la virgule. On verra ainsi la variation de température avec dix fois plus de sensibilité.
Pour satisfaire ces deux approches, le comportement adopté pour le programme apporte le compromis raisonnable suivant : Quand le curseur se trouve dans une position quelconque latéralement, il affiche dans le cadre T la valeur mémorisée sans décimales. Les deux chiffres significatifs sont alors « incontestables ». Si le curseur vertical est placé tout à fait à droite, comme mis en évidence en rouge sur la Fig.117, c’est la valeur de la dernière mesure qui est affichée par T, et avec une décimale. Si les intervalles de temps entre deux échantillonnages ne sont pas trop importants, cette donnée indiquera la température du moment, surtout si le gradient de variation est faible. Si la température est négative, quelle que soit la position du curseur, le cadre orange T affichera avec une décimale, mais … les planplantes seront gelées !
La valeur de la température contenue dans les 12 Bits de données est mémorisée en binaire, il faut la convertir en degrés Celsius plus adaptés à notre mental : EnDegresCelsius = Temperature * 0.0625;
Arrivé à cette ligne de code, le programme a téléchargé les données, et dans la variable Temperature de type int se trouve mémorisée en binaire la valeur de la température. Le Bit de signe a été forcé à « 0 ». Nous savons que chaque unité issue du convertisseur analogique numérique vaut 0,0625°C. Il suffit donc de multiplier le nombre binaire par ce coefficient particulier pour convertir en degrés Celsius, ce n’est assurément pas un traitement compliqué, car c’est la puce électronique qui a linéarisé le résultat.
Comportement du programme quand il fait froid.
Avec toutes ces explications sur le comportement du programme, nous avons complètement oublié ce pauvre capteur dans le congélateur alors que sa température corporelle diminuait linéairement en 3. Pauvre petite puce électronique, car bien que nous ayons soigneusement fermé la porte, elle grelotte de plus en plus. Que devient dans ces conditions la valeur de la variable EnDegresCelsius quand la température devient négative ? Et bien brusquement elle se prend un coup de fièvre et le programme affiche 127°C. Étrange non ? Le capteur se prend un coup de fièvre, avec ce froid il est tombé malade !
Et bien pas du tout. Robuste comme un percheron, il peut allègrement se promener par -55°C sans faiblir. Comme il a enfilé son manteau binaire, dès que la température devient négative, le bit de signe passe à « 1 » et la grandeur est alors exprimée en complément à deux. Tous les bits passent alors à « 1 » avec la fausse valeur numérique qui en résulte. Il faut « complémenter le complément » pour avoir la grandeur réelle quand on détecte un signe négatif. Comme une température supérieure à 50°C ne se présentera en principe jamais dans la véranda, on va se contenter de surveiller des valeurs excessives qui traduiront sans ambiguïté ce cas de figure. Pour comprendre comment on procède, il faut analyser la mémorisation.
Préserver un maximum de précision dans les échantillons mémorisés consiste à rechercher une plage de variation la plus grande possible entre 0 et 255 puisque chaque valeur est codée sur un octet. Hors la fourchette de température qui nous concerne va de 0 à 50. L’idée consiste à multiplier par cinq la grandeur numérisée, ainsi on augmente la précision dans ce rapport. L’instruction chargée de cette capture dans void Traitement_specifique_voie_A() est la suivante :
OCTET = byte (EnDegresCelsius * 5.08) + 1; // Valeur température x 5.
Explications : N’oublions pas qu’OCTET est le byte qui sera rangé dans la mémoire d’échantillons. On aimerait qu’une température de 50°C engendre une valeur maximale de 255. Par ailleurs, la valeur de zéro est réservée pour traiter graphiquement une température négative. Donc pour certifier qu’un échantillon mesuré nul ou positif ne soit jamais interprétée comme négatif, on ajoute 1.
(On verra plus avant le traitement du négatif.)
De ce fait, on peut écrire que 255 – 1 = 50 x k. On en déduit le coefficient multiplicateur k :
Petit détail scabreux : Multiplier le float EnDegresCelsius par le nombre décimal 5.08 engendre également pour résultat un type float. Hors on veut loger ce nombre dans un byte et « ça ne rentre pas » ! C’est la raison pour laquelle la multiplication est précédée de la directive byte qui impose au compilateur de se débrouiller dans les calculs pour que le résultat retourné soit codé sur huit bits.
Que se passe-t-il si la température devient négative ?
Et bien le résultat contenu dans Temperature sera codé en complément à 2.
Pour avoir la température réelle il faut appliquer la transformation :
Quelques exemples sont donnés dans le petit tableau ci-contre. La plage des températures n’est pas choisie au hasard, elle correspond aux valeurs « opérationnelles » du capteur dans le domaine « du froid ». Afficher en numérique la valeur de la température reste donc facile : Toute température supérieure à 72 sera considérée comme négative et sera traitée en tant que tel. Il ne faut toutefois pas que le graphique soit pénalisé. C’est la raison pour laquelle les valeurs numérisées et sauvegardées dans la mémoire d’échantillonnage seront systématiquement remplacées par zéro lorsque la température sera négative. Dans l’historique nous ne saurons pas à combien est descendu « le mercure », mais uniquement qu’il y aura eu du négatif dans le local. De toute façon c’est trop tard, la sentinelle n’a pas sauvé la situation et les végétaux vont terminer lamentablement dans le composteur. Nif nif nif, je déteste l’informatiquequitique !
if (EnDegresCelsius > 72) OCTET = 0; // Traite les températures négatives.
Effectuée dans la procédure void Traitement_specifique_voie_A() la valeur stockée dans la mémoire des échantillons sera systématiquement zéro si la température est considérée comme négative. Nous savons que -55°C donne une valeur en complément à deux qui en binaire fait 73. Donc toute valeur > 72 sera considérée comme représentative d’une température négative.
– Et s’il fait +80°C dans la véranda, le résultat sera mal interprété alors ?
– Exact, mais c’est qu’il y a le feu, alors franchement, ce n’est plus un problème ce qu’affiche OLED, il vaut mieux sauver les plantes !
C’est la procédure de visualisation des données void Affiche_le_couple_de_valeurs() qui traite « en temps réel » les valeurs affichées dans le cadre orange. Si le curseur est en position droite maximale, la dernière valeur de l’identificateur EnDegresCelsius est traitée. Cette subroutine se charge de la zone orange et des lettres symboliques qui y sont affichées. Elle traite également le complément à deux si la valeur de EnDegresCelsius dépasse le seuil de 72.
En (1) si le mode STATION_METEO est validé, tout ce qui est encadré par les accolades roses {} sera réalisé, donc le traitement spécifique des températures. En (2) si la température est négative, la détection se fait sur EnDegresCelsius qui alors dépasse le seuil de 72, on affiche la valeur en corrigeant le complément à deux. Le paramètre ,1 dans l’instruction display.print impose d’afficher avec une décimale. Si en (2) la valeur de EnDegresCelsius est inférieure ou égale à 72, c’est que les températures sont positives ou nulles, tout ce qui est encadré par les accolades oranges {} sera réalisé. Dans le test « orange », si le curseur est en position droite maximale, alors la dernière valeur calculée de EnDegresCelsius sera affichée avec une décimale. Dans le cas contraire, en (4) on affiche la valeur échantillonnée stockée en mémoire dans la cellule pointée par PTR.
– Et si qu’on se faisait un film?
– Bonne idée Totoche, un bon scénar avec du sussepense !
– Silence, on tourne !
Sur la Fig.118 en 1 la température du capteur placé en extérieur fluctue et finit par se stabiliser à celle régnant dans la buanderie. En 2, on a placé le DS-18B20 bien au chaud dans le congélateur en prenant la précaution de bien refermer la porte. Il en résulte en 3 une baisse régulière de température. Le curseur étant tout à droite la valeur est affichée en T avec une décimale. Dans le cadre % est visualisée la valeur numérisée.
On y trouve % = byte (1,3 x 5,08) + 1 qui donne bien 7.
En Fig.119 on commence juste à passer en température négative, tout au moins en utilisant pour unité le degré Celsius. À partir de maintenant la valeur mémorisée sera zéro ce que confirme %. C’est précisément ce zéro qui indique une température négative et surtout maintien la trace graphique de l’historique tout en bas du cadre bleu.
Image Fig.120 il commence à fridouner dans le navire. % continue à indiquer zéro, mais surtout vous constatez qu’en T la valeur est affichée avec une décimale bien que le curseur ne soit plus à l’extrémité droite du graphe. En Fig.121 le curseur est ramené tout à gauche, et l’on a oublié complètement le capteur. Avec -21.1°C … BRRRrrrrrrrr, ça caille !
Enfin, en Fig.122 le DS-18B20 est ressorti du congélateur et l’on observe la lente remontée en température. Comme pour la charge d’un condensateur la courbe est une exponentielle, car le gradient est proportionnel au différentiel de température qui diminue régulièrement.
Souffler le froid et le chaud.
Surtout le chaut du reste, car pour le froid on a déjà donné ! Il reste en effet à analyser le comportement du programme quand la température devient positive, et en particulier la linéarité de présentation graphique. Autrement dit, on désire vérifier que si la température avoisine 40°C par exemple, que la trace sera correctement pixélisée à la hauteur de la graduation latérale concernée. Pour observer la trace graphique et les affichages numériques, on peut souffler notre haleine sur le capteur. Le DS-18B20 est très sensible, et l’on verra très bien la variation s’enregistrer, surtout si le curseur est positionné tout à droite. Il est toutefois difficile dans ces conditions de dépasser notablement 27°C. À moins que vous ne souffriez d’une très forte fièvre, vous aurez bien du mal à atteindre les 50°C.
– Et si qu’on prenait un chalumeau à découper ?
– Petit et noir en deux secondes, mon ami Totoche, il sera ton capteur !
Bon, oublions le chalumeau, un peu trop radical.
Le petit sèche-cheveux domestique déjà évoqué dans le chapitre Observer des températures convient à merveille. En adaptant l’option « chauffe mais pas trop » et en dosant l’éloignement, on arrive facilement à la température maximale ou la dépasser modérément.
– Chauffe Marcel !
– Silence, on tourne !
Sur la Fig.123 en 1 on a soufflé avec notre haleine sur le composant. La température qui avoisinait les 20°C est monté vers 27°C puis a commencé son long retour vers la valeur ambiante du laboratoire. En 2 le sèche-cheveux a pris la relève, et vers 47°C le processus a été volontairement interrompu pour ne pas dépasser les 50°C correspondant au maximum possible sur le graphique. S’en suit en 3 le laborieux décrément logarithmique. Notez que le curseur n’étant pas en position extrême droite, la valeur de l’échantillon est affichée sans décimale.
Avec la Fig.124 commence la descente en enfer. Le sélecteur du sèche-cheveux est positionné sur maximum et la turbine tourne au ralenti. C’est chaud, très chaud. En 4 on observe des fluctuations, car ça brûle et l’on lâche le capteur. Tenu autrement, cette fois on va jusqu’à dépasser les 50°C. La multiplication par 5.08 dépasse les 255 possibles en binaire, les Bits de poids forts sont alors perdus. Seuls les poids faibles sont mémorisés. Du coup, durant toute la zone de dépassement des 50°C en 5, le graphique est faux. Mais vous ne le saurez jamais, car je vous assure qu’à cette chaleur ambiante il y aura longtemps que vous aurez fui la véranda pour plonger dans la piscine ! (Remarquez qu’en sortant de l’eau vous pouvez facilement vous sécher les tifs car l’ustensile est à portée de main !) Puis, stoppant la chauffe, on retrouve en 6 et 7 la diminution très pondérée de la température du petit module électronique. En soufflant dessus en 8, le gradient devient bien plus important. Mais on ne va pas s’époumoner jusqu’à épuisement. Le retour « à la normale » va ainsi prendre beaucoup plus de temps qu’il n’en a fallu pour culminer « tout en bas » !
CONCLUSIONS :
• Pour simplifier le logiciel on a purement et simplement éliminé le BIT de signe.
• Pour détecter les températures négatives on utilise la propriété du complément à deux.
• Pour simplifier le logiciel le graphique ne prend en compte que les températures positives.
• Sur l’historique les températures négatives maintiennent le tracé en bas de l’écran à la valeur 0.
• Les températures dépassant 50°C donnent un résultat erroné, une correction n’est pas envisagée car ce domaine est inenvisageable dans le contexte
x d’utilisation du système.
• Pour tenir compte de la précision de ± 0,5°C du capteur, l’historique est numérisé sans décimale.
• Si l’on désire une décimale pour la température actuelle dans le local surveillé, il suffit de placer le curseur en position droite maximale.
• Si la température devient négative, la dernière qui est mesurée est affichée avec une décimale quelle que soit la position du curseur d’indexation dans
x l’historique.
Mesurer l’hygrométrie ambiante.
Trop d’humidité, c’est bien connu, attire les salamandres. Et puis surtout, et principalement l’été, un air trop sec n’est pas très bon pour les plantes.
(Pour les humains non plus du reste.) Aussi, comme l’ENREGISTREUR dispose de deux voies, pourquoi ne pas transformer notre générateur en une petite station météo ? Mesurer que la température n’en faisait qu’un thermostat moderne, mais ajouter un paramètre typiquement « grenouille électronique » lui assure le grade de station météo. Belle promotion que le préfixe PICO n’altère absolument pas. Et si PICOSYNTHÉ annonce un air trop sec : Arrosez !
L’utilisation d’un capteur d’humidité n’est absolument pas élémentaire. Souvent, ces dispositifs sont conçus comme des condensateurs dont le diélectrique est l’air ambiant. La capacité de ces composant reste assez dérisoire, et aller en mesurer la variation qui résulte du changement d’hygrométrie n’a rien d’anodin. J’oserai affirmer que c’est presque un défi technique qui a été relevé brillamment par des ingénieurs spécialisés.
C’est ainsi, que dans le commerce des produits comme celui en 4 sur la Fig.111 sont disponibles pour quelques Euros et fournis avec une bibliothèque qui en rend la mise en œuvre quasi évidente.
Le capteur d’Humidité et de Température DHT11.
Montré sur la Fig.127, ce module de mesure est constitué d’un senseur d’humidité résistif complété par une thermistance à coefficient négatif de température. Les dimensions du capteur d’humidité étant forcément influencées par la température, il importe d’en tenir compte pour la correction qu’il faut apporter aux valeurs mesurées. C’est la raison pour laquelle, accessoirement ce capteur mesure également la température. Un microcontrôleur intégré s’occupe de faire les mesures, de les convertir en pourcentage d’humidité, puis de les transmettre par une voie qui dialogue au moyen d’une seule ligne série bidirectionnelle « à collecteur ouvert » de type OneWire. (Un fil.) Chaque module est calibré en usine et ses paramètres de personnalisation (Son empreinte.) sont stockés dans la mémoire ROM du microcontrôleur local.
Caractéristiques techniques du capteur DHT11 :
La Fig.126 donne le brochage du composant ainsi que celui du petit module en circuit imprimé. La Fig.127 indique comment établir la liaison avec un microcontrôleur. La mise en œuvre sur ARDUINO est d’autant plus facile que la bibliothèque DHT11.h dédiée est disponible en ligne. et se charge des protocoles des dialogues série. Le format des données série est de 40 bits.
• Mesure de l’humidité relative. (RH)
• Alimentation comprise entre 3 Vcc et 5.5 Vcc.
• Courant d’alimentation : 100 µA maximum en veille, 2.5 mA maximum en dialogue.
• Mesures des températures comprises entre 0 °C et 50 °C.
• Mesures d’humidité entre 30 % et 90% RH à 0°C.
x entre 20 % et 90% RH à 25°C.
x entre 20 % et 80% RH à 50°C.
• Résolution 1 % RH. • Précision à 25 °C : ± 5% RH.
DIALOGUE sur la ligne DATA.
Lorsque le microprocesseur 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. (Si le signal de départ est valide) Il repasse ensuite en mode veille jusqu’à la prochaine sollicitation. Une « conversation ressemble » à :
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
x dont voici le format :
Le schéma ci-dessus donne le format des BIT de données, la Check Sum (Somme de vérification.) est élaborée par la somme des quatre premières données, donc avec les 32 premiers BIT. Revue de détails :
x * En bleu clair l’état zéro forcé par le microprocesseur µP ou en réponse par le DHT11.
x * En rose pâle l’état « 1 » maintenu par la résistance de forçage R. (Pull Up)
x * En bleu épais la requête du µP et en violet la réponse sérielle du capteur. (ACR : ACcusé de Réception.)
Faire connaissance avec le circuit DHT11.
Franchement, foncer « bille en tête le nez dans le guidon » ne me semble pas du tout raisonnable. Par ce préambule, je veux dire que mélanger directement le code relatif à cette application dans celui propre à PICOSYNTHÉ va provoquer un « brassage » incompréhensible. Sans prétendre expliquer tous les détails du code spécifique utilisé, on va avec P38_Humidistance_DHT11.ino aborder deux ou trois points particulier qui méritent d’être soulignés. Ensuite, en vous aidant des nombreux commentaires qui émaillent ce démonstrateur, vous pourrez établir le lien avec les documents disponibles sur Internet.
Entre autres particularités, comme ce code fait appel à la bibliothèque DHT11.h que vous devrez déclarer comme explicité dans le chapitre Mise en œuvre du circuit DALLAS DS-18B20, on doit se plier à l’utilisation des identificateurs propres à la librairie. Par ailleurs, s’y trouve une façon très particulière d’employer l’instruction switch / case qu’il vaut mieux aborder. Cette syntaxe est totalement légale dans l’IDE, mais on ne la rencontre pas très souvent il faut le dire :
Ces précisions sur le type énumération étant développées, nous pouvons mieux aborder l’étude du démonstrateur qui pour des raisons de simplicité affiche les valeurs sur le moniteur série de l’IDE.
Probablement que certains d’entre vous vont trouver étrange de brancher deux modules différents sur la petite station météo alors que le DHT11 serait suffisant puisqu’il fournit à lui seul l’hygrométrie mais également la température. Deux motivations ont conduit à ce luxe apparent :
• Le composant n’est pas prévu pour des températures négatives.
• Brancher deux modules est plus riche pédagogiquement, car il nous a amené, pour ne citer que ça, à
x utiliser une broche d’entrée analogique en E/S binaire pour une ligne OneWire.
Téléversez le croquis d’évaluation, n’oubliez pas de vérifier que votre ligne de communication est déclarée à 115200 bauds et observez le déroulement du programme. Si la vitesse de dialogue est correcte, le logiciel se présente, puis la boucle de base réalise une mesure par seconde.
Dialogue cohérent, le premier cas de l’instruction switch est validé. Le case affiche alors en A sa valeur pour que vous puissiez ainsi faire le lien avec les explications de l’encadré donné ci-dessus.
Débranchez alors le fil de la ligne de dialogue. Immédiatement, comme souligné par B sur la Fig.129 c’est le deuxième cas qui sera sélectionné par switch. Et comme précisé dans les explications l’identificateur concerné vaut 1. Rebrancher alors le fil provisoirement isolé. Immédiatement en C le cycle se poursuit. Une petite précision s’impose. L’instruction switch reçoit la valeur :
x readDHT11(Broche_Com_DH11, &Temperature, &Humidite)
Concrètement, readDHT11 est une fonction qui tente un dialogue avec le DHT11 et « décortique » la réponse supposée arriver sur Broche_Com_DH11. En fonction de la morphologie chronométrée des états « 0 » et « 1 » présents sur cette broche, un bilan d’erreur est élaboré. Si le « TIMEOUT » n’est pas dépassé, il y a échantillonnage temporel des bits puis analyse de l’octet Check Sum. Si ce dernier est correct, la fonction retourne la valeur zéro. switch réalise alors le premier case. Notez que Temperature et Humidite sont des identificateurs de pointeurs, d’où la syntaxe utilisée pour s’en servir. C’est nous qui les avons déclaré juste après la directive enum.
Ayant globalement cerné la mise en service du capteur d’humidité avec un Arduino, passons de la ligne de dialogue USB à l’affichage sur l’écran OLED. Pour préparer le terrain en vu d’une intégration dans PICOSYNTHÉ, le démonstrateur P39_Mesure_HYGROMETRIE.ino reprend le programme P37_Mesure_des_temperatures.ino dans lequel on va se 
contenter de compléter le test de présence du capteur de température pour vérifier également celle du capteur d’humidité. On va ajouter les séquences spécifiques au DHT11, autant celles pour effectuer les mesures que celles pour l’affichage. Ainsi, quand les deux paramètres météorologiques seront traités par ce démonstrateur, il suffira de « transporter » le total dans le programme complet. Il nous faut aborder la façon dont sera traitée la représentation graphique : Comme verticalement on a cinq intervalles, le plus simple consiste encore à graduer entre 0 pour le tiret du bas à 100% pour celui du haut du cadre bleu. Par exemple sur la Fig.130 le pourcentage d’humidité relative était stable vers 50%. Pour augmenter facilement l’humidité relative de l’air qui l’environne, il suffit de souffler dessus. On peut observer sur la Fig.130 que l’hygrométrie est monté jusqu’à 90%, et encore je n’ai pas insisté. Pour sa part, la température a également changé de 25°C jusqu’à 27°C. Le retour à la normale est très lent, car il faut que l’humidité présente sur le corps d’épreuve du DHT11 se résorbe.
Tout naturellement, c’est la procédure void Traitement_specifique_voie_B() qui se charge d’effectuer les mesures d’humidité. Comme le précise un commentaire dans le programme, puisque la présence des deux capteurs a été vérifiée en entrée dans l’ENREGISTREUR, des erreurs sont maintenant très improbables, sauf sur une panne du système. On épure le code en abandonnant l’idée d’afficher un texte d’alerte. Cependant, pour que l’utilisateur puisse savoir qu’il y a un problème, en cas de TimeOut ou de ScheckSum incorrecte, la valeur est forcée à zéro. Comme nous savons que 0% d’humidité relative est pratiquement impossible, l’opérateur sera ainsi informé.
La ligne (1) invoque pour l’instruction switch la fonction readDHT11 qui retourne 0,1 ou 2 en fonction des événements survenus durant le dialogue. Si le délai de réponse est dépassé le case de la ligne (2) est validé. Si la ligne a été parasitée et que la donnée récupérée n’est pas cohérente, c’est le case de la ligne (5) qui s’active. Si tout va bien, ce qui sera normalement le cas, la sélection (2) affecte à OCTET en (3) la valeur d’Humidite interpolée entre 0 et 255 pour enregistrer avec le maximum de précision, et surtout pour engendrer une déviation verticale couvrant toute la hauteur du rectangle bleu quand la valeur échantillonnée varie entre 0 et 100. Cette instruction map est vraiment commode à utiliser.
Évidemment, pour afficher correctement la valeur numérique, il faut opérer la transformation réciproque. Ce n’est vraiment pas compliqué. Dans void Affiche_le_couple_de_valeurs() on vérifie en (1) s’il faut corriger la valeur traitée. Si l’option STATION_METEO est active, il suffit de diviser la valeur mémorisée par 2.55 pour retrouver le pourcentage correct. Cette correction est effectuée en (2) qui de plus par la directive ,0 impose à display.print d’afficher la valeur sans décimales. Si le booléen STATION_METEO vaut false, alors en ligne (3) on affiche sans modification la donnée mémorisée.
Munir la pico-centrale météo d’une sentinelle.
Véritable promotion pour notre ENREGISTREUR, ce petit perfectionnement va surtout nous éviter toute la nuit, quand à l’extérieur il fait froid, de se lever pour aller voir sur le petit écran orange et bleu s’il faut intervenir et activer un chauffage. De plus, c’est toujours quand vous êtes partis de chez vous pour une semaine complète, que brusquement le thermomètre dégringole et que vous n’êtes pas à la maison pour agir. Pour ne pas avoir à se lever pour rien, la solution est élémentaire. Il suffit de munir la petite station météo d’une sentinelle, vocable un tantinet pédant pour désigner une séquence de programme qui surveille la température et déclenche une alarme si elle descend en dessous d’un seuil critique.
C’est d’autant plus facile à faire qu’il nous reste disponible la broche A5 qui n’est pas encore affectée. On la configure en sortie. Un fil chemine jusque dans votre chambre et quand elle passe au niveau « 1 », il alimente un quelconque couineur qui vous sortira brutalement des bras de Morphée. Bien qu’informatiquement ajouter un peu de code pour traiter ce perfectionnement ne justifie pas un démonstrateur à part, P40_Sentinelle_METEO.ino se trouve dans la liste des programmes. En réalité, l’idée de sentinelle est venue après avoir effectué l’intégration de la fonction météo dans le programme complet. Cette phase n’a pas été immédiate, car une collision de PILE est survenue durant cette phase. Du coup, pour y aller progressivement, la sentinelle a été développée à part pour évaluer le cout en octets et voir si le code supplémentaire qui en résulte serait acceptable. Cet exposé ne respecte donc pas la chronologie du développement pour des raisons purement pédagogiques.
Notez au passage qu’il serait aussi facile de surveiller un dépassent en chaleur, un taux d’humidité insuffisant pour certaines plantes etc. On peut varier à l’infini, mais il faut savoir se limiter. N’oublions pas que l’appareil est avant tout un générateur, pas une station météo. Cette option est décrite dans ces chapitres uniquement pour démontrer la facilité de traiter des capteurs particuliers et montrer la souplesse du système.
En tête du démonstrateur est placée une directive qui vous permet de définir la température en dessous de laquelle se déclenchera l’alarme. (Ou le dispositif de chauffage automatique.) La valeur 2 n’est pas choisie au hasard. Deux critères ont conduit à la sélectionner. Beaucoup de plantes ont besoin d’avoir froid pour détecter l’hiver, et au printemps redémarrer la floraison. Par exemple, en appartement un oranger ou un citronnier n’auront jamais de fruits, même si avec un petit pinceau vous titillez les fleurs pour remplacer la pollinisation que ne font pas les abeilles en ville. Il faut impérativement laisser la température descendre. Les plantes grâces tolèrent généralement du -1°C, mais pas moins. Le deuxième critère, c’est l’inertie thermique du réchauffage. Pour faire remonter la température, il faudra du temps. Alors cette marge de « sécurité » semble raisonnable. Il faudra placer le capteur dans l’endroit le plus froid, généralement proche d’une vitre à l’opposé du radiateur qui tempère le local en hiver.
x #define Sentinelle 19 // A5 utilisée en sortie pilotera l’alarme de température.
Pour rendre le programme plus lisible, on affecte un identificateur pertinent à la broche A5. Dès que l’on ouvre la fonction ENREGISTREUR, on configure A5 en sortie et à l’état « 0 » :
En sortie de la fonction ENREGISTREUR on rétablit la broche A5 en entrée, pour raison de sécurité. Si par mégarde durant les manipulations on y force un état « 0 » ou « 1 » elle ne risquera strictement rien.
Dans la procédure void Traitement_specifique_voie_A() le traitement de la sentinelle est situé tout à la fin. En (1) la comparaison effectuée avec EnDegresCelsius < T_MINI_autorisee passera Sentinelle à « 1 » si la température pénètre dans la plage des valeurs comprises entre +1,9°C et 0°C. Ensuite, si la température devient négative entre -0,1°C et « beaucoup », nous savons que EnDegresCelsius devient plus grand que 72 d’où la deuxième comparaison avec entre les deux un opérateur OU inclusif. En ligne (2), dès que la température du local remonte au dessus du seuil critique +1,9°C la Sentinelle est replacée à « 0 ».
ATTENTION : Pour effectuer des observations rapidement, dans les démonstrateurs le délai entre enregistrements a été provisoirement réduit à une seconde. Les temps de réaction sont rapides. Dans le programme complet, la valeur par défaut pour l’ENREGISTREUR est de douze minutes. Ce choix privilégie l’affichage avec un étalement en largeur journalier pour le graphe. Douze minutes constitue le temps de retard le pire, celui ou le paramètre vient de franchir le seuil de réaction une seconde après la dernière mesure des échantillons. Ce délai de réaction me semble un peu long, le réchauffage risque d’arriver un peu tard si l’inertie thermique des lieux est relativement courte. Quand la température aura été remontée par un dispositif idoine, si ce dernier est piloté par PICOSYNTHÉ, il va encore chauffer durant tout ce temps. C’est la raison pour laquelle si un dispositif de réchauffage est piloté automatiquement par une consigne de la pico station météo, je vous suggère de diminuer les écarts entre deux échantillons à une minute, pas plus.
La lecture du source P40_Sentinelle_METEO.ino révèle que l’ajout le la fonction sentinelle ne consomme aucune place supplémentaire dans la RAM des variables dynamiques. Pour le programme, toutes les instructions donnant vie à la surveillance automatisée ne « poussent les murs » que de 74 octets. Ce n’est donc pas ce perfectionnement bien commode qui va grever le budget informatique. Comme par ailleurs le code pour la station météo n’augmente « que » de 2352 octets et vu la place qu’il reste encore de disponible, on peut espérer une intégration pépère de cette option séduisante dans le programme complet actuel.
Intégration de la station météo dans PICOSYNTHÉ.
Fastoche, il suffit de déclarer les constantes et les variables spécifiques, de faire appels aux bibliothèques incontournables, de remplacer le « bloc des séquences de l’ENREGISTREUR » et la partie est gagnée. On compile, monsieur C++ accepte, nous annonce une occupation de 96%. Ouaffff, c’est bien. On utilise un max l’ATmega328, et il reste encore 4% d’espace programme possible, c’est une affaire qui roule. On téléverse, le Panda continue bien sagement sa sieste. Et le GENERATEUR ETALON ronronne comme un chat suite à un RESET. Fastoche, je vous avais dit, c’était prévu …
– Allez, on se la fait cette séquence météo ?
– Ben oui Totoche, un chti clic sur FC- long, un petit cloc sur Fc+ court, c’est génial.
– T’as vu, les capteurs sont OK ?
– Normal, c’est Moâmoâ que j’ai branché les fils. Encore un clic et à nous la Thermohumidotruc.
– Scongregneugneu, ya des pixels du genre Bug en bas à droite de l’écran graphique !
La verrue sur le gâteau, ces quelques petits pixels qui vous gâchent définitivement la journée. On vient de se prendre encore de plein fouet une collision de PILE avec le TAS. On a plein plein plein d’octets encore disponibles en mémoire non volatile, mais en RAM dynamique c’est la crise du logement. Retour dans l’enfer du « gagne petit » pour arriver à faire entrer un éléphant dans une grosse boite … d’allumettes !
Bref, en l’état le programme cafouille, il faut impérativement gagner de la place sans pour autant enlever des Items dans le MENU de base. C’est encore la crise du logement qui revient chaque fois que l’on jubile.
– Non, pas question de chasser mon Panda sous prétexte qu’il oblige à garder trop de textes dans le corps du programme !
Et pourtant nous savons que le moyen le plus direct pour faire maigrir la dynamique sans perdre pour autant « la rentabilité » du code, c’est de diminuer de façon drastique les bavardages. L’idée consiste à remplacer les belles phrases par du style télégraphique. On active le moteur de recherche, on lui désigne comme cible (« les deux caractères d’ouverture d’un affichage textuel, et partout on remplace des « Bonjour les Amis, comment ça va ce jour ? » par des « Salut ! » sachant que tout caractère en moins entre les délimiteurs « se traduit par de la place en plus entre la PILE et le TAS.
Exemples : « Mode STATION METEO ? » devient « METEO ? », « Capteur » devient « Cptr », « RAZ ENREGISTREMENT ? » devient « RAZ MEMOIRE ? ». Partout ça frise le TEXTO.
L’intégralité du programme est passée en revue. De temps en temps, on recompile le tout, on téléverse et miracle, la misère en bas à droite finit par disparaitre. Pour augmenter la sécurité, car nous savons qu’une collision entre la PILE et le TAS est un phénomène sournois, bien que le logiciel fonctionnait tout à fait correctement, la poursuite des économies « bouts de chandelles » a été conduite sur l’intégralité du programme. Ainsi, on ajoutait de la marge « en poussant encore un peu les cloisons ». Cependant, l’intégration de l’option météo a été effectuée sans la sentinelle, pour aboutir à P41_COMPLET_avec_METEO.ino qui donne pleine satisfaction. On tente l’ajout de la sentinelle.
Prouououiiitchhh … une petite formalité avec P42_COMPLET_avec_SENTINELLE.ino qui tourne comme une montre Suisse. On pouvait s’en douter, car la zone mémoire pour le programme laissait encore 4% d’espace libre, alors avec nos 74 octets le compilateur se gosse discrètement. Outre ces ridicules locataires binaires, la sentinelle ne bavarde pas. Pas de « texte » = « rien à voir, circulez ! ».
Et pourtant elle tourne … mais prendre une assurance sur l’assurance de l’assurance reste malgré tout indispensable. On ne peut laisser partir dans la nature un programme génétiquement modifié sans s’assurer qu’il ne va pas muter. Aussi, nous l’avons déjà fait pour les petits laboratoires, avant de valider le logiciel et de débrancher le cordon pour le téléversement de la DB9, on prend la loupe et on regarde combien il reste de place entre le TAS et la PILE. Dans le logiciel dernière version, vous validez les deux zones de code repérées par des « @@@@@« .
Le verdict tombe, assez rassurant : 185 emplacements sont disponibles pour les périodes d’encombrement.
Bref, on sature le microcontrôleur, tout ce que l’on pouvait espérer entre dans la boite d’allumettes. Il est grand temps de considérer que le contrat est pleinement rempli.
Reste qu’il ne faudrait pas confondre cette petite application de loisir comme un système ultra professionnel à qui on peut confier la grande serre horticole de 2000 mètres carrés. Nous restons dans le cadre ludique d’une expérimentation « pour le plaisir ». Sur des applications dont l’enjeu est notable, il conviendrait de multiplier les sécurités, dupliquer les systèmes. C’est un autre monde avec qui il ne faudrait surtout pas confondre.
Mise en service des deux capteurs météorologiques.
Expliciter la façon dont on pouvait tirer partie de l’enregistreur n’était, avec la mesure des températures et de l’hygrométrie relative, qu’un exercice d’école. D’un autre coté, l’application proposée ici en travaux pratique n’est pas forcément ridicule. On peut réellement placer Boarduino dans une véranda pour nous prévenir d’un frima intempestif. Du reste, comme dans ce cas le synthétiseur est inutilisé, tous ce chapitre pourrait s’intégrer dans PICOLAB pour en faire un item de mesures particulier. L’appareil serait plus compact. Bref, toutes les options sont permises. Il faut dans cette hypothèse exclure des fils volants, branchés ou débranchés à la demande chaque fois que l’on veut intervenir sur l’appareil. La réalisation d’un adaptateur rendant commode ces opérations s’impose, et de surcroit évitera les erreurs de connexion pouvant s’avérer fatales pour les capteurs. La Fig.131 dévoile le schéma très compliqué de cet adaptateur qui est constitué par un petit circuit imprimé dont le connecteur HE14 à 9 broches se branche sur PICOSYNTÉ, par une ligne un peu longue de quatre fils de liaison et à l’autre extrémité du connecteur à six broches C2. En fait, C2 est soudé sur un autre petit circuit imprimé qui sert de support dans le boitier qui protège mécaniquement les deux capteurs. Sur le circuit servant de prise, soudé sur la ligne HE14 femelle à neuf broches, on trouve C1 qui permet de relier GND et la sortie A5 au choix sur un éventuel 
système acoustique ou un dispositif de chauffage assez puissant par rapport au volume utile à maintenir hors gel. En théorie C1 devrait se contenter de deux broches puisqu’il ne véhicule que deux lignes, mais disposant d’un élément [3 x 2] contacts, l’utiliser tombe sous le sens et permet en option jusqu’à trois périphériques.
Quand la sortie A5 passera à l’état logique « 1 », c’est que la température est descendue en dessous du seuil critique. Pour visualiser cet état, une LED rouge D est ajouté avec sa résistance de limitation R de 470Ω. Le circuit imprimé qui sert de prise pour s’enficher sur les connecteurs de PICOSYNTHÉ est donné sur la Fig.132 par un dessin très agrandi. En A nous avons la vue de dessus avec le dessin des pistes cuivrées qui sont visibles, comme si la plaque prépercée était transparente. En B la représentation coté cuivre sur laquelle seulement deux pistes sont coupées. En particulier celle en vert. Pour être certain que le -5Vcc ne soit pas présent trop « loin » sur le circuit, en 4 la broche du connecteur HE14 a été écourtée. Les 
différents fils qui vont vers les capteur sont soudés directement sur le circuit prépercé ou sur les broches du connecteur. Donc ces fils fragiles sont situés sur le dessous. Pour en augmenter la solidité mécanique en cas de traction accidentelle, le circuit a été ajouré par le petit trou rectangulaire 3. Ainsi les fils transitent facilement du dessous vers le dessus où ils sont serrés dans de la gaine thermo rétractable 5. L’isolant mécanique qu’elle constitue traverse à son tour le fourreau 2 constitué d’un matériau supportant les très fortes température. Se fourreau est à son tour serré fortement contre le circuit imprimé par deux petits ponts 1. La Fig.133 est propice à l’observation de l’aspect global présenté par le circuit de l’adaptateur. Ce dernier est présenté quand il est branché sur l’appareil de mesures. 
On y retrouve les divers éléments et en particulier le petit pont 1 soudé en dessous sur les pistes cuivrées. Une deuxième bride analogue serrant fortement la gaine 2 est peu visible derrière la résistance qui pour la circonstance chevauche au-dessus. Le fourreau de protection 2 est constitué d’un matériau résistant aux températures élevées, pour ne pas se voir dégrader lors de la soudure des deux pontets 1. Notez également, que la gaine thermo rétractable en 5 est en réalité constituée de deux éléments de diamètres différents et constituent ainsi un protecteur mécanique à « souplesse progressive ». Le trous de passage des fils soudés sur le dessous et visible en 3 présente sur la photographie une tache blanche délicate à interpréter. On comprend bien mieux en regardant la Fig.134 qui montre le coté pistes cuivrées. Quoi que l’on fasse, les fils soudés sur le dessous font obligatoirement des boucles avant de traverser le circuit par l’ouverture de passage prévue à cet effet. Impossible de les plaquer totalement compte tenu de leur souplesse. Proéminents sous cette prise improvisée, ils sont particulièrement vulnérables.
Statistique bien connue des techniciens en maintenance industrielle, 80% des pannes sur les systèmes automatisés proviennent des capteurs, de la connectique et des fils de liaison. Ces divers éléments en constituent les organes les plus fragiles. Pour parer cette faiblesse de notre adaptateur, les fils sur le dessous ont été noyés par inclusion dans une gangue protectrice constituée, vous l’avez deviné, de colle Araldite. Cette dernière ayant un peu coulé à travers l’orifice de passage des fils entoure un peu la sortie des ces derniers sur le dessus. C’est cette protection translucide qui fait reflet sur la photographie.
Support et branchement des deux capteurs météorologiques.
À l’autre extrémité de la ligne, bien visibles sur la Fig.135, les quatre fils de liaison sont soudés sur un tout petit circuit imprimé qui supporte le connecteur C2 dont la Fig.136 présente le dessin. Ce dernier comme tous les autres est très agrandi et montre le coté composants avec au centre en « mode transparent » les trois pistes cuivrées utilisées. Les « gros trous » latéraux ont juste le diamètre pour laisser traverser des vis ØM3 assurant la fixation dans un tout petit boitier de protection réalisé aux dimensions requises. Sur le dessin, en vue de dessus l’encombrement du capteur de température est colorié en vert pastel, alors que celui du capteur d’humidité est représenté en bleu clair. Le dessin pourrait faire croire à une interférence matérielle. Rien à craindre, car c’est le contour « absolu » qui est souligné en rouge, vous pouvez voir sur la Fig.135 que les deux modules cohabitent parfaitement sur le connecteur HE14 avec un jeu minimal d’un millimètre.
ATTENTION : Rien n’interdit d’intervertir les deux modules, si vous vous trompez, les branchements seront incorrects. Repérez-bien sur la vue de dessus le coté réservé à l’hygrométrie et celui réservé à la mesure des températures. Ceci dit, durant le développement la bêtise a été faite à plusieurs reprises, les circuits ne sont pas rancuniers et n’ont pas souffert de la permutation accidentelle.
Quand tout fonctionne à la perfection, on se bricole un petit coffret pour mettre les deux capteurs en sécurité. Sur la Fig.138 on peut voir qu’il y a des trous de capture de l’air ambiant sur toutes les faces de la petite boite, alors que sur la Fig137 le couvercle n’est pas encore refermé. En 1 nous avons la limande qui relie électriquement le boitier au circuit imprimé servant de prise. En 2 une petite bride immobilise sérieusement la ligne à l’intérieur. Le petit circuit imprimé servant de support est solidarisé en 3 sur deux entretoises laissant largement assez de place sur le dessous pour « sortir » les fils latéralement. Enfin, entre le coté 4 et les deux petits modules on laisse assez de place pour pouvoir facilement les débrocher sans avoir à démonter le circuit et les entretoises en 3.
