A.M.F.N.

Avec les systèmes classiques comme le Railcom, ou même avec la solution évoquée précédemment (solution 1), il faut un bus de rétrosignalisation pour faire remonter les informations depuis les détecteurs situés le long de la voie jusqu'à un organe central de prise de décision: centrale, PC, ou autre.

La solution décrite ici permet non seulement de ne pas avoir à sectionner la voie, mais aussi de se passer de ce bus de rétrosignalisation.

On verra plus loin comment ce système peut être utilisé en complément d'un système digital, sans modifier celui-ci.

Réalisation:

L'idée centrale consiste à inverser la logique  habituelle, où c'est la voie qui détecte le passage d'un train et l'identifie.
Ici, c'est le train qui détecte son passage en un point du réseau (sur une balise) et rapporte cet évènement à l'ordinateur de gestion.
Pour cela, il est fait usage de petits modules WiFi très à la mode: la famille ESP8266.
On trouve sur internet quantité d'informations sur ces modules, et la façon de les programmer via l'environnement de développement (IDE) d'Arduino. Aussi nous n'y reviendrons pas.

Les balises:

Comme indiqué précédemment, vu les difficultés rencontrées avec le RFID (bien qu'il semble à première vue plus satisfaisant pour l'esprit),  on utilise ici des balises actives émettant un signal infra-rouge.

Les avantages de ces balises sur les solutions traditionnelles sont les suivantes:
- elles ne nécessitent pas de coupures dans la voie, seulement un trou de 3mm pour la LED,
- elles sont bien plus simples et donc bien moins chères qu'un module de détection,
- et le câblage en est bien plus simple également.

De ce fait, les balises peuvent être installées ultérieurement, sur une réseau "non cantonné" à l'origine, et sans abimer une voie déjà peinte et ballastée.
 
 

Une balise de base se compose d'un microcontrôleur quelconque ( pourvu qu'il ait un port série), d'une LED infra-rouge et d'une résistance. Le microcontrôleur envoie des octets sur la LED via le  port série. La vitesse de signalisation est limitée par les performances de la LED et du photodétecteur. 19200 bps semble être la limite raisonnable avec les composants utilisés ici.

Un microcontrôleur peut commander plusieurs LEDs, donc plusieurs balises, ce qui réduit la quantité de matériel nécessaire. Chaque LED est commandée à tour de rôle pour envoyer un octet. Ci-contre, schéma d'une balise octuple réalisée à partir d'un Arduino nano. L'Arduino met chaque point de commande (D2, D3...) à l'état haut pendant la durée d'émission d'un octet. Pendant ce temps les autres points de commande sont à l'état bas, aussi les LEDs correspondantes sont inactives. On peut commander 8 LEDs par microcontrôleur avec une vitesse de signalisation de 19200 bps. Chaque LED émet alors un octet toutes les 4ms. De nombreux  paramétrages différents sont possibles.

Les microcontrôleurs doivent être alimentés électriquement. Un simple feeder 5V courant le long du réseau constitue  la solution la plus simple.
Sur un réseau digital on peut envisager d'alimenter les microcontrôleurs depuis la voie, via une électronique ad-hoc.

Les détecteurs-transmetteurs embarqués:

Ils peuvent être réalisés comme un montage autonome, pour installation dans un engin moteur, à coté du décodeur DCC traditionnel, ou bien logés dans un véhicule auxiliaire,
On peut aussi y intégrer la commande de l'engin moteur. Cette possibilité, utile pour les engins fonctionnant sur batterie, n'est pas décrite ici.
 

Le détecteur-transmetteur minimum est basé sur un ESP-01, le plus petit module de la famille des ESP8266. (Note: non, le phototransistor n'est pas monté à l'envers!).

Pour les tests, nos détecteurs-transmetteurs sont alimentés par batterie.

Les ESP-01  sont assez petits d'origine, mais il est possible d'en diminuer encore l'encombrement. Voir ici.

Performances:

