pery95

Ampli audio DIY

 Audio philie  Commentaires fermés sur Ampli audio DIY
Mai 022014
 

Amplificateur audio « do it yourself ».

 

Je suis de formation électronicien d’origine; dans ma jeunesse (oui, oui, ça remonte un peu…), j’ai beaucoup « bricolé »,  du matériel de sonorisation (boites de mixage, amplificateurs, enceintes pour les fêtes entre copains) et du matériel hi-Fi (amplificateurs, enceintes); c’est ainsi que j’ai fabriqué des amplificateurs à tubes et à transistors; pour ces derniers, je m’étais orienté sur des montages fonctionnant en classe A, popularisés par Jean Hiraga dans La Revue de l’Audiophile; j’en ai notamment fabriqués deux qui ont été revendus ensuite; un premier, plutôt modèle prototype, le second, une bête en rack 6U, bi-mono, dissipateur passif central…

Plus récemment, dans le cadre de l’évolution de mon home-cinéma, j’ai voulu me réorienter vers des amplis de ma propre fabrication. ATTENTION, c’est une question de plaisir et de satisfaction personnelle et en aucun cas une question d’économie; en effet actuellement, il y a beaucoup moins de distributeurs de composants électroniques qu’il y a 30 ou 40 ans et les coûts s’en ressentent (composants passifs et actifs, réalisation du circuit imprimé, dissipateur avec son usinage, boitier avec son usinage…). De plus, faire ses amplis home-cinéma suppose, bien que ce ne soit pas une obligation absolue, de s’orienter sur un pré-ampli audio-vidéo-HC, ce qui grève encore un peu le budget.

J’ai d’abord tenté un premier essai avec des modules de chez Trypath, qui ont une bonne réputation en audiophilie; j’ai acheté sur internet un module et une alimentation à découpage (vous cherchez « hifimediy » et vous trouvez facilement le site, il y a aussi des résultat intéressant avec « hifi diy » ou « audio diy »); j’ai monté le tout sur une planche et direction un essai en vrai grandeur : résultats très convaincants sur le plan audio, le son est fin, sec et détaillé dans le médium et l’aigu, l’aisance est là ans le grave (pour info, l’alimentation est un modèle de 350W pour un module de 2x80W et je possède des enceintes Klipsch). Hélas, trois fois hélas, j’ai poussé la chose dans ses derniers retranchements (oui oui le niveau sonore était plutôt conséquent) et « boum », étincelles et fumée; pourtant le minuscule dissipateur n’était même pas très chaud et nous n’étions même pas le 14 jullet ! Je pense qu’il s’agit d’un défaut de fabrication et je retenterais sûrement ultérieurement l’expérience car j’ai vraiment été agréablement surpris de la qualité audio.

Entre-temps, sur « TheBé », j’ai trouvé plusieurs vendeurs (chinois ou US) qui proposent des matériels en kit ou montés (circuits imprimés nus avec schéma et part-list, circuits imprimés + kit de composants, circuits câblés); on trouve notamment des « répliques » d’amplis mythiques, Hiraga 20W classe A, NAIM, QUAD 405… Il y a du choix et il faut faire judicieusement ses courses (et tenir compte des aspects-coûts « mécaniques » : boitier et dissipateur).

Je suis en train de câbler des modules et j’ai sous le coude un kit CI + composants classe A et un jeu de CI nus classe A d’une autre conception.

