Protocole MFX : Retour d'information des décodeurs

[bk4nt]

Et finalement, j'ai trouvé ceci: https://rainer.mueller-korntal.de/mfxreceiver.htm

Soupirs. Il s'agirait donc bien d'un signal analogique, modulé. Donc une solution simple ne suffira pas.

Il utilise les fonctions d'un PIC: des amplis op, un comparateur et un convertisseur AD. Et il partage un code source.

Une solution partielle, mais un début: "Bisher ist das nur die Ein-Bit-Rückmeldung mit ASK-Wert implementiert, die Auswertung der Phasensprünge fehlt momentan noch."

J'en conclue que la solution à LM393 est imparfaite, ne permet que la détection d'une modulation et sans décodage. Pour un feedback élémentaire.

[bobyAndCo]

Je te remercie sincèrement une nouvelle fois de m’aider et de chercher des solutions. Je ne suis pas disponible encore jusqu’au WE au moins ce qui ne me permet même pas d’étudier les pistes que tu soumets.

Je pense cependant que le PT2579 (ou équivalent) est la piste à privilégier même si le composant est rare et que cela va s’amplifier. C’est malgré tout celle qui reste la plus simple pour arriver à un résultat selon moi et explorer ensuite de nouvelles directions mais à partir de résultats déjà existants.

Le dernier montage que tu proposes fonctionne avec 1 bits car « Dans le cas de la confirmation simple, il n'y a pas de synchronisation avec l'horloge RDS® comme dans le cas de la confirmation de données ».

Il y a des précisions intéressantes dans le document dont j’ai donné le lien plus haut : https://www.skrauss.de/modellbahn/Trackprotocol.pdf


2.3 Canal de retour

On appelle voie de retour la transmission d'informations du décodeur à la centrale via le rail.

2.3.1 Modulation

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

2.3.2 Codage du retour d'information 1-bit

La réponse simple de 1 bit est codée par le fait qu'il y a ou non une réponse du décodeur. Si le décodeur répond, cela vaut un (« oui »). Si la centrale ne reconnaît pas de réponse, cela signifie zéro (« non »). La particularité : ce type de réponse peut être envoyé simultanément par plusieurs décodeurs, les réponses sont reliées par OU. La réponse est donc reconnue comme existante si au moins un décodeur envoie une réponse.

Le décodeur utilise le signal porteur RDS® comme réponse, c'est-à-dire qu'il génère un signal rectangulaire d'une fréquence de 52,63 kHz.

Techniquement, il s'agit d'un signal ASC (Amplitude Shift Keying). Le signal porteur est donc modulé en amplitude avec le flux de données. Il n'y a que deux états à transmettre : Bit = 0 signifie que l'amplitude du signal porteur est nulle, Bit = 1 signifie que le signal porteur est transmis avec une amplitude complète sans changement de phase.

Dans la centrale, on utilise le fait que la puce du décodeur RDS® signale la présence d'un signal porteur indépendamment des données transmises.

2.3.3 Codage lors de la confirmation des données

Lors de la confirmation des données, un flux de bits de données est envoyé, que la centrale interprète. 1, 2, 4 ou 8 octets de données ainsi qu'un octet de somme de contrôle sont transmis.

Lors des essais, seuls 1, 2 et 4 octets ont pu être transmis. Les informations contenues dans la documentation CAN de la Märklin Central Station 2 et la structure de commande permettent toutefois de conclure que 8 octets sont également possibles.

Le retour d'information ne peut être effectué simultanément que par un décodeur qui y est invité par la commande correspondante.

La modulation biphase définie pour le RDS® est utilisée pour coder l'horloge et les données. A chaque signal d'horloge, la position de phase du signal porteur change de 180°. Une horloge dure 912 μs, elle est donc transmise à 1096,5 baud (= signal porteur divisé par 48). Les bits sont également codés par changement de phase :

Bit = 1 : la position de phase ne change pas à l'intérieur d'une mesure.
Bit = 0 : la phase du signal porteur change de 180° au milieu d'une mesure (donc
456 μs après le changement de phase de l'horloge).


Je ne peux malheureusement pas en ce moment faire de recherches très poussées mais je crois que c’est la piste à suivre qui est me semble t’il la mieux documentée.

