LOCODUINO

Un moniteur de signaux DCC

Comment espionner les commandes émises par la centrale DCC

.
Par : Dominique

DIFFICULTÉ :

Dans l’article « L’Arduino et le système de commande numérique DCC », nous avons vu à quoi ressemble la norme DCC.

Dans l’article « Comment piloter trains et accessoires en DCC avec un Arduino (2) », nous avons étudié la bibliothèque CmdrArduino qui se charge de générer les signaux DCC pour nous en tâche de fond.

Dans cet article nous allons utiliser une autre bibliothèque pour visualiser sur notre ordinateur les trames DCC qui sont envoyées aux rails, pour vérifier le bon fonctionnement de notre projet.

Cette bibliothèque est celle de Minabay qui est aussi utilisée dans l’article Un décodeur d’accessoires universel (1).

Mais cette fois-ci, la bibliothèque va observer le signal DCC et afficher les paquets vus toutes les 2 secondes.

La trace ci-dessous correspond à ce que ma centrale "va-et-vient" envoie en mode automatique. On peut voir l’adresse 4 de la loco (premier octet 00000100) et les 2 commandes :

  • la lumière (fonction groupe 1) : 10010000 (allumée)
  • la vitesse : advanced operation instruction 00111111 + octet de vitesse (bits 0..6) et direction (bit 7)

Le dernier octet est le code de contrôle qui ne nous intéresse pas ici.

J’ai ajouté la signification des paquets à droite de la liste.

Total Packet Count: 144
Idle Packet Count:  127
Longest Preamble:  489
Count    Packet_Data
127      11111111 00000000 11111111
4        00000100 00111111 00000001 00111010		speed 1<
8        00000100 10010000 10010100			        FL on
1        11111111 00000000 00000000 11111111
4        00000100 00111111 10000011 10111000		speed 3>
============================================
Total Packet Count: 144
Idle Packet Count:  127
Longest Preamble:  505
Count    Packet_Data
127      11111111 00000000 11111111
1        11111111 00000000 00000000 11111111
4        00000100 00111111 10000101 10111110
8        00000100 10010000 10010100				FL on
4        00000100 00111111 10000111 10111100		speed 7>
============================================
Total Packet Count: 144
Idle Packet Count:  128
Longest Preamble:  529
Count    Packet_Data
128      11111111 00000000 11111111
8        00000100 10010000 10010100				FL on
4        00000100 00111111 10001001 10110010		speed 9>
4        00000100 00111111 10001011 10110000		speed 11>
============================================

Premières constatations :

  • On compte bien entre 130 et 140 paquets par seconde comme calculé dans la Présentation de la norme DCC. Ici on a 272 paquets en 2 secondes.
  • Environ 90% des paquets sont des Idle 11111111 00000000 11111111
  • La bibliothèque répète bien automatiquement les paquets de vitesse et lumière, environ 4 fois par seconde

Réalisation matérielle du moniteur

J’ai utilisé un simple Nano complété par un petit circuit d’interface entre les rails (tension +/- 15 volts, insupportable pour l’Arduino) et la broche 2 programmée en entrée digitale sous interruption.

Ce circuit est celui du site Minabay : j’y ai ajouté un condensateur de 270 pF (une valeur inférieure, jusqu’à 30-50 pF peut convenir également).

Voici la liste des composants nécessaires :

  • un Arduino (j’ai choisi un Nano mais n’importe lequel doit convenir)
  • 2 résistances de 10kΩ
  • 1 résistance de 1kΩ
  • 1 Diode 1N4148
  • 1 condensateur de 270 picoFarad
  • 1 Opto-coupleur 6N137 (il en faut un rapide quand même)
  • 1 plaque d’essai pour assembler les composants

Plutôt que d’utiliser un Uno avec son bornier femelle, j’ai préféré le Nano sans bornier. J’ai inséré des barrettes à souder dans les trous à la place des barrettes à picots habituels : de cette façon les fils à raccorder au Nano sont soudés sur les barrettes ce qui procure un meilleur contact qu’un ensemble de prises mâle et femelle.

