Voir les contributions

Cette section vous permet de consulter les contributions (messages, sujets et fichiers joints) d'un utilisateur. Vous ne pourrez voir que les contributions des zones auxquelles vous avez accès.


Messages - laurentr

Pages: 1 ... 13 14 [15] 16 17 ... 44
211
Vos projets / Re : Les SATELLITES AUTONOMES: évolutions du socle initial
« le: février 13, 2024, 03:38:21 pm »
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

212
Vos projets / Re : Les SATELLITES AUTONOMES: évolutions du socle initial
« le: février 13, 2024, 12:33:11 pm »
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

213
Bonjour Etienne

As tu regarder le montage du MERG que je proposais? ( lien dans mon post précèdent)

Tu sembles indiquer que l'on peut se passer du comparateur et donc en gros de presque tout le montage autours. Ce que d autres montages sur la toile montrent a quelques variantes prêt.

Toutefois cela se fait au prix d'une sensibilité à calibrer coté soft + debounce je pense. Sur un ESP32 avec interface WEB c'est plus simple à réaliser que coté CPU dédié sans interface...

Si on suit l'idée de Christophe de laisser à un petit CPU le soin de traiter cela à part de l'ESP32 et de simplement l'informer de l' état (0/1) il semble que l'approche avec réglage externe ( potard/trimer) soit à privilégier.

Michel avait proposé aussi un montage à base d'ACS712 et d'ampli op qui pourrait convenir également.

A voir ou se trouve l'optimum.

La contrainte va outre être le cout de faire tenir le tout dans un format exploitable ( avec les satellites V2) ou le rendre modulable facilement ce qui a pour conséquence immédiate de multiplier les connections...

A creuser donc...
Ltr

214
Hello

J ai aussi fait des recherches sur ce sujet concernant la détection de conso à l'aide des COILS pour gérer la détection. Plusieurs montages existent.

1000 tous ou 50 tours ( ou autre valeur) , nombre de passage autour du tore... voila bien des questions/sujets à expérimenter.

Les AVR ( et MEGATINY) sont en effet plus connus pour avoir un ADC disons plus efficace que celui de l'ESP32.

Apres il y a 2 cas d'usage:
on exploite via un "simple" état 0 ou 1 une occupation ou non.
on veux un retour d'une mesure qu'on veut traiter (interpréter plus finement) voir corriger en cas de sensibilité à ajuster. ( le contexte peut influencer des mesures et il est prudent d avoir un ajustage (mais tout se discute)

Pour ma part je préfère séparer les usages entre mesure continue ( COIL) ( ou INA219) ou ( INA169) ( ou AMPLIOP)  et détection de CC( via ACS712) ( c est encore une fois un avis discutable)

L'ACS712 et le coil ont 2 intérêts: ils offrent une isolation galvanique totale entre le DCC et l'électronique autours de l'ESP32 ou des autres composants. ( pourquoi s en priver)
Cependant l ACS IMPOSE de travailler de son cote en 5V.
Leur présence n altère pas le signal DCC ( chute de tension, etc)

Passer des info entre l'AVR/MEGATINY et l'ESP32 impose de garder cette isolation ( du fait des tension en 5V cote AVR et 3V3 cote ESP32.)

On va me dire alors pourquoi ne pas faire tourner l'AVR/MEGATINY en 3V3 puisque c est possible... à vitesse réduite, cela se réfléchit mais disqualifie l ACS712 pourtant bien pratique.

En tous les cas la V2 sur laquelle je planche utilise:
un petit CPU en 5V avec l'ACS712 et la détection de CC pour protection ( et inversion de pole si besoin confiée à des MOSFET plutôt qu'à un relais), la notification d'état à l ESP32
je laisse l ESP32 gérer tt le reste comme précédemment avec en plus la faculté de basculer ou réarmer la protection de coupure en cas de CC en agissant sur l'AVR.

Par contre l ACS712 n'est (probablement) pas assez sensible pour les très faibles consos donc le recours au "coil" est de mise.

Pour le moment la lecture de ce qu'il mesure est confiée à l'ESP32 mais peut riper sur l'AVR qui va devoir grossir un peu pour aller sur un 20 broches ( c est déjà FULL en 14!) et traiter ces mesures. sauf à de légers compromis ( sur les leds d indication puisque il faut alors disposer de 2 I/O ( 1 pour les mesures , 1 pour faire la notification d'état)

