Auteur Sujet: Protocole MFX : Retour d'information des décodeurs  (Lu 4473 fois)

bk4nt

  • Full Member
  • ***
  • Messages: 106
    • Voir le profil
Re : Protocole MFX : Retour d'information des décodeurs
« Réponse #75 le: décembre 11, 2024, 10:35:08 pm »
Euh... qu'on soit d'accord, c'est pas du tout fait pour être branché sur "les rails" ...

J'imagine que c'est pensé pour être branché sur le fil d'un rail, pour en capter le courant, le courant qui circule quand le décodeur envoie son feedback.

Je dis qu'on peut se passer de ces diodes:
- Centrale, fil A, rail A
- Centrale, fil B, TR1 a, TR1 b, rail B

Où serait le risque de court-circuit? Et l'utilité d'un pont de diodes?

bobyAndCo

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1117
  • HO avec DCC++
    • Voir le profil
Re : Protocole MFX : Retour d'information des décodeurs
« Réponse #76 le: décembre 11, 2024, 10:49:37 pm »
Ok tu dis que l'un seulement des fils de la central passe dans la primaire de la bobine. Centrale, fil A, rail A. C'est assez logique en effet. Par contre je ne comprends pas ce que tu veux dire par Centrale, fil B, TR1 a, TR1 b, rail B

Pour moi TR1 c'est le secondaire, comment pourrait il être relié au rail B ?

bk4nt

  • Full Member
  • ***
  • Messages: 106
    • Voir le profil
Re : Protocole MFX : Retour d'information des décodeurs
« Réponse #77 le: décembre 11, 2024, 10:56:40 pm »
Ok tu dis que l'un seulement des fils de la central passe dans la primaire de la bobine. Centrale, fil A, rail A. C'est assez logique en effet. Par contre je ne comprends pas ce que tu veux dire par Centrale, fil B, TR1 a, TR1 b, rail B

Pour moi TR1 c'est le secondaire, comment pourrait il être relié au rail B ?

Juste comme ça, sans diodes. La loco génère un courant, le transfo le capte, et puis c'est tout. En se passant de ces diodes. Qui sont pour moi inutiles.

bobyAndCo

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1117
  • HO avec DCC++
    • Voir le profil
Re : Protocole MFX : Retour d'information des décodeurs
« Réponse #78 le: décembre 11, 2024, 10:59:29 pm »
Ok, je comprends ! A tester avec et sans.

bk4nt

  • Full Member
  • ***
  • Messages: 106
    • Voir le profil
Re : Protocole MFX : Retour d'information des décodeurs
« Réponse #79 le: décembre 11, 2024, 11:06:19 pm »
Ok, je comprends ! A tester avec et sans.

Sans ces diodes, pour moi, ça suffit. Le PT ou ces décodeurs RDS ne sont pas sensibles à une polarité. Ce qu'ils captent, c'est:

52kHz <changement de phase> 52kHz <changement de phase> 52kHz <changement de phase>

La polarité (selon l'orientation des locos sur les rails, ou selon comment c'est câblé, sur rail A ou rail B), le PT ou ces décodeurs, je pense qu'ils y sont indifférents.
« Modifié: décembre 11, 2024, 11:09:41 pm par bk4nt »

bk4nt

  • Full Member
  • ***
  • Messages: 106
    • Voir le profil
Re : Re : Protocole MFX : Retour d'information des décodeurs
« Réponse #80 le: décembre 11, 2024, 11:53:10 pm »
Voici donc un exemple de code qui me semble t’il devrait permettre de lire et exploiter les infos de retour. Vos remarques sont les bienvenues.

#include <Arduino.h>


Quant à cette idée, très simple, 64 bits in, je pense que ça ne va pas fonctionner. Parce que le nombre de bits et d'octets qui vont entrer seront aléatoires.

Pour commencer, il faudra peut être faire du shit in/affichage bit à bits. C'est possible: le RDS, c'est à 1000-1200 Baud et le serial doit pouvoir fonctionner à 115200 Baud.

