Reverse-engineering d’une alimentation numérique et contrôle avec bash

Magazine
Marque
Hackable
Numéro
32
Mois de parution
janvier 2020
Spécialité(s)


Résumé

Le marché propose de nos jours des alimentations de laboratoire aux caractéristiques très intéressantes : compactes, puissantes, programmables... Conçues et fabriquées en Chine, évidemment, elles sont économiques et très peu concernées par les standards ou les protocoles, contrairement aux équipements professionnels des grandes marques, chers, mais relativement ouverts. Cet article va examiner un modèle particulier que vous risquez de retrouver sous une forme ou une autre. Ses protocoles ont pu être documentés, grâce aux efforts de la communauté des bricoleurs, ce qui rend cet appareil encore plus utile et très facile à programmer !


Body

Les habitués commencent à connaître le refrain. On trouve un truc intéressant sur un magasin en ligne, on le commande, on le reçoit et tout bascule. En l’occurrence, il s'agit de pentodes venant de Moldavie, plus précisément des 1Ж29Б-В de fabrication soviétique, vieilles d'environ 30 ans. Elles m'ont semblé intéressantes, car c'est une conception relativement récente miniature, avec une consommation plus faible et une fréquence de fonctionnement plus élevée que les tubes classiques (surtout utilisés en audio). Mais surtout, l'anode n'a besoin « que » de 60 V...

1. Alimentation de laboratoire : analogique ou numérique ?

C'est toujours mieux que les 200 V requis par les doubles triodes miniatures 6Н21Б que j'avais aussi trouvé, bien je n'aie pas envie de jouer avec de telles tensions. Et aussi, il est plus facile de trouver des alimentations de laboratoire délivrant seulement 60 V à un prix abordable. Au-delà de cette tension, soit on a recours au bricolage, soit on casse la tirelire pour trouver de l'équipement très spécialisé.

J'aurais aussi pu me fabriquer une alimentation capable de fournir 60 V, mais le temps et les composants auraient coûté plus qu'une alimentation déjà disponible dans le commerce. Je prends mon temps pour chaque projet et on n’en serait toujours pas sorti, si j’avais dû réinventer la roue encore une fois ! Au bout d’un moment, il faut arrêter de faire des sous-sous-sous-projets et passer à l’action. D’autant plus que les prix ont incroyablement chuté ces dernières années (la qualité aussi) et dans un laboratoire, rien ne vaut un appareil qui fonctionne, qui obéit au doigt et à l'œil, qui est à peu près calibré et qui permet de travailler tout de suite. Ce n’est pas un luxe, mais un investissement !

C'est là que la question cruciale se pose : dois-je choisir une alimentation à contrôle analogique ou numérique ?

  • Les alimentations analogiques (que leur affichage soit à aiguille ou à segments numériques) sont délicieusement simples : on tourne un bouton pour le courant, un autre bouton pour la tension, et c'est bon. Évidemment, la précision (et parfois la stabilité) peuvent laisser à désirer et on peut s'offrir le luxe d'une alimentation avec deux boutons pour chaque réglage : le réglage grossier et le réglage fin. Cependant, à l'exception de certaines alimentations industrielles avec une entrée analogique 0-10 V, il n'est généralement pas possible de les piloter avec un appareil extérieur.
  • Les alimentations numériques, au contraire, obligent à appuyer sur plein de boutons. Et puisque les économies l'obligent souvent, le clavier est assez petit (NDLR : sans parler du Rigol DP832, dont le clavier circulaire est une horreur en termes d'ergonomie [1]), les fonctions sont souvent multiplexées, donc il faut réfléchir à plusieurs manipulations séquentielles pour effectuer le moindre réglage. Par contre, on dispose de fonctionnalités supplémentaires, comme des mémoires et le réglage est précis : pour obtenir 12,34 V, on entre directement la valeur, sans avoir à triturer le bouton de réglage analogique ou corriger la dérive (les échauffements internes peuvent parfois dérégler le régulateur des modèles les plus économiques). Et surtout : tous les réglages et les mesures sont disponibles à l'extérieur, si le modèle le permet. D'ailleurs, l'appareil peut aussi remplir d'autres fonctions annexes comme par exemple devenir un convertisseur numérique analogique de puissance (mais lent) ou un convertisseur analogique numérique (comme un multimètre). Des configurations plus sophistiquées permettent d'élaborer des bancs de mesure informatisés, reléguant le multimètre au banc des gadgets.

Rigol dp832 0

NDLR : Le DP832 de Rigol est très appréciable en termes de fonctionnalités, mais j'aimerais bien savoir qui, chez ce fabricant, s'est dit qu'un pavé numérique circulaire était une bonne idée...

Chaque approche a ses avantages et ses inconvénients, comme pour les oscilloscopes : chacun a son domaine d'utilisation approprié.

  • Par exemple, si on veut augmenter doucement la tension de sortie pour voir comment réagit un appareil et explorer ses réactions à la main, une alimentation analogique convient pour les premiers tests, puisqu'il suffit de tourner un bouton. C'est rapide, intuitif et ne requiert aucune préparation.
  • Par contre, ce n'est plus réaliste s'il faut répéter cette opération à l'identique de nombreuses fois : c'est là qu'il faut automatiser et une alimentation numérique trouve tout son intérêt, car elle peut être contrôlée de l'extérieur par un système programmable (au hasard : un ordinateur sous GNU/Linux ?).

