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 2 [3] 4 5 ... 40
31
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

32
Reprise simplifiée du montage précèdent proposé par Eric (NOXPOR) ( dérive du montage de PAISLEY)

https://web.archive.org/web/20140825051230/http://home.cogeco.ca/~rpaisley4/DccBODvt5.html

Je pense que je vais mettre en œuvre celui ci...

Ltr




33
Voici une autre version "custom" reprise de https://web.archive.org/web/20140825051230/http://home.cogeco.ca/~rpaisley4/DccBODvt5.html dont j ai adapté les sorties.

Le seuil est ici au 2/3 de la tension lue sur les capa de 2.2uF en entrée.


Cela semble donner un fonctionnent très "binaire".

Elle est cependant tronquée de la partie "réglage" par "potar" de la solution de H SCHAFER mais produit un résultat similaire.

A voir ou se trouve l'optimum.

Ltr

34
Bonsoir

Pour apporter un peu de visibilité sur les designs discutés voici les 3 constructions de design assurant la détection de courants faibles.

Chaque solution requiert plus ou moins de composants notamment en regard des tensions requises sur les IO du CPU final ( ex 3V3 pour les ESP32 vs 5V sur AVR)


La solution d'Eteinne66 est testée sur AVR (ARDUINO MEGA 2560). Elle fonctionne mais quelques ajustements peuvent être requis ou traités au niveau soft.
Cette solution est l'une des plus économiques.

Pour ce qui est des détections "erronées" un début d'explication dans les propos de R.MULLER:

Traduction GOOGLE:
"J'ai donc essayé de me débarrasser du potentiomètre. Mais un test sur un tracé réel a montré des problèmes avec certains modules, montrant une occupation même sans rien sur la piste. La capacité des fils appariés produisait suffisamment de courant au moins aux bords du signal DCC. Le retard logiciel a rendu le capteur encore plus sensible à cet effet. Un condensateur à la base du transistor a résolu le problème. Aucun des 28 capteurs utilisés lors de la réunion d'Alsfeld n'a détecté de fausses informations. même avec le condensateur, le capteur est suffisamment sensible pour cette application."

Source: voir section CIRCUIT:
http://dcc-mueller.de/wire4dcc/sensor_e.htm

Ltr




35
Bus DCC / Optimisation du hardware autour de l opto 6N137
« le: mars 28, 2024, 10:45:34 am »
Bonjour

Au hasards de mes recherches je suis tombé sur cette mine d'information pour optimiser le hardware autour de l opto 6N137 qui est très souvent utilisé comme interface CPU <-> DCC.

https://wakwak2popo.wordpress.com/2020/12/11/dcc-sniffer/


On voit que les tests poussés à l'oscillo montrent bien un optimum pour avoir des fronts les plus nets possible.

Aussi cela se fait avec la combinaison d une capa de 1nF en entrée cote signal DCC, la diode 1N4148 et une résistance de PULLUP mise à 470r

Information précieuse qui favorisera la qualité des signaux transmis à nos équipements.


Laurent

36
Vos projets / Re : Projet partagé d'un gestionnaire de réseau
« le: mars 27, 2024, 10:29:36 pm »
Bonsoir


Pierre dans ce que tu définis comme une "zone de manœuvre" sur laquelle entrer avec une occupation cela me semble aussi ressembler aussi à une option de "forçage" du bloc.

Les cas d'usage sont multiples indépendant du concept de manœuvre pure:

mise en tête/queue d une loco sur une rame assurant une détection de présence sur la zone
cas des UM /couplages
refouler /avancer une loco qui "aurait fait des petits" pour raccrocher

Pour toute ces raison le mode manœuvre ouvre une sorte de dérogation permanente sur des section bien précises
Dans le cas du forçage c est une condition externe à caractère "spécifique et temporaire".

La facilite c est aussi de tout déclarer possiblement en manœuvre... mais la sécu du bloc va en prendre un coup!...


