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 - bobyAndCo

Pages: 1 ... 7 8 [9] 10 11 ... 59
121
Présentez vous ! / Re : Hello!
« le: février 14, 2024, 12:31:24 am »
Hello Joel and welcome to Locoduino.

I think you'll find something here to satisfy your interest in DIY and Arduino in general.

What country are you from?

You mentioned in another post that you've made the Railcom boards and are running them successfully, I'm glad.

Do you have any photos of your layout?

For your questions about components, Catplus (Marcel), with whom I worked on this project and who is more of a specialist than I am, will get back to you without delay.

Christophe

122
Bonjour Marcel,

Eh bien, les grands esprits se rencontrent. Je me faisais exactement la même réflexion quand tu as envoyé ce message. J'avais déjà rappelé le montage d'Eric qui fonctionne : https://forum.locoduino.org/index.php?topic=489

et qui utilise le circuit de Paisley dont tu parles justement.

Néanmoins, je voudrais aller un peu plus loin (mais le montage d'Eric n'est pas pour autant remis en cause). Sur la même carte, je voudrai que l'on puisse sortir deux signaux numériques (pa analogiques) pour libérer l'ESP32 du traitement. Ca peut être des ATtinny (c'est toi d'ailleurs qui avait eu cette idée je crois) qui font le job ou un transistor avec un réglage de sensibilité possible. A voir.

Mais effectivement, autant s'appuyer au départ sur quelque chose qui fonctionne comme tu le rappelles.

Christophe.

123
Railcom me semble être une évolution majeure dans la gestion d'un réseau. Je pense que toutes les solutions actuelles avec les suivis de trains sur les logiciels n'auraient pas été conçues de la sorte si  Railcom avait été présent dès le début.

Oui c'est vrai que Railcom est vraiment la meilleure solution selon moi. J'ai maintenant un peu plus d'une année de recul avec une utilisation intensive pour la mise au point des satellites et vraiment, je lui trouve de plus en plus de qualités.

J'avais envisagé au départ faire cohabiter RFID et Railcom dans les satellites. Mais outre le fait que le RFID nécessite un peu plus d'infrastructure (perçage du plan, plus de fils, tag sous la loco...) j'ai été par exemple confronté au fait que l'on doit attendre de passer sur le capteur qui est souvent en milieu de canton pour une voie à double sens. C'est trop long pour le cas où il faut un ralentissement. Reste aussi que le RFID décroche si la vitesse du train est trop rapide.

Ca reste une bonne solution si on les place à des points stratégiques comme l'a fait Dominique (entrée ou sortie de gare par exemple) mais on n'aura pas une reconnaissance sur chaque canton comme Railcom sauf à mettre un suivi logiciel des trains ce qui n'est pas très compliqué avec les satellites autonomes.

même si je trouve un peu compliqué d'avoir une carte par canton

C'est vrai qu'on peut le voir comme cela. Maintenant, quand je vois finalement le nombre de choses que l'on peut faire (que l'on doit faire), je me dis que ce n'est pas superflus. Tu as peut-être vu que je cherche maintenant à faire une détection locale de trains mais aussi de wagons et aussi une gestion locale des courts-circuits, alors oui ça peut sembler beaucoup. A chacun de peser le pour et le contre.

Il y a d'autres approches j'en suis convaincu. Je n'ai pas prétendu que cette version serait un point final. J'ai compris dès le départ, et j'ai été conforté au fur et à mesure que j'écrivais le code, que le concept est loin d'être bridé. Je pense par exemple à une gare cachée avec de nombreuses aiguilles et je pense que le concept est bien adapté.

Merci de nous tenir informé de tes avancées.