En pratique, les deux types d'appareils sont complémentaires. C'est mon expérience avec les oscilloscopes : je commence souvent par « dégrossir » ou explorer le problème à la main avec un modèle analogique, afin d'affiner les paramètres à observer. Le phosphore de l'écran réagit bien plus vite qu'un oscilloscope numérique de base et laisse passer moins d'indices utiles à la trappe.

Ensuite, l'oscilloscope numérique peut être utilisé plus précisément, sans risque d'erreurs dues à l'aliasing par exemple, et on peut capturer et analyser une trace unique qui a été fixée dans le temps, puis exporter le tracé sur un ordinateur...

Par le même raisonnement, c'est un avantage de disposer des deux types d'alimentations, car on peut directement faire ce qu'on veut en appuyant sur le moins de boutons possible, en choisissant le meilleur appareil pour chaque cas.

2. AX-6002P

Ne disposant pas encore d'alimentation numérique et désirant réaliser des tests automatiques, j'ai donc choisi une petite alimentation qui atteint justement 60 V (61 V en pratique) sous 2,1 ampères (soit plus de 120 W à pleine puissance de réserve !), ce qui est largement suffisant pour la plupart des circuits à tester.

La plupart des nouvelles alimentations de laboratoire utilisent un bloc à découpage au lieu d'un transformateur classique, ce qui les rend plus compactes. Elles réagissent plus vite aux changements de charge, elles sont plus légères et elles ont un meilleur rapport puissance-prix, à condition de tolérer une légère ondulation à haute fréquence pour les modèles économiques. Les modèles de luxe disposent aussi d'une post-régulation linéaire pour gommer les petits défauts du hachage.

Dans cette histoire, j'ai trouvé l'AX-6002P de AXIOMET (une marque que je ne connaissais pas) sur Internet en Pologne à un prix à peine plus élevé qu'une alimentation classique comparable. Probablement aussi parce que la compagnie a sorti un modèle supérieur, l'AX-6003P [2], qui remplace l'AX-6002P dans son magasin, et les stocks ont peut-être été liquidés. L'absence de documentation en ligne concernant l'AX-6002P est triste, mais la documentation papier fournie devrait normalement faire l'affaire.

 M7 7046

Fig. 1 : L'AX-6002P prend peu de place sur l'étagère du laboratoire, entre les fréquencemètres et les autres alimentations.

Le format de l'appareil permet de le caser partout (voir la figure 1) et de disposer de juste assez de fonctions supplémentaires par rapport aux modèles classiques, comme les mémoires de paramètres : l'appui sur un des quatre boutons dédiés reconfigure l'appareil immédiatement. Je ne saurai jamais comment accéder à la cinquième mémoire (il y a 5 LED), mais peu importe, car la fonction est rarement utilisée, tout comme le bouton de verrouillage. En tout cas, c'est clairement un système bâti autour d'un microcontrôleur, vive l'intégration !

J'aurais préféré un clavier numérique pour rentrer les valeurs directement. Un unique bouton rotatif numérique permet d'incrémenter ou décrémenter un des chiffres de la valeur, ce qui prend un peu plus de temps... Le processus de sélection du chiffre est pénible, avec une temporisation courte pour basculer entre la sélection du mode (courant ou tension), et il n'y a qu'un bouton rotatif partagé par les deux réglages. Un deuxième bouton rotatif et un sélecteur mécanique pour indiquer la décimale à modifier auraient été excellents ! Mais comme on dit, on a ce qu'on paie...

L'interface n'est pas au niveau d'une alimentation professionnelle, c'est vrai, et je n'aurais pas dit non à un appareil de plus haut niveau, même d'occasion. L'interface de son successeur, l'AX-6003P, semble avoir été améliorée, mais l'appareil est plus puissant et plus cher. Utiliserais-je un jour tout son potentiel ? J'ai rarement besoin de 180 W dans mes circuits et j'ai déjà une alimentation fournissant 18 V sous 10 A...

Au final, le prix de l'AX6002P est attractif, je me retrouve à l'utiliser aussi souvent que les autres et surtout, je l'avais achetée pour la contrôler avec ma linuxette...

3. Communication

Ce modèle est livré avec deux connecteurs en face arrière : une DB9 pour le port série et un USB-B. Je n'ai pas vérifié si le port série était fonctionnel et j'ai tout de suite branché un câble USB. Je suppose que le microcontrôleur communique simplement par un port série asynchrone et qu'un simple pont série/USB ajoute l'autre port.

Après la connexion du câble USB sur mon ordinateur, l'alimentation émet un bip et dmesg retourne ces informations :

[1069116.978946] usb 2-1.3: new full-speed USB device number 28 using ehci-pci
[1069117.058694] usb 2-1.3: New USB device found, idVendor=03eb, idProduct=3301
[1069117.058708] usb 2-1.3: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[1069117.058714] usb 2-1.3: Product: Standard USB Hub
[1069117.061972] hub 2-1.3:1.0: USB hub found
[1069117.062213] hub 2-1.3:1.0: 4 ports detected
[1069117.348953] usb 2-1.3.2: new full-speed USB device number 29 using ehci-pci
[1069117.461864] usb 2-1.3.2: New USB device found, idVendor=0416, idProduct=5011
[1069117.461878] usb 2-1.3.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[1069117.461884] usb 2-1.3.2: Product: USB Virtual COM
[1069117.461889] usb 2-1.3.2: Manufacturer: USB Vir
[1069117.461894] usb 2-1.3.2: SerialNumber: NT2009101400
[1069117.465957] cdc_acm 2-1.3.2:1.0: ttyACM3: USB ACM device

