Décodeur accessoire DCC/analogique universel

Le titre est accrocheur, parce que même si la volonté y est, le projet est ambitieux ! Malgré tout, je vais tenter de vous expliquer à quoi je suis arrivé pour le moment.

Je vous propose un montage matériel/logiciel basé sur l'Arduino pour fabriquer un décodeur universel d'accessoires. Etant moi même une bille en électronique, je n'ai fait qu'agglomérer les circuits et développements faits par d'autres ! L'avantage de la méthode Arduino est le coût, moins élevé que les décodeurs du commerce... Mais il faut quand même y passer un peu de temps. Je vous expose ici le fruit de mes réflexions, recherches sur le net et discussions menées ici même, mais je peux me tromper, et je ne demande pas mieux que d'apprendre, alors si quelque chose vous choque, n'hésitez pas à me le faire savoir.

Il y a deux parties pour mon projet : le décodage du DCC et l'activation des accessoires. Chaque partie comporte un volet matériel essentiellement électronique, et un volet logiciel sur l'Arduino.

La première chose à avoir est bien sûr un Arduino. Pour ma part, j'ai trouvé un Arduino Mega2560 autour de 10€ sur la toile. C'est un compatible asiatique (rappellons que ce n'est pas interdit puisque l'Arduino est Open Source...), mais il marche bien...

1) Décodage
1.1) Logiciel

Je commence par le logiciel parce que c'est ce qui va conditionner le côté matériel ensuite. J'ai utilisé la librairie écrite par Kevin Snow et mise à disposition sur son site Mynabay.com . C'est gratuit et libre de droits.

1.2) Matériel

Mynabay aussi fournit le schéma d'un petit circuit électronique basé sur un Opto coupleur qui permet, si j'ai bien tout compris, de séparer physiquement le courant venant des rails de la partie Arduino. Une sécurité quoi... Je l'ai réalisé pour moins de 10€.

2) Accessoires
2.1) Matériel

Là, c'est plutôt le matériel qui va conditionner le logiciel. En effet, selon ce que vous voulez commander, il faudra trouver une compensation au manque de puissance de l'Arduino, même Méga. S'il n'y a que quelques diodes basse puissance ou de petits servos à alimenter, l'Arduino peut suffire. Il faut malgré tout bien calculer son coup, sous peine de voir le Micro-contrôleur partir en fumée ! Si plus de puissance est nécessaire, il y a plusieurs possibilités. Le principe de base reste le même, une alimentation extérieure assez puissante est dirigée vers les appareils à piloter via un dispositif dont la commutation est commandée par l'Arduino. On peut utiliser des relais, des transistors, ou des H Bridges qui ne sont que des assemblages de transistors.
Il faut aussi faire avec la variété de dispositifs à contrôler. Courant en continu comme une led ou un moteur tournant, courant intermittent comme un dételeur ou un aiguillage à solénoïde... Avec un peu de puissance pour une diode, un petit servo, un petit moteur, ou avec beaucoup de puissance pour un gros moteur, un aiguillage imposant comme le cross boarding de Kato qui comprend quatre solénoïdes... Il y a aussi les moteurs d'aiguillage trois fils, et les moteurs type Kato qui réclament deux fils alimentés un coup en + / -, et l'autre coup en - / + ! C'est ce que permet le H-bridge. Comme j'ai prévu d'équiper un module T-Trak avec entre-autres des aiguillages Kato, c'est ce que j'ai utilisé.

J'ai identifié cinq méthodes différentes pour alimenter mes accessoires:

- A tout seigneur, tout honneur, par l'Arduino! C'est le plus simple, et il n'y pas de matériel complémentaire, mais le nombre et la puissance sont limités.