J’ai aussi trouvé ce petit article très général mais qui montre la possibilité de lire le « message » RDS avec un ATMega mais qui n’apporte pas beaucoup de détails sur le montage et encore moins sur le code.

https://tekmanoid.com/rds

Christophe

[bk4nt]

Je pense cependant que le PT2579 (ou équivalent) est la piste à privilégier même si le composant est rare et que cela va s’amplifier. C’est malgré tout celle qui reste la plus simple pour arriver à un résultat selon moi et explorer ensuite de nouvelles directions mais à partir de résultats déjà existants.

Tout à fait d'accord. Tandis que selon les sources, certains de ces composants sont encore disponibles pour pas cher.

Ils avaient été spécialisés et améliorés pour une mise en oeuvre toute simple et sans nécessiter de réglages. Si on reconstruisait un vrai démodulateur AM "Double-sideband suppressed-carrier DSB-SC", ce serait très vite une usine à gaz, à la fois encombrante et difficile à reproduire.

J'ai fini par trouver enfin des traces de scope. Dans un article où précisément quelqu'un commençait à construire un démodulateur à transistors. Un autre lui répond: "il va te falloir une boite pleine de transistors." 

Une modulation avec des délais courts, longs, courts, longs... la donnée PSK, à 1200 Baud. Normalement, un simple LM393 et un AVR peuvent recevoir et décoder cela. Mais il resterait un doute sur la polarité si on procédait de cette façon.

https://www.mikrocontroller.net/topic/319718

[bk4nt]

Juste 1200 Baud mais un sacré casse tête. Des délais courts ou longs... avec un AVR, comment savoir où sont les 1 et les 0?

La doc nous dit qu'il y a aussi changements de phase. Ajoute qu'il y a idle bits, préambule et une checksum.

Le préambule 010 (et les idle bits) devraient pouvoir permettre de se synchroniser... Sinon, il faudra un truc en plus pour détecter aussi les changements de phase.

C'est l'avantage de ces circuits spécialisés: ils s'occupent de tout.

[bobyAndCo]

certains de ces composants sont encore disponibles pour pas cher.

J'ai trouvé des LC72725KV chez Mouser. A ce jour, ils en ont un peu plus de 2000 en stock à 1,50€ pièce ce qui est très raisonnable. https://www.mouser.fr/ProductDetail/onsemi/LC72725KV-TLM-E?qs=y%252BJdrdj3vZrUHkd4SqtCFg%3D%3D&countryCode=DE&currencyCode=EUR&_gl=1*1q96xd3*_ga*MTAzODU3NzU0NC4xNzMzMzAzMTY5*_ga_15W4STQT4T*MTczMzMwMzE2OS4xLjAuMTczMzMwMzE3OC41MS4wLjA.*_ga_1KQLCYKRX3*dW5kZWZpbmVk

Juste 1200 Baud mais un sacré casse tête. Des délais courts ou longs... avec un AVR, comment savoir où sont les 1 et les 0?

Je ne pense pas que la partie logicielle posera de gros problèmes. le codage est déjà bien documenté dans le document de Stefan Krauss https://www.skrauss.de/modellbahn/Trackprotocol.pdf à partir de la page 13 § 2.2.6 : Principle of feedback.

A mon retour, je fini le RMT (2 à 3 jours ) et je me mets sur le sujet.

Christophe

[bk4nt]

Bonjour,

J'ai même vu des puces  à 0€50. Qui fait partie du casse tête: réaliser quelque chose qui ne ferait pas exploser le budget.

Vu la grosse doc du MFX, ce n'est pas un signal analogique à la sortie des décodeurs, mais bien des séries d'impulsions. De l'AM en mode ON/OFF, mais qui est donc manifestement compatible avec les puces spécialisées RDS. Un simple signal binaire qui doit être exploitable sans difficultés avec un LM393. Ce qui fait déjà deux composants avec un AVR.

Cette histoire de changement de phase à 57kHz m'ennuie plus. Pas sûr que l'AVR puisse facilement les détecter. Ca pourrait nécessiter des composants en plus pour envoyer une impulsion à l'AVR à chaque changement de phase. Peut-être un CD4046, une PLL. Ca ferait 3 composants déjà. On devrait pouvoir se passer d'une PLL si on se fie aux préambules 010 pour se synchroniser sur le flux de données, en ce cas, un LM393 et un AVR devraient suffir.