On peut trouver la place sur le PCB mais on va perdre un peu en modularité... (on place les composants sous le module RAILCOM qui est en surplomb.) A voir donc...

Je pense au montage du MERG dans le cas d un simple détecteur d'occupation à seuil réglable. En étant opto couplé il ira aussi bien sur un AVR que sur un ESP32!

https://www.merg.org.uk/merg_resources/dcc/download/BOD1_SCH.pdf

Il y en a d'autres naturellement.


Tous les avis sont possibles.

J attends les vôtres :)

Ltr





215
No soucis!

J ai légèrement fait évoluer ce mapping pour des optimisations de routage sur le nouveau PCB.

A priori rien de gravissime à (re)définir.

Ltr

216
Vos projets / Re : Les SATELLITES AUTONOMES: évolutions du socle initial
« le: février 12, 2024, 05:28:49 pm »
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

217
Vos projets / Re : Les SATELLITES AUTONOMES: évolutions du socle initial
« le: février 12, 2024, 03:45:38 am »
Avec une petite vue actualisée du dispositif.


218
Vos projets / Re : Les SATELLITES AUTONOMES: évolutions du socle initial
« le: février 12, 2024, 03:35:30 am »
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




219
Vos projets / Re : Les SATELLITES AUTONOMES: évolutions du socle initial
« le: février 11, 2024, 06:23:35 pm »
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


220
Hello Christophe

Tu peux me confirmer que le mapping suivant est bon ? ( d après tes docs.)

Quels sont les utilisations qui peuvent être modifiées et celles qu'il faut considérer comme fixes?

Je pense à regrouper certains PINS par usage ( ex les SERVO), ajouter l'usage de l'I2C au passage, ...

Ltr


221
Vos projets / Re : Les SATELLITES AUTONOMES: évolutions du socle initial
« le: février 10, 2024, 11:56:31 pm »
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





222
Bonsoir

Le 4eme volet est également dispo!

Efficace et très bien fait.

La suite la suite..!!

Ltr

223
Bonjour

Pour en revenir au détection par "COIL" il faut bien regarder le transfo qui est utilisé.

En effet le ZTC103C est un transfo qui est de 1000 tours

https://5nrorwxhmqqijik.leadongcdn.com/ZMCT103C+specification-aidirBqoKomRilSjpimnokp.pdf

On notera ici la figure II du document pour memo

A contrario des transfos de 50 tours comme le PE-51686NL

https://www.mouser.fr/datasheet/2/447/P578-2903922.pdf

ou le  CS1050L
https://www.mouser.fr/datasheet/2/597/senhi-463471.pdf

Les deux dernières marques proposent des versions à 100 et 200 tours également mais pas 1000 tours.

Donc selon la sensibilité/plage de mesure désirée le choix est important.

On peut aussi multiplier le nombre de spires de passage du pole DCC dans l'anneau ce qui revient à diviser le nombre de tours par le nombre de passage et donc la valeur en sortie.

Ltr



224
Bonjour

Pour la détection utilisant le meme principe par "COIL" il y a le modèle du MERG de Mike BOLTON

https://www.merg.org.uk/resources/dcc

Plus précisément ce montage: BOD1:

https://www.merg.org.uk/merg_resources/dcc/download/BOD1_txt.pdf

Schematic:

https://www.merg.org.uk/merg_resources/dcc/download/BOD1_SCH.pdf

On retrouve bien la similitude d'avec le montage évoqué précédemment.

La description fournie explique bien le phénomène.

Avantage ici une sensibilité réglable ce qui peut toujours être utile dans des contextes d'utilisation toujours différents d'un réseau à l'autre. ( hydrométrie, température, âge du capitaine...!)

D'autres montages sont également présents sur les pages du MERG, notamment au travers de leurs solutions d'utilisation du bus CAN.

Ltr



Ltr

225
Vos projets / Re : DETECTION ET PROTECTION CONTRE LES COURT-CIRCUITS
« le: février 08, 2024, 05:43:53 pm »
Rm: dans l'exemple de code fourni pour illustrer plus haut qui était prévu pour un MEGATINY x6 à 20 broches les ports sont différents.

Il faut donc remplacer les 4 port B du x6 part des port C sur le x4 qui ne dispose pas de port B sur son hardware.

Ltr

Pages: 1 ... 13 14 [15] 16 17 ... 44