Les livres de Pascal Barlier : "ARDUINO: Faites le jouer au train"

[Dominique]

Le volume 1 est sorti à la boutique LocoRevue 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


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

[Pascal Barlier]

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.

[Pascal Barlier]

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

[Dominique]

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 
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 
En attendant il y a cette édition 2 à lire.

Cordialement
Dominique

[chris_bzg]

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

[Dominique]

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 ?

[Pascal Barlier]

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.

[Dominique]

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.

[Pascal Barlier]

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

[Pascal Barlier]

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.

[Pascal Barlier]

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

[bobyAndCo]

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 

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 ?

[chris_bzg]

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 

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

[Pascal Barlier]

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.

[Pascal Barlier]

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