OpenDCC - Station de commande DCC - Détails du logiciel

    Différents logiciels peuvent être chargés. Dans cette page vous trouverez la description de logiciels polyvalents qui sont configurables au moyen de cavaliers.

      Cavalier / Mode de fonctionnement
      JP2 JP1 Mode
       ouvert   ouvert  Fonctionne en mode station de commande, le jeu de commande émule l'Intellibox ® de Uhlenbrock. Le jeu de commande peut être changé pour émuler Lenz (En changeant la valeur dans un #define dans config.h, nécessite une recompilation).
       ouvert   fermé  Fonctionne en mode contrôleur DMX, commande au moyen de touches (La télécommande n'est pas encore activée)
      (Note: Cela est obsolète, merci de réaliser le contrôle DMX avec le décodeur DMX .)
       fermé   ouvert  Fonctionne en mode interface HSI88, le jeu de commande est compatible de Littfinski
      fermé fermé Fonctionne en mode test: Tous les voyants clignotent, toutes les données sur l'interface sont renvoyées Ã&xnbsp; 19200 bauds.


    Quand il n'y a pas de cavaliers, le terminal fonctionne en mode station de commande DCC. Les commandes du PC sont traduites en DCC. OpenDCC (selon le choix effectué) émulera soit la station de commande Lenz soit une Intellibox ® (default). Toutes les commandes selon Lenz V3.0 ou IB ne sont pas implémentées. Par exemple les commandes pour 27 pas de vitesse et pour la multi-traction ne sont pas implémentées.

    Le logiciel est écrit en C sous WinAVR (basé sur avrgcc), il est simulé sous AVR-Studio (disponible Ã&xnbsp; www.atmel.com).
    Le logiciel est librement disponible comme open source sous licence GNU.
    Lors du développement un grand soin a été pris pour maximiser le débit des commandes DCC; en outre, un algorithme intelligent de rafraîchissement est aussi implémenté. Il donne priorité aux nouvelles commandes de vitesse puis les répètent de manière cyclique. La fréquence de répétition des commandes pour les locos qui n'ont pas été utilisées depuis longtemps est diminuée. L' algorithme fait une également distinction entre fonctions, accélération et freinage: Les commandes de frein ont la priorité maximale.

    Le logiciel est constitué de différents modules:


      module overview

       

    • HARDWARE.H: Initialisation du processeur et des ports
    • CONFIG.H: Initialisation des modes de fonctionnement, de la taille mémoire, etc.
    • DCCOUT.C: Génération du protocole DCC (DCC Encoder)
    • DMXOUT.C: Génération du protocole DMX (DMX Encoder)
    • ORGANIZER.C: Moteur des commandes DCC (priorité, répétition, rafraîchissement)
    • LENZ_PARSER.C, IBOX_PARSER.C: Traduction des commandes du PC en appels internes appropriés.
    • LENZ_PROGRAMMER.C, IBOX_PROGRAMMER.C: Traitement des commandes de programmation.
    • RS232.C: Interface avec le PC (incluant l'interruption et le contrôleur Fifo)
    • STATUS.C: Gestion d'état, compteur, boutons et voyants
    • S88.C: Evaluation du circuit externe de rétroaction.
    • MAIN.C: Initialisation, boucle de séquencement.

Génération

    Le module DCCOUT génère le signal envoyé sur les voies.

  • Quelle est l'allure d'un signal DCC?
    Sur la voie le signal DCC est Ã&xnbsp; tension constante, mais de polarité alternative. L'information vers les locomotives ou les aiguillages est codée au moyen des changements de polarité.

    Les règles de codage sont très simples: deux changements de polarité en l'espace de 58µs signifie: '1', deux changements en l'espace de 116µs signifie: '0'. Puisqu'il y a toujours deux changements de polarité symétrique, le signal de sortie n'a pas de composante continue et la polarité vue au récepteur n'est pas significative. Un '1' dure deux fois 58µs = 116µs. Un '0' dure le double du temps.


    Bild mit Bits

    Un flux de bits série est envoyé Ã&xnbsp; la locomotive. Pour permettre une évaluation de ces bits par le récepteur, le flux de données doit être subdivisé. Le signal DCC est subdivisé en préambule, data_octets et contrôle. Le préambule marque le début d'un nouveau message. Préambule, data_octets et le checksum (8 bits) sont séparés par un 0 l'un de l'autre.

    Afin de permettre la détection du préambule par le récepteur, il doit être construit conformément Ã&xnbsp; une règle qui ne s'applique pas dans le flux de données normal. Avec DCC le préambule est caractérisé par au moins douze bits Ã&xnbsp; 1. Puisque les octets de données sont séparés par «0» en paquets de 8 bits, cette longue séquence de "1" n'apparaît pas dans le flux normal de données.

    Le message (après le préambule) contient deux Ã&xnbsp; cinq octets de données (séparés par un 0), qui contiennent typiquement l'adresse et l'information de vitesse pour une locomotive. Le format DCC originel comprenait seulement 2 octets de données, cela a été étendu plus tard jusqu'Ã&xnbsp; 5 octets de données. Une somme de contrôle (checksum) est ajoutée Ã&xnbsp; ces octets de données, somme XOR sur 8 bits. Si le récepteur calcule le XOR de tous les octets reçus, le résultat doit être 00000000, seulement dans ce cas, le message est valide.


  • Quelle est la signification des différents bits?

    Le premier octet indique s'il s'agit d'une commande locomotive, décodeur d'accessoires ou d'une commande de programmation (service mode). Les octets suivants sont codés différemment selon leur groupe d'appartenance.

    First octet
    0: 00000000: L'adresse 0 est réservée pour la diffusion Ã&xnbsp; toutes les locomotives.
    1-127: 0AAAAAAA: Si le premier octet commence par un 0, alors il s'agit d'une commande de la locomotive avec adresse courte.
    128-191: 10AAAAAA: La plage (128-191) (y compris) est réservée aux accessoires décodeurs.
    192-231: 11000000-11100111: Il s'agit de l'en-tête pour une commande de locomotive avec une adresse longue, les autres bits d'adresse sont dans l'octet suivant.
    232-254: 11101000-11111110: Cette zone est réservée pour les extensions ..
    255: 11111111: rien est adressé (inoccupé).

    En principe, un message DCC commence toujours par un (ou deux octets d'adresse) suivi par un ou plusieurs octets de données dans lequel est codé l'action ou la vitesse de la locomotive.
    Le protocole DCC a été étendu de multiples fois au cours des années; Malheureusement, différentes représentations ont été mis en place pour la vitesse (14,27, 28 et 126 pas de conduite).
    Pour plus d'information sur le codage des octets de données voir NMRA.

  • Exemple 1: Commande de conduite pour la loco 5, avance Ã&xnbsp; vitesse 4 (sur 14 pas possibles).
    Une commande avec 3 octets est envoyée:
    Préambule bit_de_début  Octet adresse (=0AAAAAAA)
              bit_de_début  Octet de donnée (=01DCSSSS)
              bit_de_début  somme de contrôle
              bit_d'arrêt
    
    Dans cet exemple l'octet adresse AAAAAAA [A6..A0] est l'adresse de la locomotive et dans l'octet de donnée D est la Direction, C est la fonction lumière, SSSS indique la vitesse. Le message DCC est composé comme suit:

         octet adresse  = (Loco address & 0x7F);
         octet de donnée = 0b01000000 | (speed & 0x0F) | (direction bit << 5);
         Checksum = Addressoctet ^ dataoctet;
    
    Le bit de direction est "un" pour avance et "zéro" pour recule.
    Préambule 0 Octet adresse 0 octet donnée 0 somme de contrôle
    11111111111111 0 00000101 0 01100100 0 01100001


  • Exemple 2: commande DCC pour aiguillage
    Une commande avec 3 octets est envoyée:
    Préambule bit_de_début  octet d'adresse  10AAAAAA
              bit_de_début  octet de données 1AAA1BBR
              bit_de_début  somme de contrôle
              bit_d'arrêt
    
    Dans cet exemple l'adresse de l'aiguillage est constituée de l'octet adresse AAAAAA [A5 .. A0] et de l'octet donnée AAA [A8. A6], par lequel les bits d'adresse A8 Ã&xnbsp; A6 sont transférés inversés. BB est l'adresse locale dans le décodeur (0,1,2,3), R est le bit de sortie, c'est Ã&xnbsp; dire quelle bobine doit être activée ( vert/rouge). Le code est:
       octet adresse      = 0x80 + (adresse & 0x3F);
       octet donnée       = 0x80 + (adresse / 0x40) ^ 0x07) * 0x10;
       somme de contrôle  = octet_adresse ^ octet_donnée;
    
    L'adresse 0 est réservée Ã&xnbsp; une diffusion, de sorte que le premier groupe d'aiguillage commence Ã&xnbsp; l'adresse 1. Malheureusement, selon les protocoles PC il y a de petites différences, mais des différences gênantes relative Ã&xnbsp; l'adressage, et dans l'interprétation des bit de sortie ainsi que des bits d'activation (dans l'exemple ci-dessus le 1).

    Uhlenbrock (Intellibox) décrit et transmet comme suit :
    'r' (rouge = dévié) et ('r' peut être spécifié comme '0') (a train entering from the single track end of the turnout diverges when the switch is "thrown". )
    'g (vert = droit) et ('g' peut être spécifié comme '1')
    La plage d'adresses de l'interface PC démarre cependant Ã&xnbsp; 1, contrairement Ã&xnbsp; la documentation. Autrement dit, le premier décodeur est aux adresses 1 ... 4; Intellibox n'envoie jamais la commande d'arrêt sur la voie, même si cela est demandé par le PC.


    Lenz décrit le bit de direction en tant que D2 avec le texte suivant:
    D2: D2 = 0 signifie la sortie 1 de l'aiguillage est sélectionnée.
        D2 = 1 signifie la sortie 2de l'aiguillage est sélectionnée.
    Mais nulle part nous ne pouvons savoir ce que signifie la sortie 1 ou 2. L'examen d'un fichier journal, semble montrer que rouge et vert sont échangés. OpenDCC a une Variable de Configuration CV spéciale pour faire face Ã&xnbsp; cette inversion (commutable).
    Mais Lenz démarre avec l'adresse 0 pour les adresses aiguillage et la commande d'arrêt existe (au moins parfois).


  • Règles générales pour les paquets
    • Préambule: Un récepteur doit reconnaître le préambule Ã&xnbsp; parir d'au moins '1's, un préambule avec moins de 10 '1's doit être rejeté; une station de commande doit envoyer au moins 14 '1's. Le bit d'arrêt doit être inclus dans le préambule de la commande suivante. En mode programme , le préambule doit faire au moins 20 bits de long.
    • Longueur: Les paquets peuvent contenir de 3 Ã&xnbsp; 6 octets, cependant, le dernier octet est toujours un XOR de contrôle des octets.
    • intervalle de temps: Les paquets pour le même décodeur doivent être espacés d'au moins 5ms. Après plus de 30ms tout paquet DCC doit être renvoyé de telle sorte que le décodeur ne passe pas en analogique. Avec l'introduction de RailCom les paquets de demande de «transparence», deux paquets peuvent être envoyés directement au même décodeur...
  • Comment ces bits sont-ils générés dans OpenDCC?
    Le chronomètre 1 est utilisé, en mode CTC (Clear timer on Compare), après avoir atteint la valeur de comparaison le chronomètre recommence Ã&xnbsp; zéro. A ce moment le bit de DCC est commuté par le matériel. Les sorties des comparateurs sont connectées au booster et ainsi le signal envoyé sur le rail est généré.

    Pour ce chronomètre le dépassement de capacité génère également une interruption, la routine d'interruption met Ã&xnbsp; jour la valeur de comparaison pour le prochain bit, selon qu'un 0 or un 1 doit être envoyé. Chaque changement de polarité du signal DCC génère une interruption, toutes les deux interruptions le message DCC avance d'un bit.

    En débutant avec le préambule la routine d'interruption gère bit par bit le message DCC et gère également les bits spécifiques du protocole DCC. (pour ainsi dire, Layer 1). Cela signifie que le préambule et la somme de contrôle (octet XOR) sont calculés par l'l'ISR.

    Le prochain programme de niveau plus élevé, ne doit réunir que les octets de données et les transmettre Ã&xnbsp; DCCOUT (via le tableau de données »next_message "). La remise se fait au moyen d'un sémaphore ('next_message_count'). DCCOUT ne traite le message que si le sémaphore est supérieur Ã&xnbsp; zéro et décrémente ce sémaphore de 1 Ã&xnbsp; chaque fois qu'un message est envoyé sur les voies.

S88.C lecture des détecteurs d'occupation

    La routine S88.C lit les détecteurs d'occupation et supervise les changements. Il y a trois bus S88; Ils sont lus en parallèle. Si un bus a un flux de données plus court (Ã&xnbsp; savoir: a moins de bits), le flux est lu mais les bits ne sont pas évalués.

    On peut utiliser jusqu'Ã&xnbsp; 1024 entrées de détecteurs d'occupation; cependant, ils ne sont pas tous disponibles selon les formats. Si le mode HSI88 est actif, seulement 31*16 = 496 entrées peuvent être lues. Plus de 496 valeurs n'est pas possible selon la description de la norme HSI 88, de même les programmes de contrôle de PC sont limités Ã&xnbsp; cette valeur.

    Il y a deux tableaux de données, s88_data et S88_change. Si un changement est détecté lors de la lecture du bus S88, ce bit est copié dans le tableau de données s88_data et le bit correspondant est mis Ã&xnbsp; 1 dans le tableau s88_change. Quand le bit de donnée est envoyé au PC, the drapeau de changement est mis Ã&xnbsp; zéro.
    La notification au PC a lieu selon le protocole soit en mode quartet (Lenz), en mode octet (Intellibox) ou sous forme de valeurs 16 bits (Littfinski HSI88).

STATUS.C, Top du chronomètre et administration d'état

    Dans la routine status.c l'état des voyants est géré, les boutons et les entrées externes sont lues and le statut d'OpenDCC est géré.

    L'état des voyants est contrôlé par un chronomètre et utilise une "structure led_pwm". Cette structure contient pour chaque voyant le 'temps restant' dans l'état actuel, la durée de la période en état allumée et la durée de la période en état éteinte. Si le temps restant a une valeur nulle l'état actuel est maintenu en permanence. Il est donc facile de générer les différents modes de clignotement:
      LED_RS232_OFF;
         led_pwm.rs232_rest = 20000L / TICK_PERIOD;
         led_pwm.rs232_ontime = 50000L / TICK_PERIOD;
         led_pwm.rs232_offtime = 150000L / TICK_PERIOD;
         break;
    Par exemple le voyant RS232 est éteint durant 20mS avec ces valeurs, après cela il est allumé et clignote Ã&xnbsp; 5Hz avec un rapport impulsion-pause de 1:3. TICK_PERIOD est l'intervalle entre interruption du chronomètre. Il est fixé Ã&xnbsp; 5mS dans config.h. Toutes les définitions des temps de chronomètre dans le code sont faites en µs Ã&xnbsp; savoir 50000L signifies 50ms; on notera que ces valeurs sont mémorisées comme unsigned char, Ã&xnbsp; savoir quelle doivent être inférieures Ã&xnbsp; 1.25s.

    Le chronomètre est aussi utilisé pour l'anti rebond des poussoirs et comme compteur de délai d'attente pour les tâches de programmation.

ORGANIZER.C, administration des locomotives et des commandes

    C'est Ã&xnbsp; ce module de fournir Ã&xnbsp; faible temps de latence et le débit de données élevé pour les commandes de locomotives, ainsi que d'organiser le rafraîchissement des locomotives déjÃ&xnbsp; en mouvement. La mise en Å“uvre sophistiquée de ce module est l'un des principaux avantages de OpenDCC par rapport aux contrôleurs disponibles sur le marché!

    La limite actuelle est le débit sur​le rail. DCC a une moyenne d'environ 4000 - 5000 bits / s, soit environ 100 messages / s. Par conséquent, dans OpenDCC un ensemble de règles est défini qui garantissent que les nouveaux messages sont émis rapidement et sont ensuite repris avec une priorité plus basse dans le rafraîchissement général.

    Les commandes de frein (par exemple des commandes avec laquelle la vitesse est réduite par rapport Ã&xnbsp; la vitesse réelle) sont exécutées avec priorité sur le rail, alors qu' une commande d'accélération émise simultanément pour une autre locomotive doit attendre un petit peu.

    jeu de règles pour l'organizer
    Pour les commandes de locomotive: la vitesse de loco est stockée dans la mémoire loco.
    
    Analyser tous les files d'attente et des tampons de la loc, pour analyser si une vieille commande
    pour cette locomotive est toujours en attente - si oui, échanger et traiter la nouvelle commande.
    
    La vitesse est-elle supérieure ou inférieure à la vitesse actuelle?
    -     si inférieure: mettre la commande dans la queue haute priorité.
    -     si supérieure:(ou fonction ou accessoire): mettre la commande dans la queue basse priorité.
    
    Quand une commande prise dans une queue est exécutée, 
    alors cette commande est mémorisée dans le tampon de répétition:
        Les commandes de vitesse sont répétées 3 fois, celles pour accessoires sont répétées 2 fois.
    L'envoi de la commande sur les rails est effectué dans l'ordre suivant:
       1. queue haute priorité.   Puis quand cette queue est vide:
       2. queue basse priorité.   Puis quand cette queue est vide:
       3. Tampon de répétition.   Puis quand cette queue est également vide:
       4. Rafraîchir la mémoire loc. (selon la séquence suivante:
                 Speed, funct1, speed, funct2, speed, funct3, speed)
    
    

    En outre, l'organisateur suit quelques règles supplémentaires comme par exemple aucune commande deux fois successivement pour les mêmes locomotives, priorité Ã&xnbsp; la commande diffusion, ...etc...

    Nombre de locomotives et format
    OpenDCC peut adresser jusqu'Ã&xnbsp; 9999 (Lenz parser) ou 10239 (Intellibox parser) locomotives. Cependant elles ne peuvent pas rouler en même temps. Le nombre de locos roulant en même temps est limité (par le logiciel actuel) Ã&xnbsp; 64 (espace de mémorisation dans le tampon locomotive), plus de loco n'a pas vraiment de sens avec le protocole DCC. Un message DCC dure environ 8-12ms, selon l'adressage et le nombre de pas de vitesse, Ã&xnbsp; savoir qu'avec 10 plus de locomotives freinant simultanément les choses commencent Ã&xnbsp; être intéressantes. Cependant, plus de locomotives peuvent tout Ã&xnbsp; fait exister; En cas de problèmes de place la mémoire de la locomotive et le tampon de répétition restent adaptés en supprimant la locomotive la plus «ancienne». De plus cette ancienne locomotive n'est plus rafraîchie.

    OpenDCC peut utiliser l'adressage DCC14, DCC28 or DCC128. Ce problème est résolu dans le cas du protocole Lenz simplement par la commande de conduite Ã&xnbsp; partir du PC. Dans le cas du protocole IB il n'y a pas de commande qui définit le format. Ainsi, deux commandes supplémentaires ont été définies, qui permettent la définition d'un format de locomotive du PC vers OpenDCC:
    P50X-ASCII LS {Lok#, [Format], [Steps]}
    only "2" (=DCC) est autorisé pour le format.
    P50X-BINARY 0x86: XLokCfgSet - length 1+3;
    octet1+octet2 = addr, octet3 = format

    Certains programmes de contrôle de PC ne stockent même pas le format de la locomotive, mais demandent cette information de format Ã&xnbsp; la station de commande. OpenDCC mémorise le format d'une locomotive dans l'EEPROM et retourne la valeur Ã&xnbsp; la prochaine requête du programme d'ordinateur.

    Si une locomotive n'a jamais été contrôlée auparavant, le format par défaut est renvoyé. OpenDCC travaille avec comme paramètre par défaut la valeur DCC28 qui est modifiable par un CV. Pour commander une locomotive dans un autre format, il suffit d'appeler cette locomotive une fois dans le format souhaité. OpenDCC prend en charge un maximum de 64 locomotives avec un format s'écartant de la valeur par défaut.

    Toutes les vitesses sont mémorisées en interne OpenDCC au format DCC128. Les commandes de vitesse sont toujours converties dans ce format par le parser. La conversion inverse est effectuée pour émettre le message DCC sur la voie. (Les Routines: convert_speed_to_rail () et convert_speed_from_rail () sont utilisées Ã&xnbsp; cet effet).
    Si le Parser Intellibox® est utilisé, aucune conversion n'est nécessaire du côté parser, P50X fournit toujours 0 .. 127 speed steps. L'octet de poids fort indique la direction.
    Résumé des commandes de fonction pour ORGANIZER
    init_organizer(void)
    organizer_ready(void)
    do_loco_speed_f(addr, speed, format)   Réglez la vitesse et le format d'une locomotive
    do_loco_speed(addr, speed)             Réglez la vitesse d'une locomotive
    do_loco_func_grp0(addr, funct)         fonction lumière
    do_loco_func_grp1(addr, funct)         fonctions f1-f4
    do_loco_func_grp2(addr, funct)         fonctions f5-f8
    do_loco_func_grp3(addr, funct)         fonctions f9-f12
    do_accessory(addr, output, activate)   commande aiguillage
    do_all_stop(void)                      commande STOP
    

RS232.C, Contrôle de l'interface série

    OpenDCC utilise l'interface série Ã&xnbsp; 19200 Baud (ce qui est aussi la valeur par défaut de Lenz V3.0). Ce débit peut être changé avec la commande Baud (0xF2). Les débits 38400, 57600 and 115200 Baud peuvent être utilisés. La valeur par défaut peut également être changée lors de la compilation. (init_rs232 call in main.c)

    Le format est toujours 8 bits, pas de parité et 1 bit d'arrêt (8n1).

    La communication est gérée par interruption et est tamponnée avec Fifos ( 64 octets). Cinq octets avant que le fifo ne soit rempli, les commandes PC sont arrêtées par handshake matériel.

    Si OpenDCC reçoit a BREAK (Ã&xnbsp; savoir Rx reste Ã&xnbsp; +12V, or '0' est reçu en permanence), alors l'UART est remise automatiquement Ã&xnbsp; la valeur par défaut de (19200 Baud). Voir aussi les commentaires dans ISR (SIG_UART_RECV).

MAIN.C, main program

    Il y a 4 routines d'interruption:
    • DCC compteur: Cette interruption déclenche la reprogrammation du compteur 1. Ainsi sont généré, les séquences pour DCC-0 et DCC-1 sur les sorties de comparaison de ce compteur.
    • chronomètre: Cette interruption contrôle les boutons poussoirs et les temporisations.
    • UART Rx: l'octet reçu est écrit dans le Fifo.
    • UART Tx: l'octet dans le Fifo envoyé est transmis.
    Ces 4 interruptions traitent les fonctions critiques en temps. Le traitement des instructions et le contrôle sont effectués par le programme principal, qui utilise un multitâche simple. Tous les modules sont appelés cycliquement. Les routines dans les modules doivent retourner au programme principal, même dans les cas où ils sont inactifs. Le programme principal possède la structure suivante:
    int main(void)
      {
    
        init_main();                       // all io's
        init_dccout();                     // chronomètre pour DCC
        init_organizer();                  // moteur pour la répétition des commandes,
                                           // mémoire des vitesses locos et format
        init_rs232();                      // isrs+fifos from/to pc
        init_interrupt();
        init_tick();                       // chronomètre 5ms 
        init_programmer();                 // dcc programmer
        init_parser();                     // analyseur de commande 
    
        set_opendcc_state(RUN_OFF);        // déconnecter (abgeschaltet)
    
        while(1)
         {
           run_state();                    // test les boutons poussoir et les court-circuits
           run_organizer();                // démarre l'exécution d'organizer
           run_parser();                   // test les commandes du PC
         }
      }

Documents / Liens


    Protocole et analyse du signal de la voie: avec ShowDCC et un petit adaptateur pour carte son: