Messages

1

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

« le: septembre 07, 2024, 05:47:08 pm »

Bonjour,

Ayant reçu mes composants (zmct103c, diodes, zeners...) j'ai monté une carte de détection 16 cantons
sur une breadboard à souder connectée aux entrées analogiques d'un mega2560.
(pour l'instant je n'ai connecté que 8 entrées)
Et j'ai monté une voie de test (avec mes vieux rails jouef acier!) avec 3 cantons pour tester le tout.

Et ça fonctionne comme prévu à un détail près : les parasites.
Lors du premier essai à vide j'avais un haut niveau de parasites, d'un ordre de grandeur comparable à la
mesure d'une roue résistive. Du coup tous mes cantons étaient détectés comme occupés.
J'ai monitoré les valeurs lues par le mega et j'ai eu une surprise : les parasites étaient aussi sur les
broches qui n'étaient pas connectées. Donc ça ne venait pas des coils. J'ai rapidement vu qu'ils apparaissaient
dès que j'allumais la centrale.
J'ai essayé de faire des mesures avec un wagon sur un canton et une loco sur un autre. Et là, surprise!
Les deux cantons occupés avaient une valeur plus forte mais surtout les autres n'avaient plus de gros parasites.
Des essais supplémentaires m'ont permis de conclure que je n'ai des gros parasites que si le réseau est
totalement innoccupé (ce qui n'arrivera jamais).
Il est probable que le réseau à vide joue le rôle d'une antenne qui amplifie les parasites.
Donc je valide mon montage et je continue avec les tests de communication avec JMRI.

Bonjour, et excusez moi du déterrage mais après avoir déménagé j'ai enfin attaqué la construction de mon réseau et j'ai donc pu faire des tests en réel.
Et ça ne marche pas 
Après divers tests et quelques recherches internet j'ai trouvé pourquoi.
L'impédance statique (résistive) des entrées analogiques de l'arduino sont assez élévées, mais ça dégringole dès qu'on commence à lire les entrées.
L'explication se trouve dans la charge d'un condensateur pour échantillonner l'entrée avant l'envoi sur l'ADC qui détruit l'impédance effective.
Et ça provoque des erreurs qui ressemblent à une interférence entre les entrées adjacentes.
On recommende une impédance du circuit qui alimente les entrées analogiques de moins de 10 Kohms ( et moi j'ai 2.7Mohms )
Du coup j'ai commandé des LM324N qui vont me servir de buffers entre les circuits à base de ZMCT103C et les entrées de l'arduino.
Affaire à suivre quand j'aurai reçu mes circuits de chez ChinoisExpress.

2

JMRI et Arduino / Re : Carte 24 entrées 48 sorties pour JMRI

« le: avril 07, 2024, 02:04:43 pm »

Tu importes la librairie servo :
#include "Servo.h"

Tu crées une variable MonServo de type Servo :
Servo MonServo;

dans le setup tu l'initialises :
MonServo.attach(numeroPin);

Et pour le commander dans le loop :

MonServo.write(angle);

Attention au choix des pins : il faut des pins PWM

3

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

« le: avril 06, 2024, 09:39:25 pm »

C'est plus compliqué à calculer car on est sur un signal carré en entrée, il y a le condensateur à charger,
et la diode nous fait aussi perdre un peu.
Et surtout, il y a la linéarité du coil. Le 0.2% de linéarité dans la datasheet du zmct103c est mesuré entre 250mA et 6A et on est loin en dessous à 1.5mA pour une roue.
Du coup on est bien en dessous de la valeur calculée.

Mais bon, l'important est qu'on a des valeurs utilisables et fiables.

4

Vos projets / Re : Utilisation du laser vl53lxx

« le: avril 05, 2024, 02:32:48 pm »

Je pense que le mieux pour tes ascenseurs c'est d'utiliser un moteur pas à pas.
C'est le nombre d'impulsions qui donnera la distance parcourue.

Sinon tu peux aussi utiliser des contacts de fin de course comme ceux qu'on a sur les imprimantes 3D.

5

JMRI et Arduino / Re : Projet d'interface polyvalente pour JMRI

« le: avril 05, 2024, 12:23:50 pm »

Le système SNCF-2015 est vraiment mal configuré, incorrect et incomplet.
Je recrée donc un autre système qui utilisera les icônes de l'original mais des fichiers de configuration totalement différents.
Aspects DCC inchangés
Ajout des cibles C, E (2 versions), G (3 versions)
Suppression des TIV et autres pancartes qui n'ont rien à faire dans ces fichiers.( à part perturber le fonctionnement des BALs)
Fonctionnement prototypique des feux de manoeuvre.
Fonctionnement prototypique des ralentissements et rappels de ralentissement.
La combinaison RR30 et RR60 sur un même mât est possible mais demande un peu de logique (logix) supplémentaire.
(sans cette logique le RR30 prend le dessus)
Fonctionnement prototypique du carré qui reste fermé si la voie n'est pas réservée pour un train
(ça demande un peu de logix et ce n'est possible qu'avec des trains automatiques ou semi-automatiques)

Je ferai des tutos pour l'implantation des signaux et leur configuration dans JMRI.

En ce qui concerne l'interface :
Création automatique des mâts de signalisation dans JMRI (on doit juste mettre la liste des cibles dans le sketch du mega)
Le nom système contient la lettre de la carte et le numéro de broche de la première led pour faciliter les connexions.
J'ai fait un tableau qui donne l'ordre des leds pour chaque type de signal.
La transmission des aspects fonctionne et la carte les convertit en leds allumées/éteintes/clignotantes (il me reste à le faire pour quelques aspects et à faire le clignotement)
La carte gère aussi l'oeuilleton quand il y en a un.

6

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

« le: avril 02, 2024, 04:29:07 pm »

En fait je suis à 2.7Mohms et 470nF
Le produit des deux te donne grosso modo le temps comme tu l'as compris.

La valeur de la résistance te donne la tension en sortie par rapport au courant produit par le coil.
On a le courant de départ (par exemple 1,5mA pour une roue résistive de 10kOhms et alimentation DCC à 15V)
Il est divisé par le nombre de spires du coil (1000 pour le zmct103c)
Et multiplié par le nombre de tours passés dans le trou du coil.
Le courant multiplié par la résistance te donne la tension en sortie, donc le seuil que tu dois tester.

Le temps de retour à la voie libre va dépendre du courant. Il faut plus de temps avec une loco qu'avec une seule roue.
Le temps minimum va dépendre de la proximité du seuil par rapport au courant d'une roue.
Le temps maximum va dépendre du seuil par rapport au voltage max.
Si on veut limiter l'écart entre les deux on peut utiliser une zener avec une tension plus faible, ou réduire le nombre de tours du coil,
ou augmenter la valeur de la résistance et diminuer celle du condensateur.
Je pense qu'il faut surtout avoir un temps assez grand pour une roue de manière à réduire les libérations intempestives par faux contacts.
A noter que la résistance ne joue pas sur le temps de charge du condensateur, seulement sur le temps de décharge.

7

Vos projets / Re : Projet partagé d'un gestionnaire de réseau

« le: mars 30, 2024, 04:58:30 pm »

J'ai trouvé un truc pour les signaux de manoeuvre :

Pour les signaux qui peuvent afficher blanc et vert/jaune, on met au blanc si le signal suivant est un carré violet fermé
et au vert/jaune si c'est un autre feu.
Et on place un carré violet virtuel à chaque butoir.

Pour info, je viens de tester le coup du tiroir virtuel avec JMRI et ça fonctionne.

8

JMRI et Arduino / Re : Projet d'interface polyvalente pour JMRI

« le: mars 30, 2024, 04:51:11 pm »

Je change mon fusil d'épaule pour les feux.
Le système de départ fonctionne sauf que ça ne gère pas les clignotants ce qui pose problème, surtout
pour les R60 et RR60.
Donc le script python pour JMRI va transmettre les aspects dcc et le mega2560 fera la conversion.

Comme je le pensais les fichiers SNCF2015 de JMRI ne sont pas configurés correctement pour un fonctionnement
automatique des feux de manoeuvre.
J'ai fait les essais avec une modif de la cible D et j'obtiens un fonctionnement correct des feux de
manoeuvre.
Je vais donc clôner le système et modifier les fichiers du clône.

9

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

« le: mars 29, 2024, 04:43:37 pm »

Le lissage on est obligé de l'avoir vu que le coil sort un courant alternatif à la fréquence du DCC, donc il faut le redresser et le filtrer.
Et il n'y a pas 50 façons de le faire : il faut le faire avec un condensateur avant d'envoyer le signal à une entrée analogique ou
un comparateur.
C'est différent des protections dans les centrales qui utilisent par exemple un ACS712 mais qui sont branchées sur l'entrée
du pont en H donc sur un courant continu. Donc on peut envoyer la valeur du courant à l'entrée analogique et faire une
moyenne numérique.

Mais avec un coil on aura une sortie en dent de scie si on ne met pas de redresseur ni de condensateur. Donc les mesures
sur une entrée analogique seront variables en fonction de la phase du signal DCC au moment de la lecture.

Le circuit que j'utilise et celui de Christophe fonctionnent bien et il suffit de choisir les bonnes valeurs pour les résistances,
les condensateurs, les nombres de tours des coils et le seuil numérique.

Je pensais de Christophe ne pourrait pas faire à la fois la détection de présence et la détection de court-circuit avec
un seul coil mais il semble avoir trouvé les bonnes valeurs.

10

Vos projets / Re : Re : Re : Re : Projet partagé d'un gestionnaire de réseau

« le: mars 29, 2024, 09:50:11 am »

Un signal ne doit pas être attaché àune zone. Il doit être à la jonction de 2 zones.

Dans le programme du gestionnaire il y a des objets informatique zones, entre les zones (jonction de 2 zones) il n'y a rien, aucun objet informatique pour attacher un signal. Il faut bien attacher le signal à quelque chose.

Pierre

Oui : Une zone amont et une zone aval.
Et ça te donne automatiquement le sens du signal.

11

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

« le: mars 29, 2024, 09:46:39 am »

Pour que le circuit de Muller puisse marcher il faudrait que R23 soit de 10Mohms

Le problème des circuits utilisant un transistor comme détection de seuil c'est que le seuil n'est pas précis.

Pour donner une idée : lors de l'un de mes tests j'avais 0.3v de parasites et 0.4v avec une roue résistive.
En règlant la détection numérique pour 0.35v ça marche mais avec un transistor ça va être très sensible.

L'autre problème qu'il y a avec les circuits qui ont un seuil et une sortie digitale c'est qu'on n'a pas la
possibilité de savoir à quels niveaux sont les courants détectés, alors que dans mon circuit on peut
simplement afficher la valeur analogique lue en utilisant le moniteur de l'IDE arduino et ça permet
de voir le niveau de bruit et comparer avec les niveaux des wagons et locos.

12

Vos projets / Re : Re : Projet partagé d'un gestionnaire de réseau

« le: mars 28, 2024, 07:58:20 am »

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

C'est plus complexe que çà.

Quand tu as un simple Cv tu peux définir les blocs permissifs pour pouvoir ouvrir au blanc sur voie occupée.
Mais sur une voie principale avec un signal qui peut afficher vert ou blanc il te faut savoir si le train
manoeuvre pour prendre la décision. (d'où mon idée de voie virtuelle)

Au passage : seul un segment peut être permissif, une zone avec aiguillages ne doit pas l'être.

13

Vos projets / Re : Re : Projet partagé d'un gestionnaire de réseau

« le: mars 28, 2024, 07:16:44 am »

La liste de zones commence à la zone de départ, celle qui contient le signal de départ, puis toutes les zones d'aiguilles, pour finir sur la zone d'arrivée. Un signal doit être rattaché à une zone, dans la réalité le signal est implanté juste avant le changement de zone, avant la coupure physique des rails (si elle existe).

Pierre

Un signal ne doit pas être attaché àune zone. Il doit être à la jonction de 2 zones.
Et comme il a un sens il a une zone amont et une zone aval.

Physiquement il sera généralement un peu avant la coupure.

14

JMRI et Arduino / Re : Projet d'interface polyvalente pour JMRI

« le: mars 26, 2024, 07:19:50 pm »

Tout ce que je sais sur les arduino vient de ce site. Merci pour le partage.
Et j'espère que mes réalisations futures contribueront à aider d'autres membres.

15

JMRI et Arduino / Re : Projet d'interface polyvalente pour JMRI

« le: mars 26, 2024, 06:43:25 pm »

Un mot sur les bus de rétrosignalisation et le DCC

Historiquement le premier est le s88 de Märklin créé en 1979.
Pour ceux qui n'étaient pas nés et ceux qui ont oublié c'était l'époque des premiers ordinateurs personnels
avec des processeurs 8bits (8080, z80, 6800 et 6502) et les interfaces avec l'extérieur se limitaient à
une interface // pour une imprimante et une ou 2 interfaces série.
Märklin a donc imaginé un bus pour multiplexer les sorties de plusieurs modules vers une seule interface série,
la centrale pouvant utiliser l'autre.
Les autres fabriquants on copié le principe et ils y sont restés depuis pour garder la rétrocompatibilité avec leur clients captifs.
Il faut dire que quand un modeliste commence un réseau il en a pour 10 ans, 20 ans ou plus alors il continue longtemps
avec les mêmes circuits.
 
Mais aujourd'hui quand on commence un réseau avec de l'arduino il faut sortir de la préhistoire de l'informatique.
Le DCC par les rails a une bande passante très réduite et on n'y peut rien. Par contre on peut éviter d'y
faire passer tout et n'importe quoi. J'y fait passer les commandes du matériel roulant épicétou. ( au passage
je fais l'économie des décodeurs)

Pour le reste ça fait 25 ans qu'on a le bus USB et la carte mega peut s'y connecter à 115200 bauds "out of the box"
Chaque carte est indépendante sur son propre connecteur USB et son propre numéro de port sans avoir à se
coltiner les signaux des autres cartes. Et c'est windows qui gère les transferts.

Avec JMRI, il y a un script en python qui gère l'USB côté ordinateur et le sketch en c++ côté arduino.
J'ai pris les scripts d'entrée et de sortie de Geoff Bunza que j'ai combinés en un seul script pour gèrer
le transfert série. Ensuite j'organise les données différemment pour que le résultat soit plus facile à
utiliser en ce qui concerne la mise en relation du hardware avec les objets internes de JMRI.

JMRI est idéal pour ce résultat vu qu'il est gratuit et open source. Son seul défault est de ne pas avoir de doc
ni de forum en Français.