R2R diy Audio Dac.

Un peu de curiosité : quel rendu sonore peut bien produire un circuit convertisseur audio-numérique de fabrication personnelle.

Mise en garde : pas de débat théorique sur le sujet ici. Ça n'est pas le but. 

J'estime que la bataille en terme de qualité 'pure' sonore est terminée depuis le milieu des années 90. Depuis, les fabricants de matériels ne proposent plus grand chose d'innovant, les fournisseurs de composants n'en faisant pas plus si ce n'est augmenter le nombre de bits et la fréquence de conversion des composants, sans réellement d'intérêt pour le matériel grand public.

Le problème, à mon sens, réside dans le format inchangé du CD audio non tant en terme de résolution qu'en terme de fréquence de mise à disposition des échantillons sonores qui reste 'coincée' à 44,1 KHz, ce qui oblige toujours à la mise en place de filtres à sur-échantillonnage dans le but de faciliter la construction des filtres analogiques de sortie (suppression du bruit d'échantillonnage numérique).

Pour ceux qui souhaiteraient un peu de théorie, visitez les vidéos de JiPi :

Pour améliorer la restitution sonore, les principales sources potentielles de bruit et de distorsion ont depuis longtemps été 'quasi éliminées' :

• Erreur de bruit analogique (qualité des alimentations et de conception des matériels).
• Erreur de quantification des convertisseurs.
• Erreur ou aberrations des filtres à sur-échantillonnage.
• Instabilité des signaux d'horloge.
• etc...

Je ne parlerai pas des tentatives de nouveaux formats de transport de l'information comme le SACD et son flux DSD, et de la technologie Delta-Sigma des convertisseur numériques-analogiques qui, outre le fait d'avoir apporté un semblant de nouveau Graal commercial, dans les fait n'apportait pas vraiment grande révolution dans la restitution sonore si ce n'est un coup de production 10 fois moins élevé que les convertisseurs de type R2R de l'époque, pour le grand bien financier des actionnaires.

Et pour enfoncer le clou, le très ancien convertisseur Phillips TDA1541 demeure une référence en terme de conversion numérique analogique, malgré le (ou à cause du) fait que ce soit un convertisseur de type R2R.

https://tryphonblog.com

Ce TDA 1541 faisait suite au TDA 1540 (14 bits de résolution) :

Image récupérée sur le Web.

De tous les lecteurs CD que j'ai pu tester, je n'en ai gardé que deux. Un CD104 à TDA 1540 :

http://www.lampizator.eu

et un lecteur CD Arcam Delta 70.2 à TDA 1541 de type S1 (une couronne) :

Tout ceci pour en arriver au fait qu'il y a deux façon d'envisager la restitution sonore. Soit par l'aspect technique donc purement objectif, soit pas l'aspect 'plaisir' du rendu donc purement subjectif. A partir du moment ou le taux de distorsion du signal reste dans des proportions raisonnables (inférieur à 1%) et que le rendu est plaisant, j'estime que cela vaut mieux que d'avoir engagé de grosses sommes dans un système techniquement presque parfait mais à l'écoute ennuyeuse, voire pénible.

Le champ d'expérimentation au niveau amateur existe toujours dans le domaine ou cela reste possible bien évidemment. Puisqu'il n'est pas envisageable de façon 'artisanale' (quoi que...) de créer soi-même ses propres circuits intégrés, il reste possible de réaliser des circuits de conversion de type R2R 'à la main', sur circuit imprimé.

C'est sur cette base que Monsieur Vincent Brient à commencé à concevoir il y a quelques années son Totaldac :

