Messages

886

Vos projets / Re : Un TCO interactif sur votre navigateur WEB et relié au bus CAN du réseau

« le: janvier 31, 2019, 08:42:04 am »

Pour le programme, voici le voici. Je voulais m'y replonger car il y a surement moyen d'optimiser encore.

Le code est disponible sur le github de Locoduino : https://github.com/Locoduino/CanGateway_ESP8266

887

Vos projets / Re : Un TCO interactif sur votre navigateur WEB et relié au bus CAN du réseau

« le: janvier 31, 2019, 08:35:20 am »

Le schéma complet de la carte, je ne l'ai pas fait mais MCP et Node MCU voici, pour le reste ce ne sont que des convertisseurs de tension :

888

Vos projets / Re : Un TCO interactif sur votre navigateur WEB et relié au bus CAN du réseau

« le: janvier 31, 2019, 08:28:46 am »

C'est ce que j'ai fait :

889

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

« le: janvier 30, 2019, 11:43:43 pm »

Salut breizhou,

Ne cherches plus ! Tu es tombé sur la bonne personne. Je suis en effet l'auteur ! Et mieux, j'ai effectivement développé la version WiFi que tu recherches. Contacte moi en MP et je vais te donner tout ce qu'il faut.

Plus de beurre que de mal donc !

890

Vos projets / Re : Decodeur d'occupation compatible RAILCOM

« le: janvier 22, 2019, 12:22:45 pm »

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

891

Vos projets / Re : Decodeur d'occupation compatible RAILCOM

« le: janvier 20, 2019, 04:22:34 pm »

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

892

Vos projets / Re : Decodeur d'occupation compatible RAILCOM

« le: janvier 20, 2019, 11:06:07 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)

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 !

893

Vos projets / Re : Decodeur d'occupation compatible RAILCOM

« le: janvier 20, 2019, 10:10:25 am »

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

894

Vos projets / Re : Decodeur d'occupation compatible RAILCOM

« le: janvier 20, 2019, 08:05:19 am »

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.

895

Vos projets / Re : Decodeur d'occupation compatible RAILCOM

« le: janvier 20, 2019, 12:33:45 am »

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

à 69,90 € la pièce tout de même : 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 !

896

Vos projets / Re : Decodeur d'occupation compatible RAILCOM

« le: janvier 19, 2019, 11:55:04 pm »

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 !

897

Vos projets / Re : Decodeur d'occupation compatible RAILCOM

« le: janvier 19, 2019, 11:43:22 pm »

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 ?

898

Vos projets / Re : Decodeur d'occupation compatible RAILCOM

« le: janvier 19, 2019, 11:25:40 pm »

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.

899

Vos projets / Re : Decodeur d'occupation compatible RAILCOM

« le: janvier 19, 2019, 10:55:56 pm »

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

900

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

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

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.