Le projet qui me tient tant à coeur commence enfin à voir le jour...

Je travaille sur ce projet depuis assez longtemps pour ne plus me souvenir du point de départ exact. Cependant, je n'en suis pas venu directement à ce point aujourd'hui en une seule étape. J'ai commencé par développer de petits prototypes simples, réalisant une seule fonctionnalité à la fois, à l'aide d'un breadboard, afin de tester un composant particulier. Puis, de fil en aiguille, j'ai pu les faire évoluer vers des prototypes plus complexes en y incluant le CAN bus par exemple, établissant ainsi une communication entre les différentes fonctionnalités. Après plusieurs essais et erreurs, les prototypes ont pris forme pour en arriver à la présente version:

On peut apercevoir ici quelques uns des modules fonctionnels que j'ai réalisés. A gauche, l'injecteur/distributeur, puis le module CAN Bus/Arduino en haut, associé à un module de signalisation à sa droite, le détecteur en haut à droite, et enfin le grand module canton au centre.

Mais avant de décrire chacun de ces éléments, quelques mots sur le projet... Il peut se décrire de la manière suivante: automatiser tout ou partie d'un réseau DCC sans ordinateur...

Le concept est simple: pour des réseaux de petites tailles, il est possible d'automatiser le parcours de certains "trains de parade" pendant que l'utilisateur "joue" à manoeuvrer un petit convoi en gare. Mais aussi, lors d'une exposition, on peut vouloir automatiser la circulation d'une rame en va-et-vient sur un petit réseau point-à-point. Les exemples sont nombreux...

Mais quelle est l'utilité de ce projet? En fait, le DCC autorise beaucoup de liberté lorsqu'on est aux commandes. Mais dès qu'il s'agit de piloter plusieurs trains en même temps, cela se complique! D'où la solution souvent proposée d'utiliser un ordinateur et le logiciel approprié.

Alors pourquoi ai-je décidé de développer un autre système alors que celui-ci a déjà fait ses preuves? D'une part parce que j'ai toujours eu l'impression qu'utiliser un ordinateur dans ces conditions m'éloignait du modélisme comme tel... Vous allez me dire que toute l'électronique que j'ai utilisée peut elle aussi avoir tendance à m'éloigner de ma passion mais je vous rétorquerais que j'ai ressenti un plus grand défi à utiliser des Arduino qu'à programmer un logiciel même pour un Raspberry Pi. Et j'ai aussi très certainement appris beaucoup plus de nouveaux concepts en électronique que je n'aurais pu le faire en informatique (je suis programmeur de métier, ce qui explique peut-être cela...).

Et d'autre part, parce que je voulais me rapprocher d'une simulation répartie entre plusieurs concepts comme en réalité: les cantons avec leur signalisation autonome, le dispatcher indiquant les trajets aux trains en les aiguillant ici ou là, et enfin le pilote du train qui réagit à la signalisation et à son environnement afin d'arriver à destination. C'est ici qu'interviennent tous les modules individuels que j'ai développés de manière à répartir les fonctionnalités...

Nous pourrions argumenter pendant un long moment sur le pour ou le contre d'une telle décision, mais je ne veux pas entrer dans ce débat-là sur ce blog... Alors revenons au sujet principal. Pourquoi ai-je mentionné plus haut, des réseaux de petites tailles? Parce que je n'ai pas la prétention de développer un système universel, redimensionnable à l'infini, utilisable sur des réseaux de plus de 100 cantons où circulent 50 trains de manière indépendante et automatique. Ceci-dit, avec un peu plus de travail, je ne vois pas pourquoi cela serait impossible... C'est justement le rôle de la modularisation globale...

Je vais maintenant donner une description plus précise de chacun des modules. Tout d'abord l'injecteur/distributeur:

Dans l'idée de modulariser et factoriser les montages, le premier de la série me permet d'acheminer le courant et de supprimer le régulateur 12V/5V sur tous les modules... Je peux ainsi utiliser du 12V sur de grandes distances (fils rouge à gauche) entre plusieurs injecteurs et répartir ensuite le 5V sur de petites distances aux différents modules, sans perte de puissance. Il permet aussi de connecter les modules ensemble grâce au CAN Bus tel un réseau Ethernet. Enfin, il transmet le signal DCC (fils noirs à gauche) pour alimenter la voie parallèlement aux détecteurs de présence.

La connexion s'effectue à l'aide d'une prise RJ12 (6 conducteurs) ce qui permet d'acheminer les trois paires +5V/Gnd, DCC+/DCC- et CanH/CanL avec un seul câble plat.

On remarquera que le module est incomplet. En fait, il contient deux circuits d'alimentation indépendants. Pour les besoins de l'expérience, je n'ai eu recours qu'à un seul de ces circuits.


Ensuite, vient le module multiplexeur (à gauche sur la photo suivante): c'est la pierre angulaire de l'ensemble. Il contient un Arduino pour la logique, un encodeur MCP2515 et un transmetteur MCP2551 CAN Bus pour la communication entre les modules, la prise principale RJ12 et une barrette de connecteurs (à droite) qui permet d'ajouter l'extension désirée. Ainsi, à chaque fois que j'ai besoin d'une nouvelle fonctionnalité sur mon réseau, il me suffit de la développer, de la connecter à un multiplexeur et elle se retrouve automatiquement insérée dans le réseau. Ici, il s'agit d'un module de signalisation (encore une fois, incomplet pour le moment mais fonctionnel). Mais ce multiplexeur a plusieurs autres fonctionnalités: un exemplaire jouera le rôle du pilote du train, ce module ayant en mémoire le script d'automatisation. Un autre exemplaire servira à contrôler le booster afin d'envoyer les messages DCC au réseau.