L'appareil est ainsi reconnu et accessible sur /dev/ttyACM3. Si j’avais été responsable du développement, j’aurais poussé le vice jusqu’à changer l’idProduct à 6002, mais on n’est pas à ça près.

 M7 7049 crop

Fig. 2 : Une page de la documentation papier contient les premiers indices permettant de deviner le protocole de communication.

La documentation (figure 2) est très sommaire et indique que le protocole matériel utilisé est 8N1 à 9600 bauds, ce qui se traduit ainsi dans le petit script serial9600.sh :

#!/bin/bash
#1 start, 8 data, 1 stop, no parity

TTY=/dev/ttyACM3
stty 9600 cs8 raw -echo -echoe -echonl -echoprt -echoctl -echoke -parenb -F $TTY

Évidemment, il ne faut pas oublier de changer la variable $TTY si la valeur ne correspond pas à l'assignation de votre système d'exploitation.

D'autre part, la suite des manipulations sur le port série doit être effectuée avec le compte root, ou bien votre compte doit être ajouté au groupe concerné. Un certain DB me souffle qu'il est même possible d'ajouter un fichier dans /etc/rules.d pour ajuster les permissions et créer un lien symbolique /dev/ttyALIM automatiquement sur la base du SerialNumber (voir les détails dans [1]). Cela évite de vérifier si le périphérique est ttyACM0 ou ttyACM3, mais a-t-on vraiment besoin d'un tel luxe quand on peut juste taper su ?

Par contre, la notice n’indique pas du tout le protocole logiciel...

4. Jeu de pistes

Maintenant que la communication est établie, quel langage doit-on utiliser pour lui parler ? La documentation n'offre aucune information et le logiciel fourni est absolument inutile, puisque tournant uniquement sous Windows. On apprend juste que certains fichiers ont été créés en 2012 (ce qui donne une idée de la technologie employée) et je n'ai pas envie d'installer le logiciel, même « juste pour voir » (j’ai déjà endommagé des systèmes d’exploitation pour moins que ça). Certains bricoleurs le feraient pour ensuite extraire les messages avec un analyseur de protocole, mais je n'aime ni l'USB ni Windows et je ne dispose d'aucun outil approprié. L'enquête prend un nouveau tournant...

Cherchons alors du côté du constructeur. AXIOMET dispose d'un site web multilingue, mais il ne propose plus l'AX-6002P, comme indiqué plus haut. Cependant, l'AX-6003P [2] est présenté et la documentation est disponible en PDF [3], faisons l'hypothèse que les deux modèles sont très proches et que le dernier né hérite des caractéristiques du modèle que j'utilise.

En cliquant sur le lien, on obtient un fichier PDF nommé INSTR_AX-3003P EN.pdf dont le titre est « AX-3003P AX-6003P Use of Operation Manual ». Comme pour mon modèle, les informations fournies sont pleines de vide :

9. Remote Control
9.1.
With the remote control function provided, this series power supply can communicate with PC by USB interface and enable all the panel operations by series port software.

(Je ne prendrai même pas la peine de traduire ce chapitre). Cependant, dans la colonne de droite, on trouve un nouvel indice :

Interface:USB interface, SCPI commands provided

5. SCPI : Standard Commands for Programmable Instruments

Mais qu'est-ce que ce SCPI ? Une visite du côté de chez Wikipedia s'impose [4] et on y apprend alors l'histoire de la norme et une base de la syntaxe. Pour résumer, ce sont des commandes et des réponses au format ASCII brut, donc faciles à lire et écrire à la main.

Denis Bodor a également parlé de SCPI dans ce magazine [1], mais j'ai raté cette piste, car le terme SCPI n'était pas dans le titre et je désire me passer de Python et de librairies externes.

Wikipedia pointe aussi vers le SPCI Consortium qui publie gratuitement le document « SCPI-1999 Specification » [5], un fichier PDF de 4 volumes étalés sur 819 pages. J'y découvre que la commande de base minimale est l'identification, qui s'écrit simplement *IDN?. Je tente donc d'envoyer cette commande :

echo "*IDN?" > $TTY

Mais je ne reçois aucune réponse. En fouillant et en essayant différentes options, je découvre que le protocole de l'alimentation n'obéit pas strictement à la spécification SCPI, qui dicte que les commandes sont terminées par \n ou \r\n. Il faut ajouter l'option -n pour empêcher echo d'envoyer un caractère de fin de ligne, et la magie opère enfin !

Donc, dans un terminal, j'envoie la commande :

echo -n "*IDN?" > $TTY

Et dans un autre terminal, je lance od pour afficher chaque octet reçu :

[root@localhost yg]# od -An -v -w1 -t c /dev/ttyACM3
   K
   O
   R
   A
   D
   K
   A
   6
   0
   0
   2
   P
   V
   2
   .
   0
  \0

L'enquête avance enfin !

6. KORAD quoi ?

Une nouvelle étape est franchie, mais ce n'est pas encore terminé. Qu'est-ce que ce KORADKA ? Mes recherches sont infructueuses, alors que je croyais que la chaîne d'identification de l'appareil suffirait à lever le mystère. L'ami Google reste circonspect et réservé. À quoi bon alors mettre cette signature ?