Cet appareil est équipé de résistances de très haute précision et de circuits intégrés logiques de base (bien que j'imagine que ce design ait évolué depuis les débuts) afin de recréer le fonctionnement d'un circuit intégré R2R de type TDA1541. Je n'ai hélas jamais pu écouter ce type de machine.

J'aurais pu me lancer dans la réalisation de ce type de DAC mais le temps a passé et je me suis orienté vers d'autres sujets. Jusqu'à ce que je découvre le projet de Dilshan R Jayakody concernant la réalisation d'un DAC 24 bits stéréo à la base pour Raspberry Pi. Ce design est cependant suffisamment flexible pour être utilisé en tant que DAC standard puisqu'il possède une interface I2S, et ressemble fortement au Totaldac si ce n'est que l'ensemble de la logique est contenue dans un CPLD et que les résistances sont de type standard donc d'un coût raisonnable, même en tolérance de 0,1% comme celles que j'ai choisies :

Ce circuit étant libre de droit, et toutes les ressources étant également disponibles sur le dépôt Git du projet, j'ai décidé d'en réaliser un exemplaire. La majorité des composants passifs de ce circuit sont en boitier cms de type 603. D'habitude cela ne me pose pas de problème de souder à la main quelques composants cms en boitier 805 (taille au dessus), mais dans le cas présent, souder au fer standard presque une centaine de boitier 603 me semblait être une 'torture' inutile. Avec le circuit imprimé, j'ai donc aussi demandé la réalisation du pochoir correspondant. Quelques semaines plus tard, j'ai donc reçu de quoi réaliser le montage :

Le circuit imprimé.

Le pochoir correspondant.

La réalisation du circuit s'en trouve grandement facilitée puisqu'en premier lieu il suffit de placer de la pâte à souder sur les plots du circuit imprimé en s'aidant du pochoir. L'opération s'effectue facilement même en n'ayant pas pris le soin de conserver ce pochoir parfaitement plat sur le circuit imprimé :

Cette façon de faire un peu 'cavalière' aura pour effet de déposer un peu trop de pâte sur les pads du CPLD. Je le savais, je savais aussi qu'une petite finition à la tresse à dessoudé aurait réglé le problème. Ce qui fût le cas :

Une fois les composants cms montés, il ne restait plus qu'à placer les quelques composants traversants comme les gros condensateurs de filtrage, les connecteurs et les deux résistances ajustables. A noter que la version des fichiers actuellement disponibles ne correspond pas totalement à l'image que Dilshan R Jayakody a publiée sur son blog puisque les deux condensateurs de sortie de blocage de la composante continue ne sont pas implémentés. Ce qui n'est pas plus mal puisque d'une part il se peut q'ils ne soient pas obligatoirement indispensables puisque souvent les entrées des amplificateurs en sont déjà pourvus, et que d'autre part cela permettra de placer des condensateurs de meilleur qualité pour effectuer des essais au casque par exemple.

Même si l'assemblage de la carte semble s'être bien déroulé, la première mise sous tension est toujours quelque peu angoissante :

Fort heureusement, pas de 'magic smoke' au démarrage. Le CPLD reste froid. Il ne reste plus alors qu'à programmer ce gros circuit pour qu'il réalise la fonction de réception de signal I2S et qu'il envoi directement aux résistances les signaux correspondant. Pour cela il reste encore à connecter le montage à un PC équipé du logiciel Altera (Intel) via l'interface de programmation adéquate :

Une fois la connexion effectuée, il suffit d'installer la version 18.1 du logiciel Quartus Lite puis à lancer la compilation du projet :

La compilation se déroule sans problème et génère le fichier nécessaire à la programmation effective du CPLD. Le 'programme' est écrit en Vérilog et non pas en VHDL dont j'ai plus l'habitude mais comme l'on dit : si vous en connaissez un, vous comprendrez l'autre!

L'ensemble du projet n'utilise que la moitié des ressources logique du CPLD et presque les trois quart de ses pattes. Le composant semble donc adapté à l'application envisagée.

La programmation du composant se déroule, elle aussi, sans difficulté :

Et voilà! Le circuit est 'potentiellement' opérationnel. Il ne reste plus qu'à le connecter à une source I2S et à le brancher sur un amplificateur audio pour en tester le résultat, non sans avoir au préalable réalisé quelques tests aux instruments de mesure sur l'état de ses sorties.

Oui, sauf qu'aux premiers tests, rien ne se passa. Dès le départ j'avais une petite idée sur le problème. L'oscillateur de 50MHz possède un brochage quelque peu étrange. Un peu trop de pâte à souder avait créé une petite connexion parasite. La aussi, un peu de tresse à dessouder a réglé le problème.

Pour effectuer mes tests, il me fallait donc un générateur de bus I2S. L'occasion de ressortir ma carte d'évaluation Wolfson WM8740 :

Je ne sais plus depuis combien de temps je possède cette carte mais cela fait un bon bout de temps. Une bonne vingtaine d'années je pense. Elle a l'avantage de posséder un convertisseur de bus SPDIF vers différentes formats dont l'I2S, grâce à un CS8414. D'ailleurs ce circuit est aujourd'hui obsolète, la date de son datasheet annonce 1998!

Il va sans dire que pour tester un flux SPDIF de type Compact Disc ce récepteur SPDIF convient tout à fait. Le système de test consiste donc en une source SPDIF (une sortie de PC) et le récepteur SPDIF qui envoi directement ses signaux vers la carte DAC R2R. A noter que j'ai du installer deux diodes en série sur chaque signal du bus I2S de façon à ce que leurs niveaux haut passe de 5V à 3,6V. Ce n'est pas les 3,3V imposés par les entrée du CPLD, mais cette légère surtension ne pose pas de problème :

La petite carte en bas à gauche est une carte d'adaptation de tension des signaux. A l'origine, j'avais prévu de m'en servir pour convertir les signaux de 5V en provenance de la carte Wolfson vers les 3,3V des entrées du CPLD. Evidemment, cette carte ne monte pas assez en fréquence et déforme totalement les signaux de données et d'horloge au nouveau bits, d'ou le remplacement par le système de diodes.

J'ai aussi disposé deux gros condensateurs de type MKS de 2,2µF en sortie qui, avec les 560 Ohms de résistance de sortie des AOP, permettent de descendre suffisamment en fréquence pour restituer un signal de bonne qualité.

Evidemment, difficile de rendre compte de la qualité de sortie de ce DAC sans en faire au moins une capture de la sortie audio. Au casque le signal sonore est absolument parfait. Et pourtant nous ne sommes 'qu'en qualité CD', sans le moindre sur-échantillonnage, sans filtre efficace de sortie des harmoniques d'échantillonnage, ni la moindre correction de jitter...

Conclusion (provisoire).  Dans la conclusion de son article, Dilshan R Jayakody indique que son DAC fournit un signal de bonne qualité. Force est de constater qu'effectivement, c'est le cas. Il me reste à effectuer une capture de la sortie de ce DAC, et puis à éventuellement étudier quelques améliorations possibles de la qualité de sortie audio.

Cette petite digression audio-numérique sentait bon le milieu des années 90 ;-)

