LOCODUINO
Discussions Générales => Discussions ouvertes => Discussion démarrée par: Dominique le décembre 28, 2021, 02:31:24 pm
-
Le volume 1 est sorti à la boutique LocoRevue https://trains.lrpresse.com/A-18252-arduino-faites-le-jouer-au-train.aspx (https://trains.lrpresse.com/A-18252-arduino-faites-le-jouer-au-train.aspx) (apparement plus disponible)
Le 1er livre de Pascal Barlier "Arduino: Faites-le jouer au train" décrivait une solution générateur DCC basée sur la bibliothèque Flexitimer. Avec le livre les sources sont téléchargeables sur GitHub.
C'est une approche différente (mais intéressante) de la génération du DCC, mais aussi d'autres fonctions sous interruption.
Une discussion avait démarré ici: https://forum.locoduino.org/index.php?topic=653.msg7419#msg7419 (https://forum.locoduino.org/index.php?topic=653.msg7419#msg7419)
Et maintenant le volume 2 est disponible à la boutique LRPresse et aux éditions ENI
https://trains.lrpresse.com/A-19641-arduino-faites-le-jouer-au-train-2e-edition.aspx (https://trains.lrpresse.com/A-19641-arduino-faites-le-jouer-au-train-2e-edition.aspx)
https://www.editions-eni.fr/livre/arduino-faites-le-jouer-au-train-2e-edition-9782409032455 (https://www.editions-eni.fr/livre/arduino-faites-le-jouer-au-train-2e-edition-9782409032455)
Les sources sont sur GitHub:
https://github.com/EditionsENI/Arduino-et-le-train (https://github.com/EditionsENI/Arduino-et-le-train)
Le dossier V1 concerne sans doute le premier livre et le dossier V2 le nouveau livre.
L'intérêt de ce projet, outre le fait qu'il est bien décrit et sur papier, est qu'il présente une solution complète de gestion de réseau avec la centrale DCC, les capteurs et actionneurs et le poste de commande centralisé donc un gestionnaire des circulations et une modélisation du réseau.
Autre avantage: les circuits imprimés sont fournis sous forme de fichiers Gerber, ainsi que les schémas et des photos.
J'ouvre ce sujet pour offrir une place de discussion à son auteur Pascal Barlier que nous accueillons bien volontiers pour présenter ses choix techniques.
-
Bonjour Dominique
Il n'aura fallu que quelques heures après notre discussion sur GitHub pour que je me retrouve ici. C'est assez inattendu, mais c'est aussi la suite logique ce que j'ai créé jusqu'à présent.
Je connais bien le site Locoduino, et j'y suis souvent venu, avant même l'écriture de la première version du livre. Il m'a permis d'obtenir des éclaircissements sur certains points obscurs, et il m'a aussi permis d'orienter mes développements lorsque plusieurs choix s'offraient à moi (je tiens à préciser que je n'ai jamais utilisé le contenu du site pour écrire le livre). Mais je n'ai jamais eu l'occasion de m'inscrire sur le forum puisque j'y ai toujours trouvé les réponses à mes questions sans avoir à les poser. Maintenant, c'est fait, je suis inscrit.
-
Écrire un livre est toujours un processus douloureux, mais il y a quand même de bons moments. Je dois avouer que c'est assez amusant de faire cohabiter dans le même livre le circuit SN7445, un bon vieux TTL des familles dont la datasheet de Texas Instruments date de 1972, et le TSC2012 qui date de 2019.
-
Bonjour Pascal,
Merci de venir sur Locoduino pour échanger avec nous.
Je n’ai pas encore acheté le volume 2 mais je vois dans les schémas et les photos sur GitHub les choix des composants, les modules et leurs interconnexions qui diffèrent de ce qu’on voit habituellement sur Locoduino parce que vous ne faites pas appel aux modules tout faits du commerce, clones ou pas.
Cela va apporter un éclairage différent et un élargissement des choix techniques dans notre passion d’électronicien.
Par exemple le TSC2012 pour les mesures de courant à la place du Max471 maintenant obsolète ou l’ACS712, ou le simple ampli-op. Cela s’explique par le fait que vous concevez vos modules en toute indépendance. Avez-vous pour cela une filière de production particulière (ou JLCPCB comme la plupart)?
Une autre différence est le choix du “tout I2C”, si je ne me trompe. L’I2C n’est pas le mieux adapté pour des distances importantes entres maîtres et esclaves, mais ça marche quand même. Beaucoup de modélistes trouveront justification de leurs choix similaire.
Personnellement j’ai opté pour le Can qui me semble être la voie de la sérénité absolue ;D
Je suis certain qu’on va en discuter.
Quand au livre, c’est très agréable de tenir en main toute la description du projet.. à un instant t !
J'ajouterai surtout qu'il permet d'avoir une vue d'ensemble de tous les composants d'un réseau ferroviaire (centrale, capteurs, actionneurs, postes de conduite, tableaux de commande, ..) avec une réalisation.
J’espère que les colonnes de Locoduino vous permettront de faire évoluer les contenus du livre, en attendant la version 3 peut-être ;D
En attendant il y a cette édition 2 à lire.
Cordialement
Dominique
-
Bonjour Dominique
Il n'aura fallu que quelques heures après notre discussion sur GitHub pour que je me retrouve ici. C'est assez inattendu, mais c'est aussi la suite logique ce que j'ai créé jusqu'à présent.
Bonjour Pascal,
A la sortie de ta version 1, je t'avais contacté pour que tu nous rejoignes chez Locoduino ; tu y as mis le temps, mais il n'est jamais trop tard et je me réjouis de te voir enfin parmi nous. :)
Je suppose que la version 2 apporte quelques nouveautés par rapport à la version 1, et si tu pouvais les lister brièvement sur ce forum, cela inciterait certains de nos lecteurs à se la procurer.
Encore une fois, bienvenue.
Christian
-
Par exemple le TSC2012 pour les mesures de courant
Mais je me trompe sans doute : est-ce bien dans une réalisation d'un décodeur Railcom ?
-
Par exemple le TSC2012 pour les mesures de courant à la place du Max471 maintenant obsolète ou l’ACS712, ou le simple ampli-op. Cela s’explique par le fait que vous concevez vos modules en toute indépendance. Avez-vous pour cela une filière de production particulière (ou JLCPCB comme la plupart)?
J'ai choisi le TSC2012 comme circuit d'interface du décodeur Railcom car il intègre une isolation galvanique, il n'est donc pas nécessaire de créer une alimentation volante, et il n'y a pas besoin d'optocoupleur pour l'interfacer avec un Arduino. Je dois avouer que j'ai eu beaucoup de chance de trouver ce circuit qui a aussi d'autres avantages : il est disponible et pas cher. C'est le gros avantage d'Internet, à force de chercher, on finir par trouver la perle rare. pour le TSC2012, c'est assez spécial, car c'est à l'origine un circuit de contrôle de charge/décharge de batterie. L'utiliser pour extraire le signal Railcom peut être considéré comme du "hacking" électronique, c'est ce qui m'amuse le plus.
Pour la filière de production, bien vu, c'est chez JCLPCB. Dans la première édition, je n'avais pratiquement pas proposé de circuit imprimé. Tout était à câbler à la main. Ce n'est pas idéal, j'ai eu beaucoup de mauvais contacts. J'ai toujours une certaine appréhension lorsqu'il s'agit de me former à un nouveau programme, surtout de CAO. J'avais essayé Fritzing, mais il ne m'a pas convaincu, j'ai tracé un circuit avec et le résultat m'a déçu. Par contre je suis pleinement satisfait de KiCad, sauf pour ce qui est de son ergonomie (je me trompe toujours entre le zoom et les scrollings, c'est énervant), mais son rendu est réellement professionnel.
-
Merci pour ces informations qui me seront très utiles: je n’ai pas encore intégré de décodeur Railcom et vous me donnez l’occasion de m’y mettre, pour comparer avec la RFID/NFC.
-
Une autre différence est le choix du “tout I2C”, si je ne me trompe. L’I2C n’est pas le mieux adapté pour des distances importantes entres maîtres et esclaves, mais ça marche quand même. Beaucoup de modélistes trouveront justification de leurs choix similaire.
Personnellement j’ai opté pour le Can qui me semble être la voie de la sérénité absolue ;D
Je suis certain qu’on va en discuter.
En effet, l'I²C est un choix. Après la sortie de la première édition, on m'a parlé de l'utilisation du bus CAN, alors je suis allé me documenter, je ne l'avais pas pris en compte car je pensais qu'il était surtout destiné au secteur automobile. En fait, je dois reconnaître que le bus CAN peut parfaitement convenir, mais je ne l'ai pas choisi pour les raisons suivantes :
- Le bus I²C est intégré au processeur Atmel des Arduino. Il ne nécessite pas d'interface supplémentaire et la librairie consomme très peu de ressources.
- Le bus CAN nécessite un shield supplémentaire pour chaque Arduino, ce qui augmente le coût. Le protocole CAN étant plus sophistiqué que l'I²C (ce qui n'est pas un défaut en soi), j'ai redouté que la consommation de ressources soit trop importante pour les petits Nano que j'utililisais.
J'ai donc choisi une voie différente en m'orientant vers des amplificateurs de bus I²C. J'ai d'abord trouvé le P82B715 grâce au site MC Hobby, mais il est frappé d'obsolescence. Le site NXP m'a permis de découvrir toute leur gamme d'amplificateurs I²C, et surtout celui que j'espérais, le PCA9615, qui a le très grand avantage de fonctionner en mode différentiel avec des terminaisons de bus, donc une grande tolérance aux parasites.
-
Par exemple le TSC2012 pour les mesures de courant
Mais je me trompe sans doute : est-ce bien dans une réalisation d'un décodeur Railcom ?
Oui, c'est à ça qu'il sert, et il le fait très bien.
-
A la sortie de ta version 1, je t'avais contacté pour que tu nous rejoignes chez Locoduino ; tu y as mis le temps, mais il n'est jamais trop tard et je me réjouis de te voir enfin parmi nous. :)
Je suppose que la version 2 apporte quelques nouveautés par rapport à la version 1, et si tu pouvais les lister brièvement sur ce forum, cela inciterait certains de nos lecteurs à se la procurer.
Désolé pour la précédente invitation. Comme je l'ai dit à Dominique sur GitHub, ça me gênait de m'inscrire ici pour faire de l'auto-promo, c'est pour cela que je n'étais pas venu.
Bon alors, pour ce qui est des nouveautés :
- La grande centrale DCC a été améliorée, elle bénéficie maintenant d'un afficheur graphique.
- Le panneau de contrôle a été revu, avec de vrais circuits imprimés, et supporte jusqu'à 16 contrôleurs.
- Un contrôleur indépendant a été créé, il est doté un petit écran OLED et peut se brancher sur le bus I²C, on peut en connecter 16.
- Une extension de bus I²C permet le raccordement de circuits distants, et aussi la connexion des contrôleurs indépendants.
- Il y a un décodeur de signaux Railcom ;D
- Le détecteur de passage a été amélioré pour le rendre insensible aux éclairages parasites et permettre d'en connecter 192 sur un seul Arduino Nano.
- Le tachymètre a aussi été amélioré et il permet de piloter des afficheurs matriciels à LED de grande taille.
- Le pilotage des aiguillages a été revu, avec plusieurs solutions utilisables selon le courant consommé par les bobines.
- Les circuits d'un PCC/TCO sont décrits, mais le programme est encore en cours d'amélioration.
Et encore d'autres sujets, je ne vais pas tout détailler (protection, stockage d'énergie, pilotage des signaux)
Le livre a pris 120 pages au passage :o
-
Bonjour,
Bravo et merci tout d'abord pour tout ce qui peut améliorer la pratique de notre hobby. Un point a particulièrement attiré mon attention :
- Il y a un décodeur de signaux Railcom ;D
Je suppose que le terme "décodeur" employé ici n'est pas tout à fait exact mais qu'il s'agit probablement d'un système de détection d'un signal RailCom (et de son interprétation).
RailCom nécessite un cutout dans le signal DCC pour permettre au décodeur de locomotive "d'insérer" ses informations dans ce cutout et ne pas venir en collision avec les signaux DCC. Dans votre cas, le cutout est-il généré par la centrale DCC ou par un autre moyen ?
-
Désolé pour la précédente invitation. Comme je l'ai dit à Dominique sur GitHub, ça me gênait de m'inscrire ici pour faire de l'auto-promo, c'est pour cela que je n'étais pas venu.
Bon alors, pour ce qui est des nouveautés :
- La grande centrale DCC a été améliorée, elle bénéficie maintenant d'un afficheur graphique.
- Le panneau de contrôle a été revu, avec de vrais circuits imprimés, et supporte jusqu'à 16 contrôleurs.
- ......
Le livre a pris 120 pages au passage :o
Nous faisons tous de l'auto-promo pour les articles que nous éditons, sauf que nous, c'est du virtuel et non du papier (encore que, parfois je parle de mes articles sur Loco-Revue qui en retour fait de la pub pour Locoduino ;) )
J'ai comparé la table des matières de la V2 (téléchargeable sur ENI) avec celle de ton livre V1 et effectivement, j'ai vu pas mal d'ajouts et parfois aussi de refonte complète. Je vais donc me procurer la V2 (qui est au même prix que la V1) et relire tout cela à tête reposée...
-
Je suppose que le terme "décodeur" employé ici n'est pas tout à fait exact mais qu'il s'agit probablement d'un système de détection d'un signal RailCom (et de son interprétation).
RailCom nécessite un cutout dans le signal DCC pour permettre au décodeur de locomotive "d'insérer" ses informations dans ce cutout et ne pas venir en collision avec les signaux DCC. Dans votre cas, le cutout est-il généré par la centrale DCC ou par un autre moyen ?
Il y a la partie détection, mais la programmation de l'Arduino permet aussi le décodage. Le canal 1 est totalement décodé par le circuit (adresse de la locomotive) et le canal 2 est extrait, mais son contenu est assez variable, et de ce côté-là, il y a encore matière à décodage. Ces informations sont disponibles par lecture sur le bus I²C, ce qui permet de les utiliser par ailleurs, par exemple par le PCC ou un programmeur de CV.
Pour ce qui est du cutout, il est généré par la centrale DCC, puisqu'elle doit mettre en court-circuit la sortie de l'amplificateur pour permettre la lecture du signal Railcom. Le signal d'activation du cutout est par ailleurs transmis de la centrale vers le décodeur Railcom pour que celui-ci se synchronise précisément avec la centrale.
-
J'ai comparé la table des matières de la V2 (téléchargeable sur ENI) avec celle de ton livre V1 et effectivement, j'ai vu pas mal d'ajouts et parfois aussi de refonte complète. Je vais donc me procurer la V2 (qui est au même prix que la V1) et relire tout cela à tête reposée...
Oui, il y a eu beaucoup de refonte sur les autres chapitres : les aiguillages, la régulation des circulations, la position des trains, le bus I²C. J'ai réécrit ce qui n'était pas clair, ajouté des schémas et des photos, déplacé des sections d'un chapitre à un autre, supprimé des parties inutiles. Six mois de travail tous les soirs 8)
-
Je sais ce que cela représente de sortir un livre technique ou un cours (j'ai écrit le cours de météorologie pour pilote de ligne édité conjointement par l'ENAC et l'IAJM, publié de 1994 à 2020 (deux versions : française et anglaise) et aujourd'hui, cédé à une nouvelle équipe d'enseignants de l'ENAC car étant à la retraite, je ne suis plus trop dans le coup pour suivre les évolutions des réglementations).
Je viens de commander ta V2 ; bizarre, j'ai choisi Chronopost à la place de Collissimo mais cela n'a pas changé le prix total. J'espère l'avoir demain ; il devrait quitter le stock ce soir. :)
-
Pour ce qui est du cutout, il est généré par la centrale DCC, puisqu'elle doit mettre en court-circuit la sortie de l'amplificateur pour permettre la lecture du signal Railcom. Le signal d'activation du cutout est par ailleurs transmis de la centrale vers le décodeur Railcom pour que celui-ci se synchronise précisément avec la centrale.
Merci, c'était bien l'info que je recherchais et le mode de génération du cutout que je présentais. Comme la plupart d'entre nous sommes en DCC++, ce qui m'intéresse c'est la manière dont nous pourrions modifier DCC++ pour justement générer le cutout.
J'ai acheté votre livre (comme j'avais acheté le 1°) et je potache actuellement ce que vous appelez "décodeur". De prime abord, cela est séduisant.
-
Je viens de commander ta V2 ; bizarre, j'ai choisi Chronopost à la place de Collissimo mais cela n'a pas changé le prix total. J'espère l'avoir demain ; il devrait quitter le stock ce soir. :)
Mon cher Christian, si tu es impatient, sache que tu peux consulter la version en ligne en attendant. Il faut que tu ailles sur le compte que tu as créé.
-
Mon cher Christian, si tu es impatient, sache que tu peux consulter la version en ligne en attendant. Il faut que tu ailles sur le compte que tu as créé.
Salut Christophe,
Je crois que je peux bien attendre jusqu'à demain pour avoir le plaisir de feuilleter un objet bien réel ! :)
Odeur de l'encre fraiche, bruissement des feuilles qu'on tourne, poids de l'objet tenu en mains, etc. Je dois être un grand nostalgique... mais pas au point de faire des automatismes à la Chennevez (bien utiles en son temps et son travail, novateur à l'époque, avait été considérable, donc respect de ma part envers l'auteur).
Mais si je craque avant demain, j'aurais l'honnêteté de te le dire. ;D
A quand le deuxième volet de ton article sur ton pont tournant ? J'y ai repensé en revisionnant dernièrement la vidéo que j'avais faite pour Trainsmania 2021 et en voyant ta tablette pour le commander.
-
Six mois de travail tous les soirs 8)
Sans doute en plus du temps pour la réalisation, les circuits imprimés, les logiciels, les tests sur un réseau réel.. On sent bien que ce qui est décrit dans ce livre a été réalisé et testé. D'ailleurs je viens de l'acheter chez Cultura et je me plonge dans le décodeur RailCom.
-
Plus j'y pense et plus je me dis que j'aurais du écrire le générateur DCC sous forme de librairie. j'ai hésité à le faire, et le résultat, c'est que le même code est présent dans le programme des deux centrales DCC présentées dans le livre, c'est un peu dommage. Il va falloir que j'envisage une refonte du générateur DCC, il pourrait avoir d'autres usages, par exemple pour la régulation des circulations.
J'ai aussi pris quelques photos des circuits :
https://github.com/EditionsENI/Arduino-et-le-train/tree/master/V2/images
-
Il ne faut peut-être pas regretter tout de suite ...
Rien n'est plus énervant que de revenir quelques mois plus tard sur un programme qui fonctionnait parfaitement et qui brutalement ne se compile plus. Et qu'après moult recherches infructueuses sur base de messages improbables, on découvre que la faute est à imputer à une bibliothèque modifiée arrivée discrètement à l'occasion d'une mise à jour ...
-
On a échangé un peu sur le bus I2C par rapport au bus Can. Voici un petit développement sur ce sujet :
il y a des discussions sur la comparaison entre ces bus ici (https://forum.locoduino.org/index.php?topic=642.msg7237) et ici (https://forum.locoduino.org/index.php?topic=1118.0), et des discussions sur le Bus Can (https://forum.locoduino.org/index.php?topic=51.0) et aussi la rétrosignalisation (https://forum.locoduino.org/index.php?topic=364.0). et il y en a quantité de cas concrets en passant par la case "recherche".
Il y a aussi les articles de Jean-Luc sur la mise en oeuvre du bus Can (https://www.locoduino.org/spip.php?article130), et, plus moderne : la bibliothèque ACAN (https://www.locoduino.org/spip.php?article268).
Coté matériel, les UNO, Nano, Micro, Mega ont besoin d'une carte CAN qui s'interface en SPI alors que les DUE et ESP32 n'ont besoin que d'un amplificateur de ligne (donc comme l'I2C aussi).
Coté utilisation, le Can est bien adapté au modélisme ferroviaire :
- Insensible aux parasites (2 fils, différentiel), 100 m à 500kb/s, ou 500 m à 125 kb/s
- Messages de taille limitée. 8 octets de données au plus.
- Temps-réel. Les temps de transmission sont déterministes et peuvent être calculés à priori.
- Multi-maître asynchrone. pas d’arbitre centralisé, pas d’horloge globale, une station peut émettre quand elle veut et l’émission a lieu dès que le bus est libre.
- Priorité entre les messages. Les collisions, quand plusieurs contrôleurs CAN émettent sur le bus simultanément, sont résolues sans destruction du message le plus prioritaire.
Fiable :
- Une détection d’erreur est incluse. La probabilité qu’une erreur reste non détectée est inférieure à 4,7 10-11.
- Le protocole définit une surveillance très stricte du bus.
- La cohérence des données est garantie. Un message est soit accepté par tous les contrôleurs CAN du réseau, soit rejeté par tous.
- Acquittement des messages par toutes les stations, le signalement d’erreur émis par une station est reçu par toutes les stations.
- Retransmission automatique des messages après signalement d’erreur.
- Un contrôleur CAN gère de façon autonome les erreurs temporaires qu’il détecte.
Peu coûteux :
- Les contrôleurs CAN sont soit disponibles en tant que composant destiné à être connecté à un micro-contrôleur, soit intégrés directement dans un micro-contrôleur.
- La quantité de logiciel nécessaire pour le faire fonctionner est très succincte.
- la mise en oeuvre avec l'Arduino IDE est simple car toute la complexité est dans le contrôleur Can (voir les articles).
- Les composants CAN sont fabriqués en grand nombre, donc peu chers.
Personnellement mon premier réseau était architecturé autour d'un bus I2C, mais il faut bien étudier l'ordonnancement des échanges entre maitre et esclaves, ce qui n'est pas toujours évident.
Dans mon réseau actuel, chaque capteur émet un message dès qu'il y a un événement (ou périodiquement si c'est un état). Chaque message identifie le type de message et les données contiennent les détails. Le gestionnaire recoit tous les messages au fur et à mesure, n'a pas à les demander, ni interroger les capteurs. Un simple "switch" permet de les traiter individuellement.
Cela permet une grande modularité qui m'a permis de construire les éléments de mon réseau à mon rythme.. et il en reste encore à faire !
Pour revenir à l'I2C il faut reconnaitre que le livre de Pascal Barlier donne une foule de détails de mise en oeuvre du bus I2C qui devraient permettre a tous ceux qui l'utilisent de trouver leur bonheur.
-
Coté matériel, les UNO, Nano, Micro, Mega ont besoin d'une carte CAN qui s'interface en SPI alors que les DUE et ESP32 n'ont besoin que d'un amplificateur de ligne (donc comme l'I2C aussi).
...
Coté utilisation, le Can est bien adapté au modélisme ferroviaire :
- Insensible aux parasites (2 fils, différentiel), 100 m à 500kb/s, ou 500 m à 125 kb/s
...
- Multi-maître asynchrone. pas d’arbitre centralisé, pas d’horloge globale, une station peut émettre quand elle veut et l’émission a lieu dès que le bus est libre.
...
Dans mon réseau actuel, chaque capteur émet un message dès qu'il y a un événement (ou périodiquement si c'est un état). Chaque message identifie le type de message et les données contiennent les détails. Le gestionnaire recoit tous les messages au fur et à mesure, n'a pas à les demander, ni interroger les capteurs. Un simple "switch" permet de les traiter individuellement.
J'ai opté pour le bus I²C dès le début de mon projet (le 8/10/2014). A cette époque, je considérais le bus CAN comme un bus destiné à l'automobile, et je n'avais par trouvé d'informations pertinentes concernant des interfaces bus CAN pour Arduino.
Par la suite, le CAN m'a été suggéré par un lecteur, je me suis documenté sur le sujet, même si je dois reconnaître que j'ai toujours du mal à changer ce qui fonctionne. De plus le CAN nécessite une carte additionnelle et je voulais éviter de complexifier les montages proposés dans le livre. Je suis donc resté en I²C. Et finalement, j'ai trouvé le PCA9615, qui est un driver différentiel de bus i²C, il permet de résoudre le problème de la sensibilité aux parasites et permet la terminaison du bus.
Donc, le seul inconvénient que je trouve au bus I²C est le fait qu'il soit mono-maître, ce qui ne permet pas de signaler facilement la présence de données à lire. Le signal INT (interruption) disponible sur les périphériques I²C est destiné à cet usage, mais il ne fait pas partie de l'implémentation présente sur les µP Atmel. Je dois donc scanner le bus régulièrement.
-
Le choix de l’I2C est aussi un bon choix retenu par une grande partie des modélistes. Ton livre va intéresser ceux-ci grâce aux détails techniques et aux programmes donnés.
Il est vrai que les premières cartes Can étaient très chères. C’est pour cela que la carte Can Locoduino a été conçue :
(https://www.locoduino.org/local/cache-vignettes/L434xH451/cartecan-54f98.png?1548598075)
Mais par la suite des cartes bon marché sont apparues comme celle-ci :
(https://www.locoduino.org/local/cache-vignettes/L610xH389/interface_mcp2515-ad055.jpg?1548598595)
Maintenant il y a le clan I2C et le clan CAN, sans que je sache dans quelles proportions.
Je suis d’accord que quand le projet est bien avancé il n’est pas bien de changer de techno. Mon réseau précédent était basé sur I2C aussi.
Ton livre est agréable et facile à lire : je suis en plein dedans ;)
-
... j'ai trouvé le PCA9615, qui est un driver différentiel de bus i²C ...
ce qui permet à l'I2C d'avoir une immunité aux parasites comparable au CAN, et peut le réhabiliter aux yeux de certains déçus.
Mais ce composant est réservé aux amateurs avertis, à qui la soudure des CMS (SSOP10) ne pose pas de problème.
J'ai vu des modules avec ce composant mais à des prix curieux (>25€ chez Aliexpress).
Produit trop récent ?, la fiche technique rev. 2 est de septembre 2021.
-
J’ai une question qui s’adresse à Pascal Barlier. Sur le Github, la lience est donnée pour « GNU General Public License v3.0 ». Si je ne fais pas erreur, il est donc possible de modifier le code (en citant bien sûr la source) et de le publier le code modifé sur Locoduino par exemple, non ?
J’ai en effet modifié le code de la centrale pour la rendre pilotable par des applications externes comme JMRI en Serial, Ethernet et même en WiFi.
Ce qui m’intéressait moi, c’est tout d’abord de voir si la bibliothèque FlexiTimer2 apporte un progrès quant à la lecture et l’écriture des CVs par rapport à DCC++ (DCCpp).
En second lieu, je cherche aussi à générer des cutout pour tester la détection RailCom. Il faut que je fasse réaliser les PCB proposés et que je soude les composants !
C’est donc dans le but de partager ce code sur Locoduino que je pose la question.
Merci par avance pour la réponse.
-
Je me suis lancé pour la détection RailCom telle que la propose Pascal Barlier.
J'ai lancé la fabrication de PCB chez JLCPCB pour 9€49 les 10 et en prime, j'ai pris en plurple (disponible depuis environ 6 mois) mais il n'y plus de délais supplémentaire comme avant.
Si ça intéresse quelqu'un, je n'utiliserai pas les 10 cartes, c'est à ce stade essentiellement pour faire des tests. A ma connaissance, ce serait le premier detecteur RailCom DIY à base d'Arduino. Celui de Paco est à base de PIC.
A suivre...
(https://alkans.fr/locoduino/img/at-retour.png)
-
Mais ce composant est réservé aux amateurs avertis, à qui la soudure des CMS (SSOP10) ne pose pas de problème.
J'ai vu des modules avec ce composant mais à des prix curieux (>25€ chez Aliexpress).
Produit trop récent ?, la fiche technique rev. 2 est de septembre 2021.
Il est un peu difficile à souder, mais j'y suis arrivé avec un simple fer équipé d'une grosse panne plate. Cela permet de souder toutes les pattes à la fois, il faut juste utiliser du flux de soudure pour que ce soit possible. Avec une grosse loupe et sans trembler, c'est tout à fait réalisable. J'explique la méthode dans le livre.
Effectivement le circuit est très récent, puisque la rev 1 de la datasheet est de 2019. Les circuits du même type, mais plus anciens, sont classés obsolètes, et c'est dommage car il y avait des versions DIP plus faciles à souder.
On le trouve pour 3€66 chez Mouser (hors taxes et frais de douane, on peut ajouter 50% pour le prix réel), il tombe à 3€28 si on en prend 10. Et une dizaine est suffisante pour équiper tout un réseau puisque l'on peut ensuite déployer un bus I²C classique à partir du circuit, c'est ce que j'ai fait.
-
J’ai une question qui s’adresse à Pascal Barlier. Sur le Github, la lience est donnée pour « GNU General Public License v3.0 ». Si je ne fais pas erreur, il est donc possible de modifier le code (en citant bien sûr la source) et de le publier le code modifé sur Locoduino par exemple, non ?
J’ai en effet modifié le code de la centrale pour la rendre pilotable par des applications externes comme JMRI en Serial, Ethernet et même en WiFi.
Ce qui m’intéressait moi, c’est tout d’abord de voir si la bibliothèque FlexiTimer2 apporte un progrès quant à la lecture et l’écriture des CVs par rapport à DCC++ (DCCpp).
En second lieu, je cherche aussi à générer des cutout pour tester la détection RailCom. Il faut que je fasse réaliser les PCB proposés et que je soude les composants !
Le projet est hébergé sur le GitHub de mon éditeur, qui a choisi la licence GNU, que j'ai également choisie pour mes autres projets, qui sont hébergés sont mon compte GitHub perso. Cela signifie en effet, que les sources qui sont sur le GitHub peuvent être modifiées et republiées sous licence GNU.
J'ai prévu (page 174) un emplacement sur le circuit imprimé de la centrale pour un circuit d'interface USB (composant XA2) basé sur un circuit FT232RL. C'est une façon pratique d'interfacer la centrale avec un PC. Ce n'est qu'une option, je n'ai pas eu l'occasion (ni le temps) de développer le code nécessaire (le pilotage par PC n'est pas ma priorité).
Le circuit d'interface est disponible pour 6€99 sur Amazon :
https://www.amazon.fr/ElectroWorldFR-FT232RL-Serial-Adapter-Module/dp/B09JMCKLXX
Flexitimer2 est une bibliothèque qui permet de gérer les interruptions avec plus de précision que la bibliothèque standard, rien de plus. Elle n'est pas la seule à pouvoir le faire, mais elle permet de calibrer l'interruption à 29µs, ce qui est nécessaire pour réaliser proprement le cutout. Franchement, je me demande bien pourquoi les créateurs de la norme Railcom ont décidé de décaler de 1/2 période d'horloge DCC le début et la fin du cutout, si ce n'était pas le cas, une interruption à 58µs suffirait pour générer un signal DCC avec cutout.
C'est en répondant à cette question que je viens de réaliser qu'il y a une erreur dans le code de la centrale (at-dicicino.ino ligne 1917), je me suis trompé pour la valeur de l'interruption :-[
Il est écrit ceci :
FlexiTimer2::set(1, 0.000028, dccInterrupt);
Mais la bonne valeur est 29µs :
FlexiTimer2::set(1, 0.000029, dccInterrupt);
Ça fonctionne quand même avec mes décodeurs, mais il vaut mieux mettre la bonne valeur.
La même erreur est présente dans le code de la petite centrale (at-multi2.ino ligne 2061).
-
J'ai lancé la fabrication de PCB chez JLCPCB pour 9€49 les 10 et en prime, j'ai pris en plurple (disponible depuis environ 6 mois) mais il n'y plus de délais supplémentaire comme avant.
Je n'ai même pas mis de photo du décodeur Railcom dans le livre, en voici une. L'implantation est un peu différente car il y a eu des remaniements du circuit imprimé avant la publication du livre : le bornier et le shunt ont été déplacés, et la résistance R3 a été ajoutée.
-
C'est en répondant à cette question que je viens de réaliser qu'il y a une erreur dans le code de la centrale (at-dicicino.ino ligne 1917), je me suis trompé pour la valeur de l'interruption :-[
Il est écrit ceci :
FlexiTimer2::set(1, 0.000028, dccInterrupt);
Mais la bonne valeur est 29µs :
FlexiTimer2::set(1, 0.000029, dccInterrupt);
Ça fonctionne quand même avec mes décodeurs, mais il vaut mieux mettre la bonne valeur.
La même erreur est présente dans le code de la petite centrale (at-multi2.ino ligne 2061).
D'après la norme NMRA s-9.3.2_2012_12_10 (https://www.nmra.org/sites/default/files/s-9.3.2_2012_12_10.pdf), le cutout start est compris entre 26 et 32 µS, ce qui explique que ça marche avec 28µS... ???
Mais sur le site NMRA.org, Railcom n'a pas évolué depuis 2012 et est introuvable, dans son moteur de recherche :o
De plus, d'après Wikipedia "For data transmission to work, the system must interrupt track power between DCC packets".
Je ne comprends donc pas bien comment la mise en "court-circuit" du LMD18200 fonctionne, au lieu de placer les rails "en l'air", en haute impédance, et avec une résistance pour réduire l'impédance sans doute (le "brake" le fait-il ?)
Il y a quelque chose que je n'ai pas encore assimilé sans doute.
-
D'après la norme NMRA s-9.3.2_2012_12_10 (https://www.nmra.org/sites/default/files/s-9.3.2_2012_12_10.pdf), le cutout start est compris entre 26 et 32 µS, ce qui explique que ça marche avec 28µS... ???
Je ne comprends donc pas bien comment la mise en "court-circuit" du LMD18200 fonctionne, au lieu de placer les rails "en l'air", en haute impédance, et avec une résistance pour réduire l'impédance sans doute (le "brake" le fait-il ?)
L'interruption sert aussi pour l'envoi des données DCC et pour envoyer un "1", il faut 58µs de signal positif suivi de 58µs de signal négatif. Mais il y a une certaine tolérance, la NMRA indique entre 55 et 61 µs côté centrale, les décodeurs devant accepter de 51 à 64 µs. J'ai choisi 58 µs car il s'agit de la valeur moyenne.
Le pont en H qui consistitue l'amplificateur est composé de deux push-pull. Chaque push-pull permettant de relier une de deux sorties, soit à la masse, soit à l'alimentation positive (15 à 20V). En émission DCC, les deux push-pull sont en opposition de phase; quand l'un est au +V, l'autre est à la masse, et vice-versa. La mise en court-circuit de l'amplificateur consiste a connecter les deux push-pull à la masse. Les deux sorties sont donc reliées ensemble par l'intermédiaire de la masse, elles sont donc en "court-circuit".
Mettre les sorties en court-circuit est nécessaire pour que le décodeur puisse fournir des données. Il peut envoyer des signaux sur les rails sous la forme d'un courant, qui peut être mesuré au moyen d'une résistance de shunt. Dans la mesure où le décodeur ne peut compter que sur la réserve de puissance accumulée dans son condensateur de filtrage, qui est assez petit, je pense qu'il s'agit de la façon la plus efficace pour émettre des données du décodeur vers la centrale (quoique on aurait aussi pu utiliser une modulation par courant porteur et ne pas faire de cutout).
-
En fait je comprends que pour mesurer le courant génèré par le décodeur loco, il faut fermer le circuit côté centrale.
Serait-il possible de faire le cutout dans le décodeur Railcom directement puisque le DCC de la centrale passe dans ce décodeur: isoler le DCC de la centrale et fermer le circuit des rails sur la résistance de mesure du courant) ?
Ça nécessiterait plus de logique et de composants et une détection du bit stop de chaque trame.
Ta solution semble être la plus simple et moins coûteuse.
-
Serait-il possible de faire le cutout dans le décodeur Railcom directement puisque le DCC de la centrale passe dans ce décodeur: isoler le DCC de la centrale et fermer le circuit des rails sur la résistance de mesure du courant) ?
Ça nécessiterait plus de logique et de composants et une détection du bit stop de chaque trame.
Théoriquement, c'est possible. Dans la réalité le circuit destiné à isoler la centrale et mettre la voie en court-circuit ne peut pas être réalisé avec un relais, ce serait beaucoup trop lent. Il faut donc le faire avec des transistors. Il en faut deux pour contrôler le passage du courant, puisque l'on a alternativement du +18V sur un rail, puis sur l'autre, et encore deux autres transistors pour faire le court-circuit, et il faut aussi des diodes pour protéger les transistors lorsqu'ils sont polarisés en inverse et qu'eles soient assez puissantes pour laisser passer le courant en direct. Bref, c'est encore plus compliqué que d'utiliser un LMD18200 ou un L298N.
Il y a par contre peut-être quelque chose à faire qui serait un "canton intégré". C'est à dire, regrouper sur une seule carte :
- Un Arduino (ou bien juste un Atmel ATMega328 ou ATMega2560 soudé sur la carte) (ou un shield pour Arduino Mega)
- L'amplificateur LMD18200 ou L298N
- Le décodeur Railcom à base de TSC2012
- La mesure de courant ACS712 (protection + détection de présence)
- Des entrées pour quelques détecteurs optiques ou ILS
- Des sorties pour piloter les signaux lumineux
- Et une interface qui pourrait être I²C, CAN ou autre.
- Et en bonus, la commande des aiguillages présents sur le canton
J'y ai déjà pensé, c'est une solution tentante, et le confort d'utilisation serait optimal, par contre le coût n'est pas négligeable.
-
Pour ceux qui suivent ce sujet, je vous informe que j'ai ouvert un nouveau fil qui traite de la station DCC de Pascal Barlier (revisitée) qui autorise la détection RailCom : https://forum.locoduino.org/index.php?topic=1352.msg14568#msg14568
-
Je constate que la solution utilisée pour la partie DCC du projet de Pascal est strictement la même que dans LaBox. Quelqu'un a t-il testé les timing pour voir si ç'est mieux ou pire que LaBox ? Juste pour savoir...
-
Bonjour Thierry,
Est-ce que tu parles bien du projet que j'ai mis sur le Github hier ? https://github.com/Locoduino/DCCxx-ESP32-WiFi-Railcom (https://github.com/Locoduino/DCCxx-ESP32-WiFi-Railcom)
En effet, j'ai changé de méthode de génération du DCC par rapport à ce qu'a fait Barlier et ce dont parle ce fil.
Le nouveau fil est ici pour l'ESP32 https://forum.locoduino.org/index.php?topic=1352.msg14748#msg1474 (https://forum.locoduino.org/index.php?topic=1352.msg14748#msg1474)8
Dans le nouveau projet, j'ai de très bons résultats avec les trames DCC générées de cette manière. J'ai testé avec 5 locos différentes, 5 décodeurs différents (Marklin, ESU V4 et V5, Zimo...)
Il rete des petits problème sur cette station mais il ne concernent pas la génération de la trame en elle même mais par exemple des démarrages intempestifs de certaines locos à la mise sous tension, mais encore une fois, la génération des trames n'est pas en cause.
Marcel a aussi fait les tests de son côté et à part les points que je signale ci-dessus, il a aussi réussi à piloter sa loco.
-
Un test positif de plus avec des commandes d'une manette sur RX/TX reçues par module radio.
idem pour JMRI (serie)
sur le moniteur :
ets Jun 8 2016 00:22:57
rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
flash read err, 1000
ets_main.c 371
ets Jun 8 2016 00:22:57
rst:0x10 (RTCWDT_RTC_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:1216
ho 0 tail 12 room 4
load:0x40078000,len:10944
load:0x40080400,len:6388
entry 0x400806b4
Project : DCCxx ESP32 WIFI RAILCOM
Version : v 1.2
Fichier : C:\Users\miche\Documents\Arduino\Locoduino\Christophe Bobille\DCCxx-ESP32-Railcom\DCCxx-ESP32-Railcom.ino
Compiled : Jan 31 2022 - 18:25:26
<p0>End setup
1
<p1>0
<p0>1
<p1>1
<p1>t1 8 0 1
<T 1 0 1>f 8 144
1
<p1>t1 8 1 1
<T 1 1 1>1
<p1>t1 8 2 1
<T 1 2 1>1
<p1>t1 8 3 1
<T 1 3 1>1
<p1>t1 8 5 1
<T 1 5 1>1
<p1>t1 8 4 1
-
Merci Michel pour ce retour. Tout cela est encourageant. Si toute fois nous arrivions à tirer profit de cela pour la box qui est un peu coincée ce serait génial. Je pense que Thierry va nous faire un retour prochainement.
Par contre, je vous invite à publier maintenant sur le fil dédié à l'ESP32 : https://forum.locoduino.org/index.php?topic=1352.msg14748#msg14748
En effet, le présent fil concerne l'Arduino Mega ou Uno sur lequel j'avais porté le développement de Pascal Barlier pilotable de l'extérieur (JMRI ...) et plus structuré en classes C++.
-
Il rete des petits problème sur cette station mais il ne concernent pas la génération de la trame en elle même mais par exemple des démarrages intempestifs de certaines locos à la mise sous tension, mais encore une fois, la génération des trames n'est pas en cause.
Le démarrage à la mise sous tension se produit à cause du mode de fonctionnement mixte analogique / numérique (CV29 bit2 à un) il suffit de le désactiver pour que tout rentre dans l'ordre. Tant que l'interruption de génère pas de signal DCC, il y a 15 à 20 V continu en sortie du booster, donc la locomotive se met en route jusqu'à temps que le signal DCC arrive.
-
Ce qui peut être évité en jouant sur l'entrée Enable du LMD18200.
-
Bonjour,
J'ai voulu reproduire la carte RailCom at-retour présentée dans le livre (V2). J'ai fait fabriquer les PCB à partir des fichiers Gerber en téléchargement donc sans modification.
J'ai utilisé exactement les composants préconisés. Je ne pense pas avoir fait d'erreur dans le montage des composants. Sauf peut-être le LM393, mais j'ai fait le montage dans un sens et dans l'autre et ça ne fonctionne pas mieux.
J'utilise un LMD18200, la tension à la sortie de l'alim est de 18V. Quand je met l'alimentation en service, j'ai bien un signal DCC sur mon rail (je n'ai qu'un seul rail pour les tests), ma loco répond, avance ou recule et ses fonctions répondent normalement.
J'ai bien sûr un signal DCC envoyé aux rails qui inclus le cutout (c'est le programme donné dans le livre), qui fonctionne parfaitement et que je présentée ici : https://forum.locoduino.org/index.php?topic=1352.0
J'ai mi une resistance variable (10KΩ) comme préconisé pour trouver la bonne valeur de résistance. (fils sur le côté)
Quelqu'un a t'il des préconisation ? Peut-être Pascal Barlier lui-même peut il m'aider ?
Merci par avance.
(https://www.alkans.fr/locoduino/railcom/01.jpg)
(https://www.alkans.fr/locoduino/railcom/02.jpg)
(https://www.alkans.fr/locoduino/railcom/03.jpg)
(https://www.alkans.fr/locoduino/railcom/04.jpg)
-
Bon ça avance petit à petit mai c'est dur dur !
J'ai trouvé, sinon la cause du court circuit mais au moins le moyen d'y remédier. Dans le schéma de son livre on voit que Enable (PWM) est rélié à la broche D4, le signal (DIR) à la D6 et le brake en D5.
(https://alkans.fr/locoduino/railcom/000000001.jpg)
Or dans le programme du Nano, ce sont les broches 2, 4 et 6 qui sont utilisées !!!
(https://alkans.fr/locoduino/railcom/000000002.jpg)
J'ai donc soudé directement sur le Nano les fils respectifs et je ne passe plus par le bus DCC comme préconisé. Et je n'ai plus le court jus, la loco est normalement pilotée par JMRI
(https://alkans.fr/locoduino/railcom/0003.jpg)
(la résistance R3 qui flotte un peu, c'est parce que j'ai enlevé la résistance variable est remplacée par une de 1KΩ. C'est pour pouvoir l'enlever facilement au besoin)
... mais je n'ai toujours pas de reconnaissance de la loco par la la carte. J'ai bien une série de donnée à la sortie du Nano mais que des 0, rien sur l'adresse de ma loco.
(https://alkans.fr/locoduino/railcom/port_serie.jpg)
-
Par curiosité, j"ai chargé at-retour.ino dans un Nano, sans centrale, sans DCC, le résultat est le même.
-
Ceci dit ! Je n'ai pas encore regardé le programme de près mais qu'il renvoie des suites de 0 alors qu'il n'y a pas de loco, je peux comprendre. Mais avec une loco Railcom (décodeur ESU), c'est moins acceptable.
Au fait Michel le petit paquet est parti ce matin.
-
On l'attend de pied ferme.
Pour les LokPilot, je note :
RailCom® est activé au moyen du CV 29, bit3. Le CV 28 offre d'autres options. RailCom® est activé, par défaut, dans les décodeurs LokPilot 5