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

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

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

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

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

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

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

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

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

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

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

11
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

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

13
Composants / Re : Compatibilité PCA9685 et DFPlayer
« le: mars 18, 2025, 02:28:05 pm »
c'est singulier (sans jeu de mot) ; peux-tu mesurer le 5v , avec les servos et le DF en "service" ?

14
Composants / Re : Compatibilité PCA9685 et DFPlayer
« le: mars 17, 2025, 11:20:57 pm »
Bonjour,
est-ce que le DFPlayer seul sur le mega , ça fonctionne ?

15
Les réseaux / Re : décodeur LOCONET pour moteurs MP1
« le: février 10, 2025, 03:05:09 pm »
↑ L'Arduino , ici un modèle spécial , noir , à STM32 , commande une rangée de 4 ULN2003 (réseau de 7 Darlington) ; en haut il y a la connectique vers les moteurs , au choix des connecteurs JST XH , ou des borniers à visser au pas de 3.5mm
En bas , on a la rangée des 16 leds indicatrices
Le choix de l'arduino (programmé sous STM32duino) , s'est imposé car je voulais quelque chose d'assez puissant , avec des convertisseurs ADC de qualité , et 16 sorties PWM pour disposer du pwm pour chacune des 2 commandes de chacun des 8 moteur
Du coup , l'arduino à STM32F103RVT6 , 64 broches (le STM32 est situé , avec le CH340 pour l'USB , au dos du pcb de l'arduino , pour gagner de la place) , peut également commander directement les 16 leds , il "suffit de" faire le routage des pistes
Cet arduino , malgré les gains de place , grâce aux doubles rangées de broches et aux implantations sur les 2 faces , reste relativement imposant , d'où un encombrement du décodeur qui dépasse un peu ce que je fais d'habitude
Comme l'alim 12V dc , l'interface loconet traverse le pcb , afin de permettre de les chaîner facilement , et d'avoir un câblage fluide ; la connectique est une RJ12 (6p6c) standard loconet , ou au choix un jst xh à 5 broches , "standard moi" ; pour s'interfacer à loconet , il faut un comparateur et un transistor : ces composants , avec leurs cours de résistances , sont placés sous l'arduino
La particularité , l'intérêt , le + , bref la motivation , s'observe sous la forme par exemple des 2 résistances , R11 et R12 , placées à droite du 1er uln2003 (vous les avez ?) . C'est des résistances de shunt , mise en série entre le GND de l'uln2003 , et le vrai GND du pcb (soit le 0v de l'alim 12v dc) ; il y a 2 résistances en // , c'est pour se partager la dissipation calorique , en toute sécurité ; la tension générée par ce shunt lors du fonctionnement du moteur , est mesuré pa un canal ADC du stm32 , cela permet d'avoir une image du courant consommé par le moteur ; des échantillons sont prélevés régulièrement pendant la course du moteur , comme ça :
--↑--↑--↑--↑--↑--↑--↑--↑--↑--↑--↑--↑--↑--↑--↑--↑--↑--↑--↑ etc , il y en a 80 , soit toutes les 50ms pendant 4 secondes ; la valeur des échantillons est simplement additionnée , la somme finale reflète la consommation (le "milliampérage") moyenne
les résultats des mesures tournent autour de la valeur 500 (je n'ai pas inventé d'unité pour ça) ; quand j'empêche le moteur de tourner en freinant le curseur avec le pouce , cela tourne autour des 1500 : d'une part , car le courant consommé par le moteur contraint est plus élevé , et d'autre part car le moteur met + de temps à atteindre sa fin de course , on aura donc d'avantages d'échantillons qui ne sont pas à la valeur 0v
En tous cas , l'anomalie de fonctionnement est bien détectée , je suis satisfait (voire soulagé , car c'est toujours gonflé de partir dans le dessin et le prix d'un pcb , sans expérimentation , ni même de calcul préalable)
Je vais pouvoir continuer , et même si j'ai bien avancé , ce n'est que la partie ludique du projet qui est réalisée : il reste encore beaucoup de travail
J'ai pu remarquer que les moteurs consomment + dans un sens que dans l'autre , par exemple 550 au lieu de 450 , alors que la conception symétrique du MP1 devrait donner un résultat proche de l'égalité ? On comprend pourquoi en observent le curseur : pour le sens où il consomme le + , il part d'abord un peu sur la gauche , avant de faire sa translation vers la droite : ceci est dû au fait que sur la couronne , le maneton qui entraîne le curseur , n'est pas bien en phase avec l'arbre de la came qui actionne l'interrupteur (inverseur) de course ; est-ce un problème général , ou le résultat des tortures infligées aux 2 moteurs qui me servent pour les tests ?
On verra bien ; Le cas échéant , j'ai les moyens électroniques et logiciels pour y remédier  8)
Edit du 18 fév 25 : l’asymétrie de course affecte tous les MP1 ; cela peut aussi être dû au moment de bascule de l'interrupteur , variable selon la profondeur actionnée par la came ; on ne peut pas demander mieux pour le prix , mais c'est dommage que le curseur parte d'abord pour aller forcer une lame qui est déjà collée , avant de prendre la bonne direction ; il faudra bien choisir , en fonction de sa longueur , la section de la corde à piano entre le moteur et l'aiguillage !
(+menues corrections)
Edit du 25 fév 25 : fin de la programmation pour la prise en compte / mise en attente des commandes (au bout de 2 jours , j'étais dans une impasse ; j'ai remis tout à plat le 3ème , et ça a fini par fonctionner) le décodeur encaisse très bien les commandes intempestives , improbables , surnuméraires , précipitées , et contradictoires , qui lui sont adressées !
prochaines étapes :
- implémentation de l'interface loconet selon ma méthode (ok (ouf) 14 mars 2025)
- gestion de la tension d'alimentation des moteurs = ajustement du pwm en fonction de cette tension
- implémentation du fonctionnement en locobuffer (interface loconet ↔ usb) : profiter de la puissance du stm32 et de sa grande capacité en ram , et de l'interface usb (de tout arduino) pour éviter d'avoir un appareil dédié

Pages: [1] 2 3 ... 25