Le "courant digital", est-ce un courant continu?

Je me permets de déplacer la question pour ne pas tuer un sujet dans une toute autre rubrique.

Eh bien - non. Comme apparemment ma parle ne te convainc pas, je te renvoie vers
http://centredcc.fr/le-dcc/

La tension sur la voie varie en permanence entre +MAX et -MAX (MAX dépend de la centrale utilisée, en général MAX = 18 V).

  • Un court +MAX suivi d’un court -MAX représente un 1.
  • Un long +MAX suivi d’un long -MAX représente un 0.

Les images sur ce site-là le montrent bien. D’ailleurs, si tu branches un voltmètre à cc sur ta centrale DCC, elle affichera 0. La tension résultante, donc la somme de tous les “plus”, moins tous les “moins”, est zéro.
Si tu poses sur les rails une locomotive analogique avec moteur à courant continu, et qui n’a ni décodeur ni inverseur électronique pour système Märklin, elle ne va absolument pas rouler, puisque son moteur est en permanence stimuler avant-arrière-avant-arrière ; et du fait des champs magnétiques qui se forment, elle va chauffer, surchauffer et cramer. Fini.

Effectivement, il y a 40 ans Monsieur Lenz avait proposé un système pour faire fonctionner une loco analogique sur système digital, mais à condition qu’elle roule pratiquement en permanence ou qu’elle soit arrêtée sans alimentation : l’astuce était d’inégaliser le signal, que donc le max(+) et le max(-) n’étaient plus de même valeur, et la différence fait tourner le moteur. Or, plus il fonctionne lentement, donc plus la différence entre max(+) et max(-) est petite, plus le moteur chauffe et risque de partir en fumée ! On a donc très vite abandonné ce bricolage. (Un ingénieur peut beaucoup mieux pour moi expliquer le pourquoi de cet effet, mais le résultat me suffit largement !)

Pour un moteur Märklin classique, c’est différent : c’est un moteur tous courants, il peut fonctionner très bien avec du courant alternatif à fréquence basse (50 Hz est une fréquence basse pour cette classe de puissance), mais aussi avec du courant continu et, mais moins bien, avec du courant alternant à haute fréquence. (Que le DCC ou le mfx n’ont pas de “fréquence” puisque les espacements entre les changements de sens du courant ne sont pas régulier, peut être négligé ici.)

Une petite différence existe pour le bon vieux protocole MM, de première et deuxième génération : contrairement au DCC, il n’est pas symétrique. Il contient plus de temps en “moins” qu’en “plus”, donc la tension résultante n’est pas 0. N’empêche que là encore, c’est très mauvais pour le moteur cc puisqu’il est en permanence stimulé dans les deux sens.

Donc, non, le “courant digital” n’est pas un courant continu.
Et il faut surtout éviter l’amalgame entre “DC” et “DCC” mais aussi entre “DC” et “2 rails” puisque ce dernier induit le néophyte dans le premier.

4 « J'aime »

Bonjour,

Le courant digital d’une centrale est il bien un courant haché ?
Philippe

Bonjour Philippe,

Si l’on veut… Mais c’est un signal carré modulé en durée. :slightly_smiling_face:

Oui le courant pour des locomotives en digital est un courant haché effectivement comme l’a expliqué Wolfram. Ce sont bien des alternances très rapides entre le +18 et le -18V avec des durées précises qui permettent au décodeur de savoir si le bit est un 0 ou un 1.

En DCC, un bit 1 est réalisé par un front haut (+18V) de 26µS et un front bas (-18V) de 26 µS. Le bit 1 est donc échangé sur +/- 52µS.

Pour le bit 0 la durée négative doit être > à 50µS et positive également > à 50µS.

Marklin n’a pas rendu public (pour les raisons que l’on imagine bien) la construction exacte du signal, des alternances et des durées.

J’ai quelque part copie d’un travail gigantesque réalisé par un groupe de 3 ou 4 personnes qui ont cherché à mesurer tout cela de façon empirique. Nous arrivions à des choses assez similaires au DCC.

Mais même en connaissant cela, on est loin de maitriser le protocole, c’est-à-dire la construction exacte des trames, leur répétition etc… qui permet au décodeur de traduire les commandes envoyées.

Si quelqu’un est intéressé, je pourrai essayer de retrouver ce travail qui permet entre autres choses de générer des ordres au décodeurs en s’affranchissant des centrales avec un microcontrôleur de type AVR (Arduino…) qui fait cela très bien. Même un ATTiny peut suffire. Ou un ST32. Par contre, l’ESP32 n’est pas champion pour cela.

Christophe

Le “courant digital” est un courant digital… et rien d’autre.
Cela est tellement spécifique qu’il ne rentre pas dans les tensions usuelles telle que continue, alternative, ou une modulation.

Même si cela rentre dans le courant haché au sens large, ce terme désigne plutôt l’alternance entre l’absence de tension et la pleine tension, ce qui n’est pas le cas du numérique.

