Messages

46

Vos projets / Re : Les SATELLITES AUTONOMES: évolutions du socle initial

« le: mars 18, 2024, 04:19:06 pm »

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

47

Vos projets / Re : Les SATELLITES AUTONOMES: évolutions du socle initial

« le: mars 17, 2024, 11:31:48 pm »

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

48

Vos projets / Re : Les SATELLITES AUTONOMES: évolutions du socle initial

« le: mars 17, 2024, 10:15:43 pm »

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. 

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

49

Modélisation, Architectures logicielles et matérielles / Re : DCC : Détection par consommation avec des courants faibles

« le: mars 17, 2024, 10:11:06 pm »

Hello Marc

On s'amuse comme on peut hein !

Mais joli boulot, y a plus qu'a!


Ltr

50

Modélisation, Architectures logicielles et matérielles / Re : DCC : Détection par consommation avec des courants faibles

« le: mars 15, 2024, 05:11:37 pm »

C est bien ce que mes tests confirment de mon coté

La "clé" est donc bien dans ce lissage et les réglages autours.

Dans des conditions "extrêmes" j ai bien un PIC sur l ACS712 et donc il doit aussi en être de même sur le COIL à la même vitesse.

En revanche là ou j ai probablement une différence est que je faits 100 mesures successives individuellement de 24us chaque donc pour près de 2.5ns sur un AVR x ( j ai pris un nanoevery pour les tests)

L ATTINY44 étant plus lent pour ces même 100 mesures, on va de fait avoir naturellement un lissage sur le même nombre d itérations par le temps unitaire de chacune d elles.

Si je ne me trompe pas 100 mesures sur AVR "classique" type 328P MEGA2560 et consorts ( dont le TINY44) a un coef X4 avec les AVRx ( Serie 0, AVR Dx et MEGATIY)

Enfin cela me semble une explication valable à considérer.

Ltr

51

Modélisation, Architectures logicielles et matérielles / Re : DCC : Détection par consommation avec des courants faibles

« le: mars 15, 2024, 03:06:41 pm »

Bonjour

Lors des tests avec la solution retenue  (COIL) avez vous vous identifié un phénomène de pic transitoire ( INRUSH CURRENT)  lors de l'entrée sur la zone monitorée?

Si en détection 0/1 cela ne joue pas en cas de pic et de seuil de déclanchement, il peut y avoir des surprises...

Laurent

52

Bus CAN / Re : Question mise en place CAN dans la centrale DCC

« le: mars 14, 2024, 12:36:58 pm »

Merci Christophe pour ces info.

Débutant avec ce hardware encore mal connu pour moi et ayant quelques idées de la façon de l'intégrer à différents montages, à la lecture également du modèle de messagerie que tu as récemment proposé, j essaye de voir comment articuler le tout pour par exemple disposer de décodeurs locaux sous le réseau avec une fonctionnalité propre ex un décodeur d aiguillage CAN intégrant le pilotage d un servo, la commande d un relais pour une polarisation de pointe de cœur et message d acquittement en retour.

Idem pour un décodeur de signal.

