Une station DCC complète, polyvalente et économique avec JMRI

[msport]

1. Nano de la manette directement branchée à l'Arduino IDE en USB, sans la station

2. Manette branchée à la station, sans JMRI - Station connectée par USB à l'Arduino IDE

Ce mode de connexion en USB n'est pas celui du montage d’origine. Impossible de vous assurer un support dans cette configuration.

Ce qui est prévu c'est une connexion RX/TX du Nano de la manette vers le TX/RX du UNO de la centrale. Revoyez le schéma.

[msport]

A priori normal que JMRI ne reprenne pas les ordres de la manette surtout avec votre branchement.
C'est deux philosophies différentes : les manettes en pilotage manuel, JMRI en pilotage distant.
Si vous voulez des manettes avec JMRI, explorez les possibilités via smartphone (solution que je n'aime pas, mais efficace).
Revenez déjà à une configuration standard.

[Dralliam]

Ce qui est prévu c'est une connexion RX/TX du Nano de la manette vers le TX/RX du UNO de la centrale. Revoyez le schéma.

Oui c'est bien ce qui est réalisé en mode "raccordé au réseau de train".

Dans le cadre des essais conduits en prolongement vos conseils, le cas 1. Nano de la manette directement branchée à l'Arduino IDE en USB, sans la station a simplement servi à auditer la communication du Nano de la manette vers le Uno de la station, sans chercher à faire tourner les trains. Elle n'était aucunement raccordée à la Station.
Pour une utilisation en situation de commande, la manette est bien raccordée en TX/RX avec le UNO de la station

Cas 2. Manette branchée à la station, sans JMRI - Station connectée par USB à l'Arduino IDE
--> je précise manette raccordée à la station en TX/RX
L'intention est bien d'essayer de faire marcher le montage de "Une station DCC..." avec une manette, mais sans JMRI / sans ordinateur. Le branchement par USB de l'Arduino UNO de la station au moniteur série de l'Arduino IDE servait à voir ce que le Uno de la Station avait à dire

[Dralliam]

Pour résumer :
Je cherche à utiliser le montage "Une station DCC complète, polyvalente et économique avec JMRI" avec au moins une télécommande "physique".
J'ai donc réalisé le montage "Ma première Manette DCC", à ce stade connectée en filaire.
L'utilisation / les fonctionnalités de JMRI sont, pour mon usage, pour l'instant, un bonus non nécessaire (c'est peut-être la faute originelle  ). J'ai au moins besoin de commandes physiques / non digitales

Note : j'ai bien noté qu'il sera préférable de passer au raccordement "sans fil" pour utiliser plusieurs télécommandes

A ce stade, en configuration "standard", c'est à dire Station connectée à JMRI en USB et sans manette : tout marche parfaitement !
(c'est déjà super et je suis vraiment reconnaissant envers toute l'équipe Locoduino de m'avoir permis cet "exploit")

Pour tous les autres cas d'utilisation que j'ai expérimentés, le fonctionnement n'est pas satisfaisant celui attendu :

A- Station commandée via Arduino IDE en USB à base de commande <t 1 X XX 1>
--> Problème de la loco ayant reçu l'avant dernière consigne qui rencontre une micro coupure d'alimentation (cf. posts précédents)

B- Station commandée par "Ma première Manette DCC" en filaire
--> Problème idem

C- Station commandée par "Ma première Manette DCC" en filaire ET connectée à JMRI en USB
--> Problème idem
--> également "Inhibation" de JMRI constatée

[Dralliam]

Ce problème de l'arrêt "post micro coupure de l'avant dernière loco à avoir reçu une consigne" serait peut-être évité si mes locomotives étaient équipées de condensateurs "Stay alive", mais je n'ai pas les moyens de le vérifier.
Je m'étonne (et c'est tant mieux !) que ça ne se produise pas en utilisation avec JMRI et je m'interroge pourquoi.
Ca me permettrait peut-être de comprendre ce qui pourrait être modifié dans le programme de la manette par exemple.

JMRI répète-t-il les consignes ? Suivant quelles règles ?

[msport]

Je viens de tester avec ma BaseStation de référence (UNO + shield moteur = ma première centrale)et deux manettes style https://www.locoduino.org/spip.php?article286

Pas de coupure au changement de manette ou de locomotive sur une manette.

A priori, c'est DCC++ qui répète sans fin la dernière commande de locomotive (pas les fonctions - imaginons le sifflet)

Revenez aux basiques avec des montages qui ne laissent pas de doutes sur la connectique.
Réinitialisez vos décodeurs et reprogrammez juste leur adresse.

Nota : JMRI affiche dans traffic monitor (vu où c'est ?) ce que la centrale répond aux ordres de la manette.

[Dominique]

A priori, c'est DCC++ qui répète sans fin la dernière commande de locomotive (pas les fonctions - imaginons le sifflet)

Oui c'est obligatoire dans Communications Standards For Digital Command Control, All Scales
Adopted July 2004 S 9.2 :

Code: [Sélectionner]

C: Frequency Of Packet Transmission
Packets sent to Digital Decoders should be repeated as frequently as possible, as a packet may have been lost due to noise or poor electrical conductivity between wheels and rails.
Et c'est que fait bien DCCpp.

[Dralliam]

Je vous remercie sincèrement pour votre support et votre soutien, ce n'est pas sur tous les forums que la core team mouille la chemise comme vous le faites.
Il ne me reste plus beaucoup de cheveux mais je me sens moins seul !

Je viens de tester avec ma BaseStation de référence (UNO + shield moteur = ma première centrale)et deux manettes style https://www.locoduino.org/spip.php?article286

Pas de coupure au changement de manette ou de locomotive sur une manette.

--> Avez-vous pu observer la réaction de "l'avant-dernière locomotive ayant reçu une consigne en cas de coupure de l'alimentation de celle-ci" ?

Compte tenu de ce qui marche (JMRI seul parfaitement ou manette seule mais sans parcourir la liste des 4 adresses de loco embarquées) et de ce qui marche pas ou mal en l'état sur mon montage, je doute fort que ce soit un problème de connectique vu que ca ressemble plutôt a un probleme de répétition des commandes.
J'ai déjà réinitialisé plusieurs fois les décodeurs, malheureusement sans effet
Mais oui je vais essayer avec un autre montage de station même si les différences sont bien faibles entre les cartes de puissance.

J'ai aussi commandé une paire de décodeurs Lenz Standard+ V2. Il m'en fallait d'autres et ça changera des LaisDCC qui ne sont peut-être pas totalement innocents après tout.

[Dralliam]

A priori, c'est DCC++ qui répète sans fin la dernière commande de locomotive (pas les fonctions - imaginons le sifflet)

Oui c'est obligatoire dans Communications Standards For Digital Command Control, All Scales
Adopted July 2004 S 9.2 :

Code: [Sélectionner]

C: Frequency Of Packet Transmission
Packets sent to Digital Decoders should be repeated as frequently as possible, as a packet may have been lost due to noise or poor electrical conductivity between wheels and rails.
Et c'est que fait bien DCCpp.

Tout cela est très intéressant, il semble qu'en dehors de l'utilisation "vanille" avec JMRI et sans manette ce ne soit pas ce qui se produit sur mon montage (seule la dernière consigne communiquée serait répétée vu que l'avant derniere locomotive, elle, ne semble plus avoir de consigne)

--> Est-ce qu'il existe un montage "mouchard DCC" capable de retranscrire en rétro engineering les communications qui transitent dans les rails telles que les décodeurs les reçoivent ?

Je pourrais ainsi comparer ce que JMRI fait envoyer comme informations par la station vs. ce qu'elle ne fait pas à partir des commandes envoyees par l'Arduino IDE ou par la manette

[msport]

Sniffer le plus abouti :
https://dcc-ex.com/ex-dccinspector/index.html
https://github.com/DCC-EX/DCCInspector-EX

Voir aussi :
https://forum.locoduino.org/index.php?topic=460.msg4650#msg4650

https://forum.locoduino.org/index.php?topic=244.15

[Dralliam]

Sniffer le plus abouti :
https://dcc-ex.com/ex-dccinspector/index.html
https://github.com/DCC-EX/DCCInspector-EX

Voir aussi :
https://forum.locoduino.org/index.php?topic=460.msg4650#msg4650

https://forum.locoduino.org/index.php?topic=244.15

Merci beaucoup, je vais regarder ça en parallèle des autres tests


Autrement, je me permets d'insister sur cette question assez fondamentale suite aux tests que vous avez eu la gentillesse de réaliser :

Je viens de tester avec ma BaseStation de référence (UNO + shield moteur = ma première centrale)et deux manettes style https://www.locoduino.org/spip.php?article286

Pas de coupure au changement de manette ou de locomotive sur une manette.

--> Avez-vous pu observer la réaction de "l'avant-dernière locomotive ayant reçu une consigne en cas de coupure de l'alimentation de celle-ci" ?

[msport]

Quand j'ai coupé l'alimentation, bien sur, tout s'est arrêté. En pouvait-il être autrement sans stay alive ?

et arrêt normal quand sa consigne a été zéro.

Si elle devait passer sur un cœur d'aiguille long isolé sans élan, elle s'arrêterait. (De même la dernière)

Mais peut-être n'ai je pas compris votre question.

[Dralliam]

Oui je m'aperçois que je n'ai pas réussi à me faire comprendre ^^
Pas facile d'arriver à être clair, précis et concis

Je me permets de repartir d'un message précédent qui présente le protocole de test qui fait tourner 2 loco avec décodeurs en adresse 5 et en adresse 6 avec la Station et les consignes envoyées via la Manette ou via l'Arduino IDE (mêmes résultats)

Nouvelle description du problème (non pas que ça empire, mais que nous comprenons mieux ce qui se passe) :
En cas de coupure de courant d'alimentation sur la locomotive* qui est l'avant dernière à avoir reçu une consigne, elle s'arrête.
Illustration :
1- la locomotive adresse 5 reçoit une consigne --> OK [la consigne adresse 5 est appliquée]
2- la locomotive adresse 6 reçoit une consigne --> OK [la consigne adresse 6 est appliquée]
    la locomotive 5 poursuit sa route (OK)
3- micro coupure dans l'alimentation de la locomotive adresse 5 --> la locomotive adresse 5 s'arrête, ne reprend pas sa marche après le rétablissement de l'alimentation [la consigne adresse 5 n'est plus appliquée]

Je peux ajouter :
En parallèle la locomotive adresse 6 poursuit sa route normalement (normal, il ne lui est rien arrivé) [la consigne adresse 6 est toujours appliquée]
Et :
Si je lève les essieux de prise de courant (simulation rupture de conductivité de la voie) de la locomotive adresse 6 (la dernière à avoir reçu une consigne), la locomotive 6 poursuit sa route normalement après avoir retrouvé le courant [la consigne adresse 6 est toujours appliquée]

* Je parle d'une rupture dans l'alimentation du décodeur de la locomotive, tout à fait accidentelle, liée à la conductivité de la voie : rails "sales", ou aiguillage sans coeur alimenté.
Pour les besoins de l'expérience j'ai reproduit cette situation en levant un court instant les essieux de prise de courant, mais je n'ai pas touché à l'alimentation côté station

Dit encore autrement :
Lorsque l'avant-dernière locomotive à avoir reçu une consigne perd un court instant l'alimentation DCC, elle s'arrête et ne reprend pas sa route après avoir récupéré l'alimentation DCC.
Lorsque la dernière locomotive à avoir reçu une consigne perd un court instant l'alimentation DCC, elle reprend normalement sa route après avoir récupéré l'alimentation DCC.
--> Tout se passe comme si seule la dernière consigne concernant la dernière adresse sélectionnée était répétée
Et dans la pratique, avec la télécommande, le simple fait de faire défiler les locomotives en pressant sur "#" (rangs 1 à 4) envoie la consigne gardée en mémoire concernant le rang, et ma locomotive "avant dernière" s'arrête à la première rupture de conductivité

Mais ça ne se passe pas comme ça sous JMRI
La circulation n'est alors pas perturbée par les séquences successives de consignes sur le même anneau avec les mêmes défauts de conductivité de la voie
C'est à dire : la dernière comme l'avant-dernière locomotive conservent leur consigne, même après avoir (accidentellement) perdu un court instant l'alimentation DCC.
--> Tout se passe comme si les dernières consignes pour chaque adresse était répétées

Est-ce que cela vous semble plus clair ?

Je ne vous dit pas le nombre d'essais qu'on a dû réaliser pour arriver à cette analyse et l'attention nécessaire pour assurer les conditions reproductibles  :'(

[msport]

Nouvelle description du problème

votre problème était l'arrêt de la première loco quand une deuxième loco reçoit un ordre ? Ce qui vous est spécifique.

Mais ce que vous décrivez est différent, et "normal" :
Oui, pour le DCC seule la dernière consigne concernant la dernière adresse sélectionnée est répétée
Oui, pour chaque régulateur de JMRI, la consigne de l’adresse correspondante est répétée

[Dralliam]

votre problème était l'arrêt de la première loco quand une deuxième loco reçoit un ordre ? Ce qui vous est spécifique.

Oui c'était bien ma vision du problème au départ, mais en cherchant beaucoup on a réussi à isoler et comprendre plus finement le problème (pas facile entre l'inertie des machines, le soin apporté à la voie et les aiguillages !)

Mais ce que vous décrivez est différent, et "normal" :
[...]
Oui, pour chaque régulateur de JMRI, la consigne de l’adresse correspondante est répétée

Ca signifie que mon installation a été consciencieusement réalisée, tant mieux

En revanche ceci m'inquiète :

Oui, pour le DCC seule la dernière consigne concernant la dernière adresse sélectionnée est répétée

Je pensais naïvement que les consignes de vitesse et de sens de circulation éta