LOCODUINO
Parlons Arduino => Vos projets => Discussion démarrée par: laurentr le janvier 18, 2024, 12:08:01 pm
-
Bonjour
Comme cela avait été évoqué dans la présentation du fil de présentation de cette solution novatrice et innovante nous discuterons ici d'évolutions possibles/utiles qui viennent compléter la solution initiale conçue par Christophe.
Ces évolutions peuvent être de différentes natures tant soft que hard.
Une approche du hardware va être de reprendre l'existant avec un nouveau design des cartes, apporter une approche modulaire des blocs de composants ( alim, détection, alimentation, extensions, introduire un nouveau bus de communication (I2C), …)
Pour vous donner un avant gout de cela voici une vue de deux blocs fonctionnels portant pour l'un la mesure de courant/tension ( SENSOR INA219 via bus I2C) et l autre l'identification RAILCOM telle que déjà présentée par Christophe et Michel.
La suite au fur et à mesure sur cette branche Hardware.
Pour la branche soft je vais apporter quelques compléments dans les prochains messages pour vous exposer notamment le gestion des grills d'aiguillages ( zones complexes denses, TJD, TJS, croisement, bretelles, "bif",...)
Ceci se portera aussi sur quelques ajouts hardware ( relais, puces I2C, …) et un peu de câblage inter cartes/modules.
Laurent
-
J'apporte de suite des compléments TRES IMPORTANTS:
ICI on est sur une base EXPERIMETALE à ce stade. ( tant soft que hard pour partie)
Cela ne remet pas en question la solution initiale présentée par Christophe qui est déjà OPERATIONNELLE et validée par de nombreux tests.
Ltr
-
GRILLS D APPAREILS:
Posons les notions qui vont nous accompagner avec le terminologie associée.
De quoi s'agit il:
Un grill de gare est par défaut une zone composée à minima d'un appareil de voie ( aiguillage simple, ou multiple ( triple, TJS, TJD)) Il dessert 2 sections du réseau ( cantons, zones, ...)
Il y a donc toujours une entrée unique et une sortie unique qui permet de circuler entre l entrée et la sortie à un instant T.
Dans le cas de la présence de plusieurs appareil c est leur position respective qui oriente le tracé de desserte entrée/sortie.
Si un appareil sur ce trajet n'est pas dans une position valide( ex aig prise en talon mais dans la position non alignée avec le mouvement entrée sortie (IN/OUT) alors le parcours d un train ne peut pas s effectuer sur le tracé en place.
Il faut donc compléter les modifications des positions des lames de appareils pour libérer la faisabilité de parcours sur le tracé entre les sections que l on veut relier.
Nous allons exploiter ces caractéristiques précisément pour la gestion électrique des grills.
En effet on peut considérer qu'un grill et le prolongement artificiel d'une section avec un autre par extension/assimilation.
Ceux d'entres vous qui ont pratiqué le câblage de réseaux analogiques identifient rapidement cette notion puis qu'il d'agit de faire parcourir le courant selon la source de pilotage dans un ensemble de sections/zones en fonction des positions des appareils ( et de priorités qui peuvent être données)
Aussi nous allons nous servir du "meilleur" des deux mondes (câblage type analogique et câblage façon digital) ( approche en mode bloc oblige) pour produire la encore une approche novatrice qui s'aligne avec le socle des satellites autonomes de Christophe.
Cela se traduira par un peu de câblage et l'ajout de composants hardware. (relais pour assurer des commutations)
Si tout le monde suit nous allons pouvoir passer à un cas concret d'analyse.
Ltr
-
GRILLS D APPAREILS:
Un grill de gare est par défaut une zone composée à minima d'un appareil de voie ( aiguillage simple, ou multiple ( triple, TJS, TJD)) Il dessert 2 sections du réseau ( cantons, zones, ...)
Il y a donc toujours une entrée unique et une sortie unique qui permet de circuler entre l entrée et la sortie à un instant T.
Il y a des gares (Creil par exemple) où deux doubles voies arrivent dans le grill d'entrée, pour desservir plusieurs voies à quai. Quatre trains peuvent circuler simultanément sur le grill.
Par ailleurs dans pas mal de gares le cantonnement se fait (normalement sur les carrés) sur toute la traversée de la gare, on a donc des cantons dans le grill d'entrée (et sur les voies à quai).
Pierre
-
Bjr Pierre
En effet un grill peut être composé de multiples zones.
Plus les zones sont autonomes et associables/dissociables et plus la fluidité permet des mouvements en parallèle.
Sur les itinéraires les plus sécants on associe un grand nombre de zones qui forcera les carrés sur les liaisons non assurées par ailleurs. ( et attribuera le zonage électrique commun)
Ltr
-
Bonjour
Parlons un peu de la gestion des grills d'appareils.
Plus particulièrement après avoir abordé un cas simple, enrichissions le modèle.
Terminologie C = Canton
ZAP = Zone d'APpareils.
Toutes les coupures se font sur les 2 rails.
Dans son hypothèse de départ Christophe a associé les aiguillages en sortie de canton. C est à dire à l extrémité "avant" du sens nominal de circulation du canton (C1 sur notre image explicative)
Elles sont l'extension logique et électrique du canton précèdent Cx ( Réciproquement elles pourraient tout autant être l'extension logique et électrique d'entrée des cantons de destination C+x)
A un instant T0 selon la position des appareils présents sur le grill et de leurs combinaisons la ZAP va être alternativement l'extension de différents cantons comme 1 source UNIQUE.
Lorsqu' elle n'appartient pas au prolongement d'un canton cela produit la mise en sécurité sur ces cantons et présente un signal carré de protection devant l'appareil.
Sur un grill plusieurs combinaisons sont possibles. Plusieurs grills peuvent s'interconnecter étant les uns les autres le prolongement de chacun d eux pour établir la liaison entre l amont et aval.
1er cas:
Aiguille en talon prise en position droite ( non déviée) et aiguille prise en pointe en position droite: liaison C1 vers C+1:
Ce cas "trivial" est nativement traité par le modelé de Christophe et n'appelle à priori pas de remarque spécifique.
Sauf que.... quand l'aguille prise en talon sera abordée, soit par une origine de C3 ou de C2, la ZAP n'appartiendra plus à C1 mais respectivement à C2 ou C3!
Ces commutations vont être réalisées à l'aide de relais.
Il faut toutefois procéder avec logique pour ces commutations.
Sur un tracé donné il faut toujours identifier le fait générateur qui force la commutation et à quelle "source" se rattacher alors.
En effet le tracé de voie, vos souhaits de circulations auront des incidences sur la priorisation de traitement et donc les commutations à réaliser
-
Poursuivons.
une ZAP n'est jamais un canton mais une extension de canton auquel elle appartient alors!
A instant T elle n'appartient qu'à une source unique.
Cette appartenance se fait selon les combinions de positions des appareils.
2eme cas:
Aiguille prise en talon en position directe ou sans aiguille prise en talon et Aiguille prise en pointe:
A) entrée dans un canton:
Que la position de l'appareil soit en position droite ou déviée l'arrivée se fait dans un canton, pas de changement au modèle initial
la ZAP est l'extension de C1.
Ici nous passons de C1 vers C+1 ou C+11
B) entrée dans un autre grill:
Il y a liaison entre le grill ZAP actuel (ZAPa) et un homologue (ex ZAPb). Il faut donc combiner la liaison de ces deux éléments. L'un étant l'extension de l'autre et réciproquement.
Nous passons ici de C1 vers C+3 via ZAPa et ZAPb
C'est la position des aiguilles qui déterminera la distribution.
-
On remarque de suite que la présence d'une aiguille en talon avec d'autres appareils en succession va justifier le découpage en ZAP.
Une TJD et une TJS justifieront aussi un découpage analogue.
En effet ces appareils sont une combinaison d aiguilles en pointe et en talon.
On le voit sur l'illustration en cas de mouvement de C1 vers C+3 ou C+5 par exemple.
En effet la ZAPb qui appartiendrait par exemple nominalement parlant dans un mouvement de C+3 vers C3 au canton C3 ne peut lui appartenir si nous allons depuis C1 vers C+5.
Au mieux ZAPb pourrait être une extension de C+5 tout au plus si l aiguille est tracée pour desservir cette voie.
J essaye d expliquer le plus simplement possible en illustrant mais si des questions se font jour j essayerai d apporter les précisions requises.
-
Complétons et illustrons les cas possibles:
Ils sont nombreux et une lecture attentives des schémas produits va permettre d identifier quel cas appliquer pour le découpage et l'isolation électrique des différentes sections des grills.
Si l'on recherche une fluidité maximale on découpera plus intensément. Cela se traduira par plus de commandes de relais un cabale plus important mais jamais compliqué car répétitif
On remarque une maille importante identifiée comme "section racine". Il s'agit là d'une maille réduite au plus court composée d'une enfilade aiguille en talon et aiguille en pointe. Il sera important de localiser cette section qui sera centrale au sein d un grill et de laquelle découlera des mises en œuvres spécifiques.
Au niveau câblage la aussi la simplicité sera de mise.
Vous aurez remarque des indications HAUT/BAS AMONT/AVAL et CENTRE.
Et bien pour chaque cas il faudra identifier dans quelle combinaison nous nous trouvons afin de réaliser une liaison électrique de 2 fils entre deux éléments.
L électronique, le code, se chargeront du reste. Il faudra veiller à être rigoureux dans la mise en œuvre.
Le cas des croisements va être abordé ensuite ( et donc des doubles bretelles ou plusieurs mises en ouvres sont possibles).
A noter que tous les cantons ont une même orientation de mise en œuvre. (même sens horaire de construction qui rappelons le n est pas nécessairement celui de circulation)
Les cas ou ils se trouveraient opposés "face à face" sera traité ultérieurement.
Laurent
-
les autres schémas:
-
Pour faciliter la lecture et la compréhension détaillons le cas si joint.
Hypothèses de départ:
C1 et ZAPa sont connectés sur l itinéraire direct vers C+1
C2 et ZAPb sont connectes sur l itinéraire direct vers C+2
Les satellites C1 et C+1 sont associés
Les satellites C2 et C+2 sont associés
Nous associons ensuite C1 et C+2 d une part et C2 et C+1 de l'autre selon les indications de Christophe.
A présent nous considérons que pour une aiguille en talon qui serait déviée ici A3 alors il y a rupture de la liaison entre C1 et ZAPa d une part et ou C2 et ZAPb d autre part si par exemple A4.
Ceci produit l'activation d'un premier relais qui sépare respectivement ces flux.
OK et ensuite?
Pour C1:
A1 est droite. SI A3 droite puis A5 droite on va de C1 vers C+1 ou C+3 (selon A7) et inversement via ZAPa.
Si A3 est déviée vers la BAS cela rompt la liaison ZAPa avec C1. C1 présentera un carré et forcera un arrêt (sécurité).
Si A2 n'est pas déviée vers le HAUT elle aussi il n'y a pas de connexion entre ZAPa et ZAPb. ZAPa est "apatride".(non alimentée) A ce moment la si A2 A4 sont droites on circule sur les cantons impaires via ZAPb si rien ne s y oppose. ( C2 vers C+2 ou C+4 selon A6 et réciproquement)
A3 est toujours déviée vers la BAS (donc C1 déconnecté de ZAPa) et si A2 est déviée vers le HAUT il y a commutation. ZAPb n'est pas déconnecté de C2. ZAPa et ZAPb sont interconnectées ( commutation = activation d'un autre relais)
Un mouvement est possible de C2 via ZAPb vers ZAPa si A5 est droite. On peut alors desservir ensuite C+1 par exemple si rien ne s'y oppose (ou C+3 selon A7). Une circulation est possible aussi dans le sens inverse si rien ne s'y oppose. (C+3 peut remplacer C+1 selon A7)
Si A1 droite, A3 droite et A5 déviée mais A4 droite alors on ne peut pas faire de mouvement entre C1 et C+x mais les mouvements de C2 vers C+2 ou C+4 ( selon A6) restent possibles. C1 vers C+x affichera un carré.
Rm si (A1 droite et A5 déviée et A4 droite ) d une part et (A2 déviée et A3 droite et A4 déviée ou droite) quelque soit A6 alors il n y a pas de mouvement possible de C vers C+ ( ou C+ vers C) tant coté paire que coté impaire. ("auto blocage")
Réciproquement pour C2:
Devions A2 vers le HAUT.
Si A3 n'est pas déviée vers le BAS ZAPb et ZAPa ne sont pas connectées. Le trafic peut se poursuivre de C1 vers C+1 ( ou C+3 selon A7) ou dans le sens inverse.( C+1 ou C+3 selon A7 vers C1 via ZAPa) Mais pas de C2 ou vers C2.
ZAPa reste connectée à C1 pour le moment.
Si A3 est déviée vers le BAS alors ZAPa et ZAPb sont interconnectées et C1 est déconnecté de ZAPa. C1 vers C+x affichera un carré.
A ce stade si A5 et droite et A7 droite on a une connexion établie de C2 vers ZAPb puis ZAPa avant d entrer dans C+1 ( ou C+3 selon A7) (et similaire dans le sens de circulation inverse.) Les circulations sont possibles si rien ne s'y oppose.
Que se passe t il si A5 est à son tour modifiée et passe en position déviée vers le BAS?
Simple! Tant que A4 n'est pas déviée vers le HAUT il ne peut y avoir de circulation puisqu'il n y pas de liaison entre les cantons entrée et sortie. Il faut en informer C2.
Lorsque A4 bascule à son tour on interconnecte une nouvelle fois ZAPa et ZAPb ( sans incidence), on en informe C2. Un tracé est possible entre canton d entrée et de sortie. Une circulation est possible de C2 via ZAPb vers ZAPa puis de ZAPa vers ZAPb vers C+2 (ou C+4 selon position de A6) ou dans la direction opposée ( C+2 ou C+4 selon A6 vers ZAPb puis ZAPa puis ZAPb puis C2) dans les deux cas si rien ne s'y oppose..
Compliqué?
Prendre le temps de comprendre cette mécanique de base essentielle. Au besoin apposez y votre "sémantique" pour décrire les étapes et leurs conséquences.
-
(...)
ZAP = Zone d'APpareils.
Toutes les coupures se font sur les 2 rails
Bonjour ,
de mon temps , ZAp = Zone d'Approche : il y a malheureusement une confusion possible
https://www.roverch.net/modelisme/EnclApproche.htm (https://www.roverch.net/modelisme/EnclApproche.htm)
(...)
Toutes les coupures se font sur les 2 rails
c'est sans doute dommage , si ce n'est pas forcément utile
-
Bonjour Marc
Le choix de la double coupure est challengeable mais il imposera plus de contraintes dans la gestion de certaines zones.... donc qui peut le plus peut le moins à ce niveau
Le nombre de coupures se réduit a peu en fait entre les canton on a les ZAP et les cantons. ( comme utilisation de capteur optique pour les arrivées "en zone" on se facilite la vie également!)
Pour l appellation ZAP chacun renommera selon ses envies. Il en fallait une qui soit "parlante" ( en mone analogique del époque...!) et en complément de "ZA" pour Zone d Arret et "ZR" Zone de Ralentissement.
Mais oui le terme Zap peut ausis etre employe dans d autres contextes avec l annonce.. etc ( Voir un vrai TCO SNCF "historique" pour voir le fonctionnement global)
Laurent
-
Bonjour Laurent,
Un truc auquel il faut penser pour les grills est que l'établissement d'un chemin peut passer par le changement de plusieurs
aiguilles et que ces changements ne seront pas simultanés. Il y aura donc des chemins provisoires qui ne doivent pas déclencher
le feu vert pour le train.
Il faut donc prévoir une temporisation à chaque changement d'aiguille avant de valider un chemin. (temporisation globale pour
le réseau configurable par l'utilisateur)
-
Bonjour
Je pense que c'est déjà dans le socle d'origine et qu'on pourra ajouter cette valeur de "réaction".
Par ailleurs je regarde pour ajouter aussi un "CROSS OVER" hardware pour la gestion des polarités sur les ZAP avec les cantons en liaison ( auto commutation des pôles J/K) ( similaire à ce qu'on peut faire pour la gestion d'une boucle de retournement)
Ltr
-
Bonjour
Je poursuis le "DEV" du hard revu et j ai ajouter le montage suivant (à tester).
Il s'agit d'un "disjoncteur de protection DCC" ( ON/OFF) dont le principe est de:
- Fixer un seuil de déclanchement (ex:2A = 2000mA)
- Mesurer le courant consommé à l'aide d'un ACS712
- Comparer le temps où un pic est décelé avec une valeur de référence ( ex 20ms = 20000us)
- Si le seuil temporal est franchi on bascule le rails en coupant l'alimentation
Pour réactiver on utilise un interruption sur une broche qui effectue un RESET.
2 témoins lumineux indiquent l'état du relais.
Le cœur du dispositif est confié à un petit MEGATINY ( ex ATTINY202)
@Michel je pense que c'est le genre de montage que tu attendais depuis un moment :)
PS son petit frère est en route pour "SWITCHER" comme un LENZ LK200. 8)
Laurent
-
Et donc le "petit frère" pour "SWITCHER" et aligner les signaux DCC sur les rails de deux sections différentes.
Utilisations types
Approche modulaire.
Laurent
-
Pour le moment le code est "en dure" dans les CPU.
Une amélioration reposerait sur le fait d'intégrer un paramétrage via le DCC comme pour la gestion d'un accessoire.
Mais la sujet n'est pas simple.
En effet il faut laisser la priorité de traitement du mode RUN (exclusivement à peu de chose prêt) et basculer en mode "programmation" par un mode dérogatoire pour effectuer alors l'actualisation de CV stockées en EEPROM ce qui initialisera alors les valeurs au démarrage du composant/reboot du programme.
Les CPU actuellement sélectionnés ( format SOIC8 à 8 broches ) vont vite se montrer un peu "étroit" en taille de mémoire pour y stocker le nécessaire. On peut monter sur des versions dotées plus généreusement et de fait augmenter le nombre de pin également.( donc redesign hard pour caser le tout)
On complètera alors le HARDWARE avec la gestion du signal DCC et du ACK.
C'est une piste d'évolution à considérer.
-
Les design proposés reposent sur quelques concepts simples:
Modularité
Complétude
L'usage de différents connecteurs rend cette approche simplifiée.
Ainsi les connecteurs au pas de 2.54mm supportent par PIN jusqu'à 3A.
Les doubler à minima optimise la bonne circulation des canaux de puissance (DCC).
Les connecteurs à visser au pas de 5.08 sont "costauds" mais se sont souvent les plus disponibles en volume à prix contenu.
La substitution d un type de connecteur par un autre est possible selon le placement physique des cartes entre elles et les interconnections à réaliser.
Par ailleurs en cas de défaillance/panne de l'une d'elles un remplacement est facilité par remplacement d'une carte analogue. Dans certain cas, un "bouchonnage/pontage/bypass" et aussi possible ( ex cas de la carte RAILCOM, cas de la carte SENSOR) réduisant de fait les fonctions qu'elles supportent.
Laurent
-
Toutes les coupures se font sur les 2 rails
c'est sans doute dommage , si ce n'est pas forcément utile
Bonjour Marc,
Peux-tu développer ? De notre côté, c'est la détection Railcom qui nécessite cela. J'ai effectivement vu que Roco par exemple recommande pour le DCC une liaison continue sur l'un des rails pour former une boucle.
Par ailleurs, j'entends parler de rail J et de rail K en DCC, quelqu'un peut m'expliquer ce que cela veut dire et en quoi c'est important ?
Christophe
-
Bonjour
J/K sont selon la terminologie "LENZ" les deux pôles DCC allant aux voies.
Chez ESU cela reste désigne avec une autre terminologie: B/O.
Je je connais pas de relation entre J/K vs B/O ( J= B K =0 ou la réciproque?) mais c est bien "la même fonctionnalité"
Pour ce qui est des coupures de rail c est aussi plutôt par exemple comme le proposait DIGIKEY avec les détecteurs d occupation avec identification RAILCOM.
En effet avec un détecteur global d indentification on peut associer plusieurs détecteurs de zone locaux pour suivre la progression d un engin sur une section couverte par identification.
Ce sous découpage le permet.
Dans le cas d usage des satellites avec détecteurs ponctuels par phototransistor... le découpage électrique peut être abordé différemment.
Laurent
-
La coupure des 2 rails évite aussi tout aléas entre boosters différents sur des zones contiguës...
Qui peut le plus peut le moins. :)
Comme au niveau booster il existe différentes techno de découpage du fait de la nature des types de booster couper les deux prévient de tout aléas de cette nature. ( il y avait un excellent article dans un HS LOCOREVUE ( traduit d articles allemands) sur le digital à ce sujet.)
Ltr
-
Quelleques info par exemple ici chez LDT:
https://www.ldt-infocenter.com/dokuwiki/doku.php?id=fr:ldt-infocenter#btm-sg (https://www.ldt-infocenter.com/dokuwiki/doku.php?id=fr:ldt-infocenter#btm-sg)
Et pour illustrer un cas plus "comlplexe" de mise en oeuvre:
https://www.ldt-infocenter.com/dokuwiki/_media/de/anschlussbeispiele/page_1946.pdf (https://www.ldt-infocenter.com/dokuwiki/_media/de/anschlussbeispiele/page_1946.pdf)
On voit vite l'intérêt pour celui peu enclin à savoir quoi isoler(/et où) la "facilité" de couper les deux puis de "repiquer" la distribution si besoin...
Ltr
-
Bonjour
bien entendu , il faut une double coupure entre 2 secteurs chacun alimenté par son propre booster
mais dans un secteur alimenté par un booster donné , il faut absolument laisser une des 2 files de rail sans coupure :
1) parce que la double coupure est inutile , Laurent n'a rien démontré
2) parce que pour le fonctionnement du railcom , il faut que le courant émis par le décodeur puisse se reboucler vers le court-circuit (cutout) créé par le booster entre les 2 files de rail , c'est le béaba !
si tu as par exemple un évitement sur voie unique avec un aiguillage electrofrog à chaque extrémité , il y a déjà , d'office , 2 coupures au talon de chaque appareil : il suffit donc d'utiliser ces 2 coupures pour les 2 cantons situés entre les 2 appareils ; notons toutefois que dans ce cas , les 2 coupures se situent sur 2 files de railles différentes , il faut donc gérer ceci au niveau du module de rétrosignalisation
c'est à la technique de s'adapter au réseau , aux choses , pas l'inverse
par ailleurs , les modules qui créent une zone tampon entre 2 boosters sont généralement inutiles , car la désynchronisation des boosters reste dans les deadtime des 2 ponts en H ; citer des publications commerciales n'a pas de sens , si on n'en explique pas le réel intérêt
-
Bonjour
bien entendu , il faut une double coupure entre 2 secteurs chacun alimenté par son propre booster
mais dans un secteur alimenté par un booster donné , il faut absolument laisser une des 2 files de rail sans coupure
Bonjour Marc,
Je suis bien d'accord avec toi pour le cas que tu évoques "2 secteurs chacun alimenté par son propre booster". Cependant, je ne crois pas que ce cas ait été abordé. Cela m'amène à te poser trois questions :
1° - Quel intérêt y a t-il à alimenter chaque secteur avec son propre booster ?
2° - Perso, j'en vois quelques-uns, surtout dans le cadre de satellites autonomes où du coup on peut pousser plus loin le principe d'autonomie puisque l'on parlerait aussi de boosters autonomes (la centrale et les commandes restant centralisées mais pas la puissance). Ce concept te parait-il cohérent et présenter un quelconque intérêt ?
3° - Du coup, peut-on imaginer des cartes moteur de moindre puissance (1 à 2A) comme par exemple la Pololu MP6550 (https://www.pololu.com/product/4733) qui, si je ne me trompe pas, est capable également d’assurer le break nécessaire au cutout ?
Cette carte Pololu MP6550 dispose d’une détection de courant mais je ne sais pas si elle est assez fiable.
Quels sont vos avis, Marc et autres ?
Christophe
-
par ailleurs , les modules qui créent une zone tampon entre 2 boosters sont généralement inutiles , car la désynchronisation des boosters reste dans les deadtime des 2 ponts en H ; citer des publications commerciales n'a pas de sens , si on n'en explique pas le réel intérêt
Il n'y a pas que la synchro, il y a aussi la charge de puissance. Si un booster alimente plus de trains que l'autre, au moment du passage d'une loco entre les deux
le courant va se répartir entre les 2 boosters et la différence va passer dans les roues de la loco et donc potentiellement créer une étincelle.
C'est moins important que dans les boucles de retournement basées sur la détection de court-circuit mais ça reste un problème sur le long terme.
-
1° - Quel intérêt y a t-il à alimenter chaque secteur avec son propre booster ?
Christophe
Pour moi le seul intérêt (avec des solutions Arduino) c'est de limiter le courant de court-circuit à des valeurs plus faibles pour les gros réseaux.
-
Bonsoir
J'avance "doucement" sur la partie traitant de "l'autoreverse" (cas des boucles, pont tournant, triangle, …)
Je suis passé sur un CPU un peu plus gros (toujours dans la série des ATTINY en brochage SOIC20 broches). La taille du circuit a pris un peu d'en bon point.
Pourquoi ces évolutions?
Parce qu'il y a à présent une partie décodage DCC permettant de gérer des Lecture/Ecritures de CV stockées en EEPROM, permettant de paramétrer la sensibilité du détecteur. ( avec garde fou à mettre dans le code)
On retrouve aussi en sortie la possibilité de commander depuis l'extérieur la bascule du relais.( comme via un bouton poussoir local)
On sait aussi exporter la lecture de la mesure du capteur. ( avec possibilité de sortie vers un CPU en 3V3 ( ex ESP32 ;) ) ou un CPU en 5V type AVR/ATTINY via la bascule d un switch DIP qui active/désactive un pont diviseur de tension)
Le passage en mode "RUN" versus le mode "PROGRAMMATION" se fait via la bascule d'un switch DIP. Cette séparation permet d éviter d 'avoir à traiter des interruptions avec l'arrivée du code DCC sur la broche de traitement du signal comme de laisser cette broche "en l'air".
Quel est l'intérêt de dédier un (petit) CPU à la seule tache exclusive de mesurer et de déclencher la bascule? Tout simplement une gestion de priorité qui est autonome de tout autre traitement extérieur et donc de s'affranchir de latences sans forcer une priorité sur un CPU principal.
L'alimentation du montage est prise sur le DCC. ( c est l option actuelle) ( la faible consommation du montage ( CPU +relais en gros = 10ma + 30mA + composant divers (en gros 50ma) sera à déduire des mesures qui définiraient une occupation. ( offset))
A voir si d autres "options" sont à considérer.
Laurent.
-
Bonjour
La nuit portant conseil... j ai pu trouver une solution élégante pour ne plus avoir qu'un seul PCB pouvant gérer les 2 cas de figure:
- un CIRCUIT BREAKER = un disjoncteur si le seuil de conso MAX est franchi ( ici sur un hardware commun qui limite à 2A MAX)
- un AUTO REVERSE = un "aligneur" de polarité DCC automatique.
La sélection se fait par un pontage/ou non des pistes au dos de la carte et une reconfiguration des CV selon le mode de fonctionnement désiré.( pas d asservissement bien que cela soit aussi envisageable puisqu'il reste des broches dispo sur le CPU...)
Je me suis aussi posé une question:
Le CUTOUT RAILCOM étant perçu comme un "cour circuit" peut il influencer le dispositif? (lors de celui ci, il n y a plus de circulation de tension dans la mesure de l'ACS712)
A priori je pense que ce n'est pas le cas mais je peux me tromper.
Si oui il faudra pouvoir lors de celui ci suspendre les mesures ( ce qui imposera alors une révision du hardware)
Vos avis sont les bienvenus.
Pour memo:
Les temps de mesure et de réaction étant non compressibles à l'infini il faut un juste milieu
Dans tous les cas la bascule du relais se fait au mieux avec un temps compris entre 3 et 10ms. Donc en deca de ce timing point de bascule à réaliser.
Dans tous les cas les temps de mesure et bascule pour un version AUTOREVERSE devront être plus court que ceux du CIRCUIT BREAKER dont les temps seront pour lui aussi plus brefs que ceux de déclanchement de ceux de la centrale ou du booster.
Aussi par exemple on peut penser avoir une chaine telle que les seuils temporels de détections soient:
MODE REVERSE entre 10ms et 20 ms
MODE CIRCUIT BREAKER entre 30ms et 50ms
CONFIG CENTRALE OU BOSTER entre 50ms et 100ms.
Laurent
-
mais dans un secteur alimenté par un booster donné , il faut absolument laisser une des 2 files de rail sans coupure :
1) parce que la double coupure est inutile , Laurent n'a rien démontré
prenons l exemple d une LOOP ou d une section "ZAP" liée à deux cantons d'alimentation en "phases" opposées... Je vois mal l'inversion n'être réalisée s'il n'y a pas de coupure des deux cotés...
Le repiquage sert a cela au prix d un peu de fils.
si tu as par exemple un évitement sur voie unique avec un aiguillage electrofrog à chaque extrémité , il y a déjà , d'office , 2 coupures au talon de chaque appareil : il suffit donc d'utiliser ces 2 coupures pour les 2 cantons situés entre les 2 appareils ; notons toutefois que dans ce cas , les 2 coupures se situent sur 2 files de railles différentes , il faut donc gérer ceci au niveau du module de rétrosignalisation
c'est à la technique de s'adapter au réseau , aux choses , pas l'inverse
C est quand même mieux quand nativement on évite d'avoir à gérer des détections de CC et interagir en fonction. Cela dit je ne vois pas encore ( tu dois avoir un train ou deux d'avance comment tu gères la détection au passage de la pointe pour auto adapter la polarité sur le cœur... alors que si on asservi le cœur à la position des lames et que la sécu fait le reste ( retro, règles,...) il n y a plus de sujet... sauf à s emmêler les pinceaux lors du câblage!
Quid dans tu as N cœurs repartis sur les rail de droite et de gauche dans un "ZAP"...?
[/quote]
-
Bonjour
Le "BIG" circuit breaker est réalisé.
On pourra aller jusqu'à 7.5AMP dessus avant de le déclencher.
Cette fois en revanche c est un ACS712 version 10 AMP qui sera requis.
Un petit ajout aussi pour indiquer le niveau de charge présent par l'allumage de leds:
<2A
<4A
<6A
Indicateurs visuels précieux
Lurent
-
Bonjour Laurent,
Je suis avec intérêt tes publications, mais je dois avouer que j’ai parfois du mal à suivre. Tu développes souvent des éléments techniques avec des termes techniques (ex : format SOIC8 à 8 broches ???) au détriment du bénéfice utilisateur ; en gros, qu’est-ce que cela m’apporte ! On finit par comprendre mais cela demande un certain effort.
Je vais essayer de résumer ce que j’ai compris et tu me diras si c’est exact :
- Tu nous as présenté une carte « GLOBAL POWERCUT DCC POWER ». J’ai compris qu’il s’agissait de mesurer le courant et de couper l’alimentation DCC à l’aide d’un relais au-dessus d’un certain seuil de courant et également un seuil temporel. Le tout au travers d’un MEGATINY. Le système serait donc autonome de toute centrale DCC.
- Tu nous as ensuite parlé « du petit frère », le GLOBAL SWITCHER DCC SIGNAL ALIGNED, mais qui ne me semble pas être un petit frère mais une carte servant à « aligner les signaux DCC » dans le cas de boucles de retournement, ponts tournants etc… dans laquelle on ne retrouve plus la détection de courant ou tout au moins dans l’approche classique de coupure du DCC en cas de court-circuit.
- Je passe le CONFIGURABLE GLOBALS DCC SWITCHER qui ne semble pas avoir vécu longtemps.
- Puis arrive le CONFIGURABLE GLOBALS DCC SWITCHER BREAKER qui est, si je comprends bien, la synthèse des deux premiers. Je suppose que ce n’est plus un MEGATINY ? Tu dis précédemment « Je suis passé sur un CPU un peu plus gros (toujours dans la série des ATTINY en brochage SOIC20 broches) » ???
Mon sentiment est que à vouloir ajouter et encore ajouter des fonctionnalités cela fini par être compliqué et certainement moins efficient.
Pero, je pense qu’une carte mesurant la consommation de courant et coupant l’alimentation (relais que pourtant il me semblait que tu n’approuvais pas) au-dessus d’un certain seuil paramétrable est quelque chose de très bien et ne doit faire que cela. Donc à priori la première carte proposée GLOBAL POWERCUT DCC POWER peut-être un peu améliorée, pourquoi pas.
Pour les paramétrages via CV, je pense franchement qu’il y a beaucoup mieux à faire, par interface web par exemple, quitte à changer pour un ESP32 plus cher certes mais à plusieurs points de vue, plus intéressant, je crois !
Merci dans tous les cas pour le travail réalisé.
Christophe
-
Bonjour
Tu as raison et je me dois de mieux expliquer ces évolutions.
Aucune allergie au relais! "C 'est un acquis". J avais des doutes sur son temps de bascule qui ne peut être inferieur à 5-10ms en gros mais c'est "acceptable".
Pour memo les centrales du commerce disjonctent en cas de CC au delà de 50 à 100ms.
1/Autonomie totale ou non:
A l'origine j ai imaginé mes premières versions comme des compléments modulables et enfichables pour le nouveau hardware des satellites autonomes.
J avais en effet retenu un petit CPU ( MEGATINY 202 ou 402 par exemple en brochage à 8 broches au format SOIC8).
Je pensais en effet qu'il n'est pas opportun de mettre une interruption sur le CPU principal des satellites qui ont déjà de quoi faire de leur coté. ( la fameuse boucle des 100ms dont tu as déjà parlé)
2 sujets étaient à traiter:
- le cas types boucles de retournements: " auto loop" pour gérer les inversions de polarités
- la protection sectoriel ( "disjoncteur") au delà d un seuil et d'un temps de bascule (circuit breaker)
A force de travail sur le routage du PCB, je me suis rendu compte que ces 2 éléments peuvent partager un hardware commun (un simple double pont à réaliser au dos du PCB permet de passer d'un modèle à l'autre).
Toutefois il faut alors accompagner le paramétrage du code tournant sur le CPU.
Un simple pont pourrait aussi résoudre en partie ce "dilemme". Oui mais...
Il peut y avoir plusieurs valeurs possibles (seuil et temporisation notamment en fonction des hardware environnant ( ex Centrale du commerce)) . Donc, sauf à figer en dure ces éléments (à la fabrication et à l injection du code) l'idée d'ajouter une possibilité de reconfiguration/paramétrage sous la forme d'un décodeur d'accessoire DCC qui permet de modifier des CV et offrir des réglages est venue. (Ce qui a imposé de changer le CPU d'origine par un plus "gros" toujours en MEGATINY mais en 20 broches cette fois ( choix reposant sur les dispo de CPU)
Oui, une IHM web (sous un ESP32) est top pour le faire mais perso je ne sais pas (encore) faire... Après un ESP32 dédié pourquoi pas mais ca me semble "riche"...
On peut aussi utiliser ces éléments de façon autonome.(en dehors des satellites)
2/évolutions hardware:
Au niveau hardware les puissances à traiter imposent des choix notamment sur la sélection des relais:
Les relais de signaux (bobinage 5V) coupent jusqu'à 30V sous 2A. Parfait pour notre usage de gestion des boucles mais un peu "léger" pour un disjoncteur sectoriel (avec un secteur étendu). D'où une version "BIG" qui impose un relais plus "gros" capable de couper 5A ou 8A (à peine plus lent à la commutation).
J'ai gardé sur tous ces hardware la possibilité de sortir les info et commander leur bascule/reset de façon externe.
En cas de paramétrage de valeurs par CV par exemple on a besoin de plus de capacités coté CPU.
A noter que sur le socle de base du satellite j'ai prévu un emplacement pour recevoir un INA219 ( sortie en I2C, qui mesure aussi tension et ampérage).
Mais j'ai pensé que de confier ces taches à l ESP32 gérant le satellite n'était pas adapté pour trois raisons:
1- tache supplémentaire sur le CPU principal ( ESP32)
2- complexité au niveau de priorisation des valeurs reçues et de leur traitement. ( tu peux avoir des avis différents)
3- les temps requis pour exploiter ces éléments.
A ce stade on garde donc l'embarra du choix. Il peut encore y avoir des évolutions avant une production et nos échanges ici contribuent à enrichir les solutions qui seront retenues.
Si on vise au plus simple alors on reste sur des versions "basics" ou c'est à l'injection d'un code "fixe" sans possibilité de réglages.
Si on veut plus offrir des réglages il faut en tenir compte et permettre cette interaction sous une forme ou un autre.
Laurent
PS: les noms ont aussi évoluer pour harmonisation avec les termes Anglo saxon les plus souvent utilisés. POWERCUT = CIRCUIT BREAKER )
-
J oubliais aussi de préciser que les versions avec la gestion du DCC incorporent non seulement le hard pour le traiter ainsi que leur propre alimentation DC-DC generant le 5V DC depuis le signal DCC.
Les versions de base n'incluaient pas:
- une sortie produisant la valeur mesurée. ( sur un analoguWrite()
A voir donc selon ce que l'on désire in fine.
Laurent
-
Bonsoir
Je me suis donc remis sur une version simplifiée.
"Petit CPU" (MEGATINY 8 broches type ATTINY202/402/212/412).
2 rôles exclusifs l'un de l'autre sont possible selon le pontage de plots au verso de la carte:
- Soit un mode pour gérer l'autoreverse en cas de détection de CC (LOOP MODE)
- Soit un mode pour gérer la coupure d alimentation en cas de CC "prolongé ( MODE BREAKER)
Les paramètres seront encodés en dure pour chaque mode dans le code du CPU.
Il n'y aura rien à traiter de plus.
L'alimentation du montage est externe en +5V &GND.
Un plot pour générer une interruption par impulsion permet de basculer le relais come la pression sur le switch poussoir.
On dispose d'un indicateur visuel sur la carte pour connaitre l'état.
On peut disposer de l'état vers l'extérieur.
Dans ce cas les modes d alimentation +5V ou une avec une autre tension ( ex +3V3) sont possibles.(leurs masses sont communes)
On n'exporte pas la lecture de la conso.
J'ai encore un peu de travail sur le code correspondant mais très bientôt dispo.
Je pense mettre:
A/ pour le mode breaker un seuil proche de 30 à 40ms avant coupure.
La sensibilité sera réglée pour 2A MAX (ce que peut supporter le relais)
Tout dépassement de cette conso plus de 30ms entraine la bascule
B/ 10ms à 20ms pour le mode reverse
Le seuil de détection peut ici être plus bas ( quelques mA) et tout dépassement à compter de 10ms entraine la bascule
A noter que le temps de bascule du relais est très voisin de 5ms. (HONGFA HFD2/005-S-L2) (https://www.tme.eu/Document/cb545971aaf7e641179e4750a1704dc9/HFD2_en.pdf (https://www.tme.eu/Document/cb545971aaf7e641179e4750a1704dc9/HFD2_en.pdf))
Je suis preneur de vos avis sur ces valeurs de temporisation.
Plusieurs essais seront possiblement nécessaires pour trouver le juste milieu.
Laurent
-
Bonsoir
Apres le "récréation" sur la substitution des relais pas des transistors MOS (et quelques composants périphérises) dans les cas de gestion de commutation des pointes de cœur et des boucles de retournement, nous appliquions les principes mis en œuvre et reprenons nos avancées sur la carte V2 du SATELLITE AUTONOME.
En effet, en portant un module de gestion de boucle ( type LOOP AUTO REVERSSER) avec POWER GUARD ( surveillance globale de conso / détection de seuil et donc de court circuit ) nous pouvons exploiter ces éléments pour nos satellites en apportant les fonctionnalité suivantes:
A/ détection de surconsommation ex >2A / et de cour circuit
B/ mise en protection (coupure de la distribution du DCC vers la voie)
C/ bascule de la polarité en cas d'inversion des pôles DCC vers la voie
Il nous faut pour cela compacter et placer nos composants puis les interfacer avec notre ESP32 sur une carte socle.
Pour cela nous allons nous appuyer sur la distribution que Christophe a attribué préalablement sur les V1 mais nous rêverons possiblement certains MAPPINGS PINS/Usages pour des commodités de routage du PCB. Les ajustement de codes suivront.
Mes premiers essais sont encourageants pour une compacité optimale.
L'approche modulaire/modulable a pour but de favoriser une maintenance simplifiée et un remplacement simplifié ( donc rapide) en cas de panne de blocs fonctionnels.
Pour des questions de choix personnels, je laisse un CPU secondaire (un MEGATINY) gérer de façon autonome la détection de CC et la bascule. Je transmets juste ces info via optocoupleurs vers l ESP32 ( ce dernier fonctionnant en 3V3 et les autres éléments en 5V, nous passons par cet étage de conversion des états 1/0).
De même nous confiront à l'ESP 32 le soin d'effectuer un réenclenchement en cas de disjonction/mise en protection du satellite en cas de (long) CC ( via l'interface WEB par exemple ou autre mécanisme encore à définir) . Nous conserverons un bouton local pour action de bascule dans la distribution des pôles DCC. (ce qui peut aussi résoudre certains cas de CC)
Nous allons je pense aussi retrouver sur ce socle la gestion du CAN et de l'alimentation en 5V du montage depuis une source externe ne provenant pas du signal DCC sorti de la centrale ou d un booster.
Nous pourrons y placer l'ESP32 ainsi que le module de traitement du RAILCOM.( 40mmx40mm)
Voila déjà de quoi bien remplir notre PCB de 10cm x10cm!
Ltr
-
Bonjour
Voici une vue en cours de construction de cette V2.
Il reste encore du chemin pour finaliser dont quelques choix à arrêter ( ex extension 74HC595 maintenue?), ajout de l I2C mais on, commence deja a voir une bonne idee d ela solution.
On retrouve:
En haut à droite la partie gérant la protection et l inversion.
En dessous la partie CAN avec le CMP2562
En bas à droite la partie POWER à laide d un module externe ( plus économique à intégrer ainsi)
Au centre on identifie bien l ESP32.
A sa gauche la zone en construction dans le bas
Au milieu la partie "découverte" avec la mesure par "COIL" ( plusieurs modèles d'empreintes possibles déjà mise en place)
En haut à gauche la sortie DCC vers les voies ou d'autres extensions.
C est le moment c est l'instant d'indiquer vos doléances car les I/O ne sont pas inépuisables et il faudra alors procéder à des choix.
Ltr
-
Il reste encore du chemin pour finaliser dont quelques choix à arrêter ( ex extension 74HC595 maintenue?), ajout de l I2C mais on, commence deja a voir une bonne idee d ela solution.
Bonsoir Laurent,
On commence à voir à quoi ça va ressembler en effet.
Je pense que les 74HC595 + ULN2803 + résistance est une solution plus simple que l’I2C
Je ne retrouve pas les RJ45 du bus CAN qui sont également les connecteurs pour l’alimentation 12 / 24 V
Pour le power, il n’y a en effet besoin que d’un connecteur.
Pour les BP du mode découverte et pour le switch, il faut respecter l’implantation que j’ai pour que ce soit intuitif. BP – /switch / BP + sur la même ligne
Tu as bien prévu une mesure de courant pour les CC ~ 2,5A et une autre pour courants faibles ?
Bon courage.
Christophe
-
Hello
Oui ca turbine!
Pour les boutons BP+ et BP- il seront légendés pour bien les distingués.
J ai jouté un DIP SWITCH pour les adresses (3 inter donc au lieu de 2)
J'ai pour le moment sorti les connecteurs RJ45.
Chaque carte se voir à minima avec 3 entrées sur 3 borniers distincts:
BUS DCC ( PWR)
BUS CAN
BUS POWER
Choix en phase avec les intensités là où c'est requis. ( et d un léger manque de place sur du 10x10) On pourra les intégrer sur des modules extension pour la compatibilité si besoin.)
Les extensions se font par des connecteurs au pas de 2.54 qui nativement peuvent encaisser jusqu'à 3A individuellement. (ils sont doublés à minima pour la partie DCC)
Ainsi le module RAILCOM vient "en chapeau" sur la quart haut gauche de la carte (nord ouest)
Les pistes hors DCC sont tracées pour supporter 1A sur tout ce qui est signal et distribution basse tension. (confort donc!)
Le "COIL" permettra de mesurer la conso dans la voie au niveau de l'ESP32 y compris pour les faibles conso donc ceci nous assurera la détection d'occupation globale.
Seul inconvénient son emplacement relativement prêt de l antenne WIFI de l ESP32. JE verrai si j arriva a le glisser vers le bord de la carte et à l'en écarter.
L'ACS712 qui est présent à un autre rôle, celui de disjoncteur en cas de CC prolongé et la mise en sécu de la distribution du signal DCC si le CC perdure.
Dans le cas contraire le mode auto sens peut s'activer pour réaligner les phases des pôles en sortie. (montage issu du LOOP avec POWER GUARD retranscrit ici)
Ce rôle n'est pas piloté par l ESP32 mais par un MAGATINY x4.( local)
Un bouton permet la bascule locale et le réarmement. Ce réarmement/bascule peut aussi être initié par l'ESP qui est notifié en cas de CC. (ca bouffe 2 IO au passage)
Les optocoupleurs assurent la transition 5V<=>3V3 des niveaux logiques. La bascule et cette partie du montage prend sa source sur le signa DCC à contrario de la partie sous ESP32 qui dispose de sources séparées par un convertisseur DC DC depuis toutes sources externe.
En revanche pas de chance avec les quotas de PINS dispo/occupées:
La présence du pilotage d'extensions sous 74HC595 est présent ( au sud de la carte) mais son implémentation va réduire la présence de 2 servos max en natif sur la carte directement. Il faudra passer par le bus I2c pour des extensions ( ex avec un PCA9685 qui en supporte 16! mais aussi des leds,...)
Sinon peut être se servir du 3eme switch présent pour choisir soit 4 ou 5 servos en local à la place du bus pour le 74HC595. ( et inversement) C'est une option à considérer.
Ce bus I2c possède son port d'extension à l'OUEST de la carte ( cote gauche donc) ainsi qu'un connecteur pour les 2 capteurs ponctuels.
J ai encore un peu de travail! Mais ça chemine (plutôt) bien!
De plus une partie des cartes venant à l'OUEST est déjà en "conception" (pilotage d I/O pour boutons, servo, commande de relais, signaux, ...) et de relais pour la distribution du signal DCC dans les zones complexes (grills d aiguillages)
Idem au sud pour un carte à base de 74HC595.
Je dois aussi prévoir 2 places pour placer le départ/retour sur bobinage du "coil": avant et après le module RAILCOM. Ce qui sera selon les tests intéressant de voir quelle est l'implémentation la plus intéressante.
Encore quelques jours me seront nécessaires pour finaliser le tout d autant que la semaine cote pro va être intense!
Si tu as quelques suggestions à glisser je prends :)
Je préparerai aussi un nouveau tableau avec les nouvelles affectations des broches sur leurs nouveaux usages.
Encore du travail donc! :)
Ltr
-
Avec une petite vue actualisée du dispositif.
-
Bonjour
Petite vue illustrative du principe des "extenders" raccordés sur la carte satellite autonome V2.
Ici on voit qu'il faudra permuter les connecteurs du haut et du bas pour une question d'ergonomie évidente lors du câblage. LE connecteur au "sud" recevant alors les I/O de commande depuis l extendeur pilotant les sorties. Cela sera redessiné.
La liaison s'opèrent latéralement ici vers la gauche via les connecteurs au pas de 2.54 pour le signal DCC
Le même principe sera conservé au "sud est" avec un autre extendeur en charge du pilotage des I/O supplémentaires qui viendra ici piloter les relais via son connecteur("nord") La source de cet "extender" sera sur le connecteur d'extension latérale ad hoc offrant le support du bus I2C.
On imagine donc très bien les combinaisons futures... et les chainages qui s'offrent à nous ensuite.
Nous n'y sommes pas encore tout à fait mais nous cheminons!
Ltr
-
Bonjour
J ai beau bien regarder il est délicat de pouvoir ajouter la circuiterie qui va avec un détecteur de présence réglable sur cette version et de rester sur un format 10cmx10cm. ( je vais encore creuser la question)
De plus cela ajoute un bloc fonctionnel susceptible de panne qu'il serait heureux de pouvoir substituer individuellement facilement sans tout devoir remplacer.
Je pense devoir sortir de cette limite de dimensions pour pouvoir sereinement ajouter ce qu'il faut pour couvrir le besoin.( sans aller viser un A4 non plus!)
Dans l'attente du montage final sur la détection courant faibles en cours de ciblage, nous pourrions déjà valider la combinaisons des enchainements des "étages fonctionnels"
D'après mes lectures sur le sujet et la doc LENZ on doit cascader du plus prêt du train vers sa source d alimentation (DCC) les blocs suivants:
1/Détection RAILCOM
2/Détection d'occupation globale (présence)
3/Détection de CC et protection ou "reverse"
4/Source DCC (BOOSTER ou Centrale)[/li][/list]
Valide t on déjà cette cascade d éléments?
Ltr
-
D'après mes lectures sur le sujet et la doc LENZ on doit cascader du plus prêt du train vers sa source d alimentation (DCC) les blocs suivants:
1/Détection RAILCOM
2/Détection d'occupation globale (présence)
3/Détection de CC et protection ou "reverse"
4/Source DCC (BOOSTER ou Centrale)[/li][/list]
Valide t on déjà cette cascade d éléments?
Laurent,
Je ne comprends pas ce que tu veux dire : D'après mes lectures sur le sujet et la doc LENZ on doit cascader du plus prêt du train vers sa source d alimentation (DCC) les blocs suivants
Donc oui je suis d'accord avec les 3 premiers points :
1/Détection RAILCOM
2/Détection d'occupation globale (présence)
3/Détection de CC et protection ou "reverse"
mais ne comprenant pas le dernier !!!
Christophe
-
Le dernier point c est ta source du signal DCC qui va vers les voies soit venant de la centrale, soit d un booster.
Ce dernier point est en fait le point d'entrée dans nos montages.
On peut le numéroter "bloc fonctionnel 0" l'arrivée du DCC.
Détection CC et inversion en "bloc fonctionnel 1"
Détection présence en "bloc fonctionnel 2"
Détection RAILCOM en "bloc fonctionnel 3"
Mieux défini ainsi?
Ltr
-
Je serais d'avis de dissocier la detection CC des satellites pour 2 raisons :
- la majorité des cantons n'en ont pas besoin
- un canton peut avoir plusieurs aiguillages à la suite et donc plusieurs frogs à alimenter indépendamment.
-
La partie protection / reverse n a pas pour but de traiter les cas des “frog” au niveau local ( elle le pourrait cependant mais cela imposerait selon moi un câblage dissocié de chaque cœur, donc autant traiter leur polarisation directement en // de la commode du servo par bascule d un relais ( simple efficace et suffisant )
Elle a pour but d aligner les pôles notamment dans le cas de grills complexes d aiguillages ou un canton horaire ferait face à un antihoraire. ( cas d une boucle notamment )
On peut comme tu le soulignes la sortir du socle. Mais il faudra plus de contact in/out pour traiter les échanges avec le socle
Telle que j imagine alors les choses on pourrait avoir 3 blocs fonctionnels enfichables selon la combinaison de fonctions à produire depuis l’entrée Dcc vers la voie :
Protection / reverse
Détection occupation
Détection railcom ( identification est plus juste d ailleurs)
( puis extension distribution pour grills complexes)
Ou
Seulement les deux derniers par exemple
On aurait alors un socle “carte mère” recevant ces sous ensembles. Au prix de dimensions un peu plus généreuses sur le socle ( type 10cm x 15 ou 16cm)
Ce surcroît offrira aussi la possibilité t intégrer plus de composants sans “extenders direct”
Si un bloc n’ est pas utilisé on le bouchonne simplement .
Je dois creuser à ce niveau, ce n est pas immédiat et cela va entraîner quelques heures de dessins aussi.
À discuter donc…
Ltr
-
Bonjour
Christophe, pour la gestion d un accessoire ( ex commande de servo avec commutation du relais de polarisation de la pointe de cœur, commande d'un signal,...) est il possible d'imaginer avoir un mécanisme de traitement type "découverte" pour appairer un satellite et un accessoire? ce qui aurait pour but dans ce cas de créer des "couples" [satellite N; accessoire X] qui seraient commandés alors par le bus CAN...
Un petit MEGATINY, un transceiver CAN, une gestion d alim locale et ce que l on veut ajouter sur chaque petite carte (satellite de satellite) ( PS non j ai rien pris! tout va bien) en somme...
Ce qui nous affranchit alors de bus d extension directement type I2C ou à base de 74HC595... et permet de nouveaux type d extensions, même déportés comme pour gérer un TCO avec boutons et leds, commande d un passage à niveau, ... et réduit à 3 bus à distribuer sous le réseau:
Le CAN, le DCC et un bus d alim des accessoires et cartes
Bon coté dimension je ne ferai pas moins que du 180mmx100mm avec les options actuelles.., peut être pas très optimal comme dimension. En FULL CAN un retour sous 100x100 devient possible...
Qu'en penses tu? On satellise les extenders via CAN?
Laurent
-
@Laurent
Christophe, pour la gestion d un accessoire ( ex commande de servo avec commutation du relais de polarisation de la pointe de cœur, commande d'un signal,...) est il possible d'imaginer avoir un mécanisme de traitement type "découverte" pour appairer un satellite et un accessoire? ce qui aurait pour but dans ce cas de créer des "couples" [satellite N; accessoire X] qui seraient commandés alors par le bus CAN...
Oui le principe est envisageable et le CAN est particulièrement fléxible pour ce genre de choses mais...à la condition que je vais poser ci-dessous.
Un petit MEGATINY, un transceiver CAN, une gestion d alim locale et ce que l on veut ajouter sur chaque petite carte (satellite de satellite) ( PS non j ai rien pris! tout va bien) en somme...
Ce qui nous affranchit alors de bus d extension directement type I2C ou à base de 74HC595... et permet de nouveaux type d extensions, même déportés comme pour gérer un TCO avec boutons et leds, commande d un passage à niveau, ... et réduit à 3 bus à distribuer sous le réseau:
Le CAN, le DCC et un bus d alim des accessoires et cartes
Le problème je pense est que l'ATTiny n'a pas de bus SPI ! Alors le MEGATINY que je ne connais pas est-il dans le même cas ? C'est essentiellement un problème de hard. Sur n'importe quel µC à base d'AVR qui disposerait d'un bus SPI doit pouvoir fonctionner avec nos bibliothèques CAN bien aimées. J'ai vu qu'il devait exister des solution logicielle pour avoir du SPI sur ATTiny85.
Et pourquoi pas un ATmega328 et un quartz ? Le satellite peut fournir sans problème le 5V nécessaire.
Jean-Luc saurait certainement nous répondre et connais de toutes les façons des solutions CAN "low cost" puisque c'est de ça dont il s'agit.
PS : Il reste des broches dispo sur l'ESP puisque j'ai viré le RFID. Voir schéma fin article 2
-
Les MEGATINY ont nativement le SPI et incluent leur lib SERVO donc:
ACAN compatible!
SLOW SERVOMOTION compatible!
Autant rester sur des pièces HARD qui nous offrent nativement ce dont on a besoin, économiques, dispo et flexibles ( nombreuses ref possibles)
Plus d info pour tt cela grâce à ceci:
https://github.com/SpenceKonde/megaTinyCore/tree/master/megaavr/libraries/SPI (https://github.com/SpenceKonde/megaTinyCore/tree/master/megaavr/libraries/SPI)
et plus généralement
MEGATINY CORE:
https://github.com/SpenceKonde/megaTinyCore/tree/master (https://github.com/SpenceKonde/megaTinyCore/tree/master)
DX CORE
https://github.com/SpenceKonde/DxCore (https://github.com/SpenceKonde/DxCore)
A user sans moderation! ( et tres pratique à l'usage!)
Ltr
-
Et on les achète où ces petites bêtes ? Un lien sur un site marchand ?
-
Pour des proto rien de mieux que d utiliser ce type de carte:
Pour MEGATINYCORE:
https://www.microchip.com/en-us/development-tool/DM080104 (https://www.microchip.com/en-us/development-tool/DM080104)
ex chez MOUSER:
https://www.mouser.fr/ProductDetail/Microchip-Technology/DM080104?qs=sGAEpiMZZMuqBwn8WqcFUj1SFkunHY10MiU1bSRVZdO1ag7jWmWQuQ%3D%3D (https://www.mouser.fr/ProductDetail/Microchip-Technology/DM080104?qs=sGAEpiMZZMuqBwn8WqcFUj1SFkunHY10MiU1bSRVZdO1ag7jWmWQuQ%3D%3D)
ou
https://www.mouser.fr/ProductDetail/Microchip-Technology/EV50J96A?qs=sGAEpiMZZMuqBwn8WqcFUj1SFkunHY10pOzHZoSU7PqXNqc0wSi7Lw%3D%3D (https://www.mouser.fr/ProductDetail/Microchip-Technology/EV50J96A?qs=sGAEpiMZZMuqBwn8WqcFUj1SFkunHY10pOzHZoSU7PqXNqc0wSi7Lw%3D%3D)
La différence c est la taille de la mémoire( 16k vs 32k) mais l'archi est similaire.
pour DX CORE:
https://www.microchip.com/en-us/development-tool/EV35L43A (https://www.microchip.com/en-us/development-tool/EV35L43A)
ex chez MOUSER:
https://www.mouser.fr/ProductDetail/Microchip-Technology/EV35L43A?qs=sGAEpiMZZMuqBwn8WqcFUj1SFkunHY10BFYc6DllOgqEScMi970BUg%3D%3D (https://www.mouser.fr/ProductDetail/Microchip-Technology/EV35L43A?qs=sGAEpiMZZMuqBwn8WqcFUj1SFkunHY10BFYc6DllOgqEScMi970BUg%3D%3D)
Et dans le pire des cas un AVR NANO EVERY peut aussi convenir pour "dépanner" puis que c'est un "cousin" des MAGATINY et AVR Dx.
Au niveau dispo de puces ensuite j utilise souvent OCTOPART.com pour faire une recherche sur les volumes mondiaux dispo, voir les couts... et choisir un fournisseur ou une pre commande chez JLCPCB avant assemblage.
A noter que pour un brochage défini les volumes de mémoire peuvent influer sur les dispo des références donc... on cible ou on substitue.
Ta CB va chauffer ;)!
Ltr
-
Oui ça n'a rien de tiny, surtout pas le prix.
Pourquoi ne pas prendre un bon nano en clône à 1€ ?
-
Paracerque le NANO première génération à base de 328P me semble un peu "HASBEEN".
Sur un PCB dédié c est un peu gros mais sur un PCB socle pourquoi pas cela offre la possibilité à plus de personnes de réaliser le montage.
Que la dispo et son prix ne sont pas ou plus toujours très compétitifs en regard des nouveaux composants et de leur possibilités. Mais dans l absolu un 328P peut le faire.
Mais je pense que tu verras à l usage que les MEGATINY et AVRDx offre des avantages certains.
Ltr
-
En terme d alternative il y aurait bien les Raspberry Pico nano ( en module ou en CPU a integrer mais vu le prix d un module avec USB alim... )
Musclés, economiques, mais d un autre niveau à programmer .
https://fr.aliexpress.com/item/1005006071676557.html?spm=a2g0o.productlist.main.3.561338e3AboPso&algo_pvid=5e9470d1-b5b8-4f49-af33-66605470331d&aem_p4p_detail=202402141844371502732058331140010563228&algo_exp_id=5e9470d1-b5b8-4f49-af33-66605470331d-1&pdp_npi=4%40dis%21EUR%212.68%212.55%21%21%2120.23%2119.22%21%4021038e7717079650770221092eb582%2112000035596473659%21sea%21FR%210%21AB&curPageLogUid=rL33Nu64KZG0&utparam-url=scene%3Asearch%7Cquery_from%3A&search_p4p_id=202402141844371502732058331140010563228_2 (https://fr.aliexpress.com/item/1005006071676557.html?spm=a2g0o.productlist.main.3.561338e3AboPso&algo_pvid=5e9470d1-b5b8-4f49-af33-66605470331d&aem_p4p_detail=202402141844371502732058331140010563228&algo_exp_id=5e9470d1-b5b8-4f49-af33-66605470331d-1&pdp_npi=4%40dis%21EUR%212.68%212.55%21%21%2120.23%2119.22%21%4021038e7717079650770221092eb582%2112000035596473659%21sea%21FR%210%21AB&curPageLogUid=rL33Nu64KZG0&utparam-url=scene%3Asearch%7Cquery_from%3A&search_p4p_id=202402141844371502732058331140010563228_2)
Pour le CAN dessus:
https://github.com/KevinOConnor/can2040 (https://github.com/KevinOConnor/can2040)
-
Oui ça n'a rien de tiny, surtout pas le prix.
Pourquoi ne pas prendre un bon nano en clône à 1€ ?
Exemple de recherche pour un MEGATINY 1606 ( ATTINY1606)
https://octopart.com/search?q=ATTINY1606¤cy=EUR&specs=0 (https://octopart.com/search?q=ATTINY1606¤cy=EUR&specs=0)
Bon, on est loin du prix du module dev proto ( /24 en gros mais juste pour le CPU)
Ltr
-
Bonjour
A la réflexion "cout" une soluce AVR( MEGATINY ou AVR Dx) + MCP2515 (ou MCP2517) +MPC2562 + alim etc fait que cela semble moins intéressant (plus onéreux et fonctionnellement moins riche) que de prendre directement un petit ESP32 a qui confier le job avec un MCP2562.
Lequel prendre? Un double cœur est il obligatoire pour gérer le CAN et afficher quelques leds ou piloter un servo et un relais? ( carte a usage unitaire: ex 1 servo avec un relais à piloter pas plus, pas de carte globale pour gérer N périphériques, ce qui entrerait alors dans de la config dynamique un peu laborieuse a mettre en œuvre simplement)
l ESP32 offrirait en plus nativement une vue web de config ( ex mapping couleur des feux sur les sorties, réglages vitesse de clignotement, réglage du servo( vitesse, pos max, pos min, vitesse du mouvement...) ... alors pourquoi s'en priver?!!
Ltr
-
Bonjour Laurent,
Toi qui est à l'aise avec KiKad, je me demande dans quelle mesure il ne faut pas acheter l'ESP32 seul (env 3€) au lieu de carte de développement plus onéreuses (10€) et surtout plus encombrantes.
Du coup, ça fait une belle mécanique pour tes cartes "secondaires" tout en restant peu encombrant et économique.
Si cela était possible, ce serait super sympa bien sûr de le faire aussi pour les satellites.
Mais sinon, oui un ESP32 en carte de développement reste un super rapport qualité/performance/modularité/prix
Christophe
PS : Perso, je ne comprends pas très bien cette envie de réduire à tout prix la taille des cartes ! Elles sont souvent sous le réseau, quel est le véritable intérêt ?
-
Bonjour
Pour la taille comme pour le prix il faut trouver des optimaux en gardant une simplicité de mise en œuvre ( soft, hard, connectique , fabrication (dont injection du code) , réglages, dispo, ...)
Je trouve "surfait" de mettre un gros dev kit ESP32 pour ne gérer que une ou deux I/O mais leur prix fait pencher vers eux naturellement:
on perd en surface et connectique avec des DEV kits comme celui ci à prix discount mais tout est dessus:
https://fr.aliexpress.com/item/1005006140560853.html?spm=a2g0o.productlist.main.25.610e5515yNHlaY&algo_pvid=0fe03238-fd9a-403d-ada1-f255d7f50832&aem_p4p_detail=202402150431591441831242318720011327211&algo_exp_id=0fe03238-fd9a-403d-ada1-f255d7f50832-12&pdp_npi=4%40dis%21EUR%211.75%210.88%21%21%2113.21%216.61%21%40211b618e17080003192136452e3ad9%2112000035941612021%21sea%21FR%210%21AB&curPageLogUid=dj27IzI8coly&utparam-url=scene%3Asearch%7Cquery_from%3A&search_p4p_id=202402150431591441831242318720011327211_13 (https://fr.aliexpress.com/item/1005006140560853.html?spm=a2g0o.productlist.main.25.610e5515yNHlaY&algo_pvid=0fe03238-fd9a-403d-ada1-f255d7f50832&aem_p4p_detail=202402150431591441831242318720011327211&algo_exp_id=0fe03238-fd9a-403d-ada1-f255d7f50832-12&pdp_npi=4%40dis%21EUR%211.75%210.88%21%21%2113.21%216.61%21%40211b618e17080003192136452e3ad9%2112000035941612021%21sea%21FR%210%21AB&curPageLogUid=dj27IzI8coly&utparam-url=scene%3Asearch%7Cquery_from%3A&search_p4p_id=202402150431591441831242318720011327211_13)
A comparer avec un module similaire :
https://www.lcsc.com/product-detail/WiFi-Modules_Espressif-Systems-ESP32-WROOM-32D-N4_C473012.html (https://www.lcsc.com/product-detail/WiFi-Modules_Espressif-Systems-ESP32-WROOM-32D-N4_C473012.html)
Edifiant!
Pour la taille pure dans des zones de forte densité plus c'est petit mieux c'est. ( y compris pour nos amis Nistes) ( mais ca se discute) ( ex cas d une potence avec plusieurs feux) surtout si c est uni fonctionnel ( ex 1 satellite de satellite pour 1 feu ( n sorties) , un autre pour un servo avec son relais, ...) Raison pour laquelle je pense que de mettre des modules natifs ESP32 est peut être plus avantageux (en place surtout) . Lequel prendre?
Cote prix il faut garder en tête le cout global et trouver un bon rapport prix/ facilité de mise en œuvre. (pour le plus grand nombre ou avec des consignes ad hoc)
Intégrer un module natif ESP32 ne pose pas de soucis cote layout du PCB, il faut juste bien voir ce qui doit être mis autours (alim 5 vers 3V3 + boutons + mémoire éventuelle selon le type de CPU (ex un ESP32 C3 a déjà la RAM et la Flash intégrée au CPU) - et prévoir un connecteur de programmation à défaut d'un mode OTA.
Ca fera gagner de la place mais peut être paradoxalement contribuera à un prix plus chère! ( voir trop chère!)
Pour les satellites de satellites je pense qu'un module ESP32 C3 serait pas mal puisque CAN compatible, prix moindre et suffisamment d I/O pour des usages simples. Mais un WROOM 32D basic est parfait aussi. ( c es celui utilisé déjà sur le DEV KIT C 38 broches des satellites autonomes)
CAN et EP32 C3:
https://www.seeedstudio.com/blog/2022/07/11/voice-needed-do-you-know-xiao-esp32c3-can-can/ (https://www.seeedstudio.com/blog/2022/07/11/voice-needed-do-you-know-xiao-esp32c3-can-can/)
Mais c est peut être aller trop loin que nos bons vieux DEV KIT classiques plus gros, bien connus feraient l'affaire!?
Besoin de réfléchir collectivement sur les "bons choix"!
Pour moi in fine dessiner avec un composant ou un autre relève du même genre d'exercice, donc à voir cote soft comment se simplifier les choses! ( sans flinguer la CB!)
Ltr
-
Bonsoir ,
(j'étais absent de vos topics et le temps passe vite , alors n'hésitez pas à me (re)poser des questions)
je reviens vers vous pour vous faire part de mes expériences et réflexions quant au choix de différents arduinos selon le besoin (et l'envie) ... pour tout de suite dire qu'il n'y a pas de solution évidente
perso , j'utilise plutôt des arduino complets , avec USB et bootloader , c'est plus facile à téléverser , à paramétrer , et à interfacer avec un PC ; il est placé en carte fille sur le circuit imprimé , qui comporte les autres composants nécessaires au montage
je les classe très subjectivement en 2 catégories : les 5v et les 3v3 ...
- les 3v3 , qui ont l'avantage de la compatibilité avec certains périphériques modernes
- les 5v ont l'avantage d'une meilleure commande des mosfet , d'une meilleure immunité aux parasites , quand on commande par exemple des circuits externes du genre 74HC165 ou 74HC595 , et une compatibilités avec des périphériques classiques capteurs , etc.) en général , les 5v marchent aussi en 3v3
dans un ordre quelconque :
1) Arduino classique à base d'AVR : 5v , convient pour 90% des besoins , manque de capacité pour certaines applis
2) ESP32 , 3v3 , la superstar , puissance , wifi CAN , prix , disponibilité , existe aussi en toute petite carte (avec USB)
perso , je n'aime pas ... : il y a un OS , cad. qu'il s'efforcera sans doute de faire ce qu'on lui demande , mais au final il fera ce qu'il veut : si on lui demande de faire des trucs précis , DCC , railcom , c'est la cata ; de + , mauvais ADC , latence d'ISR anormalement longue et variable , "poor wifi integration design"
(les gens de DCC EX l'ont laissé tomber , ils s'orientent vers du STM32 avec un ESP32 C3 en simple interface wifi)
3) STM32 , amha le top en 3v3 , CAN , mais pas de wifi
4) pi pico , 3v3 , wifi , n'a pas tous les défauts de l'ESP32 , mais des faiblesses comparé au STM32 , pas de CAN
5) les nouveaux AVR de Laurent , 5v , bien , mais désespérément pas de petite carte bon marché
6) UNO R4 , 5v , wifi , CAN , pas de défaut comme ESP32 et pi pico , un peu cher mais il existe des clones acceptables
...
-
Bonsoir
Merci Marc pour ces info utiles à nos réflexions pour conduire à des choix optimums.
Pour ce qui est de mes AVR ce sont plutôt ceux de MICROCHIP mais j avoue commencer à bien les connaitre. :)
Cote ESP32 j ai un peu creusé l'opportunité d'utiliser des modules. Il y en a tellement que c est presque une jungle pour s'y retrouver!
Ex un ESP32 WROOM 32D ( en fin de vie mais discount) ou un ESP32 C3 tiennent la corde.
Vu la très grande hétérogénéité des formats avec les spec j'ai quand même identifié un brochage qui serait pour nous une base commune ( presque substituables pour peu que les pin utilisées soient dispo sur les deux versions)
les versions à base de "32 PINS" et comment les programmer
https://capuf.in/esp32-programmer-v2-capuf-embedded/ (https://capuf.in/esp32-programmer-v2-capuf-embedded/)
Donc un connecteur 6 broches fera bien notre affaire...
Et un programmateur externe bien sympathique pour injecter le code (avant des usages OTA possible ensuite?):
https://capuf.in/esp32-programmer-v2-capuf-embedded/ (https://capuf.in/esp32-programmer-v2-capuf-embedded/)
fonctionne sur le WROOM 32D ou le C3 32S car empreinte de brochage similaire (mais affectation des PINS plus ou moins dispo.) ( à tester of course!)
Comme Marc le souligne il y a pléthore de "petits modules" avec USB natif mais je trouve leur diversité pas évidente à approvisionner dans le long terme et leurs couts plus onéreux...
Vu qu'on va surtout leur demander des choses ultra basiques pas trop d'inquiétude sur leur capacité à faire ( pilotage led, relais, servo, bouton, CAN, voir I2C) Les versions à 1 seul cœur devraient même pouvoir suffire!
Ils offrent surtout une opportunité d'avoir une interface WEB pour lecture/modification de paramètres via un navigateur web! Confort!
Très gros atout donc pour ces CPU.
La réflexion se poursuit donc.
Ltr
-
Dans la série des "petits module avec USB" il a la gamme de chez SEED STUDIO.
Gros intérêt de la maison SEED STUDIO des brochages similaires( 2 X 7 broches) présentant des pin avec usages similaires ( IC2, TX, RX, SPI...) aux même endroits!
Le cout reste raisonnable compte tenu du service rendu.(on peut même envisager de substituer certains produits par d autres pour peu que l on retrouve ce dont on a besoin! (ex pas de partie web partout...)
https://wiki.seeedstudio.com/SeeedStudio_XIAO_Series_Introduction/ (https://wiki.seeedstudio.com/SeeedStudio_XIAO_Series_Introduction/)
Les modules à base d ESP32 C3 et S3 tiennent la corde.
pour le C3
https://wiki.seeedstudio.com/XIAO_ESP32C3_Getting_Started/ (https://wiki.seeedstudio.com/XIAO_ESP32C3_Getting_Started/)
Pour le S3:
https://wiki.seeedstudio.com/xiao_esp32s3_getting_started/ (https://wiki.seeedstudio.com/xiao_esp32s3_getting_started/)
Un challenger toutefois en S3 mais avec un prix "exotique"( impossible à avoir en volume sinon a 8€... et une distribution des broches différente des SEEED:
https://fr.aliexpress.com/item/1005006495429840.html?src=google&src=google&albch=shopping&acnt=248-630-5778&slnk=&plac=&mtctp=&albbt=Google_7_shopping&gclsrc=aw.ds&albagn=888888&isSmbAutoCall=false&needSmbHouyi=false&src=google&albch=shopping&acnt=248-630-5778&slnk=&plac=&mtctp=&albbt=Google_7_shopping&gclsrc=aw.ds&albagn=888888&ds_e_adid=&ds_e_matchtype=&ds_e_device=c&ds_e_network=x&ds_e_product_group_id=&ds_e_product_id=fr1005006495429840&ds_e_product_merchant_id=5326656560&ds_e_product_country=FR&ds_e_product_language=fr&ds_e_product_channel=online&ds_e_product_store_id=&ds_url_v=2&albcp=20871206076&albag=&isSmbAutoCall=false&needSmbHouyi=false&gad_source=1&gclid=CjwKCAiAibeuBhAAEiwAiXBoJBv4vfCDZD0tIRO1RACXZ-dyqSKi0CU-2o9674Jr4EHytD_t2wNAJxoCw0sQAvD_BwE&aff_fcid=6de9d73656b6400f879095c45480380e-1708047788710-05008-UneMJZVf&aff_fsk=UneMJZVf&aff_platform=aaf&sk=UneMJZVf&aff_trace_key=6de9d73656b6400f879095c45480380e-1708047788710-05008-UneMJZVf&terminal_id=bb63e0b038954714a45b278c1b104d79&afSmartRedirect=y (https://fr.aliexpress.com/item/1005006495429840.html?src=google&src=google&albch=shopping&acnt=248-630-5778&slnk=&plac=&mtctp=&albbt=Google_7_shopping&gclsrc=aw.ds&albagn=888888&isSmbAutoCall=false&needSmbHouyi=false&src=google&albch=shopping&acnt=248-630-5778&slnk=&plac=&mtctp=&albbt=Google_7_shopping&gclsrc=aw.ds&albagn=888888&ds_e_adid=&ds_e_matchtype=&ds_e_device=c&ds_e_network=x&ds_e_product_group_id=&ds_e_product_id=fr1005006495429840&ds_e_product_merchant_id=5326656560&ds_e_product_country=FR&ds_e_product_language=fr&ds_e_product_channel=online&ds_e_product_store_id=&ds_url_v=2&albcp=20871206076&albag=&isSmbAutoCall=false&needSmbHouyi=false&gad_source=1&gclid=CjwKCAiAibeuBhAAEiwAiXBoJBv4vfCDZD0tIRO1RACXZ-dyqSKi0CU-2o9674Jr4EHytD_t2wNAJxoCw0sQAvD_BwE&aff_fcid=6de9d73656b6400f879095c45480380e-1708047788710-05008-UneMJZVf&aff_fsk=UneMJZVf&aff_platform=aaf&sk=UneMJZVf&aff_trace_key=6de9d73656b6400f879095c45480380e-1708047788710-05008-UneMJZVf&terminal_id=bb63e0b038954714a45b278c1b104d79&afSmartRedirect=y)
On voir alors que l'offre SEED est plutot bien placée.
Ltr
-
1) Arduino classique à base d'AVR : 5v , convient pour 90% des besoins , manque de capacité pour certaines applis
2) ESP32 , 3v3 , la superstar , puissance , wifi CAN , prix , disponibilité , existe aussi en toute petite carte (avec USB)
perso , je n'aime pas ... : il y a un OS , cad. qu'il s'efforcera sans doute de faire ce qu'on lui demande , mais au final il fera ce qu'il veut : si on lui demande de faire des trucs précis , DCC , railcom , c'est la cata ; de + , mauvais ADC , latence d'ISR anormalement longue et variable , "poor wifi integration design"
(les gens de DCC EX l'ont laissé tomber , ils s'orientent vers du STM32 avec un ESP32 C3 en simple interface wifi)
3) STM32 , amha le top en 3v3 , CAN , mais pas de wifi
Bonjour Marc,
Merci pour cet inventaire intéressant car exhaustif.
Je suis d’accord avec toi sur de nombreux points. Tout d’abord, concernant les Arduino, surtout les Nano. On a tendance à les oublier mais pour pas mal de choses, ils font le job. On les accuse de prendre beaucoup de place, pas trop les Nano mais les Mega par exemple. Sauf qu’un Mega c’est 3 ports série, et plus de 40 broches « vraiment » utilisables. Pas de concurrent à ma connaissance de ce point de vue. Et a-t-on toujours besoin de faire petit ?
Pour l’ESP32, je te trouve trop critique et là encore, tout dépend du besoin. Il est indéniable qu’à ce prix, avec les possibilités offertes, c’est absolument canon.
Sans avoir vraiment optimisé le programme, je fais du DCC avec et aussi du Railcom !!! Alors oui, j’ai 25% des trames qui sont hors des spécifications du NMRA mais tout fonctionne depuis longtemps et de façon très satisfaisante.
Et alors, concernant Railcom, je ne te suis plus du tout. Là aussi nous avons un certain recul (1 an ½) et aucun retour négatif. Michel a même testé avec succès trois lectures Railcom simultanées avec le même ESP.
Il y a un peu de doigté sans doute à mettre quand on développe avec l’ESP32. Chercher à utiliser les deux cœurs mais en sachant que toutes les applications asynchrones l’on fait avant nous (Serial, WiFi, CAN, Web…). Je n’ai pas de recul là-dessus mais je désactive maintenant le Wifi quand je n’en ai pas besoin et aussi le port Serie. Est-ce vraiment efficace ? Dans quelle mesure ?
Quant à DCC-Ex, tu confirmes ce qui se présentait qui est qu’ils ne développeront pas Railcom sur ESP32 ce qui n’est pas forcément une bonne nouvelle pour la Box. Ni pour moi, car même si je dispose d’une solution alternative, j’aurais préféré utiliser la Box avec les satellites autonomes.
Que l’on se comprenne bien, je ne dis pas, loin s’en faut, que l’ESP32 est exempt de défauts, mais qu’on ne peut pas l’exclure car il répond à de très nombreux besoins.
Et une fois encore, c’est le besoin puis le prix qui doivent nous guider. N’est-il pas par exemple plus judicieux de mettre deux ESP sur une carte en répartissant les tâches qu’un seul microcontrôleur qui vaut deux fois le prix.
Christophe
-
Bonjour
Je me suis avancé à projeter rapidement ce que pourrait être physiquement un décodeur à base d ESP32 ( version C3 de SEEED STUDIO ici) avec transceiver CAN MCP2562 pour gérer 2 servos conjointement à 2 relais couplés pour la polarisation de la pointe de cœur de chaque aiguille.
Un bouton pour l'appairage avec un satellite ou pour récupérer un ID CAN voir passer du mode RUN au mode PROG et deux autres boutons pour les valeurs de réglages en + ou en - ( course du servo)
Comme j ai mis des relais "DUAL COILS" le nombre d'I/O est un peu juste ( 11 dispo et 11 utilisées) sans pour autant offrir de témoin visuel pourtant pratique. Sur de simples relais je pourrai récupérer 2 I/O bien utiles pour d'autres usages.
On gagne toutefois la possibilité d avoir une page web pour les réglages.
Ce type de carte a t il du sens?
Si à la place de l ESP32 C3 (version SEED) on a d autres modelés on a peut être un gain...
Ou alors c est un autre type de CPU, comme un MEGATINY mais il faut alors ajouter un module CAN type 2515 ou 2517 et on perd le cote WEB...
J ai du mal à identifier la limite et la bonne combinaison à trouver.
Help!
-
Ce type de carte a t il du sens?
J ai du mal à identifier la limite et la bonne combinaison à trouver.
Help!
@Laurent, c'est surtout que je ne vois pas d'où vient ce projet ni où il va ? Quel rapport avec ce fil que tu as toi-même ouvert et que tu as intitulé "Les SATELLITES AUTONOMES: évolutions du socle initial".
Avec ce dont tu parles, je vois plutôt une petite carte indépendante, un peu comme un décodeur d'accessoires en DCC mais ici en CAN, très bien !
Est une évolution du socle initial ? Pour l'instant je vois apparaitre différentes nouvelles propositions de cartes, mais sans voir la cohérence globale.
Comme j'ai pu le dire récemment, il faut réaliser un listing de besoins, le hiérarchiser et tenter de voir globalement comment répondre à ces besoins de façon rationnelle.
J'ai un peu le sentiment que tu procèdes dans le sens inverse, une technologie t'intéresses et tu te demandes ce que tu pourrais faire avec. C'est bien, mais tu es alors dans un processus de prospective et d'expérimentation.
Marc citait DCC-Ex dans un post récent. Au moins, il faut leur reconnaitre d'avoir une vision assez précise et un cheminement qui ne l'est pas moins.
Alors, pour répondre à ta question, oui selon moi cette carte peut avoir du sens, probablement pour se substituer à des commandes de servos en DCC mais dans les satellites, cela est pour l'instant réglé et s'il devait y avoir amélioration, c'est bien sûr toujours possible, je ne pense pas que ça prendra cette forme.
Christophe.
-
Hello
L idée était venue pour une question de simplification/rationalisation/manque de place de ne garder sur la carte satellite socle que l'interface CAN et de déporter les usages sur des cartes externes recevant le CAN comme bus de data.( quitte ensuite à étendre vers I2C, etc...)
C est en ciblant cet usage que j ai pensé à cette carte à titre d'exemple compte tenu d un choix sur ESP32 C3 ( XIAO) SEEED SUTDIO) ( d autres pourrait aussi bien faire le job)
J avais en tête les propos prudents de Marcel et de Michel sur l'usage de l'I2C au delà de 50cm... ce qui ne manque pas d arriver avec un carte satellite "centrale" et des usages à chaque bout d un canton de plusieurs mètres. D'où le CAN comme "palliatif" au transport "moyenne distance" dirons nous.
J ai en effet les 3 fonctions "de base" à caser sur le socle:
1/PROTECTION/REVERSE
2/DETECTION PRESENCE
3/IDENTIFICATION RAILCOM
Ajoute à cela pour la hardware la gestion de l'énergie avec convertisseur DC DC
et le transceiver CAN avec un ESP32 au cœur du dispositif.
J ai toutefois besoin d I/O en sus et il me faut trouver les bons compromis pour les ajouter.
L'I2C que je pousse en est un moyen. pour une carte fille qui jouxte la carte principale mais pour aller un peu plus loin... le CAN a de nets avantages!
Perso avec des cantons de 3m en gros et des aiguilles à chaque bout la commande centralisée pour des servos est un gageure! (piloter un servo a plus de 2m de distance est une ineptie qui expose à tout un tas de parasites dont je me passe très bien!)
J ai des petits décodeurs locaux pilotant les servos et la polarisation des cœurs par relais mais leur commande est en DCC.( pas la fin du monde non plus!)
Mais comme il n'est pas question de mes solutions passées mais plutôt de solutions au service des satellites autonomes nouvelle version je cherche des optimums.
Nous avons déjà les 3 besoins de bases identifiés( protection/inversion - détection présence - identification railcom)
Nous les complétons avec les 2 capteurs ponctuels à y ajouter
Vient ensuite la question de la gestion des aiguillages: pour nous dans un premier temps via des servos moteurs et idéalement de la polarisation des cœurs en relation
Vient également la question signalisation
S'ajoute aussi la gestion de boutons de commande distants ou non.
Je pense être complet sur les besoins "primaires" avec cette liste.
Les 3 premiers sont couverts, j'ai les solutions. ( avec un peu de dessin derrière)
Reste la suite!... Mais je conviens que ce que j ai en tête a besoin de schémas pour être compris et débattu.
Ltr
-
@Laurent,
Ok je comprends mieux mais effectivement c'est mieux avec le contexte et le besoin.
Cette carte dont tu parles doit s'analyser dans un cadre un peu plus large que tu as déjà abordé, les modules complémentaires ! Soit complémentaires par fonctions, j'entends par là celle qui ne sont pas des fonctions de base (détection, traction, protection...), soit complémentaire par leur implantation "décentralisée" par rapport au satellite.
Tu abordes ici ce qui est un vrai problème pour des réseaux d'une certaine importante (pas la cible visée par le satellite autonome actuel) qui est la distance entre le satellite et certains accessoires.
Dans l'esprit des satellites depuis le début, la piste est dans des cartes plutôt universelles et versatilles. Alors, oui, des cartes satellites "de sous-ensembles" où serait alors regroupées les différentes réponses techniques qui doivent être déportées en cas de besoin.
Alors, il faut lister ses besoins et la solution viendra ensuite.
Pour l'instant, mais peut-être à tort, j'hésite à m'éloigner des µC que l'on maitrise (Arduino, ESP32, ATTiny), je pense que ces trois là répondent déjà bien et je cherche à ne pas trop de disperser "façon puzzle" et ce n'est déjà pas facile.
Oui c'est vrai que je souhaite privilégier dans l'ordre chronologique :
J ai en effet les 3 fonctions "de base" à caser sur le socle:
1/PROTECTION/REVERSE
2/DETECTION PRESENCE
3/IDENTIFICATION RAILCOM
mais je ne souhaite pas non plus m'ingérer dans la conduite de ton projet !
Christophe
-
Pendant que tu me répondais je dessinais ... sous PowerPoint cette fois pour illustrer la topologie que voici illustrée 8)
Oui le cas des distances plus longue est dans le pipe nativement... et aura surement ses propres solutions. ( "type satellites de satellite" dont par exemple la carte de pilotage de servos esquissée plus tôt)
Pour le choix des CPU on a une assez bonne connaisse combinée des "classiques" cités ( AVR/AVR Dx/MEGATINY,ESP32 )et on doit pouvoir bien s'en sortir avec en conjuguant nos talents.
On imagine bien ici au "sud" (bas) l'extension 75HC595 sur une approche similaire aux extenders à "l'ouest" (gauche)
Les3 blocs de fonctions en vert ici sont sur des modules enfichables sur le socle et facilement remplaçables (maintenance en cas de panne et ou réutilisation)
Ltr
-
Oui, outre le fait que ce soit joli, cela me parait cohérent. Je retrouve bien sur la carte principale ce qui doit y être selon moi. Cela la rend utilisable seule ce qui doit suffire pour petits et moyens réseaux. Normalement, compte tenu du fait que j'ai enlevé le RFID, il doit y avoir le nombre de pins.
Pour le soft, il va aussi falloir s'assurer que ça suive mais si on met un µC pour la protection et pour la détection de présence, ça va le faire. Je pense toujours que l'ATTiny pourrait faire le job.
Mais je ne vois pas d'µC sur extenders relais. De même sur extenders I2C (j'en déduit que tu comptes sur l'ESP32), je pense que ça va être dur dur pour le programme !
Merci.
Christophe
-
Ca va être à toi de me dire s'il peut traiter l I2C en // ou si c'est trop juste. ( auquel ca on va devoir se creuser pour des solutions)
Les MAGTINY joueront bien leur rôle sur chaque module
C est bien un chip I2C drivé par l'ESP32 qui va (doit) traiter les I/O nécessaires pour piloter les relais ( leds, servo) supplémentaires) ou des boutons.
Ltr
-
Petit ajout pour illustrer en cas d insuffisance de ressource sur l'ESP312 principal pour traiter l I2C un contournement par EXTENDERS incluant un ESP32 communiquant par bus CAN avec le socle du satellite principal.
Ces extenders avec CPU sont aussi un moyen de déporter localement des commandes (de type IN (bouton, detecteur ponctuel, ...) ou OUT (leds, servos, relais, moteurs, ...)
On comprend ainsi la philosophie de la petite carte "satellite de satellite" gérant 2 servo avec 2 relais évoquée plus tot
Ltr
-
Merci Laurent, je vois que tu a bien compris et intégré la philosophie générale.
Sur le principe, je préfère cela. Un ESP n'est sans doute pas nécessaire pour extender sat : led mais un autre ESP pour l'ensemble des extenders me plait bien.
J'aimerais bien avoir des avis autres comme de la part des concepteurs initiaux, Jean-Luc, Thierry, Dominique mais je ne pense pas me tromper quand à l'esprit et à la direction.
En fait, je veux être prudent concernant l'ESP principal. Il lui faut en effet maintenir une fréquence élevée pour ne pas louper d'évènements. A terme, la partie du programme qui s'occupe de la gestion de réseau doit pouvoir faire 1 cycle en moins de 100ms.
Si on lui donne trop de choses à calculer, il le fera mais hors délais.
Je vais écrire le code pour tester des charges intensives pour environ 20 satellites simultanément, déjà pour mesurer s'il ny a pas de messages CAN perdus et ensuite pour vérifier la bonne exécution de certaines commandes, surtout celles liées à la sécurité (ordres aux locos, coupure de courant en cas de CC).
Je vais essayer de pousser aux limites en réduisant le timing de la boucle de gestion de réseau de 100 à 90 puis 80 ms... Je peux commencer à écrire le programme de test mais je ne pourrai le mettre en œuvre que début mars.
Je sais qu'il y a des optimisations possibles du programme principal (par exemple à ce stade j'exécute le programme pour un sens de loco et pour le sens inverse.) Je peux aussi jouer sur des tâches secondaires comme l'allumage des signaux : Passer de 1 à 2 secondes n'est par exemple pas bien important.
Christophe
-
J ai exclu la l utilisation du WIFI (nbx effets de bords non désiré lorsqu'il est actif) en mode AP entre sat et extenders y préférant le CAN. (par défaut)
Voici la vue du premier des 3 blocs fonctionnels en approche modulaire: celui ci gère la partie PROTECTION/REVERSE
Il est opto couplé avec l'ESP32 à qui il notifie un état de CC. l'ESP peut alors effectuer un RST pour (tenter) de corriger le défaut.
Visuellement un indicateur indique si la distribution des pôles DCC (J/K) est directe ou croisée. Cette information n'est pas transmise à ESP32 ( économie de broches oblige) mais cela serait possible avec ajout d'un opto supplémentaire si cette exploitation de données se révèle pertinente.
A défaut c est auto géré en auto au niveau local.
Ltr
-
Christophe
Mars n'est pas loin, février n'a que 29 jours :)
Pour tes tests tu vas pouvoir alléger la partie gestion des CC.
Le module de gestion de protection/reverse va notifier l'état OK/KO(CC) et couper la distribution du signal DCC.L'ESP32 pourra traiter cela comme une priorité (plutôt) haute ( à définir pour enclencher le SWT qui changera l'état.) Si cet état est persistant l'ESP32 doit temporiser avant de relancer tout autre commande mais dans le même temps il devrait aussi:
A/assimiler le canton comme occupé (en dérangement) et agir sur les trains en conséquence si nécessaire.
B/fermer la signalisation
C/permettre de modifier une position d'aiguille.
Ltr
-
Juste une petite remarque, tu ne prévois pas de passage de vis ?
J ai exclu la l utilisation du WIFI (nbx effets de bords non désiré lorsqu'il est actif) en mode AP entre sat et extenders y préférant le CAN. (par défaut)
On est d'accord de passer en CAN tant que cela est possible ou qu'il n'y a aucune tâche critique. C'est le cas pendant le processus de découverte ou quelques millisecondes de plus ou de moins n'ont pas d'importance.
Voici la vue du premier des 3 blocs fonctionnels en approche modulaire: celui ci gère la partie PROTECTION/REVERSE
Il est opto couplé avec l'ESP32 à qui il notifie un état de CC. l'ESP peut alors effectuer un RST pour (tenter) de corriger le défaut.
J'avais compris que tu ne passais pas par l'ESP32 en cas de CC Il n'y a pas besoin selon moi et je croyais aussi que tu avais prévu un système rapide (à l'instar du LENZ 200 je crois) pour couper le DCC. Tu gagnes une broche et surtout en rapidité. Il faut juste prévoir un réarmement du DCC après un petit délais, mais ça ce n'est pas très compliqué. Pourquoi pas le 555 comme dans le montage d'Eric.
Par contre pour l'occupation, il faut informer l'ESP que l'on est au dessus du seuil (réglable). On a dit que ça pouvait être un signal 0 ou 1. Si l'on est au dessus du seuil de CC, ce n'est pas grave, c'est une information "busy" comme pour l'occupation et c'est vrai en plus.
Visuellement un indicateur indique si la distribution des pôles DCC (J/K) est directe ou croisée. Cette information n'est pas transmise à ESP32 ( économie de broches oblige) mais cela serait possible avec ajout d'un opto supplémentaire si cette exploitation de données se révèle pertinente.
Non je doute que la polarité des rails apporte quelque chose dans le logiciel.
-
Mars n'est pas loin, février n'a que 29 jours :)
Bon on n'est quand même que le 16 février ! Et je ne suis pas pressé de rentrer de vacances.
Pour tes tests tu vas pouvoir alléger la partie gestion des CC.
Le module de gestion de protection/reverse va notifier l'état OK/KO(CC) et couper la distribution du signal DCC.L'ESP32 pourra traiter cela comme une priorité (plutôt) haute ( à définir pour enclencher le SWT qui changera l'état.) Si cet état est persistant l'ESP32 doit temporiser avant de relancer tout autre commande mais dans le même temps il devrait aussi:
A/assimiler le canton comme occupé (en dérangement) et agir sur les trains en conséquence si nécessaire.
B/fermer la signalisation
C/permettre de modifier une position d'aiguille.
Oui tout ça est vrai mais ce sont les autres auront à fermer leur signalisation et adapter le comportement des trains, ce qui est déjà le cas normalement car l'état occupé est déjà envoyé (à 100 ms près).
Christophe
-
Pas besoin de vis ici car les doubles connecteurs socle au pas de 2.54 assurent un très bon maintient.
Il n y a pas d'effort et la gravité ne joue pas une fois l'enfichage réalisé.
En mode RUN pas de wifi c est une règle d usage bien intégrée.
En fait le circuit de protection va:
1/en cas de CC: inverser une première fois les pôles DCC J/K dans la distribution et cela très rapidement
2/en cas de CC constant post inversion après une temporisation il va couper distribution DCC et
2.a/ soit il notifie immédiatement l'ESP32 et attend une commande de réarmement de sa part
2.b/ soit il effectue un cycle de réarmements auto et seulement en cas d échec de celui ci notifie l'ESP32 qui pourra alors agir pour réarmer. (sinon il faut intervenir par un push bouton local)
A voir ou est le meilleur compromis.
On utilise 2 broches de l'ESP, une pour recevoir l'état CC ou normal et une pour commander le réarmement.
Pas d indication de conso à ce niveau.
Ltr
-
Bonjour
Pour répondre à la question de Marcel sur le statut de l'évolution de SAT AUTONOMES en approche modulaire incluant quelques évolutions HARD+SOFT voici dans un tableau la synthèse à ce jour (17/02/2024)
Il y a encore de quoi faire mais cela progresse bien.
Pour illustrer voici le premier module finalisé: PROTECTION/REVERSE et sa mise en situation.
Je passe aux suivants :)
Ltr
-
Bonsoir
Voici 2 déclinaisons du bouclier assurant la détection de présence d'un train ou d'un véhicule à faible conso.
Tout deux reposent sur l'utilisation d une "bobine" (mini transfo) de 50 tours et de composants additionnels pour laisser à l'ESP32 un message binaire: OCCUPE ( valeur 0) ou LIBRE ( valeur 1)
La mesure de consommation de courant (même très faible) est isolée entre DCC et électronique de mesure assurant ainsi une réduction du parasitage et une détection de haute sensibilité.
La version à base de NE555 repose uniquement sur des valeurs de composants présent pour la temporisation sans autre forme de réglage contrairement au second montage qui apporte un réglage de seuil et une possibilité de correction dans le code du MEGATINY ( 202 ou 204 par exemple)
A noter que les deux montages proposent chacun d'allumer une LED en cas de détection active.
Ltr
-
Bonsoir
Mise en situation des 3 blocs fonctionnels modulaires en voisin d'un ESP32 dev kit C 38 broches.
L agencement laisse encore un peu de place pour sortir des connecteurs externes et placer des plots pour les servos. mais la place est contenue!
Ltr
-
Bonsoir Laurent,
C'est intéressant, merci.
Christophe
-
Le routage et les équipements se poursuivent...
Premier constat:
impossible de laisser les 75HC595 sur ce PCB en 10cm x 10cm.
Soit il faut augmenter la dimension pour les y ajouter soit avoir une carte fille externe (ma préférence car je préfèrerai disposer de l'I2C....)
J'essaye de coller à la V1 pour les fonctions clés.
Toutefois quelques ajustements sont requis dont un connecteur d'extension qui facilitera sur une carte latérale la connexion des détecteurs ponctuels notamment. ( et tous usages via I2C si on arrive à le caser)
La présence de servo est reprise ici mais comme déjà indiqué. Cependant se nombre est réduit à 2 uniquement si utilisation simultanée des 74HC595 sinon ce nombre pourra monter à 5. (sélection via DIP switch)
Encore du travail pour tout router mais cela progresse toujours bien...
Ltr
-
Cette fois on touche au but...
Tout est en place et routé!
La 3D apporte un net plus dans la conception des différents blocs et sur le placement des composants positionnés de façon optimale.
Ltr
-
As-tu chiffré ce que ça va coûter?
Parceque ça fait un peu usine à gaz pour gèrer un seul canton.
-
@Laurent,
Effectivement, ces images sont très séduisantes et j'imagine ce que ça représente de travail. Ce principe de cartes enfichables est intéressant.
Quelques regrets : Je trouve dommage que tu n'ai pas gardé les connexions CAN et courant d'alimentation en RJ45 qui selon moi apportait un vrai plus. Quand à l'I2C, vs 74HC595, je t'ai déjà dit ce que j'en pensais.
Quand j'ai utilisé la métaphore de la voiture, c'est le même principe. Il faut passer du prototype à quelque choses que les utilisateurs vont s'approprier. La simplification est un facteur déterminant à mon sens. Ce n'est sans doute pas parce que ça ne rentre pas sur ton PCB tel que tu l'as imaginé que ce n'est pas ce qu'il aurait fallu faire. Mais je ne détient pas plus la vérité que toi ni personne.
Tu peux essayer comme celà de toutes façons et c'est le retour des utilisateurs qui sera juge.
En tous les cas je te renouvelle mon admiration devant le travail réalisé.
Christophe
-
As-tu chiffré ce que ça va coûter?
Parceque ça fait un peu usine à gaz pour gèrer un seul canton.
Etienne,
Aborder la question sans nuance sous le seul angle du cout est trop réducteur.
Tout d’abord, tous les équipements ne sont pas forcément mis en place et tout dépend du besoin sur un canton donné. C’est exactement ce qu’avait visé Laurent avec ce principe de cartes modulaires. Si tu as plus de solutions, c'est plus cher. Si tu en as moins, c'est moins cher !
C’est typiquement le cas par exemple pour la mesure de courant. On peut tout à fait se contenter de la « méthode classique » avec détection de courts-circuits « centralisée ». Ou adopter le principe proposé. Il en est de même pour la détection que j’ai appelée « de courant faibles » pour désigner la présence d’autres véhicules que des locomotives. Il est possible de faire sans.
Une partie du second argument est déjà dans la réponse ci-dessus. Il faut aussi regarder cela en termes de bénéfices. C’est exactement l’exemple de la détection de courts-circuits ou de ce que peut apporter Railcom.
On peut aussi mettre en avant le bénéfice pour l’utilisateur avec une vraie simplification de la mise en œuvre. Et l’assurance que l’on n’a pas mal fait les choses au risque de griller des composants.
Enfin, je suis prêt à prendre les paris sur le prix de revient global dont je doute qu’il dépasse les 50€ et je suis certainement au deçà en disant cela. Quand je regarde des modules spécialisés du commerce, pour la détection, la rétro signalisation ou encore Railcom je ne crains pas la concurrence.
Christophe
-
As-tu chiffré ce que ça va coûter?
Parceque ça fait un peu usine à gaz pour gèrer un seul canton.
Etienne,
Aborder la question sans nuance sous le seul angle du cout est trop réducteur.
Enfin, je suis prêt à prendre les paris sur le prix de revient global dont je doute qu’il dépasse les 50€ et je suis certainement au deçà en disant cela. Quand je regarde des modules spécialisés du commerce, pour la détection, la rétro signalisation etc… je ne crains pas la concurrence.
Christophe
L'argent est le nerf de la guerre. Alors examinons les types de ferrovipathes :
Ceux qui ont peu de place ne vont pas s'emmerder avec de l'arduino pour gagner peut-être une poignée d'euros mais passer des semaines
à lire un forum pour essayer de comprendre comment ça marche.
Ils vont acheter une centrale avec 2 ou 3 modules et peut-être les connecter à un PC, ou pas...
Par contre pour ceux qui ont de la place pour un plus grand réseau il y a beaucoup à gagner financièrement avec de l'Arduino.
Et quand on planifie le réseau on compte les cantons, les aiguillages et les feux et on fait des additions et surtout des multiplications.
Et ça peut aller très vite...
Prenons l'exemple du réseau Luzy de Renaud Yver. Environ 90 cantons, 70 aiguillages et une vingtaine de feux.
Avec les modules du commerce ça doit tourner entre 1500 et 2000€ centrale comprise.
Si tu réduis tes modules à 20€ en moyenne tu seras à 1800€.
Avec des Arduino mega en utilisant les 16 entrées analogiques pour la détection de courant avec des zmct103 et les 52 I/O restantes
pour les détecteur IR de zones d'arrêt, les aiguillages commandés par des relais et les feux avec des darlingtons N2803A
on est à moins de 30€ chez les chinois pour un mega complet avec les détecteurs et les relais.
Et on peut gèrer Luzy avec seulement 6 Arduino mega, donc pour moins de 200€ et avec la centrale en uno et un hub USB
Donc si tu parviens à réduire le prix de ton module en dessous de 20€ et si il est vraiment plus simple à mettre en oeuvre
que les solutions du commerce à un prix comparable alors c'est OK.
Mais économiquement par rapport à une solution avec des mega 2560 répartis géographiquement sur le réseau tu es
loin du compte.
-
Quand on veut tuer son chien on dit qu’il a la rage.
C’est consternant comment tu avances tes arguments comme des vérités universelles. Tout en ne te privant pas des scuds qui vont bien du style « passer des semaines à lire un forum pour essayer de comprendre comment ça marche ».
Quant à l'argumentation technique des 6 Arduino Mega pour les 90 cantons, chacun pourra apprécier.
Mais bon !
-
Je donne juste mon avis.
Tu as une idée de départ qui est bonne : c'est le truc de la découverte.
Le problème c'est qu'en faisant une carte par canton tu multiplies des éléments qui pourraient être regroupés sur une seule carte.
Vous avez dérivé sur le principe des boucliers mais en les appliquant encore à une carte par canton et c'est là qu'il faut changer.
Ta carte mère doit être commune à plusieurs cantons (4, 6 ou 8 à voir en fonction des brochages), tu y mets la détection de présence
et le railcom en fixe puisqu'on en a besoin de toute façon, et tu mets en option un bouclier court-circuits (on n'en a pas besoin pour
beaucoup de cantons, 2 suffisent pour un circuit en os de chien) un I2C et un wifi.
Tu auras un seul processeur, un seul régulateur de tension, un seul CAN, etc...
Ton principe de fonctionnement reste le même mais tu économises un max.
Et si tu arrives à faire ça pour moins de 100€ pour 8 cantons tu auras un produit compétitif.
-
C’est un point de vue mais ce n’est pas celui que j’ai cherché à développer. J’ai bien précisé à quels modélistes je m’adresse et pour quel type de réseau, petits et moyens, dioramas et va-et-vient.
Il s’agit d’une solution clef en main ou presque hormis quelques soudures et des câbles Ethernet pour relier les satellites.
Et surtout pas de programmation ni de passage obligé dans le code pour que ça fonctionne. Ce que tu as oublié également dans tes propos précédents, c’est que la gestion de réseau est ici assurée. Ce que je ne vois pas dans tes 6 Mega et 90 cantons. Et qu'au détour, il n’y a pas non plus besoin d’ordinateur pour que cela fonctionne correctement.
Alors, certes, cela a peut-être un prix, celui de la simplicité et celui de pouvoir jouer au train sans se prendre le chou avec la technique.
C’est le cas par exemple LocoFred que je cite strico sensu :
C'est, je le pense, exactement la solution que je cherchais pour piloter mes locomotives "à la main" à l'aide d'un TCO "analogique" (pas certain que ce soit le bon terme) commandé par interrupteurs ou boutons poussoirs et surtout, sans nécessiter la présence d'un ordinateur même si ça reste possible...
Seulement voilà... Je ne suis vraiment pas expérimenté et c'est là que le bat blesse... Bien que bricoleur averti et amateur de projets Arduino, sachant souder, je ne suis ni informaticien ni électronicien et forcément, ça se complique...
Si ce n’est pas ta vision du modélisme ferroviaire, accepte au moins que d’autres en aient une différente.
Et rien ne t’empêche de montrer tes réalisations, de partager ta propre vision des choses qui, à n’en pas douter sera constructif et enrichissant.
Locoduino a toujours été un espace où la tolérance n’a eu de limite que la connerie. Souhaitons que ça continu.
-
Bonjour
L'aspect cout a bien sure une importance somme toute cohérente. Ceci fera l'objet du travail (ingrat) à suivre.
Avant la considérer ce seul aspect je verrai d abord comme premier argument le gout de réaliser quelque chose qui corresponde à ses attentes sans forcement réinventer l'eau chaude!
Se faire plaisir aussi!
Réduire à quelque MEGA ce qui serait suffisant pour traiter un réseau comme LUZY est TROP réducteur car il y a forcement des compléments. ( interfaces, ...)
Par ailleurs il faut bien une topologie et on est là sur du spécifique de chez spécifique... donc pas très en accord avec l'aspects satellite qui se veut plus universel dans sa mise en œuvre.
Mais si tu te sens inspiré pour nous proposer une alternative, nous seront heureux de lire tes propositions.
Regrouper des fonctionnalités imposerait un comparo pour N équipements pouvant gérer un nombre de cantons/zones similaires, de commande d aiguillages, de signaux... voir leur mise en œuvre) et ce qu'elle requiert autours... ( logiciel)
Bref tout raccourcis est trop hâtif.
Pour assurer une retro compatibilité avec les V1, au moins d'un point de vue hardware, j ai imagine une extension pour intégrer comme sur ceux ci les prises RJ45 transportant le signal CAN et l'alimentation accessoire comme c'est illustré ici. (neutralisant de fait les accès aux connecteurs à vissage du socle)
Une mise en œuvre au "NORD" dans la longueur serait possible également mais viendrait pour d'autres usages bloquer les extensions cote "OUEST" préférant alors le coté "EST" dédié aux entrées.
Ltr
-
Je voudrais aussi revenir sur la TOPOLOGIE "vision satellite".
C est une architecture distribuée ( elle n est pas concentrée en un endroit du réseau mais repartie au long du tracé)) et regroupée ( au moins à ce stade) qui inclue sur un socle les fonctions de:
a/identification des trains
b/gestion des aiguillages (par servo)
c/détection d'occupation et de mouvements
d/affichage de la signalisation
e/interaction avec ses "voisins" selon les tracés
f/commandes des engins (arret, ralentissement, démarrage...)
Les bloc fonctionnels sous forme de bouclier sont bien sure utilisables dans d'autres contextes ( ils ne seront pas moins chères pour autant!) mais cela ne se fera qu'au compromis d'approches différenciées au niveau topologie.
Par exemple sur une ligne CAN avoir des décodeurs locaux par usage ( ex signaux, servo, ...) Mais c'est la une autre paire de manches à traiter surtout pour facilement mettre cela en "musique" sans passer des heures à coder... Ou alors il faut une IHM sur un système central qui assure les arbitrages... autre vaste sujet!
Ltr
-
Une extension au "NORD" des RJ45 est possible sous cette forme...
A vous de me dire ou va votre préférence...
Ltr
-
Bon tu vas vraiment me prendre pour un ch*eur mais l'avantage du RJ45 (dans la version initiale) c'est que l'on fait passer également le courant. Dans la dernière version, j'utilise 6 fils sur 8 pour cela (les 2 autres pour le CAN).
Mais bon, je donne juste mon avis !
Christophe
-
Non ne t inquiète pas!
Si je demande c'est bien que je ne suis pas fermé à toutes adaptations! La preuve! ( mais je l ai glisse hors du CPB 10x10 pour des raisons de place/volume sinon il faut passer à un peu plus grand...)
Tu penses qu'il faut passer à plus grand et les mettre en natif sur le socle principal?
J ai bien utilisé le même mapping que toi sur les utilisations de broches RJ45.
J'en profite pour glisser l'EXTENDER "SUD" gérant les 74HC595 pour le signaux. (EXTENDER SHIFT REGISTER 74HC595)
Ici réalisé en composants traversants, pour le plaisir de monter quelques cartes et d'utiliser mes stocks!
En complément du bouclier principal voici ce qui complète à merveille ce dernier avec l'EXTENDER RJ45 pour s'assimiler pratiquement à un "V1" dont le mapping des I/O est juste modifié pour le routage.
Ltr
-
Ah je trouve ça super pour l'extender des 74HC. Et celui qui ne veut pas mettre de signalisation ou pas tout de suite n'est pas pénalisé.
Du coup avec la place gagnée, peux tu mettre les RJ45 sur la carte principale. Mieux selon moi pour des raisons de fiabilité de connexions.
-
C est un peu trop juste pour les ajouter nativement sauf à forcer en 130x100mm minimum.
Avec les connecteurs mis en place les contacts sont "sérieux", il n y a pas trop d'inquiétude à avoir et on passe jusqu'à 3A par broche si besoin...
C est du contact au pas de 2,54mm très standard (type connecteur IDE).
Chaque platine bien fixée aucun soucis à prévoir. ( la languette du câble RJ45 aura rendu l'âme avant!)
Pour les expenders c est selon les besoins "à la carte". On a besoin on utilise, on a pas besoin on fait bien sans :)
Idem pour les boucliers ( encore que...!) on bouchonne avec un PCB "dummy" afin de ponter les I/O entrées/sorties ( faut que je les dessine ceux la!)
Pour le moment je vais me glisser à l"OUEST" avec les expenders optionnels.
Ltr
-
Bonjour
Ma méconnaissance de certaines subtilités de l'ESP32 m'avait amener à faire des choix de mappings pour la distribution des usages.
En effet lors de la phase de boot du CPU il est impératif que certaines broches soient dans des états très précis (hauts ou bas)
C est le cas des PIN suivantes qui doivent alors être lors du BOOT dans une configuration précise:
source : https://lastminuteengineers.com/esp32-wroom-32-pinout-reference/ (https://lastminuteengineers.com/esp32-wroom-32-pinout-reference/)
PIN13 IO:12 BAS
PIN35 IO:15 HAUT
PIN34 IO2: BAS
PIN33 IO0: HAUT
PIN29 IO5: HAUT
Bien sure, je n'ai pas vu cette subtilité initiale et je vais devoir revoir certains mappings pour me conformer avec cette impératif.
2 états hauts peuvent être trouvés facilement avec le bus I2C et les résistances de tirage.
un état bas aussi en lui attribuant la broche TX du RAILCOM qui n'est pas utilisée.
Il reste alors 2 broches, une de chaque état à trouver.
Pour les broches en état haut une astuce peut être utilisée via la détection/signal railcom qui est par défaut en état HAUT si il n y a pas de détection ou si le circuit gérant la protection n'est pas encore basculé pour rendre actif la distribution du DCC vers ses consommateurs! Subtile oui mais si on bouchonne ces modules on perd cette opportunité...
Je vais donc me pencher sur ce qui est optimisable à ce niveau... et revoir en conséquence les mappings et le routage qui en découle.
C est la phase troubleshooting!
Ltr
-
Attention avec le mapping. On parle ici du WROOM. Tu ne donnes pas le bon lien qui est celui-ci :
https://lastminuteengineers.com/esp32-wroom-32-pinout-reference/ (https://lastminuteengineers.com/esp32-wroom-32-pinout-reference/)
J'ai attribué GPIO17 à Railcom TX (qui ne sert pas) car elle n'est pas utilisable autrement. Pas plus que GPIO16 sans que l'on sache vraiment pourquoi mais je l'ai moi-même constaté !!!
Voir ici : https://esp32.com/viewtopic.php?t=3390 (https://esp32.com/viewtopic.php?t=3390)
Et quand tu regardes ici : https://www.upesy.com/blogs/tutorials/esp32-pinout-reference-gpio-pins-ultimate-guide (https://www.upesy.com/blogs/tutorials/esp32-pinout-reference-gpio-pins-ultimate-guide)
il est bien spécifié :
16 YES YES Not available on WROVER
17 YES YES Not available on WROVER
-
@ Mr Etienne66
Polémiques.
Bonjour Monsieur,
Je viens de lire votre intervention sur le travail de Christophe, vos remarques sont très pertinentes et surtout en dehors du sujet.
Si le coût est élevé (pour vous) personne oblige personne de faire ce ou ces montages.
Comme tous les forums, ici les contributeurs donnent et surtout partagent leur modeste savoir.
-
Bonjour
J ai identifié l'origine des numéros de broches (pas des IO ESP32) liée à une empreinte KIKAD n'ayant pas la même distribution.
Je vais agencer celle ci pour respecter la convention utilisée dans les liens indiqués.
Par ailleurs, j'ai donc un peu repris les MAPPINGS et le routage correspondant afin de respecter les contraintes des broches lors du BOOT de l'ESP32.
Avec cette disposition les contraintes sont normalement couvertes dans les différents cas de figure. ( notamment sur la PIN IO15 qui peut sortir des états fluctuant lors du boot, ici sans incidence sur le SCL (CLK) de l'I2C)
Le switch de changement d'état du module de protection n'est volontairement pas lié à EN ni a CMD_SW_STATE ce qui aurait pour conséquence dans le premier cas de rebooter l'ESP32 ( pourquoi pas dans l'absolu!) ni de passer en mode PROG dans le second cas.
Les servos 1 et 2 sont "sacrifiés" en cas de module WROVER mais devraient normalement fonctionner avec un module WROOM 32.
On alors à disposition en standard sur modèle WROOM 3 servos :Servo 0, Servo1 et Servo2 et la signalisation sur les 74HC595.
On monte jusqu'à 6 servos sans 74HC595( sans signalisation sur ce canal) avec un WROOM: 0 1 2 3 4 5.
Avec un WROVER on alors 1 servo : servo0 et les sorties signalisation sur 74HC595 ou 4 servos sans le 74HC595 ( sans signalisation via ce canal).
Tout ceci ouvre aussi la voie à une intégration simplifiée de modules ESP32 en natif (sans le support) mais avec ajout d'un connecteur de programmation, d'une régulation 3V3 et de minima 1 bouton(RST), rien de trop ardu d'autant que la place sera la pour ces éléments.
En cas de besoin de ressources HARD supplémentaires ou d'indispo un swap de module CPU devient alors plus facilement possible.
A noter qu'avec la compilation du code natif de Christophe les ressources sont en sortie de compilateur pour run ESP32 WROOM 4Mo ( CPU de type S3) :
RAM : 6.8%
FLASH: 17,1%
Pour un CPU de type WROVER
RAM:6.8%
FLASH: 18.1%
Un portage sur une version mono CPU serait intéressante ( core version C3) mais comme le code alloue des taches au second core... il faut vérifier les impacts si retour sur le premier...
Christophe saura mieux que personne nous dire si cela tient du domaine du possible ou non.
Ltr
-
Question subsidiaire:
Que se passe t il si on met les GPIO16 et 17 en usage ( ex RAILCOM TX ) avec un WROVER dépourvu de connexion "IO17" ( et"16) ?
En principe de ce que j ai lu c est la connexion physique qui n'est pas reliée aux sorties du module mais en interne... quelle est la "cuisine" si on fait ce mapping?
BIG question!
@Christophe: tu penses que de mettre les servos 1 et 2 sur les pins 16 et 17 du WROOM passe finalement? Tu semblais laisser entendre que non...
Ltr
-
Le double cœur est primordial mais la mémoire flash ne constitue normalement pas un problème. 4Mb, c'est peu et beaucoup.
De plus il existe des moyens pour répartir la mémoire flash différemment, en prenant par exemple sur la mémoire allouée par défaut à l'OTA qui est je crois de l'ordre d'1Mb. Pas d'OTA donc, mais de toutes façons, en exploitation, le satellite autonome n'a pas de WiFi !!!
Dans ton calcul de la mémoire flash, il faudrait aussi prendre en compte les fonctions qui sont programmées pour "tourner" en mémoire flash et il y en a quelques unes dont la plus importante "void IRAM_ATTR GestionReseau::loopTask(void *pvParameters)" signalé par "IRAM_ATTR"
Evaluer cela sur ESP32 n'est pas très simple et, pour moi en tous cas, plutôt empirique et résultat de tests avec des "charges" de plus en plus importantes pour trouver les limites.
Christophe
-
Question subsidiaire:
@Christophe: tu penses que de mettre les servos 1 et 2 sur les pins 16 et 17 du WROOM passe finalement? Tu semblais laisser entendre que non...
En fait, il ne se passe rien ! Si tu fais par exemple un digitalWrite sur l'une ou l'autre de ces deux pins, et bien rien ne changera !!!
Par contre, tu peux les utiliser pour certaines instances comme justement Serial.begin() qui peut n'avoir que le paramètre de débit comme c'est souvent le cas ou quatre paramètres comme mySerial->begin(250000, SERIAL_8N1, m_rxPin, m_txPin); pour Serial1 et Serial2 mais pas trois paramètres.
Christophe
-
Re
Hormis le futur ESP32 P4 qui doit arriver cette année et qui sera un monstre coté CPU en sacrifiant au passage le WIFI!... on reste bien dans le besoin absolu de 2 cœurs ( jusqu'à démo du contraire)
Donc tout module de type "S3" peut convenir.( ou module ESP32 " historique" à base de double cœur)
J'ajoute que pour les SAT V2 à ce stade il faut un modèle avec 38 broches! ( le même que sur la V1) (ce qui cible les achats d ESP32 avec ces caractéristiques)
Ltr
-
Question subsidiaire:
@Christophe: tu penses que de mettre les servos 1 et 2 sur les pins 16 et 17 du WROOM passe finalement? Tu semblais laisser entendre que non...
En fait, il ne se passe rien ! Si tu fais par exemple un digitalWrite sur l'une ou l'autre de ces deux pins, et bien rien ne changera !!!
Par contre, tu peux les utiliser pour certaines instances comme justement Serial.begin() qui peut n'avoir que le paramètre de débit comme c'est souvent le cas ou quatre paramètres comme mySerial->begin(250000, SERIAL_8N1, m_rxPin, m_txPin); pour Serial1 et Serial2 mais pas trois paramètres.
Christophe
J aurai alors tout intérêt à laisser IO17 avec serial TX pour le RC... et substituer les servos avec. Ca fait gagner 1 servo.
En revanche il faut être sur que cela ne vas pas influer sur les accès du CORE vers le module PSRAM... ( d après ce que tu dits ca semble bon)
-
Hormis le futur ESP32 P4 qui doit arriver cette année et qui sera un monstre coté CPU en sacrifiant au passage le WIFI!... on reste bien dans le besoin absolu de 2 cœurs ( jusqu'à démo du contraire)
Donc tout module de type "S3" peut convenir.( ou module ESP32 " historique" à base de double cœur)
Attention, tu vas trop vite parfois. Il faut prendre un peu de temps de réflexion ou de recherches. Ou regrouper tes questions.
Tous les S3 ne sont pas double cœurs !!! Du moins je crois mais j'avoue être un peu dépassé par le rythme !!!
Bon, si, il semble bien que tous les S3 soient double cœur : https://www.espressif.com/en/products/socs (https://www.espressif.com/en/products/socs)
-
Oui il faut éplucher... c est assez laborieux pour s'y retrouver.
La page ci après aide bien pour dégrossir cela même si le niveau de détail n'y est pas:
https://fr.wikipedia.org/wiki/ESP32 (https://fr.wikipedia.org/wiki/ESP32)
Toutefois on peut retenir ceci:
S3 = double cœur ==> CONVIENT pour nos usages
S2 et C3 = simple cœur ==> ne convient pas pour nos usages ici
J'ai interverti TX et Servo1 ce qui ajoute celui ci de dispo dans les configurations citées plus haut.
Ltr
-
Voici le mapping revu pour s'accorder aux contraintes ESP32.
Le servo 2 est "sacrifié en cas de CPU de type WROVER.
Les servos 3 4 et 5 sont soit activés au détriment du 74HC595 gérant la signalisation soit inactif au profit de celle ci.
Routage mis à jour.
Ltr
-
1) Arduino classique à base d'AVR : 5v , convient pour 90% des besoins , manque de capacité pour certaines applis
2) ESP32 , 3v3 , la superstar , puissance , wifi CAN , prix , disponibilité , existe aussi en toute petite carte (avec USB)
perso , je n'aime pas ... : il y a un OS , cad. qu'il s'efforcera sans doute de faire ce qu'on lui demande , mais au final il fera ce qu'il veut : si on lui demande de faire des trucs précis , DCC , railcom , c'est la cata ; de + , mauvais ADC , latence d'ISR anormalement longue et variable , "poor wifi integration design"
(les gens de DCC EX l'ont laissé tomber , ils s'orientent vers du STM32 avec un ESP32 C3 en simple interface wifi)
3) STM32 , amha le top en 3v3 , CAN , mais pas de wifi
Bonjour Marc,
Merci pour cet inventaire intéressant car exhaustif.
à ton service
Je suis d’accord avec toi sur de nombreux points. Tout d’abord, concernant les Arduino, surtout les Nano. On a tendance à les oublier mais pour pas mal de choses, ils font le job. On les accuse de prendre beaucoup de place, pas trop les Nano mais les Mega par exemple. Sauf qu’un Mega c’est 3 ports série, et plus de 40 broches « vraiment » utilisables. Pas de concurrent à ma connaissance de ce point de vue. Et a-t-on toujours besoin de faire petit ?
Pour l’ESP32, je te trouve trop critique et là encore, tout dépend du besoin. Il est indéniable qu’à ce prix, avec les possibilités offertes, c’est absolument canon.
Sans avoir vraiment optimisé le programme, je fais du DCC avec et aussi du Railcom !!! Alors oui, j’ai 25% des trames qui sont hors des spécifications du NMRA mais tout fonctionne depuis longtemps et de façon très satisfaisante.
Et alors, concernant Railcom, je ne te suis plus du tout. Là aussi nous avons un certain recul (1 an ½) et aucun retour négatif. Michel a même testé avec succès trois lectures Railcom simultanées avec le même ESP.
il y a bien entendu une part de subjectivité de ma part (c'est pour ça que j'ai précisé "perso") ; perdre un peu de bande passante à cause de quelques messages déformés , je suis bien d'accord que c'est acceptable , mais je trouve ça dommage , dès qu'on peut faire quelque chose de nickel avec la plupart des autres microcontrôleurs
et en effet , je suis inquiet pour le railcom , je vois mal le cas d'une centrale qui pourrait se remettre à émettre intempestivement des bits DCC , alors que les décodeurs s'attendent à un cutout et commencent à envoyer leur canal 1 railcom ; sans doute les décodeurs sont protégés contre ça , mais perso je tiens à éviter à tout prix
Il y a un peu de doigté sans doute à mettre quand on développe avec l’ESP32. Chercher à utiliser les deux cœurs mais en sachant que toutes les applications asynchrones l’on fait avant nous (Serial, WiFi, CAN, Web…). Je n’ai pas de recul là-dessus mais je désactive maintenant le Wifi quand je n’en ai pas besoin et aussi le port Serie. Est-ce vraiment efficace ? Dans quelle mesure ?
Quant à DCC-Ex, tu confirmes ce qui se présentait qui est qu’ils ne développeront pas Railcom sur ESP32 ce qui n’est pas forcément une bonne nouvelle pour la Box. Ni pour moi, car même si je dispose d’une solution alternative, j’aurais préféré utiliser la Box avec les satellites autonomes.
je ne suis pas dans le secret de DCC EX , donc je ne peux rien confirmer je peux juste constater que ce n'est toujours pas fait , et supputer que vu leur niveau , ce serait déjà fait si c'était possible . Par ailleurs mes connaissances de la bête (RMT , interruptions) font que que ce n'est pas possible en l'état actuel ; on peut espérer une suite favorable , car l'ESP32 sait intrinsèquement le faire , mais je suis pessimiste
Que l’on se comprenne bien, je ne dis pas, loin s’en faut, que l’ESP32 est exempt de défauts, mais qu’on ne peut pas l’exclure car il répond à de très nombreux besoins.
Et une fois encore, c’est le besoin puis le prix qui doivent nous guider. N’est-il pas par exemple plus judicieux de mettre deux ESP sur une carte en répartissant les tâches qu’un seul microcontrôleur qui vaut deux fois le prix.
chacun fait comme il veut , maintenir 2 logiciels différent me gênerait , je me braque sur certaines choses qu'un ESP32 ne peut pas faire , et 2 ne pourront pas non plus ...
j'ai dit ce que je pensais devoir dire , mais je pense que le choix du microcontrôleur n'est pas si crique à ce stade ; vous preniez la décision de migrer , tu aurais vite fait d'adapter ton sauf au nouvel élu , et entre temps Laurent , (qui me pardonnera mes intrusions ? ) aura déjà dessiné la nouvelle carte
il faut que je vous laisse travailler maintenant (pareil pour moi , j'ai tant de choses en retard) !
Christophe
-
Tu es toujours le bienvenu Marc.
Je sais que de ton coté tu as commencé a regarder les STM32, tu nous en parleras surement tôt ou tard ;)
Je dessine vite mais... pas encore aussi vite que cela! Mais je m'améliore toujours :) et les encouragements y contribuent.
Je vais illustrer un cas très basique d'extension "OUEST".
Grace au connecteur 14 broches et aux IO qu'il contient on peut déporter ici les commandes des servos 0 1 2. ( pas le 2 si on a un WROVER évidemment!)
on peut y glisser la commande de 2 relais pour des polarisations ou le pilotage d'accessoires accouplables avec les servos (ou bien piloter 2 autres servos indépendants qui ne sont pas les 3 4 5)
enfin on a les départs vers les capteurs ponctuels : horaire et antihoraire.
A défaut d'I2C c'est déjà une "bonne extension".(certes perfectible)
Beaucoup d'autres combinaisons sont possible aussi comme des boutons en entrées...
Les seules limites viendront du soft ou plutôt de la facilité à les y entrer soit avec un code spécifique au satellite qui reçoit ce type d extension soit avec un code générique commun à tous les satellites et dont on activera tel ou tel usage via la vue WEB... si on sait faire comme cela?
A vos avis
Ltr
-
Laurent,
Je poursuit sur ton fil pour ne pas polluer celui de la Box. Donc je pense que tu comprends bien que le problème est côté génération du cutout, espace de quelques centaines de µs inséré dans la trame DCC.
Extrait de l'article sur Railcom : Railcom© nécessite que les trames DCC envoyées sur le réseau contiennent un « cutout », c’est-à-dire une suspension de l’alimentation d’environ 460 µs pendant laquelle le décodeur transmet un court message (généralement deux ou quatre octets) incluant son adresse. Ce cutout est réalisable assez simplement avec une centrale DCC en DIY.
Par ailleurs, il faut une carte moteur qui dispose d'une entrée break, il n'y en a pas tant que cela mais le LMD18200 en fait partie. Carte dont il faut dire au passage que les gens de DCC-Ex la trouve ringarde et obsolète. Mais je crois qu'ils n'aiment pas grand choses en dehors de ce qui sort de chez eux.
Pour les satellites, pas de problème, on changera de centrale au besoin, probablement Mega + (pour moi) shield Ethernet + LMD18200.
Pour l'instant, ma centrale fait le job, mais je ne souhaite pas faire le support, donc pour de multiples raisons, il était préférable que Railcom fonctionne avec la Box.
Ai-je bien répondu à ta préoccupation ?
Christophe
-
Oui claire et limpide. Merci Christophe. J ai bien compris les aléas du sujet ( dont le cœur du pb repose sur les interruptions software et non hardware comme sur nos bons vieux AVR!)
Je vois surtout que cote DCC EX on sait programmer avec talent mais moins se lancer dans un PCB comme LABOX à laquelle on préfère des boucliers "tout fait" dont au pire on coupe une pate ou piste ou a qui on ajoute un pont/ jumper.
Expression du "génie Français?" Cocorico! :)
Surement dommage de ne pas être allé au bout de la démarche dans ce genre d'exercice complet d autant qu'il existe des cartes support pour module ESP32 toutes désignées pour effectuer ces quelques tests.
Thierry qui suit le sujet aura peut être un avis très autorisé sur la question.
Ltr
-
Bonjour
Pour compléter les satellites il nous fallait un montage pour les capteurs ponctuels.
Basé sur le montage proposé par Geoff BUNZA voici la version qui ira sous la voie disposant nativement de 2 capteurs par circuit.
https://forum.mrhmag.com/post/sma23-%E2%80%93-a-new-dcc-dc-car-loco-detector-%E2%80%93-differential-absolute-position-detector-dapd-12203476 (https://forum.mrhmag.com/post/sma23-%E2%80%93-a-new-dcc-dc-car-loco-detector-%E2%80%93-differential-absolute-position-detector-dapd-12203476)
Il sera plus simple d'en équiper les extrémités de canton plutôt que de tirer du fil d'un bout à l autre pour les sonde PT19 ou PT204.
Notez que le montage dispose d'un pont de diode ainsi que d'un régulateur de tension en 3V3 ( pour aller vers nos ESP32). Il sera alimenter par le +5V de nos satellites en entrée ce qui du fait des distance de fil compensera largement les pertes en ligne.
Ltr
-
@Christophe
Doit on impérativement disposer de la LED dans le Discovery?
Y a t il comme sur AVR une manip coté ESP qui pourrait faire basculer une PIN d une config INPUT à OUTPUT ( genre TOOGLE) ce qui permettrait une réutilisation de broche simplifiée.
Je devrais alors ajouter cela au montage des V2.
Ltr
-
Bonjour Laurent,
Comme je te l’ai déjà dit plusieurs fois j’ai vraiment du mal à te suivre. Tu nous présente des cartes mais dont on ne sait pas exactement ce qu’elles font et comment elles fonctionnent. Je ne sais pas faire de schémas électroniques mais je sais les comprendre.
Tu nous dit : Il sera plus simple d'en équiper les extrémités de canton plutôt que de tirer du fil d'un bout à l autre pour les sonde PT19 ou PT204.
Je ne sais pas ce qu’est un PT19 ni même un PT24.
Alors si tu ne tires pas de fils, comment exploite t’on le signal ?
Et puis tu nous dit que tout de même il faut tirer des fils, alimentation, certes mais tout de même.
Comme suggérer par Dominique, je crois qu’il faut isoler ce qui est de la recherche pure du fil du forum. Et il faut poser un peu plus les choses. Comme cette carte par exemple, je ne doute pas qu’elle soit intéressante mais elle arrive comme cela, sans prévenir. Je ne savais pas qu’il y avait un problème avec les capteurs ?
Quant à la question sur les leds ? Que puis-je te répondre si ce n’est que OUI cette led est importante. Je pense que cela se comprend à la lecture de l’article sur le processus de découverte.
Christophe
-
Bonjour
Les capteurs ponctuels que tu utilises on besoin d un circuit pour envoyer l info de présence ou pas en un point donné.
C'est ce que traite ce petit montage selon les info données à son sujet.
Ce montage n'est pas propre aux satellites, il est universel (et pourrait faire l'objet d'un post dédié). Elle pourrait très bien convenir pour gérer les capteurs d'un PN...
Les PT19 / PT204 sont des phototransistors:
PT204:
https://www.tme.eu/fr/details/pt204-6c/phototransistors/everlight/ (https://www.tme.eu/fr/details/pt204-6c/phototransistors/everlight/)
D'autres références peuvent aussi convenir (à tester naturellement) (comme celui ci https://www.vishay.com/docs/81532/bpw96.pdf (https://www.vishay.com/docs/81532/bpw96.pdf))
Cette platine a pour but de simplifier leur mise en œuvre au niveau de la voie (elle se positionne localement dessous)
Il faut juste la relier au satellite pour son alimentation en entrée et récupérer une ou deux sorties.
Il me parait plus simple dans le cas ou un canton de plusieurs mètres est présent d'en placer une à chaque extrémité plutôt que de tirer du fil pour aller d'un bout à l'autre uniquement pour le phototransistor.(et plus fiable)
On peut considérer cela comme un écosystème en fait.
Pour la led il faut que je trouve une astuce d'utilisation ( j'ai quelques idées ! :)
Ltr
-
Bonsoir
Je me suis livré a quelques calculs pour la fabrication des PCB.
Je vous livre ci après des données pour la réalisation du (bouclier du) module RAILCOM ( le plus complexe car bi face)
PCB hors connecteur il faut compter...
pour un volume de 80 pièces (sur 5 panneaux de 4x4 items = 80 décodeurs assemblés) incluant taxes et TVA + fabrication + transport + composants nous amène au prix indécent de .....3€!
Alors certes il faut un peu de trésorerie ou se grouper pour partager les couts mais c' est jouable je pense in fine d'avoir un satellite complet à prix contenu pour peu que l'on veuille s accorder à réaliser quelques soudures
Je vais faire le même travail pour les autres boucliers bien que cela prenne un peu de temps à traiter.
Ltr
-
Le calcul du module assurant la détection de présence à base de NE555 et de COIL comme proposé arrive lui aussi à un cout de 3€10 hors connecteurs pour un volume de 80 pièces fabriquées, tout compris ( taxes, TVA , transport, composants et fabrication).
On reste donc compétitif puisque les 2 modules de fonction principaux ne dépassent pas 7€ avec la connectique.
Un ESP32 à disons 5€ nous amène vers 12€ hors bouclier socle et bouclier de protection. ou du bouchon de ce dernier.
Il me reste le bouclier de protection/reverse à chiffrer...
Ltr
-
Bonjour
Je viens de finaliser le chiffrage du bouclier du MODULE PROTECTION/REVERSE, toujours sur la base d'un volume de 80 pièces.
Une référence n'est pas dispo en standard chez le fabricant. Il s'agit de la pièce TLP3553A. Je n'ai pas trouvé d'équivalence à meilleur prix. Une autre option est de redessiner le module avec d'autres composants mais la place sera alors un vrai challenge à relever.
Cette pièce est disponible en volume@2€15HT . Il en faut 4 par module ce qui fait grimper le prix de celui ci à un prix complet proche de 18€. Il faudra alors souder ces composants ( plutôt gros ce qui ne sera pas très difficile à faire avec un minimum de soin.)
Rappelons que ses fonctions sont en cas de nécessité (Court circuit) d inverser au besoin la distribution des pôles DCC et de se mettre en protection en cas de CC continu.
Ce module peut être optionnel et seul un bouchon sera à placer pour le remplacer ( cout très faible disons 1€)
Chacun pourra apprécier l'apport du dispositif au cas par cas.
>Grosso modo le prix des 3 boucliers (PROTECTION/REVERSE, DETECTION, RAILCOM) se positionne vers 25€.
Il faudra y ajouter l'ESP32 et le socle de base dont il me reste le chiffrage à effectuer aussi.
Selon toute vraisemblance on devrait être bien en deca de 50€. et proche de 30€ sans le module de protection.
Ainsi cette combinaison s'approche de la version initiale que Christophe vous a présentée apportant modularité et complémentarité.
Ltr
-
Bonjour
Le montage que l'on retrouve sur du premier bouclier vient d être reçu et va entamer sa phase de tests en fin de semaine...
(voir le sujet https://forum.locoduino.org/index.php?topic=1661.0 (https://forum.locoduino.org/index.php?topic=1661.0))
Ltr
-
Bonjour
Premiers tests et premiers ajustements déjà reportés sur ce bouclier pour faciliter la programmation du montage.
Ltr
-
Une idée d'évolution : le mode découverte par roulage d'une loco.
Des boutons sur le circuit main pour passer en mode découverte et diverses options
- On place une loco sur le réseau et rien d'autre.
- Sélection du mode découverte -> message can du main vers tous les satellites
-- Le satellite qui détecte la loco envoie un message -> les satellites enregistrent l'info
- mise en route de la loco -> le main détecte la commande DCC et envoie un message can
-- marche avant = horaire, marche arrière = anti-horaire
-- les satellites enregistrent l'info
- la loco entre dans canton suivant :
-- le satellite détecte la loco -> envoi message can entrée
-- les 2 satellites concernés enregistrent la liaison entre eux et le sens de circulation ainsi que la position des aiguilles qu'ils contrôlent.
- la loco quitte le 1er canton
-- les satellites enregistrent la nouvelle position de la loco dans le second canton et on est pret pour une seconde liaison
- si la loco fait demi-tour et revient dans le premier canton on enregistre cette liaison avec l'autre sens de circulation.
- dans le cas d'une boucle de retournement :
-- entrée dans le canton : changer le sens de la loco (la marche avant devient anti-horaire)
-- sortie du canton : on ne change rien
-- demi-tour de la loco dans le canton : on change le sens de la loco (la marche avant redevient horaire)
On peut avoir sur le main :
- le bouton pour entrer dans le mode découverte
- un bouton pour en sortir (ou utiliser le même bouton)
- un cavalier pour un reset des satellites (pas un bouton pour éviter le reset involontaire)
- un bouton pour passer en mode suppression ( circuler entre 2 cantons va supprimer le sens de circulation de cette liaison)
- un bouton pour le mode manoeuvre (on pourrait ainsi définir indépendamment les autorisations de circulation en mode manoeuvre)
Avantages du système :
- Bien plus facile pour l'utilisateur qui n'a plus à ramper sous la table pour pousser des boutons.
- Suppression du risque de fausses manips.
- Plus besoin de boutons sur les satellites -> libération de pins et économie de place sur le pcb.
-
Bonsoir
Les travaux sur la détection d'occupation en basses conso ayant permis de dégager un consensus sur un montage j'ai de ce fait ajuster mes boucliers existants pour y porter les évolutions du hardware.
Comme pour les boucliers d'origine ont une très grande souplesse d'utilisation peu d adaptations ( mais un gros travail malgré tout) a pu être faites pour aller dans ce sens.
Le premier bouclier en entrée venant de la centrale ou du booster va porter une double fonctionnalité sur son carré de 50mm x50mm (cotes inchangées, seules 2 connectiques évoluent pour intégrer les changements.)
A/ fonction 1: protection (8A et plus)
B/ fonction 2: détection d'occupation même en faible conso. (via utilisation de COIL 50 tours).
On y trouve en version CMS les montages évoqués pour ces usages.
Toutefois plusieurs éléments en diffèrent:
1/ une alimentation DC-DC 5V est intégrée nativement pour éviter de trop chauffer sur le montage qui "tire" quelques mA malgré tout. (depuis la source DCC)
Une option d'implantation (astucieuse!) permet de se passer de cette source DCC en prenant l'alimentation depuis un autre convertisseur DC DC 5V depuis le socle recevant les différents boucliers.
Le choix est alors dans laissé selon les connecteurs mis en service ou non.( +1 composant à dessouder, rien de compliqué)
Il n'y a pas de relais sur cette carte. 8)
La fonction de coupure de protection est confiée à un montage de type SSR à base de NMOSFET en montage "BACK TO BACK" et d'un driver de MOS.
Plus rapide que le relais dans la commutation, moins consommateur que le montage avec relais et finalement pas plus onéreux toujours à puissance de coupure identique ou supérieure! ( ici on parle de 8A)
Encombrement réduit et isolation galvanique en prime, on a de nombreux avantages à passer par cette méthode d'implémentation.
Il n'a plus de fonction d'inversion de la distribution des polarités comme précédemment. Cette faculté va être reportée sur un second bouclier optionnel de dimension 40mm x 40mm qui vient en série dans le montage global avant d'attaquer la partie d'identification RAILCOM (j ai encore à le dessiner!)
Si cette fonction n'est pas requise, un bouclier "bouchon" fera le job en "pontera" son entrée sur sa sortie.
Il reprendra un montage de type SSR à base de 4 TLP3553 ( opto NMOSFET back to back encaissant jusqu'à 4A en nominal) toujours pilotés par un MEGATINY.
Mes essais de ce montage sont excellents!
Pour des questions de disponibilité de broches il n'est pas possible d'exploiter sans modification plus lourde (re attribution de broches) l'information de sens de commutation des polarités DCC ni de la piloter.
Cette fonctionnalité étant optionnelle et autonome finalement ce n'est pas un soucis. Cela existe est c'est "automatique" lorsque c 'est requis et on peut donc ne pas avoir à s'en soucier. ("transparent")
Un indicateur visuel (LED) reste toutefois présent
Les essais en cours de Christophe et rNe confirmeront naturellement le bien fondé de ces évolutions.
Ltr
-
En compléments:
Il n'y avait pas de seuil réglable par un dispositif externe du seuil de déclanchement de la protection.
Je viens de l'ajouter en trouvant juste la place pour y ajouter ce dispositif.
Un DIP SWITH 2 pôles fera le job offrant 4 réglages dont les valeurs seront positionnées au niveau DU SOFT.
Ltr
-
Bonjour
Vues actualisées des nouveaux boucliers modulaires.
Le premier assure les fonction de détection et protection ( DETECT & PROTECT)
Le second la fonction d'inversion des pôles DCC si on l(implémente. A défaut on la substitue par un "bouchon" pour "ponter" les parties IN & OUT. (INVERSER)
Cette version utilise un ACS712 mais un montage de type "COIL" pourrait aussi convenir. Le cout de la première solution étant plus avantageux.. on optimise!
Et pour les allergiques au SSR un relais serait une déclinaison encore acceptable...
Ltr
-
Bonjour
Pour illustrer la substitution simple des boucliers et des fonctionnalités qu'ils portent voici une vue cote à cote de deux d'entre eux pouvant occuper alternativement le même emplacement sur le socle qui les reçoit:
Chacun assure la détection et la mesure de conso (le montage à base de COIL a une sensibilité plus forte que celui à base d ACS712)
Chacun peut protéger en cas de court circuit
Le montage de gauche est limité à 4A MAX contrairement à celui de droite 8A MAX.
En revanche celui de gauche permet en plus d assurer une permutation des pôles DCC lors de leur distribution si besoin.
Le montage de gauche peut disposer de connecteurs directs permettant un usage autonome similaire à un "LK200".
Ltr
-
Bonsoir
Le bouclier inverseur à détection type "COIL" vient compléter la série.
Ltr
-
A titre d illustration voici en combinaison avec le socle les boucliers
DETECT ( avec faible courant) & PROTECT
INVERSER
RAILCOM
qui viennent desservir l'ESP32 et sa distribution.
On peut facilement combiner selon la nature des besoins et le cahier des charges pour y répondre.
Ex identification RAILCOM( module3), détection courant faible et protection "forte" ( module 1) le module 2 est alors "bouchonné"
Autre exemple: identification RAILCOM (module 3), inverseur (module2), détection courant faible et protection forte. (module1)
Ps le module inverseur à base de TLP3553 peut encaisser un bref pic allant jusqu'à 9A sur 100ms qui seront très suffisant pour enclencher la protection en amont bien avant d avoir atteint ce délais. On est donc "full" dans les spec des composants, ce que n'aurait pas pu tolérer aussi bien un relais à 2A par contact de coupure.
On voit du coup assez bien l'attrait qu'apportent les SSR a nos combinaisons.
Ltr
-
Bonjour
Le "module 3" ( en haut à droite) qui porte la fonction d'identification RAILCOM vient d'être redésigné afin de lui conférer une implantation CMS mono couche et ainsi réduire sont cout de fabrication.
Il prend naturellement place sur le socle support en lieu et place de son prédécesseur bi face. Son occupation très réduite de 40mmx40mm est idéale et on peut déjà imaginer la réutilisation de ce bouclier pour d'autres montages...
Ltr
-
Bonjour Laurent
Pense tu faire une cde de ces 2 modules?
J'aimerai bien tester le module RailCom
Marcel
-
Bonjour Marcel
Oui c est prévu. ( encore un peu de travail en amont pour préparer tous les exports pour la fabrication)
Il faudra que tu m'indiques les quantités que tu désires.
Si d'autres personnes veulent aussi en recevoir nous ajusterons le volume des commandes. Par défaut c est toujours 5 pièces de réalisées par tirage. Il en faut mini 3 voir 4 pour une mise en situation dynamique. (sans satellite autonome en version historique) mais l'atout de ces version va aussi être d assurer la compatibilité "montante" avec les satellites déjà existant y compris avec les ports RJ45 par ajout d'un adaptateur. ( si c est pas beau :) !)
Je note que tu désires tester le MODULE RAILCOM et quel(s) autre(s) module(s) veux tu essayer également?
Ltr
-
Bonsoir Laurent
Merci pour ces précisions.
Juste le module RailCom.
Marcel
-
Je t'en mets un "au chaud" quand il est prêt :)
Ltr
-
Bonsoir
La commande du bouclier RAILCOM est partie et la livraison est attendue d ici un grosse dizaine de jours.
Ltr
-
Bonjour
Alors que le bouclier RAILCOM est à présent en transit et arrivera dans quelques jours, le bouclier de gestion des CC/INVERSION est parti en fabrication.
J y ai revu quelques "bricoles" pour optimiser le tout avec cohérence favorisant une universalité. ( regroupement des leds cote à cote par exemple), couplage de sortie avec amplification transistor et PMOS pour pilotage des optomos,...
Le prochain à y passer devrait être en principe le bouclier de détection de présence faible courant avec fonction de protection (MAX 8A réduit à 5A) sauf si le besoin du socle de réception de base passe devant...
Ltr
-
Bonjour
Le bouclier de détection "faible courant" est en cours de finalisation.
Basé sur le montage proposé par NOXPOR et adapté du montage de PAISELEY il est ajuster pour nos usages avec la possibilité de
choisir la tension de pilotage de l optocoupleur permettant ainsi un portage AVR en 5V <> ESP32 ou CPU en 3V3 par un simple jumper.
choisir le mode de sortie en logique inversée ou non: si un train est détecté on envoie un message "0" on en envoi alors un message "1" la aussi par la fermeture d'un jumper
Comme une seule zone est prévue au monitoring le NE556 est remplace par son petit frère le NE555.
2 leds locales ( rouge/verte) indique visuellement si une détection est présente ou non.
Il encaissera comme détecteur global également sans broncher ses 5A.
Ltr
-
Bonjour
Premier boucliers RAILCOM reçus ce matin... en attente des connectiques encore en transit! :)
Moment d'émotion! 8)
Le surdimensionnement des condensateurs est totalement assumé (tranche 50V) occupant de fait un volume plus important de l'ordre du cm d'épaisseur! (<15mm))
Les pistes pour la circulation du DCC allant aux voies sont prévues pour supporter jusqu'à 3A (seuil max des diodes du montage)
Avec les connecteurs de liaison sous le PCB on aura ainsi une hauteur totale contenue sous les 3 cm.
Ce bouclier est naturellement exploitable pour d'autres usages que les seuls satellites autonomes.
Ses dimensions de 40mmx40mm compactes le rendent facilement "logeable".
Ltr
-
Bonjour
J'ai (encore) retravaillé une implémentation du bouclier N°2.
J'avais précédemment réussi à lui confier la détection de court circuit avec inversion de la distribution des pôles DCC par optoMOSFET soit par l'intermédiaire d'une mesure par COIL soit par mesure via ACS712 5A. (au choix à l'implantation)
Cette inversion était alors temporisée en cas de pic (type court circuit) pour éviter de multiples "FLIP FLOP" avant qu'un dispositif de coupure n'intervienne à un autre niveau (bouclier N°1 ou dispositif externe)
Ce montage pourrait assuré cette coupure mais n'aurait pas disposé de mécanisme externe de ré armement. ( 1 broche supplémentaire d'interface serait requise ce qui aurait fait revoir la conception des modules de type N°2 et de leur brochage... un très gros travail dont je me passe volontiers :) !)
Toutefois je restais persuadé de pouvoir encore "améliorer la chose" car je disposais sur ce bouclier d'une broche d'interface confirmant une détection.
Comme de nombreux composants pour confirmer une présence étaient déjà présents, ils ne demandaient qu'à être exploités avec plus d'efficience, il fallait chercher et trouver...
Il manquait alors au montage d'origine une interface avec cette sortie et la "pseudo opto isolation" permettant la bascule des niveaux de tension de façon optimale lorsqu'elle est nécessaire. ( pour PIN de CPU 3V3 ou 5V)
Un peu de travail pour y parvenir et tout caser dans les 16cm² à disposition sans bouger les broches de connexion, ajouter des composants, adapter la sérigraphie...
Tout y est à présent! 8)
Il y a même une petite astuce pour inactiver/ponter la partie d'inversion si elle n est pas nécessaire!
Le temps de revérifier ( encore et encore après une tempo propre à prendre le recul suffisant) ) et de confirmer les hypothèses ( quelques valeurs de composants dont il faut confirmer les valeurs précises) et il pourra partir aussi en production/fabrication...
Ltr
-
Bonjour
Le bouclier N°1 dans sa version "light" (limitée à 4A en protection mais assurant ici la fonction d inversion et de réarmement externe) est arrivé et doit encore recevoir quelques composants pour être ensuite testé.
L'intérêt de cette version et de pouvoir être 100/100 autonome pour la gestion d'une boucle/triangle/plaque de retournement.
Le WE s'annonce chargé en tests d'autant que la connectique commence à arriver...
Ltr
-
Bonsoir
Mes tests ont commencé... et avec un code encore perfectible! ( un oubli de #conditionnel sur le Serial.begin pour le "debug" a eu tôt fait d'activer la pin TX en permanence faussant mes résultats! et le lançant sur des recherches bien loin de l'origine de cette erreur grossière!!
Tout semble rentrer dans l'ordre à présent.
La bonne nouvelle quand même c est que le hard semble faire ce qu'on attend de lui :) ( tests à poursuivre)
A suivre donc...
Ltr
-
Bonjour
Le hard du bouclier d'inversion/protection est validé.
L'alimentation du montage depuis le DCC régule bien via le convertisseur DC DC.
Les commutations tournent comme une horloge. (déclanchement mécanique via bouton)
Il reste à valider les seuils des bascules, voir des temporisations de façon dynamique.
Si pour le HO je suis pourvu, les tests pour le N me sont impossibles car pas équipé pour.
Un volontaire qui dispose de l'infra pour cela? @Dominique peut être?
La suite dans la foulée...
Ltr
-
Bonjour
Le bouclier assurant les détections est arrivé. ;D
Ici en panneau 3x3 il faut encore l'équiper de ses composants "traversants" dont les "COILS" et le passage du fil dans l'anneau.
L'empreinte pour les COILS est adaptée pour différents modèles.
Illustrés ici sur les photos le cas de ZMCT103C de 1000 tours.
Quelques essais restent donc encore à mener pour les valider.
Pour memo ils sont basés sur le montage "PAISELY" proposé par NOXPOR (Eric) qui a été ici adapté au contexte "satellites" en approche modulaire.
Le NE555 remplace le NE556 puisque seule une "entrée" est utilisée.
Un opto assure la conversion de tension (5V ou 3V3) de l'état de sortie pour aller vers le CPU.
Des indicateurs lumineux (ROUGE = OCCUPE) ( VERT = libre) complètent le dispositif en affichant l'état sur la zone de détection.
En complément il est possible d'inverser l'état de sortie haut ou bas qui traversera l'optocoupleur pour indiquer au CPU l'état d'occupation.
Ltr