IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Voir le flux RSS

Le blog de f-leb

[Actualité] [Raspberry Pi Pico][SDK C/C++] Le convertisseur analogique-numérique : erreurs DNL et INL - Partie 2/2

Noter ce billet
par , 20/11/2024 à 09h00 (2917 Affichages)
Dans la première partie de ce billet, j'étudiais la population des échantillons retournés par le convertisseur analogique-numérique 12 bits (ou ADC pour Analog Digital Converter) de la carte Raspberry Pi Pico, par exemple :

Nom : test2513-1535.png
Affichages : 1671
Taille : 30,9 Ko

À gauche, le potentiomètre rotatif est réglé sur N=2513 (valeur moyenne), soit une tension Vout = 3,3 x (2513/4095) = 2,03 V.
Pour 1000 échantillons mesurés, on voit (grosso modo) la répartition « en cloche » bien connue.

Il se passe quelque chose de particulier sur le graphique de droite pour N=1535. Je l'observe bien en voyant défiler les valeurs dans le terminal série, il y a très peu de fluctuations. Et pour cause, 85% des échantillons sont sur la valeur moyenne, pile sur la valeur 1535, avec très peu de dispersion vers des valeurs supérieures, et curieusement, quasiment pas de dispersion vers des valeurs inférieures. Je suis tombé par hasard sur cette valeur de 1535 en tournant le potentiomètre, bizarre... Alors que normalement je tombe sur des allures de courbe en cloche, comme on peut s'y attendre.

L'explication se trouve dans la datasheet de la puce RP2040, notamment dans ces courbes caractéristiques de l'ADC :

Nom : INL-DNL.png
Affichages : 534
Taille : 417,8 Ko