Ltr

37
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

38
Supposition sur le phénomène ou causes qui peuvent amplifier:
proximité (trop)rapprochée des coils
passage des fils DCC et mesure qui se touchent

dernière hypothèse: la faute à pas de chance :) ( je sais elle plait souvent celle ci!)

Ltr

39
Bibliothèques / Re : Bibliothèque SlowMotionServo
« le: mars 26, 2024, 10:23:19 am »
Bonjour

J ai une suggestion d ajout à la bibliothèque SLOW SERVO MOTION.

En effet lors de la mise en place  d'un servo il peut etre intéressant que celui ci soit "centré" avant de venir de configurer ses mouvements dans un sens ou l'autre.
On ne part ainsi pas toujours de la butée d un coté ou de l'autre.
Il existe des petits boitier dans le commerce qui réalise cette opération.
A titre d exemple:
https://fr.aliexpress.com/item/1005006068916027.html?spm=a2g0o.productlist.main.63.1e513f36pLiCcm&algo_pvid=d1e57db0-71f9-464e-aa5e-e059ffb6f348&algo_exp_id=d1e57db0-71f9-464e-aa5e-e059ffb6f348-31&pdp_npi=4%40dis%21EUR%213.72%212.23%21%21%213.94%212.36%21%402103853617114448488042159e8186%2112000035582837081%21sea%21FR%21907093358%21&curPageLogUid=o6sH43QgsiNI&utparam-url=scene%3Asearch%7Cquery_from%3A

ou bien encore:
https://fr.aliexpress.com/item/1005004995645232.html?spm=a2g0o.productlist.main.67.1e513f36pLiCcm&algo_pvid=d1e57db0-71f9-464e-aa5e-e059ffb6f348&algo_exp_id=d1e57db0-71f9-464e-aa5e-e059ffb6f348-33&pdp_npi=4%40dis%21EUR%217.03%217.03%21%21%2153.92%2153.92%21%402103853617114448488042159e8186%2112000031284887558%21sea%21FR%21907093358%21&curPageLogUid=pLveJpALMQv5&utparam-url=scene%3Asearch%7Cquery_from%3A

Dans cette idée une methode de type bool  ou void setMiddle(uint8_t PIN) serait bienvenue.

On peut certes la créer de toute pièce avec une valeur de 0.5 mais en disposer nativement me semble un plus comme outils.


Laurent

40
Bonjour

Ah RC et le canal N°2...!

On a pas encore versé dedans jusque la, ca va être l'occasion!


Les boucliers RAILCOM version CMS sont en fabrication donc très prochainement dispo.( je pense milieu de semaine prochaine)

Je me pose la question suivante en tant qu'ensemble à former:

Bouclier de mesure RAILCOM + ESP32 ( ex un petit mini C3)   + alim DC DC + module de détection d'occupation haute sensibilité ( COIL) + tranceiver CAN et/ou interface  LOCONET pour former un détecteur d'occupation avec identification me semble réalisable.

Pourquoi LOCONET?
En effet sauf à disposer d'une moulinette qui transcrira le CAN sur un équipement tête de ligne "compatible" hormis l'encapsulation LOCONET de la trame RAILCOM avec une utilisation des infos par des SOFT commerciaux... je n'ai pas vu de réalisation équivalente.

Pour le moment outre le cout cumulé des ces sous ensembles je ne vois pas de restriction spécifique.

Je suis même curieux de savoir comment la transco s'opère dans l'idée d une passerelle RAILCOM sur CAN/LOCONET vers SOFT

A vos avis...

Laurent

41
Bonjour Etienne

Voila un retour intéressant :)

Si on considère le "bruit" à corriger , de quel ordre de grandeur est il?

Sur mes tests avec ACS712 5A (échelle 185mV/A) et avec un ADC 10bits coté CPU une sensibilité < 50mV semble à proscrire. (soit en gros 10mA) A confirmer par d'autres essais pour voir sil ne faudra pas doubler les valeurs.

