Seuils de détection des essieux avec ou sans RailCom

GrandCharles a écrit:

Ca s'applique également sur l'essieu alors ?
Charles

Il s'agit d'un vernis contenant du graphite en suspension, donc, bien remuer avant usage.
Une petite couche pour recouvrir la rondelle plastique isolante des essieux et établir la liaison entre roue métal et essieu métal.
Laisser sècher, puis mesurer à l'ohmmètre... d'ordinaire, avec les détections Viessmann, LDT, Tams ou DR4088 Digikeijs, 5k à 10Kohms est une bonne valeur.
Résistance trop élevée = ajouter une couche, résistance trop faible = gratter un peu...
Dans certains cas, ce n'est pas possible, lorsque l'essieu est constitué de deux 1/2 essieux réunis par un tube plastique, mais ce procédé est assez rare.

Bonjour,
J'ai aussi des DR5088 et en effet sur certaines locos, si les feux ne sont pas en position "on" la loco n'est pas vu par le détecteur d'occupation.
Par contre, j'ai du rater quelque chose sur la config de RRTC sans rail com.
J'explique :
J'ai quelque fois des ratés de commande d'une aguille qui mène à la gare cachée faite par un Arduino.

Dans ce cas, ou une aiguille n'avait pas physiquement tourné, j'ai eu des collisions car RRTC n'a pas réagi qu'il y avait une détection de train non attendu sur un canton.
Avec railcom, dès qu'une adresse est détectée sur un autre canton que celui prévu, tout s'arrête.

Mais il y a peut être une option que je n'ai pas activé

Bonjour, dans les propriétés du trajet, "règles" il y a dans le paragraphe "sécurité" une option "protection limitée contre les aberrations" qui permet d'arrêter le train s'il sort du trajet prévu (c'est pas du 100%).
A+

philippech a écrit:

si les feux ne sont pas en position "on" la loco n'est pas vue par le détecteur d'occupation.
Par contre, j'ai du rater quelque chose sur la config de RRTC sans rail com.

Pour ce qui est de cet état de fait tu as eu la réponse plus haut. Tu as choisi un détecteur qui ne sait pas détecter un décodeur en veille !

Ensuite, ce n'est pas dans TC qu'on désactive RaiCom mais dans le décodeur via la CV29. Ce n'est pas toujours la même valeur, voir la notice du fabricant.

philippech a écrit:

J'ai quelque fois des ratés de commande d'une aguille qui mène à la gare cachée faite par un Arduino.

Dans ce cas, ou une aiguille n'avait pas physiquement tourné, j'ai eu des collisions car RRTC n'a pas réagi qu'il y avait une détection de train non attendu sur un canton.
Avec railcom, dès qu'une adresse est détectée sur un autre canton que celui prévu, tout s'arrête.

Mais il y a peut être une option que je n'ai pas activé

Je n'ai pas d'expérience avec le RailCom mais à priori ça sert aussi à ça, puisque le décodeur renvoie son identité et son état de fonctionnement, et la rétro-signalisation précise d'où vient cette information.

Papybricolo a écrit:

Quand au Railcom je n'en ai pas trouvé d’utilité ! à part me mettre automatiquement des adresses quand je programme un nouveau décodeur avec ma centrale alors que j'aime bien les choisir moi même  

C'est parce que tu utilises une centrale ESU... Avec la CS3 de Märklin ce serait pareil ! Avec Lenz LZV100, nous sommes peinards... pour l'instant !

Bonjour Philippe,

philippech a écrit:

J'ai aussi des DR5088 et en effet sur certaines locos, si les feux ne sont pas en position "on" la loco n'est pas vu par le détecteur d'occupation.

Le constructeur donne 10-15 mA comme sensibilité, cela veut dire que le décodeur consomme moins que ça "à l'arret" et sans sortie activée. Je pensais en utiliser pour un réseau 2 rails mais je vais tester et faire attention à ce point... car cette remarque ne me plaît guerre au niveau de la fiabilité de détection.

philippech a écrit:

J'ai quelque fois des ratés de commande d'une aguille qui mène à la gare cachée faite par un Arduino.

Je pense qu'il faut résoudre le problème à la source, c'est à dire comprendre pourquoi vos aiguillages ne répondent pas aux ordres.
Vous parlez d'Arduino mais comment sont commuté exactement vos aiguillages (via quelle centrale, quel décodeur d'accessoires)

