Messages

136

Vos projets / Re : décodeur dcc pour signaux sncf complexes, avec arduino nano (et pcb)

« le: septembre 16, 2022, 09:22:46 am »

Bonsoir Laurent,
merci,
merci pour les liens
en fait j'ai choisi un AVR classique (quoiqu'un peu exotique), pour pouvoir fonctionner en 5V : les 2 feux jaunes du  Ralentissement, comme ceux du rapPel sont en série, donc 3v3 ça suffit pas
pour les timers et le pwm, je connais (il y a longtemps, j'ai commencé à programmer les AVR en assembleur, bare metal total), donc une bibliothèque autre ne m'apportera rien (il y a désormais beaucoup de gens qui font des bibliothèques sans trop maîtriser leur sujet)
j'ai signalé à Aiko Pras la possibilité, voire la pertinence et la facilité, d'utiliser la fonction capture sur des AVR classiques ; il fera ce qu'il voudra
le nano every est chouette, mais même en clone, c'est 3x le prix des modules à LGT ... alors par les temps qui courent ...

137

Vos projets / Re : décodeur dcc pour signaux sncf complexes, avec arduino nano (et pcb)

« le: septembre 14, 2022, 11:46:49 pm »

les différents signaux peuvent avoir de 1 à 8 feux (les ralentissement et rappels comptent pour 1 feu, car leurs 2 leds jaunes sont câblées en série)
avec les variantes, ça me fait 14 types de signaux différents, c'est peut-être suffisant
la configuration de chaque arduino se fait au moniteur (arduino ou émulation terminal), je trouve dommage de devoir configurer des CV depuis une centrale quand on dispose de l'USB !
il y a un petit menu ; on saisit une lettre pour dire qu'on veut configurer, puis on saisit :
- l'adresse de base
- le type (parmi 14) du 1er signal raccordé
- puis le type des signaux suivants, j'usqu'à ce que toutes les sorties soient occupées
au fur et à mesure des saisies s'affichent les types, l'adresse de chaque indication, le branchement de chaque led, le nombre de leds qui peuvent encore être branchées
dans mon exemple, à la fin, il restait une sortie libre, j'y ai représenté une led, qui peut servir dans le décor, par exemple, en utilisant une adresse ; on peut aussi configurer en sortie permanente, HIGH ou LOW, donc pas besoin d'adresse
quand la config est terminée, le menu propose d'appuyer sur une touche pour sauvegarder la config  ... is that simple
il y a quelques sorties CV (commun voltage, en orange sur le dessin) réparties le long des borniers

au démarrage l'arduino va rechercher la config dans l'eeprom et la place dans la ram
après mûre réflexion, et lecture studieuse du réglement S1A, j'ai retenu l'odre suivant pour les indications :
Ve,Se, Vc,Av, Sc,Ac, Ca,Cv, Pe,Pc, Ra,Rc, M,Mc (Pe c'est le rapPel 30 et Pc le rappel 60, c pour clignotant)
on a donc 14 indications, soit 7 adresses pour le signal le + complexe
Et que c'est pas fini
bien entendu, l'oeilleton est géré, il s'alume et s'éteind en fonction des indications
il y  a aussi les indications combinées : Pa+Av, Pa+Ac, Pc+Av, Pc+Ac, et Rc+Ac, ; elles s'obtiennent simplement en commandant à leur tour les indications compatibles, par exemple si on veut le rapPel 60 + l'Avertissement, on commande d'abord le Pc, puis on commande l'Av, et on obtient Pc+Av
Pc+Av peut aussi être obtenu en commandant d'abord Av, puis Pc
si maintenant on commande le rappell 30, Pe, on obtient Pe+Av, car les 2 indications sont compatibles, il n'y a pas lieu d'effacer l'Av
par contre, si on commande par la suite, par exemple le Ralentissement 30, Ra, le R s'affiche tandis que le A doit s'éteindre progressivement

progressivement ? of course ! alors un peu de technique
bien qu'il doit être possible de lui adapter mon code, j'ai laissé de côté le nano classique au profit du LGT8F328P, car il permet de faire + pour moins cher
j'ai notamment besoin de + de vitesse (32MHz) et d'un 2ème timer à 16 bits, le timer 3
le timer3 me sert à piloter le pwm des leds (19 ou 32 leds suivant le modèle) , selon une rampe de type exponentielle avec une précision de 10 bits sur 45 pas
le timer1 me sert à mesurer les durées des impulsions DCC, avec une précision de 1/2us ; j'utilise l'entrée capture du timer : cela me permet d'avoir une mesure exacte, même si une autre interruption est en cours au moment de la transition du signal DCC, et aussi de disposer d'un filtre qui élimine automatiquement les éventuels parasites du signal ; la suite du décodage se fait selon la bibliothèque d'Aiko Pras, que j'ai adaptée (facilement) pour avoir la fonction capture sur un AVR de type classique

en vrac :
l'ordre de câblage des feux des signaux est le suivant (ça suit peu ou prou l'ordre des indications) : V, S, A, C(ouCv), O, P, R, M ; dans l'exemple , j'ai des signaus de type S,A,V, R (ou S,A,R,V, je ne sais pas, en tous cas chez moi c'est V,S,A,R) : si on suit l'odre des feux comme indiqué ci avant, il faudrait laisser libres les sorties correspondant aux feux C(carré) et O(oeilleton) : j'ai donc créé un type (le 42), qui permet d'éviter ça et de câbler le R directement à la suite du A (on économise 4 sorties dans l'exemple)
j'ai laissé tomber le choix alim par DCC ou dédiée par cavalier : comme le montre l'illustration, si on veut alimenter par le DCC, il suffit de ponter les sorties DCC et alim sur le dernier bornier en bas (notons que chez trimarco232, le câblage des modules suivants est évident, pas besoin de faire de dérivation...)
pour avoir des feux qui s'allument alors que d'autres s'éteignent sur un même signal, on peut avoir jusqu'à 5 leds qui s'alument ou s'éteignent simultanément et progressivement (par exemple, l'indication Ca qui suit l'indication Pe+Av : on a les feux P+A+O qui s'éteignent progressivement, alors que les feux S+C s"allument pareil) ;  j'ai donc 5 tableaux de 8 lignes (le nombre de feux) et 19 colonnes (le nombre d'indications), en PROGMEM, qui me donnent instantanément ce que chacune des 5 leds doit faire, sans que l'AVR n'ait à effectuer le moindre calcul ; c'est un peu fastidieux, mais comme la CPU doit aller vite c'est la bonne méthode ; en principe perso, alors que certains en sont à l'intelligence artificielle, je programme complètement à plat, c'est l'intelligence zéro, tous les cas sont listés, puis pour chaque cas j'ordonne au cpu ce qu'i doit faire

on va terminer par un petit quizz :
dans l'illustration il y a une petite erreur au niveau du câblage, laquelle ?
dans l'ordre des indications, j'ai mis Vc (vert clignotant) dès la 3ème position (2ème adresse, 1ère position), pourquoi ?

138

Vos projets / Re : décodeur dcc pour signaux sncf complexes, avec arduino nano (et pcb)

« le: septembre 14, 2022, 09:42:19 pm »

les 2 1ers prototypes fonctionnent, ils seront mis en service sur le réseau prochainement
Edit : suite à l'adoption définitive de la technique "capture" du timer1 pour mesurer la durée des 1/2 bits DCC, les prototypes sont disponibles à la vente grâcieuse, (ou à la casse)
j'ai finalement opté pour + de souplesse
un petit dessin pour illustrer le principe : les leds des signaux se raccordent à la suite, il n'y a pas de séparation gauche droite, mais une continuité :
à gauche leds 1 à 10  ↓_↑  leds 11 à 19 à droite
exemple de câblage des signaux sur la 2ème carte dans l'illustration

139

Vos projets / Re : décodeur dcc pour signaux sncf complexes, avec arduino nano (et pcb)

« le: août 02, 2022, 02:07:03 pm »

même pas 1 scud ...
j'ai déniché une version rallongée de nano à lgt8f328p ; elle utilise le même mcu, mais en 48 broches
j'ai dessiné dans la foulée une carte pour celui-ci, en voici une image avec placement des composants en vue d'une réalisation par le service PCB Assembly de chez jlcpcb :
(il y a quand même dans les 70 résistances, on comprendra que j'ai préféré confier cela à un robot)

140

Composants / Re : LGT8F328P peut remplacer ATMEGA328P, notamment sur un nano

« le: juillet 25, 2022, 11:18:31 am »

Bonjour,
un peu de neuf https://forum.arduino.cc/t/lgt8f328p-et-le-grofonano/1015817

141

Vos projets / Re : décodeur dcc pour signaux sncf complexes, avec arduino nano (et pcb)

« le: juillet 24, 2022, 12:05:16 pm »

c'est du très classique : on a un nano avec des résistances et des borniers ; on y ajoute une alim et l'optocoupleur du dcc
j'ai imaginé le système de résistances suivant :
celles (cms) qui sont sous le nano sont là pour la protection ; elles ont une valeur minimum (470R), autorisant toutes les manoeuvres hasardeuses en aval du nano
à côté du nano, en série avec les résistances de protection, il y a en // 2 types de résistances :
- les cms ont la valeur maximum qui correspond aux leds consommant le moins (rouge, jaune, vert) ; j'ai fixé cette valeur maximum à 3k3, ce qui doit correspondre à 1 mA pour les leds rouge, vert et jaune ;
- les tht 1/8w permettent de réduire la résistances selon la consommation des leds (blanc, violet) ou selon la tensions de seuil (blanc, violet, 2 jaunes en série) pour cela, je me munis d'un assortiment de 1/8w, qui me permettra d'ajuster au cas par cas
.
les 2 borniers ont la configuration suivante
côté gauche
9   8   7 +  6   5   4  +  3   2   1  +
USB
+ 10 11 12 + 13 14 15 + 16 17 18
côté droite
les numéros des sorties sont continus entre le bornier de gauche et le bornier de droite
le + peut aussi, globalement par cavalier, être un - selon l'électrode commune
il y a une 9ème broche, réservée pour un fonctionnement avec des nanos à lgt328p, qui peuvent faire fonctionner leurs broches A6 et A7 en sorties
après 2 prototypes à 19 sorties (19 feux), j'ai réalisé une série de 5 en version "définitive", en utilisant le module avec la puce à 48 broches, ce qui me fait 32 sorties (32 feux en tout)
.
plus qu'à faire la mise au point ....
l'idéal, serait d'avoir une souplesse maximale, afin d'économiser au mieux les broches et les adresses ...
j'ai donc défini plusieurs configurations devant devant satisfaire la grosse majorité des besoins :
// pm les 14 indications (sauf combinées): 00Se, 01Ve, 10Av, 11Vc, 20Sc, 21Ac, 30Ca, 31Cv, 40Pe, 41Pc, 50Ra, 51Rc, 60Ma, 61Mc
// les config sont :
// 8 : 8 feux, 7 adresses : 1fV, 2fS, 3fA, 4fC, 5fO, 6fP, 7fR, 8fM //
// 7 : 7 feux, 6 adresses : 1fV, 2fS, 3fA, 4fC, 5fO, 6fP, 7fR //  00Ve, 01Se, 10Av, 11Vc, 20Sc, 21Ac, 30Ca, 31Cv, 40Pe, 41Pc, 50Ra, 51Rc
// 6 : 6 feux, 5 adresses : 1fV, 2fS, 3fA, 4fC, 5fO, 6fP //  00Ve, 01Se, 10Av, 11Vc, 20Sc, 21Ac, 30Ca, 31Cv, 40Pe, 41Pc
// 5 : 5 feux, 4 adresses : 1fV, 2fS, 3fA, 4fC, 5fO //  00Ve, 01Se, 10Av, 11Vc, 20Sc, 21Ac, 30Ca, 31Cv
// 4 : 4 feux, 4 adresses : 1fV, 2fS, 3fA, 4fC  //  00SV, 01Se, 10Av, 11Vc, 20Sc, 21Ac, 30Ca, 31Cv /// pertinent ?
// 41 : 4 feux, 3 adresses : 1fV, 2fS, 3fA, 4fC //  00Ve, 01Se, 10Av, 11Vc, 20Ca, 21Cv // ligne spéciale
// 42 : 4 feux, 4 adresses : 1fV, 2fS, 3fA, 4fR //  00Ve, 01Se, 10Av, 11Vc, 20Sc, 21Ac, 30Ra, 31Rc // traitement spécial
// 3 : 3 feux, 3 adresses : 1fV, 2fS, 3fA       //  00Ve, 01Se, 10Av, 11Vc, 20Sc, 21Ac
// 31 : 3 feux, 2 adresses : 1fV, 2fS, 3fA      //  00Ve, 01Se, 10Av, 11Vc
// 2 : 2 feux, 2 adresses : 1fV, 2fS //  00Ve, 01Se, (10Av) 11Vc typiquement pour M, Cv, et Mcli // (10Av) interdit
// 21 : 2 feux, 1 adresse : 1fV, 2fVS  //  00Se, 01Ve  pour Cv, M
// 1 : 1 feux, 1 adresse : 1fV // nécessite une condition de nombre de feux, /// comme pour le 3ème Cv et l'A
// 10 : 1 sortie permanente à LOW
// 11 : 1 sortie permanente à HIGH
.
je partage très en amont du projet, c'est pour recueillir vos questions, suggestions, scuds ...

142

Vos projets / décodeur dcc pour signaux sncf complexes, avec arduino nano (et pcb)

« le: juillet 24, 2022, 10:21:38 am »

Bonjour,
le décodeur pour signaux sncf à 4 feux, dont j'ai pu écrire un .ino qui fonctionne, est adapté à beaucoup de situations, et économise aux mieux les adresses
il lui manque la gestion des signaux complexes, du clignotement et de la gradation
je me lance dans ce projet dans le but de remplacer les décodeurs sncf LDT d'un ami : c'est pénible (pour moi) à configurer, je ne suis pas parvenu à les faire fonctionner à partir de sa centrale ECOS
l'avantage de l'arduino (entre autres), c'est le moniteur, on pourra depuis le moniteur, regarder ce que la centrale envoie aux addresses du décodeur, et faire un petit menu qui permettra de configurer confortablement le décodeur
en tant qu'homme du hardware (autoproclamé) , j'ai commencé par dessiner un petit pcb, que je vous joins, si vous aimez les images

143

Vos projets / Re : les centrales dccà esp32 de trimarco232

« le: juillet 12, 2022, 02:06:39 pm »

je n'ai malheureusement pas pu (ou su ...) adapter la méthode du pwm à la génération du signal cutout ; il s'en suit une approximation d'environ 1us
on utilise un des 4 timers à disposition, pour générer une impulsion qui elle même générera une isr à sa fin
dans l'isr on inscrira le début du cutout, puis la fin
d'abord, dans les déclarations, on créé un pointeur du type hv_timer, qu'on nomme "cutout_timer" :

Code: [Sélectionner]

hw_timer_t *cutout_timer = NULL; // puis, dans le setup, on créé le timer et on lui colle une interruption
ici, le "0" c'est le n¨du timer (parmi 4) ; le "80", c'est le prescaler, qui va nous faire battre le timer à 1MHx (période = 1us) ; par "&on_cutout_timer" on donne le nom de l'isr qui se produit quand le timer a atteint sa consigne ; "true" veut dire que les opérations se font sur fronts montants

Code: [Sélectionner]

cutout_timer = timerBegin(0, 80, true); // config cutout timer - 1us -
timerAttachInterrupt(cutout_timer, &on_cutout_timer, true); // allow cutout timer interruptpuis on initialise le timer, dans la l'isr qui se produit à chaque front montant du signal dcc pwm
la variable bits_sent compte les bits dcc 1 du preamble :
au 1er bit on initialise le timer avec les 26us, au 4ème on l'initialise avec 104us

Code: [Sélectionner]

void IRAM_ATTR dcc1sig_isr() {
  static uint8_t bits_sent ; // compte tous les bits du préamble
  bits_sent++ ;
if (bits_sent == 4)   { // tempo déclenchée au 3ème bit du preamble
   timerWrite(cutout_timer, 0) ; // clear cutout timer
   cutout_time_us = 58*2 -12 - 4 ; // -4 pour compenser le manque de réactivité
   timerAlarmWrite(cutout_timer, cutout_time_us, false); // configure timer 104us
   startstop_cutout = 2 ; // dit à l'isr ce qu'elle doit faire
   timerAlarmEnable(cutout_timer);  //enable interrupt
  }
else if (packet_bit_pointer == 1)  { // tempo avant cutout déclanchée au bit stop
   timerWrite(cutout_timer, 0) ; // clear cutout timer
   cutout_time_us = 58*2 + 26 - 4 ; // -4 pour compenser le manque de réactivité ...
   timerAlarmWrite(cutout_timer, cutout_time_us, false); // configure timer 26us
   startstop_cutout = 1 ; // dit à l'isr ce qu'elle doit faire
   timerAlarmEnable(cutout_timer);  //enable interrupt
   bits_sent = 0 ;
}enfin l'isr, sans commentaire :

Code: [Sélectionner]

void IRAM_ATTR on_cutout_timer()  {
if ( startstop_cutout == 1 )  { // début du cutout
  digitalWrite(Pwm1piN, HIGH);
}
else if ( startstop_cutout == 2 )  {
  digitalWrite(Pwm1piN, LOW);
}
}ceci fonctionne pour des ponts en H tels le lmd18200, qui ont une entrée dir (signal dcc) et un entrée pwm (signal booster/cutout)
pour les autres, il faut adapter
... 3 captures pulseview pour illustrer la chose :

144

Vos projets / Re : centrales dcc esp32 trimarco232

« le: juillet 12, 2022, 01:13:56 pm »

le timing du cutout est, je trouve, pas très biendécrit dans la norme ; heureusement le site "open dcc" nous donne + d'explications ; pour l'instant j'ai adopté le timing avec les 4us de marge, préconisées par Wolfgang Kufer ; ça nous donne ça (voir la pj.)
le cutout intervient 26us après le début du 1er bit dcc du preamble, et se termine 104us après le début du 4ème bit dcc du preamble

145

Vos projets / Re : centrales dcc esp32 trimarco232

« le: juillet 12, 2022, 12:55:31 pm »

bonjour à tous
parlons du cutout pour la lecture des signaux railcom
pour mémoire, "mes" signaux dcc sont générés par une méthode simple qui consiste à utiliser un signal pwm dont on change la période (la fréquence en fait, c'est pareil) selon le besoin
petite illustration :

146

Shields et Modules / Re : "extension 4 feux pour le décodeur de signaux à 2 ou 3 feux"

« le: juillet 12, 2022, 12:38:10 pm »

bonjour,
félicitations à Pierre, l'audace (car il en faut à ce stade) a payé 
j'avais édité mon pgm, principalement pour clarifier les commentaires, mais peut-être un loup s'y est glissé
quoiqu'il en soit, adopter le pgm de msport me semble la bonne option, car msport a déjà (si j'ai bien suivi) fait quelque chose pour adapter ça aux logiciels qui décalent les adresses : on aura bien un jour une demande en ce sens, msport sera prêt 
je laisse mon pgm pour mémoire, ça sera peut-être utile quand on envisagera les allumages et extinctions progressifs

147

Vos projets / Re : décodeur dcc à uln2003 pour moteurs d'aiguille type mtb, et extensions à 74hc595

« le: juillet 02, 2022, 10:30:18 am »

Bonjour merci pour vos retours,
.
à CATPLUS
la solution d'avoir une capa par paire de solénoïde est indiquée dans le cas d'une commande manuelle, et simplifie en effet le programme dans le cas d'une commande électronique
pour ma part, je préfère la solution avec une seule capa côté maître (celle de la CDU) : ça oblige à commander les aiguilles à tour de rôle, mais économise des capas et simplifie le dessin des commandes par mosfet ; c'est montré ici : https://forum.locoduino.org/index.php?topic=1433.msg15526#msg15526
.
à MARC-HENRY
j'ai déjà en service un poste d'aiguillage à base de CDU et de commande de peco avec du 24v (capa de 35v), le tout avec des 74hc595 et des mosfets ; il n'y a pas de problème de parasites, mais le tout est monté sur sur le même circuit imprimé, il faudra en effet voir ce que ça donne avec un maître et des extensions
en tous cas la version à uln2003, ici, est destinée aux moteurs type mtb

148

Vos projets / décodeur dcc à mosfets pour aiguilles à solénoïdes, et extension à 74hc595

« le: juin 29, 2022, 04:10:31 pm »

Bonjour,
de me suis finalement décidé à dessiner ce décodeur
la base est la même que que le décodeur à uln2003 https://forum.locoduino.org/index.php?topic=1431.0
les uln2003 sont remplacés par de petits mosfets en boitier double sot23-6 ; les caractéristiques de ces mosfets sont 30v, 2A5 continu et 10A pulsé
cela suffit peut-être pour du peco ou du seep, mais je l'ai plutôt prévu pour des solénïdes de roco, fleischmann, trix ...
le dispositif de protection prévu pour les mosfets utilise des NUP2105L, normalement faits pour protéger les lignes CAN, est ambitieux, optimiste ou raisonnable, en tous cas pas encore évalué, on est donc sur de l'expérimental pour cette partie
je ne conçois pas de commande de solénoïde sans dispositif CDU, même si les moteurs sont munis de fin de course ; il vaut même mieux, amha, mettre les fins de course hors service et utiliser le cdu
ici, le cdu est un peu particulier : l'alim se fait en 10-12v, et les tensions nécessaires aux solénoïdes sont 16v, voire 24v pour du peco ; on a donc un convertisseur dcdc boost qui charge la capa cdu à la tension voulue ; l'arduino peut choisir cette tension entre 2 valeurs (par ex 16v ou 24v), on peut donc panacher les moteurs d'aiguille ; le CI convertisseur dcdc est aussi en boitier sot23-6 : c'est un MT3608
le cdu doit stopper la charge de la capa cdu tant qu'il y a une consommation au niveau des solénoïdes : c'es le rôle de l'électronique de contrôle située à droite de la capa cdu (on intervient "simplement" sur la broche enable du CI convertisseur dcdc)
l'arduino mesure aussi la tension de la capa cdu, le but c'est d'attendre qu'elle doit rechargée avant de commander la décharge suivante
en pj, un dessin du décodeur avec l'identification des différentes parties
bien entendu, il y a aussi les cartes d'extensions, visibles en situation sur la 2ème pj

149

Vos projets / Re : décodeur à uln2003 pour moteurs d'aiguilles type mtb, et extensions avec 74hc595

« le: juin 26, 2022, 09:05:05 pm »

la carte décodeur dcc est pilotée par un nano, il y a l'optocoupleur rapide dcc, un module dcdc 5v (option, si on ne peut pas utiliser le 5v du nano), 3 uln2003 et 2 74hc595 ;
j'ai préféré  mettre 3 uln2003 à la place de 2 uln2803, car c'est finalement moins encombrant, d'avantage disponible, et globalement moins cher ... de + ça permet de doubler certaines sorties, utile s'il faut + de courant ;
j'ai mis 2 74hc595 ; le but est de libérer des broches du nano, mais aussi d'appliquer un pwm à l'entrée OE des 74hc595, ce qui permet de moduler la puissance appliquée aux moteurs ; les broches libérées permettent de créer 2 liaisons de type spi (une à gauche, une à droite), pour piloter les cartes d’extension à base de 74hc595 ; les broches en rab sont sorties sur le bornier du bas, agrémenté quelques lignes d'alimentation ;
les cartes d'extension sont comme le décodeur, moins l'optocoupleur, le nano, et le convertisseur dcdc ; les cartes à implanter à gauche sont (légèrement) différentes de celle à implanter à droite, mais incompatibles entre elles ;
une astuce, je commande le pwm des 74hc595 par la ligne du latch ; c'est faisable dans cette application, cela me permet d'économiser un fil ; (cette idée m'est venue tardivement, ça m'a fait modifier tous mes dessins déjà réalisés ...)
la connectique, tant pour les aiguillages ou les modules entre eux, laisse le choix entre des borniers à visser au pas de 3.5, ou des nappes jst xh au pas de 2.5 ;
je n'ai pas chiffré le coût, mais je pense que ça reste très bas par rapport aux produits du commerce ; à part le nano, dont le prix des clones a grimpé, la disponibilité des composants choisis n'a jamais posé de problèmes ; il me faut 2 jours (ou 1 jour et 1 nuit pour dessiner la carte décodeur dcc)
.
le soft reste à faire .. il faut :
- mettre les commandes dans une queue et les actionner à tour de rôle ; (supprimer les commandes contradictoires dans la queue)
- dans l'idéal, je verrais une petite ihm, qui invite depuis la console à saisir et à placer dans l'eeprom quelques paramètres, tels : nombre d'extensions à gauche et à droite, adresse de base, taux du pwm ... cela permettrait à un non arduiniste de paramétrer confortablement le truc (le téléversement du firmware étant effectué), une option qui amha fait souvent défaut dans notre sphère

150

Vos projets / décodeur dcc à uln2003 pour moteurs d'aiguille type mtb, et extensions à 74hc595

« le: juin 26, 2022, 08:15:03 pm »

Bonjour,
j'avais dessiné des modules d'extension qui permettent de commander des moteurs type mtb (à la rigueur, ça peut marcher avec des solénoïdes à faible consommation genre fleischmann)
emporté par mon élan, j'ai aussi dessiné un décodeur dcc qui peut servir de maître pour ces modules : la capacité est impressionnante

(j'ai aussi sous le coude des modules à mosfets costauds (pour peco), ou moyens (pour tous solénoïdes raisonnables), le tout commandé par "ma" centrale
je dessinerai peut-être un décodeur maître pour ceux-cis, (s'il y a une demande), un peu moins simple car j'y ajouterai une cdu à xl6007)
édit : le décodeur dcc pour solénoïdes courants (roc, flesichmann, trix ...) est dessiné, voir l'article https://forum.locoduino.org/index.php?topic=1433.msg15526#msg15526

une image, en attendant :