Mise à jour avril 2017 : j’ai continué les essais avec des modules en classe D toujours pour l’instant avec des modules trouvés sur « TheBé »; essai donc avec une base de TDA7498. Le résultat est plutôt très bon sur le plan musicalité avec 2x80W sur 8ohms, 1 module tout petit et une alim de 350W qui prend 8 fois plus de place ! Je vais monter en bricolage un multicanaux (7 canaux) qui va remplacer mon Denon 3805 (dont je n’utilise plus que la partie amplificateur de puissance). Entre temps, j’ai découvert ClassDAudio et ses modules qui semblent faire merveille (les forums audio sont assez dithyrambiques); petit soucis, ce matériel vient des USA et le port voire les frais de douane en plus grèvent sérieusement le prix; j’ai donc cherché des « équivalents »; il s’avère qu’au moins une partie de ces modules sont à base de circuit de commande IRS2092 suivi d’un couple de MosFet (en deux boitier ou en une seul boitier à 5 pattes). Je me suis donc mis à la recherche de produits similaires : la base est le concept IRAUDAMP7  d’International Rectifier qui se décline en 4 série différentes L15, L20, L25 et L30 avec des tensions d’alimentations différentes et à l’arrivée des puissance différentes (la recherche sur « TheBé » se fait par exemple avec [IRS2092 L15] et on trouve rapidement tous ces modules); le prix est évidemment très intéressant et ce sera mon essai suivant, sachant que je ne suis pas encore décidé sur l’alimentation, SMPS ou linéaire standard. Attention 1 avec les TDA7498 : les modules sont annoncés pour une alimentation de 32V. la fiche technique trouvée sur le net donne une valeur typique de 36V. et une valeur maxi de 39V.; j’ai donc tenté le 36V. et c’est pas bon du tout !!! le module part en fumée en quelques secondes. En revanche, à 32V., il fonctionne parfaitement et même à forte puissance, ne chauffe que très peu (on est en HiFi ou Home-cinéma, pas en sono). Attention 2, à priori, il semble nécessaire de placer en sortie de ces modules une protection contre le courant continu en cas de Pb sur les modules (le CC est destructeur pour les enceintes). Pour l’instant, je ne l’ai pas encore fait mais c’est prévu sur mon montage prototype multicanaux, j’ai acheté (toujours au même endroit !) les petits circuits qui vont bien, qui plus est adaptés aux modules TDA7498 qui fonctionnent en pont dès l’origine (d’où une bonne puissance avec seulement une alimentation mono-tension de 32V.)

Mise à jour mai 2018 : bon, le projet n’a pas réellement avancé; un support est prêt mais rien n’est monté et câblé; en parallèle, la retraite approchant, je suis lancé sur une création d’entreprise pour fabriquer et vendre deux produits : un préamplificateur à tubes pour platine vinyl et des amplis en classe D (le second produit sera sans doute testé par mes soins en version multicanaux pour ma propre installation de home-cinéma mais je prévois quand même de finaliser le premier proto).

Pour ces nouveaux produits, cela fera l’objet d’articles spécifiques mais seulement sans doute début 2019.

Je continuerais d’enrichir cet article au fur et à mesure de mes essais (c’est un peu lent car je ne fais pas que ça).

 

Arduino et prises commandées (3 – protocole de transmission)

 Arduino philie  Commentaires fermés sur Arduino et prises commandées (3 – protocole de transmission)
Mai 012014
 

Arduino

Commande de prises électriques, éclairages…

par transmission 2.4GHz

Protocole de transmission

 

A l’issue de tous ces choix de base et quel que soit le mode de fonctionnement retenu, il est nécessaire de définir la façon dont les informations circulent.

Prérequis :

  • différencier les différents modules avec des plages d’adresses suffisamment étendues (prise, éclairage, capteur de température, thermostat, alarme…).
  • permettre d’identifier le type de commande (programmation, commande directe, demande de statut…),
  • en cas de programmation pour les A/M des prises, permettre plusieurs programmations quotidiennes et/ou hebdomadaires,
  • en cas de programmation pour les éclairages, permettre de commander soit des niveaux directs, soit des plages – temps de variation,
  • … et j’en ai surement oublié,
  • tenir compte du fait que les modules 2.4GHz (nRf24l01) ne permettent de transférer que 32 octets, il faut donc être économe dans l’utilisation de ces octets ou utiliser d’autres astuces. NB : cette valeur de 1 à 32 octets, c’est le Mirf.payload que l’on initialise dans le programme.

J’avais donc opté pour le découpage suivant :

  • Octet 1 (numéroté 0 dans la programmation) : 1ère partie de l’adresse du module ; permet surtout de différencier les types d’interfaces ; de 1 à 255 (on évite d’utiliser la valeur 0) ;
  • Octet 2 : 2ème partie de l’adresse du module ; permet d’identifier le module dans son type ; de 1 à 255 (on évite d’utiliser la valeur 0) ;
  • Octet 3 : type de commande (programmation, commande directe, lecture du statut du module, reset des plages horaires des modules, remise à l’heure, si nécessaire, des horloges des modules… entre l’utilisation des bits à l’unité et les combinaisons possibles, il reste beaucoup de fonctions imaginables) ;
  • Octet 4 : état de la commande directe (0 ou 1 pour une prise, de 0 à 255 pour une lampe) ;
  • Octet 5 : utilisé pour la commande de lampe, sur commande directe, de 1 à 255 pour une variation sur le nombre de secondes indiquées ;

