Un moniteur de signaux DCC
Comment espionner les commandes émises par la centrale DCC
. Par :
Vous répondez à :
J’ai pour projet de construire une centrale DCC commandée par une application de type WEB.
J’en suis à l’étape de réalisation d’un prototype de validation.
Les commandes sont accessibles à partir d’un ordinateur, d’une tablette ou d’un téléphone portable.
Composants logiciels : serveur http node.js + développement spécifique,
bibliothèque CmdrArduino et sketch Arduino.
Composants matériels : carte Arduino, un bridge LMD18200, un module MAX471,pour cette partie j’ai suivi la série d’articles publiés par Dominique
’Comment piloter trains et accessoires en DCC avec un Arduino’.
Je bute actuellement sur une impasse avec la partie moniteur du signal DCC.
J’ai tenter de réaliser sans succès le montage publié dans cet article avec
les modifications conseillées par SUPERN (R1 = 2.7K, R3= 1K).
Le signal DCC ne passe pas au travers de l’optocoupleur, alors qu’il semble bon en entrée.
Un décodeur de locomotive connecté sur le bus réagit correctement aux commandes.
Le signal observé en entrée à l’aide d’un oscilloscope ne traverse pas le 6N137.
J’ai effectué un test avec le signal émis par un générateur BF (avec R1 < 1K) pas mieux.
N’ayant aucune compétence en électronique je ne sais pas comment faire pour m’en sortir.
Confirmez-vous la validité du schéma publié, l’avez-vous mis en oeuvre ?
Une autre solution pour l’interface matérielle est-elle envisageable ?
Vous remerciant par avance de l’attention que vous porterez à mes malheurs ...
62 Messages
-
Un moniteur de signaux DCC 19 février 2015 12:20, par DDEFF
Bonjour Dominique,
Il est super, cet article !En fait, je vais essayer de l’employer pour mon projet (si ça t’intéresse, c’est sur le forum LR). Il y a là toutes les briques qui devraient me servir.
Mon problème est plus simple que ce que calcule ton programme :
Je voudrais, en testant le DCC, savoir, pour tous les trains présents (jusqu’à 40) savoir dans quel sens ils vont, en temps réel. C’est "tout".
Et remplir une table dans l’arduino (n°train, sens).
Si je raisonne bien, 144 paquets en 1s, ça fait 7 ms/paquet.
Pour 40 locos, ça fait 280 ms. Et le DCC ne traite pas que les locos...
A ton avis, en combien de temps maximum puis-je avoir l’info pour les 40 locos ?
Autre question : l’info sens est-elle envoyée périodiquement ou uniquement quand on change le sens ? Ce qui, évidemment, arrangerait bien mon problème.
Bien amicalement
A+-
Bonsoir Denis,
Tout d’abord, il faut savoir que l’information de sens est transmise dans TOUS les paquets de vitesse.
L’explication est dans l’article "L’Arduino et le système de commande numérique DCC".Une commande de vitesse 28 pas (par exemple) est décrite par la succession de bits 0 et 1 suivants :
111111111111 0 0AAAAAAA 0 01DCSSSS 0 EEEEEEEE 1
.............. le temps s’écoule dans ce sens .................>111111111111 est le préambule qui doit contenir au moins 12 bits 1,
le 0 suivant marque le début de l’adresse qui suit,
0AAAAAAA est l’adresse de la loco (par exemple pour l’adresse 37 : 00110111),
le 0 suivant marque le début de la commande qui suit,
01DCSSSS est la commande de direction et vitesse :
D = 1 pour la marche avant, D = 0 pour la marche arrière
CSSSS est la vitesse codée en 28 pas dans chaque sens (par exemple pour la vitesse 6 en avant : 01110100)...Tu trouveras un décodage simple de l’adresse, vitesse et direction d’une commande 128 pas dans cet article.
En ce qui concerne les temps de transmission de 40 commandes de vitesse pour tes 40 locos (bigre ! j’imagine mal que tu puisses faire circuler 40 machines en même temps, ou alors tu circules sur un réseau de plusieurs centaines de mètres et tu dois avoir un sacré bloc système !!!), c’est à peu près cela : 300 ms. Tout dépend de ta centrale, si elle introduit des trames IDLE et des répétitions (oui en général, elles bourrent le bus de commandes répétées au maximum).
Donc tu auras l’info en moins d’une seconde, mais ce sera répété sans arrêt et ton programme sera bien occupé !
Bien amicalement
Dominique
-
-
Un moniteur de signaux DCC 26 février 2015 18:52, par DDEFF
Merci Dominique,
Ce réseau existe : Chalindrais 2.0, Loco Revue 810.
Un L de 10 m de côté, 350 m de voies, 91 aiguilles et 69 cantons et ... 40 trains !
Mais, moi, je n’ai pas (encore) de réseau :-( -
Un moniteur de signaux DCC 26 mars 2015 21:34, par jac56
Bonjour,
Encore un article très intéressant.
J’ai utilisé ce développement (basé sur la librairie Minabay) non pour décoder les trames des accessoires, mais pour vérifier les commandes de vitesse émises par la librairie RailStars/CmdrArduino_Master (cité dans les articles : piloter en DCC).
J’ai utilisé un montage direct entre un générateur et un décodeur, au niveau 5V, sans passer par le LMD18200 de puissance. Le sketch du générateur lance des commandes, avec une période de 1 sec environ, vers soit une, soit huit adresses différentes (8, en une seule rafale) ; la vitesse varie linéairement à chaque période, cycliquement entre les deux extrêmes. On peut aussi lancer des commandes F0, arrêt - marche. Côté moniteur, pour faciliter la vérification, j’ai complété le sketch proposé par un sous-programme qui affiche en clair : adresse, commande, vitesse dans différents cas possibles (c’est plus facile de vérifier en clair, et on est plus assuré d’avoir bien compris les règles de codage ; je peux copier ce bout de code, si souhaité, mais ce n’est qu’un brouillon peu soigné).
J’ai fait les constats suivants (il est possible que je n’ai pas bien compris la norme) :- la commande F0 fonctionne correctement ;
- les commandes de vitesse fonctionnent correctement en mode 128 pas (trame à 4 ’packets’ analysés par la librairie dont une pour le XOR), à condition de ne jamais envoyer de commande de vitesse nulle (assimilé à un arrêt d’urgence, semble-t-il) ; aucune trace de surcharge n’apparaît : il y a bien 4 trames pour chaque consigne de vitesse différente et toujours, grosso modo, le même nombre total de commandes émises par seconde ; l’interprétation des ’packets’ ne pose pas de problème ; le module de la vitesse est présent sur (packet[2] & 0x7F) ; le bit de direction sur (packet[2] & 0x80)>>7 ;
- les commandes de vitesse en 14 ou 28 pas semblent mal fonctionner (même sans envoi de vitesse nulle) ; par exemple, en mode +- 28 pas (3 ’packets’ analysés dont le XOR) , en faisant varier la vitesse de -27 à + 27 sans passer par 0, le bit de direction change bien, mais on observe que seulement 3 bits se modifient parmi les bits réputés concerner le module de la vitesse ; quelque soit la façon d’interprêter les autres bits (il y a une permutation à faire), on ne pourra donc décoder 27 niveaux distincts ;
- l’envoi d’une commande de vitesse nulle (sur une adresse) perturbe le fonctionnement d’ensemble ; le décodeur indique ne plus recevoir que des trames ’oisives’ (’idle’), en nombre normal ; pour débloquer cette situation il n’y a pas d’autre solution qu’un reset, et l’absence d’émission de toute trame de vitesse nulle. Y-a-t-il une conduite particulière à tenir après l’émission d’un arrêt d’urgence à destination d’une loco ?
Je n’ai pas été plus loin dans l’analyse du fonctionnement interne des librairies ; finalement le problème peut venir de la librairie émettrice, comme de la réceptrice. Dans le code, la librairie émettrice prévoit bien la cas de la vitesse nulle, qu’elle transforme en une trame spéciale d’arrêt d’urgence (avec adresse). Cette librairie semble avoir déjà été beaucoup utilisée. Je n’ai pas regardé l’autre code. La librairie réceptrice semble montrer d’autres signes d’anomalie dans le traitement des vitesses, mais ce n’est en rien une preuve. Peut-être a-t-elle été écrite plutôt dans l’optique du décodage de trames d’accessoires et est moins étudiée et exhaustive pour les vitesses ?
Le juge de paix serait le comportement d’une vraie loco, mais je ne dispose pas encore des composants de puissance, car je voulais d’abord tester le fonctionnement logique de mon projet .
D’autres ont-ils fait des observations semblables ? Où ai-je pu commettre une erreur ?
Bravo pour l’ensemble du site. Une mine.
-
Un moniteur de signaux DCC 27 mars 2015 10:10, par Dominique
Merci Jacques, pour cette première analyse très intéressante :
J’avais déjà constaté des "choses" et j’avais décidé de pousser les investigations plus loin, donc c’est le moment de partager maintenant.
Moi aussi j’ai commencé par interfacer l’émetteur et le récepteur au "niveau TTL", comme je construisais le pilote DCC et le bloc système sur le même Arduino, il fallait voir vite ce qui se passe.
Ensuite je me suis procuré une MS2 pour programmer mes quelques locos et pour comparer ce qu’elle envoie par rapport à ma centrale basée sur Cmdrarduino. Plus tard j’ai rendu le moniteur autonome et j’ai pu regarder ce que d’autres centrales envoient (l’ECOS en particulier, le référence dans les clubs).
Je me suis d’abord concentré sur les commandes de locos (vitesse et fonctions) en 128 pas uniquement (c’est plus logique avec un Arduino que 28 ou 14 et moins saccadé).
J’ai tout de suite vu l’inversion que le bibliothèque Cmdrarduino fait au niveau des vitesses 0 (urgence, sans inertie) et 1 (arrêt avec inertie). J’ai donc décidé de ne pas utiliser l’arrêt d’urgence, car c’est à la centrale de gérer la circulation pour éviter cela.
Ensuite j’ai eu des doutes sur la répétition automatique des commandes de vitesse, car j’avais l’impression que mes locos ne réagissaient pas à tous les coups.
Ma constatation est que la bibliothèque Cmdrarduino envoie moins de commande que les centrales du commerce qui, elles, remplissent le temps de trames de commandes, alors que nous voyons dans l’exemple de cet article qu’il y a 90 % d"idle".
Bien-sur cela demande du temps pour analyser encore plus ce comportement et décortiquer la bibliothèque, ne cesserait-ce que pour la transposer sur Arduino DUE qui est nettement plus puissant.
Je n’ai pas encore testé Cmdrarduino pour programmer des CVs et commander des accessoires, mais cela viendra.
Pour obtenir un comportement des locos qui me plait, j’ai pris l’habitude de répéter les commandes toutes les secondes ou demi-secondes.
Dans la suite à venir de "Comment piloter trains et accessoires en DCC avec Arduino (4)", je donnerai le programme complet qui est quand même un peu compliqué. Si vous êtes pressé de le lire, allez sur mon site perse "bultez.fr".
A priori je pense que vous pouvez faire confiance à ce que le décodeur de Minabay "voit" : je n’ai vu aucun défaut à l’usage.
Par contre, si vous comparez la trace du décodeur avec le comportement d’une vrai loco, n’oubliez pas qu’il y a pas mal de CVs qui modifient son comportement : en particulier les CVs d’accélération et décélération doivent être mis à 0 (zéro).
Je vous suggère de me contacter par email pour approfondir cette analyse qui méritera un article futur dans Locoduino.
Bien cordialement
Dominique -
Un moniteur de signaux DCC 2 novembre 2015 13:19, par Didier
Bonjour,
Je suis intéressé par votre réalisation que je trouve très intéressante.
Malheureusement la librairie Minabay n’est plus accessible.
Savez-vous où l’on pourrait la trouver ?
En vous remerciant par avance
Bien cordialement
Didier-
Pour vous dépanner rapidement, voici un lien où on la trouve encore
http://www.scale-n.nl/Downloads/dcc...Effectivement le site Minabay a supprimé le téléchargement de cette bibliothèque sans que l’on sache pourquoi.
Nous allons faire des recherches, voire la mettre en téléchargement sur ce site.
Je vous signale également qu’une autre bibliothèque est disponible qui n’est pas compatible avec dcc_decoder, mais qui permet de décoder le trafic DCC.
https://github.com/mrrwa/NmraDcc
Nous allons prochainement élargir l’article (ou un autre) à cette bibliothèque.
Encore merci de nous avoir signalé ce changement gênant.
Cordialement.
Dominique
-
-
Un moniteur de signaux DCC 12 février 2016 18:48, par SUPERN
Bonsoir,
Merci pour cet article très détaillé et très utile. Je suis en train de le réaliser, mais je trouve deux petits problèmes dans votre schéma de lecture du DCC.
La résistance d’entrée R1 de 1K est trop faible. Le courant de déclenchement de la diode émettrice est de 5 mA. Comme le DCC fait au moins 18 volts, le courant envoyé est de 18 mA, ce qui est trop (max 15 mA en continu). Une résistance entre 2.7 et 3.3 K préserverai mieux la durée de vie de la 6N137.
De même la notice de cet élément spécifie une résistance de sortie collecteur comprise entre 330 ohms et 4 k. Donc votre R3 de 10 k est trop forte.
Je préconise la valeur typique de la notice d’utilisation qui est de 1 K.
Voila pour mon petit apport d’électronicien.
A+ lorsque j’aurai reçu mon Arduino mini.-
Merci beaucoup pour cette précision très utile.
je m’étais contenté de reproduire un schéma de R. Falkenburg sans vérifier les valeurs. Quand tu auras fait tes tests et confirmé ces valeurs (j’en ferai autant de mon coté), je mettrai à jour ce schéma !
Cordialement
dominique
-
J’ai pour projet de construire une centrale DCC commandée par une application de type WEB.
J’en suis à l’étape de réalisation d’un prototype de validation.Les commandes sont accessibles à partir d’un ordinateur, d’une tablette ou d’un téléphone portable.
Composants logiciels : serveur http node.js + développement spécifique,
bibliothèque CmdrArduino et sketch Arduino.Composants matériels : carte Arduino, un bridge LMD18200, un module MAX471,pour cette partie j’ai suivi la série d’articles publiés par Dominique
’Comment piloter trains et accessoires en DCC avec un Arduino’.Je bute actuellement sur une impasse avec la partie moniteur du signal DCC.
J’ai tenter de réaliser sans succès le montage publié dans cet article avec
les modifications conseillées par SUPERN (R1 = 2.7K, R3= 1K).Le signal DCC ne passe pas au travers de l’optocoupleur, alors qu’il semble bon en entrée.
Un décodeur de locomotive connecté sur le bus réagit correctement aux commandes.
Le signal observé en entrée à l’aide d’un oscilloscope ne traverse pas le 6N137.
J’ai effectué un test avec le signal émis par un générateur BF (avec R1 < 1K) pas mieux.N’ayant aucune compétence en électronique je ne sais pas comment faire pour m’en sortir.
Confirmez-vous la validité du schéma publié, l’avez-vous mis en oeuvre ?
Une autre solution pour l’interface matérielle est-elle envisageable ?Vous remerciant par avance de l’attention que vous porterez à mes malheurs ...
-
Bonjour,
D1 est dans le bon sens ?
-
Je vous confirme que l’ai mis en œuvre 2 fois, même avant les corrections de SUPERN, et je n’ai aucun souci.
Comme le suggère Jean-Luc, il y a probablement une erreur de câblage ou un composant mal placé. Un petite photo ?
-
Merci à Jean-Luc et Dominique, il s’agissait bien d’une erreur, j’avais monté l’optocoupleur à l’envers.
Je suis confus de vous avoir dérangé avec une telle bêtise.-
Tant que tu ne l’as pas grillé, tout va bien :-)
-
J’ai attendu quelques jours avant de faire ce retour pour m’assurer du fonctionnement, voilà les paramètres que j’ai adopté :
OK1 : 6N137
R1 : 3,1 Kohms
R2 : 450 ohms
R3 : 450 ohms
D1 : 1N4148
C1 : CMS1206 1µFC1 : condensateur céramique ajouté entre 5 et 8
Merci pour cet article et votre attention.
-
Un moniteur de signaux DCC 14 février 2023 15:26, par Frédéric Labbé
bonjour, je voudrais savoir la valeur du condensateur place entre 5 et 8
merciFrédéric
-
-
-
-
-
-
-
Un moniteur de signaux DCC 14 février 2023 15:54, par Frédéric Labbé
bonjour, est-il possible que si la R1 de 1,5k serait assez et que de ce fait le signal DCC pourait ne pas etre très bien interprèté par l’arduino
j’ai parfois des commandes qui ne passe
Merci
Frédéric-
Bonjour,
on trouve suivant les sites pour R1 des valeurs de 1K à 2K, et ça ne semble pas critique.
Par contre, le condensateur, indiqué ici de 270pF, doit être adapté suivant le 6N137 et le réseau (qui présente des capacités réparties) On peut potentiellement le supprimer ou commencer par une valeur faible : 22pF
Si il y a un condensateur entre 5 et 8 du 6N137, il s’agit d’un condensateur de découplage, habituellement 100nF.
Cordialement
-
-
-
Un moniteur de signaux DCC 8 mars 2016 09:22, par Multitrain (Patrick)
Une petite info pour la valeur des résistances : la valeur de 4k min est pour un débit de 10 Mbit/s, pour le DCC, 10k sont OK.
Pour mes petites appli perso, je travaille avec des PIC’s il faut faire un circuit imprimé mais j’ai réalisé des applis embarquées qui tiennent quasiment sur l’ongle.
Je regarde un peu l’Arduino pour certaines réalisations et aider quelques amis qui s’y mettent.
Je ne connaissais pas locoduino, mais je vous joins un lien ci dessous où vous trouverez deux petites adaptations du logiciel du décodage DCC, l’une où on voit les commandes en clair et en binaire, l’autre où il n’y a que les commandes, ce qui est intéressant pour une validation définitive, on fait assez vite des confusions sur les rangs des bits et on finit par ne plus rien voir avec la version originale !
-
Merci pour l’info !
Ce sera l’occasion de compléter nos articles ;)
-
Bonjour Patrick,
Pourquoi ne créerais-tu pas un post sur le forum Arduino pour expliquer ce que tu as fait et les problèmes que tu as eu avec le lien que tu cites (Ruud Boer) ?
Parce que ce programme a l’air sympa et, évidemment, compatible RRTC (Ruud Boer et ses tutos...)
-
-
Un moniteur de signaux DCC 25 juin 2016 10:24, par Cyril
Bonjour,
A la compilation j’ai le message d’erreur suivant :
CC_mon:175 : error : ’DCC’ was not declared in this scopeDCC.loop() ;
-
Un moniteur de signaux DCC 25 juin 2016 16:32, par Dominique
Peut-être n’avez vous pas installé la bonne bibliothèque (voir en bas d’article) , ou il y a une erreur de syntaxe un peu plus haut dans le code.
Une bonne relecture devrait tout arranger, j’espère !
-
Merci, en effet la bibliothèque n’était pas la bonne :)
-
-
Un moniteur de signaux DCC 29 juin 2017 18:35, par Hervé BLOREC
Bonjour,
J’ai découvert Locoduino il y a peu de temps, et je suis surpris par tout ce qu’il est possible de faire avec un arduino. Je compte réaliser un moniteur DCC, ayant des 4N35 puis_je les utiliser à la place du 6N137 ?
Merci
Hervé-
Le 4N35 est notablement plus lent que le 6N137 qui est recommandé pour faire un décodeur DCC.
Le 4N35 est au moins 50 fois moins rapide que le 6N137.Un bon comparatif se trouve ici :
4N35 vs 6N137Quand le 4N35 a un temps de montée de 5 à 10 µS, le 6N137 lui, n’a que 140 nS. Il risque moins de déformer le signal DCC.
Le mieux est d’acheter des 6N137 à 0,70€ ici, c’est en France et c’est vite livré :
https://distri-compo.com/cataloguea...-
Bonsoir,
étant peu manchot avec le fer à souder, auriez-vous un composant "arduino" ou autre qui remplisse les mêmes fonctions que vous montage.
Merci par avance-
Sans fer à souder, vous pouvez réaliser le montage sur une plaque d’essai et prendre un Uno
-
-
Bonjour,
Je confirme qu’il faut utiliser un 6N137.
J’ai essayé avec un 4N35, pendant toute une journée, impossible de faire marcher le moniteur, les trames restent vides.Alors qu’avec le 6n137, ça marche à tous les coups.
Sans doute un problème de rapidité du composant à déclencher sur les fronts d’impulsion.-
Il y a une discussion sur le forum :
Mini décodeur à base d’ATTiny 84qui montre qu’il faut ajouter une petite capa (100 pf en moyenne) pour faire marcher le décodeur.
Dites nous si ça résoud votre problème (de toute façon il faut utiliser un 6N137).
-
Bonsoir,
Merci de cette indication, mais dorénavant je vais utiliser des 6N137.
J’avais utiliser des 4N35 car il m’en restais du projet "rétrosignalisation S88" paru sur Locoduino et qui fonctionne à merveille.
Mais bien sûr dans le cas de la rétro, peut importe la vitesse de l’optocoupleur, on cherche juste à détecter la consommation de courant.
-
-
-
-
-
Un moniteur de signaux DCC 30 décembre 2017 16:41, par Phil95
Bonjour,
Cet article me parait très intéressant. Il ouvre pleins de possibilités. Je trouve juste dommage qu’il ne soit pas expliqué comment sont décodés les signaux DCC (entre la sortie de l’opto et les trames disponibles)-
Bonjour Phil95,
Vous avez en partie raison, cet article décrit comment "voir" et "compter" les trames DCC en vue de comprendre le trafic DCC et éventuellement détecter et corriger des anomalies. Son rôle n’est pas de décrire toutes les trames DCC (ce qui est fait dans d’autres articles et sur le site de la NMRA).
Cet article vise à décrire la réalisation d’un outil très pratique, sans entrer dans le détail de la norme DCC.
La façon avec laquelle les trames DCC sont décodées est décrite dans le code Arduino fourni avec cet article. Si vous comprenez le langage de programmation, et les structures des trames DCC, vous devez pouvoir en déduire comment les signaux DCC sont décodés.
Par ailleurs, si vous voulez approfondir le sujet, il y a d’autres articles sur ce site qui décrivent des réalisations basées sur le code de Minabay et aussi sur d’autres codes comme celui de NMRA.
Bonne lecture.
-
-
Un moniteur de signaux DCC 4 février 2018 15:47, par Phil95
Bonjour,
J’ai pas trouvé les commentaires qui permettraient de comprendre comment sont décodés les signaux DCC :
à part que le code utilise la pin 2 en mode "interruption", on ne sait pas grand chose :
quels sont les ressources du micro-controller utilisées ? il devrait normalement utiliser un compteur/timer, mais lequel ? comment ?J’ai réaliser ce petit montage et télécharger le code (premiere version : sans afficheur LCD). Premiers tests pas vraiment concluant :
des fois ça marche, mais souvent, il n’y a aucune trame de détectée. Puis je me suis souvenu qu’un décodeur du commerce était sensible à la polarité du signal DCC :
j’inverse donc les fils J et K, et là bingo : le monitor fonctionne, il me renvoie bien sur le PC toutes les trames émises par la centrale.J’en déduit que cette bibliotheque ne fonctionne pas correctement car tout décodeur DCC doit pouvoir détecter les bits DCC (c’est à dire leur durée de modulation) quelque soit la polarité du signal DCC dans les rails.
Je pense que cette librairie se contente de générer une interruption uniquement sur un type de front (par ex front montant) alors qu’elle devrait générer une IT sur tous les fronts !Bon, c’est pas non plus rédhibitoire pour ce genre d’application ou pour un décodeur d’accessoires, mais quand même, une petite explication sur les limites de ce genre de montage serait la bienvenue.
-
Bonjour,
Ce moniteur repose sur la bibliothèque de MynaBay dont le fonctionnement interne n’est pas exposé.
Mais on peut tout à fait aller voir comment elle fonctionne. Le signal DCC provoque une interruption (broche à choisir) sur les fronts montants et descendant. à Chaque front correspond une date qui est issue du Timer 0 via la fonction
micros(). Il suffit d’aller voir dans le code de la bibliothèque de MynaBay. Ligne 76 la fonction qui attache l’interruption, ligne 46, le handler d’interruption.Déclencher une interruption sur les deux fronts ne suffit pas pour corriger l’erreur de branchement, il faut également écouter le bus afin de déterminer si c’est le front montant qui détermine le début de bit ou le front descendant, ce que ne fait pas la bibliothèque de MynaBay (à priori). Si on n’est pas calé sur le bon front alors le front inverse ne sépare pas la durée en deux parties égales.
-
-
Un moniteur de signaux DCC 4 février 2018 19:29, par Dominique
J’ai eu le même souci avec mon décodeur hier.
C’est vrai que revoir la façon de mesurer la largeur des bits avec l’Input Capture Unit que j’ai regardé cet après-midi sur le site de Nick Gammon serait à faire prochainement.
Je vais me pencher sur le sujet !Voir en ligne : Input Capture Unit
-
Un moniteur de signaux DCC 1er septembre 2018 18:14, par Pierre
Bonjour,
J’ai réalisé ce projet, pour savoir ce que m’envoie ma centrale Intellibox1, avant d’attaquer le projet "Accessories" pour piloter mes aiguillages.
Avec des commandes de locomotives, je voit bien les trames DCC de vitesse, lumière, etc..
Par contre si j’envoie une commande d’aiguillage depuis ma Centrale, je ne voit rien à part les trames Idle.
Est-ce normal, ou c’est ma Centrale qui a un problème et n’envoie pas de commande pour les aiguillages ?Cordialement
-
Un moniteur de signaux DCC 2 septembre 2018 18:50, par Dominique
Le programme présenté dans cet article ne présente que les commandes de locomotives,
Si vous voulez voir les commandes d’accessoires, il faut utiliser le programme Dcc_Basic_Acc_decoder qui se trouve dans le dossier « exemples » de la bibliothèque, en passant par le menu « exemples » de l’IDE.
-
Bonjour,
J’ai chargé ce programme, mais la console série reste désespérément vide.
Est-ce qu’en appuyant par exemple sur le bouton qui commande l’aiguillage 1 sur mon Intellibox1, je devrait obtenir un message sur la console série, ou est-ce plus subtil ?
Cordialement
-
-
Un moniteur de signaux DCC 3 septembre 2018 11:27, par Dominique
Je pense que oui..
je ne peux pas répondre plus précisément maintenant mais vous trouverez la réponse en explorant les liens de l’article.
-
Un moniteur de signaux DCC 4 septembre 2018 19:23, par Pierre
Bonjour,
Ce que je trouve curieux, c’est que au niveau du moniteur pour signaux de locomotives, j’ai finalement très peu de trames affichées.
La plupart du temps, j’ai 0 dans Total Packet Count et dans les autres valeurs, et de temps en temps je vois passer une trame de 1 et 0.
Il me sembkle que au début de l’article, vous montrez les trames les unes en dessous des autres, j’en suis loin.
Est-ce normal ?
Cordialement
-
A priori ce n’est pas normal et vous devriez reconnaître vos locos. S’il n’y a aucune loco, ça peut être normal.
Essayez d’inverser les fils d’entrée DCC et ajoutez une capa comme indiqué sur le forum :
-
-
Un moniteur de signaux DCC 20 août 2019 01:46, par jerome
Bonjour,
Je me suis appuyé sur votre article pour écouter les ordres d’aiguillages dcc depuis ma cs3 de Marklin.
Le schéma du circuit est très simple et très facile à suivre et cela a marché du premier coup.
Je vais pouvoir faire de grosses économies sur le matériel pour piloter mes aiguillages.Donc je voulais vous dire un grand merci !
-
Un moniteur de signaux DCC 1er avril 2020 19:19, par Guy
Bonsoir,
J’ai essayé plusieurs montages avec 6N137 et 4N35, cependant l’arduino nano ne lit aucune des trames dcc émises soit par une centrale ROCO ou un arduino uno doit le programme est DCC master station qui est reconnu par mes locomotives équipés de décodeurs.De quoi cela peut-il venir ?
Merci pour votre aide
Cordialement
-
Un moniteur de signaux DCC 1er avril 2020 23:06, par msport
Bonjour,
dans un premier temps, vérifiez au multimètre que vous avez bien 2,5 volts sur la pin 2 de l’Arduino. (tension moyenne que vous devez lire à cet endroit)
Pour aller plus loin, ouvrez un sujet dans le forum pour pouvoir joindre une photo de votre montage.
Cordialement-
Bonsoir,
Merci pour votre réponse.
J’ai mesuré 2,3V à la pin 2 de l’arduino lorsque j’utilise le 5V fournit par l’arduino (environ 4.5V), en revanche en utilisant une alimentation externe 5V je ne retrouve pas 2,5V mais 4,4V est-ce normal ? tout cela avec le même montage.Cordialement
-
-
Un moniteur de signaux DCC 2 avril 2020 22:17, par msport
Bonsoir,
pas normal, bien sur.
c’est peut-être un problème de masse (GND) qui devrait être commune ou séparée ?
Schéma de ce que vous avez monté, photo ?
Cordialement-
Bonjour,
Merci beaucoup et effectivement les masses n’étaient pas toutes rassemblées et l’opto était hs . Maintenant j’ai pu voir les trames, la prochaine étape est d’arriver à faire communiquer un décodeur d’accessoire (signaux) avec le logiciel RocRail. Peut-être lire les trames pour ce décodeur.
Bon après midi
Cordialement
-
-
Un moniteur de signaux DCC 8 avril 2020 14:31, par msport
-
Un moniteur de signaux DCC 17 juillet 2020 17:53, par Stéphane
Bonjour,
Je voudrais essayer ce moniteur de signaux, malheureusement, lorsque je souhaite télécharger la bibliothèque, Chrome m’indique : "Chrome a bloqué dcc_decoder.zip car ce fichier peut être dangereux". Que se passe-t-il ? Contient-il virus et/ou malwares ? -
Un moniteur de signaux DCC 17 juillet 2020 21:42, par msport
Bonsoir,
dcc_decoder.zip ne contient que le fichier .ino (le sketch)
C’est du texte, je ne vois pas quel danger il peut représenter. (sauf pour vos neurones).
D’ailleurs, je viens de le télécharger et Chrome ne s’est pas plaint. Voyez plutôt pourquoi votre antivirus est devenu paranoïaque.-
Merci mais rien à voir avec l’anti-virus, c’est Chrome (et donc Google) qui bloquait le téléchargement. Aujourd’hui ça fonctionne. Allez comprendre ...
(Pour info, le zip ne contient pas que le .ino, mais le .cpp et le .h de la librairie, et les .ino des exemples !)
-
-
Un moniteur de signaux DCC 20 juillet 2020 12:56, par msport
Oui, effectivement, c’est dcc_monitor_lcd qui ne contient que le sketch, mais le 2e zip ne contient que du texte aussi, donc c’est sans risque au premier degré. Je n’ai pas encore vu de virus fourni sous une forme à compiler ...
Vous pouvez également regarder le sniffer de Rudy qui est un peu plus explicite.
Les photos sont dans le topic=460.
On peut également utiliser le DCC pour alimenter le montage, c’est encore plus pratique.Voir en ligne : Moniteur DCC - Version autonome du sniffer de Rudy
-
Je parlais d’anti-virus parce que Chrome accepte au moins cinq ou six plugins antivirus et j’imagine que c’est un plugin qui est entré en action (?)
-
Non je supprime toujours les plugins que les anti-virus essaient d’ajouter. Là, il s’agissait bien d’un blocage de Chrome.
J’ai trouvé quelques explications ici : Chrome bloquera automatiquement les téléchargements non sécurisés
Il semble qu’avec la version 83 (dont je dispose), les fichiers zip affichent un avertissement. Bizarrement dans mon cas ils ont été bloqués, et puis débloqués ... Mais d’après les infos, dès la prochaine version, ils seront définitivement bloqués, jusqu’à ce que Locoduino passe en HTTPS !-
Pas d’avertissements de mon coté avec la version 83.
Je suppose donc que Locoduino propose donc son téléchargement en https.
Incidemment, la Version 84.0.4147.89 (Build officiel) (64 bits) s’est installée.-
Locoduino est passé en HTTPS !!!
-
Merci pour l’info ! Maintenant il faut configurer une redirection automatique lorsqu’une requête arrive en http pour qu’elle soit automatiquement redirigée vers sont équivalent en https, car pour ma part, je tape locoduino.org dans la barre d’adresse, et je tombe sur le site de locoduino en http ... Je ne savais même pas que le https existait sur ce site ...
-
-
-
-
-