LOCODUINO
Parlons Arduino => Vos projets => Discussion démarrée par: laurentr le janvier 18, 2019, 12:06:25 am
-
Bonjour
Sur le modele du DR5088 De DIJIKEIJS je trouve interessant de voir ce qu'il serait possible de faire pour un decodeur DIY a base d Arduino qui permette de remonter les info RAILCOM.
Le DR5088 ( mu par un ATMEGA 128) traite cela sur le bus LOCONET.
Pourquoi pas!
La norme NMRA 9.3.2 decrit de nombreux points. ( bien que les constructeurs de décodeurs aient pris quelques liberté aussi avec...)
https://www.nmra.org/sites/default/files/s-9.3.2_2012_12_10.pdf (https://www.nmra.org/sites/default/files/s-9.3.2_2012_12_10.pdf)
Une tres belle approche est donnée ici: ( en anglais)
http://www.rmweb.co.uk/community/index.php?/topic/123719-handmade-railcom/ (http://www.rmweb.co.uk/community/index.php?/topic/123719-handmade-railcom/)
Reste a traiter "tout le reste"...
Dessiner le CI ne me pose pas trop de soucis (il faut qd meme le faire :) )
Par contre, la suite me dépasse un peu....
J aurai donc apprécié un peu d aide sur ce sujet que je trouve porteur...
Laurent
-
Bonjour Laurent,
Je viens de lire le post et je trouve cela intéressant.
Le montage est somme toute relativement simple à créer, le hic où instale-t-il ce montage?
A l'intérieur de la loco pour du O, pour du Ho? Sur le feeder, de plus pour détecter une machine c'est compréhensible, mais 2 ou plus?
Si tu utilise des accessoires en DCC ... Mélange des trames des signaux comment l'Arduino fait le trie
Je vais suivre avec intérêts tes investigations.
Cordialement
Marcel
-
Bonjour Marcel
Le décodeur est statique et se situe sous le réseau.
Il est compatible pour toutes les échelles.
Son but: indiquer l occupation d une zone et identifier le matériel via railcom présent sur cette même zone.
La description donnée plus haut donne les éléments hardware de la partie détection.
Reste à interfaced cela avec nos arduino/atmega328 et voir ce que l on tout en exploiter.
8 entrées de présence avec railcom serait un bon début
Ensuite autre partie à traiter envoyer ces informations vers les centrales.
Le DR5088 le fait par LOCONET. On peut s en inspirer aussi, sinon voir quel autre protocol utiliser pour cela. (Je dirai XPRESSNET, voir CAN...)
Bref un sujet de synthèse qui est assez vaste mais très polyvalent...
Tout aide serait bien venue!
A ce stade j ai déjà dessiné un typon du décodeur présenté dans la norme 9.3.2 et un regroupement de ce dernier x4 sur un circuit en 10x10cm
Apres... je sèche un peu...
Sur une autre partie il faudra dessiner le bouclier ou le support du 328, et y mettre les entrées dont celles utilisant les interruption (pin 2 et 3 pour Int0 et Int1.)
Pour les autres pin des In je n ai pas d avis sur lesquelles prendre à ce stade.
-
Merci pour ces précisions
Je vais cogiter si j'ai un moment de libre, pour la Programmation voir avec les nombreux membres qualifiés sur ce forum
Cordialement
Marcel
-
Hello
Je me permets aussi d ajouter ici le lien vers la notice du DR5088RC cité en référence et pour lequel nous souhaitons avoir un fonctionnement analogue a base d'Arduino ( si toutefois cela reste possible ?)
A noter que le nombre de zones sera dans notre ambition moins généreux ( au moins dans un premier temps, et que de partir sur 8 semble être une base intéressante.) ( explication: l'ATMEGA 128 du DR5088 est plus "robuste" que notre ATMEGA 328)
http://support.digikeijs.com/display/DS/DR5088RC (http://support.digikeijs.com/display/DS/DR5088RC)
Autre bout de reflexion aussi sur la partie LOCONET et ARDUINO grace à ce qui est deja rélisé sous ARCOMORA avec le ARLOCO
doc et info ici:
https://www.arcomora.com/download/ (https://www.arcomora.com/download/)
Bref, à s'inspirer des réalisations d ici et de là on doit pouvoir faire une synthèse consolidée et me semble t il opérationnelle.
Bonne lectures sur ces sujets...
Laurent
-
Bonsoir,
Je me pose des questions sur le fonctionnement. Comment le détecteur établit-il la relation entre le de odeur et sa position physique sur le réseau ?
-
J'imagine que c'est par canton : en tout ou rien : "moi", je suis ici (ou pas : silence)
https://www.locgeek.com/fr/2012/10/railcom-railcom-plus-kesako/
-
Bonsoir,
Je me pose des questions sur le fonctionnement. Comment le détecteur établit-il la relation entre le de odeur et sa position physique sur le réseau ?
Le detecteur Railcom alimente en DCC une zone isolée. C’est sa position physique qui détermine la zone concernée.
Quand une loco passe dans la zone (détectée par détection de consommation), le détecteur crée une coupure complète du signal DCC de traction (cutout) pendant laquelle la loco envoie des infos qui la décrivent, notamment son adresse DCC, etc...
C’est suffisamment bref pour que la loco reste alimentée sur ses condos intégrés à son décodeur spécifique Railcom.
Côté détecteur les infos reçues sont en protocole série et c’est de la variation de tension.
On se penchera un de ces jours sur la construction d’un detecteur Railcom, grâce au site Arcomara, mais probablement après la détection RFID, plus simple et immédiate et ne nécessitant pas de décodeur spécial dans les locos, tout en donnant une identification fiable.
Mais cette discussion doit continuer pour préciser les besoins de chacun.
Dominique
-
Bonjour
Dominique a très bien résumé le principe de fonctionnement.
Je pense que nous pourrons utiliser:
>8 entrées avec chacune reliée à un détecteur (diode, comparateur,...) (PIN 4 5 6 7 8 9 10 11 12)
>1 entrée dédiée à la détection du CUTOUT RAILCOM (PIN3 =INT1 ?))
>1 entrée et 1 sortie pour le LOCONET ( sur base Arcomora (mais impose de déplacer certaine PIN d entrée) ou déplacé vers les A0 AX à déclarer en entrée sortie digitale)
>1 entrée pour le signal DCC ( via Optocoupleur?) (PIN2 = INT0 ?)
Ensuite il faut intégrer une partie de code capable d'interpréter RAILCOM adresse 1 (à minima) puis adresse 2 (factultatif) ? ( une librairie RAILCOM?) (la librairie LOCONET sait elle deja interpréter ces signaux?, faut il tout créer ?)
Combiner cela avec une adresse de block pour la gestion des dectections de zone ( y compris pour le decodeurs non "RAILCOMable" ou avec un RAILCOM DESACTIVE.
Intégrer celle du LOCONET (et des autres procol de sortie possible XPRESSNET, CAN? autres?)
Pas mal de boulot donc.
Pour ce qui est des décodeurs des locomotives:
la plus part des décodeurs récents à diffusion majoritaire dans l' hexagone ( ESU, LENZ, ZIMO) sont compatibles RAILCOM (depuis environ 2010). (ils constituent la majeur partie des parcs installés hors MARKLIN)
Les LAISDCC ne le sont pas.
Les Doehler & Haass doivent l'etre ( à confirmer)
Uhlenbrock doivent l'etre également ( à confirmer selon modèle)
...
Donc massivement un parc très large.
Pour les autres marques... à voir au cas par cas. Mais pour moi pas de "faux" débat sur la compatibilité RAILCOM.
Laurent
-
Cette discussion est tres interessante, mais il serait bien de situer une telle realisation dans le contexte du systeme global.
Si c'est pour realiser un equivalent du DR5088, ou est l'economie, a part le plaisir de realiser soi-meme ?
Bienvenue a celle ou celui qui partagerait un tel projet.
Quelle centrale DCC ? Pourquoi pas une realisation a base de DCC++ ou la bibliotheque DCCpp ?
Mettre des detecteurs Railcom partout ? Pourquoi pas du NFC/RFID ?
Loconet ou Xpressnet sont-ils indispensables ? Pourquoi pas le Can ?
Quel gestionnaire de reseau ?
Evidemment cela a tout son sens si l'acquisition de tous ces produits du commerce est irreversible !
Sinon, que pensez-vous de l'approche que nous avons publie aujourd'hui ?
http://www.locoduino.org/spip.php?article242 (http://www.locoduino.org/spip.php?article242)
Votre avis m'interesse ;D
Ps : desole pour les problemes d'accents : indem...dable sur iPhone :(
-
Bonsoir
Enjeux du projet au niveau global:
Disposer d'un décodeur capable de décoder RAILCOM sur des zones occupées et de transmettre cette information vers un système central par un protocole standard. ( avec exploitation par logiciel des informations remontées) ( et s'il y a moyen d afficher l'info en option sur un LCD, on prend!)
Oui un "clone like" du DR5088 mais avec moins d'entrées et si on peut du coup avoir un tarif plus bas, et "homemade" alors le jeu en vaut plus que la chandelle.
De plus je souhaite également distribuer les deux pôles du signal DCC aux rails et réduire la diaphonie. ( ce que ne permet pas un DR5088 nativement)
Par ailleurs et pour ce qui me concerne je trouve que la limitation à 3A par module est "un peu basse" et je préfère voir à pouvoir distribuer "plus" et donc mieux. ( 3A par zone OK mais avec plusieurs zones capables de pouvoir "encaisser" plus.
Voila qui "borne" le cahier des charges global avant d'affiner.
Comme tu le signales tout est "ouvert" donc on doit aussi pouvoir permettre certaines pistes de sorties possibles ( choix d un protocole avec un hard dédié?... etc)
A ce stade cela me semble "plus universel" dans la mise en œuvre que le projet de RFID qui demande des équipements spécifiques.
La toute personne qui est en S88 par exemple pourrait modifier facilement son câblage en remplaçant son détecteur d'occupation par le nouveau et "en avant la musique..."
Y a plus qu a! :)
Laurent
-
Donc le cahier des charges étant posé, la question est : Qui pourrait contribuer à sa réalisation ?
Laurent, comme tu connais bien le sujet, peux tu alimenter techniquement ce sujet à partir des schémas existants de "détecteurs" Railcom ?
En Arduino bien-sur ;)
J'en profite pour corriger la terminologie et eviter toute confusion :
- le terme "décodeur" reste utilisé pour ce qui est placé dans la loco
- le terme "détecteur" sera utilisé pour ce qui est placé sous la voie (exactement à la place d'un détecteur d'occupation), bien qu'il soit vrai que ce "détecteur" comprenne 3 parties : un détecteur de présence, un "booster" qui va réaliser le cutout et un décodeur des signaux reçus de la loco. Ce qui nous intéresse, c'est l'ensemble.
Un lien ancien mais interessant :
https://www.locgeek.com/fr/2012/10/railcom-railcom-plus-kesako/ (https://www.locgeek.com/fr/2012/10/railcom-railcom-plus-kesako/)
et la norme :
https://www.nmra.org/sites/default/files/s-9.3.2_2012_12_10.pdf (https://www.nmra.org/sites/default/files/s-9.3.2_2012_12_10.pdf)
-
Y a plus qu a! :)
Laurent
... répondre à cette question :
Que pensez-vous de l'approche que nous avons publiée aujourd'hui ?
http://www.locoduino.org/spip.php?article242
Votre avis m'interesse ;D
-
Bonjour Laurent,
Je trouve vraiment très intéressant que tu ais ouvert un fil sur le sujet de Railcom. Ce faisant, tu abordes l’un des sujets qui concerne (en générale) les réseaux les plus aboutis et les plus automatisés, celui de l’identification des locomotives pour Railcom ou des locomotives et aussi des wagon pour le RFID dont il a été question un peu plus haut.
L’identification est le nec plus ultra car c’est grâce à elle que l’on peut arriver à un niveau élevé d’automatisation (et donc de sécurité) sur un réseau numérique.
Une fois n’est pas coutume, c’est en analogique que les choses sont plus faciles si l’on ne dispose pas d’identification, mais seulement de la détection d’un train anonyme. En effet, si le signal est au rouge à la fin d’un canton, on va progressivement ralentir la vitesse de la locomotive (par réduction du courant) jusqu’à détecter le passage sur un capteur qui va alors provoquer la coupure totale du courant sur ce canton et donc l’arrêt de la locomotive. Et cela fonctionne quel que soit la locomotive. Elle n’a pas besoin d’être identifiée, seulement détectée.
En numérique, il en va tout autrement puisque les commandes s’adressent à des locomotives bien spécifiques et il faut donc savoir à quelle locomotive on a affaire, on a donc besoin d’identification.
Alors, Railcom ou RFID ?
Comme c’est souvent le cas, il y a des plus et des moins avec chacun des deux systèmes :
Sans doute par ordre de priorité :
- Railcom nécessite des décodeurs qui « embarquent » cette technologie ». Comme tu le dis justement, cela concerne probablement 60 à 80 % des décodeurs mais c’est loin d’être universel et tout ce qui est Marklin ou Trix par exemple en est exclus et c’est loin d’être négligeable !!!
- Le RFID impose un équipement sous la voie qui est assez encombrant, ce qui n’est pas le cas de Railcom pour lequel l’équipement peut être déporté, au besoin sous la planche.
- Railcom communique le sens de roulement du train, ce que ne fait pas le RFID sauf à placer par exemple deux capteurs ponctuels de pars et d’autre et de voir lequel à détecter le train en premier.
- Le RFID nécessite de poser un badge sous chaque locomotive. Il en existe de très petit et très fins, mais certains modélistes sont totalement allergiques à l’idée de poser quoique ce soit sous leur locomotive. Railcom ne nécessite aucun équipement particulier si ce n’est la compatibilité du décodeur.
- Le RFID, mais cela reste à préciser, est probablement perturbé par la présence de métal à proximité. Or il est difficile de trouver des zones exemptes de métal sous une locomotive.
- Railcom n’identifie que des locomotives alors que le RFID peut aussi servir à identifier des wagons. Ceci est loin d’être anecdotique. En effet, Marcel (Catplus) par exemple cherche à connaître la composition de ses convois pour faire une gestion de parc. En RFID, la position de chaque wagon sur le réseau peut être connue. Cela peut aussi être utilisé pour s’assurer que des wagons ne se sont pas décrochés et prendre alors les mesures appropriées.
- Railcom ne se limite pas à fournir une identification de locomotive mais communique quelques autres informations comme par exemple la vitesse et la température du moteur.
Et pour rajouter à la confusion, précisons que pour certains puristes l’identification n’est pas nécessaire puisque les logiciels de gestion de réseaux savent parfaitement où sont chacune des locomotives. Mais bon, ça c’est la théorie.
Aux vues de ces quelques précisions, chacun pourra déterminer quelle technologie lui semble la plus appropriée pour son propre cas. L’une ne supplante pas l’autre. Et quant à savoir si ça doit fonctionner en Loconet ou en CAN, tout cela n’est somme toute que du détail. A nous d’être assez malin pour rendre cela le plus universel possible.
Pour moi qui suis plutôt curieux, j’aimerais bien sûr tester l’une et l’autre puisque les fonctions remplies et les contraintes ne sont pas les mêmes. Et puis, cela me fera de nouvelles techniques d’identifications puisque j’utilise déjà, et avec succès, l’identification par code barre dont a peu parlé mais qui dans certaines conditions rend de bons et loyaux services. (A la disposition de ceux que ça intéresse pour développer)
Donc Laurent, bien sûr qu’il faut que tu poursuives tes recherches et que tu n’hésites pas au besoin à demander de l’aide. Me concernant, je ne peux guère t’aider que sur la programmation mais il y en a pas mal d’autres qui maitrisent aussi très bien l’électronique. Personnellement, je trouve qu’il serait tout à fait gratifiant de pouvoir proposer une solution Railcom DIY sur Locoduino.
-
Dominique
Dire que je connais bien le sujet est un peu excessif. :)
Disons que j'ai "analysé" le concept et que je sais le restituer en termes de besoins en "vulgarisant" les notions.
J ai surtout l"envie d aboutir sur un truc "maison" qui "fasse le job".
Je sais dessiner des PCB, les monter mais coté ARDUINO sic... suis bien trop novice pour "pondre" le code qui va bien.
Je viens de jeter un œil à DCC++/DCCpp dont je ne connaissais que de nom.
Il semble que l’intégration RAILCOM soit inclue à présent mais semble très récent (OCT 2018). ( d après le lien ci dessous)
http://pgahtow.de/wiki/index.php?title=DCC (http://pgahtow.de/wiki/index.php?title=DCC)
Est ce que cela signifie que l ont peut se baser sur la bibliothèque en question pour appeler des fonctions sur nos besoins RAILCOM sur nos ARDUINO?
ensuite comment sortir l info vers une centrale "standard" ou autre par exploitation par un logiciel?
Des élements de réponse ici déja fort bien structurés
http://pgahtow.de/wiki/index.php?title=Zentrale (http://pgahtow.de/wiki/index.php?title=Zentrale)
En poursuivant mes recherches sur le mot clé RAILCOM j ai trouvé ceci coté JMRI:
http://jmri.org/JavaDoc/doc/index.html?jmri/RailCom.html (http://jmri.org/JavaDoc/doc/index.html?jmri/RailCom.html)
ou on "capte" pas mal de petites choses aussi. Au moins dans la structuration.
Je pose les bases et on 'travaille ensemble sur le sujet.
Voila deja un petit dessin issu de la norme pour le détecteur. C'est une version de travail d'un double détecteur... ( 2zones donc issu du dessin de la nome NMRA 9.3.2)
Sur un 10x10 j en fait tenir 4 en 2 couches mais avec des ponts externes qui disparaissent sur un 4 couches.
connecteur J/K pour le signal DCC au pas de 5.08 en entrée et sortie pour aller sur un autre point de distribution. Jx et Kx de chaque zone détectée. Sx Sx+1 sont les poles a envoyer vers l arduino. les autres points peuvent permettre de traiter l alimentation de manière centrale ou via J/K.
(http://)
-
Je viens de jeter un à DCC++/DCCpp dont je ne connaissais que de nom.
Il semble que l'intégration RAILCOM soit inclue à présent...
Laurent, le lien que tu donnes ne concerne pas DCC++ mais un autre programme qui utilise la bibliothèque "DCCPacket" (et dérivés) qui, du moins jusqu'à l'arrivée de DCC++, était moins performante et que nous avons abandonnée de ce fait au profit de DCC++
-
Pour illustration le détecteur X4 pour 8 zones:
(http://)
Toujours une version de travail cette fois en X4 Détecteur et en 4 couches pour économiser des connecteurs
-
Hello Boby
Donc si DCC++ est "up to date" il inclu probablement ce qu il faut à présent?
Je dois poursuivre mes approfondissements...
Pour ce qui est des ambitions je "limite" pour le moment le besoin à ce périmètre:
>La réalisation d un DÉTECTEUR d'occupation compatible RAILCOM via ARDUINO/AMTEGA328. Il aura pour but d'exploiter les info RAILCOM des décodeurs qui en sont pourvus et de simplement traiter l'occupation des zones pour les engins/équipements qui en sont dépourvus.
>Ce détecteur communiquera avec les centrales via un protocole normalisé ( pouvant etre différents selon les versions réalisées)
>Les informations pourront être exploitées par les logiciels type RRTC, ROCRAIL, ... ou custom qui savent exploiter RAILCOM.
-
Quel est l’interêt de réunir 8 détecteurs Railcom sur une seule carte alors que physiquement ils concernent des sections de rail de la taille d’un canton distants typiquement de 1m sauf dans des zones très denses ?
-
Donc si DCC++ est "up to date" il inclu probablement ce qu il faut à présent?
Non justement, et c'est ce que je voulais te dire, il ne s'agit pas de DCC++ dans le lien que tu donnes. Maintenant, ce n'est pas forcement très grave car en s'inspirant de ce programme, il sera sans doute possible de modifier DCC++.
Selon moi, le plus important et de "lire" un signal en sortie de l'électronique que tu proposes. Interpréter ce signal ne sera certainement pas le plus compliqué.
Par contre, il faut programmer pour que le DCC puisse générer les conditions du "cutout", c'est forcement réalisable mais il faut chercher.
Par ailleurs, je rejoins Jean-Luc sur le post qu'il vient d'envoyer. Je crois qu'il faut que tu cherches à "coller" au concept de Satellite dont on vient de publier le premier article. Cela revient à limiter à un ou deux détecteurs sur un espace donné plutôt que ce qui ce fait traditionnellement d'appareils spécialisés qui nécessitent de multiplier les câbles puisque par principe, ils vont être relativement éloignés des zones sous leur contrôle.
-
Un PCB de 5x5 coute à produire la même chose qu'un PCB de 10x10... donc un 10x10 avec 4x2 détecteurs est " économiquement plus intéressant. ( et usage des composants SMD)
Après on peut se contenter d un détecteur double sur 5x5 mais il faudra alors faire courir le signal vers l Arduino...
L intérêt du 10x10 comme premier niveau permet de glisser sur un second niveau l'Arduino ou un PCB contenant l ATMEGA328.
J'ai "redessiné" un "ARLOCO" selon cette méthode pour le rendre compatible avec mes détecteurs d'occupation qui eux encaissent 5A sans soucis par zone.
J ai extrait l ARDUINO pour y glisser directement un ATMEGA328 avec son quartz et son circuit de Reset.
Les PCB sont au tirage ( comme d autres d'on on parlera très bientôt :) )et seront la le mois prochain.
Je mettrai des photo dans une rubrique dédiée.
Laurent
-
Hello
Le CUTOUT est disponible sur les Centrales du commerce ( LENZ, ESU, ZIMO,...)
On trouve des boosters qui le sont également.
Pour moi le plus connu est celui de PACO que j ai bien sur déjà réalisé et "un peu" améliorer pour du 5A sur un PCB maison.
lien du BOOSTER de PACO:
http://usuaris.tinet.cat/fmco/railcom_en.html (http://usuaris.tinet.cat/fmco/railcom_en.html)
Photo ci jointe.
-
Non. Un PCB 5x5 revient 4 fois moins cher qu’un 10x10 : J’ai une scie proxxon et je découpe.
Et puis chez seeed par exemple la découpe de designs identiques est gratuite.
http://support.seeedstudio.com/knowledgebase/articles/388503-what-are-the-pcb-panelization-rules
De toutes manières, le coût du PCB est très minoritaire dans le coût total de la carte.
-
Le CUTOUT est disponible sur les Centrales du commerce ( LENZ, ESU, ZIMO,...)
Oui bien sûr mais justement, ce que l'on veut, c'est "contourner" les produits "du commerce" (souvent peu équitable;-).
Maintenant, que tu me dises que des boosters (dont d'ailleurs je crois que tu parles plutôt de cartes moteurs) puisse générer le "CUTOUT", je suis plus que septique !!! Le "COUTOUT" ne peut selon moi être généré que de manière logicielle mais peut-être que je me trompe et si ce que tu dis est exact, ça simplifirait pas mal de choses. Es-tu sûr de ce que tu avances ?
-
Autant pour moi, je vois en effet sur le site de PACO qu'il présente bien un "booster" dont il dit qu'il génère le "CUTOUT". Un problème de moins à régler donc, d'autant que si tu as réalisé une version 5A, contre 2,9 dans son cas. A première vue, on dirait bien que c'est un LMD18200 d'ailleurs.
Tout ceci est très encourageant !
-
Je disais plus haut que Railcom ne permettait que l'identification des locomotives (équipées de décodeurs compatibles Railcom) Mais après recherches, il existe cette offre commerciale de Lenz pour placer dans des wagons : http://www.lenzusa.com/1newsite1/LRC100.html (http://www.lenzusa.com/1newsite1/LRC100.html)
à 69,90 € la pièce tout de même : https://www.jura-modelisme.fr/accueil/30621-decodeur-digital-plus-le0521.html (https://www.jura-modelisme.fr/accueil/30621-decodeur-digital-plus-le0521.html)
Mais tout ceci nous éloigne du DIY et nous coute un bras à chaque fois !
-
Là encore après recherche, la norme NMRA (S-9.3.2) au chapitre 2.1 précise que le CUTOUT peut être fait soit avec la carte moteur, soit avec un dispositif externe : On peut donc aussi programmer le logiciel qui code les trames DCC permettant ainsi d'utiliser une carte moteur "standard".
The information flow in a DCC system normally takes place from the command station to the power station (booster) to the decoders by means of the track. The reverse transmission of information from the decoder requires the interruption of power and this data stream. This interruption is occurs via the boosters that produce a so-called RailCom cutout, at the end of each DCC packet, by disconnecting the two TRACK wires from the voltage supply and shorting them.
This function group inside the boosters is called a cutout device. Such a cutout device could also be executed as a separate entity outside of the booster. The actual data transfer occurs by means of a current loop. The decoder must provide the necessary current for the transfer from its internal cache. Figure 1 shows the arrangement of booster, detector, and decoder during the RailComcutout.
-
Bonjour à tous,
10 contributions de plus sur ce sujet et je n’y comprends plus rien !
1) S’agit-il de coder le 328 qui se trouve sur la carte de Laurent, dont on n’a toujours pas vu le schéma ?
2) quelles fonctions embarque cette carte sachant qu’il y en 3 pour Railcom (détection de présence, booster pour le cutout et réception des messages). Je ne vois pas les triacs de commutation.
La encore les schémas sont nécessaires.
3) comment s’inscrirait ce projet dans le positionnement que nous venons de publier ? J’ai mis le lien 2 fois et pas de réponse !
En particulier cette carte devrait être compatible avec un détecteur de présence par consommation de courant qu’elle remplace. Ou une carte de détection RFID. Comment la concevoir dans le concept de satellite ?
4) est-ce que cette carte DOIT s’interfacer avec une centrale du commerce, des logiciels de gestion du commerce et des décodeurs de loco compatibles Railcom dont tout le monde n’est pas equipé ? (et combien de modélistes le sont vraiment ?) Auquel cas la petite économie réalisée sur la carte est très largement détruite par les coûts des autres équipements.
Merci d’eclaircir ces points.
Amicalement
Dominique
-
J’interprète la proposition de Laurent comme étant une solution parmi d’autres pour l’identification de locomotives sur des sections du réseau (canton).
Pour fonctionner, il faut tout d’abord générer le CUTOUT, soit de manière logicielle (modification des trames DCC dans DCC++ par exemple) soit avec une carte moteur (booster) qui génère elle-même le CUTOUT. Pour cette dernière hypothèse, Laurent dit avoir réalisé la carte qui va bien (en se basant sur la carte publiée par PACO et dont il donne le lien). Donc de ce côté-là, tout semble donc réuni pour que ça fonctionne.
Côté rétro signalisation, il s’agit d’une carte que PACO appelle RailComDisplay et que Laurent se propose de réaliser et que lui appelle Small Detecteur RAILCOM.
Je dirais qu’il s’agit donc d’un détecteur comme un autre sauf que bien sûr, il s’agit non pas d’un signal binaire mais, si j’ai bien suivi, d’un signal codé sur 8 bits.
2) quelles fonctions embarque cette carte sachant qu’il y en 3 pour Railcom (détection de présence, booster pour le cutout et réception des messages).
Dès lors, dans le concept de satellite par exemple, on peut très bien imaginer que ce message « remonte » par le bus CAN exactement comme cela devrait se produire s’il s’agit d’un message reçu d’un capteur RFID.
Cette carte peut remplacer un capteur par consommation car elle détecte la présence sur tout le canton (alors que le RFID dans un rôle de capteur est un capteur ponctuel).
4) est-ce que cette carte DOIT s’interfacer avec une centrale du commerce, des logiciels de gestion du commerce et des décodeurs de loco compatibles Railcom dont tout le monde n’est pas equipé ? (et combien de modélistes le sont vraiment ?) Auquel cas la petite économie réalisée sur la carte est très largement détruite par les coûts des autres équipements.
Ceci n’est pas le problème ici, c’est à chacun de « gérer » le message transmis par RailComDisplay. Pour nous, dans le concept de satellite, on se retrouvera avec une problématique de codage de message tout à fait similaire à ce qu’elle va être pour le RFID.
Je ne crois pas que « penser Satellite » veille dire système de détection unique ou identification unique !
Tout comme la détection ponctuelle peut être assurée avec des capteurs à effet Hall, des ISL ou de IR…, l’identification doit pouvoir être possible avec plusieurs systèmes. A charge du détecteur de coder son message au format que nous avons défini. J’ai moi-même dit que j’avais testé l’identification par lecture de codes barres sous les locos. Il est également intéressant de pouvoir si on le souhaite utiliser cette technique, non ?
des décodeurs de loco compatibles Railcom dont tout le monde n’est pas equipé ? (et combien de modélistes le sont vraiment ?) Auquel cas la petite économie réalisée sur la carte est très largement détruite par les coûts des autres équipements.
Je répète, une technique n'est pas exclusive d'une autre, à chacun de choisir et probablement de mixer les deux (s'il le souhaite et s'il le peut) selon ses besoins et chaque cas particulier rencontré sur son réseau. Moi j'ai 60 à 70 % de mes locos qui sont compatibles Railcom dont je n'ai aucun surcout de ce côté là ! Mais inévitablement, autant le RFID est probablement universel, autant Railcom ne l'est pas.
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 ???
-
Bonjour,
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)
Par ailleurs l’électronique des détecteurs Railcom (dont on n’a pas vu le schéma, le typon ne m’intéresse pas) serait sans doute plus simple si ils n’avaient pas à détecter le CUTOUT. Dans notre contexte, à savoir le Satellite V2, l’information « CUTOUT en cours » peut être diffusée sur le CAN par la centrale.
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.
-
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.
-
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 !
-
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.
-
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/ (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
-
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 8) ( 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.
-
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 (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 :D ::) 8)).
Ç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
-
Voila une petite synthèse vite faite :)
-
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
-
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.
-
Je tente de m'accrocher, mais pour illustrer le cutout (je découvre comment Railcom fonctionne) le dessin du site de Paco est clair :
-
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
-
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.
-
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 ?
-
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
-
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
-
Hello
Le 1er tirage de la section DETECTION est lancé (10x10 en 4 couches) pouvant traiter jusqu à 8 zones.
Plus qu'à attendre leur arrivee dans 1 mois...
Ça va être long! 8)
Laurent.
-
Bonjour
PCB recus ce jour
En attente des composants manquant pour assemblage...
Laurent
-
Petite vue de la carte
-
Bonjour
Le 1 er CI est en cours de montage ( encore quelques références à recevoir pour achever le 1er détecteur ( de 2 zones) avant de passer à la suite...)
Aperçu du montage en cours . Pas de complication, ça se monte "tranquille"! :)
A bientôt pour la suite!
Laurent.
-
Bonjour
Afin de passer à la "phase 2" et de commencer d éventuels dessins, pourriez vous m indiquer vers quelles broches de l arduino/ATMEGA 328P nous ferons remonter les info? ( les digital in de base + les Ana A0 A6 en entree digital?...?
Si nous interfaçons aussi en sortie une /des interfaces type CAN ou LOCONET... qui de celle a dédier à ces fonctions et donc établir la "bonne répartition"?
Cdt
Laurent