Messages

1366

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.

1367

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

1368

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 

1369

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

1370

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

1371

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

1372

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 ...

1373

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).

1374

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.

1375

Présentez vous ! / Re : Presentation

« le: janvier 14, 2019, 07:25:38 pm »

Bonjour Bruno,

Bienvenue sur Locoduino 

1376

Les réseaux / Re : Projet Dominique

« le: janvier 13, 2019, 09:07:05 pm »

Je pense que le mieux est de partir d'une bibliothèque existante qui utilise les interruptions.

Je viens de voir que PJRC vient d'en pousser une ces derniers jours :
https://github.com/PaulStoffregen/Encoder

Il me semble aussi que la question a probablement déjà des réponses. Je vais chercher avant de se lancer dans un boulot déjà  fait.

Tu as le temps de commander un encoder de ce type :
https://howtomechatronics.com/tutorials/arduino/rotary-encoder-works-use-arduino/
Ou
https://playground.arduino.cc/Main/RotaryEncoders
Ou
https://www.amazon.fr/Rotary-Encoder-Decoder-Module-Arduino/dp/B00Q6WP196

1377

Discussions ouvertes / Re : Re : Programmation : les closures

« le: janvier 13, 2019, 03:28:37 pm »

Par ailleurs, cela ne pose aucun problème d'écrire auto x = 4; plutôt que int x = 4;

Pour la lisibilité du code, je n'en suis pas persuadé, s'il faut que tu cherches ailleurs dans le code pour trouver le type probable.

1378

Les réseaux / Re : Projet Dominique

« le: janvier 13, 2019, 03:18:51 pm »

Quelqu'un se propose-t-il d'écrire une bibliothèque liées aux codeurs quadratiques, si elle n'existe pas ?

1379

Discussions ouvertes / Re : Programmation : les closures

« le: janvier 13, 2019, 03:16:17 pm »

Humblement, je concluerais qu'il ne vaut mieux pas se servir de "auto", source de confusion, voire de bugs. Non ?


PS : on dirait que les caractères accentués sont maintenant respectés ?

1380

Discussions ouvertes / Re : Programmation : les closures

« le: janvier 13, 2019, 12:10:29 pm »

Ca interroge, tu as raison :

Si, à l'initialisation, la variable de type "int" n'occupe que 2 octets et si, plus tard, elle est amenée à en occuper 4, alors il faut "pousser" de 2 octets toutes les variables suivantes (si ce sont des globales).

Je suppose que, dans ce cas, le compilateur analyse toutes les dimensions d'une variable auto pour lui affecter la plus grande taille.

De même, est-ce qu'un pointeur sur cette variable risque de changer en cours d'exécution ?