Ca devrait être facilement réalisable et codable pour le fun et pour approfondir la couche basse, ces signaux MFX/RDS. Puis pour ensuite tenter d'optimiser le nombre de composants.


Sinon, pour une détection d'occupation ou une localisation (sur Ack), comme il est possible de le faire avec Railcom (sans tout recevoir ni décoder), ce devrait être très simple. S'il y a des impulsions à 57kHz (détectable avec un LM393 et un banal circuit RC), il y a un décodeur sur la voie concernée.

[bk4nt]

J'ai trouvé des LC72725KV...

C'est excellent. Je viens de survoler la doc de cette puce, qui confirme qu'on peut se contenter d'un LM393 

Dans un récepteur radio FM, le signal RDS est analogique, susceptible d'être bruité. Tout une partie en entrée de ces puces sert à conditionner/filtrer ce signal analogique.... dans cette puce, ce signal analogique est ensuite envoyé vers un très simple comparateur. A la sortie de ce comparateur, du binaire, comme présenté dans la grosse doc MFX. Ou encore du binaire comme à la sortie d'un montage à LM393. Des salves, qui correspondent aux éléments binaires (séparés ou distinguables du fait des changements de phase).

Traiter de l'analogique aurait été beaucoup plus complexe.

Ils utilisent une PLL pour récupérer l'horloge, pour générer RDCL et pour décoder la data en étant synchrone.

C'est "juste" cette partie "décodage data en étant synchrone" qui sera à développer sur un AVR.

A mon retour, je fini le RMT (2 à 3 jours ) et je me mets sur le sujet.

On devrait donc prochainement avoir un résultat 

Et à quelques unes de mes erreurs ou approximations près, désolé, l'essentiel sur la couche basse devrait être couvert par ce dont on a discuté ici.

[trimarco232]

Bonjour,
but now , I'm back , to let you now that :
1) sourcer ces ICs , c'est 0€39 , et il y en aura encre pour un moment : https://fr.aliexpress.com/w/wholesale-PT2579.html
2) décoder des signaux tels celui-ci preambule idle.JPG , il faut que je vérifie , j'ai peut-être une idée avec un STM32 : on utilise un module capture (yen a plein dedans) , et on configure son filtre digital de manière à ce qu'il ignore les impulsions courtes : on récupère les changements de phase , avec le temps qui les sépare ...

[bobyAndCo]

Bonsoir Marc,

Je me réjouis de ton retour.

Merci pour les liens sur les composants chinois. Pour les tests, j’ai préféré rester au large de ces composants pour ne pas ajouter à la complexité de mise au point une éventuelle défaillance des composants

Tu as vu que ce projet me tient particulièrement à cœur et ton aide s’ajoutant à celle de bk4nt serait particulièrement bienvenue.

Je crois que tu as du Marklin, je peux t’envoyer tous les composants au besoin. Idem pour bk4nt mais je crois comprendre qu’il est en DCC.

Je pense (mais je me trompe peut-être) que le traitement logiciel du signal n’est sans doute pas très compliqué. Peut-être faut t’il comme tu le notes un µC un peu puissant et disposant surtout des fonctions nécessaires comme le SMT32, mais c’est du traitement de signal et c’est tout de même connu et documenté.

Un oscilo est sans doute bienvenu (ce que je n’ai pas) pour connaitre précisément les spécificités du signal, ses niveaux, ses timing etc.. Mais encore une fois, ceci me semble bien documenté ici : https://www.skrauss.de/modellbahn/Trackprotocol.pdf à partir de la page 13 § 2.2.6.

Merci encore,

Christophe

[bk4nt]

Un oscilloscope basique devient vite inutile pour ce genre de projets car les signaux fluctuent tout le temps ou sont très éphémères. Tandis qu'un oscillo numérique avec la possibilité de faire des captures est plus cher.

Il y a plus utile pour ce genre de projets: un analyseur logique. On en trouve de bons à 150, à 50 et même à moins de 10 euro. J'ai fait beaucoup avec un OpenLogicSniffer qui m'avait coûté environ 50.

