Protocole MFX : Retour d'information des décodeurs

[bobyAndCo]

Bonjour à tous,

J’ai présenté une centrale en MFX qui reprend la base matérielle de LaBox et qui fonctionne de manière très satisfaisante.



DCC et MFX sont des protocoles qui sont assez similaires pour ce qui est du codage du signal de voie.

Mais le MFX dans son fonctionnement intrinsèque utilise plus les informations de retour des décodeurs que ne le fait le DCC.

Or je suis bloqué sur ce point pour que cette centrale soit vraiment complète.

Je lance un appel à l’aide aux spécialistes de l’électronique intéressés par le retour d’informations des décodeurs. J’ai pu constater au travers d’autres fils que l’activité était bouillonnante pour ce qui concerne Railcom. Peut-être une opportunité pour moi ?

Pour essayer de faire simple, MFX comme DCC, créent dans les trames de voies une fenêtre pendant laquelle les décodeurs envoient leurs informations retour. Ce signal semble correspondre à la technologie RDS.



Voir ici : https://www.skrauss.de/modellbahn/Schienenformat.pdf 2.3.1 et suivants :

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.



La datasheet du composant est ici : https://mobilluk.com.ua/wp-content/uploads/2024/01/PT2579-SN.pdf?srsltid=AfmBOoqq0ymKa5gb6j-dqeNJvNYznXRjoW_3IB-ZcrYzXdUKD85p4YnY

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.



Extrait de : https://www.persmodelrailroad.com/mfx_boost.html

Je lance un appel au forum pour qui serait capable de m’aider dans ce projet.

Christophe

[bk4nt]

Bonjour,

on s'intéresse davantage à Railcom car MFX est plus propriétaire? Il existe de la doc pour MFX?

Ce que vous avez trouvé là, autour d'un LM393, est curieux. Il semblait avoir un booster de type 6017, sans récepteur MFX. Et avoir utilisé le LM393 pour reporter des variations de courant depuis la voie sous booster 6017, et vers la voie où se situe la centrale capable de recevoir du MFX.

La seule chose qui nous intéresserait serait alors le signal à la sortie du LM393. Le 393 étant un comparateur, ce signal à sa sortie devrait être numérique...

Sa solution avec un 393 est aussi discutée ici: https://www.marklin-users.net/forum/posts/t10321-mfx-feedback-with-6017-booster "I have been able to add mfx feedback to a 6017 booster." "I pick up the current draw variations in the boostered section with a signal transformer. Then I amplify the signal and let it cause a corresponding current draw in the section directly fed by the Mobile Station."

Or le PT2579 est un démodulateur, d'un signal analogique (modulé en amplitude, avec suppression de porteuse).

La modulation DBS étant décrite ici, ce qui me semble à priori incompatible avec ce circuit à comparateur 393: https://www.semanticscholar.org/paper/Development-of-Radio-Data-System-Decoder-IC's-Ogawa-Arai/ab5a18be27b2aad7c5538b964c6a079022730640

On serait peut être sur une astuce qui consisterait à n'envoyer qu'une partie du signal modulé AM vers le PT2579, son entrée 4 (l'image où j'ai ajouté des traits en jaune). Potentiellement, un fonctionnement hors specs du PTS2579...

Ca mériterait un test, le 393 alimenté sous 5V, avec une atténuation du signal (simple diviseur avec deux résistances) entre la sortie du 393 et l'entrée du PT2579 (qui prend plutôt du 2,5 à 2V peak peak). Si le PT2579 peut recevoir/démoduler quelque chose dans ces conditions, RDCL (bit clock) et RRDA (data) pourraient être exploités par un arduino.

[bobyAndCo]

Merci de t’être intéressé au sujet et pour ta réponse. Depuis j’ai avancé et j’ai trouvé ceci qui est beaucoup plus proche du circuit Marklin et fonctionne en RDS.



Voici l’intérieur d’une MS2 où l’on voit distinctement la PT2579, démodulateur RDS.



J’ai commandé et reçu les composants nécessaires mais étant absent quelques jours, je ne pourrai reprendre cela que la semaine prochaine. Je n’ai pas trouvé de PT2579 mais j’ai cependant réussi à trouver un équivalent, le LC72725KV


Comme tu sembles connaitre le sujet, il m’intéresse d’avoir ton retour sur ces éléments.

Dans l’immédiat, je suis complètement sur le passage de la modulation du signal MFX sur RMT comme cela est le cas pour DCC-Ex. Je vais d’abord terminer ce chantier avant d’entamer celui du RDS.

Christophe

[bk4nt]

C'est curieux.