- Avec un shield 293D. C'est disponible sur la toile pour moins de dix euros, ça peut commander quatres moteurs DC en PWM, ou deux servos et quatres moteurs DC. La puissance est limitée à 0,6A par canal, et ce n'est pas chainable. Sur un Arduino classique, c'est donc limité définitivement à quatre actionneurs. De plus, le shield ne renvoie pas de place disponible pour d'autres dispositifs, il n'y a pas de connecteurs pour un autre shield au dessus. Enfin tous les canaux PWM sont pris par le shield...
Sur le Méga, seuls des pins analogiques et digitales restent dispos pour d'autres applications.

- Avec un montage à base de L298N. C'est un petit circuit trouvé sur la toile à moins de 8 euros. Deux moteurs DC sont pilotables, avec 2A Maxi pour chacun. Chaque moteur réclame deux pins digitales pour se mettre en route. Ce qui fait un vingtaine de moteurs pilotables sur un Méga !

- Avec des relais. Les barres de relais sont disponibles par un, deux, quatre ou huit et tout à moins de dix euros !
Le relais est bruyant, mais il assure une transmission de puissance bien supérieure à ce que permettent les H Bridges...

- Avec des transistors. Un transistor n'est rien d'autre qu'un relais dans un petit boitier électronique. Si le fonctionnement est un petit peu différent, le principe est le même. L'inconvénient majeur du transistor, c'est son manque de puissance pour un prix raisonnable... N'ayant pas de transistor sous la main, je n'ai pas testé/codé cette partie.

La vraie alimentation externe dont je me suis servi est issue de récupération d'alimentations de vieux portables qui délivrent 12 à 24v sous 1 à 12A selon le modèle. Il y en a même dont le voltage est réglable !

2.2) Le logiciel

2.2.a) Le Cahier des charges

- Simplicité de programmation. Le but est qu'un utilisateur de ma librairie n'ai pas besoin d'y toucher. Il lui suffit d'une partie déclarative pour décrire ses accessoires, d'une partie setup pour initialiser tout ça, et d'une loop() la plus réduite possible.

- Compacité. Autant que faire se peut, il doit être possible d'utiliser de petits Arduino dotés de 32Ko de mémoire programme.

- Facilité de maintenance. La librairie doit intégrer tout le nécessaire pour débugguer aussi facilement que possible.

- Extensibilité. Bien sûr, je n'ai codé que les classes que je pouvais tester. Il y a sans doute d'autres accessoires auquel je n'ai pas pensé, et d'autre alimentations possibles. Il faut que l'utilisateur puisse se coder cela.

2.2.b) Les moyens

Coder un projet un peu important avec l'outil Arduino ne m'a pas paru possible. Bien sûr, dans mon jeune temps, faute d'outil évolué et comme tout le monde à l'époque, j'ai développé sur un simple éditeur de texte et compilé via la ligne de commande. Mais les outils modernes nous ont donné d'autres habitudes et d'autres exigences. Comme je dispose de Visual Studio 2012, j'ai trouvé un addin adapté à l'Arduino, Visual Micro, gratuit en essai. Il permet aussi de débugguer, mais je n'ai pas réussi à le faire fonctionner pour ça... Parmi les autres outils que j'avais évalué, seul MariaMole se détachait du lot et permettait vraiment de travailler.
D'autres n'ont pas réussi à générer quelque chose de correct, comme CodeBlocks ou Xamarin...
Bref, j'ai utilisé Visual Studio 2012 avec Visual Micro. Peut être que c'est possible d'utiliser Visual Studio Express qui est gratuit, mais je n'ai pas essayé...
Pour ceux qui voudraient lire mon code, je m'excuse par avance de l'usage immodéré et exclusif de l'anglais. C'est une habitude professionnelle, et une simplification pour moi. Au revoir les accents, les longues descriptions, les noms à rallonge. L'anglais est concis, sans fioriture, efficace. Amis poêtes, passez votre chemin !

2.2.c) Le modèle objet

Le programme principal et les libraries sont codés en C et C++ . J'ai utilisé abondamment le C++ pour hiérarchiser mes classes et décrire le monde... Pour ceux qui ne le savent pas, le C++ permet de créer des objets qui vont interragir entre eux via des fonctions. Il y a une partie déclarative, qui décrit à quoi ressemble un objet et ce qu'il est capable de faire, et une partie executive qui décrit les comportements voulus pour cet objet.

