1
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" ?
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
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 ?
est-ce que le DFPlayer seul sur le mega , ça fonctionne ?
3
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é
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é
4
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 :
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 :
5
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 »...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
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.
...
6
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
7
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.
8
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
9
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é ...
- 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é ...
10
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
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
11
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
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
12
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 ...
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 ...
13
Trucs & astuces / Re : Rétrosignalisation S88 et UNO
« le: novembre 17, 2024, 05:48:19 pm »
allez merci pareillement ! 
14
Vos projets / Re : Carte détecteur de présence 16 entrées RailCom
« le: novembre 15, 2024, 01:53:04 am »
Bonjour,
mystique , je ne pense pas , les choses sont peut-être même assez simples :
- il détecte , sans les décoder , la présence de signaux railcom sur le canal 2 , en correspondance avec le message dcc qui vient d'être envoyé : les décodeurs doivent au moins renvoyer un ACK
- il faut pouvoir , pour cette détection , traiter des petits signaux négatifs et en donner le signe : l'adc de l'xmega sait le faire , parce qu'il fonctionne en différentiel , et accepte des signaux j'usqu'à -0.3v (schottky de protection de la broche)
donc la seule info qu'on a , c'est la présence de la loco , avec son adresse dcc et son sens de placement ; les infos du genre vitesses de la loco ne sont pas décodées , il faudrait en effet + d'électronique pour ça
mystique , je ne pense pas , les choses sont peut-être même assez simples :
- il détecte , sans les décoder , la présence de signaux railcom sur le canal 2 , en correspondance avec le message dcc qui vient d'être envoyé : les décodeurs doivent au moins renvoyer un ACK
- il faut pouvoir , pour cette détection , traiter des petits signaux négatifs et en donner le signe : l'adc de l'xmega sait le faire , parce qu'il fonctionne en différentiel , et accepte des signaux j'usqu'à -0.3v (schottky de protection de la broche)
donc la seule info qu'on a , c'est la présence de la loco , avec son adresse dcc et son sens de placement ; les infos du genre vitesses de la loco ne sont pas décodées , il faudrait en effet + d'électronique pour ça
15
Trucs & astuces / Re : Rétrosignalisation S88 et UNO
« le: novembre 14, 2024, 11:57:00 am »
merci , pas de souci , on a une info , l'autre n'est pas importante