PS : Si vraiment tu veux Railcom sur le hard de la Box, je l'ai développé mais on n'a pas toutes les fonctions de la Box (Lecture et programmation de cv's, écran LCD...) mais pour faire des tests.

Pour Railcom sur la Box, tu as peut être vu mon post suite à la récente publication de Thierry. Sur ESP32, je suis loin d'être aussi optimiste que lui. Aux vues des avancées de développements, je pense sur Mega dans un premier temps et STM32 rapidement ensuite.

Christophe

124

    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

    125
    Quand je disais que j'ai pas mal recherché, j'ai en particulier consulté toutes les sources citées par Sudima Crossing dont je crois personne ne met en doute le sérieux :
     http://www.sumidacrossing.org/LayoutControl/TrainDetection/InductiveDetectionCircuit/

    Il a lui même regardé l'ensemble de ce qui se faisait (je crois qui parle même du travail du MERG !)

    Tous arrivent à la conclusion qu'en pratique, il utilisent maintenant des bobines de 50, 100 ou maximum 200 tours pour le NCE BD20 qui est l'une des références dans la matière mais un produit commercial.

    Je joins l'un des documents qui me semble le plus complet, que l'on peut traduire avec Google traduction : http://dcc-mueller.de/wire4dcc/sensor_e.htm

    Christophe



    126
    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.

    Pour la détection de courants faibles, il ne faut pas penser une seule minute aux 1000 tours. Même si l'on fait 2 tours de la bobine, cela fait un rapport de réduction de 500... sur 10 à 20mv, je ne cherche même pas à compter !

    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 moi c'est un état 0 ou 1 une occupation ou non. Du prêt à consommer par un ESP32 par exemple en digital.

    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)

    Oui je penche aussi pour cette solution, et au final produire une carte uniquement pour la détection (avec ses propres réglages de sensibilité) et qui le fait bien. Carte qui peut être utilisée hors satellites d'ailleurs et, pour les satellites, enfichable !!! Le cout des composants n'est tout de même pas important.

    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.

    Il faut rester en 5V pour avoir les meilleures performances de l'ATtiny. Pas très compliqué de communiquer 5v / 3,3v par opto ou autres

    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

    Voila une bonne conclusion.

    J'espère que nos spécialiste de l'électronique nous donnerons leus avis !!!

    Christophe

    127
    Hello Christophe

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

    Salut Laurent,

    Désolé, j'avais zappé ce message. Le bon mapping est celui qui est en bas de la page : https://www.locoduino.org/spip.php?article349

    Il a évolué hier encore pour la pin 33 (lecture de courant). C'est LE sujet sur lequel je travail totalement en cemoment et je vais te poser un certain nombre de question sur le fil "Détection par consommation avec des courants faibles" : https://forum.locoduino.org/index.php?topic=1656

    128
    Bonjour à tous,

    J’ai beaucoup, beaucoup lu et potaché sur le sujet de la détection de courant et cela m’occupe pratiquement tout mon temps actuellement.

    Il faut dire que le sujet est important et je dois avouer (sans jeu de mot) que je n’ai pas totalement pris la mesure des enjeux et des difficultés.

    Il me faut la détection de courants faibles pour savoir si le canton est occupé par des wagons qui ne l’on pas encore quitté ou qui se sont décrochés ou encore si le convoi est « poussé ».

    La seule chose dont je sois à peu près certain c’est qu’il faut une détection de présence par consommation de courant à base de Transformateurs de courant. Le seul système (je crois) vraiment capable de retourner des valeurs faibles de l’ordre de 10 à 50mA (essieu de wagon avec résistance de 10 à 18 KΩ

    Mais il faut pour cela une bobine à 50 tours : https://www.mouser.fr/ProductDetail/580-56050C

    Je me pose aussi la question de savoir s’il faut confier la conversion AC/DC à l’ESP32, qui n’est pas excellent dans ce domaine mais ce n’est pas la vraie question. La vraie question est le temps de traitement surtout si on applique un smoothing ce qui me semble absolument nécessaire.

    Du coup, c’est Laurent qui m’a mis la puce à l’oreille, pourquoi ne pas utiliser un Attiny pour cela qui fera bien le job, dans son coin, sans gêner personne et qui adresserait sur l’une de ses pins en sortie un bit 1 ou 0 (busy or not) beaucoup plus efficace pour la charge de l’ESP32.

    A la réflexion, je crois également que ce serait une très bonne chose que chaque satellite puisse assurer sa propre gestion des court-circuits sur son canton. Du coup, plein d’autres questions. Avec la même bobine et le même Attiny, pas idiot je pense et faire commuter un relais en cas de dépassement de seuil.

    Est-il nécessaire de prévoir un autre dispositif pour les CC (ACS712) avec son propre Attiny ???

    Mais il y aura certainement des ajustements à prévoir pour les réglages. Je doute que toutes les sections réagissent avec les mêmes réglages avec par exemple la même résistance sur les wagon. Il y a fort à parier que la longueur du tronçon, l’environnement etc influent spécifiquement.

    Voilà un vaste sujet qui dépasse largement le cadre des satellites et pour lequel j’attend des réactions et des conseils (de préférence avisés).

    Christophe


    129
    Vos projets / Re : TCO bp + ordi
    « le: février 12, 2024, 06:42:39 pm »
    Bon je n'ai pas eu à chercher longtemps. Le programme joint n'est pas encore celui auquel je pensais mais il va sans doute t'intéresser encore plus (pour le moment). Je reconnais que le programme est un peu compliqué mais il fonctionne. Tu pourras faire ce que tu voulais et puis, on pourra en discuter.

    Ce programme répondait à la même demande que toi de piloter et régler les servos à partir de l'interface série de l'IDE Arduino

    Ce programme permet de piloter 6 servos (mais 16 serait possible sur un Mega).

    Pour le faire fonctionner, il faut dézipper et placer le dossier (avec les 3 fichiers) dans ton dossier Arduino.

    Dans le fichier Servo_Aiguilles.ino, il faut tout d'abord choisir combien d'aiguilles on veut piloter. Ici on a mis 6 : #define NB_SERVO 6

    Ensuite il faut indiquer sur quelles pins sont reliés les servos :

    // Setup de chaque instance
    // id, servoPin, togPinAig, ledPinAig, minPosition, maxPosition, (dirAig)
      aiguille[0].setup(0, 2, 31, 40, position[0], position[1], 0);
      aiguille[1].setup(1, 3, 33, 42, position[2], position[3], 0);
      aiguille[2].setup(2, 4, 35, 44, position[4], position[5], 0);
      aiguille[3].setup(3, 5, 37, 46, position[6], position[7], 0);
      aiguille[4].setup(4, 6, 39, 48, position[8], position[9], 1);
      aiguille[5].setup(5, 11, 41, 50, position[10], position[11], 0);

    Par exemple :

    aiguille[0].setup(0, 2
    2 est le numéro de broche
    aiguille[1].setup(1, 3
    3 est le n° de broche

    Si tu peux, garde le même brochage comme cela il n'y aura rien à modifier

    Et il n'y a rien d'autre à modifier.

    Maintenant comment ça marche ?

    Quand le programme est lancé, il faut saisir des codes dans la barre du moniteur série de l'IDE Arduino :

    - On commence par entrer le n° du servo que l'on veut régler (0, 1, 2...)
    - va faire reculer le servo (très peu !), il faut donc appuyer plusieurs fois pour vraiment le voir bouger
    + va faire avancer le servo (très peu !)
    s enregistre en EEPROM
    w affiche à l'écran les réglages de tous les servos

    Bon je n'ai pas beaucoup le temps là mais ensuite je te montrerai comment on fera pour actionner les différents servos à partir des réglages appliqués.

    Et bien sûr ensuite avec des Boutons Poussoirs.

    Christophe

    130
    Vos projets / Re : TCO bp + ordi
    « le: février 12, 2024, 05:47:36 pm »
    Je pense que actionner les aiguilles avec des boutons poussoirs est une première étape. En programmation, si le code est bien écrit au départ, il n'est en générale pas trop compliqué d'ajouter des fonctionnalités.

    Combien y a t'il d'aiguilles ? Ce sont des servomoteurs de mémoire ?

    Sur quelle carte ? Uno, Mega, Nano ?

    Il y a déjà eu plein de choses sur le même sujet dans le forum et en article, fais des recherches !

    Je ne suis pas certain que le PCA9685 se justifie, j'avais fait un programme pour 16 aiguilles avec mouvement lent des aiguilles sur un autre forum et ça marchait nickel. Je vais rechercher dans l'après-midi.

    Mais fais vraiment des recherche sur le site éditorial et sur le forum avec "aiguillage" "servomoteurs" etc... Tu ne vas pas perdre ton temps de toutes façons

    Christophe

    131
    Vos projets / Re : Re : Re : TCO bp + ordi
    « le: février 12, 2024, 04:26:52 pm »
    Mais tu parles maintenant de te lancer avec Processing qui est beaucoup plus difficile à appréhender encore que la programmation Arduino où tout a été fait pour que ce soit très simple à utiliser. Libre à toi mais tu ne trouveras pas grand monde alors pour t'aider.
    Processing c'est comme Arduino, tout a été fait pour que ce soit simple à utiliser, mais pour un autre domaine, celui du dessin et de l'animation 2D et 3D.

    Pierre

    A la bonne heure Frédérique, puisque Processing est si simple tu as eu bien raison d'y penser... et j'ai bien eu tort de t'en dissuader.

    Christophe

    132
    Vos projets / Re : TCO bp + ordi
    « le: février 12, 2024, 02:50:51 pm »
    Frederic,

    Si je peux me permettre un conseil, tu cherches à aller trop vite sans maîtriser les fondamentaux. On ne le répétera jamais assez, il faut commencer par la commencement et sur Locoduino, il est ici : https://www.locoduino.org/spip.php?id_mot=26&page=theme

    Compte tenu de l'erreur que je t'ai corrigée, on voit bien il s'agissait d'un bout de code que tu as copié sur internet avec d'autres bouts de code. Résultat, ça ne fonctionne pas mais tu ne sais pas pourquoi.

    Le programme que tu as présenté est tout bringbalant mais pourrait fonctionner sans trop de difficultés après quelques corrections.

    Mais tu parles maintenant de te lancer avec Processing qui est beaucoup plus difficile à appréhender encore que la programmation Arduino où tout a été fait pour que ce soit très simple à utiliser. Libre à toi mais tu ne trouveras pas grand monde alors pour t'aider.

    Bien cordialement.

    Christophe

    133
    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

    134
    Bus CAN / Re : Mes débuts en CAN, entre déboires et réussite...
    « le: février 11, 2024, 05:05:16 pm »
    Je me suis décidé à écrire ce fil après avoir vraiment rencontré pas mal de difficulté à mettre en place un réseau CAN qui fonctionne. (et ce n'est pas encore tout à fait le cas...)

    J'avais trouvé cet article qui me semble intéressant car il est, je trouve, assez compréhensible pour un non initié et pas superficiel.

    C'est juste une proposition : https://www-kvaser-com.translate.goog/can-protocol-tutorial/?_x_tr_sl=en&_x_tr_tl=fr&_x_tr_hl=fr&_x_tr_pto=rq#:~:text=The%20message%20arbitration%20(the%20process,has%20detected%20an%20idle%20bus

    135
    Bus CAN / Re : Mes débuts en CAN, entre déboires et réussite...
    « le: février 11, 2024, 03:50:44 am »
    Et deux photos en prime.

    Photo pcb vert : Avec Ethernet (monté)
    Photo pcb rouge : Avec Ethernet (non monté) et DCC Inspector (monté)

    Pages: 1 ... 7 8 [9] 10 11 ... 59