Interface MIDI / CV-GATE terminée!

Cette fois ça y est, l'interface est enfin finalisée. Il m'a fallu un peu de temps pour peaufiner la programmation du système :

L'interface propose 8 canaux CV-GATE.

Quatre switchs permettent de modifier le comportement de l'interface.

• 1 switch permet la sélection des canaux MIDI bas (1 à 8) ou haut (9 à 16).
• 1 switch permet le basculement du mode monophonique / polyphonique. On passe alors de 8 canaux MIDI, à 8 notes possibles sur le canal 1 ou 9.
• 1 switch permet le mode DUAL. La capacité de l'interface en terme de canaux MIDI est alors divisée par 2 car chaque sortie est doublée. 
• 1 switch permet de modifier le comportement des sorties CV, soit en mode note-ON / note-OFF, soit en mode trigger.

La linéarité de l'interface est très bonne. Pour l'instant elle est à la norme 5V/octave mais peut être câblée en 10V/octave au besoin, avec étendue d'un clavier 61 notes standard.

Le développement de cette interface n'a pas été très facile. Passer d'une idée simple à la base à une solution opérationnelle et fiable tout en sélectionnant au mieux les composants afin de garder un design simple et efficace n'est en fait, pas aussi simple que cela!

De plus, pour ce genre de réalisation, il faut aussi mettre en place tout un environnement de test sans lequel il est impossible de progresser sérieusement dans le développement et éventuellement le débug. Cela faisait très longtemps que je n'avais pas programmé d'interface sous windows. J'ai développé sous Dev C++ :

