Decodeur d'occupation compatible RAILCOM

[Dominique]

Si Laurent se propose de réaliser un booster qui génère le CUTOUT et une carte de détection qui puisse envoyer sur le bus CAN un message respectant un codage spécifique aux satellites, pourquoi ne pas le laisser faire

La je suis d’accord avec toi et nous attendons d’en savoir plus de la part de Laurent. Je pense aussi que le booster peut être intégré à la carte.

[bobyAndCo]

Si le booster coupe entre 2 paquets DCC, il faut qu’il y ait un intervalle de temps suffisant entre deux paquets pour que des trames ne soient pas perdue. Cet intervalle de temps est de combien et c’est défini où ? (J’ai diagonalisé ceci dit, j’ai sans doute loupé l’info). Si c’est la centrale maison qui génère le CUTOUT, c’est plus simple il me semble (c’est toujours plus simple de ne pas faire un truc plutôt que de l’inhiber par un mécanisme espion)

Je crois également que c'est mieux de le faire ainsi. Je ne voyais même au départ que cette hypothèse. (voir posts précédents).

Cependant, le soft de codage DCC auquel se réfère Laurent est "CmdrArduino". Je suis très réservé. Nous en avions tous mesuré les limites (voir les bugs) il y a quelques années d'où notre empressement à l'abandonner dès que nous avons découvert DCC++. Les choses se sont elles améliorées ? J'ai parcouru le code de CmdrArduino (version actuelle), il y a bien un certain nombre de fonctions ayant trait à Railcom mais un certain nombre d'autres sont commentées (ça fleur pas bon ce genre de choses).

A t'on vu un booster "classique" piloté par CmdrArduino et qui génèrerait les CUTOUT Si oui, les fonctions internes pour le CUTOUT devraient probablement être "copiées" sans trop de difficultés. Il y a aussi un fil sur Trainboard : DCC++ modified to produce Railcom cutout? je vais regarder.

Enfin pour ma part, le sujet m’intéresse si c’est dans le projet qui nous occupe, à savoir le système DIY de commande du réseau et le Satellite V2.

Donc Laurent fait complètement ce qu’il veut mais comme il nous sollicite pour faire le soft, il faut que nous accordions nos violons.

C'est bien ce que j'ai dit dans mon précédent post !

[Dominique]