De ce fait, les barrettes du Nano ne sont soudées qu’aux 4 coins ce qui permet de récupérer l’Arduino si le projet n’est plus utilisé plus tard.

A l’arrière de la plaque d’essai, le nombre de soudures est minimal et on ne prend pas de risque da court-circuits.

Le circuit terminé ne m’a pris qu’une petite heure. Le connecteur 4 points permet de sortir une liaison I2C vers un afficheur LCD 4 lignes de 20 caractères qui devrait me permettre de me passer du PC/Mac, à condition d’ajouter une petite alimentation 5V. Pour la liaison I2C, ne pas oublier les 2 resistances de rappel au 5V, de 4,7kΩ chacune sur SDA et SDL respectivement.

Le logiciel qui suit ne tient pas compte de cette possibilité.

La mise en boite est un simple sandwich entre 2 planchettes de contreplaqué.

Le logiciel

Après installation de la bibliothèque, on ouvre simplement l’exemple DCC_Monitor qui se trouve dans le dossier DCC_Decoder.

// DCC_Monitor
// Based on DCC_Decoder Library Version 4
// Dump of DCC packets every 2 seconds
// Arduino Pin 2 is the DCC input. It drives interrupt 0.

#include <DCC_Decoder.h>

////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////
//
// Defines and structures
//
#define kDCC_INTERRUPT    0

typedef struct
{
    int count;
    byte validBytes;
    byte data[6];
} DCCPacket;

////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////
//
// The dcc decoder object and global data
//
int gPacketCount = 0;
int gIdlePacketCount = 0;
int gLongestPreamble = 0;

DCCPacket gPackets[25];

static unsigned long lastMillis = millis();
    
////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////
//
// Packet handlers
//

// ALL packets are sent to the RawPacket handler. Returning true indicates
// that packet was handled. DCC library starts watching for 
// next preamble. Returning false and library continue parsing packet
// and finds another handler to call.
boolean RawPacket_Handler(byte byteCount, byte* packetBytes)
{
    // Bump global packet count
    ++gPacketCount;
    
    int thisPreamble = DCC.LastPreambleBitCount();
    if( thisPreamble > gLongestPreamble )
    {
        gLongestPreamble = thisPreamble;
    }
    
    // Walk table and look for a matching packet
    for( int i=0; i<(int)(sizeof(gPackets)/sizeof(gPackets[0])); ++i )
    {
        if( gPackets[i].validBytes )
        {
            // Not an empty slot. Does this slot match this packet?
            // If so, bump count.
            if( gPackets[i].validBytes==byteCount )
            {
                char isPacket = true;
                for( int j=0; j<byteCount; j++)
                {
                    if( gPackets[i].data[j] != packetBytes[j] )
                    {
                        isPacket = false;
                        break;
                    } 
                }
                if( isPacket )
                {
                   gPackets[i].count++;
                   return false;
                }
            }
        }else{
                // Empty slot, just copy over data
            gPackets[i].count++;
            gPackets[i].validBytes = byteCount;
            for( int j=0; j<byteCount; j++)
            {
                gPackets[i].data[j] = packetBytes[j];
            }
            return false;
        }
    }    
    
    return false;
}

// Idle packets are sent here (unless handled in rawpacket handler). 
void IdlePacket_Handler(byte byteCount, byte* packetBytes)
{
    ++gIdlePacketCount;
}

////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////
//
// Setup
//
void setup() 
{ 
    Serial.begin(9600);
    
    DCC.SetRawPacketHandler(RawPacket_Handler);   
    DCC.SetIdlePacketHandler(IdlePacket_Handler);
            
    DCC.SetupMonitor( kDCC_INTERRUPT );   
}

