Les SATELLITES AUTONOMES: évolutions du socle initial

[laurentr]

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

[bobyAndCo]

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

[laurentr]

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 )

[laurentr]

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

[laurentr]

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)


Je suis preneur de vos avis sur ces valeurs de temporisation.

Plusieurs essais seront possiblement nécessaires pour trouver le juste milieu.

Laurent

[laurentr]

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

[laurentr]

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

[bobyAndCo]

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

[laurentr]

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

[laurentr]

Avec une petite vue actualisée du dispositif.

[laurentr]

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

[laurentr]

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

[bobyAndCo]

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

[laurentr]

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

[Etienne66]

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.