Voilà j’ai une question un peu complexe pour ceux qui ont la chance de posséder une CS ou une ECOS.
La norme DCC spécifie deux modes différents pour commander des accessoires (aiguillages, signaux, pont tournant, etc.). Dans les documents précisant cette norme, le premier mode est appelé “mode basique” , le second mode est appelé “mode étendu”
Le mode basique est celui bien connu qui permet de commander des accessoires simples comme des aiguillages ou des signaux. Le mode étendu est plus complexe, il permet en utilisant une seule et unique adresse de commander des accessoires pouvant avoir jusqu’à 32 états possibles; par exemple un feu qui pourrait être rouge/rouge, rouge, rouge clignotant, jaune, jaune clignotant, vert, vert clignotant peut en mode étendu être piloté en n’utilisant qu’une seule et unique adresse.
Évidemment pour utiliser le mode étendu, le décodeur doit être prévu pour fonctionner dans ce mode et la centrale doit savoir émettre les messages spécifiques à ce mode.
Ma question porte sur le mode étendu …
Ne possédant ni ECOS, ni CS je voudrais savoir comment ces centrales proposent dans leurs menus la possibilité d’utiliser un décodeur fonctionnant en mode étendu.
Est ce que certains parmi vous auraient déjà utilisé des décodeurs qui implémentent ce mode avec une de ces centrales?
La CS2 ne le permet pas au niveau de l’interface graphique.
Par contre, cette possibilité apparait dans la spécification du protocole CAN, donc serait à priori possible depuis un PC. Cette doc au format HTML n’est disponible que depuis la CS2. Un pdf est disponible sur le site de Märklin mais il s’agit d’une très vielle version datant d’avant le DCC sur la CS2.
Mais à savoir si le GFP (Gleis Format Prozessor) le permet, c’est une autre question à la quelle je ne peux pas répondre. D’ailleurs je ne connais aucun décodeurs prévu pour cela.
Cela peut être sympa pour les signaux.
A noter que pour la prochaine sortie de la version logiciel 4.0 annoncée comme nécessaire pour commander les nouveaux signaux mFX (les sémaphores) qui seront les premiers signaux au protocole mFX. Peut-être que cette possibilité sera utilisée. (C’est de la pure supposition!!!)
Je suis un peu surpris que la CS ne sache pas utiliser cette fonctionnalité qui simplifie considérablement la vie dans certains cas…
Je me posais la question parce que je fais mon électronique moi même, mais je cherche quand même à respecter les standards au cas où un jour je voudrais acheter une centrale du commerce.
J’utilise ce mode étendu pour certains de mes décodeurs, par exemple pour déplacer mon pont transbordeur je passe sur une adresse unique le numéro de la voie sur laquelle je veux faire aller le pont et le décodeur se débrouille tout seul pour amener le pont en face de la voie souhaitée…
Donc je me suis posé la question de savoir comment faire si je voulais faire fonctionner ce décodeur avec une CS ou une ECOS et j’apprends que je ne pourrais pas C’est dommage.
Maintenant ta réponse attise ma curiosité … Tu parles de spécification du protocole CAN … c’est quoi? et où puis je trouver une documentation à ce sujet? Si tu pouvais m’indiquer où je peux trouver des informations là dessus, ce serait sympa …
Concernant le GFP, je suppose qu’il s’agit de la partie “bas niveau” de la CS qui formate et organise les messages pour les envoyer vers la voie … Si c’est ça il ne devrait pas y avoir la moindre difficulté, qu’on utilise le mode basique ou le mode étendu le message émis est toujours un message au format DCC; c’est juste la manière d’interpréter le contenu qui diffère.
La centrale ECOS2 (au moins) peut communiquer avec les booster via les EcosLink au travers d’un bus Can. C’est un système de communication qui s’appuis certainement sur un protocole mais on parle plus de Bus. Ce type de bus a été, je crois développer a l’origine pour les véhicules automobiles (multiplexage) afin de véhiculer toutes les informations nécessaires au véhicules modernes sur un nombre de fils réduit.
Jean Louis, fait des recherches sur “Bus Can” et pour exemple :
Oui il s’agit bien du Controller Area Network de Bosch.
Introduit par ESU pour la conception de la CS1. Il est présent au moins dans les systèmes numériques de Märklin (CS1 et CS2), ESU (Ecos), La Z21 de Fleischmann/Roco (c’est du Zimo) et le projet OpenLCB soutenu par la NMRA (Ils ne sont pas compatible entre eux). Un système de modules compatible MS1, CS1, MS2, CS2, Ecos est commercialisé sous le nom de projet CAN Digital Bahn et donne une bonne idée des capacités de ces systèmes.
La doc de Märklin, version 1.0 de septembre 2008 est disponible sur le site web de Mär.. Les docs plus récente ne sont disponible que sur le web-server de la CS2. Et je ne pense pas que je puisse les diffuser sur internet.
La communication avec le PC au moyen de l’Ethernet s’effectue de deux manières. Un web-serveur pour l’accès à une partie de la config et l’aide et une passerelle UDP/CAN pour le pilotage du réseau.
Je suis au début de la conception de mon prog PC + de mes modules, et j’ai juste fait un sniffer du bus CAN, Au regards du ping et des trames échangée, la CS2 a deux parties logique, Le GUI et le GFP. Le GUI s’occupe de l’interface humain de la CS2 (écran et boutons), des automatismes de navettes et des memory et le GFP s’occupe du signal envoyé aux voies (sortie normale, sortie programmation et probablement sortie booster 6015/6017). Les MS2 branchées en additionnel, les boosters nouvelle génération (60174), le connet-6021 se branchent sur le bus CAN, au moyen des connecteurs mini DIN.
Pour illustrer ma question, j’ai fait une petit video montrant les différents configurations d’un signal SNCF commandé par un décodeur de ma réalisation qui utilise le fameux mode DCC étendu.
Les commandes possibles sont :
0 : tout éteint
1 : feu vert = voie libre
2 : feu vert clignotant = voie libre vitesse limitée à 160 km/h
3 : feu rouge = arrêt, peut être franchi en marche à vue après arrêt complet
4 : feu rouge clignotant = peut être franchi en marche à vue sans arrêt complet
5 : double feu rouge appelé carré rouge = arrêt, ne doit pas être franchi
6 : jaune clignotant = avertissement
7 : double jaune fixe = rappel de ralentissement à 30 km/h
8 : double jaune clignotant = rappel de ralentissement à 60 km/h
9 : jaune fixe + double jaune clignotant = bifurcation avec rappel de ralentissement …
Je ne suis pas spécialiste de la signalisation ferroviaire, je me suis peut-être trompé et j’ai sûrement oublié des combinaisons, le jaune fixe par exemple …
Maintenant des images parlent plus que des paroles … Excusez moi c’est petit, c’est de l’échelle N
Une autre question concernant les centrales et le codage DCC:
D’après la norme pour les décodeurs d’accessoires DCC l’adresse du décodeur est stockée dans la CV1 (6 bits de poids faible) et dans la CV9 (3 bits de poids fort)
Mais cela c’est pour un décodeur classique type K83 avec 4 sorties d’appareils de voie …
Quand on utilise un décodeur individuel du type 74461 on doit aussi mettre quelque part un numéro (1 à 4) qui correspondant à la position qu’aurait l’appareil sur un K83 … Qui peut me dire sans quelle CV est stocké ce numéro?
Je n’arrive pas à trouver cette information dans le texte de la norme.
Dans les deux bits restant du CV1 (idéalement les LSB du CV), c’est comme cela que fait Märkin pour son nouveau décodeur (sinon pourquoi séparer l’adresse en 3+6 bits au lieu de 1+8bits). Je ne m’intéresse pas trop à ce type de décodeur, mais je ne connais pas d’autre décodeurs de ce type qui se programment avec des CVs.
Cela me parait logique mais comme la norme DCC dit que la CV1 doit contenir les 6 bits de poids faible de l’adresse du décodeur, je cherchais où mettre les 2 derniers …
En fait cela n’a pas trop d’importance, il suffit que la notice du décodeur le précise.
L’histoire du “6+3” doit avoir des origines lointaines datant de l’époque où l’électronique était lente …
Le bit de poids fort (bit7) du premier octet de commande en DCC spécifie s’il s’agit d’une locomotive (bit7=0) ou d’un accessoire (bit7=1).
Cela explique pourquoi seules 127 adresses sont utilisables en adressage court.
Si bit7=1 , bit 6 sert à spécifier un autre truc (je ne me souviens plus quoi) donc il reste 6 bits pour l’adresse d’un accessoire et cela explique pourquoi seuls 64 décodeurs de 4 appareils pouvaient être adressés à l’origine.
En mettant l’adresse dans CV1 on construit le premier octet de commande juste en copiant CV1 (dans les cas des locos) et en mettant à 1 le bit 7 s’il s’agit d’un accessoire, c’est rapide et facile …
