Messages

571

Vos projets / Re : Decodeur d'occupation compatible RAILCOM

« le: janvier 19, 2019, 11:34:18 pm »

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

Photo ci jointe.

572

Vos projets / Re : Decodeur d'occupation compatible RAILCOM

« le: janvier 19, 2019, 11:27:12 pm »

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

573

Vos projets / Re : Decodeur d'occupation compatible RAILCOM

« le: janvier 19, 2019, 11:07:14 pm »

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.

574

Vos projets / Re : Decodeur d'occupation compatible RAILCOM

« le: janvier 19, 2019, 11:00:27 pm »

Pour illustration le détecteur X4 pour 8 zones:



Toujours une version de travail cette fois en X4 Détecteur et en 4 couches pour économiser des connecteurs

575

Vos projets / Re : Decodeur d'occupation compatible RAILCOM

« le: janvier 19, 2019, 10:45:24 pm »

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

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

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

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.

576

Vos projets / Re : Decodeur d'occupation compatible RAILCOM

« le: janvier 19, 2019, 08:01:19 pm »

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

577

Vos projets / Re : Decodeur d'occupation compatible RAILCOM

« le: janvier 19, 2019, 03:38:23 pm »

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

578

Vos projets / Re : Decodeur d'occupation compatible RAILCOM

« le: janvier 18, 2019, 01:03:10 pm »

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

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/

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

579

Vos projets / Re : Decodeur d'occupation compatible RAILCOM

« le: janvier 18, 2019, 08:46:29 am »

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.

580

Vos projets / Decodeur d'occupation compatible RAILCOM

« 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


Une tres belle approche est donnée ici: ( en anglais)

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

581

Bus CAN / Re : BUS CAN et ECOS/CS1 MS1

« le: septembre 12, 2018, 11:20:42 am »

Bonjour

On va dire que c est une base qui ouvrirait la porte a des éléments custom qui pourrait exploiter cette interface...

A creuser plus avant en effet mais surement un piste sympa....
Le document étant de 2009 il y a peut etre eux quelques évolutions mais la base a du rester la même.

Apres est on en capcaite de se connecter dessus et d exploiter.... c est autre chose.
ex un BOOSTER sur l ECOS ESU est relié par le bus ECOS LINK ( = bus CAN ESU) ==> des lors sait on grâce aux info exposées fabriquer un BOOSTER maison et le "linker" via le bus en question?
Quid ensuite des autres élements ( detection avec remontee info occupation ( genre railcom,)...

Bref de beaux sujets à explorer collectivement même si je sais que les priorités sont pour le moment situées ailleurs avec comme point d orgue Orléans 2018...

Laurent

582

Shields et Modules / Re : Carte Servomoteurs DCC + CAN

« le: septembre 11, 2018, 05:01:19 pm »

Bonjour

Non RRTC ne propose pas (encore) de prise en charge ( native ou via interface dédiée/particulière)  d une interface CAN. Cela fait parti de developpements à venir ( un jour, peut être?!, mais déjà en cours pour intégrer ces éléments via les centrales les plus rependues qui en disposent ZIMO/ESU)
Mais quel CAN sera retenu?

• ROCO/ZIMO
  ESU
  CAN autre? ( type MERG?, autre?)
  Tous?

Mystere!...

Yes we CAN.... certes mais... tout n est pas encore gagné!
Cela dit c est peut etre l'avenir?...
Pour le moment hors ZIMO  et ESU (niveau indistrielle) en développement propriétaire sur leur BUS de communication CAN c'est plutôt desert. ( et fermé?!)
A chaque fois une centrale type DCC avec CAN bus sert de passerelle.( MX1, Z21, ECOS...) et les logicelles passe par cette paserelle.

Si des alternatives apparaissent et enrichissent l'offre cela sera intéressant. (et prometteur)

Laurent

583

Shields et Modules / Re : Carte Servomoteurs DCC + CAN

« le: septembre 11, 2018, 01:52:09 pm »

Bonjour

J ai quelques questions un peu "basiques" vous voudrez bien m'en excusez!

Est il possible de "modifier" pour avoir 4 AIG ET 4 relais dédies chacun à la polarisation de la pointe de cœur ( peut être la carte satellite aura cette possibilité?)
En effet, les servo c est bien, avec la polarisation des cœurs C EST BEAUCOUP MIEUX! (tout projet confondu!!)

Lorsque vous parlez de commande via le protocole CAN je n'ai pas identifié par quelle "magie" vous l'interfacez ( quelle interface, quelle déclaration dans le logiciel? aller au hazard avec un logiciel comme RRTC, par exemple...)

D avance merci pour vos reponses.

584

Bus CAN / BUS CAN et ECOS/CS1 MS1

« le: septembre 11, 2018, 01:05:59 pm »

Bonjour

ESU a implémenté sur l ECOS la CS1 et la MS1 MARKLIN un protocol CAN "custom".

Il semble peu documenté pour pouvoir s'interfacer dessus!

J ai toutefois trouvé ceci:

http://www.skrauss.de/modellbahn/CAN_Doku_V101.pdf

Est ce que cela ouvrirait la porte à des DEV custom à base de nos Arduino pour exploiter le dit bus directement?

Le document est un peu ancien mais doit encore être bien d actualité... et peu tetre toujours bien valable pour l ECOS ( version actuelle)

Merci de vos avis...

Laurent

585

Vos projets / Re : Tableau de commande optique FBO

« le: février 09, 2018, 11:36:29 pm »

Bonsoir Jean Luc

effectivement tu as mener des pistes très avancées sur le sujet qui vont bien au delà de la "modeste "réalisation que je vise!
Pour quoi pas dans une phase 2 gérer la colorisation selon l état...

Mais je voudrais d abord me concentrer sur l' aspect DISPLAY et encodage paramètre dans un premier temps.. et bien sur sous XPRESSNET!...


J espère recevoir l aide qui me manque sur différents sujets.

Cdt
Laurent