1
L'Arduino pour le train miniature
Nouvelles:
Le forum LOCODUINO est consacré aux discussions ayant trait à l'utilisation de l'Arduino dans les automatismes et les animations pour le train miniature. Nous avons eu récemment quelques inscriptions de personnes ayant des projets plus généraux mais surtout inapplicables au train miniature. Si votre projet ou vos questions ne concernent pas le modélisme ferroviaire, ne vous inscrivez pas, vous perdriez votre temps et nous aussi.
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.
2
Vos projets / Re : Une manette PlayStation PS3 sans fil pour LaBox.
« le: septembre 11, 2025, 09:12:29 pm »
super !
3
Les réseaux / Re : signaux SNCF complexes réalisés avec un PCB, avec commande muliplexée via 4 fils
« le: septembre 11, 2025, 07:30:40 pm »
bon , il avait (déjà) un bug , mais j'ai pu le traquer avec l'analyseur logique et corriger (1 mois ... )
encore des détails à régler , mais l'ensemble est réussi et opérationnel
reste à donner la 3ème dimension aux signaux pour les implanter sur le réseau ...
Les 4 sorties du décodeur vers chaque signal peuvent avoir 3 niveaux : HIGH , LOW et INPUT → pour que le fil soit isolé ; on ne peut pas voir cela avec l'analyseur logique , car il ne sait lire que HIGH et LOW ! J'ai donc eu recours à une astuce : j'ai fait générer un signal carré rapide à l'une des broches du STM32 , que j'ai injecté par une résistance sur chacun des 4 fils . On voit alors assez bien les niveaux HIGH et LOW , et quand c'est INPUT (donc haute impédance , ou tout simplement coupé) , c'est hachuré ; ainsi le diagramme (voir ci-dessous) est bien lisible : sans cela je ne m'en sortais pas .
encore des détails à régler , mais l'ensemble est réussi et opérationnel
reste à donner la 3ème dimension aux signaux pour les implanter sur le réseau ...
Les 4 sorties du décodeur vers chaque signal peuvent avoir 3 niveaux : HIGH , LOW et INPUT → pour que le fil soit isolé ; on ne peut pas voir cela avec l'analyseur logique , car il ne sait lire que HIGH et LOW ! J'ai donc eu recours à une astuce : j'ai fait générer un signal carré rapide à l'une des broches du STM32 , que j'ai injecté par une résistance sur chacun des 4 fils . On voit alors assez bien les niveaux HIGH et LOW , et quand c'est INPUT (donc haute impédance , ou tout simplement coupé) , c'est hachuré ; ainsi le diagramme (voir ci-dessous) est bien lisible : sans cela je ne m'en sortais pas .
4
Vos projets / Re : LaBox" : Une Centrale DCC polyvalente et abordable
« le: août 24, 2025, 10:31:54 pm »
Bonjour,
tiens , j'ai raté un truc , l'ESP32 sait générer les signaux pour le cutout ?
tiens , j'ai raté un truc , l'ESP32 sait générer les signaux pour le cutout ?
5
Vos projets / Re : LaBox" : Une Centrale DCC polyvalente et abordable
« le: août 12, 2025, 10:43:34 pm »
sauf si elles permettent de se débarrasser des quelques pointes parasites , dont le DCC est un vil générateur . Faites comme vous voulez , mais moi je les laisserais .
6
Vos projets / Re : LaBox" : Une Centrale DCC polyvalente et abordable
« le: août 12, 2025, 05:17:56 pm »
Bonjour , perso , j'utilise pour le "roue libre" la même puissance que pour l'alim , donc ici ce serait du SMA . (ça fait + de fumée si monté à l'envers)
7
Débuter / Re : transformer mon 16V en 5V
« le: août 12, 2025, 05:06:09 pm »
Bonjour Bruno,
on peut acheter des leds munies de résistances , qui sont prévues pour du 12v continu . Amha , cela doit fonctionner en 16V~ , il faudrait faire l'essai.
on peut acheter des leds munies de résistances , qui sont prévues pour du 12v continu . Amha , cela doit fonctionner en 16V~ , il faudrait faire l'essai.
8
Les réseaux / Re : signaux SNCF complexes réalisés avec un PCB, avec commande muliplexée via 4 fils
« le: août 12, 2025, 10:36:36 am »
Bonjour Bruno , merci pour ton intérêt !
J'ai pu avancer sur la partie réception des indications : quand une nouvelle indication arrive et remplace celle qui est en cours , les feux concernés doivent s'allumer , ou s'éteindre , ou se mettre à clignoter , le tout progressivement , bien sûr ... :
Edit : cela fonctionne bien pour un signal , reste à compléter le code pour les 3 autres (une punition , vu ma "méthode" de beaucoup coder à plat ; j'espère que cela ne va pas déterrer un dernier vilain bug ...
J'ai pu avancer sur la partie réception des indications : quand une nouvelle indication arrive et remplace celle qui est en cours , les feux concernés doivent s'allumer , ou s'éteindre , ou se mettre à clignoter , le tout progressivement , bien sûr ... :
Edit : cela fonctionne bien pour un signal , reste à compléter le code pour les 3 autres (une punition , vu ma "méthode" de beaucoup coder à plat ; j'espère que cela ne va pas déterrer un dernier vilain bug ...
9
Les réseaux / Re : signaux SNCF complexes réalisés avec un PCB, avec commande muliplexée via 4 fils
« le: août 03, 2025, 01:25:16 pm »
Pour rappel , le but c'est aussi de pouvoir faire varier l'intensité lumineuse des LED par PWM , ce qui permet de simuler l'allumage et l'extinction progressives des feux , dus à l'inertie thermique des lampes à incandescence des anciens signaux SNCF . Pour cela , la commande est constituée de trames répétées ayant chacune 12 fenêtres de temps , dont la durée varie en fonction du rendement lumineux de chaque LED , et dont la durée constitue aussi une période PWM , à l'intérieur de laquelle le duty cycle varie pour déterminer la luminosité de la LED.
Le problème c'est toujours le carré violet , dont la LED a un rendement médiocre . Pour pallier , il a fallu doubler le fil P3 par une deuxième sortie du STM32 (P3x) , dépourvue de résistance : on a alors 150R + 0R pour cette LED , au lieu de 270R + 270R pour les autres LED . Pour un carré normal , à LED rouge , ce n'est pas nécessaire , le fil P3x (0R) reste en INPUT , cad. en haute impédance.
Du coup , la difficulté c'est que pour chaque signal , il faut 5 broches en PWM , et que ces 5 sorties PWM soient synchronisées : c'était possible avec le pi pico , mais pas avec le BluePill+ : il ne dispose que de 4 timers , donc un timer par signal , qui n'ont chacun "que" 4 canaux PWM . J'ai donc dû laisser les broches P3 et P3x en GPIO (sorties digitales) ordinaires , et de n'appliquer le PWM que sur les fils P1 ou P2 ou P4 . Dans ce cas , pour les LED "manoeuvre" , "vert" et "id2" , il a fallu mettre le fil P3 en sortie digitale (GPIO) HIGH , et commander les autre fils (cad. P1 ou P2 ou P4) en PWM inversé (pour STM32 , PWM normal = PWM1 , PWM inversé = PWM2) . J'ai eu du mal à le concevoir et à le mettre au point , il a fallu écrire directement dans les registres , car STM32duino , bien que très complet ne rentre logiquement pas dans ces détails , et cela a aussi permis un gain de temps bien nécessaire ... mais enfin , ça marche bien .
Comme je tiens absolument à utiliser un timer en mode compare + filtre numérique , pour décoder du DCC , et que tous les timers sont pris pour les signaux , le bus de commande doit être d'un type permettant la transmission (la réception , surtout) par UART , c'est à dire Loconet , ou Xpressnet , ou RS485 protocole perso.
La carte de la photo , fonctionne avec Xpressnet , ou RS485 protocole perso , l'interface MAX485 n'est pas visible ici , car située sous le bluePill+ .
Donc a ce stade , je sais commander chacune des 4x 12 LED , individuellement , en intensité lumineuse variable .
La prochaine étape , c'est de commander les LED groupées en indication (aspect) réglementaire de signal , et de ménager la transition progressive d'une indication vers la suivante. Puis il faudra activer le bus , pour que la carte prenne les commandes qui lui sont destinées . L'expérience atteste que , même si c'est des choses que j'ai déjà faites , il faudra du temps .
Le problème c'est toujours le carré violet , dont la LED a un rendement médiocre . Pour pallier , il a fallu doubler le fil P3 par une deuxième sortie du STM32 (P3x) , dépourvue de résistance : on a alors 150R + 0R pour cette LED , au lieu de 270R + 270R pour les autres LED . Pour un carré normal , à LED rouge , ce n'est pas nécessaire , le fil P3x (0R) reste en INPUT , cad. en haute impédance.
Du coup , la difficulté c'est que pour chaque signal , il faut 5 broches en PWM , et que ces 5 sorties PWM soient synchronisées : c'était possible avec le pi pico , mais pas avec le BluePill+ : il ne dispose que de 4 timers , donc un timer par signal , qui n'ont chacun "que" 4 canaux PWM . J'ai donc dû laisser les broches P3 et P3x en GPIO (sorties digitales) ordinaires , et de n'appliquer le PWM que sur les fils P1 ou P2 ou P4 . Dans ce cas , pour les LED "manoeuvre" , "vert" et "id2" , il a fallu mettre le fil P3 en sortie digitale (GPIO) HIGH , et commander les autre fils (cad. P1 ou P2 ou P4) en PWM inversé (pour STM32 , PWM normal = PWM1 , PWM inversé = PWM2) . J'ai eu du mal à le concevoir et à le mettre au point , il a fallu écrire directement dans les registres , car STM32duino , bien que très complet ne rentre logiquement pas dans ces détails , et cela a aussi permis un gain de temps bien nécessaire ... mais enfin , ça marche bien .
Comme je tiens absolument à utiliser un timer en mode compare + filtre numérique , pour décoder du DCC , et que tous les timers sont pris pour les signaux , le bus de commande doit être d'un type permettant la transmission (la réception , surtout) par UART , c'est à dire Loconet , ou Xpressnet , ou RS485 protocole perso.
La carte de la photo , fonctionne avec Xpressnet , ou RS485 protocole perso , l'interface MAX485 n'est pas visible ici , car située sous le bluePill+ .
Donc a ce stade , je sais commander chacune des 4x 12 LED , individuellement , en intensité lumineuse variable .
La prochaine étape , c'est de commander les LED groupées en indication (aspect) réglementaire de signal , et de ménager la transition progressive d'une indication vers la suivante. Puis il faudra activer le bus , pour que la carte prenne les commandes qui lui sont destinées . L'expérience atteste que , même si c'est des choses que j'ai déjà faites , il faudra du temps .
10
Les réseaux / signaux SNCF complexes réalisés avec un PCB, avec commande muliplexée via 4 fils
« le: août 03, 2025, 12:13:50 pm »
ce projet a 4 ans ... https://forum.locoduino.org/index.php?topic=1269.msg13739#msg13739
Je l'avais repris en utilisant un pi pico , le but est de ne pas utiliser de composant autres que de simples résistances pour faire le charlieplexing ; je ne sais pas si j'avais publié sur cette variante , mais de toutes manières cela a fini par un échec , sans doute dû à ma connaissance (bonne mais néanmoins) insuffisante du pi pico.
J'ai donc repris le tout avec ce que je connais le mieux , un STM32 , ici un (bluePill+ de chez WeAct) ; la réussite était donc obligatoire , mais ardue.
L’essentiel de l'étude reste valable , mais c'est l'occasion de lancer un nouveau topic ici.
Le schéma du signal a été redéfini , pour valoriser le maximum de LEDs possibles , soit 12 avec 4 fils (il y en a 14 , mais c'est parce que les 2 LEDs du R et du RR sont mises en // sans autre forme de procès)
Je l'avais repris en utilisant un pi pico , le but est de ne pas utiliser de composant autres que de simples résistances pour faire le charlieplexing ; je ne sais pas si j'avais publié sur cette variante , mais de toutes manières cela a fini par un échec , sans doute dû à ma connaissance (bonne mais néanmoins) insuffisante du pi pico.
J'ai donc repris le tout avec ce que je connais le mieux , un STM32 , ici un (bluePill+ de chez WeAct) ; la réussite était donc obligatoire , mais ardue.
L’essentiel de l'étude reste valable , mais c'est l'occasion de lancer un nouveau topic ici.
Le schéma du signal a été redéfini , pour valoriser le maximum de LEDs possibles , soit 12 avec 4 fils (il y en a 14 , mais c'est parce que les 2 LEDs du R et du RR sont mises en // sans autre forme de procès)
11
Vos projets / Re : signaux sncf réalisés avec un pcb, avec commande 4 fils muliplexée
« le: août 03, 2025, 10:31:25 am »
ben oui , 4 ans déjà ...
J'avais repris le projet en utilisant un pi pico , le but est de ne pas utiliser de composant autres que de simples résistances pour faire le charlieplexing ; je ne sais pas si j'avais publié sur cette variante , mais de toutes manières cela s'est fini par un échec , sans doute dû à une connaissance (bonne mais néanmoins) insuffisante du pi pico.
J'ai donc repris le tout avec ce que je connais le mieux , un STM32 , ici un (bluePill+ de ches WeAct) ; la réussite était donc obligatoire , mais ardue.
L’essentiel de l'étude reste valable , mais c'est l'occasion de lancer un nouveau topic ici.
J'avais repris le projet en utilisant un pi pico , le but est de ne pas utiliser de composant autres que de simples résistances pour faire le charlieplexing ; je ne sais pas si j'avais publié sur cette variante , mais de toutes manières cela s'est fini par un échec , sans doute dû à une connaissance (bonne mais néanmoins) insuffisante du pi pico.
J'ai donc repris le tout avec ce que je connais le mieux , un STM32 , ici un (bluePill+ de ches WeAct) ; la réussite était donc obligatoire , mais ardue.
L’essentiel de l'étude reste valable , mais c'est l'occasion de lancer un nouveau topic ici.
12
Les réseaux / Re : décodeur LOCONET pour moteurs MP1
« le: juillet 06, 2025, 10:39:57 pm »
Bonjour,
mille excuses pour la réponse tardive
si vous avez du lokmaus2 et du multimaus , le bus n'est pas loconet mais xpressnet : ils se ressemblent , mais ne sont absolument pas compatibles
j'ai quelque chose qui est électriquement compatible , mais le protocole xpressnet n'est pas (encore) implémenté
mille excuses pour la réponse tardive
si vous avez du lokmaus2 et du multimaus , le bus n'est pas loconet mais xpressnet : ils se ressemblent , mais ne sont absolument pas compatibles
j'ai quelque chose qui est électriquement compatible , mais le protocole xpressnet n'est pas (encore) implémenté
13
Le logiciel DCC++ / Re : DCC++ & Arduino Uno R4 WiFi
« le: avril 23, 2025, 02:28:56 pm »
Bonjour,
le Renesas dispose d'un Event Link Controller (ELC) ; on peut peut-être , par ce moyen , atteindre n'importe quelle broche depuis les timers , ce qui permettrait de générer le cutout sur les 2 voies : j'ai commandé un module pour étudier ça (c'est où qu'on peut commander quelques vies de + pour pas cher , pour avoir le temps de réaliser tout ça ?)
le Renesas dispose d'un Event Link Controller (ELC) ; on peut peut-être , par ce moyen , atteindre n'importe quelle broche depuis les timers , ce qui permettrait de générer le cutout sur les 2 voies : j'ai commandé un module pour étudier ça (c'est où qu'on peut commander quelques vies de + pour pas cher , pour avoir le temps de réaliser tout ça ?)
14
Débuter / Re : gestion passage à niveau pour deux voies unidirectionnelles
« le: avril 17, 2025, 03:24:51 pm »
Bonjour,
je pense que l'analyse des annonces pour la DV (unidirectionnelle) est plus simple que pour une VU
il faudra plutôt enlever du code
je pense que l'analyse des annonces pour la DV (unidirectionnelle) est plus simple que pour une VU
il faudra plutôt enlever du code
15
Le logiciel DCC++ / Re : DCC++ & Arduino Uno R4 WiFi
« le: avril 17, 2025, 12:21:56 pm »
Bonjour,
J'arrive ... tardivement sur ce topic intéressant : merci pour le partage !
A la sortie de l'UNO R4 , comme beaucoup , je l'avais balayé du revers de la main : trop cher , trop lent , gaspillage des broches du microcontrôleur Renesas.
Mais il avait des choses intéressantes , comme un fonctionnement en 5v , pratique pour le S88 , l'I2C, et les accessoires de mon cru , à base de 74HC595 ou de 74HC165 , entre autres ; ainsi que la présence d'un comparateur analogique , qui me sert pour l'interface avec Loconet.
Depuis peu , on trouve des clones chinois pour cette carte , dont les prix sont abordables ; concernant la lenteur (48MHz pour un cortex M4 , c'est très peu , comparé aux 133MHz double coeur d'un Pi Pico , imbattable en prix) . Là aussi , on doit pouvoir s'en sortir en utilisant la richesse des périphériques HW , le DMA , en hiérarchisant les priorités des interruptions ...
Je me suis donc -rapidement- (lire : même si ça m'a pris du temps , je n'ai fait qu'effleurer) , penché sur ce code , dans l'optique de voir si on ne peut pas le faire évoluer afin d'y incorporer un cut-out Railcom , proprement réalisé.
Le code de Matth_76 est brillant (pour peu que mon niveau définitivement crasse en C/C++ ne me permet pas d'en juger) , et surtout , très important pour moi , il respecte l'excellent travail de de Gregg E. Berman , en faisant générer des signaux nickels par un HW maîtrisé , ceci à l'opposé de certains qui on cru bien faire de le réécrire en SW , ce qui génère des approximations plus ou moins acceptables.
Pour générer le cutout avec le motor shield (officiel ou clone) , si on prend par exemple le canal A du motor-shield , il faut pendant le cutout , mettre la broche DIRA à LOW , en même temps que le la broche BRAKE-A soit au niveau HIGH. Je pense que c'est faisable , car le signal DIRA est sur le canal timer GTIOC6B , alors que le BRAKE-A est sur GTIOC7B . Il "suffit de" démarrer les timers 6 et 7 simultanément , et s'assurer par la suite qu'ils comptent les mêmes périodes : ainsi , les 2 timers resteront synchronisés . Pendant le cut-out , le BRAKE-A est donc à HIGH , et il reste sur LOW (duty=0) le reste du temps.
Le problème , c'est que le timer 7 est aussi (le seul) utilisé pour le signal BRAKE-B , donc sa sortie GTIOC7A : on ne peut donc pas également faire fonctionner le cutout sur la voie de programmation , c'est l'une où l'autre. (on pourrait faire fonctionner quand-même , en synchronisant les packets "main" et "programm" mais ce serait lourd , je préfère ne pas en parler). Édit ça doit être possible quand-même , voir post suivant.
Une solution , c'est de se passer du shield moteur , utiliser par exemple le POLOLU MC33926 MOTOR SHIELD . On n'est plus dans le mécaniquement stackable , mais on peut arranger le câblage pour trouver un timer libre pour le signal BRAKE-B ; le plus élégant serait de mettre DIRA et BRAKE-A sur le même timer , et pareil pour le B (sur le Pololu , ça s'appelle autrement , mais au final , ça marche pareil) . Dans ce cas , il serait aussi intéressant d'utiliser la carte genre gros NANO de chez WeAct , ce qui permet de retrouver les broches perdues du Renesas ; il faudrait alors aussi y raccorder un ESP32-S3 pour avoir le WiFi , en considérant les tensions différentes.
Voilà juste une 1ère réflexion , je n'ai rien testé.
J'arrive ... tardivement sur ce topic intéressant : merci pour le partage !
A la sortie de l'UNO R4 , comme beaucoup , je l'avais balayé du revers de la main : trop cher , trop lent , gaspillage des broches du microcontrôleur Renesas.
Mais il avait des choses intéressantes , comme un fonctionnement en 5v , pratique pour le S88 , l'I2C, et les accessoires de mon cru , à base de 74HC595 ou de 74HC165 , entre autres ; ainsi que la présence d'un comparateur analogique , qui me sert pour l'interface avec Loconet.
Depuis peu , on trouve des clones chinois pour cette carte , dont les prix sont abordables ; concernant la lenteur (48MHz pour un cortex M4 , c'est très peu , comparé aux 133MHz double coeur d'un Pi Pico , imbattable en prix) . Là aussi , on doit pouvoir s'en sortir en utilisant la richesse des périphériques HW , le DMA , en hiérarchisant les priorités des interruptions ...
Je me suis donc -rapidement- (lire : même si ça m'a pris du temps , je n'ai fait qu'effleurer) , penché sur ce code , dans l'optique de voir si on ne peut pas le faire évoluer afin d'y incorporer un cut-out Railcom , proprement réalisé.
Le code de Matth_76 est brillant (pour peu que mon niveau définitivement crasse en C/C++ ne me permet pas d'en juger) , et surtout , très important pour moi , il respecte l'excellent travail de de Gregg E. Berman , en faisant générer des signaux nickels par un HW maîtrisé , ceci à l'opposé de certains qui on cru bien faire de le réécrire en SW , ce qui génère des approximations plus ou moins acceptables.
Pour générer le cutout avec le motor shield (officiel ou clone) , si on prend par exemple le canal A du motor-shield , il faut pendant le cutout , mettre la broche DIRA à LOW , en même temps que le la broche BRAKE-A soit au niveau HIGH. Je pense que c'est faisable , car le signal DIRA est sur le canal timer GTIOC6B , alors que le BRAKE-A est sur GTIOC7B . Il "suffit de" démarrer les timers 6 et 7 simultanément , et s'assurer par la suite qu'ils comptent les mêmes périodes : ainsi , les 2 timers resteront synchronisés . Pendant le cut-out , le BRAKE-A est donc à HIGH , et il reste sur LOW (duty=0) le reste du temps.
Le problème , c'est que le timer 7 est aussi (le seul) utilisé pour le signal BRAKE-B , donc sa sortie GTIOC7A : on ne peut donc pas également faire fonctionner le cutout sur la voie de programmation , c'est l'une où l'autre. (on pourrait faire fonctionner quand-même , en synchronisant les packets "main" et "programm" mais ce serait lourd , je préfère ne pas en parler). Édit ça doit être possible quand-même , voir post suivant.
Une solution , c'est de se passer du shield moteur , utiliser par exemple le POLOLU MC33926 MOTOR SHIELD . On n'est plus dans le mécaniquement stackable , mais on peut arranger le câblage pour trouver un timer libre pour le signal BRAKE-B ; le plus élégant serait de mettre DIRA et BRAKE-A sur le même timer , et pareil pour le B (sur le Pololu , ça s'appelle autrement , mais au final , ça marche pareil) . Dans ce cas , il serait aussi intéressant d'utiliser la carte genre gros NANO de chez WeAct , ce qui permet de retrouver les broches perdues du Renesas ; il faudrait alors aussi y raccorder un ESP32-S3 pour avoir le WiFi , en considérant les tensions différentes.
Voilà juste une 1ère réflexion , je n'ai rien testé.