Sur marklin users (dot) net, les gens répondent à bobyAndCo de voir la doc MFX, à cette adresse: https://www.skrauss.de

Je doutais que les décodeurs de loco intègrent un modulateur AM. Ils n'enverraient que des implusions, comme pour Railcom. Une électronique simple, donc.

Le 393 est donc approprié pour détecter ces signaux feedback MFX. Resterait à tester ou à comprendre mieux comment interfacer un tel montage à 393 avec un PTS2579. Peut être juste un atténuateur à 2 résistances.

bobyAndCo , sur ce second montage que vous avez trouvé, on voit que le signal des locos (des impulsions) est écrêté à 0.7V par D1/D2, et envoyé dans l'entrée MUX d'un démodulateur AM/RDS. De là, les sorties clock et data, exploitables par un processeur.

Du coup, j'ai le sentiment que des démodulateurs RDS AM sont utilisés hors spec, avec de l'AM en mode ON/OFF généré par les locos. Mais si ça fonctionne...

[bobyAndCo]

Sur marklin users (dot) net, les gens répondent à bobyAndCo de voir la doc MFX, à cette adresse: https://www.skrauss.de

Le lien https://www.skrauss.de/modellbahn/Trackprotocol.pdf c'est un document très complet sur le signal  de voie MFX de Marklin. Ce document aborde le retour d'information (§2.2.6 et suivants) mais tous les autres asspect du protocole. C'ets en partie sur ce socument que je me suis appuyé pour produire le code de la centrale MFX.

Tu sembles bien connaître le sujet, penses-tu que tu pourrais m'aider ? Ce qui est bien sûr pour mettre à disposition de tous.

Christophe

[bk4nt]

Désolé bobyAndCo,

je suis déjà occupé par mes propres projets autour de Railcom. Et en tous les cas, je n'ai pas de matériel MFX, je n'irais donc pas bien loin, nul part dans la pratique.

Tu semblais vouloir en savoir plus sur ces feedback MFX. Et il n'y avait pas de réponses. J'ai donc simplement ajouté quelques mots, espérant avancer le sujet.

J'en profite pour corriger ma lecture du second schéma que tu as trouvé:
- on a bien MUX, l'entrée du signal depuis la voie
- RDCL la clock bits
- RDDA, la data, pour du shift in au rythme de RDCL
- le SCOUT/LM311 (un simple comparateur encore), je pense que c'est un signal binaire qui indique une détection de données RDS

Avec Railcom, une tendance pourrait être de le recevoir par canton ou par secteur au moins. Avec autant de composants requis. Et c'est assez facile, on devrait recevoir des mots de 8 bits via UART, directement exploitables.

Du coup, si on voulait un à plusieurs récepteurs MFX sur un réseau, on devine déjà avec quels composants électroniques les construire.

Reste à voir comment traiter les bits RDS reçus. Peut-être avec un simple port SPI pour data et la clock, comme on fait avec des registres à décalages. En ce cas, à chaque message, on recevrait x mots de 8 bits via SPI, ce serait simple.

Si c'est bien aussi simple, il faudrait un SPI en réception:
- clock
- data
- SPI transfer vers un buffer déclenché par la sortie du LM311

Puis ce qu'on fera des données une fois dans le buffer, c'est une autre histoire 

[bk4nt]

Du coup, j'ai encore regardé un peu le gros PDF sur MFX. Qui nous parle encore d'autres modulations que AM...

Mais le doc expliquant que RDS peut être démodulé avec des composants du commerce, donc un PT2579, un SC6579, ... ce sont alors eux qui s'occupent de la couche basse, AM, ASK ou phase, on a pas à s'en soucier.

Il y a ici manifestement des gens qui savent coder. Et il doit y avoir maintenant assez d'éléments ici pour construire un récepteur avec ce que bobyAndCo a partagé.

Resterait à faire un montage pour tester et "sniffer", pour voir ce qui sort en pratique de broches clock/data(/LM311) d'un de ces composants du commerce.

Plus loin dans la doc, ça semble dire qu'on reçoit de 1 à 4 octets. Voire moins. Il faudra alors probablement faire plus qu'un simple SPI transfer, pour s'adapter aux nombre de bits et octets reçus. A moins que faire un SPI transfer avec un timeout si on ne reçoit pas 4 octets dans un délais donné. D'une façon ou d'une autre, ça doit pouvoir se coder.

[bk4nt]

Last but not least, auquel je viens de penser, il pourrait suivre un problème d'approvisionnement de ces composants spécifiques. En effet, on substitue le DAB/DAB+ à la FM (dont RDS, qui devrait un moment s'éteindre également... et la production ainsi que la vente de ces composants avec).

