Sans aller jusqu’à développer la théorie du signal ou les séries de Fourier avec mise en œuvre d’une FFT, un minimum d’explications s’imposent si l’on veut comprendre ce que l’on observe quand on utilise un Convertisseur Analogique vers Numérique (CAN). Considérons la Fig.1 qui représente le signal que l’on mesure sur une entrée analogique d’Arduino par exemple. La source mesurée présente une tension moyenne représentée par le trait mixte rouge sur le dessin. Mais cette tension est mesurée au moyen de fils qui vont de la source à l’entrée E. Inévitablement cette ligne va capter un peu de 50Hz rayonné par l’environnement du secteur et les appareils qui y sont reliés.
À ce signal parasite (Pseudo sinusoïdal et généralement assorti d’harmoniques à 100Hz …) s’ajoute ce que l’on convient de nommer « du bruit ». Ce phénomène omni présent se traduit par des fluctuations rapides et permanentes d’un petit signal qui semble s’ajouter à celui de la source. Les origines en sont nombreuses, et en particulier l’agitation moléculaire issue de la chaleur des composants. Un peu comme les mouvements Browniens dans l’air qui nous entoure. Ce chuintement électronique est nommé « bruit », car il se traduit par du « souffle » plus ou moins important sur les systèmes audio. Enfin, de temps en temps apparaissent des Pics très courts en durée, mais d’intensité souvent notable par rapport au « bruit ».
Considérons maintenant la phase de numérisation. Sur la Fig.1 TT représente le Temps de traitement, c’est à dire le délai qui s’écoule entre deux affichages sur l’écran. Il inclut le temps de conversion du CAN, les routines de calculs, le formatage pour afficher et le délai qu’il faut pour envoyer les données sur la ligne série USB. Sur la Fig.1 les traits verticaux en rose représentent les instants où sont effectués les échantillonnages de valeurs « binaires ». Chaque numérisation est séparée de la suivante par la durée TT qui représente en fait la durée de la boucle de base void LOOP. Chaque petit cercle violet représente la valeur instantanée qui a été convertie en « 0 » et « 1 » pour être ensuite traitée par le programme. CATASTROPHE ! On constate que chaque valeur est différente de la précédente. Pas beaucoup, mais différente et l’affichage à l’écran va varier en permanence le rendant pratiquement « illisible ». Avec le Pic nous avons de la chance, car il est passé inaperçu. Mais Pic pour son compte va retourner une valeur aberrante. Et encore, dans ce fatras nous n’avons pas cité les fluctuations qui résultent du convertisseur CAN qui pour son propre compte va apporter sa contribution à ce joyeux chamboulement.
Comment s’affranchir de toutes ces fluctuations ? Heureusement la réponse est à la fois facile à trouver et à mettre en œuvre dans un programme informatique codé en langage C. Il suffit de LISSER. Mathématiquement on pourrait parler d’intégration, mais n’entrons pas dans ces détails scabreux. En observant avec attention la Fig.1 on constate que des valeurs numérisées sont plus importantes que celle moyenne que l’on désire « stabiliser ». D’autres sont en dessous du trait mixte rouge. Statistiquement, si l’on échantillonne un grand nombre de fois, on finit par avoir autant de dépassements vers le « haut » que « vers » le bas. Il suffit de faire un grand nombre de mesures et d’en faire la moyenne. Plus le nombre de mesures est important, plus la durée d’une CAN va augmenter, mais avec les microcontrôleurs à 16MHz actuels on peut avoir des nombres de plusieurs centaines.
Autant dire que les Pics vont être totalement exclus de notre « paysage herbeux ». La solution est donc élémentaire : N mesures en boucle dont on fait la somme puis calcul de leur moyenne en divisant cette somme par N. On a ainsi effectué un lissage informatique, méthode utilisable chaque fois qu’un programme mettra en œuvre une CAN dont les fluctuations sont préjudiciables.