Heureusement, Internet ne se limite pas à un moteur de recherche et j'ai réuni les derniers éléments de l'énigme en posant la question à quelques endroits stratégiques, en particulier Hackaday.io [6] et en utilisant d'autres critères de recherche. Par exemple, le bon terme n'est pas KORADKA, mais KORAD : c'est la société chinoise qui a conçu l'appareil et l'a fabriqué et vendu sous son propre nom, ainsi que pour le compte d'AXIOMET.

On a aussi trouvé des produits KORAD distribués et rebrandés par Tenma/Farnell, Stamos, RND, ainsi que Velleman. Je ne retrouve pas le LABPS3005D aujourd'hui au catalogue de ce dernier, mais le modèle LABPS3005DN ressemble étrangement au KA-3005P. Il lui manque le port série et les mémoires, ce serait une version réduite pour poches étroites, mais toujours aussi utile et utilisable.

On trouve le site de KORAD à http://www.koradtechnology.com/, mais encore une fois, à part quelques grosses archives de logiciels à installer sous Windows, impossible d'obtenir la moindre information sur le protocole. On y trouve aussi [7] la version 2018 du manuel d'utilisateur au format PDF, similaire à ce qui a été photocopié par AXIOMET et livré avec mon appareil. Mais cette fois-ci, la page 14 indique :

Functionality check
Run this query command via the terminal application such as MTTTY (Multi-threaded TTY).
*IDN?
This should return the identification information:
Manufacturer, model name, software version.
KORAD KA3003P Vx.xx

Voici enfin la ligne qui manquait à ma version papier antérieure sur la figure 2 ! Le code *IDN? a probablement été supprimé par un traducteur qui aurait pris ces caractères pour une erreur. Le protocole SCPI n'est même plus évoqué, peut-être suite à des plaintes pour non-conformité...

Le modèle KA-3005P (le petit frère qui fournit plus de courant, mais seulement 30 V) a été présenté dans deux vidéos de EEVblog sur YouTube [8] [9], peu de temps après sa sortie en 2012. L'une d'elles dédie 24 minutes à démonter et analyser la conception et le fonctionnement de l'appareil. Comme d'habitude, les explications de Dave Jones sont très intéressantes ! On y apprend les surprenantes astuces de fabrication, comme l'étrange convertisseur numérique analogique discret...

Avec stupeur, je m'aperçois aussi que cette famille est en fait une alimentation linéaire optimisée et non une alimentation à découpage... Cela explique pourquoi on entend bien la vibration à 50 Hz du transformateur, qui a été placé de manière stratégique. La mise sous tension fait un bruit typique de circuit électromagnétique que l'on branche sur le secteur.

Le gros radiateur de mes autres alimentations de laboratoire a été remplacé ici par un assemblage astucieux de refroidissement actif, le microprocesseur ajustant directement la vitesse du ventilateur selon la lecture du courant, au lieu de juste se fier à une simple sonde de température qui réagira toujours trop tard. Il faudra cependant toujours faire très attention à garder les entrées d'aération libres.

Les commentaires sous la vidéo sont aussi très informatifs, on y apprend que les microcontrôleurs (dont les marquages ont été effacés) sont un Nuvoton/Tang M054LAN pour le processeur central (un ARM Cortex-M0 à 48 mHz) ainsi qu'un NUC120LD1BN pour le processeur de communication (c'est celui qui nous intéresse ici). Il n'y a donc pas de « pont USB » !

Détail notable : la conception est économique, mais pas bâclée, car tout est « flottant ». La platine de communication est opto-isolée, donc aucun risque de griller son PC en se connectant dessus.

7. Et le protocole est...

Les membres du forum EEVBblog sont allés plus loin que Dave et ont investi du temps pour extraire les informations qui nous intéressent, parfois en capturant les messages du logiciel de KORAD alors qu'il tournait sous Windows dans une machine virtuelle. Cette technique puissante a permis de découvrir des commandes non documentées.

Sur une des pages du forum [10], on apprend ainsi que l'interface externe se désactive au bout de 20 secondes sans communication. De plus, toutes les commandes se passent de caractères de fin de ligne, contrairement à la spécification SCPI. En l'absence de délimitation explicite d'une fin de commande, nous devons faire attention aux temporisations et envoyer une commande d'un seul coup, car toute attente terminera l'interprétation du message, qui sera considéré comme tronqué par l'alimentation. Ainsi, on ne peut pas envoyer les commandes au clavier, caractère par caractère, car le délai est trop long. Cela explique les nombreux échecs de personnes utilisant un émulateur de terminal. Au lieu de cela, nous devons envoyer explicitement des commandes entières avec echo -n "message" par exemple.

Le protocole n'est donc pas des plus fiables et les utilisateurs recommandent d'utiliser une boucle pour envoyer la commande jusqu'à ce que la lecture de la sortie corresponde à la valeur demandée. La commande STATUS? pose aussi son lot de problèmes, mais on peut s'en passer dans un premier temps.

Utile

Dans un message du 10 avril 2013, l'utilisateur jav nous livre des informations très utiles, suite à son analyse des messages dans une VM. Le logiciel de KORAD utilise aussi un autre protocole particulier, à base de messages binaires au format fixe de 24 octets, toujours envoyés à 9600 bauds, 8N1. Le détail est un peu compliqué, mais très puissant si on a la patience de coder ou le besoin de manipulations complexes, sur deux canaux simultanés :

0xAA 0x20 vh1 vl1 ah1 al1 vh2 vl2 ah2 al2 0 0 0 0 1 out 1 0 prot mode 0 0 0 crc

