Présentation de Pierre

Bonjour,

Je construit actuellement un réseau en N (actuellement 60m de voies de posées en PECO code55).

Vous pouvez me trouver sur le Forum du N ("Chemin de Fer Miniature du Val d'Ozon")

J'en suis à informatiser le réseau en Digital.

Je m'intéresse à RRTC et je pense le tester en version Bronze pour commencer et l'upgrader après.

Je viens de tester un peu iTrain qui est sympa à utiliser.

J'ai une rétrosignalisation avec des détecteurs de courants que je fabrique reliés à un microcontroleur Arduino qui me
génère le protocole S88.
L'Arduino est relié à une Intellibox, elle-même relié à un PC sous XP.

L'Arduino peut me gérer 64 détecteurs pour 25€ ( qui a dit que la rétrosignalisation coûte chère...)

Bon, allez je télécharge RRTC...

  Cordialement

Bonsoir et bienvenue collègue N'iste et presque voisin ...
Pour l'exploitation de ton réseau, avec RRTC tu ne seras pas déçu à condition d'oublier la version Bronze (qui n'est pour moi qu'un ersatz de Train Controller ... ).
Au niveau des aiguillages, tu utilises quels moteurs et quels décodeurs d'accessoires ? Au passage, tu peux mettre toutes ces infos techniques dans ta signature (menu profil/signature). Cela facilitera le prochains échanges ...
Bon tests de RRTC ...

A+
Georges

Bonjour,

Je vais rapidement passer à la Silver, mais je m’entraîne avec la Bronze.

Je n'ai pas encore de moteurs et décodeurs d'accessoires, je viens à peine de terminer la pose des voies.

Cordialement

Bonsoir Pierre, et bienvenue.

Passe plutôt en Gold, que des avantages.

Bienvenue a toi , +1 pour gold , mais tu peut aussi la télécharger et te faire une idée en mode démo utilisable pendant 30 jours non consécutifs

pierrepv a écrit:

  Bonjour,

Je vais rapidement passer à la Silver, mais je m’entraîne avec la Bronze.

Je n'ai pas encore de moteurs et décodeurs d'accessoires, je viens à peine de terminer la pose des voies.

 Cordialement

Bienvenue Pierre...

Il ne sert à rien de tester la "bronze" si tu veux acquérir la "silver", il y a un monde d'écart entre les 2 et ton travail sur la "bronze" sera perdu...

Attention à ne pas trop pavoiser avant d'avoir testé réellement ta rétro... quand il y a du monde sur le réseau, ça devient plus "hard"... même pour Arduino...

Bonsoir,

Justement l'intérêt de l'Arduino c'est que la gestion
des 64 modules de rétro se font dans un seul
micro contrôleur donc moins de fils risquant de
prendre des interférences.
Je suis un fana d'Arduino et c'est un super produit
pour le modélisme ferroviaire.

Bonsoir Pierre,

Je crains que Elie n'ait raison.

Arduino est sans doute très bien pour le modélisme ferroviaire pour gérer quelques opérations simples. De là à lui confier la gestion de la rétrosignalisation de 64 cantons, c'est un pas que je ne franchirais pas.

Jean

Bonsoir,

L'avantage de l'Arduino, c'est qu'il n'y a pas d'électronique,
Juste de la programmation.
Moi je vais essayer et je vous tiendrais au courant.
J'aime bien sortir des sentiers battus et innover.

Cordialement

Arduino, ce n'est pas de l'innovation... c'est un support commercial de Atmel, fabricant de µC.
Des µC, il y en a maintenant dans tous les modules que nous utilisons pour le train miniature, et ce que tu as fait avec ton Arduino, c'est reproduire le schéma d'une détection S88 créé par Marklin à l'origine.
Ce ne sera par exemple, pas comparable avec un système RS de Lenz ou même un HSI88 de LDT qui dispose de 3 bus et d'une tension de 16/18v qui y circule...
Avec Arduino, tu es sous 5v et tu devras tout mettre en œuvre pour éliminer les parasites sur le réseau car la marge entre l'état 0 et l'état 1 est réduite.
Cela dit, c'est une bonne expérience...