Ça c’est toujours faux à 100%
Le MM1 et le MM2 ont été documentés dès leur commercialisation et cela même avant que le DCC existe.
le mfx est documenté, je t’ai déjà fournis un lien vers la documentation dans une autre discussion.

Delias

Wolfram,

Tu as raison Wolfram, j’avais toujours pensé que les packets de commandes modulaient un signal DC ou AC suivant les cas. Cependant dans les description que je lis Digital Command Control - Wikipedia, le signal digital, n’est pas référencé par rapport à la masse. Une de mes lectures mentionne que les signaux sont toujours montrés avec une ligne au milieu faisant penser à la référence de masse, sans en être une. Ceci entraine une petite confusion dans le esprits.

Quant à tes remarques sur les associations 2R-DC-DCC elles viennent je pense du fait que chez la plupart des fabriquants, les systèmes 2R étaient alimentés en DC et les 3R en AC. Il y a eu des exceptions mais je ne retrouve plus lesquelles. Et de plus le DC de DCC ne veut pas dire Direct Current Control mais bien Digital Command Control.

Il semble rester quelques mystères autour du système Märklin et de son signal. Je n’ai rien trouvé comme belle explication sur le net.

En tous cas, merci pour ces précisions, on en apprend tous les jours.

Bonne semaine,

MarcD

Bonjour Delias

Ce n’est pas de ces commandes en CAN à la centrale dont il s’agit dans ce fil mais du codage bit à bit envoyé via les rails aux décodeurs et qui constitue la forme caractéristique du signal

La documentation à laquelle tu fais référence est « Kommunikationsprotokoll »: https://streaming.maerklin.de/public-media/cs2/cs2CAN-Protokoll-2_0.pdf

Mais ne concerne pas le codage qui circule sur les rails qui, je confirme, n’a jamais fais l’objet d’aucune publication par Marklin.

A titre de comparaison, voici comment est structuré un paquet type de commande en DCC.

Un bit est constitué par une alternance “haute” et une autre “basse”. C’est la durée de chaque alternance qui permet au décodeur de déduire s’il s’agit d’un bit 1 ou d’un bit 0.

Un préambule qui est généralement une suite de 16 bits à 1. Le décodeur en déduit que ce qui va suivre est une commande.

Le second paquet (sur 8 bits) est l’adresse de la locomotive.

Le troisième paquet, la commande dont il est demandé l’exécution. Notez qu’il peut y avoir plusieurs paquets de 8 bits pour quelques commandes.

Enfin, un dernier paquet de 8 bits pour la détection d’erreur.

La source de ces informations est le NMRA qui a normalisé le standard DCC : https://www.nmra.org/sites/default/files/s-92-2004-07.pdf

L’étude dont je parlais pour le codage spécifique de Marklin à cherchée à analyser chaque commande CAN pour voir comment est était codée en bit à bit ce que font la CS2 ou la CS3 par exemple. Cette recherche montre que le codage de Marklin est très similaire à celui du DCC.

Ce domaine est assez passionnant car, comme on peut l’imaginer, il est alors possible de communiquer directement avec les décodeurs.

Christophe

PS : J’ai retrouvé ce document que je vous joins :
Schienenformat.pdf (568,3 Ko)

1 « J'aime »

PWM : Pulse Width Modulation : Modulation par largeur d’impulsions.

1 « J'aime »

Document dont j’avais mis le lien dans ma première réponse à ton premier sujet technique sur le forum.

De ce que j’en ai parcouru, le docu me semble complet, la première version est assez ancienne et il a suivi l’évolution du protocole.

Oui c’est bien ce document qui traite du codage bit à bit des commandes envoyées via les rails aux décodeurs et des décodeurs à la centrale (via les rails).

Mais ce document n’émane pas de Marklin. Quand je dis que Marklin pas rendu ce protocole public, il n’y a aucune critique de ma part, juste un constat. Je ne vois rien d’anormal à ce qu’une entreprise commerciale protège ce qui constitue son retour d’investissement et ses profits.

1 « J'aime »

J’avais pas mal épluché ce document. Traduire les commandes en bit à bit vers les décodeurs ou lire les informations en provenances du décodeur est complexe.

Je m’intéressais au retour d’information (l’équivalent de Railcom en DCC) qui permet un retour par lequel les décodeurs mfx® envoient des informations à la centrale.

Le mode de fonctionnement pour le déclenchement est assez similaire à celui du Railcom, mais pour le retour, Marklin utilise le RDS, technique utilisée en radio pour faire circuler des informations texte en même temps que le son (nom du morceau de musique par exemple). Il faut un décodeur spécial dans la centrale.

Mais il y a beaucoup de choses que je n’ai pas comprises et de plus, je ne trouve plus de décodeurs RDS, TDA7478 (https://www.st.com/en/automotive-infotainment-and-telematics/tda7478.html)