Cet environnement est largement obsolète mais pour développer du natif windows cela reste une des solutions les plus simples face à l'usine à gaz que sont les outils de développement microsoft, et au moins cela m'a permis d'élaborer mon environnement de test 'assez' rapidement:

Je me demande si l’environnement de programmation JAVA ne serait pas plus adapté à ce type d'application. J'ai installé avec succès l'environnement Eclipse de développement Java en version 64 bits...

Retro-computing : imprimante MINITEX

Histoire d'évoquer la contribution française à la grande histoire de l'informatique.

Aujourd'hui : l'imprimante Minitel Minitex n°11571

Je ne sais pas s'il s'agi d'un objet rare mais avec le n° de série 11571, j'imagine que non.
Je n'en avais jamais eu entre les mains, et n'ai trouvé que très peu d'informations sur cet appareil sur le Web.

A la mise sous tension, le voyant rouge clignotait et rien ne semblait se passer, notamment la séquence d'initialisation de la machine. Un démontage s'imposait :

La machine est construite en tout métal. La mécanique est du type matricielle à 7 aiguilles, simple mais efficace et certainement très robuste. La translation de la tête se fait par arbre rainuré et non pas par un traditionnel système d'entrainement par moteur pas à pas et poulie/courroie. Le papier utilisé est de type perforé, 11cm de large. Je n'en possède pas, hélas. Il sera difficile d'effectuer les tests d'impression.

APPEL au don : si quelqu'un possède quelques ramettes de papier pour ce type d'imprimante, je suis preneur.

La mécanique est contrôlée par une carte processeur, et pas n'importe quoi :

Simplement une carte à processeur 6502, celui-là même qui équipait l'Apple 2 sorti en 1977. La majorité des composants sont estampillés 1987, soit juste 10 ans après la sortie de son vénérable aîné.

Dans l'idée, la carte est simple et comporte :

• Un processeur R6502.
• Un circuit de gestion de liaison série R6551 (liaison péri-informatique).
• Un circuit d'entrées/sorties parallèle R6522 (gestion du déplacement de la tête et des aiguilles plus les boutons de la face avant me semble-t-il).
• Une ROM programme.
• Une RAM.

Les trois principaux circuits sont de marque Rockwell, à l'époque ou ce constructeur fabriquait des circuits intégrés. La RAM est marquée MHS, une co-entreprise de Harris Corp et de notre gloire nationale de l'époque : Matra. L'aventure aura duré 10 ans, de 1979 à 1989 (Wikipédia), la décennie de 'gloire' de l'industrie française du semi-conducteur. Je possède toujours un 80C31 de ce fabriquant, un micro-contrôleur très utilisé à l'époque.

Je ne parle pas de ST que notre grand inspirateur d'alors, Juppé premier ministre, avait voulu brader en 1996 pour un franc symbolique à l'entreprise Daewoo L'entreprise était en faillite, certes, mais quand même! Aujourd'hui ST est bien présent notamment dans l'industrie des micro-contrôleurs sur base ARM. J'utilise d'ailleurs un de ces circuits dans mon Hub/Merge MIDI/USB.

Au fait, que reste-t-il de Matra-Harris, près de Nantes? En gros, ceci :

Image prise sur le site de Google. Donc, je ne connais pas sa date de publication. Il faudrait que j'ailles me rendre compte sur place...

Revenons à notre imprimante. Une fois retirés la mécanique et la carte électronique, je peux accéder à l'alimentation et effectuer les premiers tests :

Facile : l'alimentation ne fournit plus le +12V.

Donc, changement du régulateur par un modèle récupéré sur une carte électronique et réputé fonctionnel :

Trop facile : après le remplacement du régulateur défectueux, cela ne fonctionne toujours pas!!!
Moi qui m'attendais à une réparation de type rapide, j'en suis pour mes frais. Par contre le radiateur est très chaud. Court-circuit en sortie du 12V?

Yessss :

Un des deux gros condensateurs de filtrage. 10 000µF en 16V joliment en court-circuit. 1 Ohm au Fluke 289.  Evidemment, un condensateur de 16V pour une tension de sortie de 12V, la marge est un peu faible. Et vu la surface des films nécessaire pour atteindre une telle capacité, l'isolant très fin entre les deux surfaces constituant le condensateur s'est forcément détérioré, d'ou le court-circuit.

