Bonjour à tous,
Les choses ne vont pas toujours très vite mais l’essentiel n’est-il pas de progresser ?
Ce fil que j’avais initialisé il y a 1 an ½ a franchi une étape importante avec la centrale MXF DIY que j’ai présentée ici : Contrôler vos trains MFX depuis un Arduino Due SANS passer par la Gleisbox - #28 par bobyAndCo
Pour arriver à cela, il a fallu maitriser le protocole de voie pour le MFX, c’est-à-dire la façon dont les informations binaires sont envoyées aux décodeurs des locomotives en se servant du courant d’alimentation (+/- 18v) et de la fréquence d’alternance qui permet au décodeur de reconnaitre s’il s’agit de 0 (zéro) ou de 1.
Deux documents fondamentaux permettent de comprendre le mécanisme. Les liens ont déjà été donné dans ce fil par Julie @Julaye et Sylvain @Delias mais je les recopie ici pour centraliser l’information.
Gérald @gelit lui a présenté une réalisation qui introduit dans son programme une machine à états permettant de commuter les sorties d’un driver pour transformer des trames « binaires » en alternances électriques.
Pour peu que l’on ait les clefs de lecture (protocole) les choses deviennent alors plus simples et permettent par exemple d’aboutir à la centrale MFX que je présente.
Si cette centrale est capable de transmettre toutes les commandes pour piloter des locomotives, il me manque malgré tout la « communication retour » des décodeurs vers la centrale pour que les choses soient vraiment complètes.
J’ai déjà abordé ce point dans ce fil un peu plus haut. Marklin utilise pour cette communication retour un principe assez proche de ce qui existe en DCC. A savoir une « fenêtre » durant laquelle aucune information n’est envoyée aux décodeurs et que ces derniers interprètent comme le signal pour envoyer leurs informations en retour.
Je suis bloqué à ce niveau car je n’ai pas les compétences suffisantes en électronique. De ce que je comprends conforté par des échanges avec Délias, les décodeurs envoient un signal à une certaine fréquence. Pour peu que l’on dispose du composant électronique capable de lire ce signal, il est assez simple de le convertir en code informatique.
Extrait de : https://www.skrauss.de/modellbahn/Schienenformat.pdf
En principe, le canal de retour est codé comme un signal RDS® (codage binaire et modulation). Il est donc possible d’utiliser une puce de décodage RDS® disponible dans le commerce pour décoder le canal retour dans la centrale. C’est d’ailleurs ce qui est fait.
La fréquence porteuse ne correspond pas exactement à la fréquence porteuse définie pour le RDS®. On utilise une fréquence légèrement inférieure qui, contrairement à la fréquence porteuse RDS®, peut être dérivée d’un quartz avec une valeur de fréquence « paire » (par ex. 4 MHz). La fréquence porteuse est de 52,63 kHz (obtenue en divisant 4 MHz par 76, au lieu de 4,332 MHz divisés par 76 = 57 kHz pour le RDS®).
Comme décrit au point 2.2.6, il existe deux types de messages de retour : un simple message de retour de 1 bit et le message de retour de données. Les deux utilisent certes la puce de décodage RDS®, mais de manière différente. Seul le retour de données proprement dit utilise la technique de transmission du RDS®.
On peut d’ailleurs voir à l’intérieur d’une CS2, la puce PT2579 qui est spécifiquement une puce pour le traitement des signaux RDS.
Sur une autre source, il semble que l’auteur ait réalisé un montage électronique qui permet de décoder le signal retour. Mais là aussi je ne sais pas analyser cela.
Je précise que décoder le signal retour des décodeurs ouvre des champs d’application plus vaste que celui des centrales comme la détection avec identification. Ce qui serait l’équivalent du Railcom appliqué au MFX.
Je lance un nouvel appel au forum pour qui serait capable de m’aider dans ce projet.
Christophe