Ici, la présentation d'un "gadget" qu'on trouve pour pas cher (regarder à partir de 12 minutes 30 secondes pour l'utilité):



La seule difficulté pouvant être le déclenchement de la capture (ce qui est le cas aussi pour synchroniser un oscillo). Une broche d'un processeur/système sous test pouvant être dédiée à cela. Selon ce qu'on code, on ajoute une ligne pour que la broche change d'état au moment choisi: la capture se fait dans la foulée.

Sinon, pour un oscillo cheap, il y a des solutions aussi. Un simple petit dongle audio (carte son USB avec entrée micro) à 2€ fait l'affaire. Comme on travaille souvent sous 3 à 5V, ça peut suffire. La bande passante est alors limitée, à 20kHz (mais avec deux voies si l'entrée est stéreo). Associé à Audacity, on peut en faire des choses très sympa aussi.

Dernier élément qui complète un tel analyseur, un dongle audio ou même un vrai oscillo: un isolateur USB (encore un modèle pas cher). Car dans certains cas, raccorder la masse/0V d'un PC à la masse/0V d'un circuit peut provoquer des choses étranges.

Pour environ 20 euro, on peut ainsi avoir un équipement minimal pour y voir vraiment plus clair.

[trimarco232]

j'ai un oscillo qui m'a coûté 50€ chez Ali , il est USB , donc il faut l'écran du PC , très bien , mais en effet , il reste dans son carton ; il aurait été utile pour faire de la BF ...
par contre , l"analyseur logique à 10€ , je m'en sers systématiquement , parfois pour "programmer à l"analyseur" , cad. triturer le code jusqu'à ce que l"analyseur montre les bons signaux ... ... ou bien ajouter un truc du genre PINB0 = 1 dans la loop , pour vérifier que le programme n'accroche pas anormalement quelque part , car on peut avoir l'impression qu'il marche bien , alors qu'il y a un gros bug ...
pour l'analyseur , prévoir un large ruban de dupont à l'avance , car cette merdre se met à foirer dès qu'on l'a enfichée et défichée l'une ou l'autre fois

concernant mon idée de capture + filtre , ça marcherait , mais c'est pas assez robuste : on risque en effet de louper le point de changement de phase , s'il y a une perturbation juste à ce moment là , et du coup , l'ensemble du message serait peru . En fait , ce qu'il faut détecter , c'est ... le changement de phase , cad. on constate qu'il y a une certaine phase , puis on conste que la phase à changé : l'évaluation n'est pas critique , du temps qui s'est passé entre les 2 changements de phase ; une phase dure 9.5us , donc il faudrait échantillonner environ toutes les 2us , et mettre un peu d'intelligence , pour déterminer ce qui se passe.
Donc pour un AVR , ça va trop vite. Un STM32 , genre G030 à 64MHz , le fera facilement , et un Pi Pico , aussi , mais le cœur serait très chargé avec ceci : si l'autre cœur est accaparé par le CAN , on ne pourra plus lui faire faire grand-chose d'autre.
Quoi qu'il en soit , je vais ressortir un Pico , lui faire générer un tel signal sur une broche , et voir si j'arrive à le décoder sur la broche d'à côté
en fait la seule question , demeure le hardware pour la détection au niveau de la centrale

[bk4nt]

Bonjour,
but now , I'm back , to let you now that :
1) sourcer ces ICs , c'est 0€39 , et il y en aura encre pour un moment : https://fr.aliexpress.com/w/wholesale-PT2579.html

