586
Vos projets / Re : Barette eclairage avec decodeur integre sur base ARDUINO/328
« le: janvier 26, 2019, 01:28:28 pm »
autres vues
L'Arduino pour le train miniature
Nouvelles:
Le forum LOCODUINO est consacré aux discussions ayant trait à l'utilisation de l'Arduino dans les automatismes et les animations pour le train miniature. Nous avons eu récemment quelques inscriptions de personnes ayant des projets plus généraux mais surtout inapplicables au train miniature. Si votre projet ou vos questions ne concernent pas le modélisme ferroviaire, ne vous inscrivez pas, vous perdriez votre temps et nous aussi.
Voir les contributions
Cette section vous permet de consulter les contributions (messages, sujets et fichiers joints) d'un utilisateur. Vous ne pourrez voir que les contributions des zones auxquelles vous avez accès.
587
Vos projets / Re : Barette eclairage avec decodeur integre sur base ARDUINO/328
« le: janvier 26, 2019, 01:27:22 pm »
photo de dos
588
Vos projets / Barette eclairage avec decodeur integre sur base ARDUINO/328
« le: janvier 26, 2019, 01:26:52 pm »
Bonjour
Sur la base de l excellent travail réalise par Geoff Bunza
disponible à cette adresse:
https://model-railroad-hobbyist.com/node/24316
J ai eu l idée de reprendre et d'adapter le tout à une réalisation "universelle" dédiée à un éclairage pour véhicules.
J ai choisi de commencer par la réalisation de 2 barrettes dédiées aux VU ROCO: l A9c9ux et le chaudrons commun des A11,B11, B10c10ux.
Les bases sont très proches et la partie alimentation est modulaire. Garantie "anti chauffe" par un convertisseur "BUCK" DC to DC.
L Arduino étant "trop gros" je suis parti sur l'utilisation direct du 328P dans sa version la plus petite ( ca se soude bien!)
Reste encore à finaliser!
Quelques composants sont encore à recevoir ( et PCB dédié à la programmation du chip) ainsi que l’adaptation du code pour ajouter quelques fonctions spécifiques:
>gestion "aléatoire" de l'activation de l'allumage des différentes LED ( avec choix de celles à considérer)
>Optimisation du chargement du croquis dans le chip...
Pour ceux qui voudraient s y essayer aussi j ai des PCB de dispo... à monter bien sur!
Sur la base de l excellent travail réalise par Geoff Bunza
disponible à cette adresse:
https://model-railroad-hobbyist.com/node/24316
J ai eu l idée de reprendre et d'adapter le tout à une réalisation "universelle" dédiée à un éclairage pour véhicules.
J ai choisi de commencer par la réalisation de 2 barrettes dédiées aux VU ROCO: l A9c9ux et le chaudrons commun des A11,B11, B10c10ux.
Les bases sont très proches et la partie alimentation est modulaire. Garantie "anti chauffe" par un convertisseur "BUCK" DC to DC.
L Arduino étant "trop gros" je suis parti sur l'utilisation direct du 328P dans sa version la plus petite ( ca se soude bien!)
Reste encore à finaliser!
Quelques composants sont encore à recevoir ( et PCB dédié à la programmation du chip) ainsi que l’adaptation du code pour ajouter quelques fonctions spécifiques:
>gestion "aléatoire" de l'activation de l'allumage des différentes LED ( avec choix de celles à considérer)
>Optimisation du chargement du croquis dans le chip...
Pour ceux qui voudraient s y essayer aussi j ai des PCB de dispo... à monter bien sur!
589
Vos projets / Re : Decodeur d'occupation compatible RAILCOM
« le: janvier 23, 2019, 10:34:55 pm »
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!
Laurent.
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!
Laurent.
590
Vos projets / Re : Decodeur d'occupation compatible RAILCOM
« le: janvier 22, 2019, 06:15:54 pm »
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
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
591
Vos projets / Re : Decodeur d'occupation compatible RAILCOM
« le: janvier 21, 2019, 11:27:04 pm »
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
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
592
Vos projets / Re : Decodeur d'occupation compatible RAILCOM
« le: janvier 20, 2019, 04:15:04 pm »
Voila une petite synthèse vite faite 
593
Vos projets / Re : Decodeur d'occupation compatible RAILCOM
« le: janvier 20, 2019, 03:25:30 pm »
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.
(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.
594
Vos projets / Re : Decodeur d'occupation compatible RAILCOM
« le: janvier 20, 2019, 03:06:42 pm »
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
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
595
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.
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.
596
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
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
597
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.
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.
598
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
Toujours une version de travail cette fois en X4 Détecteur et en 4 couches pour économiser des connecteurs
599
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.
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.
600
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
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