Pour constater d'abord comment les messages sont "enveloppés". Puis pour adapter ensuite le code. Qui ne tiendra pas dans une routine d'interruption, une routine qui figerait tout l'ESP pendant son exécution (lente).

The data stream of the return channel transmits one bits in the idle state. The data frame is structured as follows:
. . . 11111 010 Byte1 (Byte2 ... Byte8) Checksum 111...


Au début, on a des "idle states", des 1. Ensuite, un préambule, 010. Ce n'est que après qu'on commence à avoir des data, de 1 à 8 octets.

010: le préambule, ça va commencer... Sur erreur de transmission, on aura un faux préambule, ou on le rate.

Problème majeur: on n'a pas d'info de longueur, du nombre d'octets qu'on va recevoir. On va devoir "deviner" que la transmission est terminée, sur réception d'un checksum (suivi de bits à 1).

J'aurais préféré une trame plus simple, qui facilitait tout:

. . . 11111 010 Length Byte1 (Byte2 ... Byte8) Checksum 111...

Comme on a pas "Length", il va falloir "deviner" à quel moment c'est terminé. En sachant qu'un "ByteX" pourrait très bien imiter une checksum et faire penser à tort que c'est fini...

Et s'il y a erreur de transmission, la checksum ne sera pas valide... on pourrait finir sur un timeout ou bloqué là, à l'attendre...

Recevoir et valider/rejeter ce genre de flux de données sera plus compliqué qu'un simple shift in.

De deux choses l'une:
- soit on a pas trop de bruit, tout baigne, avec juste un timeout ou des erreurs occasionnelles
- soit ce genre de message est très susceptible d'être perturbé et leur réception/correction sera compliquée

« Modifié: décembre 12, 2024, 12:15:26 am par bk4nt »

bk4nt

  • Full Member
  • ***
  • Messages: 106
    • Voir le profil
Re : Protocole MFX : Retour d'information des décodeurs
« Réponse #81 le: décembre 12, 2024, 12:54:55 am »
111...1 <010> <message> <checksum> 1111

Les "flags", ce sont les 111 (nombre indéterminés par la doc)... <010>, le début, suit le <message>, la <checksum> à la fin. Suivent encore des "flags"...

Il va falloir une routine pour détecter "l'enveloppe", et si la checksum est valide, en extraire le message.

Ca m'a fait revoir ce qu'est HDLC. Qui prévoit qu'une data imite un délimiteur ou "flag". Si rien n'est prévu lorsqu'une data imite une "checksum/flag", il va falloir se casser un peu la tête pour recevoir et valider/invalider le message. Sans y rester bloqué en cas d'erreur de transmission.

bobyAndCo

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1117
  • HO avec DCC++
    • Voir le profil
Re : Protocole MFX : Retour d'information des décodeurs
« Réponse #82 le: décembre 12, 2024, 09:41:48 am »
Bonjour,

Je comprends et je suis d’accord avec tout ce que tu dis.

Il faut ajouter à cela que la centrale sait combien d’octets elle attend en retour de la demande qu’elle a fait. La construction même de la fenêtre de retour de données créée par la centrale détermine le nombre de nombre d’octets attendus en retour. §2.2.8

C’est une piste pour avoir le nombre d’octets en retour.

Et/ou, il faut raisonner en effet en « enveloppe de message » pour pouvoir extraire les data « utiles » et oui aussi à un timeout dans le cas où rien de cohérent ne vient « conclure » l’enregistrement du message.

A ce stade, je ne pense pas que l’on puisse faire bien autrement que de surveiller à l’oscillo puis analyser les messages échangés entre la centrale et les décodeurs et adapter selon les résultats obtenus.