Je note bien que les filtres vont jouer un rôle majeur mais la notion de priorité me pose question car si il y a une pile de messages prioritaires qui ne désemplie pas ( ex le cas de tes satellites qui pilotent les info servant aux instructions les vitesses des trains) comment s assure t on de disposer d assez de bande passante pour les messages moins prioritaires? ( enfin qu'ils soient émis et reçus car si toujours relayes ils finissent par ne pas être transmis?)

Il doit bien y avoir des "trucs" pour tout cela... je dois encore les appréhender.

Ltr

53

Vos projets / Re : DETECTION ET PROTECTION CONTRE LES COURT-CIRCUITS

« le: mars 13, 2024, 01:56:37 pm »

Une solution "simple" consiste à réaliser un échantillonnage de mesures sur un plus grand nombre d'itérations ce qui allonge la durée au détriment de la réactivité.

J'ai personnellement préféré une mesure brève des échantillons de référence.

Voici la trame mise en œuvre:

1/mesures:
on effectue un échantillonnage sur 100 mesures consécutives via analogRead() afin de vérifier si la valeur moyenne > seuil
passage en 2/ si dépassement sinon on reste en 1/

2/ on inverse immédiatement la distribution des pôles J/K, on note le temps T0 de référence, on calcul le temps de fin max et on passe au point 3/

3/ on temporise légèrement grâce au temps de référence comme base et le temps écoulé avec une comparaison du temps de fin max avec micros() (via boucle while() , pas de delay()!! )  comme l'avait suggéré Etienne.
J'ai mis ici 30ms.
Puis, on mesure s'il y a un pic de conso > seuil au delà d'une durée de référence ici mise à 30ms également.

Ces deux valeurs peuvent encore faire l'objet d'ajustements.

Si temps maxi dépassé on passe en 4/
Sinon on repasse en 1/

4/ ou coupe pour protéger


Une interruption externe permet de sortir de 4/ pour repasser vers 1/ et inverse également la distribution des pôles J/K.

Dans chaque étape des leds témoins indique les statuts.

Les premiers tests sont encourageants et répondent comme attendus.
Le pic de courant du moteur de test lorsqu'il est connecté et avec son démarrage sont bien vus par 1/ et font passer en 2/ puis 3/ avant de revenir vers 1/

Il faudrait sortir l'oscillo pour mesurer le temps du pic avec ce moteur et avec d'autres pour voir si une tendance peut être dégagée et optimiser les valeurs, idem avec une rame loco en charge d'une rame "lourde" et ou" haut le pieds".
En effet l'effort à produire au démarrage d'un convoi étant diffèrent les timings et valeurs peuvent nécessiter d'être revues/ajustées.

Pour la charge des "grosses capas" si les choses sont bien faites leur courant de charge est limité. (IL DOIT L'ETRE) Toutefois dans le cas de multiples charges à réaliser en parallèle les unes des autres ces courants s'additionnent et donc leurs pics d'appels même transitoires.

Ltr.

54

Vos projets / Re : DETECTION ET PROTECTION CONTRE LES COURT-CIRCUITS

« le: mars 13, 2024, 11:22:04 am »

C'est "au menu des tests" à réaliser afin aussi de se prémunir de tout aléas, voir d ajuster des valeurs dans le code (timing/seuils...)

Ce n'est finalement pas si "trivial" que cela en à l'air!

Ltr

55

Modélisation, Architectures logicielles et matérielles / Re : DCC : Détection par consommation avec des courants faibles

« le: mars 13, 2024, 11:19:30 am »

Dans son rôle de séparateur en effet avec une même masse commune... l'isolation galvanique est morte! Cependant, il contribue encore au passage des seuils 3v3 et 5V qui ont alors masse commune ici.

Pas sur que cela soit le résultat visé/ attendu puis qu'on va de fait lier la masse du CPU principal ESP32 à la masse de ce montage provenant du DCC ce qu'on désirait ( je présume) éviter également.
Mais c'est bien un rôle de proto de lever tous les "lièvres"...

Ltr

56

Modélisation, Architectures logicielles et matérielles / Re : DCC : Détection par consommation avec des courants faibles

« le: mars 13, 2024, 11:01:26 am »

Bonjour

J ai avancé de mon coté avec les mesures qu'apportent l'ACS712 pour la gestion de ma boucle de retournement avec mise en protection en cas de dépassement de seuil post bascule. Ce n'est pas le montage retenu ici mais les enseignements que j en ai tiré permettent un retour d'expérience appréciable qui pourra être intégré au montage en cours.

J ai "essuyé les plâtres" si j'ose dire! 

Je ne sais pas comment le montage avec  COIL va se comporter (comme l ACS712?) car je ne dispose pas (encore) du matos pour le tester moi même.

Mais à toute fin utile j'ai actualisé et détaillé les conditions de tests et les résultats obtenus dans le post correspondant.
https://forum.locoduino.org/index.php?topic=1661.0 

Je pense qu'il faut du coup bien éprouver les conditions de tests avec différents matériels et se méfier des seuils bas et du "bruit" .

Ltr

57

Vos projets / Re : DETECTION ET PROTECTION CONTRE LES COURT-CIRCUITS

« le: mars 13, 2024, 10:47:47 am »

Bonjour

J'ai procédé à la suite de mes tests.

J'ai rencontré quelques "surprises inattendues" qu'il a fallu traiter étape par étape.

La plus grosse d entre elle est que dans ma loop() une condition switch(ETAT), qui constitue exclusivement le corps du code, itère selon la valeur d une variable, ne fonctionnait pas!

J ai découvert le "truc" en insérant des Serial.print() régulier dans les étapes du code pour voir les enchainements.
Ceux ci ne se réalisaient pas! Le switch étant inopérant!!!

Autre subtilité une variable dont la valeur ne se conservait pas... et la suspicion d'un WATCHDOG actif sur le CPU de test.
Apres un re flashage des fuses... cela c'est passé beaucoup mieux! ( merci BLINK!)

Autre "surprise du chef" et oui on en va pas s'arrêter en si bon chemin, en utilisation en courant continu sur le pilotage du moteur connecté sur l'ACS712 la lecture fait apparaitre même de façon extrêmement temporaire un PIC au démarrage du moteur (INRUSH CURRENT) qui peut alors déclencher les conditions de bascule de façon "abusive" et "erronée" car ce pic n'est que transitoire lors du démarrage du moteur. Je pense que l' on pourrait avoir exactement le même comportement en source d'alim DCC. (tests a venir)

En revanche la hauteur de celui ci m'a fortement surpris. (proche de 1A!!)

J'utilise le moteur d'une carte de TEST ESU permettant de connecter des décodeurs DCC pour leur programmation.
La carte dispose d'un petit moteur équipé d'un volant d inertie.

La consommation de ce moteur à vide est très faible en étant proche de 50mA sous 12V environ.


Je suis repassé à des if(ETAT ==xx) ce qui a permis de bien enchainer les éléments ce que curieusement le switch() ne réalisait pas.

Je n'ai pas compris l'origine de ce symptôme

Pour augmenter la consommation du moteur je pose doucement mon doigt dur le coté du volant afin de générer un effort qui fait monter la consommation.

Celle ci fait varier les mA et une fois atteint le seuil de bascule... cette fois cela commute si toutes les conditions sont bien remplies.

le "RESET EXTERNE" est confié à un bouton poussoir sur un PIN en INPUT_PULLUP via un attachinterrupt(digitalpintointerrup(broche ID),fonction_reset,FALLING) qui joue merveilleusement bien son rôle

Comme la tension n'est pas un modèle de stabilité absolu les fluctuations sur les retours de analoguRead() de la broche provenant de l'AC712 sont "écrêtés par la bas" pour nettoyer le "bruit" Pour memo l'ACS712 a un bruit de l'ordre de 20mV (source datasheet)

De même, la moyenne de l'échantillon de mesure (100 mesures successives prenant chacune ~24us ) est également "écrasée" pour les plus faibles variations qui en mv sur la lecture se traduise dans la mise à l'échelle par des mA imaginaires.

Ces petits ajustements fait j'obtiens à ce stade de réalisation des conditions de tests valides et des résultats en accord avec l'objectif donné.

D'autres tests vont suivre mais ceux ci caractérisent une étape importante de franchie.

Ltr

58

Bus CAN / Re : Question mise en place CAN dans la centrale DCC

« le: mars 08, 2024, 04:40:15 pm »

Bonjour

Je me plonge dans cette rubrique qui mériterait plus de visibilité pour ceux qui comme moi plongent dans le CAN de "0".

Une première question qui me vient est que l ensemble des messages transitant d une source vers une destination ( possiblement multiple) y aurait il un intérêt à définir un bus montant et un autre bus descendant pour favoriser l écoulement des flux?
Cela peut paraitre luxueux mais après tout cela spécialise chacun des bus à un usage déterminé: émission ou réception, ce qui peut dans certain cas en passant par un "centralisateur" décorréler les actions en favorisant les vitesses de transmission en regard des temps de traitement qui peuvent requérir plus de cycles surtout si les destinataires d un même message sont nombreux et doivent être différenciés.
Ltr

59

Modélisation, Architectures logicielles et matérielles / Re : DCC : Détection par consommation avec des courants faibles

« le: mars 08, 2024, 04:11:40 pm »

Nous sommes tous d accord, moins il y a de CC est mieux cela va.

Plus on peut anticiper et mieux c'est.

Quand il y en a un, plus on agite vote est mieux  c'est aussi!

Apres l ambition est de couper localement plus vite qu'au niveau global avec moins de conséquences ( surtout sur des réseau de plus grande taille que la simple table de cuisine)

En capitalisant sur ce sujet on peut aussi extrapoler à d'autres usages.

Ltr

60

Vos projets / Re : DETECTION ET PROTECTION CONTRE LES COURT-CIRCUITS

« le: mars 08, 2024, 01:11:41 pm »

Bonjour

Utilisé avec bonheur et simplicité hier soir!

Remarquable, simple et efficace!
Un outils très utile finalement.

Laurent.