Faire sa propre centrale DCC

Tu peux regarder sur internet
Moi j'ai trouvé le mien comme ça
sur Nancy il y a ça
Hameg

En HO le transfo de base fourni est en 12V

jlb a écrit:

Les deux sont numériques.

Et un oscilloscope 1 voie ne sert pas à grand chose à mon avis

meme pour faire juste un controle? tu proposerais quoi de petit et pas trop cher?

J'ai un vieil analogique Beckman acheté d'occasion que je vais bientôt remplacer par un Rigol DS1052E. On le trouve à moins de 300€ TTC port compris : http://www.batronix.com/shop/oscilloscopes/Rigol-DS1052E.html
Cherche sur le web les tests concernant cet oscillo.

Pour juste faire un contrôle, 100€ c'est déjà trop cher. J'utilise très rarement le mien en 1 voie, on a toujours besoin de synchroniser sur quelque chose ou de comparer les délais entre 2 signaux

J'ai vu celui de nancy mais je redoute de transporter un analogique
A la limite pour tester a la maison mais pas en expo

Les rigols j'en ai vu plusieurs, y compris des test avec comparaison avec l'autre numerique de mon poste
mais jamais a moins de 300€, ca merite reflexion

Je te comprends. Ce n'est pas que mon Beckmann ne marche plus mais il est très très encombrant (et très lourd à trimbaler). À lui tout seul, il prend presque 1/3 de la surface de mon plan de travail  

Finalement le rigol a ce prix est parfait, merci pour le bon plan
Surtout quand on voit son prix chez ***rad

Y'a un test complet sur Youtube ainsi qu'un comparatif avec le premier prix Conrad (mais en anglais)

En attendant de pouvoir faire le signal DCC, j'ai fait une routine basique pour faire du PWM, comme j'ai prévu une boucle qui peut passer en analogique, deja cette partie sera faite

Si ca interesse quelqu'un, pas de soucis je fourni le code arduino

Kazaam a écrit:

pour l'oscillo, je souhaite délaisser le pc 
vu la facilité qu'on les gens pour le filmer (voir youtube) j'ai l'espoir qu'il soit assez lisible et j'espere qu'il fera des courbes suffisamment précises pour tester les circuits aussi bien en DCC qu'en PWM

Bonjour,

Je vois que ce sujet est récurrent mais ne mérite pourtant pas de se prendre la tête   

Je résume les moyens que j'ai mis en oeuvre avec un oscillo de base (2 voies analogiques de chez Selectronic), quelques leds, et un Arduino nano :

1) je regarde d'abord à la sortie de l'Arduino (soit une et souvent 2 pins, sans oublier la ou les pins de validation du booster) :
- avec une led : ça clignote ou pas
- avec l'oscillo : on voit peut être mal car c'est dur d'avoir un signal stable avec des créneaux de 2 durées différentes, mais on arrive à peu près bien à mesurer la durée des créneaux. Mais on ne peut pas mémoriser les trames pour savoir quelle trame c'est (il faudrait in scope digital à mémoire et moi, je suis comme d'autres : rien pour MacOSX   )
- avec un petit Arduino et le soft DCC_Monitor qui montre très bien si ça marche ou pas (je pense qu'on n'a pas besoin de plus, sauf si on se lance dans la programmation des CVs).

2) je regarde ensuite à la sortie du booster (et aussi aux entrées pour vérifier le câblage)
- avec 2 led en tête bêche (sans oublier la résistance de 10 K série) : si elles s'allument toutes les 2 c'est bon signe. 
- avec l'oscillo on doit voir un signal similaire à celui en sortie de l'Arduino et on mesure les tensions (C'est vrai que le booster ne perd pas de volts par rapport à l'alim. Pour le moment j'alimente toujours en 12 V et ça suffit : je ne dépasse pas 50% de la course des potard, après ce n'est plus réaliste)
- on peut ajouter DCC_Monitor mais derrière des optocoupleurs

Personnellement, avec le booster à base de LMD18200 je n'ai jamais eu de problème (j'en ai acheté 3 de plus au passage) et vos difficultés confirment que c'est la bonne bébête   .

Les seuls cas où j'ai peiné ont été au changement de librairie pour générer le signal DCC avec CmdrArduino qui utilise le Timer1 au lieu du Timer2 auparavant. 

Citation :

