Messages

16

Vos projets / Re : Re : Decodeur d'occupation compatible RAILCOM

« le: janvier 22, 2019, 09:13:05 am »

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 ?

17

Vos projets / Re : Decodeur d'occupation compatible RAILCOM

« le: janvier 22, 2019, 09:10:20 am »

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.

18

Présentez vous ! / Re : Bonjour à tous les membres

« le: janvier 20, 2019, 10:22:56 pm »

Bienvenue Remi sur Locoduino.

Et bonne annee 2019 

Cordialement
Dominique

19

Vos projets / Re : Re : Decodeur d'occupation compatible RAILCOM

« le: janvier 20, 2019, 06:03:40 pm »

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.

20

Vos projets / Re : Decodeur d'occupation compatible RAILCOM

« le: janvier 20, 2019, 03:40:37 pm »

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

21

Vos projets / Re : Decodeur d'occupation compatible RAILCOM

« le: janvier 20, 2019, 11:18:00 am »

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.

22

Vos projets / Re : Re : Decodeur d'occupation compatible RAILCOM

« le: janvier 20, 2019, 10:46:16 am »

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.

23

Vos projets / Re : Decodeur d'occupation compatible RAILCOM

« le: janvier 20, 2019, 09:21:34 am »

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

24

Vos projets / Re : Re : Decodeur d'occupation compatible RAILCOM

« le: janvier 19, 2019, 09:10:31 pm »

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 

25

Vos projets / Re : Detecteurs d'occupation compatible RAILCOM

« le: janvier 19, 2019, 09:07:59 pm »

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/

et la norme :
https://www.nmra.org/sites/default/files/s-9.3.2_2012_12_10.pdf

26

Vos projets / Re : Decodeur d'occupation compatible RAILCOM

« le: janvier 19, 2019, 05:30:53 pm »

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

Votre avis m'interesse 

Ps : desole pour les problemes d'accents : indem...dable sur iPhone

27

Vos projets / Re : Re : Decodeur d'occupation compatible RAILCOM

« le: janvier 18, 2019, 10:11:23 pm »

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

28

Les réseaux / Re : Projet Dominique

« le: janvier 15, 2019, 05:35:49 pm »

Voilà plein de bonnes idées pour un futur article sur les encodeurs ...

29

Les réseaux / Re : Projet Dominique

« le: janvier 15, 2019, 08:49:39 am »

Oui mais c’est déjà mon arrêt d’urgence (vitesse à 0 et arrêt DCC).

30

Les réseaux / Re : Projet Dominique

« le: janvier 14, 2019, 09:02:20 pm »

Avec les evolutions de mon va-et-vient automatique, j’ai ajoute une commande manuelle avec l’encodeur, de telle sorte que le passage par zero entraine un changement de sens.

Je me rends compte qu’il faudrait un retour rapide a zero sans le depasser pour eviter un arret d’urgence qui n’est pas realiste.