Par ailleurs, tu soulèves à juste titre la question de de blocage ou de lenteur dans une routine d’interruption. Mais je n’étais qu’au state premier de l’expérience. Il y a des moyens simples de contourner mais cela viendra selon moi en parallèle. Sur un ESP, on peut tout à fait imaginer une routine d’interruption qui envoie les data brutes dans une queue pour traitement parallèle. Je me demande aussi, comme tu l’as je crois déjà évoqué, si l’on ne peut pas confier cela à un ATTiny qui là aussi enverrait les data au µC.

Christophe

bk4nt

  • Full Member
  • ***
  • Messages: 106
    • Voir le profil
Re : Re : Protocole MFX : Retour d'information des décodeurs
« Réponse #83 le: décembre 12, 2024, 12:14:09 pm »
Il faut ajouter à cela que la centrale sait combien d’octets elle attend en retour de la demande qu’elle a fait. La construction même de la fenêtre de retour de données créée par la centrale détermine le nombre de nombre d’octets attendus en retour. §2.2.8

Bonjour,

Les centrales attendent des réponses précises? Hier soir, je me demandais s'il serait possible de planter ou de faire rebooter une Marklin en lui envoyant n'importe quoi. Ce serait rigolo, lors d'une expo, si on branchait un petit truc sur une voie  :)

Sur ce genre de projet, il ne faudra pas s'attendre à quelque chose de précis en retour. Surtout avec Labox, je pense, destinée à du DIY et à des développements divers.

Si la solution fini assez robuste, elle pourrait faciliter ensuite le développement d'un décodeur avec feedback, sans perturber la centrale.

Je me demande aussi, comme tu l’as je crois déjà évoqué, si l’on ne peut pas confier cela à un ATTiny qui là aussi enverrait les data au µC.

Eventuellement un tiny qui reçoit proprement, avec la centrale qui elle même valide ou non, selon le nombre d'octets attendus/reçus...
« Modifié: décembre 12, 2024, 12:23:15 pm par bk4nt »

bk4nt

  • Full Member
  • ***
  • Messages: 106
    • Voir le profil
Re : Re : Protocole MFX : Retour d'information des décodeurs
« Réponse #84 le: décembre 12, 2024, 03:24:28 pm »
Il faut ajouter à cela que la centrale sait combien d’octets elle attend en retour de la demande qu’elle a fait. La construction même de la fenêtre de retour de données créée par la centrale détermine le nombre de nombre d’octets attendus en retour. §2.2.8

Sur ce point, j'ai pu faire fausse route. Si la centrale sait combien d'octets sont attendus, et que les locos s'y tiennent, c'est plus facile. Il suffit alors de recevoir ce nombre d'octets, la checksum, puis de la vérifier. Avec un timeout simple, pour ne pas rester bloqué en cas d'erreurs de transmissions.


bk4nt

  • Full Member
  • ***
  • Messages: 106
    • Voir le profil
Re : Protocole MFX : Retour d'information des décodeurs
« Réponse #85 le: décembre 16, 2024, 06:19:03 pm »
Bonjour,

J'ai reçu le pack MS2. Avec un transfo de 2A. Dans le booster, c'est tout petit, tout est petit...

Je n'ai pas trouvé de transfo pour le feedback; il aurait pu être soudé à l'arrière du PCB. Autour du pont en H, on voit deux sondes de courant. Celle de droite, c'est manifestement comme sur Labox (motor shields, etc), une sonde de courant; une piste va vers la CPU qui a un ADC.