Bonjour Yann,
Oui en effet ce point sur le seuil de consommation m'avait échappé et je ne comprenais pas pourquoi certaines loco n'étaient détectées à l'arrêt. Cela peut être perturbant.

Pour les aiguilles commandées par l' Arduino :
L'Arduino reçoit les ordres DCC de la centrale (Z21) comme un détecteur d'accessoire. L'Arduino commande les servos des aiguilles . Le programme embarqué dans l'Arduino est celui de "mardec".
Globalement cela marche, mais après coup, je me suis aperçu que "mardec" ne marche pas si le railcom est en service sur la centrale. Et compte tenu que j'ai aussi quelque fois des ratés, même sans le railcom, j'ai approvisionné deux DR4024 pour remplacer l'Arduino. J'ai déjà deux autres DR4024 en service qui ne posent pas de problème et qui sont très facile à programmer pour ajuster la course du servo.

coquelicot94 a écrit:

Bonjour, dans les propriétés du trajet, "règles" il y a dans le paragraphe "sécurité" une option "protection limitée contre les aberrations" qui permet d'arrêter le train s'il sort du trajet prévu (c'est pas du 100%).
A+

merci, dès que j'ai un moment je vais essayer cela en manœuvrant un servo à la main pour simuler une erreur de commande et voir comment TC réagit

Lorsque l'on veut un fonctionnement impeccable, il faut se méfier des systèmes exotiques... qui fonctionnent "globalement"...

Sur mon réseau de test, j'ai aussi un Mardec pour 5 servo. Si je les active avec ma WLANmaus, l'état change bien dans TC. Ma centrale (DR5000) a bien le Railcom qui est activé.
J'avais eu des soucis lors des essais sur mon premier réseau, mais en créant mon réseau de test actuel, j'ai vu qu'il y avait une mise à jour pour le Mardec (entre autre) sur le site ArCoMoRa et je n'ai pas eu de problème depuis sa mise en route.

Charles

Bonjour Charles,
Merci de l'info, j'ai raté cette mise à jour.
Mais pour l'instant, je vais remiser l'Arduino et installer deux décodeurs "non exotique" comme indique Elie pour fiabiliser ce point et voir tourner les trains sans craindre une collision

GrandCharles a écrit:

Alors, sachez qu'après avoir fait des essais, une simple résistance d'1 ou 2k sur les voies affichent bien l'occupation.

Bonjour,

Je trouve cela extrêmement bas comme valeur... et donc un courant beaucoup plus important... hallucinant qu'un module de détection demande autant de courant pour une détection...

Comme l'a dit Christophe, c'est pile poil pour le train de jardin...

DiCoS69 a écrit:

Comme l'a dit Christophe, c'est pile poil pour le train de jardin...

Oui pour ce point précis de la sensibilité, d'un autre côté chaque section de détection est limitée à 3A ce qui me semble un peu limite pour un train de jardin...

Yann a écrit:

DiCoS69 a écrit:

Comme l'a dit Christophe, c'est pile poil pour le train de jardin...

Oui pour ce point précis de la sensibilité, d'un autre côté chaque section de détection est limitée à 3A ce qui me semble un peu limite pour un train de jardin...

Effectivement 3 A ce n'est pas beaucoup. Mais il y a rarement une telle consommation dans un canton. 1,8 à 2 A est une valeur moyenne constatée avec la centrale 1200Z Massoth qui donne une indication instantanée de l'ampérage pour une rame en rampe de 30/000.