La première étape c'est l'abstraction.

2.2.c.1) Les accessoires

Accessory
AccessoryLight
AccessoryLightDriver
AccessoryMotor
AccessoryMotorOneWay
AccessoryMotorTwoWays

Un Accessory, c'est au sens large un accessoire. C'est divisé pour l'instant en deux groupes: les éclairages (AccessoryLight) et les actionneurs (AccessoryMotor).
Dans le cas des éclairages, fixes ou clignotants, il y a qu'une version simple commandée par ce que j'ai appelé des Drivers, c'est à dire des commutateurs d'alimentation, comme cité plus haut.
Du côté des moteurs, j'ai pour l'instant découpé le monde est deux groupes : les moteurs qui ne tournent que dans un sens, comme un moteur d'un moulin à vent ou à eau, ou un dételeur... Les moteurs bi-directionnels, c'est à dire tout les autres ! Cela inclus les aiguillages, les plaques tournantes, et j'en oublie sans doute... Il y a aussi les servos, mais pour l'instant, je n'ai pas créé la classe. Sans doute une dérivation supplémentaire du moteur bi-directionnel.

2.2.c.2) Les drivers

Driver
DriverArduino
DriverL293n
DriverL298d
DriverRelay
DriverPort
DriverPortArduino
DriverPortL293n
DriverPortL298d
DriverPortRelay

Le driver est l'interface, le shield, l'Arduino ou le composant de circuit électronique qui va piloter un ou plusieurs accessoires. Il est doté de ports, c'est à dire d'endroits possibles où brancher un moteur ou une lumière. Par exemple sur le shield L293d, il y a quatres ports disponibles. Sur la carte L298d, il n'y en a que deux. Tandis que les cartes de relais vont de un à huit, et peut être plus... C'est aussi le driver qui recevra l'alimentation extérieure qui va donner la puissance aux accessoires. Comme je l'ai dit plus haut, il y a d'autre types de drivers possibles que je n'ai pas encore codé, comme les transistors, et aussi d'autres H bridges peut être plus puissants... C'est ouvert. Il suffit de dériver Driver, puis de dériver DriverPort, et d'associer les deux grâce au constructeur du driver.

2.2.c.3) Les groupes

L'idée du groupe (AccessoryGroup), c'est de rassembler plusieurs accessoires et de les piloter ensembles. Il y a deux cas que me viennent à l'esprit.
Le premier est un feu de signalisation simple avec juste rouge et vert. Chaque led est un accessoire (AccessoryLightDriver) piloté par une broche de l'Arduino (DriverArduino, pin 52 et 54 par exemple), et la combinaison des leds pour former un motif précis (rouge fixe + vert clignotant par exemple) constitue un état du groupe. Un autre état serait le rouge seul, un autre le vert seul... La somme des états forme le groupe. Le programme n'a plus qu'à demander de passer à un état particulier, le groupe va se charger d'activer ce qui doit l'être, et d'éteindre le reste.
Le second exemple est le double crossing de Kato, un gros croisement formé par quatre aiguillages. Il y a donc quatre moteur à piloter, environ 2A, ce que tous les Driver à base de transistor ou de H bridge ne peuvent pas faire. Il faut donc séparer les moteurs et les cabler deux par deux. Ainsi un Driver L293d pourra les actionner séquentiellement. Pas ensemble, sinon l'appel de puissance sera trop important. On a donc deux accessoires (AccessoryMotorTwoWays, chacun pilotant deux moteurs, mais c'est le cablage qui s'en occupe), pilotés par un DriverL293d. Le groupe comprend deux états, un pour la position droite des aiguillages, l'autre pour la position déviée. Lors du changement d'état, le groupe doit d'abord activer un accessoire, puis lorsqu'il a fini, activer l'autre. Ainsi pas trop de dépense d'énergie.

La suite au prochain épisode !