////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////
void DumpAndResetTable()
{
    char buffer60Bytes[60];
    
    Serial.print("Total Packet Count: ");
    Serial.println(gPacketCount, DEC);
    
    Serial.print("Idle Packet Count:  ");
    Serial.println(gIdlePacketCount, DEC);
        
    Serial.print("Longest Preamble:  ");
    Serial.println(gLongestPreamble, DEC);
    
    Serial.println("Count    Packet_Data");
    for( int i=0; i<(int)(sizeof(gPackets)/sizeof(gPackets[0])); ++i )
    {
        if( gPackets[i].validBytes > 0 )
        {
            Serial.print(gPackets[i].count, DEC);
            if( gPackets[i].count < 10 )
            {
                Serial.print("        ");
            }else{
                if( gPackets[i].count < 100 )
                {
                    Serial.print("       ");
                }else{
                    Serial.print("      ");
                }
            }
            Serial.println(
            	DCC.MakePacketString(
                    buffer60Bytes,
            	    gPackets[i].validBytes,
            	    &gPackets[i].data[0]
                )
            );
        }
        gPackets[i].validBytes = 0;
        gPackets[i].count = 0;
    }
    Serial.println("============================================");
    
    gPacketCount = 0;
    gIdlePacketCount = 0;
    gLongestPreamble = 0;
}

////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////
//
// Main loop
//
void loop()
{
    DCC.loop();
    
    if( millis()-lastMillis > 1000 )
    {
        DumpAndResetTable();
        lastMillis = millis();
    }
}

Une fois le programme compilé et installé dans l’Arduino, on relie l’interface aux rails, puis on lance le moniteur de l’environnement Arduino ou tout autre terminal de son choix.

J’ai testé le programme sur différents Arduino, y compris le Due.

Version LCD I2C

On trouve facilement, pour 10€ environ, des afficheurs 4 lignes de 20 caractères avec une interface I2C.

J’ai donc modifié l’exemple de Minabay ci-dessus pour obtenir un affichage décodé selon les besoins de mon projet (centrale va-et-vient).

Toutes les 2 secondes, l’afficheur présente :

  • Sur la ligne 1 : le nombre de paquets IDLE et le nombre de paquets de données valides ;
  • Sur les lignes suivantes : le nombre de chaque type de paquet de données et leur signification.

Par exemple :
1@4>3 signifie 1 paquet d’adresse DCC 4, direction avant et vitesse 3
4@4>5 signifie 4 paquet d’adresse DCC 4, direction avant et vitesse 5
15@4L0 signifie 15 paquets d’adresse DCC 4, lumière éteinte
4@4>7 signifie 4 paquet d’adresse DCC 4, direction avant et vitesse 7

On voit bien l’accélération de 3 à 11 crans DCC pendant l’interval de 2 secondes.

Le logiciel de cette version est ici :

/*  DCC_Monitor for LCD 4x20

  Based on DCC_Decoder Library Version 4 from http://www.mynabay.com/arduino
  Display DCC packets counts every 2 seconds (IDLE should be around 50%)
  Arduino Pin 2 is the DCC input. It drives interrupt 0.
  Arduino Pin A4 is SDA, Pin A5 is SLC (even on Nano !).
  To connect an LCD 20x4 display via I2C

  Don't forget I2C pull-up resistors (4,7K each) connected to + 5V
  Compilation on Arduino 1.5.x necessitate a minor change in the DCC_Decoder library:
  Replace "prog_char*" type by "char*"
  
  Display 1st line : Idle paquets count, valid data paquets count
  Display next lines : for each data type :
  - paquet count, DCC address, 
    - speed paquet : direction (< or >), speed value (0..127)
    - light function paquet (FL) : L0 (off) or L1 (on)

  This program is free software; you can redistribute it and/or
  modify it under the terms of the GNU General Public License
  as published by the Free Software Foundation.
  
  Copyright (c) 2014 Dominique Bultez. */

#define VERSION "1.0b3 Oct 14"
#define D_USB // comment this line to cancel display to the computer's terminal

#include <DCC_Decoder.h>
#include <Wire.h> 
#include <LiquidCrystal_I2C.h>

LiquidCrystal_I2C lcd(0x27,20,4);  // set the LCD address to 0x27 for a 20 chars and 4 line display