Bonjour et bienvenue.

Poupy

Bonjour Pierre et bienvenue.

pierrepv a écrit:

...
J'aime bien sortir des sentiers battus et innover.
...

Je suis une fois de plus d'accord avec ce qu'a écrit Elie. Avec Arduino tu reproduis le S88 d'origine de Marklin. Donc côté innovation, tu repasseras puisque c'est un truc qui au moins 30 ans d'âge sinon plus.

Quant à l'inconvénient majeur du S88 ancien, c'est son fonctionnement sous faible tension qui induit des parasites dès qu'il y a cohabitation des câbles du S88 avec d'autres conducteurs: ceux du courant traction par exemple. J'en parle en toute connaissance de cause.

La S88 d'aujourd'hui s'appelle S88-N et ne comporte plus tous ces inconvénients.

Jean

Bonjour et bienvenue dans le (vaste) monde de TrainController

Jean_01 a écrit:

Bonsoir Pierre,
Je crains que Elie n'ait raison.
Arduino est sans doute très bien pour le modélisme ferroviaire pour gérer quelques opérations simples. De là à lui confier la gestion de la rétrosignalisation de 64 cantons, c'est un pas que je ne franchirais pas.
Jean

je suis d'accord avec Elie et Jean,

j'ai fait (et je fais encore) beaucoup de test sur arduino, en mode décodeur accessoire (pas encore vraiment essayé le mode retro mais je bute ici avec le bus RS)
en mode décodeur sans TC ça marche sans problème, et ça marche même bien et c'est pas cher.
pour les interréssés, j'utilise cette méthode de connexion du DCC et la bibliothèque DCC_decodeur.h de MynaBay:
" />

en mode avec TC, l’Arduino n'arrive pas à assimiler tous les ordes qui lui arrivent. Je m'explique, lors de l'activation d'un trajet TC envoie les ordres pour plusieurs aiguillages et cela peu importe l'orientation des aiguilles.
Mes tests ont porté sur 6 servos gerés par un arduino nano, avec un lancement par TC des ordres suivant le paramétrages ici :
" />
quelque soit la consigne renseignée dans la case turnout intervalle ou la consigne swich time ici :
" />

et bien arduino oublie quelques servos de façon aléatoire,   .... ça coince,
pour un même activation de trajet, test effectué 300 fois en cycle, sur 95 % des séquences lancées un voir deux servos ne se sont pas activés.
j'ai tout essayé, la durée d'envoi des ordres , la fréquence, la vitesse de rotaion du servo, etc.. rien n'y fait. j'en conclue donc que la méthode utilisée (branchement) ou la librairie ou simplement arduino lui même ne fonctionne pas correctement, encore une fois en liaison avec TC.

le même essai réalisé (dans les mêmes conditions) avec les mêmes servos et avec uhlenbrock 67810 n' a pas posé de problème, aucun refus sur le mouvement des servos !
je ne comprends pas pourquoi, mais c'est mon retour d’expérience.
je ne suis pas un grand spécialiste du langage C++ et encore moins de Arduino, il y a un an je ne connaissais même pas son existence et encore moins le langage C (je suis resté avec le vieux langage Basic), peut être une explication dans ce sens sur mon programme C++, mais j'ai également recopier bêtement des programmes tout fait, c'est pareil.
Elie qui est un fin connaisseur du DCC et des microcontrôleur pourra peut être expliquer.

Conclusion :Arduino ...... avec TC j'en reviens .... sans TC OK

