Bonjour à tous!
Je suis nouveau, donc susceptible de ne pas avoir lu tous les sujets déjà publiés; mais tant pis: je me lance.
Peut-on trouver de la documentation technique sur le protocole MFX ?
On effet je suis curieux de nature et je trouve le prototcole DCC un peu “dépassé”. Hornby propose une amélioration avec son système HM7000 et Märklin propose son protocole MFX qui permet entre autre la négociation que j’appellerai “One-Ticket” de façon dynamique pour un certain nombre de paramètres. Mais j’aimerai bien en savoir un peu plus. Ou peut t’on trouver unn document de référence de protocole comme le fait Roco ?
D’avance merci. Alain (D’Auvergne)
1 « J'aime »
Bonjour,
Je pense que tu mélanges certaines choses. Tu parles de Hornby et de son système HM7000 qui est un mode de communication. Mais le protocole qu’utilise Hornby est le DCC et c’est la seule chose que l’on puisse comparer au MFX.
Le HM7000 est une technologie de communication en Bluetooth entre une centrale et le décodeur et qui utilise toujours le DCC comme protocole de commande. Le signal ne passe plus par la voie mais en sans fil donc. Il est cependant toujours nécessaire de faire « passer » le courant de puissance par les rails.
Il existe de nombreux système de commande sans fil pour piloter des locomotives chez Marklin comme chez les autres constructeurs. Peux-tu préciser quel avantage tu vois à l’utilisation du HM7000 que l’on ne puisse déjà trouver sur le marché ou en DIY ?
Christophe
Bonjour Christophe,
Merci de ta réponse.
Je vais essayer de mieux m’exprimer.
Le système HM7000 n’est qu’une encapsulation du protocole DCC dans une couche physique appelée Bluetooth; pour cela je suis d’accord; mais ce n’est pas le fond de mon propos.
Le fond de mon propos est de comprendre le fonctionnement du protocole MFX.; puisqu’il apporte visiblement un “PLUS” par rapport au DCC.
Donc, en clair, m’a question est : Existe-il une documentation technique dispoinble sur le protocole MFX ?
Alain (d’Auvergne)
Il existe un document Marklin qui s’intitule « CAN protokol » (*) qui détaille la structure des messages qui permettent, sur un bus CAN, d’envoyer des commandes à une centrale qui va ensuite les « convertir » en messages sur la voie à destination des décodeurs.
Je pense que tu parles donc de ce dernier protocole que l’on peut appeler le protocole de voie, comparable à ce qu’est le DCC.
A ma connaissance et j’ai cherché longtemps, ce protocole n’a jamais fait l’objet de publication. Mais au travers de différents travaux on en connait maintenant tous les aspects. Gelit vient justement de publier un post à ce sujet et il a après beaucoup de travail, réussi à encoder de manière logicielle des trames MFX pour adresser toutes les commandes nécessaires aux décodeurs.
C’est ce fil qu’il faut que tu suives si c’est bien cela que tu recherches.
Christophe
(*)
cs2can-protokoll-2_0.pdf (957,6 Ko)
Bien que dénommé CAN protockol, c’est une structure de message très similaire que Marklin utilise pour les communications en TCP.
Merci pour ta réponse.
Oui, cela va répondre à ma question.
Je vais donc lire ce qui a été publié par Gelit.
Je vais lire également le document dont tu donnes le lien.
Mon objectif est de comprendre (et d’apprendre)
Merci encore Christophe.
Alain
Si ça te facilite la vie, j’ai traduit le document allemand mais seulement pour les commandes qui m’intéressaient. ll y en a tout de même 60 pages.
marklin_can_protokoll.pdf (678,3 Ko)
Je crois que tu as fait déjà un énorme travail. Je te remercie car je ne suis pas familier de la langue de Goethe.
J’apprécie ton geste. Merci.
Alain.
Bonjour,
En complément je tiens à confirmer que Maerklin n’a jamais publié la spécification MFX.
Maerklin possède la marque MFX (qui est protégée) mais je doute qu’elle possède la propriété intellectuelle du protocole MFX.
Mon développement a été rendu possible grâce à l’excellent travail de Stefan Krauss et son équipe https://www.skrauss.de/modellbahn/Schienenformat.pdf
En l’étudiant, j’ai compris l’utilité de l’UID (identifiant unique présent sur chaque décodeur) qui permet d’identifier une locomotive. Ma centrale MFX a besoin de connaître cet UID que je lis via une Gleisbox et ce logiciel Raildue/examples/Get_MFX_UID at master · gelit/Raildue · GitHub
Par fainéantise, j’ai renoncé à implémenter la lecture des données MFX; je voulais aussi démontrer qu’il est possible de contrôler mes trains sans lecture
Maerklin, qui n’est pas une société logicielle, se devait de faciliter l’usage de produit tiers tel que TrainController, …
Le lien, dont parle Christophe, est la solution consistant à DEVOIR utiliser une Gleisbox, via l’interface CAN utilisé dans le monde automobile, pour commander les trains.
Avant ma période MFX, j’ai développé une centrale autonome MM2 et profité de critiquer le fonctionnement de cette Gleisbox multiprotocole dans https://gelit.ch/Train/DirectMM2.pdf
A votre disposition pour tout complément
Bonjour Gelit,
Je répond suite à une conversation avec bobyAndCo.
J’ai commencé à lire des documents sur le protocole MFX. Je suis un habitué des protocoles de la suite TCP/IP et je ne m’étais jamais intérressé aux “Bus industriels”. Donc je commence à comprendre que ce sont (dans mon langage et ma culture), des trames de niveau II avec un en-tête et une charge utile; à priori basé sur des échanges de type “Request / Response”.
Par contre, je ne saisi pas encore sont positionnenemt ou son rapport avec le protocole DCC. Je poursuit donc ma lecture.
En tout cas, merci pour les informations.
Alain (d’Auvergne)
Bonjour Alain,
le protocole MFX, comme le protocole MM2 ou DCC, sont concurrents pour commander les locomotives.
MFX et MM2 sont propriétaires alors que DCC est dans le domaine publique
MFX est particulièrement confortable avec une centrale Maerklin qui va facilement identifier une nouvelle loc sans que l’utilisateur ne fasse quoi que ce soit.
La référence au modèle OSI en 7 couches n’est pas utile … car une pure implémentation de niveau 2 (comme HDLC) sans couche physique ni couche applicative n’a pas d’utilité pratique … comme les couches TCP et IP sans les couches physique et applicative
Bonsoir Gelit,
Très bien, ton explication me suffit amplement. On peut dire que les protocoles MFX, MM2 ou DCC sont des protocoles dédiés qui n’ont pas forcément besoin d’encapsulation. La différence pratique se situe au niveau des outils de mise en oeuvre; dans mon cas, une Mobile Station 2.
Bonne soirée et merci.
Alain
Bonjour Alain,
J’ai beaucoup critiqué la Mobile Station 2 mais je dois reconnaître qu’elle permet à quiconque de commander une locomotive équipée d’un décodeur DCC ou MFX (ou MM2 qui est obsolète). L’utilisateur va pouvoir donner à sa loc. une adresse DCC particulière ou laisser sa loc MFX fonctionner “par magie”
Mes petits-enfants (3-5-8 ans) l’utilise avec plaisir
Bonjour Gelit.
Oui, c’est parfait pour moi, pour débuter. Et cela n’exclut pas la CS3 … mais pour plus tard car il va y avoir déjà un budjet pour les rails. (MarcD vient de me faire le plan Anyrail à partir du plan Noch Baden-Baden.
Donc je suis dans les rails.
Merci.
Alain
Heu… non. La connexion entre un logiciel comme TrainController et le rail n’a rien à voir avec mfx, cela passe par la CS3 et est complètement indifférent du protocole de communication qu’applique la CS3 vers les décodeurs. La CS prend, pour ainsi dire, le rôle d’un chef de chantier - il reçoit ses ordres par l’architecte, en français ou anglais ou en latin s’il travaille au Vatican, mais l’architecte se fiche complètement de la façon dont le chef de chantier transmet les ordres aux ouvriers : en roumain, en catalan, en arabe ou en langage des signes ou, pourquoi pas, par coups de sifflets comme jadis dans les gares de manoeuvre.
Pour ce qui est des différences entre mfx et DCC, il me semble que beaucoup se joue en annexe. Le DCC initial ne connaissait pas de retour décodeur → centrale, mfx l’a introduit en laissant de petites pauses de communication pendant lesquelles les décodeurs peuvent envoyer des informations. En mfx c’est même indispensable. Mais la procédure régulièrement répétée de prise de contact entre centrale et décodeur n’est pas indispensable - tams montre bien avec son m3 qu’on peut attribuer une identité de communication à un décodeur une fois “pour toutes” (enfin tant qu’il reste dans le giron de cette centrale), cela se fait manuellement.
DCC a introduit la programmation d’un certain nombre de réglages du décodeur par CV. Cela a été maladroitement recopié en MM (“fx”), et repris pleinement en mfx. L’avantage du microcosme Märklin est la facilité d’utilisation avec la surface graphique de la CSx, qui permet de programmer même des procédés complexes sans trop se soucier dans quel ordre il faut envoyer quels CV au décodeur. D’autres fabricants ont des solutions semblables, mais ce n’est pas en DCC que cela se passe, ça va par des programmers de la marque qui communiquent par des codages hors DCC - la preuve, les premiers décodeurs Märklin mfx qui ne comprenaient pas DCC pouvaient être programmés par LokProgrammer d’ESU.
Un logiciel open source permet aussi pas mal de choses en DCC, c’est la suite JMRI - mais ce sont des logiciels qui s’interposent entre l’usager et le DCC par une surface graphique et transmettent les programmations dans le bon ordre via la centrale.
Côté communication retour (donc décodeur → centrale) le monde DCC profite maintenant de deux projets bien commercialisés, le BiDiB (qui permet aussi une communication entre modules hors rail, comme le CAN-Bus) et Railcom-plus.
Railcom-plus permet de transmettre le sens d’enraillement du modèle (à condition d’être en 2rails, donc alimentation assymétrique), le sens de marche et la vitesse, évidemment l’adresse et encore quelques autres informations. Mais c’est propriétaire à son producteur !
BiDiB en fait moins, mais je me demande aussi à quoi servent les informations sus citées… bon, cela n’engage que moi.
Par contre - même si c’est peu intéressant pour le modéliste “sérieux” (heu, le tonton tousse…) - il y a mfx+ et la surface graphique de la CS3 qui permet de conduire une loco comme sur un pupitre, avec consommation de carburant, eau le cas échéant et sable. Si on veut… loksim plus train qui roule sur voie C.
Je ne pense pas que DCC soit “un peu ‘dépassé’”, il évolue avec les possibilités techniques, avec les exigences des utilisateurs (du moins de ceux qui crient le plus fort) et aussi avec le progrès de la concurrence qui, à ce jour, se limite plus ou moins à mfx.
Mfx fait de même : il a été précurseur de l’inscription automatique des locomotives auprès de la centrale et du grand nombre de fonctions (14 plus f0 en 2004), DCC a suivi et dépassé, mfx a augmenté le nombre de fonctions à 31 (me semble-t-il), certains fournisseurs se vantent d’un nombre théoriques de fonctions commutables en DCC de 32768 (2^15, pour celui qui s’y intéresse) alors qu’en réalité personne n’a encore dépassé les trenteetun, à ce que je sache. Mais ça viendra.
Et sans être informaticien je suis cette évolution dans laquelle les concurrents notamment se stimulent mutuellement, après une longue phase pendant laquelle on était content d’avoir 14 crans de vitesse et la lumière à commander…
2 « J'aime »