Regardez les valeurs des pics sur la deuxième courbe ci-dessus (avec l'erreur « DNL »)...
Je tourne le potentiomètre pour viser la valeur 512 (pas facile de viser juste), là où l'erreur DNL présente aussi un pic, et j'observe le même phénomène avec très peu de fluctuations autour de 512 et à nouveau cette étonnante dissymétrie de la distribution autour de la valeur moyenne :

Nom : test512.png
Affichages : 525
Taille : 19,5 Ko

Il semble que je sois tombé sur un « défaut » du convertisseur, dû à sa structure physique, et qui n'arrive que pour quatre valeurs bien définies : 512, 1536, 2560, et 3584.

  • Les erreurs de non-linéarité « DNL » et « INL »

Pour comprendre (c'est coton à assimiler), il faut savoir que les convertisseurs analogique-numérique présentent des défauts identifiés qui font dévier ses caractéristiques de la caractéristique « idéale » :

Nom : courbe-transfert-adc.jpg
Affichages : 509
Taille : 34,6 Ko

La courbe A en haut à gauche est la caractéristique de transfert « idéale », avec sa forme « en escalier » qui montre les seuls défauts de quantification (dus à la numérisation). Suivent des caractéristiques avec des erreurs de gain, de linéarité, de « code manquant », et de décalage.

Les erreurs DNL (Differential Nonlinearity) et INL (Integral Nonlinearity) sont des erreurs de non-linéarité « locales » que vous visualiserez mieux sur la figure ci-dessous avec un convertisseur fictif 3 bits :


Cette courbe suppose que le convertisseur est calibré de sorte que l'erreur de décalage (offset) et l'erreur de gain sont annulées (on peut le faire par logiciel).
Ces erreurs sont généralement exprimées en multiple du quantum (notation LSB pour Least Significant Bit dans les documentations, car si 1LSB est la variation du bit de poids faible, elle correspond à la plus petite variation en Volt).

  • L'erreur de non-linéarité différentielle DNL est l'écart entre la largeur réelle du palier et la largeur idéale (de taille égale à la valeur du quantum=1LSB). Si la largeur réelle est égale au quantum, l'erreur DNL est nulle, et toute largeur qui s'écarte du quantum donne lieu à une erreur DNL non nulle. Par exemple pour le code binaire 0b110, le palier est trop large : 1,71LSB, soit une erreur DNL = 1,71 - 1 = 0,71LSB. Pour le code binaire 0b101, le palier est au contraire pas assez large : 0,54LSB, soit une erreur DNL = 0,54 - 1 = -0,46LSB, négative.
  • Pour l'erreur de non-linéarité intégrale (INL), il faut regarder les transitions de code. Soit la transition se produit trop tard (erreur INL positive si la transition se produit à une tension plus grande que prévue), soit elle se produit trop tôt (erreur INL negative si la transition se produit à une tension plus petite que prévue).


Les deux erreurs INL et DNL sont liées. Si, par exemple, le palier pour chacun des codes est toujours trop large, les transitions entre codes vont s'effectuer de plus en plus tard et la courbe de transfert va s'éloigner de plus en plus de la courbe de transfert idéale au fur et à mesure des transitions de code. On peut démontrer que l'erreur INL pour un code donné est l'accumulation des erreurs DNL des codes qui précèdent.

  • Comparer les caractéristiques des convertisseurs A/N d'après leur documentation

Un convertisseur A/N de qualité minimise les erreurs, pardi !
Par exemple, la datasheet du convertisseur MCP3208 donne le tableau suivant :

Nom : MCP3208.jpg
Affichages : 510
Taille : 37,1 Ko
Extrait datasheet Microchip MCP3208

Les erreurs d'offset et de gain peuvent être corrigées par logiciel. Pour les erreurs DNL et INL, elles ne dépassent pas ±1LSB pour le MCP3208-B.
Faites maintenant la comparaison avec le convertisseur A/N du microcontrôleur RP2040 plus haut...
Des erreurs DNL qui restent à ±1LSB en général, sauf pour quatre codes particuliers où l'erreur DNL monte à plus de +7LSB !! Et L'erreur INL qui peut aller de -7LSB à +7LSB, c'est beaucoup d'erreurs !

Regardez ce qui se passe sur ces relevés, les deux autour du code N=1535 :

Nom : test1535-1535.png
Affichages : 510
Taille : 29,2 Ko

Marrant cette dissymétrie autour de la valeur moyenne, non ? (Coup de bol de tomber dessus). Pourtant, on peut l'expliquer :

Nom : test1235-1235.drawio.png
Affichages : 514
Taille : 33,5 Ko

Il y a un long palier pour le code N=1535. Sur la courbe de gauche, on doit se trouver probablement au niveau du point A. On peut avoir quelques fluctuations si la tension est un peu plus faible, mais si on a des fluctuations avec une tension un peu plus grande, on reste sur le palier avec des codes bloqués à N=1535.
Sur la courbe de droite, on se trouve au niveau du point B, on voit des fluctuations avec des tensions un peu plus grande, mais si on a des fluctuations avec une tension un peu plus faible, on reste sur le palier avec des codes bloqués à N=1535.
Si j'avais pu tomber sur la configuration où la tension serait entre A et B vers le milieu du palier, j'aurais certainement eu encore moins de fluctuations. CQFD.

  • Des codes manquants ?

À ce niveau d'erreurs, il peut se produire des phénomènes comme des « codes manquants » :


On voit sur la figure ci-dessus la transition qui fait passer du code 0b100 (4 en décimal) à 0b110 (6 en décimal), il manque le code 0b101 (5 en décimal), comme si la largeur du palier pour ce code était nulle. Les codes manquants sont typiquement les conséquences d'erreurs importantes de non-linéarité.

  • Conclusion

Quand je suis sur le code N=512, je suis sans doute sur un palier très large (DNL > 9LSB). Dans cette zone, la tension peut fluctuer de plusieurs fois le quantum, le code reste bloqué à N=512, c'est pour ça qu'il y a très peu de fluctuations. Il y a probablement aussi des codes manquants autour de cette valeur. Le convertisseur Microchip MCP3208 offre une garantie avec la mention No missing codes, ce n'est pas le cas du convertisseur du microcontrôleur RP2040.

En dehors de ces pics sur l'erreur DNL, les erreurs INL sont aussi élevées. Pour 400<N<500, INL=-2 à -3LSB, avec un saut pour 512<N<600 où INL=+6 à +7LSB, donc des erreurs sur les transitions de code.

7LSB = 7 x quantum = 7 x 3,3/212 = 5,6 mV.

Une erreur de 6-7 mV peut sembler faible, mais attention quand même... Un capteur de température analogique de sensibilité 10 mV/°C et vous générez près de 1°C d'écart rien que sur l'erreur de non-linéarité (erreur de non-linéarité à laquelle il faut rajouter au moins des erreurs de gain ou d'offset si on ne prend pas de précautions, et on rajoutera à cela des erreurs qui ne sont pas inhérentes au convertisseur : alimentation, bruit, etc.).

Donc... Le convertisseur A/N de la Rapsberry Pi Pico est de qualité suffisante dans la majorité des cas (il a une bonne résolution), mais il a des défauts structurels et présente des erreurs de non-linéarité qui sont quantifiées. Ces erreurs ne sont pas forcément gênantes, mais elles ne sont pas négligeables non plus puisque j'arrive à en voir les effets avec un simple potentiomètre tourné à la main. Pour certaines applications, des convertisseurs A/N externes de bonne facture, avec la garantie No missing codes, comme le MCP3208 de Microchip sont recommandés.

--------------------
À lire sur les erreurs de non-linéarité des convertisseurs A/N :

Envoyer le billet « [Raspberry Pi Pico][SDK C/C++] Le convertisseur analogique-numérique : erreurs DNL et INL - Partie 2/2 » dans le blog Viadeo Envoyer le billet « [Raspberry Pi Pico][SDK C/C++] Le convertisseur analogique-numérique : erreurs DNL et INL - Partie 2/2 » dans le blog Twitter Envoyer le billet « [Raspberry Pi Pico][SDK C/C++] Le convertisseur analogique-numérique : erreurs DNL et INL - Partie 2/2 » dans le blog Google Envoyer le billet « [Raspberry Pi Pico][SDK C/C++] Le convertisseur analogique-numérique : erreurs DNL et INL - Partie 2/2 » dans le blog Facebook Envoyer le billet « [Raspberry Pi Pico][SDK C/C++] Le convertisseur analogique-numérique : erreurs DNL et INL - Partie 2/2 » dans le blog Digg Envoyer le billet « [Raspberry Pi Pico][SDK C/C++] Le convertisseur analogique-numérique : erreurs DNL et INL - Partie 2/2 » dans le blog Delicious Envoyer le billet « [Raspberry Pi Pico][SDK C/C++] Le convertisseur analogique-numérique : erreurs DNL et INL - Partie 2/2 » dans le blog MySpace Envoyer le billet « [Raspberry Pi Pico][SDK C/C++] Le convertisseur analogique-numérique : erreurs DNL et INL - Partie 2/2 » dans le blog Yahoo

Commentaires

  1. Avatar de Jules34
    • |
    • permalink
    Merci pour cette suite ! Il me semble que le pico 2 a corrigé ce défaut dans l'ADC.
  2. Avatar de f-leb
    • |
    • permalink
    Citation Envoyé par Jules34
    [...]Il me semble que le pico 2 a corrigé ce défaut dans l'ADC.
    Bien vu ! La datasheet du microcontrôleur RP2350 du Pico 2 le mentionne bien (à la page 1063) :
    12.4.1. Changes from RP2040

    • Removed spikes in differential nonlinearity at codes 0x200, 0x600, 0xa00 and 0xe00...
    Le Pico 2 est sorti l'année dernière, je n'ai pas trop de retard

    Merci Jules34