////////////////////////////////////////////////////////////////////////////////////////
//
// Defines and structures
//
#define kDCC_INTERRUPT            0

typedef struct
{
    int count;
    byte validBytes;
    byte data[6];
} DCCPacket;

////////////////////////////////////////////////////////////////////////////////////////
//
// The dcc decoder object and global data
//
int gPacketCount = 0;
int gIdlePacketCount = 0;
int gLongestPreamble = 0;

DCCPacket gPackets[25];

static unsigned long lastMillis = millis();
    
////////////////////////////////////////////////////////////////////////////////////////
//
// Packet handlers
//

// ALL packets are sent to the RawPacket handler. Returning true indicates
// that packet was handled. DCC library starts watching for 
// next preamble. Returning false and library continue parsing packet
// and finds another handler to call.
boolean RawPacket_Handler(byte byteCount, byte* packetBytes)
{
        // Bump global packet count
    ++gPacketCount;
    
    int thisPreamble = DCC.LastPreambleBitCount();
    if( thisPreamble > gLongestPreamble )
    {
        gLongestPreamble = thisPreamble;
    }
    
        // Walk table and look for a matching packet
    for( int i=0; i<(int)(sizeof(gPackets)/sizeof(gPackets[0])); ++i )
    {
        if( gPackets[i].validBytes )
        {
                // Not an empty slot. Does this slot match this packet? If so, bump count.
            if( gPackets[i].validBytes==byteCount )
            {
                char isPacket = true;
                for( int j=0; j<byteCount; j++)
                {
                    if( gPackets[i].data[j] != packetBytes[j] )
                    {
                        isPacket = false;
                        break;
                    } 
                }
                if( isPacket )
                {
                   gPackets[i].count++;
                   return false;
                }
            }
        }else{
                // Empty slot, just copy over data
            gPackets[i].count++;
            gPackets[i].validBytes = byteCount;
            for( int j=0; j<byteCount; j++)
            {
                gPackets[i].data[j] = packetBytes[j];
            }
            return false;
        }
    }    
    
    return false;
}

// Idle packets are sent here (unless handled in rawpacket handler). 
void IdlePacket_Handler(byte byteCount, byte* packetBytes)
{
    ++gIdlePacketCount;
}

////////////////////////////////////////////////////////////////////////////////////////
//
// Setup
//
void setup() 
{ 
   Serial.begin(115200);
   lcd.init();                      // initialize the lcd 
   lcd.backlight();

   lcd.print("DCC monitor Version ");
   lcd.print(VERSION);
   delay(1000);
   //lcd.clear();
   
   DCC.SetRawPacketHandler(RawPacket_Handler);   
   DCC.SetIdlePacketHandler(IdlePacket_Handler);
            
   DCC.SetupMonitor( kDCC_INTERRUPT );   
}