Tension sortie 1 = (vh1*256 + vl1) / 100.

Courant sortie 1 = (ah1*256 + al1) / 1000.

Tension sortie 2 = (vh2*256 + vl2) / 100.

Courant sortie 2 = (ah2*256 + al2) / 1000.

out = 1 pour activer la sortie, 0 pour couper.

prot = type de protection (1 quand limite du courant atteinte).

mode = (pour les modèles à 2 canaux)

  • 0 = les 2 canaux sont indépendants.
  • 1 = canaux en série.
  • 2 = canaux en parallèle.
  • 3 = canaux symétriques.

crc = CRC-8 de tous les octets précédents avec seed=0.

Le message de réponse (du même format) contient les valeurs mesurées en sortie, à la place des consignes données. Nous utiliserons ici le protocole textuel, car il est plus simple et plus rapide à mettre en œuvre.

D'expérimentations en découvertes, le vocabulaire du protocole a été collecté et des scripts en Ruby et Python ont vu le jour. Un autre commentaire confirme bien qu'AXIOMET vendait un KA-6002P depuis 2013.

Le vocabulaire a été complété par les informations d'un manuel fourni par Velleman, et synthétisé sur une page du wiki du projet Sigrok [11]. Cette page nous apprend que certaines versions du firmware ont un bug de buffer : la lecture du courant avec ISET1? renvoie un sixième caractère superflu, qui semble venir de la réponse à *IDN? s'il a été traité avant. Comment a-t-on pu laisser passer un tel bug ? Les versions suivantes du micrologiciel semblent avoir résolu ce petit souci.

Les commandes peuvent être classées en deux catégories, selon qu'une réponse est attendue. C'est indiqué par le caractère qui suit le premier mot : un point d'interrogation va lire une valeur dans l'appareil et elle sera retournée sous forme de texte ASCII (toujours sans terminateur).

Les ordres connus sont les suivants :

  • VSET1:12.34 ordonne que la tension de sortie du canal 1 soit mise à 12,34 V. Si un deuxième canal est disponible, on enverra aussi l'ordre VSET2:.
  • ISET1:0.125 ordonne de limiter le courant à 0,125 A. Utilisez ISET2: pour un modèle disposant d'un deuxième canal.
  • OUT1 active la sortie. Ne pas oublier d’attendre une fraction de seconde avant d'envoyer la commande suivante.
  • OUT0 désactive la sortie.
  • OVP1 active l'« Over Voltage Protection » L'alimentation se déconnectera alors si la tension de sortie dépasse la consigne.
  • OVP0 désactive la protection de survoltage.
  • OCP1 active l'« Over Current Protection ». Cela désactive la sortie si le courant dépasse la limite, au lieu de juste limiter en chutant la tension.
  • OCP0 désactive la susdite protection de surcourant.
  • TRACKx pour les modèles à deux canaux :
    • TRACK0 canaux indépendants.
    • TRACK1 canaux en série.
    • TRACK2 canaux en parallèle.
  • RCLx configure la sortie avec la mémoire n° x (de 1 à 5), ne pas oublier d’activer la sortie.
  • SAVx sauve les paramètres actuels dans la mémoire n°x (de 1 à 5).

Les paramètres peuvent être lus avec ces requêtes :

  • VSET1? demande la tension de consigne. Cela renvoie 5 caractères, par exemple "12.34".
  • VOUT1? demande la tension mesurée à la sortie, renvoie "12.34".
  • ISET1? demande le courant de consigne, renvoie "0.123" (attention au bug du caractère ajouté).
  • IOUT1? demande le courant mesuré à la sortie, renvoie "0.123" pour 123 mA.
  • STATUS? renvoie un octet qui est une combinaison booléenne de plusieurs drapeaux : --   0x01 => 1:CV, 0:CC (à vérifier). --   0x20 => 1 si OVP et/ou OCP sont activés. --   0x40 => 1 si sortie active.D'autres bits sont définis par SCPI, mais les réalisations « varient »...

Certaines de ces commandes sont valides pour tous les modèles, d'autres ciblent des modèles particuliers, à vous d'essayer !

8. Et maintenant, scriptons !

Le vocabulaire a donc été réalisé en Ruby [12], Python [13][14], TCL, C++ [15], C# [16], et j'en passe. On peut même se passer de langage puisque bash suffit ! En effet, sachant déjà qu'il faut envoyer le message d'un seul coup, on peut utiliser la commande echo -n à loisir. Par exemple, pour mettre la tension de sortie à 12,34 V, il suffit de taper ceci :

echo -n "VSET1:05.00" > $TTY

Le mérite d'utiliser > ou >> n'est pas clair, l'un comme l'autre semblent fonctionner tout aussi bien. Le format numérique semble relativement flexible, mais sujet à de possibles confusions, donc la syntaxe complète (5 caractères avec un point au milieu) semble s'imposer. Pour mettre la tension à 5 V, on peut aussi bien écrire directement 5, ou 05, ou 5.0, ou 5.00, ou 05.0, en faisant bien attention de vérifier la sortie.

À partir de là, il est aisé d'écrire un petit script qui va commander une rampe : une simple boucle utilisant la sortie du programme seq suffit. L'option -w assure que tous les nombres ont le même nombre de chiffres.

# petit script qui génère
# une rampe de 0 à 60V

echo -n "VSET1:0" > $TTY ; sleep .1
echo -n "OUT1"    > $TTY ; sleep .1
for i in $(seq -w 0 60)
do
  echo ${i}V
  echo -n "VSET1:"$i > $TTY
  sleep .1