Sur cette première base, il s’avère que 5 octets sont utilisés, il en restait donc 27 de disponibles.

NB : en s’inspirant d’une structure telle que celle du X10 (16 codes maison x 16 codes modules), on aura pu se limiter à un byte d’adresse, soit « seulement » 256 modules ; cela m’a paru trop limitatif et je suis donc resté sur 2 octets pour l’adresse.

Tableau récap pour les 5 premiers octets :

Octet[0]

Byte 7

Byte 6

Byte 5

Byte 4

Byte 3

Byte 2

Byte 1

Byte 0

Utilisation

0

0

0

0

0

0

0

0

Inutilisé

x

x

x

x

x

x

x

x

Adresse première partie

 

Octet[1]

Byte 7

Byte 6

Byte 5

Byte 4

Byte 3

Byte 2

Byte 1

Byte 0

Utilisation

0

0

0

0

0

0

0

0

Inutilisé

x

x

x

x

x

x

x

x

Adresse deuxième partie

Si par exemple, on décide que les prises sont à l’adresse haute 1, le premier module prise portera l’adresse basse 1 et donc l’adresse globale 11 en hexa (soit 00000001 00000001 en binaire).

Si les éclairages sont à l’adresse haute 2, le premier module éclairage sera à l’adresse globale 21…

Octet[2]

Byte 7

Byte 6

Byte 5

Byte 4

Byte 3

Byte 2

Byte 1

Byte 0

Action

0

0

0

0

0

0

0

0

Aucune

0

0

0

0

0

0

0

1

Programmation

0

0

0

0

0

0

1

0

Commande directe

0

0

0

0

0

1

0

0

Lecture statut

x

x

x

x

x

0

0

0

Option à venir

1

0

0

0

0

0

0

0

Remise à l’heure des RTC des modules

1

1

1

1

1

1

1

1

Remise à zéro (notamment les plages horaires programmées pour les modules prises)

 

Octet[3]

Byte 7

Byte 6

Byte 5

Byte 4

Byte 3

Byte 2

Byte 1

Byte 0

Action

0

0

0

0

0

0

0

0

Commande A/M

(prise)

0

0

0

0

0

0

0

1

x

x

x

x

x

x

x

x

Niveau d’éclairement

(lampe)

A noter que la commande de volet – écran, peut se faire sans problème avec une fonction A/M sous réserve d’avoir un relais mécanique en sortie.

Octet[4]

Byte 7

Byte 6

Byte 5

Byte 4

Byte 3

Byte 2

Byte 1

Byte 0

Action

x

x

x

x

x

x

x

x

Temps de variation lumineuse en secondes

(entre valeur actuelle et valeur demandée dans l’octet[3])

Si ma prise est à l’adresse basse 1 et que je veux lui envoyer un ordre direct de marche, je vais émettre 01h, 01h, 02h, 01h, 00h.

Pour les prises, j’étais parti sur 2 ou 3 programmation quotidiennes possibles mais je me suis rendu compte que je bloquais la possibilité d’avoir des programmations différentes, par exemple, pour la semaine et le WE.

J’étais donc reparti sur le fait de prévoir le maximum de possibilités en utilisant les 27 octets restants ; néanmoins, il me fallait un octet pour définir le ou les jour(s) de la semaine et 4 octets (compactables en 3 avec du concaténage) pour définir une heure de début (marche) et une heure de fin (arrêt).

J’avais donc redéfini le mode de programmation des heures, découpés de la façon suivante :

  • le premier octet contient un numéro de jour ou une combinaison : 1 octet = 8 bits, 1 semaine = 7 jours, ce qui permet toutes les combinaisons possibles, y compris des commandes répétitives, la valeur 0 permet au module de comprendre qu’il ne gère pas les octets suivants,
  • le second octet contient la valeur de l’heure pour l’allumage,
  • le troisième octet contient la valeur des minutes pour l’allumage,
  • le quatrième octet contient la valeur de l’heure pour l’extinction,
  • le cinquième octet contient la valeur des minutes pour l’extinction.

Et là, je vous entends me dire : reste 27 octets, 5 octets par commande, cela ne fait plus que 5 programmations possibles, c’est pas assez… Et je suis d’accord !

Donc, il faut non pas envoyer toutes les plages horaires lors d’une transmission mais envoyer les plages horaires à raison de 1 par transmission et les mémoriser dans le module ; il faut donc faire attention dans ce cas de ne pas « exploser » la capacité mémoire du module et de savoir mémoriser les données ; dans ce but, on va utiliser la partie EEPROM du module Arduino NANO qui fait 512 octets (pour la version ATmega168) et 1ko (pour la version ATmega368) ; du coup, on se retrouve avec la possibilité de programmer 512 / 5 = 102 pages horaires.

Dans la mesure où il sera intéressant de pouvoir récupérer ces info (avec le mode « lecture du statut ») et de les afficher, il faudra être raisonnable. De mon point de vue, 4 à 5 programmations différentes par semaine doit représenter la majorité des besoins.

Tableau récap pour les octets correspondants aux jours et heures:

Octet[5]

Byte 7

Byte 6

Byte 5

Byte 4

Byte 3

Byte 2

Byte 1

Byte 0

Jour

0

0

0

0

0

0

0

0

Inutilisé

0

0

0

0

0

0

1

0

Lundi

0

0

0

0

0

1

0

0

Mardi

0

0

0

0

1

0

0

0

Mercredi

1

0

0

0

0

0

0

0

Dimanche

1

1

0

0

0

0

0

0

Samedi + dimanche

1

1

1

1

1

1

1

0

Semaine complète

0

0

1

1

1

1

1

0

Du lundi au vendredi

 

Octet[6]

Byte 7

Byte 6

Byte 5

Byte 4

Byte 3

Byte 2

Byte 1

Byte 0

Heure de début

0

0

0

0

0

0

0

0

00hxx

0

0

0

0

0

0

0

1

01hxx

0

0

0

0

0

0

1

0

02hxx

0

0

0

0

0

1

0

0

04hxx

0

0

0

0

0

0

1

0

0

1

0

18hxx

0

0

0

..

0

0

0

1

0

1

1

1

23hxx

 

Octet[7]

Byte 7

Byte 6

Byte 5

Byte 4

Byte 3

Byte 2

Byte 1

Byte 0

Minutes de début

0

0

0

0

0

0

0

0

xxh00

0

0

0

0

0

0

0

1

xxh01

0

0

0

0

0

0

1

0

xxh02

0

0

0

0

0

1

0

0

xxh04

0

0

0

0

1

0

1

0

1

0

xxh42

0

0

0

..

0

0

1

1

1

0

1

1

xxh59

Idem pour octet[8] pour l’heure de fin et pour octet[9] pour les minutes de fin.

Au total, par transmission, on n’enverrait donc que 10 octets (Mirf.payload = 10).

Comme les modules récepteurs sont intelligents et stockent les informations, on n’envoie ces informations que lorsque l’on veut modifier la programmation, c’est-à-dire pas souvent.

Gestion du statut : cette fonction permet de récupérer l’état d’un module prise ou d’un module lampe, de lire la programmation horaire pour un module prise, de récupérer une valeur, par exemple pour un module thermomètre…

Adressage des modules : dans un premier temps, je vais préparer mes modules avec les adresses programmées en dur ; ultérieurement, j’aimerais faire en sorte qu’un module soit en phase d’auto-apprentissage pendant, par exemple 30 secondes après sa mise sous tension (et sous réserve qu’il n’ait pas déjà une adresse, auquel cas, il faut d’abord passer par une commande de remise à zéro).

 

Ce n’est donc pas terminé car je voudrais encore améliorer plusieurs points :

1) permettre d’utiliser un module Arduino pour commander plusieurs prises différentes; cela signifie qu’un module prise ne répond pas qu’à une seule adresse mais à plusieurs;

2) rendre possible le fait de reseter les modules;

3) reprogrammer un module (après l’avoir reseter ou à la première utilisation); il faut donc gérer le fait que l’adresse est « vide » pour être alors en mode programmation puis ne plus le faire quand l’adresse est enregistrée.

Suite : voir article sur les premiers essais