////////////////////////////////////////////////////////////////////////////////////////
void DumpAndResetTable()
{
    char buffer60Bytes[60];
    
    #ifdef D_USB
    Serial.print("Total Packet Count: ");
    Serial.println(gPacketCount, DEC);
    #endif
    
    lcd.clear();
    //lcd.setCursor(0, 0);    // 1e ligne
    lcd.print("Idle:");
    lcd.print(gIdlePacketCount, DEC);

    #ifdef D_USB
    Serial.print("Idle Packet Count:  ");
    Serial.println(gIdlePacketCount, DEC);
    #endif
    
    lcd.print(" Data:");
    lcd.print(gPacketCount - gIdlePacketCount, DEC);
    lcd.print("  ");    
    
    #ifdef D_USB
    Serial.print("Longest Preamble:  ");
    Serial.println(gLongestPreamble, DEC);    
    Serial.println("Count    Packet_Data");
    #endif
    
    lcd.setCursor(0, 1);    // 2e ligne
    int j=0;
    for( int i=0; i<(int)(sizeof(gPackets)/sizeof(gPackets[0])); ++i )
    {
        if( gPackets[i].validBytes > 0 )
        {
            if (gPackets[i].count != gIdlePacketCount)
            {
              #ifdef D_USB
              Serial.print(gPackets[i].count, DEC);                                
              if( gPackets[i].count < 10 )
              {
                Serial.print("        ");
              }else{
                if( gPackets[i].count < 100 )
                {
                    Serial.print("       ");
                }else{
                    Serial.print("      ");
                }
              }
              Serial.println(
                  DCC.MakePacketString(
                      buffer60Bytes,
                      gPackets[i].validBytes,
                      &gPackets[i].data[0]
                  )
              );
              #endif
              
              if (gPackets[i].data[0] != 255)
              {
                lcd.print(gPackets[i].count, DEC);
                lcd.print("@");
                lcd.print(gPackets[i].data[0], DEC);
                switch (gPackets[i].data[1]) 
                {
                  case 0x3F:  // Advanced Operation Instruction : speed & direction
                  if (gPackets[i].data[2] > 127)
                  {
                    lcd.print(">");
                    lcd.print(gPackets[i].data[2] - 128);
                  }else{
                    lcd.print("<");
                    lcd.print(gPackets[i].data[2]);
                  }
                  break;
                  case 0x90:  // Fonction Group One FL on
                  lcd.print("L1");
                  break;
                  case 0x80:  // Fonction Group One FL off
                  lcd.print("L0");
                  break;
                  default:
                  lcd.print(gPackets[i].data[1], HEX);
                  break;                  
                }
                j++;
                if (j>5) j=0;
                switch (j)
                {
                  case 0:
                  lcd.setCursor(0, 1);    // 2e ligne
                  break;
                  case 1:
                  lcd.setCursor(10, 1);    // 2e ligne
                  break;
                  case 2:
                  lcd.setCursor(0, 2);    // 2e ligne
                  break;
                  case 3:
                  lcd.setCursor(10, 2);    // 2e ligne
                  break;
                  case 4:
                  lcd.setCursor(0, 3);    // 2e ligne
                  break;
                  case 5:
                  lcd.setCursor(10, 3);    // 2e ligne
                  break;
                }
              }
            }
        }
        gPackets[i].validBytes = 0;
        gPackets[i].count = 0;
    }
    #ifdef D_USB
    Serial.println("============================================");
    #endif
    
    gPacketCount = 0;
    gIdlePacketCount = 0;
    gLongestPreamble = 0;
}

////////////////////////////////////////////////////////////////////////////////////////
//
// Main loop
//
void loop()
{
    DCC.loop();
    
    if( millis()-lastMillis > 2000 )
    {
        DumpAndResetTable();
        lastMillis = millis();
    }
}

Le code peut être téléchargé ici :

La bibliothèque peut être téléchargée ici :