done

Dans la même veine, nous pouvons aussi écrire :

# un autre script qui génère
# une rampe de 0 à 1A

echo -n "ISET1:0" > $TTY ; sleep .1
echo -n "OUT1"    > $TTY ; sleep .1
for i in $(seq -w 0 999)
do
  echo "0,"${i}"A"
  echo -n "ISET1:0."$i >> $TTY
  sleep .1
done

La commande sleep contrôle la vitesse de variation, mais aussi assure que la commande a bien été reçue, tout en laissant un peu de temps à l'électronique du régulateur pour stabiliser la tension. Ce dernier point dépend du courant et de la tension demandés, ainsi que de la charge en sortie.

Il semble qu'un délai minimum de 0,02 seconde soit nécessaire pour assurer le fonctionnement, d'une part parce que sleep peut dépendre de la période du "tick" de l'OS (50 Hz était une valeur courante à une époque) et on ne connaît pas la durée du timeout du contrôleur de l'alimentation. D'autre part, le condensateur de filtrage peut mettre plus ou moins de temps à se (re)charger selon le courant tiré en sortie et selon le délai d’arrivée de la phase du secteur. En pratique, une attente de 50 ms à 100 ms convient, ce qui permet d'envoyer environ 10 commandes par seconde.

Bash peut effectuer certains traitements de chaînes de caractères, mais le code devient très vite inintelligible. Je me permets donc ici de ne pas traiter la lecture des valeurs, bien que cela soit parfaitement possible : il suffit de lire $TTY dans un autre terminal (avec od ou tout autre programme). Cependant, bash travaille avec des lignes clairement délimitées, alors que KORAD envoie juste un paquet d'octets délimités par le temps, ce que bash ne gère pas simplement. Des trucs et astuces existent, mais cela complique la structure des scripts.

9. Formatage avec bash

Rapidement, une autre complication apparaît : le programme seq est pratique, mais la gestion des nombres fractionnaires est difficile. On arrive vite à des bricolages avec sed et le script devient illisible... C'est là que les langages de programmation « plus propres » montrent leur intérêt et les librairies toutes faites (comme celles de Sigrok) vous seront utiles. J'ai même codé un petit fichier en C pour convertir les formats...

Cependant, pour du « prototypage rapide » et pour des cas simples, bash reste un choix intéressant. De plus, on peut très bien contourner le problème des nombres fractionnaires en travaillant avec des entiers représentant une sous-unité : le courant est facile à traiter en milliampères (cette alimentation a le bon goût d'avoir dix fois plus de résolution que mes autres alimentations analogiques) et la tension en centivolts (une unité peu courante, il est vrai...). Il suffit de s'assurer que les valeurs à traiter sont ensuite représentées sur quatre caractères et une fonction simple va ajouter ou retirer un point au bon endroit.

La suppression est simple :

[yg@localhost] echo "12.34" | sed 's/[.]//'
1234

Dans ce cas, le bug de la commande ISET1 n'est pas géré et il faudra enlever le caractère superflu à la main. En tout cas, cela fonctionne assez bien pour le courant comme pour la tension, si on fait attention à conserver les zéros du début.

L'ajout est plus délicat, mais consiste à prendre chaque caractère et à les réordonner un peu, tout en mettant un autre caractère au milieu. L'expression régulière est très redondante et il faut deux versions, selon que nous envoyons une tension ou un courant :

[yg@localhost] echo "1234V" | sed 's/^\([0-9]\)\([0-9]\)\([0-9]\)\([0-9]\)/\1\2.\3\4/'
12.34V
[yg@localhost] echo "1337A" | sed 's/^\([0-9]\)\([0-9]\)\([0-9]\)\([0-9]\)/\1.\2\3\4/'
1.373A

Évidemment, on peut se simplifier la vie en créant des fonctions, à utiliser juste avant d'envoyer la valeur sur le port série.

function convertAmperes () {
 echo -n $1  | sed 's/^\([0-9]\)\([0-9]\)\([0-9]\)\([0-9]\)/\1.\2\3\4/'
}

function convertVolts () {
 echo -n $1  | sed 's/^\([0-9]\)\([0-9]\)\([0-9]\)\([0-9]\)/\1\2.\3\4/'
}

[yg@localhost] convertVolts "1234"
12.34[yg@localhost]
[yg@localhost] echo -n "VSET1:"$( convertVolts "1234" )
VSET1:12.34[yg@localhost]

Ce n'est pas encore le Pérou, mais cela permet de créer facilement des rampes avec des pas de seulement 10 mV, au lieu d'être contraint aux pas de 1 V moins précis ou à imbriquer des boucles. Par exemple :

for V in $( seq -w 0 6000 ); do
  echo -n "VSET1:"$( convertVolts "$V" ) > $TTY
  sleep .1
done

Et voilà ! À vous de broder, repiquer, tailler, transférer et faire des choses utiles.

Conclusion

On trouve encore des alimentations de la gamme KA de KORAD chez quelques distributeurs, toujours à un prix intéressant. Ce n'est pas ce qui se fait de mieux, mais le rapport qualité/prix en fait un outil très intéressant pour le bricoleur averti. D'autres modèles et d'autres constructeurs lui font concurrence, mais le port USB ainsi que le protocole qui est maintenant public et simple sont un avantage indéniable. Le petit surcoût dû à la communication est rapidement justifié, si vous deviez en avoir besoin. Mais une fois essayé, c’est adopté et il devient vite une solution à la recherche de nouveaux problèmes !

Grâce à cette relative ouverture, nous n'avons pas eu besoin d'installer un langage de script ou de le compléter par diverses bibliothèques externes, à la stabilité probable et nécessitant des rafraîchissements au gré des décisions d'autres personnes que vous. L'appareil est programmé directement, façon « bare metal », comme de vrais hackers, ceux qui n'ont pas envie de revenir tous les deux ans sur leur code à cause de la disparition d'un dépôt Git. Après tout, c'est aussi pour cela que nous faisons de l'électronique : une fois que c'est fait, on peut passer sereinement à autre chose. Vive la pérennité !

Il est donc possible d'interfacer cette famille d'alimentations avec presque n'importe quel langage et plateforme, puisque le port RS232 peut aussi être utilisé par un simple microcontrôleur. Au pire (si le microcontrôleur ne dispose pas d’UART), on peut même émuler le port série, qui est particulièrement lent (seulement 9600 bauds). Les aficionados d'Arduino, Raspberry Pi, Micro:Bit ou autres modules populaires ne sont donc pas exclus ! Le vocabulaire du protocole est facile à réaliser avec n'importe quel langage, il faut juste faire attention aux temporisations (mais un tel appareil n'est pas destiné à des changements à haute fréquence).