Expliquer, certes non...surtout que je ne pratique pas Arduino... peut être simplement l'interface optocouplée qui ne suit pas...
Cependant, il ne faut pas espérer remplacer un µC bien programmé par un module Arduino.
En effet, la programmation accessible à l'utilisateur est un "sous programme" puisque le µC inclus dans Arduino comporte déjà un programme permettant d'accéder facilement à des fonctions complexes pré programmées.
Petite réflexion sur le C++ :
Ce langage permet de gagner beaucoup de temps pour la programmation des µC, cependant il favorise les petits bugs car il "globalise le programme". En comparaison, une programmation ligne par ligne avec assembleur, certes, beaucoup plus rébarbative, permet de disséquer chaque opération... mais bien sûr, c'est long...

Bonsoir,

DiCoS69 a écrit:

... peut être simplement l'interface optocouplée qui ne suit pas...

Un peu comme moi, quoi !...
Plus sérieusement, ce qui est étonnant c'est que le problème subsiste même avec un délai entre les ordres ...   Lorsque j'avais aléatoirement des aiguilles non faites avec le couple LS150/moteur SEEP, je reproduisais le problème avec la commande à main de la centrale. De toute façon, pilotée par une commande à main ou par TC, la centrale envoi toujours les mêmes ordres DCC aux décodeurs d'accessoires, non ? ...  

A+
Georges

Geo69 a écrit:

De toute façon, pilotée par une commande à main ou par TC, la centrale envoi toujours les mêmes ordres DCC aux décodeurs d'accessoires, non ? ...  
A+
Georges