Le 31 décembre 2024, la SSR ne diffusera plus ses programmes radio en FM. Il faudra donc écouter la radio en DAB+ ou via internet. Quelles solutions pour adapter les appareils à domicile ou en voiture? https://www.rts.ch/info/societe/2024/article/fin-de-la-fm-pour-passer-au-dab-quelles-solutions-28560288.html


Si ces composants / décodeurs RDS ne sont plus produits ni vendus, même Marklin finira par avoir un soucis. Pour ce qui nous concerne, ou pour ceux qui ont investit dans MFX, ils pourraient avoir à acquérir un petit stock de puces RDS si c'est une solution simple pour des récepteurs MFX.


Il y avait eu un précédent avec DCF77, un système imaginé il y a longtemps pour diffuser des signaux, l'heure d'une horloge atomique. Il existe aussi des composants dédiés pour décoder facilement ce signal DCF77. Un moment, les antennes émettant ces signaux ont commencées à être démontées... 

https://next.ink/11388/102604-grandes-ondes-france-inter-sarretera-au-1er-janvier-pas-service-dhorloge-atomique/ "France Inter qui est actuellement disponible sur la fréquence des 162 kHz cessera d'émettre à compter du 1er janvier 2017" "depuis 1977, cette fréquence transmet un signal horaire de référence élaboré à partir d’horloges atomiques explique l'Agence nationale des fréquences (ANFR)." "Problème, ce service est largement utilisé dans des secteurs clés de l’industrie afin de synchroniser plus de 200 000 horloges indique l'ANFR. Cette dernière cite quelques exemples : la SNCF, Enedis (anciennement ERDF), Aéroports de Paris ainsi que des collectivités locales." "Afin de maintenir ce service en état de marche malgré l’arrêt de la diffusion de France Inter, l'ANFR explique qu'elle a été « missionnée » par le gouvernement afin de maintenir la diffusion du signal horaire, et ce, dès le 1er janvier 2017. "

[bk4nt]

Le truc qui me plaît le plus, c'est ce montage à LM393, tout en haut. Eco et capable selon son auteur de répercuter des signaux d'une voie vers la centrale.

Les décodeurs de loco envoient peut être des signaux tout simples (impulsions à durées et espacements variables) qu'une CPU rapide pourrait facilement recevoir puis traiter. Ca ferait faire du shift in (synchrone) de la sortie du LM393.

On en saurait plus si on trouvait une trace d'oscilloscope, de ce qu'on a en entrée/sortie du LM393. Ou sur la voie, envoyé par un décodeur MFX. Peut être un encodage tout simple.

https://connect.ed-diamond.com/GNU-Linux-Magazine/glmf-204/radio-data-system-rds-analyse-du-canal-numerique-transmis-par-les-stations-radio-fm-commerciales-introduction-aux-codes-correcteurs-d-erreur

[bobyAndCo]

Bonjour,

Est-ce qu tu parles de quelque chose comme ceci ?

https://web.archive.org/web/20120729085546/http://www.alice-dsl.net/mue473/mfxrahmen.htm

Christophe

[bk4nt]

Plus de détails sur la forme/timing des signaux seraient utiles, oui. Mais à ce lien là, sur la partie RDS/retour, je remarque:

Fenster für Bestätigungs- Rückmeldun: on voit le DDC/MFX, mais pas d'exemple de signal RDS

READ-Paket wird der Rückmeldeträger mit einer Übertragungsrate von 912µs/Bit RDS-ähnlich phasenmoduliert
modulé en phase de manière similaire à RDS

Unklarheiten...
Rückmeldungen wurden bisher nur teilweise ausgewertet. Details sind daher nur unvollständig bekannt.

Jusqu’à présent, les retours n’ont été que partiellement évalués. Les détails ne sont donc que partiellement connus.

[bk4nt]

J'en ai lu un peu plus dans cet autre fil, où tu échanges avec les Marklin users:
https://www.marklin-users.net/forum/posts/m677703-Marklin-MFX-feedback--using-RDS#post677703

Je constate que tu avais déjà perçu que ces composants RDS sont aujourd'hui difficiles à trouver. Marlin les utilisant encore pour ses nouvelles stations. Pour un industriel, ce n'est pas une difficulté, ils en auront mis assez en stock pour les prochaines années, selon leurs prévisions de ventes et réparations.

Avec un LM393, ce serait pour une approche "software based", que tu évoques là bas. RDS, c'est juste 1000 BAUD. Mais dans des temps/timings courts. Un ESP32 ne suivrait pas. Il faudra à mon avis plutôt penser à un CPU dédié à cette tâche réception/décodage RDS, qui communique ensuite les données reçues à l'ESP.

