Voir les contributions

Cette section vous permet de consulter les contributions (messages, sujets et fichiers joints) d'un utilisateur. Vous ne pourrez voir que les contributions des zones auxquelles vous avez accès.


Messages - Pascal Barlier

Pages: [1] 2
1
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.

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

3
D'après la norme  NMRA s-9.3.2_2012_12_10, 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).


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

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

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

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

8
Discussions ouvertes / Re : Distraction pour terminer l'année
« le: décembre 31, 2021, 05:20:15 pm »
On se laisse vite prendre dans le récit. Belle réussite cette "bataille du rail" version HO  :)

9
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


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


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


12
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

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

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

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


Pages: [1] 2