Le feedback MFX semble être récupéré par la sonde de gauche, en haut du pont en H. Près du PT, on voit 3 points de tests, ils seraient parfaits pour un scope; 3 signaux, le 0V est à récupérer ailleurs. Pas question de poser une sonde sur les composants, on ferait vite un court-circuit; ou il faut être prudent. On voit aussi quelques "vias" qui pourraient servir de points de mesure. On pourrait même souder quelques pattes de résistance sur certains de ces points pour faciliter les mesures (pour qu'une sonde y reste bien accrochée).

Il y a là un risque. On pourrait être tenté de prendre des mesures sur cette MS2 et en même temps sur un petit montage à transfo/PT. Pour comparer les signaux. Il faudrait alors s'assurer d'abord que les alims de ce ce booster et du circuit à transo ont bien la même référence 0V. Que le montage est Ok, sans risques de court-circuits. Avec un fil soudé entre le 0V de ce booster et le 0V du circuit à transfo/PT.

A l'arrière de cette carte, on voit une piste qui va de cette sonde de gauche vers le PT, vers la CPU aussi. Sur cette longue piste, on devrait pouvoir voir le signal RDS modulé à 52kHz. Ils ont donc réussi à se passer d'un transfo d'isolement, en intégrant une sonde à cet endroit, dans le pont. Ca a pu leurs permettre d'optimiser les coûts de production.

Le circuit à transfo garde tout ses intérêts. Il isole électriquement et reste simple, sans réglages. Ce transfo faciliterait aussi les mesures simultanés sur le booter MS2. Et ce circuit à transfo/PT peut être inséré n'importe où sur le réseau, à la sortie d'un booster dépourvu de récepteur MFX aussi.

Je n'ai pas une idée claire du fonctionnement des 4 circuits qui sont en bas à gauche sur ce booster/centrale. Vu le PCB, leurs sorties vont vers le pont en en H. C'est manifestement ce qui pilote les Mosfets du pont. vns3nv04dp... des Mosfets évolués, pas de simples transistors: https://www.st.com/resource/en/datasheet/vns3nv04dp-e.pdf

Près des prises pour les manettes, il doit s'agir un transciever CAN. Pas un bus, mais un montage en étoile... Si le bus est assez lent et comme les câbles des manettes sont courts, ça ne doit pas poser de problème.

On peut aussi remarquer quelques ferrites (dont de grosses près de l'alim et près des sorties DCC/MFX). Les industriels ont des contraintes, ce genre de circuits rayonnent, produisent du bruit susceptibles de perturber d'autres équipements. Ils sont obligés d'en ajouter pour être conformes aux normes. Au dos de cette centrale MS2, sur l'étiquette CE, je lis: "The device complies... The device may not cause harmfull interferences... The device must accept any interferrence... included intereferrences that may cause undesired operatins." On aurait juste des contraintes si on souhaitait vendre de tels produits en Europe. Ou si quelque chose qu'on a développé perturbe régulièrement la Wifi du voisin  :)

S'il y a des difficultés pour comprendre comment ça fonctionne, pas mal de choses devraient pouvoir être faites avec une MS2. L'essentiel semble être documenté. https://www.maerklin.de/fileadmin/media/produkte/CS2_can-protokoll_1-0.pdf
« Modifié: décembre 16, 2024, 07:42:56 pm par bk4nt »

bk4nt

  • Full Member
  • ***
  • Messages: 106
    • Voir le profil
Re : Protocole MFX : Retour d'information des décodeurs
« Réponse #86 le: décembre 16, 2024, 08:18:29 pm »
Christophe,

Je regardais quoi encore et comment faire avec cette MS2... Je constate que avec un scope 4 voies, tu n'auras aucune difficulté pour voir comment le tout fonctionne  :)

https://forum.3rails.fr/t/railuino-la-bibliotheque-pour-commander-son-reseau-en-diy-avec-le-protocole-can-de-marklin/27168/3

bk4nt

  • Full Member
  • ***
  • Messages: 106
    • Voir le profil
Re : Protocole MFX : Retour d'information des décodeurs
« Réponse #87 le: décembre 17, 2024, 01:13:39 am »
Je continue d'ausculter la Gleisbox MS2. Qui m'intrigue.

Côté "CAN", on remarque un transceiver RS485/RS422, un MAX3085. Les boites noires sur la droite sont des ferrites. A côté du MAX, une résistance de 120 Ohm. Deux ports, pour un branchement vers deux manettes. Sur un bus CAN on a normalement une 120 Ohm aux extrémités seulement.

En entrée du PT, j'ai un "K3WI 1". Aucune idée de ce que c'est. Juste des diodes ou autre chose. Des deux côtés, deux pattes sont en court-circuit. Soit ce sont des diodes, soit c'est plus évolué. A ce format, il existe des portes logiques programmables, des microprocesseurs aussi.

Pour le pont en H, d'un côté, un mosfet évolué (avec des protections), de l'autre, un banal IRF736 (dual P Mosfet). Et ce circuit pour le feedback RDS... Je suis curieux d'apprendre comment ce circuit feedback fonctionne.

Le pont en H est piloté par un CD4555 (avec les 4 groupes de composants). Un décodeur binaire 1 vers 4. Je me demande aussi comment ça peut fonctionner.

bk4nt

  • Full Member
  • ***
  • Messages: 106
    • Voir le profil
Re : Re : Protocole MFX : Retour d'information des décodeurs
« Réponse #88 le: décembre 17, 2024, 08:52:46 pm »
Je renouvelle aussi ma proposition de vous fournir tous les composants si toute fois vous souhaitiez réaliser des tests de votre côté.

D'après ESU, la MS2/Gleisbox doit être dans une version minimale pour que tout fonctionne... mon kit semble être Ok. J'attends deux ESU multi protocoles, dont M4, qui serait MFX. Ou c'est juste une version minimale pour la détection de nouvelles locos:
https://www.esu.eu/en/support/faq/digital-systems/m4-data-protocol/ "The software version of the command station is not older than V3.0.1."

C'est assez obscur dans ces docs, et je n'ai pas tout lu... La MS2/Gleisbox fait aussi du DCC seulement, sais tu si elle a un cutout Railcom dans ce mode (elle n'a pas un tel récepteur)?

As tu prévu de faire un mini PCB façon breakout pour périphérique Arduino, avec le transfo, le PT et quelques points pour raccorder les différents câbles et signaux? Un mini PCB avec quelques points de tests pourrait tout faciliter.

J'ai trouvé cette non solution qui pourrait aider. Non solution car avec les taxes et les frais, c'est à plus de 50€....
« Modifié: décembre 17, 2024, 09:29:56 pm par bk4nt »

bobyAndCo

  • Global Moderator
  • Hero Member
  • *****
  • Messages: 1117
  • HO avec DCC++
    • Voir le profil
Re : Protocole MFX : Retour d'information des décodeurs
« Réponse #89 le: Aujourd'hui à 03:58:07 pm »
Bonjour à tous,

Depuis deux semaines je n’ai que très succinctement survolé le forum et ce fil car je me suis totalement investi dans l’introduction de la technologie RMT de Espressif dans ma centrale MFX sur base de laBox

C’est maintenant terminé et je suis très satisfait du résultat la génération du signal de voie est plus précise et plus stable sur l’ESP32 qu’au travers des timers. Je rappelle que c’est ce procédé qu’utilise également DCC-Ex pour son soft (mais uniquement pour l’ESP32)

https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/peripherals/rmt.html

Ces captures à l’oscillo montrent bien les trames parfaites pour les bits 0 à 100µs et pour les bits 1 à deux alternances de 50µs.





Le programme est sur mon Github : https://github.com/BOBILLEChristophe/directMFX_ESP32

Réaliser cela sans oscillo aurait été très compliqué et probablement que j’aurais abandonné avant la fin. Merci à bk4nt pour ton aide et tes précieux conseils.

Merci également à Dominique, Thierry et... Michel car je réutilise le hard de laBox sans avoir eu besoin d'y apporter la moindre modification. Je challenge sera peut-être un jour de réaliser uneBox DCC et MFX (M4) comme le font beaucoup de centrales.

Je vais maintenant pouvoir me consacrer à l’implantation du retour d’information dans cette centrale.

Christophe


« Modifié: Aujourd'hui à 04:36:34 pm par bobyAndCo »