CmdrArduino is an embedded library written in C++ that provides the foundation for implementing an NMRA DCC command station. CmdrArduino presents classes and methods for, among other things, setting a locomotive’s speed, activating functions, switching turnouts, and programming DCC decoders. CmdrArduino translates these commands into DCC packets. The packets are carefully prioritzed, and CmdrArduino keeps track of packets that require repeating in the background. An interrupt service routine attached to TIMER1 (AVR) or MCPWM0 (ARM) takes these packets and injects the highest priority packet into the precision DCC waveform. This signal is suitable for amplification with your favorite booster/power station (I like LOLbooster). Please note that the Arduino outputs are not themselves capable of driving trains directly. Currently, CmdrArduino supports Arduino (including the Railstars OpenLCB Development Board), with ARM support (for LPC17xx processors) actively being added, making the library name something of a misnomer. 

J'ai du abandonner l'usage de la pin 12 (sur Mega) car elle perturbait le Timer1

Code:

// Booster Interface
#define DCC_PIN     11  // Arduino pins for DCC out are OC1A (pin 11) and OC1B (pin 12)
                        // this pin is connected to "DIRECTION" of LMD18200
#define DCC_PWM     10  // must be HIGH for signal out
                        // connected to "PWM in" of LMD18200
            
#define DCC_CS      A8  // Current Sense of Booster
#define DCC_TS      A9  // Thermal Sense of Booster

Actuellement je n'ai plus aucun outil de contrôle et pourtant il y a du monde qui joue avec MON train !

Toutefois, comme j'ai parfois des temps de réaction curieux (comme si la librairie DCC dormait), je vais connecter en permanence un Mini avec DCC_Monitor bricolé et un afficheur lcd qui me donnera les nombres de paquets par seconde (hors idle). Ca aussi suffit pour s'assurer que tout va bien.

Bon courage !

