Incidence du debit sur le bus DCC pour les accessoires

DiCoS69 a écrit:

Ce cas n'étant pas une généralité, je ne vois pas pourquoi le décodeur doit attendre une triple commande pour envoyer le changement d'état... si l'ordre est clair, il le passe, s'il ne l'est pas, il s'abstient, et si, comme tu le dis, il y a répétition, il passera l'ordre au coup suivant...
Si l'objectif est d'éviter d'éventuels "bagodements", le problème est plutôt dans le paramétrage des déclencheurs.

De quelle commande "délai" dans TC parles-tu ?

Le décodeur doit attendre une triple commande car erreur de conception qui empêche un bon fonctionnement sauf avec une Z21 dédiée à la signalisation.
algorithme utilisé:

" />

cela coince avec un trafic fort sur le bus DCC.

Un algorithme du type:

" />

permettant une action immédiate dans le décodeur devrait résoudre le problème , il correspond à priori à celui utilisé par le décodeur LS DEC SNCF de LDT.

Il permet une sélection par bloc dans la configuration suivante:

" />

Il faut envoyer AD+2 en premier, cela est parfaitement possible avec les accessoires étendus de TC, cela permet de sélectionner le bloc concerné.

Pour le délai c'est le temps de cette fenêtre:

" />

Claude

salut Claude,

Tu dis faire ton décodeur toi même; tu n'as donc dans ton décodeur aucune fonction bloquante genre "delay", "wait" dedans? ou ni même de fonction de débug pour afficher des valeurs genre "print…"?

J'ai eu aussi des problèmes avec des décodeurs de signaux "QDecoder" qui ne fonctionnait pas bien lorsque ces derniers étaient branchés sur la même alimentation digitale que la voie… En séparant une alim digitale pour la voie et une autre pour les accessoires tout se passe bien.

Du coup j'essaie aussi de faire des décodeurs d'accessoires DCC pour moi et je me suis heurté à certains soucis de ce style: pour piloter des leds ça se passe bien mais lorsqu'on veut attendre un signal externe genre un capteur, ce n'est pas possible avec le DCC; il faut séparer cela en différentes tâches.
La lecture du DCC doit s'analyser en permanence sans qu'aucun arrêt de code soit programmé!

A+

Bonjour,
Le décodeur est réalisé avec un PIC 16F887 de Microchip avec utilisation de l'environnement MPLAB qui permet l'écriture en C et au besoin avec des séquences en assembleur.
La programmation utilise une carte basique Microchip.
L'environnement de travail est minimaliste.
Une interruption est utilisée pour surveiller le signal DCC et engranger les messages reçus, le programme principal tourne en tâche de fond.
La principale difficulté a été de régler les temps correspondant au 0 e1 DCC, l'oscillo à mémoire est indispensable pour vérifier la bonne prise en compte.
Je me suis rendu compte d'une erreur de conception décrite au dessus, il faut que je modifie une partie du programme pour y remédier.

Tu as écris: mais lorsqu'on veut attendre un signal externe genre un capteur



Je ne comprends pas car avec un décodeur DCC on ne peut agir que sur des sorties donc pas d'entrées possibles.

Claude

Bonjour,

Mes premiers essais ont été fait avec des kits Arduino et j'ai un sniffer avec une interruption qui gère la lecture du DCC...
Mais après j'aimerai juste que l'adresse DCC me start une variable avec laquelle je vais piloter un élément quelconque, qui lui pourra avoir des capteurs.
Par exemple j'aimerai faire une mongolfière qui se ballade d'un capteur de position à un autre…
Donc oui, le décodeur va gérer qu'une sortie, mais l'Arduino lui, peut faire n'importe quoi d'autre… Par contre il ne faut pas de commande bloquante.

A+