J’ai vu qu’ESU propose enfin (ce n’est pas trop tôt ) un décodeur d’APV (Appareil de Voie) capable de retourner l’information des fins de course d’aiguillage à la centrale et que l’ECOS utilise cette information.
J’ai aussi lu que RRTC devrait prochainement l’intégrer.
Mais ESU utilise le protocole Railcom.
A votre avis, est ce que Märklin va suivre et un jour ou l’autre proposer la rétrosignalisation des appareils de voie en mfx?
Quand tu sais que des TJD étroites sont demandées par tous, en vain, depuis des années, ce serait fort étonnant de les voir s’attaquer aux décodeurs et aux aiguillages, juste pour ceux qui veulent les rétrosignaler.
Quand tu sais que des TJD étroites sont demandées par tous, en vain, depuis des années, ce serait fort étonnant de les voir s’attaquer aux décodeurs et aux aiguillages, juste pour ceux qui veulent les rétrosignaler.
Bonjour Christian,
Il faut voir avant tout que pour l’utilisateur c’est un plus qui ne coute rien!!, il n’y a strictement rien à rajouter.
Tu branches ton aiguillage au décodeur de façon tout à fait classique et l’icône de l’ECOS reproduit la position de l’aiguillage, si tu bouges l’aiguillage à la main, l’icône suit
En fait il suffit d’une bricole sur le décodeur et de la prendre en compte dans le logiciel.
Le décodeur voit la position des aiguillages grâce aux fins de course déjà existants, c’est super facile (mes décodeurs “made in ta_prohm” fabriquées en 1986 le font déjà!!) et la position est renvoyée à la centrale via le protocole bidirectionnel Railcom qui est le pendant du mfx en DCC. (par contre mes décodeurs demandent un fil supplémentaire, “ta_prohm” ne sachant pas faire de bidirectionnel )
En DCC, ESU le propose avec le switchpilot et TAMs avec le WD34.
La centrale ECOS l’intègre et d’après ce que j’ai lu, RRTC devrait s’y mettre.
Donc le DCC s’y met enfin, pas trop tôt
Penses tu que Märklin ne va pas réagir? …
Je trouve très stupide qu’un PC puisse créer des itinéraires, mais ne puisse pas vérifier que tous les aiguillages ont bien obéi aux ordres.
Je trouve très stupide qu’un PC puisse créer des itinéraires, mais ne puisse pas vérifier que tous les aiguillages ont bien obéi aux ordres.
L’asservissement a cela de bon qu’il est maîtrisé. Si on atteint cela, le fonctionnement des navettes n’en sera que plus affinable dans son fonctionnement
Il y a un point que je viens de réaliser en faisant mes bidouilles.
En Motorola comme en DCC, la centrale envoie 16 fois une commande pour être **presque **sûre que le décodeur la recevra; cela rend les protocoles lents.
En Motorola par exemple il ne faut pas moins de 2,2 secondes pour envoyer 10 commandes seulement
En utilisant la rétrosignalisation, la centrale est avertie dès que la commande est prise en compte et pas besoin de renvoyer la commande
Donc non seulement, on est informé, mais en plus les temps de réaction deviennent considérablement plus courts. Pour celui qui fait rouler 10 trains ou plus sur son réseau, ce n’est peut-être pas négligeable; je ne sais pas, je ne fais plus rien rouler
) un décodeur d’APV (Appareil de Voie) capable de retourner l’information des fins de course d’aiguillage à la centrale et que l’ECOS utilise cette information.
,