Je suis aussi resté sur des valeurs par défaut. Pas d'utilisation de Vref avec par exemple un TLP431 réglé aux petits soins pour étalonner.
L'écart étant ici admissible puisque ce n'est pas la précision la plus fine qui est absolument recherchée.

J ai expérimenté ( et je continue) 2 méthodes pour la correction de celui ci.

Un première consiste à négliger les valeurs unitaires des analoguRead() < à un seuil donné et de les remplacer par "0" en faisant la somme ensuite puis la moyenne.

La seconde complémentaire ou non de la première et de faire une moyenne elle aussi "nettoyée" car si inferieure à une valeur donnée là aussi elle est alors remplacée par "0"

Tests réalises sur un NANOEVERY ( AVR Serie0 ADC10bits dont la lecture unitaire d échantillon ( x100) analogRead() est de 2 samples par mesure par défaut en 22 à 24us)

Pas (encore) eu l'opportunité de sortir un 328P/2560 pour comparer.

Coté bouclier j'ai finalisé ceux ci avec l'ajout en // soit de l'usage d'un ACS712 ( 5A 10A 20A) ou d'un coil ( PE5xxx ou AS-103 ou zmct103)

J ai pour le coup également retravaillé les largeurs de pistes pour bien "encaisser" les différents ampérages sans aléas sur  les sections DCC allant aux voies. La connectique prévue des l'origine n'a subi aucune modification!

Pour rappel j'utilise cette calculette bien pratique:
http://nononux.free.fr/index.php?page=elec-brico-outils#!elec-brico-outil-largeur-piste-pcb

Les boucliers bouchons sont aussi finalisés.

Pour memo on pourra avoir:

En entrée jusqu'à 8A ( avec le module de protection) et en sortie jusqu'à 3A (via module RAILCOM)( selon les seuils des diodes)


PS: J'étale un peu les dépenses de réalisation car (seul à financer) ca pique (un peu)!
Mais tout finira par être testé!

Ltr




42
Bonsoir

La commande du bouclier RAILCOM est partie et la livraison est attendue d ici un grosse dizaine de jours.

Ltr

43
bonsoir , juste une courte récréation , si vous voulez bien
j'avais dessiné ceci , une carte de rétro-signalisation pour occupation et identification railcom , à 8voies
mais comme je ne l'ai (toujours) pas essayée , je n'en dirai pas +

Hello Marc

Sur ton décodeur d'occupation avec IDENTIFICATION RAILCOM dont tu pourras nous parler plus en détail dans un post dédié comment résous tu l'identification pour chacune des zones? ( ou alors est ce une identification globale couvrant jusqu'à 8 secteurs et une occupation secteur par secteurs? ( LN = LocoNet?) Que ce passe t il si 2 engins émettent en même temps?

Ltr

44
Je t'en mets un "au chaud" quand il est prêt :)
Ltr

45
Bonsoir rNe

Le mieux est parfois l'ennemi du bien!
A tester pour pouvoir se positionner avec plus de certitudes.

Pour ce qui est des seuils et temps de déclanchement cela varie d'une marque à l'autre:
Par exemple LENZ est proche de 100ms pour le déclanchement. Je n'ai pas le seuil max A en tête.
Coté DIGIKEIJ /YAMORC on peut régler ces 2 valeurs depuis l'interface de paramétrage. Par défaut on tourne sur 1.5A et 30ms mais on peut monter ces chiffres par configuration.

Une valeur mise à au delà de 50ms n'est en rien exagérée et couvre son rôle.

Dans tous les cas il faut garder en tête que le déclanchement de la protection du booster et ou de la centrale doit être le temps le plus long/ ampérage le plus élevé (globalement)  car en haut de chaine venant de la voie.

A voir ce que ROCO sur Z21 et ESU proposent de leur coté respectifs.

Ltr

Pages: 1 2 [3] 4 5 ... 40