Bien que la machine soit construite comme un tank (selon la formule consacrée), le choix de ce type de condensateur était à mon avis mal approprié. Je l'ai d'ailleurs remplacé par un modèle de 3 000µF mais en 35V (je n'en avais pas de tension de service plus faible dans les grosses capacités).

L'imprimante est maintenant fonctionnelle. En tout cas la séquence d’initialisation se déroule normalement et la LED rouge s'éteint. Je ne peux hélas pas la tester définitivement étant donné que je ne possède pas de papier pour cela.

Ce type d'imprimante est censé imprimer ce qu'est capable d'afficher un minitel. Si quelque lecteur possède des informations à ce sujet, qu'il n'hésite pas à me les communiquer. Ce type d'imprimante est très utile pour la réalisation d'impressions de journalisation...

Fin de confinement, et fin des tests du convertisseur CV/GATE

ou, comme l'aurait dit Claude Nougaro "Un nouveau départ, solide comme un roc"...

Rappel : après avoir développé une petite application windows pour me permettre de relever automatiquement les valeurs précises à envoyer au DAC en fonction des notes reçues par le port MIDI, j'ai pu finaliser le fonctionnement basic du logiciel de ce convertisseur et relever non seulement les tensions générées mais aussi les mesures effectuées sur de vrais modules VCO.

Pour se faire, j'ai utilisé un générateur de signal fraîchement acquis, qui possède aussi une entrée de comptage, le FY6900 dont j'ai détaillé la modification de l'alimentation pour de meilleurs performances de l'appareil :

Les deux modules VCO utilisés sont tout d'abord le Pico VCO2 de Erica Synths :

ainsi que le module ElectroSmith 3340 :

Afin de piloter le tout, j'ai utilisé un convertisseur USB/MIDI-MERGE que j'ai aussi créé  :

Équipé de tout ces appareil, j'ai d'abord relevé les tensions générées par le convertisseur MIDI/CV. Pour se faire j'ai utilisé un petit utilitaire de clavier virtuel sous windows :

La première chose à faire fût de relever les différentes tensions obtenues en 'envoyant' les notes DO des 5 octaves. Le relevé des mesure s'est avéré excellent :

Fort de ces résultats je me suis donc attelé au test 'in situe' avec les deux modules VCOs. Je dois dire qu'avant de m'appliquer à relever les valeurs des fréquences produites par ces deux VCOs, j'avais quelques difficultés à déterminer les octaves avec le module d'ElectroSmith. Il me semblait totalement désaccordé alors que le module PICO VCO lui, semblait réagir correctement.

Passage aux mesures donc :

Et le verdict est tombé :

J'avoue ne pas comprendre réellement le fonctionnement du module ElectroSmith. Le pourcentage d'erreur max relevé est totalement délirant, et correspond (hélas) à ce que j'entendais au casque.

Si le module Erica reste précis avec une erreur maximale inférieur à 2% même après 24h de fonctionnement, le module ElectroSmith délire complètement et semble présenter une échelle plus logarithmique que linéaire!

J'ai respecté la procédure de calibration comme indiqué dans la documentation du sous-module ES-3340 :

Bien que possédant un potentiomètre interne de réglage du 1V/oct je n'ai jamais été en mesure de rendre le module 3340 un tant soit peu linéaire. Pire, il arrive parfois que le résultat des mesures ne corresponde pas au sens auquel je tourne les potentiomètres de la face avant du 3340. Incompréhensible, en tournant à fond à droite les potentiomètres du 3340, j'obtiens en sortie une fréquence de plus de 98kHz!!! Oui oui, presque 100kHz! Je me demande à quoi cela peut bien servir même cela semble correct à la vue des spec. du fabriquant :

Alors évidemment, j'ai acquis le 3340 d'ElectroSmith sous forme de kit. Peut-être ais-je 'raté' quelque chose? En fait il n'y a que les connecteurs à souder soi-même. Toute l'électronique est fournie sous la forme d'un module en cms pré-assemblé. Je n'ai donc rien 'bricolé' autour de la partie analogique :

Après plusieurs vérifications, je n'ai pas vu d'erreur de ma part. Le module semble fonctionner correctement. J'ai donc de forts doutes sur la conception de ce module. En tout cas, le résultat est trop aberrant pour que ce soit mon convertisseur MIDI/CV-Gate qui soit en cause, surtout si je considère que l'ensemble fonctionne parfaitement avec le module PICO VCO2.

Si 'certains d'entre vous' avez constaté ce type de comportement avec le module ElectroSmith, n'hésitez pas à m'en faire part!

Pour l'heure, je considère mon système fiable et vais pouvoir continuer le développement du logiciel afin de rendre le montage le plus versatile possible. Quatre switchs vont permettre de sélectionner les modes de fonctionnement de ce convertisseur MIDI/CV-Gate....

[UPDATE 02 JUIN 2020] Je me suis penché sur le cas de ce VCO 3340 d'Electrosmyth pour finir par me rendre compte qu'il y avait un problème au niveau de l'embase de commande V/OCT. Après avoir identifié et corrigé le problème, le module s'est mis à fonctionner normalement. Cela m'a permis d'effectuer de nouveaux tests de précision, après avoir respecté la procédure d'étalonnage. J'arrive aux résultats suivants :

Ce qui correspond tout de même à des valeurs plus crédibles que précédemment. Malgré plusieurs itérations de la procédure d'étalonnage, je ne suis pas parvenu à améliorer la précision qui a tendance à se dégrader dans les fréquences graves, mais tout en restant cependant dans des marges acceptables.
Ce module est un peu moins précis que le VCO2 d'Erica Synth mais offre plus de possibilités de modulation.

Une petite démo du sujet peut se trouver sur Youtube :

CV/GATE : procédure détalonnage.

Après un certain nombre d'heures de programmation et de tests, me voici arrivé à une application fonctionnelle et fiable :

Il s'agit donc de la version je pense définitive (avec le multimètre utilisé) de ma petite application de calibration du DAC utilisé dans mon convertisseur midi vers CV/GATE. J'ai décrit les outils utilisés pour le développement de cet utilitaire dans mon article précédent.

Le fichier créé par cet utilitaire contient simplement une variable de type tableau, directement intégrable dans le source de l'application de gestion de ce convertisseur et correspondant aux codes nécessaires pour générer les 61 notes d'un clavier standard au format 1V/Octave avec la meilleur précision possible, typiquement aux alentours de 0,3% max, hors dérive due à la température ambiante :

Arriver à ce résultat n'a pas été particulièrement simple parce que, même si le multimètre envoi automatiquement ses données et que donc cela pourrait être perçu de prime abord comme un avantage, sous windows cela n'en est pas un. Tout simplement parce que cela signifie de l'asynchronisme. Et l'asynchronisme n'est pas trivial à gérer dans un environnement multitâche comme windows sans utiliser l'artillerie lourde (je ne détaille pas, ça n'est pas le sujet).

Je pense être en mesure d'améliorer le fonctionnement de cet utilitaire grâce à l'utilisation du multimètre Fluke 289 qui lui, renvoi sa mesure suite à une demande. Pour cela, j'ai passé commande de l'adaptateur série 'qui va bien' :

Avec ce Fluke, il me sera alors possible de gérer l'ensemble de la procédure dans la même fonction et non pas de devoir passer par une variable de transfert, avec tous les problèmes que cela suppose d'accès à un objet unique par deux processus!

Je comprends mieux maintenant la raison pour laquelle il arrive parfois qu'avec tel ou tel petit outil, l'utilitaire de configuration semble aussi archaïque, mal commode et parfois plante. Si l'on ne veut pas perdre tous les bénéfices financiers de la vente d'un petit appareil générant une marge faible, et que donc il faut impérativement produire l'utilitaire en question en 15 jours par le stagiaire n'y connaissant pas grand chose à la base, et bien on aboutit irrémédiablement à ce type d'outil.

windows n'est tout simplement pas fait pour ça.
Ce 'système' impose un nombre d'heures de développement largement trop élevé par rapport aux besoins 'amateurs' ou semi-pro.
Dans ce contexte, comme pourrait le dire Feydeau, 'windows c'est beau, ça semble puissant, ça fait plein de choses, mais ça ne sert à rien!'

Hélas bill gates n'a jamais eu l'humour inoffensif d'un Monsieur Bouzin!

Corona : activités d'éveil n°7, progression sur le convertisseur CV/GATE

Allez, on y croit : dernière semaine de confinement généralisé. Serait-ce le bout du tunnel?

En attendant, la semaine passée a été consacrée à la mise en place d'une procédure d’étalonnage du convertisseur CV/GATE 8 voies développé durant l'année 2019 :

L'image ci-dessus représente la dernière version de la carte développée. Je ne l'ai pas encore montée. Elle fait suite à deux autres prototypes dont celui qui sert actuellement de test pour la mise en place de la procédure d'étalonnage. La première version ressemblait à ceci :

J'ai développé une deuxième version de cette carte pour corriger une petite erreur de câblage au niveau d'un des régulateurs de tension. C'est cette deuxième version que j'ai utilisé cette dernière semaine pour développer le banc de test et d'étalonnage :

La dernière version du convertisseur CV/GATE propose un circuit imprimé plus petit, une amélioration  du schéma général pour une meilleur stabilité, et une rationalisation du fonctionnement.

Bien que les deux prototypes fonctionnent correctement, avec une linéarité tout à fait satisfaisante, la stratégie mise en place pour la calibration, elle, ne l'est pas. J'ai utilisé le principe de la fonction mathématique pour produire la valeur numérique à destination du DAC, correspondant à la note reçue par le biais de l'interface MIDI.

Le problème, est que d'une part la recherche de la bonne fonction a été très laborieuse puisque qu'à chaque fois il me fallait modifier le programme du processeur du montage, relever à la main les valeurs retournées par le DAC et vérifier la linéarité sur une feuille excel. D'un point de vue amateur, cela peut s'accepter, mais de façon plus sérieuse, cela fait quand même bricolage et surtout est trop laborieusement reproductible.

D'autre part le convertisseur utilisé ne propose pas une fonction de transfert stable sur l'étendue de sa conversion et je soupçonne que certaines caractéristiques de cette fonction dépendent aussi de chaque DAC.

J'ai donc décidé de modifier d'approche par l'utilisation d'une méthode plus 'brute force'. A savoir tout simplement l'envoi au DAC de toutes les valeurs possibles et sélectionner celles correspondant aux tensions voulues. Après tout, un clavier de piano ne comporte 'que' 81 touches donc au maximum 81 valeurs à retenir. En mettant en place une procédure automatique et rapide cela me permettra de calibrer chaque carte au mieux.

Le principe  : l'utilisation d'un PC pour gérer l'envoi des données au DAC et récupérer les tensions correspondantes. Le programme PC sélectionne automatiquement les valeurs correspondant aux notes d'un clavier standard et fabrique un fichier de correspondance à intégrer au source qui sera transféré dans le processeur de la carte. Avec de la 'chance', il ne sera peut-être pas nécessaire de répéter l'opération pour chaque carte si la dispersion du DAC n'est pas trop importante.

Le matériel :  pour l'envoi des données au DAC, et sachant que celui-ci fonctionne en bus SPI, le plus simple a été l'utilisation du Bus Pirate développé par Ian Lesnet (http://dangerousprototypes.com/). Connecté en USB sur le PC, il présente un port série standard et une configuration par simple protocole texte. J'utilise la version 3.6 :

La réception des valeurs de mesure se fait par l'intermédiaire d'un multimètre 22000 points classique et 'assez' précis de type UNI-T UT61E :

Publicité gratuite.

Ce multimètre possède l'énorme avantage de posséder une interface série opto-isolée disponible sur prise RS232C, un adaptateur USB s'avère donc nécessaire. J'utilise ceci :

Ça n'est pas l'adaptateur le moins cher, mais au moins il est correctement construit, possède les bons connecteurs ainsi que des LEDs d'indication pour l'émission et la réception.

Le multimètre utilisé envoi de façon automatique une chaîne de caractères dans un format spécifique qui ne pose aucun problème de décodage. Inutile donc de lui demander l'envoi d'une valeur, il le fait tout seul. Ce qui n'est visiblement pas le cas du FLUKE 289 que je possède par ailleurs :

Publicité gratuite.

Ce multimètre est très précis et possède aussi une interface série au protocole de type texte. Je suis bien tenté de commander son interface série pour l'utiliser dans mon banc d'étalonnage.

Le logiciel : avant toute chose, notez que je ressent une ABSOLUE AVERSION envers l'entreprise microsoft. Tant d'un point de vue technique que philosophique. Mon avis ne sera donc pas objectif. Ceci écrit, j'ai donc (à contre cœur vous l'aurez compris) décidé de développer une petite application sous windows (je ne mets jamais de majuscules aux produits microsoft).

Heureusement, j'avais développé une petite application de ce type il y a une vingtaine d'années, à l'époque ou il fallait tester le système d'exploitation parce que la simple ouverture de port se faisait différemment selon que l'on était sous windows 98, NT ou XP !!! Je m'attendais donc à ce que cela ne soit pas simple, même pour une toute petite application.

J'ai une fois de plus tenté 'visual studio' dernière version. Après avoir téléchargé 2Go correspondant à 8Go installés sur le disque, j'ai de nouveau constaté l’absolu archaïsme de ce système de développement (je me place au niveau d'une personne attendant un réel 'service' de la part de l'outil et non pas au niveau d'un développeur qui ne connaîtra que cette médiocrité de développement durant toute sa vie de développeur et qui donc y sera habitué, le trouvera hyper adapté et considérera que tout le reste n'est que distraction). J'ai donc opté pour une solution beaucoup plus adaptée mais totalement obsolète : WxDev-C++, 550Mo sur le disque, WxWidget compris. Au moins cette solution me permet de développer simplement une application de type boîte de dialogue comme ceci :

Je n'ai pas encore totalement terminé cet utilitaire. La sélection des bonnes valeurs correspondant aux notes d'un clavier n'est pas encore implémentée mais le plus difficile est fait : je récupère la tension générée par toutes les valeurs envoyées au DAC.

L'utilisation des ports de com n'est évidemment pas aisée sous windows. Rien n'a changé depuis mes développements précédents il y a presque 20 ans. Je n'avais pas envie d'utiliser les pthreads pour gérer la réception des trames séries : trop galère et compliqué à utiliser et bien trop consommateur de temps pour une si petite application. J'ai donc utilisé le déclenchement par timers pour lire à intervalle régulier la disponibilité, ou pas, de caractères reçus sur les ports. Et de toute façon cela tombe bien, WxDev-C++ ne possède pas de façon native la gestion des pthreads.

A noter que j'ai aussi tenté Code::Block et les WxWidgets dernière version et ai rapidement laissé tomber l'affaire. les aides à la création des fenêtres sont archaïques, incommodes et, la cerise qui fait le bonheur, plantent systématiquement : inutilisable pour ce besoin. Par contre, j'ai dernièrement utilisé Code::Block pour du développement sur Z80, cela fonctionne très bien.

Je me suis souvent dit que je passerais moins de temps à développer un petit ordinateur adapté à mes besoins plutôt qu'à essayer de faire faire quelque chose à windows. C'est d'ailleurs depuis toujours la politique de microsoft, fournir un outil de développement qui n'en est pas un et imposer des méthodes les plus éloignées possibles des besoins et capacité des gens 'normaux' pour les évincer de facto de la course à la concurrence.

C'est sur ce principe que ce sont construits les empires informatiques américains d'aujourd'hui, microsoft, google et autres : développer à outrance une technologie archaïque et improductive qui impose une organisation sociétale adaptée, propre à fournir une très grande quantité de personnes stupidement intelligentes et bien formées au sujet. Hormis la Chine dont le système de direction à permis d'imposer le changement sociétal nécessaire, pour le reste de la planète, c'est l'échec et la course perpétuelle et destructrice à l’échalote de la "startup nation" !

Bon, ça n'est pas le tout de divaguer en propos philosophiques, mais il me faut maintenant terminer cette application!