OpenDCC

• Bibliothèque numérique
• protocole DCC
• exemples DCC
• DCC et CVs
• Info Railcom
• Fct.Décodeur Railcom f.
• Railcom: test des décodeurs
• schémas Railcom
• DCC auto-logon
• Description de Bus
• BiDiB
• Xpressnet
• XBEE
• sans fil: protocole ferroviaire
• info CAN
• brochage CAN
• S88-N
• Modélisme ferroviaire
• câblage d'un réseau
• Brochage Décodeur
• Données Décodeur
• Train Programmer
• Conseils pour Traincontroller
• Moteur Faller
• Roco multiMaus®
• Charlieplexing
• General
• Notes sur le codage AVR
• Notes sur les spécificités Xmega
• Noyau temps réel AVR
• Eagle Library Parts
• Soudure manuelle des QFN
• Carte SD et AVR
• Servo réduction des à-coups
• RC5 Code
• Marquage des résistances
• nuancier RAL

DCC-BiDi (RailCom ®)

Motivation

Lorsque la commande numérique a été introduite dans les années 80, les capacités des télécommandes et la simplification du câblage n'étaient pas une préoccupation majeure. Sur la base des technologies plus anciennes des protocoles unidirectionnels (par exemple, MM, CDC) ont été développés qui peuvent transmettre simultanément sur deux fils l'information et l'énergie. Avec la diffusion croissante de la technologie, le désir de communication bi-directionnelle est apparu. Mais le développement a été rendu difficile du fait des exigences de compatibilité et des contraintes physiques: la communication vers le décodeur est une application de diffusion avec une structure hiérarchique claire, tandis que la voie retour, nécessite arbitrage et allocation du bus, comme il est requis dans les réseaux.
Parmi les différentes propositions, la proposition de Lenz a prévalu, elle a été normalisée par la NMRA RP 9.3.1 de l'année 2007. La technique peut être utilisée sans licence pour un usage personnel et non commercial.

Avantages