Avec le phototransistor du wagon de test à 13 mm au dessus de la LED infrarouge, la détection fonctionne sur une longueur de 1,5 cm.
Une balise émet un octet toutes les 4ms. La vitesse du train doit donc être inférieure à 3,75 m/s pour avoir le temps de détecter un octet.
Mais comme le détecteur attend d'avoir reçu trois octets identiques avant de les transmettre, la vitesse maximum n'est que de 1,25 m/s, soit seulement 390 km/h à l'échelle HO.

Tous les paramètres peuvent être modifiés pour obtenir des performances différentes.

Exemples d'applications:

- annonce d'entrée en gare d'un train (sans action sur le train),
- déclenchement de l'avertisseur ou du sifflet lors du passage devant la pancarte S (action sur le train),
- allumage de l'éclairage à l'entrée d'un tunnel, extinction à la sortie (action sur le train),
- obéissance aux signaux, bloc-système simplifié (action sur le train),
- exploitation plus avancée d'un réseau  (action sur le train).

Déclenchement d'une action au passage d'un train:

Le dispositif de commande peut être constitué e n'importe quel module de la famille ESP8266, mais pour simplifier l'alimentation électrique et la programmation, nous utilisons un NodeMCU, petit module qui comprend un ESP12 et les circuits nécessaires pour se connecter à un port USB.
Le détecteur embarqué lui envoie un message UDP indiquant le numéro de la balise qui vient d'être franchie. L'identité du train peut être ajoutée dans le message, ou bien déduite de l'adresse IP du détecteur.

Exemple: annonce d'entrée en gare. Il n'y a pas d'action sur le train.
Le programme qui déclenche l'action tourne sur  le NodeMCU.
Il n'y a pas de dispositif d'annonce dans nos tests, ce programme affiche simplement les informations nécessaires via  l'IDE Arduino.

Déclenchement d'une action simple sur un train:

Pour agir sur les trains, il faut envoyer à la centrale les commandes DCC appropriées, en mentionnant l'adresse de l'engin moteur.
Chaque modèle de centrale a ses interfaces, avec les protocoles correspondants.
Pour rester dans le domaine du sans  fil, nous utilisons une centrale compatible Z21: on peut la commander en lui envoyant des ordres sous forme de paquets USB, en WiFi. Il suffit de respecter le protocole Roco Z21. La centrale reçoit les commandes comme s'ils provenaient d'un smartphone ou d'une tablette équipés de l'appli Z21.

Exemple: déclenchement du sifflet ou autre accessoire embarqué (éclairage, etc).

Le programme qui déclenche l'action tourne sur un NodeMCU.
Ce module fonctionne comme un point d'accès pour les détecteurs embarqués, et comme une station vis-à-vis de la centrale.
La commande des trains depuis d'autres manettes n'est pas impactée.

Les commandes Z21 nécessaires se limitent ici à la commande des fonctions (avertisseurs, éclairages).

Un "réseau" de test tout simple:

Pour tester ces quelques solutions sans mettre en oeuvre un grand réseau, on peut se contenter d'une voie d'essai, moins encombrante:

Les commandes Z21 nécessaires sont les commandes de vitesse et de fonctions des locos.

Gestion d'un réseau réel:

La gestion d'un vrai réseau est une tache complexe, et un NodeMCU n'est pas le processeur idéal pour l'assurer.
C'est pourquoi  nous l'envisageons dans un PC pour plus de confort et de performances.

Il y a de multiples façons de faire communiquer un PC à la fois avec les véhicules et avec la centrale. Mais la centrale que nous utilisons pour les tests n'a pas d'interface réseau, et ne peut fonctionner qu'en WiFi et en mode point d'accès, aussi l'éventail des possibilités est limité.
En pratique la solution adoptée est très semblable à la précedente, sauf que le NodeMCU qui récupère les messages de localisation en provenance des mobiles et envoie ses ordres à la centrale, le fait sous contrôle du PC. 

Ici les commandes Z21 nécessaires se limitent à la commande de vitesse des locos, afin d'obéir aux signaux. Un petit protocole est à établir entre le PC et le NodeMCU.