PS : mon TCO en 2 parties (une partie avec l'interface boutons, potard, leds, afficheurs des N° de trains dans les cantons et générateur DCC, l'autre partie avec commandes d'aiguilles, lecture des capteurs et bientôt gestion de la signalisation et sécurité) avance bien. Je commence la description sur mon blog tant que ce n'est pas tout à fait clair. 
Entre temps j'ai passé du temps sur le décor qui n'est pas encore terminé ... et Noel approche...   

Bonjour,

SixtyFive a écrit:

- avec l'oscillo : on voit peut être mal car c'est dur d'avoir un signal stable avec des créneaux de 2 durées différentes, mais on arrive à peu près bien à mesurer la durée des créneaux.

De toute façon le mieux est de bien comprendre ce qu'on fait avec le micro-processeur (Arduino ou PIC dans mon cas)

Si on utilise bien les timers et les interruptions, le signal doit être exactement ce qu'on souhaite, il n'y a même pas besoin d'un oscillo pour le vérifier ...
De plus les logiciels de développement disposent pratiquement tous d'une fonction "simulation" qui permet d'analyser en détail le comportement du programme sans même disposer du matériel et cette fonction permet de tracer de façon ultra précise le signal de sortie, bien mieux qu'avec un oscilloscope.

J'ai tout développé sans aucun appareil, puis un jour où j'ai trouvé un oscillo en promo à moins de 100 Euros je l'ai acheté juste pour voir si les fronts des signaux étaient propres... cela m'a permis de rectifier la valeur d'une résistance sur un de mes décodeurs parce que j'ai pu voir que le signal digital à l'entrée du PIC était un peu avachi, mais ça marchait quand même.

L'oscillo m'a servi une heure, depuis il est au fond d'un placard.

Bonne journée   

J'en conviens, l'oscillo n'est pas indispensable, mais la je ne comprend pas pourquoi d'un coup a l'autre le train devient fou...

Et puis cela tombait bien je n'avais pas d'idée de cadeau pour noel

J'ai pu tester mon circuit ce week end avec le dcc generé par la multimaus et le PWM de l'arduino pour les trains analogiques
Encore quelques point a terminer pour la gestion auto de tout cela et ca va etre sympa.

J'ai même pris le temps de faire une carte pour mettre l'atmel tout seul (en fait rien de bien compliqué)

L'oscillo n'est pas indispensable sauf quand il le devient.

takeo a eu du pot jusqu'à maintenant tous ses devs marchent sans encombre. Et puis un jour ça ne fonctionne pas, on tourne en rond, des comportement son erratiques sans que l'on comprenne pourquoi et il n'y a pas d'autre moyen d'investigation que l'oscillo.

Exemple dimanche. Je veux connecter mon Arduino sur mon bus CAN des accessoires qui est à 125kbits. Je plante un 2515 (interface CAN via le SPI) et un 2551 dans la breadboard (transcepteur CAN), je mets les capas, le quartz qui vont bien, je raccorde à l'Arduino. Je récupère la lib CAN de Seeeduino et charge le programme exemple en réception en changeant la vitesse du bus pour 125kbits

Ça ne marchait pas. J'examine le montage, la lib, le code, à priori ok. Bon
Je sors l'oscillo et je vérifie que la trame arrive au 2515 -> ok

Je charge le programme en émission sur l'Arduino et je vérifie que la trame sort du 2515 -> ok

  

La trame sort, elle sort même trop en fait, elle sort tout le temps alors que je n'envoie un message que toutes les secondes => erreur de communication. Je regarde la largeur d'un bit sur l'oscillo : 5µs  donc 200kbits et pas 125kbit. La lib de Seeeduino est fausse sur le réglage de la vitesse.

Plongée dans la datasheet, recalcul des paramètres qui font la durée d'un bit sur le CAN, modif de la lib, ÇA MARCHE !   

Sans oscillo j'y serais encore vu qu'il peut y avoir des dizaines de trucs qui foirent. Vive l'oscillo. Quand j'aurai un numérique, je pourrai enregistrer en one-shot et examiner tranquillement les signaux. Vivement mes 50 ans

J'ai recu le rigol hier
Double carton, et vraiment tout petit (j'ai juste eu le droit de le sortie partiellement pour controller)

maintenant encore une semaine pour vraiment le deballer et le tester

Salut Jean-Luc,

jlb a écrit:

Vivement mes 50 ans

Rigole bien maintenant .... Quand tu en auras 15 de plus tu ne seras pas pressé de voir arriver les 70    

jlb a écrit:

takeo a eu du pot jusqu'à maintenant tous ses devs marchent sans encombre

Sans encombre, si seulement !!  

Mais bon j'applique les méthodes de développement que j'ai apprises pendant mes 40 années d'activité, ça aide pas mal...

Mais il m'arrive quand même de passer des heures à chercher pourquoi ça ne fait pas exactement ce que je veux ou pourquoi ça se plante à certains moments ... Mais c'est rarement un oscillo qui m'aidera à comprendre...
Je n'utilise pas non plus le simulateur/débogueur de Microchip... je trouve ça trop lourd et je préfère utiliser une ou deux leds et rajouter un "LED_On()" ou un "LED_Off()" là où je suspecte un dysfonctionnement....

Pas plus tard qu'avant hier j'ai perdu 4 heures en voulant standardiser des bouts de code entre différentes applications et pour une de ces applications ça merdait et le multimètre ne faisait que me montrer que les sorties restaient à zéro mais il ne m'a pas dit pourquoi, il a fallu que je trouve tout seul     En fait j'étais juste trop persuadé que mon bout de code tel qu'il était pouvait s'utiliser partout et j'avais zappé le tout petit détail qui faisait que dans une application il fallait retirer une ligne !!

Bonne soirée  

Les 50 ans ils sont tout près, 15 ans c'est long

Pour déboguer, l'oscillo n'aide pas forcément. Mais quand tu utilises des interfaces que tu ne peux pas ralentir et où tu ne peux pas brancher des LED pour voir ce qui se passe, il n'y a plus que l'oscillo (ou l'analyseur logique)

Et puis il y a les bouts d'analogique.

Comme tu développes sur PIC, tu serais peut-être intéressé par Piccolo. C'est un assembleur structuré pour PIC 18 et baseline: http://piccolo.rts-software.org

jlb a écrit:

Les 50 ans ils sont tout près, 15 ans c'est long

Dans 15 ans tu trouveras que c'est court !!

jlb a écrit:

Comme tu développes sur PIC, tu serais peut-être intéressé par Piccolo. C'est un assembleur structuré pour PIC 18 et baseline: http://piccolo.rts-software.org

Merci il faudra que je regarde, mais je t'avoue que l'assembleur pour moi ça remonte aux années 70 avec un T2000 de Télémécanique, puis avec des HP1000 de Hewlett Packard ...

J'utilise le compilateur C de Microchip pour les PIC18 et celui de MikroElektronica pour les PIC12...

Bonne soirée   

Oui bon   si je pouvais encore vivre un peu sans penser au mur qui va arriver   

Avec ma première méthode de génération des trames DCC, en gonflant le code, de 2 a 4 locos, je me suis retrouvé avec des timing aberrants que j'ai vu à l'oscillo.
En cherchant ce qui pouvait provoquer ça, j'ai trouvé que mon code était mal foutu !
C'est vrai que je ne m'en sers pas souvent mais ça rassure d'en avoir un.

En tout cas c'est bien de mentionner nos problèmes et solutions dans ce forum.

... Et avec l'âge (et surtout la retraite), on reste cool et on a confiance dans ce qu'on fait !

Bon c'est Noël   

Je vais, comme promis, donner plus de détails sur la réalisation de ma centrale DCC version 2 qui est construite en 2 parties :
- Le TCO, partie "émergée", qui comporte l'interface pour les pilotes (potentiomètres à glissière pour la vitesse, boutons de fonction et voyants, en bas et tableau de contrôle avec affichage des trains et commande des aiguilles, en haut).

Il contient également le générateur de signal DCC qui est envoyé au booster.

- et le Contrôleur, partie "immergée" c'est à dire "sous le circuit", qui s'occupe de la commande réelle des aiguilles et de récupérer les informations des divers capteurs. Par la suite il commandera aussi les signaux tricolores et divers éclairages.

Testé aujourd'hui, la gestion des cantons permettant aux trains de s'arrêter automatiquement si le canton suivant est occupé, fonctionne bien !
Il me reste donc à installer, cabler et gérer les feux tricolores, ce que la partie immergée fera sans difficulté.



Au total, le coût de cette centrale ne doit pas dépasser les 100 Euros.
Vu tout ce qu'elle fait, ce prix est probablement imbattable !!!

L'architecture générale est décrite ci-dessus et le logiciel est là :

TCO-soft du 27/12/2013

Cette version fonctionne mais n'est pas du tout optimisée. Elle a certainement le mérite d'être facile à lire.
Il y manque en particulier une grande partie "paramètrage" qui utilisera l'EEPROM des microcontroleurs.
Il y a aussi trop de fonctions de "debug" et de nombreuses variables redondantes, des constantes déclarées en variables, des erreurs de type, et même des bugs très probablement, etc.. 

Et pourtant ça marche   

Mais je répondrai bien volontiers à vos questions.


Bonne lecture... et bonnes fêtes.

Ce logiciel sera pour beaucoup, une source d'exemples :

- gestion d'un capteur RFID,
- gestion de capteurs infrarouge, avec fonction calibrage (entrées tantôt utilisées en digital, tantôt en analogique),
- gestion des aiguilles avec rafraichissement automatique des positions toutes les 30 secondes,
- gestion minimale de la bibliothèque CmdrArduino (envoi de commandes vitesse+direction et F0),
- gestion du dialogue I2C entre les deux processeurs (répartition des tâches)
- fonctionnement multitâche, incluant l'anti-rebond des poussoirs (pas si évident que cela !),
- gestion de la tête et de la queue des trains, sans aucune mesure de courant !!!
- gestions d'afficheurs 7 segments et leds, tous multiplexés.

La gestion des cantons, délimités par les barrières infra-rouges, est simple mais suffisante pour éviter les collisions. Même un décrochage de wagon peut stopper le train suivant.
Il est possible (dans une prochaine version) de connaitre la vitesse des trains.

Chaque train est commandé individuellement par son adresse DCC. Le système connait donc la position des trains SANS AUCUN APPRENTISSAGE MANUEL. Tout se fait automatiquement : il suffit de faire circuler les trains un tour complet !

Les numéros de trains s'affichent sur le TCO ce qui permet de contrôler le bon fonctionnement de l'ensemble.

Les cantons sont décrits dans un simple Array et chaque train dans un autre :

Code:

byte _loco[4][8] = {
  { 03,1,0,2,0,5,5,1 }, // loco 1     // 0=N° DCC de loco, 1=AV-1 ou AR-0, 2=vitesse 0..127, 3=lumière (F0)
  { 04,1,0,2,0,5,5,1 }, // loco 2     // 4=N° canton en cours 5=temps restant canton en cours (s),
  { 05,1,0,2,0,5,5,1 }, // loco 3     // 6=N° canton suivant, 7=Loco autorisee 1=START 0=STOP
  { 06,1,0,2,0,5,5,1 }  // loco 4
};

Code:

byte _canton[8] = { 0,0,0,0,0,0,0,0 };   // 0=C0(rfid1 - sortie gare, K0), 1=C1(IR3_tunnel1, K1), 2=C2(IR4_montée, K2),
                                         // 3=C3(IR5_descente, K3),  
                                         // 4=C4(IR6_tunnel2, K4), 5=garage(IR7, K5), 6=Quai1(IR1, K6), 7=Quai2(IR2, K7)
                                         // les cantons sont définis - APRÈS LE DETECTEUR -
                                         // _canton[x] = No de loco (1..4) ou libre = 0

Deux routines clés sont :

Code:

byte Canton_Suivant(byte train)  // rappel : index _loco = train - 1

qui sert à déterminer quel sera le canton suivant en fonction des positions d'aiguilles et du sens de circulation

et

Code:

byte Quel_Train_Entre(byte canton)  // numero de train attendu

qui permet de trouver le numéro du train détecté par une barrière infrarouge, en balayant justement les infos de "canton suivant" dans les arrays de locos.

Ensuite la routine < void IR_up(byte d) > détermine l'action en tête de train et < void IR_down(byte d) > en queue de train.

Vous remarquerez le traitement d'anti-rebond appliqué aux espaces inter-wagons, qui permet d'avoir une information fiable de queue de train, même si les barrières IR sont placées en biais ...

Parmi les inconvénients, il manque la programmation DCC (N°s de locos, CVs). J'ai utilisé une petite MS2 histoire de ne pas prendre tous les risques à la fois. Mais j'y pense, avec le paramètrage de la centrale ...

Bonne lecture...

Une petite video montrant le TCO et un train qui s'arrête et redémarre automatiquement se trouve ici.

https://vimeo.com/82841887

SixtyFive a écrit:

Une petite video montrant le TCO et un train qui s'arrête et redémarre automatiquement se trouve ici.

https://vimeo.com/82841887

Erreur de lien 

La video est en cours de conversion, encore quelques minutes. 
Désolé, j'aurais du attendre un peu  



La video est disponible depuis 23H02 !

Bonne Année 2014 à tous !

Je vous présente mes meilleurs vœux de réussite dans vos projets et j'espère que ce fil aura pu vous aider et pourra satisfaire au moins une partie de vos attentes.

Quand à mon projet, dans les étapes à venir, il y aura la gestion des sémaphores et de nouvelles versions du logiciel, notamment avec configuration et programmation des matériels.

Qu'en pensez-vous ?

 

Bonjour et bonne année à tous,


Je vois que ça bosse et que ça avance ...  Félicitations SixtyFive

De mon côté j'avance aussi avec mes PICs et je butte en ce moment sur les "consist adress"

Je ne comprends pas très bien comment ça marche ...

Si je mets l'adresse de concordance dans la CV 19 la loco répond sur cette adresse ..
Si je mets 0 dans la CV 19 elle répond sur son adresse ...
Note : j'en profite pour dire que depuis hier je programme les CVs avec ma bidouille   

Problème : pour changer la CV19, il faut repasser en mode service sur voie de programmation   

Donc question : comment activer et désactiver la concordance en mode opération?

J'ai lu le RP-921 du NMRA mais les explications sont loin d'être claires...

J'ai essayé des messages du genre :

Code:

preambule 0 adresse 0 00010010 0 consist_adress 0 EEEEEEEE 1

Mais cela ne marche pas ...

Si quelqu'un a un tuyau, je suis preneur ...

Bonne soirée  [/i][/i]

Bonjour Takeo,

Je ne connais pas le consisting, mais j'ai trouvé ceci


http://tonystrains.com/technews/consisting-guide.htm

Citation :

Here is the procedure I used to check out my decoders. Note: You need to switch back and forth between a consist address and the normal locomotive address during this test. Two cautions, when using the program track, be sure that only the locomotive you wish to change in on the program track. With OPS mode programming the values in these CVs can be changed using locomotives address and not the consist address.

Il semble possible de programmer le CV 19 d'une machine spécifique, donc même en dehors de la voie de programmation en utilisant le OPS mode.

Mais je n'en suis pas sûr.