Si le booster coupe entre 2 paquets DCC, il faut qu'il y ait un intervalle de temps suffisant entre deux paquets pour que des trames ne soient pas perdue. Cet intervalle de temps est de combien et c'est défini où ? (J'ai diagonalisé ceci dit, j'ai sans doute loupé l'info). Si c'est la centrale maison qui génère le CUTOUT, c'est plus simple il me semble (c'est toujours plus simple de ne pas faire un truc plutôt que de l'inhiber par un mécanisme espion)

Le principe même du DCC est la répétition des trames à cause des pertes inéluctables dues aux mauvais contacts. Le standard DCC ne prévoit pas d'intervalle de temps pour le moment. Par contre Railcom n'est pas encore un standard accepté par tous les constructeurs.
Par conséquent le cutout peut faire perdre une trame ou 2 dans la zone du détecteur, ça ne gêne pas la loco. D'ailleurs je ne vois pas pourquoi la centrale qui est unique pour toutes les zones en principe, déclencherait un cutout généralisé, provoquant des réponses de tous les décodeurs présents sur le réseau.

[laurentr]

Bonjour

je vois que ca "busille " dans les esprits
C est une bonne chose cela prouve tout l’intérêt de la problématique et de la manière de la traiter.

Pour ma part voici ma vision des choses:

Le BOOSTER de PACO est INDEPENDANT pour gérer le CUTOUT RAILCOM sur un signal DCC en entrée. ( sur son site PACO explique qu il récupère bien des info RAILCOM depuis un LRC120 LENZ connecté à son BOOSTER en mode RAILCOM et une centrale NON RAILCOM. ET cela fonctionne!
Ce n est pas de l'Arduino ( ca reste du DIY) c est un bon vieux PIC qui fait le job mais on a la fonction que l'on veut, qui plus est protégée contre les CC)
Pour ma part j ai change des composants pour passer de 2.9A à 5A et revue la disposition. Par ailleurs j ai aussi prévu des RADIATEURS de bonne dimension pour évacuer la chaleur.

Le L6203 est assez proche d un LMD18200 mais je ne connais pas assez leur similitudes/différences.

On a ainsi le synoptique suivant:

0==> PC et logiciel de pilotage
1==> CENTRALE DCC (marque du commerce ou DIY): role: génère le signal DCC ( avec ou sans railcom)
2==> BOOSTER de PACO (version Laurent à 5A) (Génère le CUTOUT RAILCOM et amplifie le signal, réagit en cas de cour circuit) rôle: permet la distribution du signal DCC pourvu du CUTOUT
3==> Detecteur d occupation capable de faire remonter l info d'occupation et la partie des messages RAILCOM:
partie 1 détection pure (selon, schéma de la norme NMRA 9.3.2,
partie 2 "Arduino/328 pour traitement du signal et remontée d informations vers un logiciel qui exploite ces info (protocole de sortie a definir...) (partie à construire "ensemble" ) et éventuellement
partie 3 une troisième partie dédiée à la propagation du signal selon la techno choisie. (CAN, LOCONET...etc)
4==> remontée des info vers un centralisateur et remontée PC, etc

On respecte ainsi l esprit "satellite"/ modulaire mais chaque bloc est bien spécifique d'une fonction donnée. (je ne suis pas la pour faire la révolution!)

Raisonnablement et compte tenu de la place que prennent les composants il faut séparer en plusieurs cartes, cela facilite la modularité et le dépannage éventuel.
Chacun peut s'équiper au fur et à mesure également.
5A pour 8 ou 16 zones, voir plus, ça laisse de quoi faire circuler!

J ai des PCB de BOOSTER 5A RAILCOM a dispo ainsi que pas mal des composants pour les monter. Si cela intéresse certains d entre vous pour leur Labo m'envoyer des signaux de fumée

Les PCB que j ai présenté plus haut en dessin sont la pure conversion du schéma de la norme NMRA 9.3.2 (partie 1 dans ce projet)
(page6)
Le tableau page 7 de cette même norme indique les temps du CUTOUT et la structuration des messages lors de celui ci.

enfin le schéma de KEYBUK ci joint donne la façon de détecter le CUTOUT sur nos entrées ARDUINO/328. (donc peut importe les timings du BOOSTER on doit adapter le code sur ce qui sera perçu ici pour assurer un excellente synchro)
source: http://www.rmweb.co.uk/community/index.php?/topic/123719-handmade-railcom/

(si je vais plus loin on aurait ainsi signal DCC sur PIN2 (INT0) et signal CUTOUT sur PIN3 (INT1) mais je me trompe peut etre?)

Voila qui me semble "boucler" le cahier des charges des différents blocs du "HARDWARE" au moins à grosse maille en termes de fonctionnalités?

Laurent

[laurentr]

En complément des quelques questions posées plus haut et à propos de bus CAN pour relier la partie DÉTECTEUR de la partie traitement je ne suis pas certain qu économiquement mettre des composants pour générer des info sur le CAN pour 2 zones détectées soit "rentable".
(ni même 4)(déjà mieux pour ( je pense qu on ne pourra pas en mettre bcp plus sur un ARDUINO/328). ( après comme toujours c est une question de place sur les PCB.)
Par contre remonter ces info sur un concentrateur qui lui communique en CAN est une autre option à considérer. Mais ce n était pas ma vision première.

Cela dit l'approche "mutualisante" des capteurs vers un concentrateur/interpréteur" commun recevant du CAN semble une piste sympa .

Auquel cas dans ma description précédente ma partie 3 est cette partie pour la diffusion des info jusqu'à ce concentrateur.

[Dominique]

Le choix du pourquoi et du comment "le Can" est expliqué dans l'article qui vient de sortir
http://www.locoduino.org/spip.php?article242

La mutualisation du Can est faite au sein de chaque satellite.
Il faudra attendre la suite pour comprendre et intégrer Railcom là dedans.
Prochain article la semaine prochaine (hé, il faut nous laisser le temps de bosser en dehors de toute contrainte excessive  ).

Ça tombe bien, ça nous intéresse beaucoup et c'est le moment d'y penser !

Donc autant le faire en détail :

Est-il possible, en attendant de voir un schéma complet d'architecture pour Railcom, pour être bien tous en phase ?
Un peu comme les beaux schémas qu'on fait dans nos articles ... si possible avec un logiciel de dessin comme celui qui sert à faire les circuits intégrés... merci d'avance

Dominique

[laurentr]

Voila une petite synthèse vite faite

[bobyAndCo]

Ce truc m’intéresse même si je suis convaincu que le RFID est plus intéressant à de nombreux égards. L’un n’étant pas exclusif de l’autre et si la mise au point de ton système n’est pas trop chronophage, pourquoi pas ?

L’essentiel de la réponse tient dans le fait que tu sois capable de sortir au niveau hard un détecteur d’occupation capable d’intercepter les trames émises par le décodeur qui est dans le canton.

Si, comme le prétend le gars de l’article que tu cites, le hard est capable de faire remonter les trames via le TX, alors effectivement, derrière c’est du gâteau et un peu de temps pour écrire le parsage du message (si on n’a pas les correspondances mais elles doivent exister ne serait-ce que dans la norme NMRA).

Pour la propagation du message, ça reste à voir. Moi ce qui m’intéresse et comme l’a demandé Jean-Luc, c’est de renvoyer une trame CAN selon un protocole qui aura été défini avec Jean-Luc mais qui ne sera probablement très proche que celui qui sera adopté pour le RFID.

Pour la diffusion à d’autres bus, j’ai par exemple mis au point une interface CAN/TCP, elle peut se faire par ce biais pour les terminaux en TCP et rien n’empêche qui ça amuse de se créer sa passerelle CAN/Loonet, CAN/S88 etc…

Il faut donc que tu sortes ce détecteur.

Concernant la génération du CUTOUT, je voudrais être sûr que l’on soit bien sur la même longueur d’onde. Pourquoi insistes-tu autant sur le BOOSTER de PACO et surtout, pourquoi dis-tu « Génère le CUTOUT RAILCOM » alors qu’il est à peu près certain que le booster ne génère rien !  Le booster, transforme un signal carré de 0 et de 1 (0V ou 5V) en un signal DCC, c’est à dire +18V / -18V en répetant les fréquences du signal 0-5V.

Revoir sur ce point l’article très explicite de Dominique : L’Arduino et le système de commande numérique DCC
: http://www.locoduino.org/spip.php?article14

Les booster, que ce soit celui de PACO, ou le tien ou encore un LMD18200 n’ont rien de fondamentalement différent et surtout pas en ce qui pourrait concerner la gestion de Railcom.

C’est donc au générateur de signaux DCC, dans notre cas à DCC++ qu’il appartient d’introduire le CUTOUT, probablement par simple arrêt d’émission de trame sur la durée précisée dans la norme (et peut être un peu d’emballage avant et après le CUTOUT histoire de prévenir le décodeur, « je suis un CUTOUT et j’arrive juste après ». Donc à mon avis pas trop compliqué non plus de modifier DCC++.

Donc comme tu dis, il y a plus qu’à. Je regarde comment ont peut générer le CUTOUT dans DCC++ et toi tu produis le détecteur. On rassemble les deux et hop, non ?

Christophe

[Dominique]

C'est donc au generateur de signaux DCC, dans notre cas a DCC++ qu'il appartient d'introduire le CUTOUT, probablement par simple arret d'emission de trame sur la duree precisee dans la norme (et peut etre un peu d'emballage avant et apres le CUTOUT histoire de prevenir le decodeur, que je suis un CUTOUT et j'arrive juste apres. Donc a mon avis pas trop complique non plus de modifier DCC++.

Donc comme tu dis, il y a plus qu'a . Je regarde comment ont peut generer le CUTOUT dans DCC++ et toi tu produis le detecteur. On rassemble les deux et hop, non ?

Christophe

Je pense qu'il n'est pas besoin de faire ce CUTOUT au niveau de la centrale, mais plutot au plus pres du reste du detecteur, simplement en inserant en serie avec le feeder DCC des transistors de commutation (Mosfet ou plutot triac car c'est de l'alternatif) pilotes par la fonction detecteur de présence et qui ne font ce CUTOUT que pour la zone du detecteur. On n'a d'ailleurs probablement pas besoin de telles intensités (5A c'est pour un paquet de zones !!) et donc il doit etre possible de mettre tout ce matériel sur une même carte fille de satellite.
En tout cas c'est ce qui réduirait le plus le cablage et les perturbations.

C'est ce genre de schéma qui serait interessant.

[msport]

Je tente de m'accrocher, mais pour illustrer le cutout (je découvre comment Railcom fonctionne) le dessin du site de Paco est clair :

[laurentr]

Bonsoir

L inconveniant d être au plus prêt et au plus dédié de la zone pour générer le cutout  et la parfaite synchro de la zone suivante.
Si cela n est pas parfait et aligne... bonjours les ennuis!
Un LMD18200 fourni 3A. S il en faut un par carte traitant 8 zones pourquoi pas. ( mais à mon sens pas plus)
Un train étant en mouvement souvent à cheval sur 2 zones et sur 8 zones 3 trains peuvent évoluer sans soucis avec chacun 1A et plus en pointe ... c est une hypothese valable d intégrer sur le bouclier signal et puissance la production local d énergie pour ces 8 zones.
Lmautrr partie du ci traitant elle la partie détection pure.

A ce stade nous aurions:
8 entrées pour la détection des zones
2 sorties pour le CAN bus
2 pour la generation du signal dcc en local sur le 18200 et gestion des cc
2 pour l I2C qui permet une extension Sion vers un. Affichage sur  lcd optionnel

[Dominique]

Je ne comprends pas pourquoi utiliser un LMD18200 qui est un « booster » complet (et plus simplement un pont en H) alors qu’il y a déjà une centrale avec son booster (un montage à base de DCC++) qui dessert tout le réseau.

Le cutout peut être fait simplement en « coupant » le signal DCC localement par une paire de triac sur les 2 rails.

Ainsi il n’y a aucun risque de desynchronisation. Évidemment il faut éviter les contacts avec les 2 zones adjacentes, grâce au block system. Railcom ne permet pas de faire l’économie de capteurs.

En tout cas je pense qu’on peut simplifier.

[Dominique]

A ce stade nous aurions:
8 entrées pour la détection des zones
2 sorties pour le CAN bus
2 pour la generation du signal dcc en local sur le 18200 et gestion des cc
2 pour l I2C qui permet une extension Sion vers un. Affichage sur  lcd optionnel

Pouvez-vous faire un schéma ?

[bobyAndCo]

Bonjour à tous,

Peut-être avez vous raison de vouloir réaliser le CUTOUT avec de l'électronique, triac etc... et peut être ne peut on pas faire autrement. Mais je ne le crois pas !

Pour moi, il faut créer le CUTOUT de manière logicielle, donc pour ce qui nous intéresse, c'est DCC++ qui doit être adapté pour générer le CUTOUT et ce sur tout le réseau. Ca n'a aucune incidence. Chaque canton étant potentiellement susceptible "d'héberger" une loco Railcom. Alors, plus de questions de synchro et tutti quanti.

J'ai convenu avec Laurent qu'il réalise un prototype du détecteur, de mon côté, je vois pour modifier DCC++ et lui faire générer le CUTOUT, et l'on voit ce qui se passe !!!

Je suis convaincu que c'est la bonne solution.

Christophe

[laurentr]

Bonjour à tous

Pour le cutout il y à plusieurs options:
1ere option:
il est produit par une centrale et il est présent sur les trames dcc ( ou celle du booster de paco)
Le détecteur ne les traite pas spécifiquement, il laisse juste remonter l info RAILCOM des décodeurs via le détecteur.

Le 328/ arduino est adjoint d'un détecteur de cutout ( pour assurer la synchro)sur une de ses entrées.
Cette combinaison est universelle ( produit du commerce et home made) et permet de traiter la detection du cutout et la détection locale d occupation d une zone.

2 eme option:
 une elec dédiée est placé sur la carte qui alimente les zones de détection. ( booster diy? Booster sur carte satellite en local?)
Le cut out est génèré par de l'elec localement.
Le detection est gérée localement aussi comme précedement

3ème option:
le cutout est génère au niveau dcc++ et donc comme sur une centrale mais exploité via le bus qui lie les satellites ( détection traitement) ( et donc pas transposable vers une solution universelle DIY et produit du commerce  ex RRTC, ROCRAIL....)

Personnellement mon choix est sur l option 1 car la plus universelle.
Des transpositions sont possibles aussi sur les deux autres cas mais leur diffusion touche un public plus restreint.

A voir deja.!
La première étape:
Construire le détecteur et récupérer le signal de remontée d'info du décodeur railcom via le détecteur.
Le PCB est  dessiné, la commande sera passée mercredi soir pour une livraison fin février/ début mars.
Les composants seront arrivés entre temps pour un montage (bien) avant le printemps.

D'ici la on peut affiner la mise en perspective du dispositif.

Laurent