• Une meilleure utilisation de la bande passante sur la voie: du fait que les commandes soient acquittées, les spécifications ne doivent plus prévoir de répétitions.
• Ouverture automatique à la station centrale d'une session pour une locomotive - par le biais de la lecture d'une image de cette locomotive. appelé Plug & play en langage moderne.
• La lecture des attributs d'une locomotive, par exemple si et quelles fonctions spéciales sont disponibles.
• La modification des paramètres d'une locomotive, tels que caractéristique vitesse.
• Possibilité de transfert de paramètre supplémentaire (référence et la vitesse réelle, l'état des fonctions, itinéraire, etc).
• Transmission des erreurs. Par exemple, le décodeur peut contrôler la consommation de puissance du moteur et indiquer, à une certaine valeur de seuil, que la maintenance est nécessaire.
• Simulation des procédures d'exploitation, tels que le charbon et la consommation d'eau.
• La locomotive peut rapporter un rapport de situation sur la voie, combien de fois, par exemple, il ya eu des coupures de courant à court terme en raison de voies sales.
• Avec la possibilité que le détecteu de retour peut peut détecter si et quelle locomotive est dans son domaine, de là résultent de nouvelles possibilités de conduite :
  • Un détecteu de retour peut manquer une locomotive HP0 ou HP2: si la locomotive est dans son domaine, un message de bus correspondant est généré.
  • La locomotive (par exemple après réenraillement) peut être indiquée à un contrôle de PC automatisé.

Comment fonctionne Bidi (RailCom ®)?

La transmission de données entre la station centrael et le décodeur n'est plus effectuée de façon continue, un multiplexage par répartition dans le temps a été introduit, en créant des créneaux temporels pour la transmission vers le décodeur, et des créneaux pour la voie retour. L'intervalle de temps pour la voie de retour (= découpe représentée en gris ci-dessus) a été défini comme suit
• La pause pour transmission du décodeur est d'au moins 448μs ou 4 bits logique 1 (= 464μs). Le signal de la station centrale est coupé 29μs (+ /-3μs) après l'envoi du bit de fin d'un message DCC , puis sur on à nouveau 16μs avant la fin. Ce temps de fonctionnement on/off permet au décodeur de détecter les fronts du signal DCC.
• Durant la pause de transmission un décodeur peut émettre l'information de retour. La transmission de retour est effectuée en série, octet par octet. Ceux-ci sont codés en RS232, paramètres de transmission 250kBaud, 8 bits, 1 bit d'arrêt. A 250 kBaud un bit dure 4μs, et un octet 40μs y compris le bit de départ (= 0) et les bits d'arrêt (= 1).
  Deux canaux (successifs en temps) sont définis:
  1. Canal 1: La transmission a lieu dans une fenêtre de temps qui commence 80μs - 95μs après la fin des dernières données de la station centrale et comprend 2 octets, elle dure 80μs. Ce canal est destiné aux rapports ad hoc, afin de rendre compte d'événements, que la station centrale ne connaît pas encore.
  2. Canal 2: La transmission a lieu dans une fenêtre de temps qui commence 190μs - 208μs après la fin des dernières données de la station centrale et comprend 6 octets, donc elle dure 240μs. Logiquement ces 6 octets sont à nouveau divisés en trois paires. Ce canal est prévu pour recevoir les informations provenant de chaque décodeur adressé.

La réalisation physique

Dans la voie retour on rencontre les difficultés suivantes:
• Un décodeur mobile n'a normalement aucune source d'énergie propre, le retour doit être généré grâce à l'énergie sauvegardée en interne.
• Il peut de temps en temps exister beaucoup d'équipements consommateurs de courants qui chargent la voie lors des retour. Heureusement, les consommateurs sont habituellement séparés par des diodes, de sorte que, à un niveau de tension inférieur, aucun courant ne circule (puisque derrière la diode les condensateurs sont encore chargés) et d'autre part le courant ne circule qu' après une certaine tension minimum. Ainsi, des problèmes apparaissent principalement par les consommateurs résistifs, comme par exemple des éclairages de train et les axes de roues. La chute de tension admissible est limitée à 200mV pour un détecteur (à un courant de 34 milliampères).
• Des tensions de rechange, tels que celles utilisées par certains détecteurs d'occupation pour maintenir les évaluations de DCC en cas d'échec peuvent également interférer avec la transmission retour.

La mise en œuvre suivante a été normalisé:
Pour activer le transfert la station centrale (ou le Booster) court-circuite la sortie et le décodeur envoie un courant dans la boucle ainsi créée. Ce courant est d'au moins 30 mA pour une chute de tension au maximum de 2,2 V. Un courant de 30 mA (+4 mA -6 mA) signifie 0, pas de courant (<0,1 mA ) signifie logique 1; La durée d'un bit est 4μs (= 250kBaud), les temps de montée et de descente sont définis, chacun de 0,5µs. Le seuil du détecteur est de 8 mA pour une tension de 2 mV. Le déchet de tension prend en considération les détecteurs de courant avant tout éventuellement insérés et les modules d'alphabet avec des diodes.

Ce courant est détecté par un capteur, le capteur convertit le signal de retour en signal RS232, qui est ensuite évaluée par la station de commande.
Selon NMRA les fréquences d'horloge peuvent varier de + / - 2%. Je pense que cela est risqué: Si des émetteurs et récepteurs sont aux limites opposées de la tolérance, un Offset au maximum de la prise d'échantillon de 8*4% = 32% ( sur un octete = 8 bits) en résulte. Typiquement si on commence au milieu du bit de départ, alors vers la fin de l'octet, on s'approche dangereusement du bord du bit, et vous devez aussi prendre en compte dans le calcul les temps de montée et de descente du matériel.

Compatibilité:

Quel est à ce jour le niveau de compatibilité de RailCom® avec les décodeurs et les stations centrales?
• Dans le protocole, le préambule suivant la coupure est réduit de près de 4 un; jusqu'à maintenant, la longueur minimale était de 10 un, les centrales étaient incitées à envoyer 14 un. Le protocol n'est pas violé par la création de cet interval de temps. Cependant, il ya des stations centrales et des décodeurs, qui n'ont pas tout à fait respecté les spécifications. En outre, certains décodeurs ont besoin d'un Etat prédécesseur stable, pour la détection précise du bit suivant. C'est pourquoi je pense qu'il est préférable de définir le nombre de bits '1' à au moins 15. Il peut aussi y avoir des problèmes dans la détection du bit de fin lorsque l'intervalle de suppression est juste après le dernier bit - permet parfois l'inversion de polarité de la connexion DCC.
• La compatibilité est plus difficile en ce qui concerne le budget d'énergie du décodeur - Il doit être capable de fournir l'énergie durant la coupure, et une coupure de 400μs , en supposant un courant moteur de 500mA et un condensateur de 47uF provoque une chute de tension juste sous 5V. Ceci peut provoquer pour des décodeurs dimensionné trop juste des erreurs du processeur dues à cette chute de tension.
• Le pic de consommation d'énergie du décodeur après l'intervalle de suppression peut parfois causer des problèmes (pour les booster, qui ont une détection de court-circuit extrêmement rapide).
• Comme présenté ci-dessus, les consommateurs ohmique sur la voie peuvent présenter une trop petite Impedance pour le courant de retour. Si et comment celle-ci est importante, dépend de la charge et des diodes dans les modules de détecteur. En général on recommande de séparer de tels consommateurs par des diodes.
• RailCom ® peut avoir des difficultés avec des modules de rétroaction déjà installés. Selon le type de circuit et le type de diodes intégrées ces modules de rétroaction peuvent agir comme une barrière pour les signaux RailCom. Même si le module répéteur (comme pour les optocoupleurs dans le câble de voie) fonctionne avec deux diodes en série, les autres consommateurs peuvent être pré-conducteur, avant de créer un courant à travers le court-circuit du booster. Il est Important d'avoir une petite chute de tension dans le module de contre-réaction comme ici .
• RailCom® nécessite des locomotives correctement câblées. Quand une lumière n'est pas reliée au décodeur-Plus (prise bleu), mais connectée sur le châssis, la transmission ne fonctionne qu'à moitié: dans un sens de mise sur la voie RailCom® fonctionne, il ne fonctionne pas dans l'autre sens.

Codage

Pour sécuriser la transmission de données contre les collisions et les erreurs de transmission, le codage de redondance est exécutée. Dans ce cas des données sont ajoutées au message utile. En conséquence moins de données utiles peuvent être transmise avec le même datagramme.
La NMRA RP 9.3.2 propose un encodage 4/8, qui mappe 6 bits utiles sur 8 bits de transfer. 4/8 signifie qu'à 8 bits transmis les codes sont choisis pour que toujours exactement 4 bits soient dans l'état '1' (le poids d'Hamming = 4). 8 bits signifie 256 états possibles, dont (8! / 4! / 4!) = 70 états ont un poids de Hamming de 4. 64 codes sont utilisés pour le codage 6 bits utiles, les 6 codes possibles restants sont utilisés pour le marquage des messages spéciaux (que l'on appelle les datagrammes d'acquittement).

Inconvénients, les problèmes potentiels

• Selon l'auteur (Wolfgang Kufer) le comportement du protocol dans le canal 1 (une locomotive crie tout simplement parce que sa propre adresse est sortie) pour cette partie de trajet, est tel que sur un système plus vaste, vous n'aurez aucun recours pour ce comportement.
  S'il ya plusieurs véhicules dans une section électrique (par exemple double traction) aucune transmission de données valable n'est obtenue dans le canal 1.
• En cas d'utilisation mixte de boosters avec BiDi et sans BiDi, il en résulte un court-circuit, lorsque ces boosters sont reliés par un véhicule lors de la découpe. Donc, vous avez à changer complètement le système.
• Il manque encore un Timing plus exact pour la découpe, si plusieurs Booster sont installés. Si la sortie de deux Booster est connectée (par exemple par une locomotive sur le lieu de séparation), cela peut être qu'un Booster produit encore le signal pendant que le voisin fait déjà la découpe. Là alors deux drivers pourraient s'opposer l'un à l'autre. Donc la Spécification doit encore être complétée d' un court temps mort dans lequel chaque Booster décroche, c.-à-d. un court temps mort doit précéder ou suivre la pause.
  
  
  Proposition de l'intervalle de garde pour éviter les courts-circuits.
  
  
• Observations précédentes, certains booster sont déjà souples sur la recommandation de 26μs/30μs (apparemment en raison de problèmes de compatibilité avec les décodeurs) et commencent le court-circuit par exemple jusqu'à 38μs après le bit de fin.
• Le contenu des réponses n'était pas standardisé jusqu'aux choses rudimentaires comme l'adresse et l'acquittement CV, il y a également, lié à la phase de début de Railcom® des décodeurs qui diffusent des paquets 'inhabituels'. Egalement le début du canal 2 a été négligé jusqu'au point que certains décodeurs ne respectaient pas la séparation de canal. Suite à l'implication de plusieurs utilisateurs d'OpenDDC il a été créé une liste des possibilités de chaque locodecoder RailCom® liste des possibilités de chaque locodecoder RailCom®.

La suite du traitement

Le traitement ultérieur de données bidirectionnels est également intéressant. D'une part, ils doivent être communiqués à la station centrale pour que celle-ci optimise son suivi de voie et reçoive par exemple aussi la réponse à la programmation. D'autre part, ils sont aussi importants pour le PC de contrôle: l'attribution d'où se trouve quel quel décodeur (la reconnaissance de train) et aussi la vitesse ou la position actuelle de ce décodeur est importante.

Railcom est la réponse et une composante essentielle de la rétroaction est la localisation. Au début du développement de railcom, dans la discussion il y avait des idées pour extendre les informations de rétroaction disponibles. Des limites furent cependant trouvées très vite par rapport à la à la bande passante et à structure d'ordre logique. Des anciens systèmes de reconnaissance de train sont fortement liés à leur matériel respectif.
• Emulation modules transpondeurs:
  L'inconvénient des émulations est la limitation du nombre de commandes - Ni la vitesse ni la direction ne sont prévues par TD88 ou Inter-10 (l'un et l'autre par Littfinski). Ils devraient être élargi au cas par cas qui compliquerait de nouveau l'intégration de logiciel sur le serveur.
• Loconet:
  Avec un débit de transmission de l'ordre de 10kBaud , on peut transporter, certes, les reconnaissances de locomotive séparées, mais pour une plus grande installation avec plus d'agents de transmission et des annonces de vitesse pour beaucoup de véhicules la bande passante est insuffisante.


Des nouvelles approches sont donc nécessaires:
• RC-Talk de Tams Elektronik est une approche relativement simple pour connecter quelques détecteurs au PC, une liaison avec la centrale n'est pas prévue. Cela transmettra l'adresse, CV et occupation en série à 19200 bauds.
• ECOS-Link utilise un bus CAN à 250kBaud et fournit ainsi plus de bande passante. Cependant, CAN est intrinsèquement un système producteur-consommateur, une sauvegarde du rapport d'occupation n'est pas fourni.
• BiDiB, est une approche maître-esclave, qui met particulièrement l'accent sur la facilité d'installation et la sécurité maximale. Il transmettra l'adresse, CV, vitesse et occupation avec une fiabilité garantie.

En 2011 Lenz et ESU ont présenté une extension pour la connexion automatique d'une locomotive (Railcom plus), qui assure un transfert automatique des données stockées dans les paramètres du décodeur pour le nom, symboles de fonction et symbole de train. Il est à espérer que cette extension soit uniformément standardisée et divulguée. En lien avec la rétroaction il y a alors possibilité d'étendre le protocole DCC: la station de commande et la locomotive peuvent s'entendre sur un jeu d'instructions élargi, ou même sur une autre transmission de données, et utiliser le DCC existant seulement comme le tremplin et l'alimentation en courant. Sont envisageables par exemple de courts paquets OFDM intercalés.

Situation juridique

La transmission retour en mode semi-duplex a été enregistrée par un brevet Lenz qui a été accordé. Jusqu'à 2011, la situation était difficile : BiDi était licencié par Lenz au NMRA, aux sociétés intéressées et se trouve décrit dans un document NMRA, on peut l'utiliser en licence gratuite, si un examen de compatibilité a été passé avec succès. Pour obtenir des renseignements la NMRA souligne qu'ils ne peuvent pas le faire et que vous devez contacter Lenz.
Ce genre de renvoi, a aussi déjà réussi pour RAMBUS au JEDEC. Mais ce qui ne m'est pas tout à fait clair : quel contrôleur de brevet donne donc en 2000 un brevet sur le semi-duplex(l'half-duplex) ? C'est ce que l'ingénieur de communication, a déjà fait dans les années 50 ...

En outre, j'ai aussi trouvé des publications des années 80 et 90, où exactement est décrit le procédé du brevet de Railcom : un modèle réduit de train est piloté par un signal numérique à 2 fils, après une transmission de données le signal numérique est mis à zéro, dans l'intervalle (à Railcom, celui-ci s'appelle coupe-circuit) résulte une transmission de retour au moyen d'une source de courant pulsée, qui est alimentée par une mémoire d'énergie chargée d'avance. Si on compare avec le brevet railcom, le même état des choses est décrit exactement, seuls le nombre de bits transmis en retour et l'intensité du courant diffèrent.
Donc le procédé déclaré au brevet pour la date de l'enregistrement était déjà «de statut reconnu» de la technologie, le brevet n'aurait pas du tout pu être donné.

Dans le cadre du réalignement des normes européennes DCC et de la politique d'octroi de licences à partir de 2010, Railcom a été homologué ouvert, et parmi les projets OpenDCC a reçu une licence. Cette licence a pour objectif principal de garantir la compatibilité des composants RailCom les uns avec les autres et prévoit pour les créateurs de modules certaines obligations qui sont rspectées par les voisins postpaysans openDCC projects.
Dans ce qui suit, je résume briévement ces conditions :
• Les produits qui utilisent la technique décrite dans les brevets doivent être marqués avec la marque «RailCom". A la mention de la marque est (comme d'habitude) indiqué le propriétaire (dans ce cas Lenz Elektronik GmbH).
• Les produits doivent être «compatibles», c'est à dire adhérer aux spécifications publiées.
• Pour les problèmes de compatibilité, il y a un processus d'arbitrage réglementaire entre les fabricants participants (y compris les groupes de travail dont l'appui est possible), pour résoudre le problème. Dans OpenDCC Je demande donc que le premier problème à résoudre soit publié sur le forum, je ferai de mon mieux pour trouver une solution.
• Les projets OpenDCC peuvent utiliser la technique décrite dans les brevets. Les ensembles finis qui utilisent cette technique ne peuvent être vendus à des tiers (soi-disant activité OEM). Cela signifie que la personne qui met des modules sur le marché , doit elle-même avoir une licence.

Liens

RC-Talk Booster (railcomfähig)
Detektor für BiDi