Dernièrement j’ai ajouté un circuit d’alimentation à partir des rails : il contient un pont redresseur reliée au connecteur des rails et suivi d’une capacité de 22uF, puis d’un régulateur 7805 et d’une capacité de 100uF. La sortie est reliée directement au 5V de l’Arduino.

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+

    Répondre

    • Un moniteur de signaux DCC 21 février 2015 23:42, par Dominique

      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

      Répondre

  • 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 :-(

    Répondre

  • 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.

    Répondre

  • 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

    Répondre

  • 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

    Répondre

    • Un moniteur de signaux DCC 2 novembre 2015 14:04, par Dominique

      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

      Répondre

  • 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.

    Répondre

    • Un moniteur de signaux DCC 12 février 2016 22:16, par Dominique

      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

      Répondre

      • Un moniteur de signaux DCC 2 mars 2016 00:54

        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 ...

        Répondre

        • Un moniteur de signaux DCC 2 mars 2016 06:58, par Jean-Luc

          Bonjour,

          D1 est dans le bon sens ?

          Répondre

        • Un moniteur de signaux DCC 2 mars 2016 09:58, par Dominique

          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 ?

          Répondre

          • Un moniteur de signaux DCC 2 mars 2016 12:14

            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.

            Répondre

            • Un moniteur de signaux DCC 2 mars 2016 13:14, par Jean-Luc

              Tant que tu ne l’as pas grillé, tout va bien :-)

              Répondre

              • Un moniteur de signaux DCC 11 mars 2016 14:25

                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µF

                C1 : condensateur céramique ajouté entre 5 et 8

                Merci pour cet article et votre attention.

                Répondre

    • 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

      Répondre

      • Un moniteur de signaux DCC 14 février 2023 17:41, par msport

        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

        Répondre

  • 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 !

    http://us.leforum.eu/t11332-Une-com...

    Répondre

    • Un moniteur de signaux DCC 8 mars 2016 16:54, par Dominique

      Merci pour l’info !

      Ce sera l’occasion de compléter nos articles ;)

      Répondre

    • Un moniteur de signaux DCC 10 mars 2016 14:59, par DDEFF

      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...)

      Répondre

  • 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 scope

    DCC.loop() ;

    Répondre

  • 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 !

    Répondre

  • 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é

    Répondre

    • Un moniteur de signaux DCC 29 juin 2017 20:19, par Dominique

      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 6N137

      Quand 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...

      Répondre

      • Un moniteur de signaux DCC 11 juillet 2017 17:42, par frenchpapa

        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

        Répondre

      • Un moniteur de signaux DCC 29 août 2018 16:35, par Pierre

        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.

        Répondre

        • Un moniteur de signaux DCC 29 août 2018 18:55, par Dominique

          Il y a une discussion sur le forum :
          Mini décodeur à base d’ATTiny 84

          qui 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).

          Répondre

          • Un moniteur de signaux DCC 29 août 2018 19:04, par Pierre

            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.

            Répondre

  • 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)

    Répondre

    • Un moniteur de signaux DCC 30 décembre 2017 17:20, par Dominique

      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.

      Répondre

  • 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.

    Répondre

    • Un moniteur de signaux DCC 4 février 2018 17:09, par Jean-Luc

      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.

      Répondre

  • 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

    Répondre

  • 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

    Répondre

  • 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.

    Répondre

    • Un moniteur de signaux DCC 3 septembre 2018 09:36, par Pierre

      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

      Répondre

  • 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.

    Répondre

  • 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

    Répondre

  • 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 !

    Répondre

  • 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

    Répondre

  • 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

    Répondre

    • Un moniteur de signaux DCC 2 avril 2020 19:47, par Guy

      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

      Répondre

  • 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

    Répondre

    • Un moniteur de signaux DCC 8 avril 2020 13:39, par Guy

      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

      Répondre

  • Un moniteur de signaux DCC 8 avril 2020 14:31, par msport

    Bonjour,
    à vous de déterminer comment RocRail commande les accessoires :

    Voir en ligne : Rocrail

    Répondre

  • 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 ?

    Répondre

  • 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.

    Répondre

    • Un moniteur de signaux DCC 20 juillet 2020 11:32, par Stéphane

      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 !)

      Répondre

  • 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

    Répondre

    • Un moniteur de signaux DCC 20 juillet 2020 13:01, par msport

      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 (?)

      Répondre

      • Un moniteur de signaux DCC 21 juillet 2020 17:05, par Stéphane

        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 !

        Répondre

        • Un moniteur de signaux DCC 21 juillet 2020 19:55, par msport

          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.

          Répondre

          • Un moniteur de signaux DCC 21 juillet 2020 20:11, par Dominique

            Locoduino est passé en HTTPS !!!

            Répondre

            • Un moniteur de signaux DCC 22 juillet 2020 01:12, par Stéphane

              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 ...

              Répondre

Réagissez à « Un moniteur de signaux DCC »

Qui êtes-vous ?
Votre message

Pour créer des paragraphes, laissez simplement des lignes vides.

Lien hypertexte

(Si votre message se réfère à un article publié sur le Web, ou à une page fournissant plus d’informations, vous pouvez indiquer ci-après le titre de la page et son adresse.)

Rubrique « Projets »

Les derniers articles

Les articles les plus lus