J'ai décidé d'utiliser le CAN Bus afin de me libérer des bus de données propriétaires des différents fabricants. En particulier, j'utilisais LocoNet. Mais en voulant développer de nouvelles fonctionnalités ou simplement faire communiquer mes modules entre eux, je me suis assez vite rendu compte que la documentation n'était pas très détaillée, qu'elle n'était pas toujours disponible facilement, que le protocole ne me permettait pas de faire ce que je voulais à moins d'utiliser des tours de passe-passe assez épiques et surtout que le protocole pouvait changer n'importe quand et qu'il me faudrait peut-être modifier tout mon code pour satisfaire aux nouvelles exigences... ouf...! Ayant plutôt l'esprit "indépendant", j'ai préféré utiliser un protocole personnel qui pourra être adapté en fonction de mes besoins et basé sur le CAN Bus pour le transport.


Quelques mots sur le module signalisation: c'est une simple extension "électronique" qui permet de disposer de 24 sorties PWM supplémentaires sans utiliser un plus gros Arduino. Ici, je peux contrôler jusqu'à 3 signaux SNCF complexes ou 8 signaux BAL ou toute autre combinaison de signaux... On pourra voir au centre de la photo le connecteur mâle à 8 broches qui permet au module signalisation de se connecter au multiplexeur et ainsi de contrôler les éventuels signaux SNCF ou tout autre animation lumineuse... Le module utilise un registre à décalage 595 et une simulation PWM logicielle. J'ai parallèlement essayé le TLC5940 (driver PWM) mais le prix était finalement plus élevé et la précision du PWM que m'apportait ce composant était superflue.


Nous continuons maintenant avec le fameux détecteur (vu précédemment dans différentes versions sur ce blog).

Le principe de fonctionnement a déjà été évoqué... Il est basé sur la détection de courant induit dans une bobine et transformé en tension, qui à son tour, actionne un transistor et produit un signal HIGH ou LOW pour l'Arduino. On remarquera ici aussi un connecteur 6 broches qui sert à la liaison avec un module multiplexeur. Chaque multiplexeur peut accueillir 4 détecteurs, soient 8 zones de détection. J'ai ajouté récemment un trigger de Schmitt ce qui rend la détection beaucoup plus stable.


Et pour finir, mon module favori: le Canton. Il permet d'automatiser un canton en voie unique (deux directions) comportant 3 zones de détections: 2 zones d'arrêt, une à chaque extrémité, et une zone de roulement au milieu. Il permet aussi de connecter deux signaux SNCF complexes (un à chaque extrémité). Ce module s'insère sur le réseau CAN Bus afin de communiquer avec ses voisins et ainsi automatiser une grande partie de mon réseau, dans un avenir proche je l'espère... En fait, ce dernier module regroupe l'équivalent d'un multiplexeur, de trois détecteurs et d'un module de signalisation...

 

Pour conclure: l'idée importante à retenir avec ce projet est l'absence d'ordinateur et de logiciel de commande. Toute la logique est répartie sur plusieurs Arduino, allégeant ainsi chaque code source sur chaque micro-contrôleur. La communication se fait par le CAN Bus et permet de répartir les différentes fonctionnalités à la façon d'une architecture hétérogène en informatique. Il n'y a pas de "coeur" ou d'ordinateur qui gère tout... Certes, il n'y a pas d'écran, d'interface graphique ou de souris comme avec un ordinateur, mais si vous avez lu les articles précédents, vous vous souviendrez sûrement du boitier de commande en T avec le petit écran LCD. C'est l'outil qui me permettra de configurer les modules à la manière d'une centrale DCC et de piloter les locos individuellement au besoin.

Dernier point concernant le protocole de communication et l'interfaçage possible avec un autre protocole commercial: il me suffit de développer un petit module qui convertit mon protocole en LocoNet et vice-versa et de l'insérer sur mon réseau et le tour est joué! Je peux ainsi continuer à utiliser ma centrale Zéphyr au besoin...

Voilà, la première ronde de validation a débuté sur mon banc de test, et les résultats sont concluant. Je peux simuler la circulation d'un train sur une boucle de 4 cantons: la signalisation de chaque canton (dans les deux sens) se fait automatiquement et la vitesse du train est dictée par les signaux... Très prometteur.

Une petite vue de mon banc de test avec les deux versions de mon prototype fonctionnant ensemble. Les premiers multiplexeurs avec les Arduino rouge en haut, le clavier au centre qui me permet de simuler la présence sur les cantons "virtuels" et deux nouveaux modules en bas avec les Arduino bleu... On remarquera aussi les leds en haut à droite sur le breadboard. Cela me permet de simuler la vitesse du train et les messages DCC envoyés. En effet, impossible d'utiliser les fameux "print" dans les programmes sans risquer de ralentir et de compromettre l'intégrité de la communication par le CAN Bus...

J'espère que cette première introduction à mon projet vous a intéressée et qu'elle suscitera des commentaires et des questions auxquels j'essaierai de répondre du mieux que je peux.

A bientôt pour la suite.