Dans un premier temps, tu pourrais déjà évaluer avec un composant dédié RDS. Ce serait une bonne base pour ensuite décoder/comparer facilement les signaux.

Puis réfléchir à comment faire un décodeur à partir d'un AVR 20MHz. Peut être en le raccordant avec un LM393, en même temps que le montage à composant RDS, ce qui permettrait des comparaisons de signaux reçus/décodés.

Je ne sais pas s'il existe déjà un software PIC ou AVR qui ferait l'affaire.

[bk4nt]

C'est à cette approche que je pense, avec un AVR rapide, 20 ou 16MHz.

Là, l'article décrit comment RDS est encodé. J'imagine qu'on a un signal équivalant à "e" à la sortie du LM393, et que les décodeurs de loco font en fait un travail d'encodage très simple.

Une approche en synchronisant l'horloge ou les timing "d" avec les transitions up/down de "e", pour faire du shift in de "e" au rythme de "d"....

Ou si l'AVR suit (en étant dédié à la tâche), peut-être avec "e" sur une pin int up/down, et un calcul rapide du délais entre deux interruptions. A nouveau pour "e" dans un buffer.

Une fois les données "e" dans un buffer, il serait facile d'en déduire "b", puis "a", la data.

"d" a une fréquence double comparé à "c". J'essayerais d'échantillonner "e" à la fréquence "d", pas sur les transitions up/dow de "e". On aurait alors deux bits par symbole "e" dans un buffer: 00, 01, 11 ou 10.

C'est du 1200 BAUD et les décodeurs n'envoient pas tout le temps de messages. Entre deux messages, l'AVR pourrait décoder le buffer "e" et transmettre la data à un ESP.

Seule difficulté: la précision et la stabilité des quartz (de l'AVR et de ceux des locos). On pourrait avoir à sur échantillonner les symboles "e" sur 4 bits ou plus au lieu de 2 pour rester assez synchro, sur une "fenêtre", et se resynchroniser sur les transitions up/dow de "e". Ou avoir à utiliser une PLL pour générer "d"; ça pourrait alors être plus simple dans l'AVR. Mais avec une PLL, on pourrait perdre des symboles du début d'un message, le temps qu'elle soit en phase.

Tout peut dépendre de la fréquence "d", si elle serait compatible avec un AVR à 20 ou 16Mhz. Si c'est juste 2375 Hz, ce serait facile. On décode bien le DCC (entre 4 et 8Khz) avec un simple UNO, alors pourquoi pas le RDS si c'est effectivement aussi lent?

2375, une valeur bizarre; pour la radio FM. Marklin a donc utilisé un quartz de 4MHz. Probablement pour une vitesse plus adaptée à des quarts 16 ou 20MHz et pour des diviseurs entiers:

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®).

L'extrait/image de source: https://www.electronicdesign.com/home/article/21202018/testing-rds-equipped-fm-radio-receivers

[bk4nt]

A mon avis, cette approche toute simple avec un AVR peut fonctionner. Et ne dépendrait alors  plus de composants obsolètes.

Je doute en tous cas que les locos aient une radio FM embarquée. A mon avis, leurs décodeurs envoient un simple signal encodé et directement exploitable, notamment par le biais de ce montage simple à LM393.


Ca m'a fait regarder comment est construit une radio FM. Le "démodulateur" RDS se situe bien après le démodulateur FM. Ces puces RDS seraient donc plutôt des décodeurs avec récupération d'horloge, d'où data et clock en sortie.

Dans cet exemple:
- un TDA7040 démodule la FM
- MPX est splité vers le TDA7021, et vers le décodeur RDS, via T1
- un TDA7021 décode la stéréo
- Le TDA7330 ou "RDS decoder" se contente de restituer la data/clock RDS


Et dans la doc du PT2579, on lit "démodulator", mais ce n'est qu'un décodeur. Donc on peut ignorer tous les aspects modulation/radio FM.

De source: https://www.techdesign.be/projects/021/021.htm

[bk4nt]

Zut. Je me suis planté. Le signal en sortie des décodeurs pourrait bien être modulé, à 57kHz/AM. Alors un tel composant particulier pourrait être requis, pour avoir un signal exploitable (1).

Mais ça n'explique alors pas comment un simple montage à LM393/comparateur présenté plus haut pourrait fonctionner. Ce ne serait pas compatible avec de l'AM.

Et je n'ai pas réussi à trouver un exemple en image d'un signal électrique MFX/RDS émis par un décodeur.