Oui, absolument, sauf que ton doigt est beaucoup plus lent (en général...) qu'un ordre envoyé par le PC...
Il est donc fort possible que plusieurs paquets de commande successifs soient générés en manuel (temps d'appui de ton doigt) et pas quand c'est le PC qui commande...
Dans ce cas, le circuit Arduino n'a pas droit à l'erreur... s'il loupe un octet, c'est cuit pour lui...

Je suppose que si Bernht Lenz avait envisagé dès le départ le pilotage par logiciel informatique des réseaux avec son DCC, il aurait inclus un certain nombre de répétitions des ordres de commande des accessoires (à moins que ce ne soit à J. Freiwald de s'en charger...).
En effet, seuls les commandes des locos sont répétés en permanence par la centrale...

DiCoS69 a écrit:

Je suppose que si Bernht Lenz avait envisagé dès le départ le pilotage par logiciel informatique des réseaux avec son DCC, il aurait inclus un certain nombre de répétitions des ordres de commande des accessoires (à moins que ce ne soit à J. Freiwald de s'en charger...).
En effet, seuls les commandes des locos sont répétés en permanence par la centrale...

Au risque de dire une bêtise Élie, je pense que c'est à l'utilisateur de se charger de cette répétition ! Mon expérience est la suivante, avec la centrale Massoth commandée par TC, les aiguillages étaient manœuvrés un par un avec une petite seconde d'écart.
Quand j'ai connecté la centrale Lenz pour la première fois, je n'ai pas prêté attention à la case nouvellement apparue: intervalle d'envoi ! À la première commande d'aiguillage la centrale a disjoncté en en bougeant 3 d'un coup ! Ce qui me laisse penser que TC s'adapte aux centrales qu'on lui raccorde. Mais que c'est à l'utilisateur de définir le rythme d'envoi.

Et pour ce qui est de la répétition des commandes de locomotives... la centrale Massoth ne le fait pas !

DiCoS69 a écrit:

Geo69 a écrit:

De toute façon, pilotée par une commande à main ou par TC, la centrale envoi toujours les mêmes ordres DCC aux décodeurs d'accessoires, non ? ...  
A+
Georges

Oui, absolument, sauf que ton doigt est beaucoup plus lent (en général...) qu'un ordre envoyé par le PC...
Il est donc fort possible que plusieurs paquets de commande successifs soient générés en manuel (temps d'appui de ton doigt) et pas quand c'est le PC qui commande...
Dans ce cas, le circuit Arduino n'a pas droit à l'erreur... s'il loupe un octet, c'est cuit pour lui...

Je suppose que si Bernht Lenz avait envisagé dès le départ le pilotage par logiciel informatique des réseaux avec son DCC, il aurait inclus un certain nombre de répétitions des ordres de commande des accessoires (à moins que ce ne soit à J. Freiwald de s'en charger...).
En effet, seuls les commandes des locos sont répétés en permanence par la centrale...

j'en avais conclu également ce que tu décris.
sauf que lorsque j ai réalisè un décodeur de signaux (toujours avec Arduino et la petite électronique qui va avec,  j'ai jamais eu de refus d'allumage d'une led.  
également je pilote un moteur pas à pas et j'ai jamais rencontré de refus.

dans l'application "gestion de servo", je pense que c'est plutôt dans le traitement du programme qu'il y a un problème,
avec des leds ou des relais à actionner, tu reçois l'ordre DCC, arduino met la sortie + 5V ou 0V il n'y a pas réellement de traitement de programme entre l’ordre DCC reçu et l'action sur les sorties arduino . ( c'est du 0/1).
dans mes essais, c'est jamais le servo 1 qui ne bouge pas , c'est toujours aléatoirement à partir du deuxième  jusqu'au 6.
Pour rappel, Arduino doit gérer en même temps :
. les pilotages des servo  d'un point A vers un point B
. l'interruption pour recevoir les ordres DCC
. des départs / arrivées differents pour chaque servo,
. une vitesse +- "lente"
et c'est là que ça ... coince
quand on sait que la vitesse n'est pas gérer en tant que telle mais plutôt par des  successions de mouvement très court suivies d'arrêt plus ou moins long
ceci pour simuler un déplacement avec une vitesse donnée.  

c'est donc réellement dans le programme et son traitement par l'µC de l'arduino qu'il y a problème.
tu parlais avec les µC de programme en assembleur, c'est surement à mon avis une des  raisons
de toute façon les décodeurs du marché fonctionnent bien, c'est donc possible mais pour en revenir à la question de depart, pas avec Arduino pour ce qui est des servos.


je ne mets pas arduino à la poubelle pour autant, mais il faut l'utiliser en connaissance de ses capacitées reelles dans notre application.

Bonjour,
Oui Marco, c'est au niveau du programme que l'Arduino fait faiblesse.

Christophe a écrit:

Et pour ce qui est de la répétition des commandes de locomotives... la centrale Massoth ne le fait pas !

Ça, c'est étonnant, parce que ça fait partie du protocole DCC...

Christophe a écrit:

Au risque de dire une bêtise Élie, je pense que c'est à l'utilisateur de se charger de cette répétition ! Mon expérience est la suivante, avec la centrale Massoth commandée par TC, les aiguillages étaient manœuvrés un par un avec une petite seconde d'écart.
Quand j'ai connecté la centrale Lenz pour la première fois, je n'ai pas prêté attention à la case nouvellement apparue: intervalle d'envoi ! À la première commande d'aiguillage la centrale a disjoncté en en bougeant 3 d'un coup !  Ce qui me laisse penser que TC s'adapte aux centrales qu'on lui raccorde. Mais que c'est à l'utilisateur de définir le rythme d'envoi.

Christophe, tu parles là de l'intervalle d'envoi, pas de la répétition des ordres déjà donnés...
Cette "cadence" n'augmente pas, non plus, la durée de l'envoi de l'ordre...

Les trames DCC restent des trames DCC, si le protocole "temps" est suivi à la lettre, je reste de l'avis d'Elie.

Le problème est que le DCC de Massoth est "compatible" pas "conforme" ! Et la visite d'un réseau des environs de Toulouse me conforte dans mon point de vue, la centrale Massoth n'est pas compatible avec TC ! Détection farfelue, et ordres pas transmis aux machines...