OpenDCC GBM, Software

OpenDCC GBM16, détection de présence, détails du logiciel

Le processeur de voie (Track_proc) se réfère au potentiel de la voie, et évalue la consommation de courant ou les messages BiDi et envoie un résumé de l'évaluation au processeur de commande.
Le processeur de commande est référencé à la «terre» (soit à partir d'un PC ou par la masse du panneau de commande). Il reçoit des données du processeur de voie (Track_proc) réduit ces données suivant le protocole de rétroaction utilisé et les transmet via USB, XPressNet et / ou S88 à l'hôte ou à la station centrale.

Logiciel du processeur de voie

Récepteur DCC:
ici utilisé dans la routine des décodeurs. Et étendu aux fonctions suivantes:
- Retarde la lecture du signal DCC de 0.75 période (voir: Méthodes de réception DCC) on n'utilise pas les interruptions, qui activent une minuterie, mais on utilise le système d'événements des ATXmega.
- Détection automatique de la polarité et de la commutation de la polarité. C'est donc une synchronisation précise en phase du premier demi bit.
- Génération d'une impulsion de démarrage après chaque front du signal DCC. A cet effet un "événement" est généré à chaque changement de configuration des pins DCC. Cet événement réinitialise une minuterie. En fin de temporisation une conversion A/N est déclenchée par l'événement.
DCC unité de programmation:
Ceci permet le changement de variables internes du processeur de voie. Ceci est traité ici comme un décodeur d'accessoire. Par exemple, le SDA ou la sensibilité sont configurés de cette manière.
Système de mesure de courant:
En synchronisme avec l'entrée de DCC la mesure de tension est réalisée sur les entrées de voie. Cette mesure est 20μs pour chaque front, il y a toujours 8 canaux mesurés en parallèle. Cette collection complète est effectuée après quatre fronts du signal de DCC. Afin de stabiliser les valeurs de mesure des mesures individuelles sont pondérées par un filtre numérique, puis transférés à la surveillance d'affectation "monitoring assignment".
Ajustement de l'Offset du convertisseur
Comme tout convertisseur A / N, le convertisseur intégré du ATXMEGA128A1 est affligé d'un léger décalage (offset), ce décalage est composé de l'offset du capteur lui-même et du décalage de l'étage d'entrée. Pour l'ATXMEGA128A1 l'offset de l'étage d'entrée est très faible, avec le plus récent Atxmega128A1U l'étage d'entrée a également un offset d'environ 5 bits de poids faible et doit être inclus dans l'ajustement. Pour rendre la mesure aussi précise et sensible, un ajustement (semi-) automatique d'offset est fourni.
Il utilise la séquence suivante:
- S'il existe déjà des données d'offset valides - alors elles seront utilisées.
- Si les données n'existent pas, alors le GBM16T montre une "lumière courante" sur les voyants d'état (comme un message d'erreur) et également en debug IF indique que les données sont invalides.
- Maintenant l'utilisateur doit faire l'une des actions suivantes:
  - Débranchez tous les raccordements de voie ferrée ou désactiver DCC.
  - Appuyez sur le bouton de programmation.
  Un étalonnage de l'offset est effectué, si des données crédibles sont fournies, les données de correction sont stockées en permanence.
- Si cet ajustement d'offset ne donne aucune donnée utilisable, un clignotant de changement est affiché (changement deux LEDs par paires). Si vous appuyez une nouvelle fois sur le bouton de programmation, la GBM16T démarre malgré l'absence de données d'offset (avec un décalage = 0, des affectations fantômes pourrait en résulter). Vous pouvez ensuite travailler avec l'interface de débogage et changer par exemple le paramètre.
  La mesure de compensation est toujours mauvaise si les offset au sein d'un groupe de 8 diffèrent de plus de max_offset_delta LSB (CV37 =). Cette valeur est par défaut à 5.
- On peut déclencher un nouveau calibrage en insérant J0 ou mettant CV70 sur 0. Ensuite, lors du prochain démarrage une mesure d'offset est réalisée.
  Remarque: il est recommandé de vérifier le CV70 avant de le mettre à zéro: il devrait y avoir 0x55.
suivi d'occupation:
Groupe de tâches, qui filtre la consommation d'électricité et suit les changements et les transmet au processeur de commande et au contrôleur de LED. En même temps cette tâche de surveillance fixe quels canaux sont assignées à l'échantillonneur BiDi. En outre l'adresse du message DCC actuel est sélectionnée pour que le canal dans lequel la locomotive est actuellement, soit sûr d'être traité. Cela empêche la réponse du Channel2 puisque cette locomotive est immédiatement détectée.
La sélection du canal est faite selon les règles suivantes (modifié round robin):
1. Bien que l'ordre de DCC actuel soit un ordre de locomotive et un canal ait déjà reconnu cette locomotive, il est ajouté dans le choix. (C'est important pour des nouvelles de Ch2).
2. Des canaux dans lesquels une annonce d'adresses est seulement partiellement présente - de sorte que les adresses sont reconnues dès que possible complètement.
3. Canaux Fraîchement alloués, ce qui rend une mise à jour très rapide sur les redéfinitions.
4. Tous les autres canaux occupés
BiDi sampler: cette tâche enregistre le signal du capteur sur les sections de voie prédéterminée. 4 canaux sont enregistrées en parallèle pour chaque convertisseur, les besoins en mémoire sont de: 220 * 16 Bit * 8 canaux = 3520 Byte;
Récepteur BiDi: cette tâche reçoit les signaux des capteurs et utilise des méthodes de traitement du signal pour identifier la direction de la loco relative à la voie et décode les messages transmis. Le signal d'entrée mesurée est filtrée dans ce cas et ré-échantillonné. Puis, sur les données ainsi interpolées une analyse "de l'ouverture de l'œil" est effectuée pour interpoler les données, elle peut aussi reconnaître en toute sécurité les signaux perturbés.
BiDi analyseur: cette tâche analyse le contenu reçue par le protocole, l'évalue, et envoie de temps en temps un message vers le processeur de commande.
Command-IF:
Cette tâche fournit un pipeline au processeur de commande pour les messages générés et un analyseur pour les commandes du processeur de commande. Le protocole de communication décrit ci-dessous.
LED Controller:
Cette tâche indique les canaux inutilisés (éclairage statique) et ceux avec trafic BiDi (clignotement rapide). En outre, le contrôleur de LED prend le contrôle de la LED pour afficher les états généraux.
Debugger: peut-être accroché comme un enregistreur de données (data logger) à n'importe quel endroit qui communique via une interface USB opto-isolée.

Logiciel du processeur de contrôle (Control_proc)

Récepteur pour des nouvelles de voie : ici les messages des processeurs de voie sont reçus et analysés. Des changements de statut sont transmis aux modules amont ou sont actualisés dans la mémoire de statut.
Tâche de surveillance pour le Trackproc : la disponibilité des processeurs de voie est surveillée en permanence et au cas par cas, la réponse est gelée.
Interface client XPressNet: Le processeur de contrôle se connecte comme un participant XPressNet normal, et envoie ses messages à la station centrale là-bas (par exemple, occupé ou un message d'accusé de réception de commande).
Interface maître XPressNet: Processeur XPressNet agit comme maître et recueille les éléments de rétroaction des autres messages.
Interface de l'hôte: Processeur émule un protocole d'accueil comme BiDiB, HSI88 ou RC-link. Sinon une interface de débogage peut être téléchargée ici (lien manquant).
fonction S88-esclave: les affectations actuelles sont répertoriées sous forme de bits dans le flot S88 actuel.

La communication interne entre les processeurs

Les deux circuits (deux zones d'alimentation différentes) sont reliés par un opto-coupleur. Le transfert de données est effectué en RS232, caractérisé un opto-coupleur dans chaque direction. Le transfert se fait à 115200 bauds, 9N1.

Protocole de liaison montante

Liaison montante: entête (9e bit est activé)

7-5

Spécifie le type de message, les affectations suivantes s'appliquent: >

UPM_TYPE_SYSTEM

Message. La signification immédiate est codé via le QID et les octets suivants:

QID 0	Extension de protocole, le deuxième octet a une signification spéciale
QID 1	System-Power-Up
QID 2	Pong Active (réponse au ping, Heartbeat)
QID 3	Pong BiDi (réponse au ping, Heartbeat)
QID 4	Pong Inactive (réponse au ping, Heartbeat)
QID 5	Version Info, suivi de matériel, logiciel, protocole
QID 6	Detector ID base de l'adresse (DID base), suivi des bits poids faible DID, DID bit poids fort
QID 7	numéro du canal, suivi d'un octet indiquant le nombre de canaux pour ce processeur de voie
QID 8	Response à une demande SO, suivi de ADDRL, AddrH, Données
QID 9	Esclave en mode programmation
QID 10	Esclave en mode normal (default)

UPM_TYPE_CURRENT

en cours, un octet suivi de la valeur

UPM_TYPE_ADDR

ADDR: Adresse des messages nouvellement reçus suivi de 2 octets avec les poids faibles et forts AL, AH, n'est plus occupé quand AH et AL sont tous deux à zéro, puis l' IDentificateur de source.

UPM_TYPE_SPEED

Vitesse avec 3 octets: ADDRL, AddrH, Speed

UPM_TYPE_CV

CV: 5 octets suivent: LOK-AL, LOK-AH, CV-AL, CV-AH, DAT

Lok-Report: tbd.

reservé

4-0

Ceci est l'IDentificateur de source (QID): dans les messages normaux la source de l'entrée est notifiée. Plage 0 à 31, pour le matériel en cours (HW-ID = 1) la plage est seulement de 0 à 15.
Pour les messages système QID indique le type de messages (voir tableau ci-dessus).

Détails de la liaison montante

Message Type 0: System

message Type 0: System

Valeur

Signification de l' ID

reservé (extension de protocole)

UPM_SYSQID_POWER_UP
Ce message est envoyé chaque fois que le processeur de voie est démarré. Ceci peut être effectué en cours de fonctionnement, Le processeur de voie attaché à la tension voie peut être mis hors tension et dans ce cas le booster est coupé. Pas de données après ce message.

UPM_SYSQID_PONG_A
Ce message (ou ug UPM_SYSQID_PONG_ *) est envoyé en réponse à un ping. Ainsi, le Controlproc par PING détermine si le Trackproc est encore «en vie», et s'il est toujours sous tension. Une réponse PONG_A indique que le trackproc reçoit un signal DCC. PONG n'est pas nécessaire si les messages normaux sont transmis. Pas de données après ce message.

UPM_SYSQID_PONG_BIDI
Ce message (ou un autre UPM_SYSQID_PONG_ *) est envoyé en réponse à une commande ping. UPM_SYSQID_PONG_BIDI indique que le DCC GBM16T est fourni avec un signal qui contient le cut_out (suppression de signal pour BiDi. Pas de données après ce message.

UPM_SYSQID_PONG_I
(Voir UPM_SYSQID_PONG_A). Le message UPM_SYSQID_PONG_I (= inactif) est envoyé en réponse à une commande ping quand il n'y a aucun signal DCC. Pas de données après ce message.

UPM_SYSQID_VERSION
Ce message indique la version du Trackproc. 3 Octets:

HW	Matériel version, 1 ; z.Z. 1
SW	logiciel version, a number from 0 to 255
Protocol	Version level du protocole d'interface

UPM_SYSQID_DID
Ce message indique le détecteur d'occupation associé à une adresse de base. Il est suivi par 2 octets de l'adresse. (Octet de poids faible en premier).

UPM_SYSQID_CC
Ce message annonce le numéro du détecteur d'occupation associé à une adresse de base. Suivent deux octets avec le numéro. (Octet de poids faible en premier)

UPM_SYSQID_SO
This message is a reply to an SO query. The following are 3 bytes:

ADDR_L	Adresse low byte
ADDR_H	Adresse high byte
DAT	Data

UPM_SYSQID_PROG_ON
Ce message indique que le GBM16T est en mode de programmation. (Le mode de programmation est annulé pour des raisons de sécurité du GBM16T à chaque changement d'état, c'est à dire que GBM16T supprime le drapeau de programmation, si par exemple l'alimentation GBM16T alterne de DCC à DC. Dans ce cas, le mode de programmation est effectué à nouveau.

UPM_SYSQID_PROG_OFF
Ce message indique que le GBM16T n'est plus en mode de programmation.

Type de Message 1: message courant / occupé
Il est suivi par un octet:

Codage consommation
Valeur	Signification
0	aucune consommation d'énergie, la voie est libre.
1..100	Consommation de courant en mA. Plage possible: 1 .100 mA
101..200	Consommation d'énergie, la date de valeur - 100 * 10 mA. Plage possible: 10 mA .1000
201..250	Consommation d'énergie, la date de valeur - 200 * 100 mA. Plage possible: 100 .. 5000 mA
251..254	reservé
0xFF	Seulement un message Occupé, pas de consommation exacte connue.

Un message de type 2: message adresse
suivi par deux octets, ADDRL, ADDRH:
0: pas d'adresse détectée. 1..10239: adresse de locomotive.

Encodage du message d'adresse

Valeur Signification

0 pas d'adresse détectée

1..10239 adresse de locomotive, le MSB indique la direction relative à la voie.

Type de message 4: message CV
suivi par cinq octets ADDRL, ADDRH, CVL, CVH, DAT

Encodage du message CV
Valeur	Signification
ADDR	2 octets, les deux MSB spécifie le type d'adresse du décodeur "reporting": 00: loco, 10: Accessoire, 11: extension d'Accessoire
CV	2 octets, CV, range 0 .. 1023 (0 corresponds CV1)
DAT	Les données lues.

Type de message i: à déterminer.
En outre, des messages toujours à définir :
- signal de vitesse (confirmation de commande)
- signal de vitesse (vitesse réelle)
- Un message CV
- Une autre locomotive est entrée dans la section. Cela pourrait être intéressant pour des manœuvres automatiques.

Protocole descendant

Liaison descendante: header (9e bit est activé)
0	reservé
1	Ping
2	Demande Revision Info
3	Demande DID Base Adresse (DID = Detektor-ID)
4	Demande DID Base Adresse (DID = Detektor-ID); es folgend 2 Bytes: DIDL, DIDH
5	Demande nombre de canaux
6	envoie SO; suivi de 3 Octets: AddrL, AddrH, Dat
7	demande SO; suivi de 2 octets: AddrL, AddrH
8	Obtenez de nouveau les derniers messages d'occupation ;
9	Get last Current Messages again;
10	Obtenez de nouveau la dernière vitesse;
11	Obtenez de nouveau la dernière adresse;

Interface de débogage - Trackproc

COM virtuel

Firmware-Update

instructions de la souris

xboot

Interface de configuration

En fonctionnement normal, une interface de commande (API) est mise en œuvre sur le port USB auquel vous pouvez envoyer des commandes au décodeur. A cet effet, un émulateur de terminal comme hterm.exe peut être utilisé.

L'API travaille avec un protocole série à 115200 bauds, 8 bits, pas de parité, 1 bit d'arrêt (8N1). l'API transmet 8-bit ASCII, qui ne diffère pas de commandes et sont sensibles à la casse. Les commandes envoyées sont terminées par <cr> ou <CR-LF>, la réponse contient <CR-LF> comme un marqueur de fin. A commande inconnue est répondu avec "commande inconnue".

Commandes API commune

Help
Paramètres: Aucun
Réponse: un texte d'aide qui décrit brièvement les commandes de l'API.

Info
Paramètres: Aucun
Réponse: "OpenDCC_BiDiGBM hw 1.0, sw 02, 01 api" (exemple)
La réponse se compose d'une chaîne, en commençant par l'identifiant matériel ("OpenDCC_BiDiGBM) et les numéros de version., Suivi des mots clés, chacun suivi d'une valeur numérique..

hw	Version du matériel
sw	Version du logiciel
api	C'est le numéro de version de l'analyseur basé sur ce numéro on peut définir quel jeu d'instructions est pris en charge.

CV ADDR [DATA]
Paramètres:

ADDR Adresse CV pour être lu ou écrit.

DATA écriture si ce paramètre est spécifié, sinon lecture.

Réponse: CV1234: 56 (= l'adresse 0x1234 contenu 0x56, la réponse est toujours la même longueur)
REBOOT
Paramètres: Aucun
Réponse: non
Le décodeur effectue une réinitialisation (par exemple nécessaire après le changement des modes de CVs)

Commandes pour le log ("trace")

L
Il indique l'état actuel.
Réponse: séquence de lettres, chacune suivie par + ou -.
Exemple: logging: A+ B1+ B2+ C- S+ T+ U+

Nom	Log activé
A	messages d'adresses
B1	BiDi, Ch1
B2	BiDi, Ch2
C	Messages CV
S	Messages vitesse
T	Message occupé (busy)
U	Messages BiDi inconnu

LA [0|1]
LA 1: Affiche toutes les adresses des messages entrants.
LA 0: l'affichage de notifications d'adresses est hors service.
Réponse: statut (en L)
LB [0|1|2|3]
LB 0: affichage des messages BiDi est hors service.
LB 1: Tous les messages BiDi entrants dans Ch1 affiché.
LB 2: Tous les messages BiDi entrants dans Ch2 affiché.
LB 3: Tous les messages entrants dans BiDi CH1 et CH2 affichés.
Réponse: statut (en L)
LC [0|1]
LC 1: CV permet d'afficher tous les messages entrants.
LC 0: affichage des messages CV est éteint.
Réponse: statut (en L)
LT [0|1] Montre l'occupation des voies
Réponse: statut (en L)

Commandes de test et de simulation

SA TRACK ADDR
l'apparition d'un message BiDi (message d'adresse) est simulée en interne trackproc.
Paramètre:

TRACK	Détecteur de présence, auquel doit être affectée à ce message.
ADDR	Le détecteur d'occupation sur cette adresse.

Réponse ok

ST TRACK
l'apparition d'un message d'occupation est simulé dans trackproc .
Paramètre:

TRACK Détecteur de présence, son activation est simulé.

Réponse: ok
M
Lire les valeurs actuelles (pour les deux polarités) pour tous les canaux.
Paramètres: Aucun Réponse: suit des paires de nombres, à partir de la piste 0
LW <TRACK>
La valeur de "TRACK" est reconnu comme canal de communication particulièrement suivi. Ce canal est alors présent à chaque évaluation. Si la valeur est 16, l'observation est éteinte. Si aucun paramètre n'est spécifié, le réglage actuel est affiché.
avant de déclencher un dump des données reçues, le canal de message doit d'abord être défini.
Réponse: <numéro> surveillé
DD
Dump de données: avec cette commande le canal d'enregistrement sauvegardé par la condition de trigger est donné complétement : Ch1, CH2 ainsi que le contenu enregistré dans la forme d'onde du canal de message.
Réponse: plusieurs champs avec des valeurs numériques.
DTC <data>
Si aucun paramètre n'est spécifié, DTC est éteint. Sinon résulte un Dump du canal de signalisation, si le CV lu a le contenu <data>. Le dump peut alors être lu avec DD. Réponse: état actuel de la DTC

XER ADDR
Lecture de l'adresse de l'EEPROM (par exemple XER 0x34)
XEW ADDR DATA
Écrivez à l'adresse EEPROM (par exemple XEW 0x34 0x45)

Intégration de OpenDCC BiDi-GBM

L'affectation d'adresses des sections de message

S88
L'attribution d'adresses pour le protocle S88 est tout simplement par la position physique dans la chaîne de répéteur, il n'y a pas d'ajustement nécessaire.
Xpressnet
Chaque voie fournit à son processeur, le processeur de contrôle (DID détecteur ID), donc l'adresse de base désirée. Le processeur de commande trie désormais les messages entrants du processeur de cette voie en fonction de l'espace d'adressage du module de rétroaction.
Interface de l'hôte
Ici, diverses émulations de protocoles sont possibles:
- BiDiB: Les messages des processeurs de voie sont présentés selon l'ordre des processeurs en tant que détecteurs de voie 0-15, 16-31, 32-47 et 48-63 sur ce nœud. Bits de message facultatifs sont 8 pour panne booster en aval.
- HSI88: Les messages des processeurs de voie sont triés en fonction du DID.
- RCTalk: Seul le processeur voie 0 est triée comme RCTalk 1..16. Les autres processeurs de piste ne sont pas évaluables.

Participation de la centrale

un DID (ID du détecteur): Sur quelle section occupée cette locomotive s'est inscrite la dernière fois.
Quelle vitesse a-t-elle annoncée?
Un drapeau, si le dernier changement a déjà été annoncé au PC
Un drapeau, si la locomotive est prise en compte dans le Refresh

Que se passe-t-il quand la locomotive est enlevée de manière dynamique à partir de LocoBuffer?

Extension du protocole P50X

P50X est étendue comme suit:

Cela correspond à l'ancien mode de programmation, mais court le risque que si PoM est demandé simultanément sur PC et la souris, le contenu des données correctes ne puisse pas être mis en œuvre.

XEvtBiDi (0xD2)

     1. Byte 1:
                        bit#   7     6     5     4     3     2     1     0
                        +-----+-----+-----+-----+-----+-----+-----+-----+
                        | LE  | res | res | res | D11 | D10 | D9  | D8  |
                        +-----+-----+-----+-----+-----+-----+-----+-----+
            LE:      0: fin de la liste, suivie d'aucunes données.
                     1: Les données suivantes pour cette entrée de liste.

            res:     réservé
            D11-D8:  DID (DID = Detektor-ID), high nibble; Il y a au maximum 2047 DID, si l'annonce du DID global vient, DID = 0xFFF = est en 2047.
     Byte 2:
            D7-D0:   Detektor-ID, Low Byte
     Byte 3: low byte of Lok# (A7..A0)
     Byte 4: high byte of Lok#, plus Dir and Speed status, coded as follows:
                    bit#   7     6     5     4     3     2     1     0
                        +-----+-----+-----+-----+-----+-----+-----+-----+
                        | Dir | Spd | A13 | A12 | A11 | A10 | A9  | A8  |
                        +-----+-----+-----+-----+-----+-----+-----+-----+
           Dir:     Orientation loco relative à la voie 
           SPD: 1: il est suivi par un autre octet avec la vitesse réelle
        Si l'adresse de locomotive transmis est 0, alors le train a quitté ce détecteur (et n'est pas apparu dans un
         autre détecteur.) et le détecteur est libre.
         (Note: affectation est affiché sur le tableau S88)
     Byte 5. 
         Vitesse en fonction du codage BiDi
                  0..63:    speed = valeur / 2;
                  64..127:  speed = valeur - 32;
                  128..254: speed = valeur * 4;
                  255:      Indique un réglage de la vitesse nulle (entre autres choses est utilisé en interne). 
                  Un maximun de 10 locos sont rapportés par XEvtBiDi.
 
  

  

  XBiDiQuery (0xD3) longueur = 1+2 Byte
  

    Parameter:  DID-low DID-high

  Réponse: L'information de BiDi complète, jusqu'à la vitesse est envoyée, seulement pour cette annonce complète.
  

  

  XBiDiSet (0xD4) longueur = 1+1 Byte
  

    Parameter:
                    bit#   7     6     5     4     3     2     1     0
                        +-----+-----+-----+-----+-----+-----+-----+-----+
                        | res | res | res | res | res | res | Spd | Loc |
                        +-----+-----+-----+-----+-----+-----+-----+-----+
            Loc:     1: Toutes les attributions des locomotives à un DID sont effacées.
            Spd:     1: Toutes les vitesses réelles sont supprimées.
            res:     réservé

Controlproc - Interface hôte

BiDiB

port COM virtuel

Firmware-Update

instructions de la souris

Interface de configuration, USB

En fonctionnement normal, une interface de commande (API) est mis en œuvre sur le port USB auquel vous pouvez envoyer des commandes au décodeur. A cet effet, un émulateur de terminal comme hterm.exe peut être utilisé.

Commande API

Aide
Paramètres: Aucun
Réponse: un texte d'aide qui décrit brièvement les commandes de l'API.

Info
Paramètres: Aucun
Réponse: "OpenDCC_BiDiGBM hw 1.0, sw 02, 01 api" (exemple)
La réponse se compose d'une chaîne, en commençant par l'identifiant matériel ("OpenDCC_BiDiGBM) et les numéros de version. Suivi des mots clés, chacun suivi d'une valeur numérique.

hw	Version du matériel
sw	Version du logiciel
api	C'est le numéro de version de l'analyseur de commande basé sur ce numéro on peut définir quel jeu d'instructions est pris en charge.

EB
Paramètres: Aucun
Réponse: Maintenant, BiDiB en cours d'exécution
Le GBM bascule du mode debug en émulation BiDi, ce basculement est permanent.
EH
Paramètres: Aucun
Réponse: HSI88 Emulation en cours d'exécution
GBM commute de DebugMode en émulation HSI88, cette commutation est permanente. Le mode HSI88 peut être quittée avec la commande 'X' (en majuscules). Attention: actuellement la vitesse de transmission ne change pas lorsque vous passez en mode HSI88, la liaison est à 115200 bauds.
ER
Paramètres: Aucun
Réponse: RCTalk Emulation en cours d'exécution
GBM commute de DebugMode into en émulation RCTalk, cette commutation est permanente. Le mode RCTalk peut être quitté avec la commande '0 x22 '(hex). la vitesse de transmission est inchangée. Le protocole RCTalk a une plage d'adresses et des fonctionnalités assez limités, il est donc seulement utile pour un premier essai. Seul le GBM16T [0] est en outre "reporté" dans RCTalk, pour un deuxième GBM16T il n'y a pas assez de la plage d'adresses. Busy messages ne sont pas non rapporté.
REBOOT
Paramètres: Aucun
Réponse aucune
Le décodeur effectue une réinitialisation (par exemple nécessaire après le changement des modes de CVs)

XER ADDR
Lecture de l'adresse de l'EEPROM (par exemple XER 0x34)
XEW ADDR DATA
Écrivez à l'adresse EEPROM (par exemple XEW 0x34 0x45)

Variables de configuration internes au GBM16C

CV	signification
1	parser_mode 0: Debug-Interface 1: HSI88-Emulation 2: p50x (non implémenté) 3: RC-Talk 1 (pour GBM16T [0])
2	VID Vendor ID (13)
3	Product ID, low byte (101)
4	Product ID, high byte (1)
5	Le numéro de série, low byte (1)
6	Le numéro de série, high byte (0)
7	cavalier
8	s88_extended Octet supplémentaire pour booster s88 en panne
9	s88_extended_did_l Detector-ID low pour cet extra octet s88.
10	s88_extended_did_h Detector-ID high fpour cet extra octet s88.
11	xp_slot_mode automatic ou manuel
12	xp_slot_addr Adresse 1..31
13	xp_use_occupancy messages occupé sont envoyés sur XP
14	xp_use_location notifications d'adresses sont envoyés à XP
15	xp_use_speed messages de vitesse sont envoyés sur XP

Commandes à HSI88

HSI88

Littfinksi (LDT)

LDT is the mode with terminal mode

v <cr>
Réponse: Ver. 0.01 / 14.10.10 / HSI-88 / OpenDCC <cr>
Demande de version de la «chaîne de base» HSI-88 peut modifier toutes les composantes de la chaîne, ainsi que la longueur.
t <cr>
réponse: t[MODE]<cr>
Commutation du mode de fonctionnement (mode terminal). Le mode change dans chaque commande, par défaut après le démarrage l'émulation est binaire. MODE = '0 'signifie binaire, MODE = '1' signifie ascii.
s [gauche] [center] [droite]<cr>
Réponse (Partie 1): s [SIZE] <cr>
Cette commande affiche la taille jusqu'à la 'chaîne principale' des chaînes partielles respectives (dans des modules à 16 bits). Pour l'OpenDCC GBM, la répartition dans des chaînes partielles est sans intérêt, on ne considère que la somme de GAUCHE, MILIEU et DROITE, cette somme est rapportée dans la réponse en tant que SIZE.
Selon le mode, à la fois le transfert des paramètres et la réponse sont en binaire ou en ASCII.
La deuxième partie de la réponse fait suite à un message initial (voir ci-dessous), tous les modules sont signalés.
Cette commande est exécutée une fois au départ, alors seulement on peut émettre des rapports initiaux des rétroactions modifiés.

m <cr>
Réponse: chaîne d'octets avec la structure suivante:
m[SIZE][[MODUL][DATA_HIGH][DATA_LOW]<cr>

SIZE	Nombre de modules qui sont signalés.
MODUL	Numéro du module. Un module comprend 16 bits de rétroaction.
DATA_HIGH	les 8 bits "haut" de ce module (The upper 8 )
DATA_LOW	les 8 bits "bas" de ce module (The lower 8)

Avec la commande m tous les modules de rétroaction connectés sont interrogés. Selon le mode, la longueur de la réponse est différente: binaire: 3 + 3 * TAILLE, ascii: 4 + * TAILLE 6

X <cr>
Réponse: X <cr>
X (en capitale) termine l'émulation HSI88 et retourne à l'interface de configuration. Cette Commande n'est pas disponible sur l'original HSI88.

Annonce initiale
Séquence d'octets ayant la structure suivante:
i[SIZE][[MODUL][DATA_HIGH][DATA_LOW]<cr>

SIZE	Nombre de modules qui sont signalés.
MODUL	Numéro du module. Un module comprend 16 bits de rétroaction.
DATA_HIGH	les 8 bits "haut" de ce module (The upper 8 )
DATA_LOW	les 8 bits "bas" de ce module (The lower 8)

Ces messages initiaux sont envoyés spontanément et seulement par les modules de rétroaction qui ont changé. Selon le mode, la longueur de la réponse est différente: binaire: 3 + 3 * TAILLE, ascii: 4 + * TAILLE 6

Encodage du message d'adresse
Valeur	Signification
0	pas d'adresse détectée
1..10239	adresse de locomotive, le MSB indique la direction relative à la voie.

ADDR	Adresse CV pour être lu ou écrit.
DATA	écriture si ce paramètre est spécifié, sinon lecture.