Electronique > Réalisations > Télécommandes > Télécommande 006b
Dernière mise à jour : 10/06/2012Présentation
J'ai conçu et réalisé ce système pour piloter ma station de travail (Cubase / Protools) depuis ma petite cabine speak, à travers un câble audio symétrique standard. Le cahier des charges était le suivant :- disposer des commandes de transport standard REC, START, STOP, etc (cabine vers station) grâce à de simples données MIDI et la fonction de synchro externe MMC (logiciel en mode esclave);
- utiliser le même câble pour transporter l'alimentation requise pour la télécommande, car je ne voulais pas ajouter de source d'alimentation dans la cabine.
Comme la longueur de la liaison entre cabine et station de travail est assez conséquente (plus de 10 mètres) et parce qu'un des deux fils de modulation du câble symétrique est réservé à l'alimentation des circuits électroniques, il ne reste qu'un seul fil de libre pour le transport des ordres de commande. Exit donc l'idée d'utiliser une liaison symétrique en courant de type RS485 (comme pour le DMX). Avec une liaison RS232 standard, il est raisonnable de ne pas dépasser 10 mètres de câble à 19200 bauds, alors avec une liaison MIDI qui va deux fois plus vite.... J'avais pensé au départ utiliser un transport avec une porteuse HF d'environ 500 kHz modulée par les données MIDI, mais j'ai changé d'avis en cours de route (pour les curieux : ancien synoptique et ancien schéma). Mon choix s'est finalement porté sur une solution de télécommande avec deux parties, un émetteur (dans cabine) et un récepteur (vers station de travail) tous deux dotés d'un petit microcontrôleur PIC 16F628A. J'étais peu enclin au début à utiliser ce principe, mais j'ai craqué. Ca m'a donné l'occasion de travailler sur une double liaison série dans un seul et même PIC standard : 2400 bauds pour la liaison entre les deux modules, et 31250 bauds pour les commandes MIDI.
Synoptique général
L'idée de départ est d'utiliser un même câble audio symétrique pour transporter l'alimentation continue (sur un premier fil) et les données à transmettre (sur un second fil). Sur le synoptique qui suit, on ne montre que deux liaisons sur les trois, celle du microphone n'est pas représentée. La liaison du haut correspond au retour audio (casque et vu), la liaison juste en dessous permet la livraison de l'alimentation (+12V) et des données de télécommande (Data).
Alimentation
La tension d'alimentation de +12 V est véhiculée entre le fil "point chaud" (broche 2 de la XLR) et la masse (broche 1 de la XLR). Cette tension de +12 V est utilisée pour l'ampli casque, et une régulation +5 V locale est assurée sur place, dans le boîtier de télécommande, pour les circuits de commandes de transport et vumètre. Le circuit qui consomme le plus de courant est l'ampli casque, mais de façon relativement modeste tout de même (on s'en tient à quelques dizaines de mW dans les écouteurs). Ensuite vient le circuit vumètre, mais là encore de façon assez modeste puisqu'il dispose d'un affichage multiplexé. Tout ceci pour dire que la perte de tension induite dans le câble de modulation sera modéré et non gênante. Un bon découplage par condensateur à l'arrivée, suivi d'un régulateur de tension pour les circuits "sensibles", et hop ! on n'en parle (presque) plus.Commandes de transport
Les commandes de transport se font via des commandes MIDI MMC. L'émetteur de télécommande envoie des ordres simple au récepteur, à une vitesse lente de 2400 bauds. A cette vitesse-là, pas de soucis avec mes 15 mètres de câble. Le récepteur "transforme" ensuite ces données simples par des commandes MIDI de type RT (Temps Réel) et MMC (MIDI Machine Control). Le principe est simple et ne demande au final que peu de matériel et de logiciel.Schéma
Le schéma qui suit représente les deux parties émission (côté station de travail) et réception (côté cabine) de la télécommande. Pour les circuits ampli casque et vumètre, voir respectivement Ampli casque 008 et Vumètre 012c (c'est ceux que j'ai utilisés).
Tous les composants représentés sur ce schéma ne sont pas au même endroit physiquement. Vous allez bientôt comprendre pourquoi, si ce n'est pas déjà le cas.
Emetteur (côté cabine)
Un PIC 16F628A (circuit intégré U1) se voit confier la tâche de délivrer des commandes simples à partir de boutons poussoir. A chaque appui sur un bouton poussoir correspond un code unique, matérialisé par un octet unique (8 bits). Ces octets sont transmis vers le récepteur à une vitesse lente de 2400 bauds. Il peut sembler surprenant d'adopter un quartz de 8 MHz pour l'envoi de données aussi peu véloce. La raison est simple, je réalise de plus en plus de montages à base de PIC et ces derniers sont le plus souvent cadencés à partir d'un quartz de 8 MHz. Parfois c'est du luxe mais j'assume. Les huits boutons poussoir sont répartis sur les ports A et B du PIC. Une résistance de rappel à l'état bas (pulldown) est ajoutée sur chaque ligne de commande. Ces résistances auraient pu être supprimées côté port B, en utilisant le pullup interne. Mais comme j'avais l'intention d'utiliser un réseau de résistances, je me suis laissé entraîner par la simplicité. Vous n'êtes pas obligés de suivre mes bêtises. Le circuit intégré U3/SN74244 sert d'interface entre le PIC et la ligne de transmission. Ce circuit, qui est un driver de ligne, est capable de délivrer de bonnes dizaines de mA et ne se plaint pas trop d'une charge capacitive élevée, surtout sous un débit de transmission modéré. Il est normalement plus robuste que la sortie d'un PIC. Enfin je l'espère, je vous raconterai. La moitié seulement de ce circuit est utilisée, l'entrée de validation de l'autre moitiée (broche 19) est reliée à la masse. La LED D1 connectée sur la broche RA4 de U1 s'allume brièvement quand on appuie sur un des boutons de commande.Récepteur
C'est le machin qu'au départ je ne voulais pas faire comme ça. On dit qu'il n'y a que les imbéciles qui ne changent jamais d'avis. Vous pensez bien, ce n'est pas tombé dans l'oreille d'un sourd. Les données transmises à faible vitesse par le premier PIC atterrissent sur le transistor Q1, qui assure une sorte d'interface de protection. En tout cas, je me suis dit que ça pouvait jouer ce rôle. Les données de commande qui arrivent sur la base de ce transistor en ressortent sur l'émetteur car le coquin est câblé en collecteur commun, que les intimes appellent aussi montage suiveur. Le condensateur C3 absorbe les petits pics de tensions qui apparaissent des fois, mais ne suffirait pas pour une descente directe de foudre. Les données ainsi récupérées, amputées de quelques centaines de mV, arrivent sur la broche RA1 du PIC U2, qui est configurée en entrée et qui sert de "récepteur RS232". Le logiciel du PIC U2 travail en interne avec deux UART (un UART est un module pour envoi et réception de données sous forme série) :- un UART logiciel qui réceptionne les commandes simplifiées venant du premier PIC U1 et qui arrivent à la vitesse de 2400 bauds sur la broche RA1/AN1;
- un UART matériel mis à profil pour générer les données MIDI à la vitesse de 31250 bauds, qui sortent sur la broche RB2/TX.
Ici, aucun soucis pour faire travailler les deux car ils ne fonctionnent pas en même temps. L'UART matériel n'est requis qu'à la réception des données de commande. De toute façon, l'UART logiciel ne travaille pas en "tâche de fond" et il est de type "bloquant". Ce qui signifie que le programme reste en attente de réception de commande et ne fait rien d'autre en attendant. Les choses sérieuses ne se produisent qu'une fois un octet de commande reçu. A vrai dire, je le savais avant de commencer. La LED D1 s'allume en cas d'erreur détectée lors de la réception de données. Ca, je l'ai su après.
Accusé de réception des ordres
J'ai pensé ajouter un accusé de réception des commandes, avec émission de sonorités bien différentes pour chaque commande principale (REC, STOP, START). Et comme j'y ai pensé, j'en ai profité pour le faire. La sortie RB7 du PIC U2 délivre des petites notes de musique sur réception des commandes, pour confirmer que les top départ lancés depuis la cabine sont bien arrivés au récepteur. L'insertion de ces petits sons se fait par injection sur les fils de ligne audio qui ramène la modulation dans la cabine. Il ne s'agit pas d'accusés d'action, puisque je ne vérifie pas si le logiciel d'enregistrement à bien réagi. Mais c'est toujours mieux que rien. Je (re)précise que ces accusés sonores ne sont utiles que quand je suis seul et que je joue en même temps le rôle de technicien son et d'interprète. Quand j'enregistre quelqu'un d'autre, ce retour sonore est totalement inutile.Alimentation
Un transformateur d'alimentation 230 V / 9 V délivre une tension de 9 Vac. Vous y croyez, vous ? C'est pourtant vrai, à condition bien sûr qu'on le branche et dans le bon sens. Les 9 Vac (ac = alternatif) arrivent sur un pont de diodes constitué de D2 à D5 et sont filtrés par le condensateur C6 de 470 uF. La tension continue obtenue en ce point est de l'ordre de 12 Vdc (dc = continu). C'est cette tension (non régulée) qui est véhiculée dans la ligne "point chaud" du câble de liaison principal. Un régulateur intégré de type LM7805 est utilisé pour chacun des deux PIC. U4 pour le PIC de l'émetteur et U5 pour le PIC du récepteur. Un troisième régulateur de même type est utilisé pour le vumètre, qui conserve son autonomie. L'ampli casque se connecte directement sur la ligne +12 V, il n'a pas droit à un régulateur mais dispose tout de même d'une bonne cellule de découplage locale car la ligne d'alim est tout de même bien longue. Oh, un détail. Comme je n'avais plus de transfo de secondaire 9 V en stock, j'en ai pris un de 12 V. La tension redressée et filtrée est plus proche de 18 V que de 12 V mais ça ne me pose pas de problème. D'une part parce que la consommation des circuits émetteur et récepteur est faible et que les régulateurs de tension intégrés 7805 n'ont pas trop de puissance à dissiper, et d'autre part parce que mon ampli casque peut survivre à un tel débordement.Prototype
Réalisé en deux étapes : premières vérifications avec ma platine EasyPic7 (débugage), puis proto installable.
Proto 001 - Vérifications générales / débugage (tests Tx et Rx séparés)
Pour les tests de ces deux parties de la télécommande, j'ai utilisé mon logiciel ComTools associé à une interface matérielle USB/RS232 et configuré en 2400 bauds / 8 bits Data / 1 bit Stop (sans aucun contrôle de flux).Test partie émetteur (Tx) - J'ai relié la sortie RB2/TX du PIC "U1" au convertisseur RS232 présent sur la carte EasyPic7 (via cavalier et microswitch adéquats). J'ai ainsi pu établir une liaison RS232 standard entre le circuit à tester et mon PC sur lequel tournait ComTools. La petite platine sans soudure qu'on voit sur la photo n'était là que pour la LED câblée sur la broche RA4 du PIC et qui clignote rapidement dès qu'on appui sur un des boutons de commande. J'ai pu vérifier avec cette installation rapide que les données envoyées étaient correctes.
Test partie récepteur (Rx) - J'ai procédé de même pour la partie réception, à savoir câblage de la sortie du convertisseur RS232 présent sur la platine EasyPic7 vers l'entrée idoine du PIC "U2". Seulement problème, on a le choix entre 8 broches possibles pour les liaisons RS232 "hard", mais le routage vers la broche RA1 n'est pas prévu. Qu'importe, le temps des tests, j'ai routé les commandes non pas vers RA1 mais vers RB5. Tout fonctionne comme prévu.
Proto 002 - Réalisation des platines et tests complets (Tx + Rx)
Me reste à faire les tests complets qui ne seront possibles qu'une fois tous les circuits réalisés et installés. C'est en cours de construction, sur des petites plaques d'expérimentation à pastilles. Pour l'instant j'ai fini la partie émission dans le boîtier cabine, avec le vumètre et l'ampli casque.
Pour le circuit vumètre, j'ai imprimé un gabarit, histoire de faire au plus droit possible. Un petit coup de pointe de fer à souder pour marquer l'emplacement du foret, et hop.
Mais le plastique, vous savez ce que c'est... Et comme je n'ai pas retrouvé de potentiomètre stéréo dans mon chantier, j'en ai installé deux simples pour le volume casque. Oui, je sais... Bon eh bien c'est l'heure de la mise sous tension. Un petit 9 V limité à 100 mA pour commencer, le vumètre s'initialise correctement, l'ampli casque ne ronfle pas et fonctionne même bien, et le PIC tourne comme lors des premiers tests. Ah si, un tout petit soucis : un des deux potentiomètres de volume casque crachote un tout petit peu. Je sais ce qu'il faut faire dans tel cas de figure (j'ai le choix entre trois options : tout jeter et recommencer à zéro, changer le potentiomètre ou le nettoyer). Maintenant, réalisation et mise en boîte du récepteur.
A l'initialisation, le récepteur délivre bien ses signaux MIDI "test" (Note On / Off brève) et la petite LED câblée sur la broche RA4 clignote comme attendu. Cool, on peut continuer les tests sérieusement et installer le tout à l'endroit prévu. Télécommande dans la cabine :
Alors, tout fonctionne ?
Maintenant oui ;-)Il m'a fallu régler deux petits ennuis :
- au début, le récepteur ne réagissait correctement qu'à la première commande envoyée par l'émetteur et pas aux suivantes. Le problème était situé sur le récepteur avec la routine de gestion logicielle des données série (données entrant sur RA1). J'ai résolu le problème en étoffant un peu le logiciel. Après lecture sur divers forums, j'ai en effet découvert qu'il était préférable de démarrer la lecture des octets entrant non pas tout le temps en boucle mais sur changement d'état d'une broche du PIC provoquant une interruption (je rappelle que pour ces données, on travaille avec une routine UART logicielle de type bloquante). C'est pourquoi désormais les données entrantes arrivent en même temps sur RA1 et sur RB0. RA1 pour réception données et RB0 pour détection changement d'état. La lecture logicielle bloquante ne démarre désormais que dès réception du bit de START. Effectivement, avec cette méthode ça fonctionne bien mieux.
- une fois l'installation terminée, j'ai noté un poil de ronflette dans le retour casque. J'ai ajouté un condensateur de filtrage à celui existant (1000 uF ne suffisait pas, je suis passé à 2200 uF sur la ligne 12 V). Je n'avais pas noté cette ronflette lors des premiers tests parce que j'avais utilisé une alim de labo de bonne qualité.
Tests avec Cubase
Ca fonctionne aussi, après avoir placé Cubase en mode "Esclave MMC" (Transport / options de synchronisation, ID device à la valeur 0).
J'ai du apporter une petite modification au logiciel de la télécommande côté récepteur. Pour lancer l'enregistrement, je devais appuyer sur le bouton REC puis sur le bouton START de ma télécommande pour (1) activer et (2) démarrer l'enregistrement. Comme je voulais que ces deux opérations (1) et (2) se fassent avec appui sur un seul bouton, j'ai créé une nouvelle commande où j'ai regroupé les deux actions. Mon bouton REC principal envoi désormais à la suite les messages MIDI REC et START. Avantage de faire soi-même, on sait où modifier et en l'occurence ici c'est super simple à faire. J'ai toutefois conservé les deux commandes séparées. Côté routages audio depuis et vers cabine, pas de difficulté majeure... mais un grand besoin de feuilleter quelques pages du manuel utilisateur. C'est la première fois en effet que j'utilise vraiment la fonction de Control Room de Cubase, avec tout ce que cela implique...
Un détail mineur : en câblant la sortie MIDI Out de ma télécommande sur l'entrée MIDI In de mon interface audio (RME FireFace 800), je me suis d'un seul coup souvenu que je n'avais qu'une seule entrée MIDI. Bref, achat vite fait d'un merger MIDI pour continuer d'utiliser mon clavier maître (Roland D50) en même temps que la télécommande.
Logiciel du PIC
Les fichiers code source (Mikropascal V5.30), assembleur (*.asm) et binaire compilé (*.hex) des deux parties émetteur et récepteur sont disponibles dans l'archive dont le lien suit.Télécommande 006b - PIC 16F628A - 10/06/2012
Si vous souhaitez recevoir par la poste un PIC préprogrammé et prêt à utiliser, merci de consulter la page PIC - Sources.
Circuit imprimé
Non réalisé.Historique
10/06/2012- Première mise à disposition.