Messages

1

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

2

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 le code de Matth_76 , 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 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 , il faut 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).
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 , en considérant les tensions différentes.
Voilà juste une 1ère réflexion , je n'ai rien testé.
 

3

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

4

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 ?

5

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

6

Les réseaux / décodeur LOCONET pour moteurs MP1

« le: février 10, 2025, 01:46:52 pm »

Bonjour ,
le but de ce projet est de donner un retour d'info , sur le déroulement de la commande du moteur d'aiguille : notamment , si cela s'est mal passé , d'en tirer immédiatement les conséquences
cette info est dispo de 3 façons :
- une batterie d'une led rouge et vert , pour chacune des 8 aiguilles , soit 16 leds
- un message dans le réseau loconet , qui pourrait être un arrêt général d'urgence
- un détail des choses , sur la prise USB , en mode débogage (moniteur Arduino , par exemple

J'ai choisi loconet car j'avais déjà des manettes pour ce bus (le CAN est bien meilleur , mais n'est compatible avec rien)
Le décodeur fabriqué , ressemble à ceci :

7

Modélisation, Architectures logicielles et matérielles / Re : Re : Re : Re : Re : Protocole MFX : Retour d'information des décodeurs

« le: décembre 09, 2024, 02:21:59 pm »

...
Ils sont sans rapport avec un simple transfo suivi d'une capa. Et reproduire un tel filtre ne serait pas simple... Je n'ai rien trouvé d'équivalent dans le commerce qui soit cheap.

Ce qui contraindrait donc de les utiliser, pour l'immunité au bruit. Vu qu'on en trouve encore facilement, ce n'est donc pas un problème.
...

mais il faudra quand-même des condensateurs , et le transfo , et le capot du transfo , et le quartz , etc. ... le BOM ne sera pas des + simples

8

Modélisation, Architectures logicielles et matérielles / Re : Re : Re : Protocole MFX : Retour d'information des décodeurs

« le: décembre 08, 2024, 11:15:43 pm »

Perso , j'ai un Hantec , mais il n'a pas d'écran : USB vers le PC , donc moins cher et confort d'utilisation du 17" ... et comme il reste principalement dans son carton ,ben  c'est juste un petit carton

Pour l'application de Christophe, un scope 2 ou 4 voies pourrait être utile. Un analyseur logique ne traite que des signaux numériques type 3.3V ou 5V.

Seul un scope permettra de voir correctement un signal de retour à l'entrée d'un LC72725KV ou d'un LM393, de l'équivalent analogique à des niveaux faibles. La ou les autres voies du scope permettant de voir la data/clock RDS décodés, une 4ème pouvant capturer ce qui passait coté DCC. Le tout simultanément, sur le même appareil et écran.

(...)

il s'agit bien d'un scope , qui me semble-t-il existe aussi en 4 voies .. mais je crains qu'en effet , il ne marche que sur PC W
je suis sur W , car j'ai toujours eu des choses (HW et SW) qui ne marchent que sous W

9

Modélisation, Architectures logicielles et matérielles / Re : Re : Re : Protocole MFX : Retour d'information des décodeurs

« le: décembre 08, 2024, 11:11:36 pm »

alors à ce stade , je ne sais pas encore comment faire ;

Je finis par en être là moi aussi 

Le bruit pouvant être un réel problème. D'autant plus que contrairement à DDC, avec MFX, les  locos continuent d'être alimentées, si j'ai bien compris. Je n'ai aucune idée de ce que ce niveau de bruit pourrait être.
c'est aussi ce que j'ai cru comprendre , ça s'ajoute ou se retranche , c'est le changement de phase qui importe ; ce qui m'interroge , c'est que du coup , le signal émis va se courber , en débitant sur tous les récepteurs du secteur ...

Les moteurs arrêtent de tourner pendant ce "moment RDS"? Ou du bruit/signaux de la consommation des locos (moteurs alimentés en PWM) peut-il se superposer au signal "RDS"?j'en ai bien peur

Quoi d'autre pourrait être source de bruits, de courants susceptibles de perturber un récepteur à LM393?
pratiquement pas de liste exhaustive sur un réseau de MF

Les puces spécialisées auraient là un gros avantage: elles filtrent, pour ne recevoir quasi que le signal "RDS" à 52.63kHz. Ce qui ne serait pas le cas avec un banal montage à LM393. le transfo et le condensateur constituent un certain filter ...

Or le montage à LM393 fonctionnerait. Et le montage avec un PIC qui peut détecter un "bit ack" n'a pas de filtres non plus.


Edit: je suis repartit dans la doc MFX... Qu'est-ce qu'ils entendent par "pause"? Tout doit s'arrêter, pour des feedback non perturbés?

Je note au passage qu'il s'agirait d'un changement de phase potentiel toutes les 912us. 48 x 19us. Ou 57k63 / 48, un équivalent 1096 potentiels changements de phase par seconde, c'est peu. 1096 / 16, 68 octet max par seconde? 1 à 4 (ou 8 ) octets par message? Ce sont des "pauses" de 120ms, pour jusqu'à 8 octets? Et pendant ce temps là, les moteurs ne tournent plus?

Faut que je me lance dans des tests. Doit pas y avoir besoin d'une bête de course pour recevoir/décoder cela.

10

Modélisation, Architectures logicielles et matérielles / Re : Protocole MFX : Retour d'information des décodeurs

« le: décembre 08, 2024, 09:45:58 pm »

Perso , j'ai un Hantec , mais il n'a pas d'écran : USB vers le PC , donc moins cher et confort d'utilisation du 17" ... et comme il reste principalement dans son carton ,ben  c'est juste un petit carton

11

Modélisation, Architectures logicielles et matérielles / Re : Protocole MFX : Retour d'information des décodeurs

« le: décembre 05, 2024, 05:57:34 pm »

le principe de ce que je pense faire est le suivant :
- on ne s'occupe pas de l'impulsion de 19us en B , car celle-ci peut avoir été perturbée ; de même , une perturbation sur une impulsion de 9.5us pourrait nous faire croire qu'on est dans le cas B ; ce n'est donc pas la bonne solution
- ce que je propose , c'est d’échantillonner statistiquement en A , et d'en déterminer la phase ; de continuer (continuellement) l'opération , et de constater en C que la phase a changée ; une évaluation approximative du point de changement de phase suffit à déterminer le nouveau bit

alors à ce stade , je ne sais pas encore comment faire ; j'avais aussi pensé à échantillonner à 9.5us , mais si on se trouve près d'un flanc , et qu'on passe de l'autre côté parce qu'on est un peu moins rapide que l'émetteur , on verra un changement de phase erroné ...

12

Modélisation, Architectures logicielles et matérielles / Re : Protocole MFX : Retour d'information des décodeurs

« le: décembre 05, 2024, 12:10:23 am »

oui c'est une option à creuser ;
pour ma part , je préfère utiliser des arduino tout faits , avec l'alim , le quartz , la liaison USB pour télécharger et déboguer ; la mise en oeuvre est immédiate
un STM32 a aussi au moins un comparateur ; j'utilise également des arduino équipés de clones d'AVR , (voir minievb) : ça ne coûte rien , ça pédale à 32MHz , il y a 2 comparateurs , dont les sorties sont accessibles , pour vérifier avec l'analyseur que le comparateur fonctionne bien

13

Modélisation, Architectures logicielles et matérielles / Re : Protocole MFX : Retour d'information des décodeurs

« le: décembre 04, 2024, 10:53:35 pm »

j'ai un oscillo qui m'a coûté 50€ chez Ali , il est USB , donc il faut l'écran du PC , très bien , mais en effet , il reste dans son carton ; il aurait été utile pour faire de la BF ...
par contre , l"analyseur logique à 10€ , je m'en sers systématiquement , parfois pour "programmer à l"analyseur" , cad. triturer le code jusqu'à ce que l"analyseur montre les bons signaux ... ... ou bien ajouter un truc du genre PINB0 = 1 dans la loop , pour vérifier que le programme n'accroche pas anormalement quelque part , car on peut avoir l'impression qu'il marche bien , alors qu'il y a un gros bug ...
pour l'analyseur , prévoir un large ruban de dupont à l'avance , car cette merdre se met à foirer dès qu'on l'a enfichée et défichée l'une ou l'autre fois

concernant mon idée de capture + filtre , ça marcherait , mais c'est pas assez robuste : on risque en effet de louper le point de changement de phase , s'il y a une perturbation juste à ce moment là , et du coup , l'ensemble du message serait peru . En fait , ce qu'il faut détecter , c'est ... le changement de phase , cad. on constate qu'il y a une certaine phase , puis on conste que la phase à changé : l'évaluation n'est pas critique , du temps qui s'est passé entre les 2 changements de phase ; une phase dure 9.5us , donc il faudrait échantillonner environ toutes les 2us , et mettre un peu d'intelligence , pour déterminer ce qui se passe.
Donc pour un AVR , ça va trop vite. Un STM32 , genre G030 à 64MHz , le fera facilement , et un Pi Pico , aussi , mais le cœur serait très chargé avec ceci : si l'autre cœur est accaparé par le CAN , on ne pourra plus lui faire faire grand-chose d'autre.
Quoi qu'il en soit , je vais ressortir un Pico , lui faire générer un tel signal sur une broche , et voir si j'arrive à le décoder sur la broche d'à côté
en fait la seule question , demeure le hardware pour la détection au niveau de la centrale

14

Modélisation, Architectures logicielles et matérielles / Re : Protocole MFX : Retour d'information des décodeurs

« le: décembre 04, 2024, 06:10:39 pm »

Bonjour,
but now , I'm back , to let you now that :
1) sourcer ces ICs , c'est 0€39 , et il y en aura encre pour un moment : https://fr.aliexpress.com/w/wholesale-PT2579.html
2) décoder des signaux tels celui-ci preambule idle.JPG , il faut que je vérifie , j'ai peut-être une idée avec un STM32 : on utilise un module capture (yen a plein dedans) , et on configure son filtre digital de manière à ce qu'il ignore les impulsions courtes : on récupère les changements de phase , avec le temps qui les sépare ...

15

Trucs & astuces / Re : Rétrosignalisation S88 et UNO

« le: novembre 17, 2024, 05:48:19 pm »

allez merci pareillement !