La seule précaution que j'envisage serait de surveiller la sortie avec un oscilloscope et/ou un multimètre bien calibrés, car des cas d'overshoot ont été reportés et la stabilité de la référence de tension sur le long terme n'est pas établie. De temps en temps, il est bon de vérifier les valeurs avec un multimètre de confiance. Comme pour tout appareil, d'ailleurs.

Je n'ai abordé que des techniques simples de programmation, car les applications vraiment utiles (telles que celle-ci https://www.youtube.com/watch?v=UGEggdBGoDU) font aussi appel à des périphériques d'entrée et d'autres capteurs. C'est ce que nous verrons dans un article suivant, rendez-vous donc au prochain numéro !

Liens

[1] Bodor, Denis : « Contrôlez votre alimentation de laboratoire avec votre Raspberry Pi » , Hackable n°15 de novembre 2016 : https://connect.ed-diamond.com/Hackable/HK-015/Controlez-votre-alimentation-de-laboratoire-avec-votre-Raspberry-Pi

[2] Fiche produit de l’alimentation de laboratoire AX-6003P chez le distributeur polonais AXIOMET : 
https://axiomet.eu/fr/en/product/axiomet/power-supply/ax-6003p/1656/

[3] Lien vers la documentation PDF de l’AX-6003P : https://axiomet.eu/fr/en/product/ax-6003p/document/528/1656

[4] La page Wikipedia de SCPI 
https://en.wikipedia.org/wiki/Standard_Commands_for_Programmable_Instruments

[5] SPCI Consortium, « SCPI-1999 Specification » : http://www.ivifoundation.org/docs/scpi-99.pdf

[6] Page de discussion sur le sujet de cet article : https://hackaday.io/page/3068-advicesinfos-about-usb-connected

[7] Page de téléchargement des documentations et logiciels gratuits de la société KORAD : http://www.koradtechnology.com/Download.html

[8] Dave Jones, « EEVblog #314 - Korad KA3005P PSU Teardown », 17 juillet 2012 https://www.youtube.com/watch?v=g94mpom2Ahs

[9] Dave Jones, « EEVblog #315 - Korad KA3005P Review/FAIL », 17 juillet 2012 https://www.youtube.com/watch?v=Fya-4mjV4N4

[10] Pages du forum EEVblog discutant des alimentations KORAD : https://www.eevblog.com/forum/testgear/korad-ka3005p-io-commands

[11] Page concernant la famille d’alimentations KA sur le wiki de Sigrok https://sigrok.org/wiki/Korad_KAxxxxP_series

[12] Une réalisation du protocole en Ruby : https://gist.github.com/k-nowicki/5379272

[13] Une réalisation en Python : https://github.com/vb0/korad/blob/master/kcontrol.py

[14] Une autre réalisation en Python : https://github.com/starforgelabs/py-korad-serial

[15] Réalisation en C++ : https://github.com/crapp/labpowerqt/blob/master/src/koradscpi.h

[15] Réalisation en C# : https://github.com/djrecipe/KA3005P

Post-Scriptum

Mais que sont devenues les pentodes dans tout ça ? Elles sont stockées au fond d’une armoire, puisqu’en plus des 60 V requis, il faut d’autres tensions comme 45 V, sans parler des autres contraintes que j’estime trop importantes (ce qui est rare). Et par principe, je n’aime pas un circuit qui chauffe sans rien faire, à moins que ce soit un chauffage. Je reste finalement concentré sur les relais électromécaniques, beaucoup plus simples (a priori) et faciles à alimenter. Mais c’est le sujet d’autres articles encore, à suivre !



Article rédigé par

Par le(s) même(s) auteur(s)

Une (autre) pile matérielle pour le modèle bipilaire

Magazine
Marque
GNU/Linux Magazine
Numéro
271
Mois de parution
septembre 2024
Spécialité(s)
Résumé

