LOCODUINO
Parlons Arduino => Vos projets => Discussion démarrée par: trimarco232 le octobre 03, 2023, 06:22:44 pm
-
un projet ambitieux dont je n'ai que franchi le seuil
le but est d'alimenter indépendamment chaque canton d'un réseau , avec un signal dcc ou analogique , en fonction de la circulation qui s'y trouve ; je n'ai aucune idée du logiciel PC qui pourra commander cela , mais je m'attaque gaillardement au hardware
il y aura une centrale avec toutes les interfaces (wifi , loconet) et la voie de programmation , et à côté , des boosters au nombre égal à celui des cantons
l'idée originale provient du club de Salzbourg , que j'avais vue à l'époque , et que je peux envisager de mettre en oeuvre avec les moyens d'aujourd'hui
cela ressemble à ça (la centrale à gauche n'est pas représentée)
-
la centrale communique avec les cartes booster par i2c , pour dire la configuration de chaque canton :
- analogique + duty (duty c'est le rapport cyclique du pwm , variable en analogique)
- ou analogique sens inverse + duty
- ou dcc
- ou dcc inversé pour les boucles
elle délivre un signal de synchronisation , car il faut synchroniser les pwm en analogique , ainsi que les signaux dcc
-
la synchro agit de 2 manières :
- le front montant donne le top qui synchronisera les timers des cartes booster (à 40ns près ...)
- la largeur de l'impulsion renseigne sur la nature du prochain bit dcc : exemple rouge = bit dcc 1 , bleu = bit dcc 0
-
les signaux analogiques seront donc contenus , sur la voie , dans le gabarit des signaux dcc :
- le signal dcc à un duty de 50% et une période qui peut être 200us (bit dcc 0) ou 116us (bit 1 dcc) ; le +15v et le Gnd (0v) s'inversent au milieu de la période
- le pwm analogique à un duty variable , selon la puissance demandée ; les polarités du duty peuvent s'inverser en fonction du sens de circulation ; la partie de la période après le duty est en haute impédance (il ne faut surtout pas inverser comme pour le dcc) ; la période étant variable selon le bit dcc (116 ou 200us) , il faut en tenir compte dans le calcul du duty : la carte booster disposera de 2 tables , pour s'éviter ce calcul
imaginons un réseau de 25 cantons : chaque booster à besoin de 2 signaux synchronisés pour sa commande , il faut donc produire 50 signaux synchronisés issus de différents timers ; chaque carte à besoin de 10 signaux synchronisés , j'ai choisi stm32duino pour réaliser ceci , les stm32 ayant des timers avec 4 sorties pwm , l'architecture des timers de la carte ressemblera à ceci :
-
le timer 1 aura le + de travail :
- réception de la synchro
- mesure de la largeur de l'impulsion de la synchro , grâce à un de ses 4 canaux capture/compare
- transmission en tant que master de la synchro , vers les 2 timers slave
- il est son propre slave pour la production de 2 signaux de commande pwm , utilisant 2 canaux capture/compare
les autres timers devront :
- recevoir la synchro en tant que slaves
- produire 4 signaux de commande pwm
les signaux en rouge sont internes au microcontrôleur , cela permet d'économiser des broches
à propos des signaux de commande pwm :
- je les appelle ainsi car ils sont produits par les 4 modules pwm de chaque timer
- il en faut 2 pour commander le pont en H de chaque booster , la logique est la suivante :
entrée du pont ------------ sortie
in1 = high , in2 = low ---- out1 = 0v , out2 = +15v : 1ère partie du bit dcc , ou duty du pwm analogique
in1 = low , in2 = high ---- out1 = +15v , out2 = 0v : 2nde partie du bit dcc , ou duty du pwm analogique (sens inverse)
in1 = low , in2 = low ----- out1 = out2 = high Z : 2nde partie du pwm analogique , ou arrêt
in1 = high , in2 = high --- out1 = out2 = Gnd : court-circuit pour le cutout railcom
-
Bravo Trimarco232,
C’est un beau projet ingénieux qui apporte un vrai potentiel aux réseaux complexes supportant différents types de machines.
C’est particulièrement bien expliqué et illustré.
Bon courage
Dominique
-
merci Dominique ,
(je viens de répondre à ton message que j'avais zappé mi-septembre)
pour le bravo , il faudra attendre un peu : je pense bien que le projet est viable , mais il me reste beaucoup des choses à écrire et à tester à l'analyseur logique , je les présenterai quand ça fonctionne
j'utilise beaucoup les possibilités du hardware , qui sont impressionnantes sur ce type de stm32 : on ne peut pas les expliquer juste en montrant du code , alors vous en verrez peu ; par contre elles sont parfois ardues , c'est pour ça que je fais les dessins utiles à ma propre compréhension
-
Bonjour Marc
Belle réflexion sur le sujet!
Il y a en effet matière à traiter différentes thématiques
Penses tu qu'un AVR type AVR DA DB DD, ou EA qui disposent aussi de quelques ressources intéressantes ( event, bus SPI, timers A et B multiples, ...) ne seraient pas aussi de bons candidats pour le hardware notamment via la lib DXCORE ? ( même si inferieur en puissance vs les ST32)
D'autres CPU comme le RP2040 ou les TEESNY voir un ESP32 ne te pariassent ils pas aussi intéressant comme candidat? (il doit bien exister des avantages et quelques limites pour chacun...)
Dans ton projet ne dois tu pas aussi des à présent intégrer un canal de retour d info qui devrait alors aussi gérer/mesurer quelques info clées ( occupation, consommation, cc, railcom,...?)
Le sujet est lancé!
Pour ma part hormis la LIB DCC NMRA qui supporte ( comme elle le peut) plusieurs types de CPU, je pense qu'il manque une/des lib capable(s) pour gérer efficacement et "simplement" le décodage du signal DCC sur STM32, (comme d autres hardwares) un peu comme AIKO PRA l a fait avec AP_DCC_LIBRARY pour les AVR et TINY des séries 0/1/2
Qu'en pensez vous?
Laurent
-
Bonjour Marc Bonjour Laurent
Belle réflexion sur le sujet! merci
Il y a en effet matière à traiter différentes thématiques
Penses tu qu'un AVR type AVR DA DB DD, ou EA qui disposent aussi de quelques ressources intéressantes ( event, bus SPI, timers A et B multiples, ...) ne seraient pas aussi de bons candidats pour le hardware notamment via la lib DXCORE ? ( même si inferieur en puissance vs les ST32) peut-être bien, mais en effet je dispose d'un module qui le fait , qui est + puissant , et qui est disponible pour pas cher , alors ...
D'autres CPU comme le RP2040 ou les TEESNY voir un ESP32 ne te pariassent ils pas aussi intéressant comme candidat? (il doit bien exister des avantages et quelques limites pour chacun...) je connais mal les TEENSY , il faudrait les essayer , mais là aussi le prix les écarte ; l'ESP32 et le PI PICO ont le grand avantage du wifi , mais je n'en ai pas besoin ici , et pour ce qui concerne les périphériques , malgré quelques possibilités vendeuses , ils sont très en deça du stm32 : par exemple , aucun canal capture , alors que "mon" stm32 en a au moins une vingtaine , dont 4 en 32 bits ...
Dans ton projet ne dois tu pas aussi des à présent intégrer un canal de retour d info qui devrait alors aussi gérer/mesurer quelques info clées ( occupation, consommation, cc, railcom,...?) voire l'i2c en bas du 1er dessin
Le sujet est lancé!
Pour ma part hormis la LIB DCC NMRA qui supporte ( comme elle le peut) plusieurs types de CPU, je pense qu'il manque une/des lib capable(s) pour gérer efficacement et "simplement" le décodage du signal DCC sur STM32, (comme d autres hardwares) un peu comme AIKO PRA l a fait avec AP_DCC_LIBRARY pour les AVR et TINY des séries 0/1/2
Qu'en pensez vous?
Aiko Pras utilise capture pour saisir le signal dcc , il serait facile de configurer un des canaux du stm32 pour avoir la même chose ; je l'ai fait avec un lgt8f328p = clone de nano , et ça marche très bien
Laurent
-
on va encore faire un peu de hardware , avant de mettre le projet en pause
on voit sur le 1er dessin que le signal de synchro va de carte en carte ; en imaginant , soyons fous , un réseau de 25 cantons , il faudra 5 cartes de 5 cantons , qui seront espacées d'environ 12cm entre elles ; cela fait 60cm pour le signal de synchro , ce qui peut entraîner des déformations gênantes
j'ai donc recherché dans le stm32 , quelque chose qui peut régénérer le signal au niveau de chaque carte , et j'ai trouvé un ... comparateur analogique
-
en vert , la synchro arrive par l'entrée + INP , et ressort par la sortie OUT
elle est comparée à la tension 1/2 Vcc , donc le comparateur fonctionne en simple suiveur
(l'entrée est analogique et la sortie digitale , c'est en quelque sorte un ADC à 1 bit instantané)
on voit aussi que j'ai mis du rouge et du doré sur le dessin , héhéhé ; c'est la sortie TIMx : elle permet d'aller , en interne , vers des entrées des timers (comme pour les AVR , mais en beaucoup + complet)
ainsi la sortie du comparateur , qui rappelons-le est le signal de synchro , ira aussi , en interne , vers :
1) (rouge) l'entrée trigger du timer1 , pour le synchroniser (le timer1 synchronisera à son tour les autres timers)
2) (doré) une entrée capture du timer 1 , pour permettre de mesurer la largeur de l'impulsion de synchro , et par là , l'info que cette largeur porte
je vous mets le dessin du timer , avec l'arrivée de ces signaux vers les 2 modules du timer
(au vu de ce timer , on imagine qu'on peut s'y amuser comme un petit fou , mais aussi au début , se tourmenter comme un vieux c...)
-
ces signaux internes permettent donc d'économiser 2 précieuses broches
et que c'est pas fini
le comparateur peut ne pas être mis en oeuvre , son entrée et sa sortie peuvent être de simples broches IO , qu'on peut utiliser en digitalRead ou en digitalWrite
cette possibilité est utilisée lors de l'initialisation de l'ensemble : la centrale (qu'on ne voit toujours pas à gauche du 1er dessin) , envoie un HIGH sur son fil de synchro ; puis elle envoie un message broadcast sur l'I2C , pour dire : "la carte 5 boosters qui a son entrée synchro à HIGH , a l'adresse I2C n°1" ; puis elle s'adresse à la carte qui a l'adresse I2C n°1 pour lui dire : "tu mets ta sortie synchro à HIGH" ; et ainsi de de suite , jusqu'à ce que toutes les cartes aient leurs adresses
à ce stade , on peut mettre les comparateurs en service, et commencer le jeu
il n'est donc pas nécessaire d'effectuer une action (straps , programmation) pour fixer les adresses
-
Bonjour, que ce passe t-il quand la locomotive est à cheval sur deux cantons ?
-
Bonjour ,
en effet , le logiciel qui pilote les trains devra gérer ça :
1) il faut que les 2 cantons aient la même tension (même forme de signal)
2) il ne faut pas d'autre locomotive à cheval aux autres extrémités des 2 cantons
-
Bonjour
En fait il faut un mécanisme de "réservation" des sections pilotée avec les mêmes instructions.
Cette allocation repose sur plusieurs paramètres:
=>taille du convoi
=>section source et de destination(s)
=>enchainement des sections ( avec lock car entre la tête et la queue de convoi il peut y avoir "enjambement" cas d une loco en tête et d un simple fourgon en queue avec éclairage et pas de consommateur intermédiaire. Dans le déplacement du convoi on a alors un "trou" de détection sur des sections courtes qui doivent garder la synchro.
C est d autant plus vrai en mode de réversibilité avec une loco en pousse...
J'ai volontairement utilise le terme de "section": en effet il y a le découpage "canton classique" et il y a des zones de transition comme par exemple un grill complexe d aiguillages qui est en quelques sorte un "canton sans zone d arrêt". C est indispensable en mode DC Analogique.
Il faut donc en tenir compte.
Par ailleurs y a t il aussi assez de ressources encore dispo pour intégrer "railcom" à la remontée d'info?
Laurent
-
(tout ceci reste à étudier en détail et à confirmer)
- le logiciel de gestion devra , pour l'analogique , indiquer quelles sections sont occupées (ou réservées) par quel train : ces infos qui sont typiquement délivrées pour renseigner un tableau optique
- pour la remontée des infos railcom , il est probable que les cartes cantons auront à faire un tri avant de les envoyer à la station
- concernant les types de cantons , sur les 5 que comportera chaque carte , il y aura :
3x cantons classiques avec une zone de détection centrale et une zone à chaque extrémité
1x canton en impasse avec une zone de détection centrale et une zone côté heurtoir
1x canton de transit avec juste une zone de détection centrale
(5 cantons classiques ne sont pas possibles car il manque des broches)
-
(tout ceci reste à étudier en détail et à confirmer)
- le logiciel de gestion devra , pour l'analogique , indiquer quelles sections sont occupées (ou réservées) par quel train : ces infos qui sont typiquement délivrées pour renseigner un tableau optique: en DCC itoo :)
- pour la remontée des infos railcom , il est probable que les cartes cantons auront à faire un tri avant de les envoyer à la station:
en fait en dehors de la simple remontée occupe/libre c est la possibilité de faire transiter d autres info 'dont RC)
- concernant les types de cantons , sur les 5 que comportera chaque carte , il y aura :
3x cantons classiques avec une zone de détection centrale et une zone à chaque extrémité
==>9 sections
1x canton en impasse avec une zone de détection centrale et une zone côté heurtoir
==> 2 sections
1x canton de transit avec juste une zone de détection centrale
==> 1 section
Sur la ventilation des sections et surtout je pense pour les 3 dernières je pense qu'il parait intéressant de penser à mettre si possible une certaine modularité d affectation
( a voir pour les 9 autres)
Cela aurait pour vertu d offrir plus de souplesse et d affecter les attributions "à la carte" pour les usages.
Cela serait alors au logiciel d'effectuer le mapping de chaque section selon les usages. Chaque section étant un clone fonctionnel (et pseudo hardware) de chaque autre.
mais peut être y a t il des limitations pour mettre cela en œuvre de cette façon?
L avantage que j y vois repose sur une modularité optimale notamment dans des cas de grills de gare avec des voies ( passage , garage, impasses, sas, des zones "pleines" d aiguillage avec des cisaillements entre autre :) et ou toute une logique d optimisation doit s opérer. Ainsi sauf à prévoir des cartes avec des répartitions différentes du modèle standard on distribue au plus juste des besoins.
Mais de toute façon il faudra bien des cartes complémentaires pour la gestion des aiguillages voir de la signalisation donc... il y a peut être plusieurs façon d'aborder le sujet.
(5 cantons classiques ne sont pas possibles car il manque des broches)
Peut être a utiliser pour des usages tel que détection de CC, mesure FCEM,... hygrométrie, Age du capitaine,...
Laurent
-
la limitation , c'est la détection en analogique , qui pour ne pas compliquer les choses , se fait sur le coupon de rail à la polarité négative , nécessairement à gauche dans le sens de circulation
les zones aux extrémités seront détectées par diode -> ADC ; pour la zone centrale , je ferai des tests pour déterminer si la mesure de consommation du pont en H donne satisfaction , du point de vue de la sensibilité ; il faudra aussi y mettre les diodes pour l'équilibre
-
Bonsoir Marc
A ce stade je relayerai bien la détection via opto coupleur... efficace et éprouvé. Mais avec double de diodes dans chaque sens pour maximiser le VDROP.
Au format SMA ca prendra sans encombre 3A, c est un peu "gros" a caser mais c est du costaud...
Je me suis demande a un moment si ce n est pas par un une mesure de courant via LM358 ou ACS712 à defaut des feu MAX471 ou autres nouveaux GY-169 n cie.... qu'il faudrait passer??
Voir à l époque les échanges sur le satellite v2 pour lesquels il avait même ete question d ajouter un transistor en plus... peut être luxueux in fine, à voir donc... et les echnags également autour de la mesure de courant avec ces composants dans la rubrique indouine.
Si on état sur un AVR ( serie 0/1/2) on aurait je pense pour une zone 1 entrée ANALOGIQUE pour la mesure de conso afin de vérifier la détection "over" en cas de cc et l autre pour la mesure de tension. Les PWM par paire "drivent" alors 3 pont H à 2 entrees IN1 IN2 ou 6 PINS PWM directement mais avec ajout de 2 PINS par pont pour les inversions de sens.
Sur un 48 broches tout rentre. Sur un 32 on doit être un peu plus à l étroit
La ou je seche sur ce modele c est pour la synchro mutli zones entre AVR... via SPI? Autre solution magique?
C est la que tu vas nettement apprécier les apports du STM32 maos costaud :)
bon y a encore qq morceaux a mettre dans l equation...
Laurent
-
bien sûr , on pourrait ajouter 1 tas de choses , mais c'est précisément ce que je ne veux pas faire
-
(il serait peut-être bien de scinder la rubrique en "projets persos" et "projets officiels" , pour éviter les chassés-croisés)
j'ai fait sur stm32 la maquette d'un moteur qui génère les synchros en fonction des packets à envoyer , cela donne ceci
-
la ligne D0 est la synchro : une largeur d'impulsion de 10us indique que le prochain bit dcc est 1 , 20us si le prochain bit dcc est 0
j'ai illustré une impulsion de 10us , qui dicte au timer esclave d'envoyer un duty de 58us (le timer esclave n'a rien d'autre à faire)
on voit des alternances d'impulsions de 10 et 20us , commandant des alternances de bits dcc 1 et 0
quelque soit la largeur de l'impulsion , il faut que la synchro respecte la durée du bit dcc en cours
les lignes D1 et D2 sont les sorties d'un timer correspondant aux entrées IN1 et IN2 d'un pont en H : on voit que D2 est l'inverse de D1
pour le cutout c'est un peu moins simple :
une impulsion de synchro de 30us est envoyée lors du "packet end bit" ("stop" dans le chrono-diagramme) , cela indique au timer esclave que le prochain "bit" est le cutout
pendant le cutout , la ligne D1 prend un duty de 500us , et la ligne D2 de 29us , on a donc le moignon de bit dcc 1 qui précède le cutout proprement dit ; pendant le cutout (271us , normalement) , les 2 lignes sont à HIGH , ce qui provoque le brake du pont en H , nécessaire au cutout
puis les bits dcc suivants sont des 1 , comme indiqué par l'impulsion de synchro en début de cutout
.
les lignes D3 et D4 commandent un pont en H pour une voie analogique ; le sens est inversé (boucle de retournement , ou marche arrière) ; la ligne D3 est reste au niveau LOW (duty = 0) , tandis que la ligne D4 est en pwm inversé : le duty est d'environ 33% , sa valeur absolue change donc en fonction de la durée du bit dcc sur lequel il est synchronisé ; on voit que pour les 67% correspondant à l'absence de puissance , les 2 lignes sont à LOW , donc le pont en H est en sortie high Z (on pourrait utiliser ceci pour mesurer la fem du moteur , afin de réguler la vitesse , mais je ne l'ai pas prévu , par manque de pins au niveau du stm32)
.
au niveau de la création de la synchro , il y a donc une petite difficulté du fait qu'il faut anticiper : donner la largeur d'impulsion correspondant au prochain bit dcc , alors que le timing des impulsions correspondant au bit dcc en cours
le chantier de la centrale commandant les cartes boosters est vaste ; je vais peut-être pour créer la synchro , utiliser le rmt de l'esp32 de la-box / dcc-ex , on aurait une certaine convergence des systèmes ...
-
(il serait peut-être bien de scinder la rubrique en "projets persos" et "projets officiels" , pour éviter les chassés-croisés)
j'ai fait sur stm32 la maquette d'un moteur qui génère les synchros en fonction des packets à envoyer , cela donne ceci
En fait il n’y a pas de projets dits « officiels ». Dans cette section il s’agit de projets en général, dont le choix du titre est essentiel.
Pour les projets typiquement personnels, il y a la rubrique « réseaux » qui s’adresse à des réalisations personnelles.
Pour bien marquer le côté personnel d’un projet, il est possible j’ajouterai son pseudo dans le titre qui peut être modifié par son auteur après coup.
-
le temps passe trop vite
on va reprendre la suite du projet avec la réalisation des 2 premières cartes prototypes à 5 cantons ; je voulais d'abord vous en parler après la réalisation des cartes et des tests , mais vu les pointures qu'il y a sur ce site , je préfère vous présenter les choses avant d'engager les frais d'un prototype par jlcpb , cela m'évitera peut-être de mettre les 2 cartes à la poubelle
je parlerai de la détection des circulation , des ponts en H , de la détection railcom , et du dessin du PCB
mais d'abord , retoucher le principe de la synchro des timers
les broches du STM32 peuvent avoir jusqu'à une quinzaine de fonctions différentes , pour en sortir ce dont j'ai besoin , je me suis servi de l'utilitaire STM32 cubeMX , cela donne ceci :
-
les 10 sorties pwm dont j'ai besoin sont prises sur les timers 1 à 4
les 4 timers peuvent être synchronisés directement par le comparateur , on n'a donc pas besoin de timer maître , la sortie du comparateur faisant office de maître pour les 4 timers
les 4 timers sont configurés pareils , avec une particularité pour :
- le TIMER1 : on utilise les canaux PWM négatifs , car les normaux n'étaient plus disponibles sur les broches ; les canaux négatifs servent à piloter directement des ponts en H réalisés en composants discrets ; ils sortent le signal normal , mais inversé , et avec introduction d'un dead time qui permet de sécuriser les transistors ; ils peuvent être utilisés comme un canal normal , car on peut paramétrer le dead time à 0 , et inverser le PWM , ce qui fait qu'inversé 2 fois de suite , le signal redevient normal (on a donc , avec les canaux négatifs , des broches alternatives aux broches normales , peu de gens le savent)
- le TIMER3 : j'ai d'abord voulu utiliser le canal capture/compare(PWM) n°4 du TIMER1 , comme canal de capture , pour avoir la durée de l'impulsion de synchro , mais ça ne marche pas , j'ai dû relire le manuel de référence : le pilotage d'un canal capture depuis le comparateur , ne marche que pour les canaux 1 et 2 ; j'ai donc pris le canal 1 du TIMER3 , le 1er qui était dispo
-
voilà pour ce qui est simple et qui a pu être testé . Avec la détection des circulations , on entre un peu dans l'inconnu
je vous avais montré le principe que j'envisageai en un 1er temps , mais cela nécessite des coupures sur les 2 rails de la même voie , ce qui n'est pas bien satisfaisant , car par exemple dans le cas d'aiguilles à cœur conducteur , il y a d'office 2 coupures en talon du cœur , il vaut mieux utiliser ces 2 coupures pour éviter des coupures inutiles (qui coupe le moins , coupe le moins)
le schéma garde sa simplicité quand est au 0 volt , le rail sur lequel sont faites les coupures :
-
le train , c'est le petit rectangle vert
un petit courant , 5 mA par exemple , fait naître une tension de 0v3 à l'anode de la schottky de droite (à vérifier dans le datasheet de la SS34) , ceci est facile à mesurer avec un ADC
mais quand le rail coupé passe du 0 volt au 15 volt , au milieu d'un bit DCC , ou en analogique pour aller dans l'autre sens , ça se corse :
-
d'abord , la tension passe à 15 volts , elle ne peut pas être mesurée par un MCU en 3v3 , il faut un diviseur de tension par 6
(cela divisera aussi les 0v3 précédents par 6 , il ne restera que 0v05 , amha , ça reste mesurable)
donc si le rail est à 15v , la chute de tension dans la shottky va ramener la chose à mesurer à 14v7 ; donc si on divise par 6 , la zone libre donnera une tension à mesurer de 15v /6 = 2v5 , et la zone légèrement occupée : 14v7 /6 = 2v45 ...
alors adieu Berthe pour faire le distingo , la différence est de 0v3 /15v = 2% ; on peut à la rigueur penser qu'un ADC de 10 bits pourra s'en sortir , mais concernant les resistances , si on a 2 diviseurs de tension avec chacun 2 résistances à 1% , on aura une incertitude de 4% , pour mesurer une différence de 2% , c'est rappé
mais j'ai aussi eu un souci du nombre de broches d'entrée ADC ; j'ai 5 cantons avec 3 zones , pour lesquels je veux aussi mesurer le rail en amont des schottky (pour avoir la différence de 0v05) , et la tension de shunt des ponts en H , pour connaître le courant consommé par le train ; cela me fait 5x(3+1+1) voies ADC , soit 25 ; on est très au-delà des broches dispo pour le MCU choisi , il faut augmenter le nombre d'entrées ADC , par l'utilisation de multiplexeurs analogique 8 <-> 1 de type CD4051B
ce multiplexeur tient 20 volts , donc avec 15 vots en entrée , ça doit le faire (je pense cependant que 18v serait une tension absolue à ne pas dépasser , il existe uns version à 24 volts , pour les cas extrêmes)
-
l'avantage , c'est qu'on va mettre le diviseur de tension sur la sortie commune ; alors on économise une ribambelle de résistances , mais surtout , notre 15v et notre 14v7 passera dans le même diviseur , on n'aura plus le souci de la précision des résistances , car ce qu'on voudra voir c'est une différence de tension , qui sera peu ou prou la même
mais il y a comme souvent , le revers de la médaille : la mesure sera fausse , si entre les 2 mesures , les 2 valeurs auront globalement varié ; par exemple , on va mesurer le 15v et trouver une valeur ; on change le canal du multiplexeur , pour mesurer la zone 1 du canton , et on va trouver une valeur ; si entre temps la charge à varié , le pont en H délivrera une tension plus faible , et ceci peut être interprété comme une occupation de la zone 1 , alors que celle-ci est libre !
pour pallier ce risque , je pense bien qu'on peut multiplier les mesures pour dégager une statistique , et changer la méthode , par exemple d'abord mesurer le 15v feeder du canton , puis la zone 1 , et faire l'inverse pour la mesure suivante ... qu'en pensez-vous ?
pour commander en 15v les 3 lignes de sélection des 4051 , il y a à gauche 3 transistors , pour faire la translation depuis 3v3 du STM32
-
Hello
Si je me souviens bien des hypothèses de départ l' idée était de réduire le nombre de composants "externes" au delà du CPU .
Si on peut en ajouter pourquoi alors ne pas partir sur un montage externe qui dans tous les cas donnera la "vérité" sur l'occupation 0/1 de la zone en question? ( montage à diodes + opto? montage à base de COIL, COIL +NE555/556..?)
Si on désire avoir toutes les mesures de conso local alors on acceptera de poser de petit TINY et remonter cela d une façon ou d une autre...
Pour la détection en analogique une solution peut consister à envoyer un bref temps un courant qui indiquera en retour l'état...
Ltr
-
Hi ,
la surface de PCB dont j'ai besoin pour traiter 15 (quinze) zones , c'est 7 cm² ; le coût , toujours pour les 15 zones , c'est 3 ou 4€
peux-tu donner les chiffres , en comparaison pour la même quantité de zones , de ta version ?
-
now ladies & etc. , le pont en H , c'est la partie la + simple
-
j'ai choisi le DRV8870 ; il a l’inconvénient de nécessiter une encombrante résistance de shunt , pour limiter et mesurer le courant , mais il est assez puissant , bon marché , facile à remplacer le cas échéant (boitier SMD à 8 broches) , et il existe un équivalent chez Alegro , et un autre , chinois , moins ... limité : donc pas de souci de disponibilité
il a une entrée Vref qui permet de limiter le courant ; cette tension est générée sur la carte par un diviseur de tension , dont les 2 résistances SMD sont assez grandes pour être remplacées , si on veut augmenter ou diminuer le courant des 5 ponts en H
un des 4 multiplexeurs CD4051B est dédié à la mesure de la tension de shunt , qui permet de déterminer le courant
à chaque pont sont associées 2 LEDs : l'une ou l'autre est allumée + ou - , en analogique , ou les 2 allumées den DCC , ou aucune , pour un arrêt en analogique , ou un défaut en DCC
la détection railcom ; je réalise ceci par des comparateurs et des resistances (c'est des composants de base jlcpcb, donc ça ne coûte rien) ; l'origine du dessin , c'est un génie du club de Saltzbourg , si quelqu'un peut m'en expliquer en détail le fonctionnement , je suis preneur :
-
grosso modo , parmi les 2 comparateurs du montage , celui qui a la moitié positive du message railcom , présente ce message sur sa sortie à collecteur ouvert , et celui qui a la moitié négative , ne présente rien , il laisse la résistance de pull-up qui lui est associée fixer le niveau de la sortie à 3v3 (HIGH pour le STM32duino)
si la locomotive est posée sur la voie dans l'autre sens , les rôles des 2 comparateurs sont inversés
j'ai ajouté une schottky entre les 2 sorties ; ainsi , le signal railcom , est présenté à l'entrée de l'UART , sortie DAT , quelque soit le comparateur actif ; cela ne change rien pour le comparateur du bas , qui selon le sens de la locomotive , présentera le signal railcom ou rien , sur la sortie DIR : cette sortie est présentée à une entrée digitale quelconque du STM32 , qui devra se débrouiller pour interpréter ce qu'il reçoit , et nous dire quel est le sens de la locomotive
le PCB :
-
de gauche à droite et de haut à bas :
- 5 connecteurs à visser de 3mm5 , pour les 5 cantons ; chacun a les 3 zones + le rail opposé
- la trichiée de schottky SS34 , pour la détection des zones
- les 5 ponts en H , avec leur chimique et leur shunt , et dessous leurs 2 LEDs ; les connecteurs à visser sont l'alim 15 volt , qui arrive par la gauche , et par la droite va vers la carte 5 cantons suivante , selon un principe de facilité et de clarté de câblage , auquel je ne déroge pas
- les 4 multiplexeurs analogiques , leurs ponts diviseurs , et les 3 transistors
- les 5 comparateurs doubles LM393 du railcom , avec leurs cours de résistances
- les connecteurs pour le réseau : on peut opter pour du RJ12 , du JST-XH , ou du bornier à visser ; le module STM32 de chez Weact ; le réseau est en RS485 , il y a aussi 2 MAX3485 en + , pour l'arrivée et le départ de la synchro ; et 5 WS2812 , que j'ai mis pour donner des infos complémentaire sur l'état des cantons (sans savoir quoi pour l'instant)
- à droite , il y a des schottky et un MPS1117-5 pour avoir du 5 volts ; une zener en série en amont de celui-ci , permet au MPS de digérer sans risque les 15 volts de l'alim
- à gauche , il n'y a rien alors j'ai vaguement meublé
une telle réalisation n'est possible , pour moi , que grâce aux facilités mises à disposition par des entreprises comme jlcpcb ; ils se chargent de confectionner le PCB à 4 couches , de fournir et de souder les composants SMD ; il faut tenir compte de la disponibilité de ces composants , par 4 niveaux , en commençant par le préférable :
- les composants basic
- les composants extended , mais pris dans une liste préférentielle , pour laquelle les frais supplémentaires des composants extended ne sont pas appliqués , si on choisit l'option economic (ici , le CD4051B)
- les composants extended (ici , le DRV8870 et les résistances de shunt ; j'hésite encore si je vais acheter ces résistances à part , et les souder moi-même)
- les composants non dispo chez jlcpcb , mais qu'on peut leur faire acheter auprès des grans distributeurs , et qu'ils garderont pour nos propres projets
j'estime à 60€ le coût de 2 cartes terminées ; cela fait 6€ par canton , avec pour chacun , bimode analogique DCC , réversibilité , sécurité électrique , détection sur 3 zones , détection railcom , indication par LEDs
mais encore un défi à faire fonctionner ...
-
encore un petit mot sur le dessin du PCB 4 couches ; j'utilise le principe suivant , sans valeur didactique :
- côté composants (rouge) , ben les composants CMS , et un maximum de routage et de plan de masse dans la place qui reste ; le placement des empreintes et le routage immédiat (et les vias) sont dessinés et optimisés une fois , pour chacun des modules élémentaires , puis ils sont copiés collés en utilisant la grille pour bien aligner les choses (reste la fastidieuse maj. des numéros , je ne connais pas d'autre méthode)
- la 1ère face interne (vert) : le plan de masse , et de rares et courtes pistes pour dépanner
- la 2ème face interne (brun clair) : le routage vertical
- côté soudures : le routage horizontal et les lignes d'alimentation (lignes d'alimentation ici , car les 2 couches internes n'ont que la moitié de l'épaisseur)
petit extrait (les 4 couches ont leur plan de masse , non représenté ; c'est pour cela qu'on voit très peu le vert)
-
Hello Marc
C est beau!
Y a du travail derrière!!Belle œuvre appréciable
Rm sur les utilisations: avec le retour d'expérience des satellites autonomes qui font appel à des détecteurs "ponctuels" placés aux extrémités de zone(s) via des capteurs optiques ( sortie 0-1) sur comparateur , est ce que cela n'arrangerait il pas tes usages ? La zone pilotée par le PONT H serait alors composée d' un seul segment ("canton") et si besoin des capteurs aux extrémités viennent informer de l'occupation "locale" selon les zones ou le tain se situe en plus de la détection globale par conso au niveau "canton"?
Pour ce qui est du calcul des couts avec les NE556 ( x2)/555(x1) et les coils selon, leur nombre (5 à priori) le cout est assez faible mais c est plus une question d encombrement qui sera probablement supérieur à ton dispositif actuel à base de diodes. et avec des montages externes pour les capteur locaux.
la SS34 est une Schottky à faible chute (mais rapide) aussi tu risques d'avoir quelques surprises avec cette faible chute qui sera plus franche avec une diode "classique" avec un Vdrop plus haut.
.
Ltr
-
Hi Laurent ,
merci , oui cela fait beaucoup de travail , alors ce sera encore plus beau si ça marchera
je vais déjà tester "mon" idée à 3 zones avec ce prototype ; en cas d'échec , il faudra trouver autre chose , alors pourquoi pas les capteurs
la SS34 , c'est parce qu'il faut penser à tout : en DCC , chacune des 2 diodes dissipe la moitié de la puissance , en analogique , l'une dissipe tout , et l'autre rien ; il faut donc que ces diodes puissent conduire le double du courant par rapport à une diode en DCC , et à gabarit égal , ce n'est possible qu'en divisant par 2 la tension de seuil ; évidemment , ça complique la lecture ADC , et j'ai bien du cogiter pour trouver une solution qui a une chance de fonctionner
faire une détection en mesurant la conso du pont en H ça ferait 5mA *0.22R = 1.1mV , trop peu pour pouvoir être mesuré
-
Bonjour.
Assemblage PCB:
Juste pour vous informer que je viens de faire une simulation pour un double face et les prix ont fortement augmenté chez JLCPCB.
Pour ma part, je ne ferai plus que des simples faces....
Alors pour un quatre couches……
-
Historiquement le rapport du cout pour passer de 2 vs 4 couches était d un rapport de 1 à 4
C'est restait plutôt stable, voir même le cout du 4 couches a baissé
A noter que le format 100mmx100mm ( 10x10cm) est moins pénalisant coté cout qu'autrefois.
En revanche les prix du port ont "explosé"!
Pour le montage c est selon... mais il y a quelques astuces pour optimiser:
respecter la taille mini du 70mmx70mm y compris avec des bords "edges" additionnels pour y parvenir.
choix de composants en évitant si possible les "extended"
garder tout ce qui est traversant à implanter soit même.( connecteurs notamment, relais,...)
en cas de petites séries rester sur des couleurs et épaisseurs "ordinaires" type 1.6mm/vert
équiper 2/5 des pcb fabriqués.
garder un oeil entre les multiples de couts des pièces et leur nombre à implanter.
enfin rester sous les 150€ pour ne pas avoir de taxes supplémentaires à devoir acquitter...
Ltr
Ltr
-
Bonjour.
Assemblage PCB:
Juste pour vous informer que je viens de faire une simulation pour un double face et les prix ont fortement augmenté chez JLCPCB.
Pour ma part, je ne ferai plus que des simples faces....
Alors pour un quatre couches……
Bonjour,
Ce n'est pas exactement le cout de transport qui a augmenté mais les taxes incluses dans ce cout "apparent". C'est vrai comme le dit Laurent que le format 100 x 100 (ou moins) reste canon chez JLCPCB.
Il faut profiter de l'offre qui est faite pour la première commande (qui se renouvelle au moins tous les jours) pour le pack 5 exemplaires. Résultat, si j'ai besoin de 20 cartes, je commande 4 fois 5 cartes !!! C'est stupide, je sais, mais beaucoup moins cher (pas pour la planète). De l'ordre de 0,88 cts € la carte.
@lebelge : je ne comprends pas, un double face n'est pas plus cher qu'un simple face ! Ce n'est jamais qu'un PCB avec des piste recto-verso. Sauf peut-être si tu fais monter les composants.
Christophe
-
Oui, pour le montage des composants, il y a un supplément de 23 € par face, donc 46 € pour un double face (plus les composants)
-
Bonjour ,
les 4 couches me permettent de diminuer le nombre de cartes , d'arduino , de câblages , donc je pense que je suis globalement gagnant ; je vous dirai combien ça coûte quand j'aurai lancé la commande (il y a aussi le coupon qui s'applique à la fin)