@TroisRoz Pour répondre (partiellement) à la demande de Roz, j’utilise une carte ESP32 sur un PCB que j’ai dessiné avec son transceiver CAN MCP 2562. Je peux fournir le GERBER si demande.
La broche CAN H de la carte est reliée dans la broche 4 de la prise DIN de la Gleisbox et la broche CAN L à la broche 8 de la Gleisbox. J’ai relié les masses entre elles (broche 2 de la Gleisbox) bien que cela ne soit sans doute pas nécessaire.
Comme on le voit sur les photos, l n’y a rien d’autre hormis l’alimentation 18V.
Je reviens sur ce fil car j’ai récemment trouvé des choses qui me semblent pouvoir permettre d’identifier l’adresse des locomotives en MFX à l’instar de ce que peut faire Railcom en DCC.
Pour résumer, l’auteur ajoute un booster (6017) à une MS(1 ou 2) pour obtenir plus de courant sur les rails. Et pour pouvoir « formater » le signal en suites de phases négatives et positives avec des longueurs précises (ce que reconnaissent les décodeurs), il a réalisé ce montage.
Je ne suis pas électronicien, mais je trouve que le schéma a des similitudes avec celui d’un décodeur Railcom.
Les microcontrôleurs existants aujourd’hui sont tout à fait capables de « sniffer » les échanges de données binaires et de les traiter dans des conditions confortables. J’ai déjà réalisé un programme qui « décode » les trames DCC pour Railcom, ce n’est pas très différent en MFX.
Est-ce que les électroniciens du forum peuvent me dire si je me trompe ou pas et s’il est possible à leur avis d’extraire un signal binaire avec ce montage ? Mesurer la durée des alternances de phase est la clef du succès, mais ça, nombres de microcontrôleurs aujourd’hui savent le faire pour des alternances qui sont de 50 à 100 microsecondes. Il faut juste un signal de l’ordre de 10 à 20 mA avec, à l’idéal, un tension de 3,3v ! Après, c’est du code informatique.
c’est en pleine tension délivrée par la centrale, le RailCom c’est en court-circuit de la centrale.
la valeur du courant est bien supérieure quoique je trouve le delta 130mA et 13mA bien grand, ben oui il n’y a pas besoin de stoker l’énergie dans le décodeur.
la fréquence est plus faible, et le baud-rate beaucoup beaucoup plus bas.
Dit autrement, là où en Railcom la fréquence est au mieux la moitié du baud-rate, en mfx, la fréquence c’est plusieurs dizaines de fois le baud-rate (48 périodes pour 1 bits.)
A la sortie du LM393 c’est le signal binaire modulé, utilisable à la tension que l’on veut vu que c’est du collecteur ouvert (dans la limite du LM393). Mais malgré une amplification de 40 du T1, on a un gain de seulement 0.06 sur T1, C4, R10 à R14. → le filtre T1/C4 ne travail pas dans une zone optimale. Il est fort possible qu’il faille fortement ajuster C4 et les résistances en fonction des caractéristiques secondaires du transfo.
De plus il doit y avoir une bonne dose de parasite à filtrer, dans le montage en question, les parasites sont remontés à la MS2 et c’est elle qui doit faire le tri.
Par contre, vu que c’est 48 périodes par bit avec une grosse tolérance sur la fréquence, il faut impérativement commencer avec un démodulateur incluant un verrouillage de phase, materiel ou logiciel, et ça c’est un truc que les micro ont de la peine à faire. Mes études datent d’une époque où la seule solution viable c’était un VCO externe (semi-analogique). Je ne sais pas en faire un propre par code.
Je te remercie tout d’abord pour ta réponse. Et je me réjouis en même temps du retour à la sérénité.
En premier lieu, est-ce que cette piste te semble peu ou prou réaliste et réalisable ? Est-ce que les questions d’ajustement de composants, de parasites à filtrer ou encore de verrouillage de phase te semblent vraiment complexe ou relativement abordables ?
En théorie pure, car je le répète, je ne suis pas électronicien, il me semble que les équipements existent.
Est-ce qu’un 74HC4046 qui tient sous la barre des 5€ ne réaliserait pas le job pour le verrouillage des phases et n’intègre t’il pas d’ailleurs les filtres ou une partie des filtres ?
De même, je crois qu’il existe des démodulateurs qui fonctionnent sur le principe de PLL. A des couts là aussi raisonnables.
Pour T1/C4, je ne me rends pas du tout compte mais est-ce que l’ajustement optimal est une opération complexe ?
Ensuite, pour le code, je n’ai pas d’inquiétude, j’avais potaché différentes docs que tu m’avais soumises avec @Julaye quand j’avais lancé ce fil, et j’en ai trouvé d’autres depuis. Je pense pouvoir m’en sortir.
Je ne sais pas si tu as suivi les posts récents mais on voit bien qu’il y a un intérêt pour des systèmes d’identification en MFX. Ce serait sympa de pouvoir sortir quelque chose comme j’ai pu le faire avec d’autres pour Railcom. Pas pour le vendre bien sûr comme certains l’avance à mon sujet. J’ai toujours partagé ce que j’ai réalisé et tout est en open-source.
Que me conseilles tu ? Ayant les compétences en électronique, est-ce que tu serais partant ?
En premier un petit erratum sur ma réponse précédente.
Un transfo de courant 1:40 cela n’existe pas, cela doit être un 40:1. (Ou alors c’est un composant actif).
Avec un 40:1, le transfo induit une attenuation de 0.025. ce qui fait que l’atténuation totale de 0.06 est plutôt très bonne (signe d’une résonance entre le transfo et le condo, ou c’est le delta de 20mA, de -10mA à 10mA qu’il faut compter, ce qui donnerait un gain légèrement supérieur à 1 au final?)
Là il n’y a pas de miracle, il faut un générateur de fonction (ou quelque chose pouvant générer les signaux nécessaires) et un oscilloscope pour mesurer la sortie et ajuster les composants en conséquences.
Le problème c’est qu’un transfo c’est fait pour fonctionner avec du sinus dans une plage de fréquence définie. Avec un signal de créneau en entrée, c’est beaucoup plus difficile de se rendre compte du signal en sortie.
Ce montage a un gros défaut, c’est que lors du fonctionnement hors période de retour du mfx, il y aura pleins de commutations, à chaque flan descendant ou montant (pas certain du quel) du signal numérique.
La PLL, ce serait ma façon de faire, des circuits pour cela il y en a plusieurs dizaines, à choisir en fonction des détails. Les application notes sont un bon indicateur. Maintenant si tu te sens de le faire sans, libre à toi.
Le problème c’est que mon expérience date d’une époque où ce n’était pas faisable par le code et on voyait majoritairement les circuits analogiques, mais cela fait il y a 20ans.
Le calage en fréquence, j’en ai très peu fait, et pas du genre du signal de retour du mfx.
Je ne vais pas aller beaucoup plus loin, j’ai d’autres activités.
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.
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.
Les composants pour démoduler le signal sont aujourd’hui très rares. Pourtant, j’ai vérifié dans ma MS2 qui a 1 an, le composant est toujours implanté par Marklin.