Dans les épisodes précédents, le « Single Stack Syndrome » a été décrit et poussé à son paroxysme en essayant (en vain) d’apprendre de nouveaux tours à GCC. Ensuite, après le « quoi », nous avons exploré le « pourquoi » de cette dystopie, tissée tout au long de l’histoire de l’informatique, du côté matériel comme logiciel. Devant une telle débâcle, c’est le moment ou jamais de garder ce qui marche et de faire l’inverse de ce qui ne va pas. Nous allons donc imaginer un « nouveau » type de pile qui pourrait trouver sa place dans de futurs microprocesseurs.

Une histoire des piles et de leur protection

Magazine
Marque
GNU/Linux Magazine
Numéro
270
Mois de parution
juillet 2024
Spécialité(s)
Résumé

Lorsque l’on parle de programmation sécurisée, on pense d’abord à un dépassement d’indice d’un tableau ou à des droits d’accès non respectés, puisque ces aspects sont visibles par le programmeur. Par contre, la pile est sous le contrôle absolu du compilateur et le contrat implicite est que « ça fonctionne » tant que nous le laissons faire son travail, qui est de plus en plus alambiqué. L’article précédent [1] détaillait de façon lovecraftienne les soucis de flexibilité et de sécurité inhérents au modèle de programmation à une seule pile, utilisé par (quasiment) tous les compilateurs actuels. J’ai amalgamé tous ces problèmes dans le terme « Single Stack Syndrome », mais il n’y a pas que le C ou le x86 dans la vie ! Nous pouvons trouver des inspirations dans d’autres langages, d’autres architectures et d’autres ères.

Les « tourments de la monopile », ou le « Single-Stack Syndrome »

Magazine
Marque
GNU/Linux Magazine
Numéro
269
Mois de parution
mai 2024
Spécialité(s)
Résumé

Si vous croyez que le format ASCIIZ (aussi appelé « chaîne de caractères à terminateur nul » à la base du langage C et d’UNIX) est le pire péché originel de l’informatique, accrochez-vous. Il est amplifié par un autre péché bien plus grave, commis au nom du minimalisme, excusé au nom de la compatibilité et perpétué par l’oubli des alternatives. Si vous avez lu l’article de mars 2023 [1] jusqu’au bout, vous avez probablement compris que la plupart des langages de programmation actuels n’utilisent qu’une seule pile. C’est la source de nombreux problèmes (de sûreté, de sécurité, de complexité et bien d’autres) aux origines de failles variées (représentant peut-être un cinquième des CVE) que nous sommes habitués à mitiger, sans les résoudre vraiment. Dans cette première partie lovecraftienne, nous irons jusqu’au fond de l’impasse pour démontrer l’absurdité, les difficultés et les dangers imposés par ce système.

Les derniers articles Premiums

Les derniers articles Premium

Sécurisez vos applications web : comment Symfony vous protège des menaces courantes

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Les frameworks tels que Symfony ont bouleversé le développement web en apportant une structure solide et des outils performants. Malgré ces qualités, nous pouvons découvrir d’innombrables vulnérabilités. Cet article met le doigt sur les failles de sécurité les plus fréquentes qui affectent même les environnements les plus robustes. De l’injection de requêtes à distance à l’exécution de scripts malveillants, découvrez comment ces failles peuvent mettre en péril vos applications et, surtout, comment vous en prémunir.

Bash des temps modernes

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Les scripts Shell, et Bash spécifiquement, demeurent un standard, de facto, de notre industrie. Ils forment un composant primordial de toute distribution Linux, mais c’est aussi un outil de prédilection pour implémenter de nombreuses tâches d’automatisation, en particulier dans le « Cloud », par eux-mêmes ou conjointement à des solutions telles que Ansible. Pour toutes ces raisons et bien d’autres encore, savoir les concevoir de manière robuste et idempotente est crucial.

Présentation de Kafka Connect

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Un cluster Apache Kafka est déjà, à lui seul, une puissante infrastructure pour faire de l’event streaming… Et si nous pouvions, d’un coup de baguette magique, lui permettre de consommer des informations issues de systèmes de données plus traditionnels, tels que les bases de données ? C’est là qu’intervient Kafka Connect, un autre composant de l’écosystème du projet.

Le combo gagnant de la virtualisation : QEMU et KVM

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

C’est un fait : la virtualisation est partout ! Que ce soit pour la flexibilité des systèmes ou bien leur sécurité, l’adoption de la virtualisation augmente dans toutes les organisations depuis des années. Dans cet article, nous allons nous focaliser sur deux technologies : QEMU et KVM. En combinant les deux, il est possible de créer des environnements de virtualisation très robustes.

Les listes de lecture

7 article(s) - ajoutée le 01/07/2020
La SDR permet désormais de toucher du doigt un domaine qui était jusqu'alors inaccessible : la réception et l'interprétation de signaux venus de l'espace. Découvrez ici différentes techniques utilisables, de la plus simple à la plus avancée...
8 article(s) - ajoutée le 01/07/2020
Au-delà de l'aspect nostalgique, le rétrocomputing est l'opportunité unique de renouer avec les concepts de base dans leur plus simple expression. Vous trouverez ici quelques-unes des technologies qui ont fait de l'informatique ce qu'elle est aujourd'hui.
9 article(s) - ajoutée le 01/07/2020
S'initier à la SDR est une activité financièrement très accessible, mais devant l'offre matérielle il est parfois difficile de faire ses premiers pas. Découvrez ici les options à votre disposition et les bases pour aborder cette thématique sereinement.
Voir les 33 listes de lecture

Abonnez-vous maintenant

et profitez de tous les contenus en illimité

Je découvre les offres

Déjà abonné ? Connectez-vous