Concurrencer ces composants dédiés à moins de 0€50, on y arrivera pas. Il s'agit finalement plus d'un POC, Proof of Concept, ou d'un challenge: s'en passer (et au passage, en apprendre beaucoup sur MFX et l'encodage RDS).

Une solution hardware simple consisterait à utiliser deux bascules monostables redéclenchables à la suite du LM393: on aurait des impulsions sur les changements de phase. Ce serait plus espacé que des transitions à 57kHz. Mais ça fait trop de composants (l'espace que ça occupe sur un PCB).

Je ne sais pas ce que peuvent faire les STM32. J'ai regardé la datasheet du atmega328, un classique. Le noise canceler du timer 1 n'est pas souple du tout, il fonctionne à sysclock, c'est trop élevé pour pour filtrer ce signal "RDS".

J'en suis arrivé à me demander si un simple attiny85 pourrait suffire. Il intègre un comparateur analogique, on pourrait alors se passer du LM393. Ce tiny peut fonctionner avec un quartz à 20MHz, pour une horloge assez stable. Ce tiny pourrait être pas loin de pouvoir tout faire, puis de transmettre les données décodées à un ESP32.

[trimarco232]

oui c'est une option à creuser ;
pour ma part , je préfère utiliser des arduino tout faits , avec l'alim , le quartz , la liaison USB pour télécharger et déboguer ; la mise en oeuvre est immédiate
un STM32 a aussi au moins un comparateur ; j'utilise également des arduino équipés de clones d'AVR , (voir minievb) : ça ne coûte rien , ça pédale à 32MHz , il y a 2 comparateurs , dont les sorties sont accessibles , pour vérifier avec l'analyseur que le comparateur fonctionne bien

[bk4nt]

En fait , ce qu'il faut détecter , c'est ... le changement de phase , cad. on constate qu'il y a une certaine phase , puis on conste que la phase à changé : l'évaluation n'est pas critique , du temps qui s'est passé entre les 2 changements de phase ; une phase dure 9.5us , donc il faudrait échantillonner environ toutes les 2us , et mettre un peu d'intelligence , pour déterminer ce qui se passe.
Donc pour un AVR , ça va trop vite. Un STM32 , genre G030 à 64MHz , le fera facilement , et un Pi Pico , aussi , mais le cœur serait très chargé avec ceci : si l'autre cœur est accaparé par le CAN , on ne pourra plus lui faire faire grand-chose d'autre.

D'où l'idée d'un petit processeur dédié, qui ne s'occuperait que de cette tâche. Il n'aurait qu'à envoyer les messages décodés à la CPU "centrale", via un UART.

Échantillonner/évaluer à 2us fait faire beaucoup de travail? Une interruption sur up/down ou toutes les 9.5us pourrait suffire? Il s'écoulerait 19us au changement de phase. Ca ne laisse que peu de cycles d'horloge/instructions entre deux interruptions à 9,5us...

Pour une immunité au bruit, il faudrait comparer les phases à N-3 ou N-4, stockés dans une FIFO. Si un échantillon N est décalé de 19us comparé à N-4, il y a potentiellement eu changement de phase.

Si on a autre chose que 9.5 ou 19us, c'est du bruit...

Ca ferait faire tourner un timer à sysclok. A chaque interruption, lire la valeur du timer. Comparer la valeur lue à la valeur N-4. Pousser la valeur N dans la FIFO.

Si on a détecté 19us pour au moins 3 échantillons (sur 4 dans la FIFO), un changement de phase serait confirmé.

Si c'est exécutable en 9,5us, la taille de la FIFO pourrait même être augmentée, pour plus d'échantillons. Si ça peut fonctionner sur interruptions, c'est synchrone; mais le timer/sysclock va shifter très légèrement par rapport au signal reçu.

Ca pourrait être évalué à une fréquence plus basse que 52k63. Ca pourrait nécessiter un peu d’assembleur pour que ça rentre dans un AVR à 20 ou 16MHz.

Une fois un message reçu, il n'y a plus d'interruptions jusqu'au prochain. Il doit rester du temps libre pour le décoder, ce n'est pas un flux de data continu.

[trimarco232]

le principe de ce que je pense faire est le suivant :
- on ne s'occupe pas de l'impulsion de 19us en B , car celle-ci peut avoir été perturbée ; de même , une perturbation sur une impulsion de 9.5us pourrait nous faire croire qu'on est dans le cas B ; ce n'est donc pas la bonne solution
- ce que je propose , c'est d’échantillonner statistiquement en A , et d'en déterminer la phase ; de continuer (continuellement) l'opération , et de constater en C que la phase a changée ; une évaluation approximative du point de changement de phase suffit à déterminer le nouveau bit

alors à ce stade , je ne sais pas encore comment faire ; j'avais aussi pensé à échantillonner à 9.5us , mais si on se trouve près d'un flanc , et qu'on passe de l'autre côté parce qu'on est un peu moins rapide que l'émetteur , on verra un changement de phase erroné ...