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 2 3 [4] 5 6 ... 57
46

Lorsque l'on associe une paire de satellites le fait de presser 1 bouton sur le premier va faire clignoter la led de celui ci.

OUI


Cet état de clignotement reste présent sur chaque satellite dont 1 bouton est pressé tant que le processus d association n'est pas achevé.

OUI


Le processus d'association bascule la led en allumage FIXE une fois le processus d'appairage achevé ET que 1 bouton sur chaque satellite reste pressé.


OUI

Elle est OFF ensuite en fois les boutons relâchés.


OUI

C est bien cela? ( elle est OFF en utilisation normale)

OUI

Si par "accident" un bouton d'appairage est pressé sans autre binôme dans le processus de découverte il n'y a pas de modification des attributions existantes?

NON

Que se passe t il si un satellite n'a pas de voisin? (soit horaire soit antihoraire) C'est le cas d'une voie en impasse par exemple.( tiroir ou gare terminus)
J'imagine que le soft gèrera le ralentissent dans la zone traitée par ce satellite et arrêtera le train une fois le capteur ponctuel horaire atteint. C'est bien cela?


OUI, s'il n'y a aucun satellite identifié à la sortie d'un canton (en fonction de la position des aiguilles éventuellement) on est dans le même cas que pour un canton occupé, le signal se met au rouge, le train frein puis s'arrête !


Pour un mouvement dans le sens de circulation opposé, y a t il des critères à avoir?


Pas comprendre la question

Tout mouvement des lors que les sécurités de "bloc automatique" sont respectées sont autorisées dans une zone d'un satellite donné?

Les commandes des trains ne suivent pas la signalisation qui n'est la que pour la décoration. Le satellite déduit des possibilités en fonctions de son environnement (position des aiguilles, occupation ou non de cantons voisins (jusqu'à +2). Ce sont ces états qui conditionnent si l'on peut appliquer tel ou tel ordre à une locomotive et qui déduisent la signalisation adéquate.

47
Tu as tout à fait raison. La prochaine version sera donc une 2.5.0 eu égard à l'importance stratégique de l'ajout !

Je suppose que ce message m'était destiné vu qu'il venait chronologiquement après mon message. Il faudrait tout de même que l'on en discute pour définir certaines choses (filtre CAN ou pas), les fonctions (DCC) sont elles suffisantes, en ai-je oublié ? La structure des messages CAN que j'ai retenue vous convient-elle ? (29 bits etc...) ?

Il faut aussi que je mette à jour le Github de Locoduino (ce que je peux faire d'ici 3 ou 4 jours) et que je teste à nouveau ce que je ne peux pas faire avant mon retour le 6 mars.

Christophe

48
A noter qu'aujourd'hui je suis le seul à proposer des améliorations sur le code. Il est pourtant gratuitement et entièrement disponible sur Github, et n'importe qui peut le prendre, le modifier, l'améliorer. Donc si toi au d'autres veulent aider, c'est tout à fait possible !

Bonjour Thierry,

Je profite de ce que tu abordes le sujet pour rappeler que j'avais proposé il y a quelque temps du code pour l'intégration du CAN dans la box. Je pense que toutes les commandes y étaient, commande de traction, de fonction, de power on/off et même le e-stop. La dernière version de ce travail date du 11/12/23 mais depuis je n'ai pas eu de nouvelles !!!

Visible sur lune branche créée ad hoc sur le GitHub de Locoduino : https://github.com/Locoduino/CommandStation-EX-LaBox/blob/CAN-messaging/CanMsg.cpp

J'avais aussi réalisé un fichier de test qui permettait de tester toutes ces fonctions et je l'avais fait sur mon réseau avec succès : https://github.com/Locoduino/Test_CommCan_LaBox

Sans réponse, je n'ai pas continué les mises à jour ce qu'il faudrait faire aujourd'hui.

Bien amicalement

Christophe

49
Bonjour et merci à tous,
je me lancerais bien dans la fabrication de quelques modules (3 ou 5) pour commencer et tester, mais il me manque encore quelques infos...
Peut-être ont-elles déjà fait l'objet de réponses, mais ou je ne les ai pas trouvées, ou je ne les ai pas comprises...

Bonjour Frédéric,

Tu trouveras ci-dessous les réponses à tes questions toujours très pertinentes.

Il y aurait dans les tuyaux ou dans les tiroirs une "V2" des satellites autonomes, mais encore en développement ?..
Et si j'ai bien compris, celle-ci, la "V1" est opérationnelle et l'on peut se lancer dans sa fabrication ?..

C’est vrai que cette « évolution » que Laurent a lancée aurait mérité un peu plus d’explications sur son positionnement et sa raison d’être. Je ne doute pas qu’il le fera sur le fil de son projet. C’est vrai que la dénomination V2 n’est pas appropriée et je ne sais d’ailleurs pas comment elle est apparue.

De ce que moi j’en comprends, il s’agit d’une version « plus musclée » qui correspondrait mieux à de plus grands réseaux (on parle de cantons de 3 mètres !!!), qui prendrait en charge plus d’équipements (plus d’aiguilles par exemple) et chercherait à améliorer ce qui pourrait éventuellement l’être dans mon projet.

Mais comme je l’ai dit, Laurent t’apportera mieux que moi ces réponses.

Pour ce qui est des satellites autonomes (pas v1), oui elle est opérationnelle, cela fait maintenant six mois environ que je la teste sur mon propre réseau.

2°/  Pour ce qui est de la commande des aiguilles adressée au satellite par le bus can, j'en ignore tout de la mise en œuvre :
J'imagine (mais j'ai peut être trop d'imagination), qu'il doit falloir insérer un nouveau nœud dans le bus qui relie déjà les satellites et les deux cartes Main et watchdog,
mais alors, si c'est bien le cas, à quoi est relié ce nœud ?..
Une carte capable de générer le message de changement de direction et de l'envoyer à la bonne adresse, ou une "manette" de pilotage reliée à la centrale qui serait capable de faire la même chose en plus des commandes destinées aux locos ?
Pour ma part, je préférerais la solution d'une carte à laquelle je pourrais envoyer un signal via un TCO physique (bouton poussoir) et qui serait capable de transmettre mes ordres aux aiguilles concernées...
Cette solution existe-t-elle ? (Au regard de toutes vos inventions, j'ai du mal à imaginer le contraire)...
Où puis-je la trouver avec ses explications, schémas, Gerber, codes, etc ?..
Locoduino est un grand bazar (au bon sens du terme), super bien achalandé, mais dans lequel j'ai encore un peu de mal à m'y retrouver...

Ce qu’il faut essentiellement avoir présent à l’esprit, c’est que les satellites autonomes privilégient la communication par le bus CAN à toutes autres forme de communication quand cela est possible. Le TCO n’échappe pas à la règle.

Donc je te redis clairement ce que j’ai dis déjà la dernière fois, les satellites reçoivent en effet les ordres de commande des aiguilles sous forme de messages CAN.

Il y a plusieurs façons d’envisager un TCO, il peut être virtuel, sur tablette ou écran ou bien physique avec de vrais boutons, de vraies leds etc… Le fait de communiquer en CAN permet au satellite autonome de répondre à toutes les formes choisies.

Puisque tu penses TCO physique, voici comment je procéderais. Les boutons de commande des aiguilles étant des boutons poussoirs répartis sur le tableau avec une lisibilité et une ergonomie maximale. Mais en tant que graphiste, tu dois savoir faire. Pour le micro contrôleur, je choisirais un Mega pour avoir d’emblée beaucoup d’entrées (boutons…) et de sorties (leds…).

Je choisirais un shield CAN (plutôt un Seeed Studio) qui fonctionne à 1Mbs : https://wiki.seeedstudio.com/CAN-BUS_Shield_V2.0/

Ce Mega avec son shield s’insèrent dans le bus CAN très simplement en reliant les fils du précédent et du suivant. Il devient de cette façon un nouveau nœud du bus CAN mais sans rien de plus.

Selon que l’on appuie sur tel ou tel bouton, le programme du Mega détecte que la commande est adressée à tel ou tel satellite et que cela concerne le servo 0, 1, 2 ou 3 du satellite. Et il allume alors la led correspondante.

Voilà, je ne veux pas faire trop long mais tu as ici le principe général pour un TCO physique. Il y en a eu un article, il y a longtemps mais c’était en xpressnet : https://www.locoduino.org/spip.php?article42

Ca peut te donner une idée.

Je suis très partant pour réaliser le programme pour un bus CAN si tu réalises la partie « physique ». Ce sera un bon sujet à partager.


3°/ Pour ce qui est de l'utilisation d'une centrale compatible RailCom®, peut-on se lancer dans la fabrication de "La Box" comme ça semblerait être proposé dans le post
"Détection RailCom© avec ESP32 (ou Arduino)" (https://www.locoduino.org/spip.php?article334) ou vaut-il mieux faire confiance au projet de Christophe,
"Une station DCC compatible RailCom" (https://forum.locoduino.org/index.php?topic=1352.0) ?..
Quelqu'un pourrait-il également m'indiquer le lien à suivre pour envisager la fabrication de la centrale idoine ?..
Une fois encore, je présume qu'il y aura un nouveau "nœud" reliant la centrale à notre bus ?..

Décidément, tu sais aborder les bons sujets !

Oui les satellites autonomes ont besoin sur le réseau d’une centrale DCC qui puisse générer un cutout. A l’heure actuelle, la Box ne dispose pas de cette faculté.

Alors, je ne parlerai pas de « confiance » pour la station que j’ai réalisée mais simplement d’option à ce stade. Oui cette station, couplée à une carte LMD18200 est la seule qui puisse être aujourd'hui utilisée avec les satellites autonomes. Mais cette station, qui fonctionne, était au départ un sujet de recherche et d’expérimentation en attendant Railcom sur la Box. Je ne souhaite pas en assurer le support ni les évolutions. Elle peut cependant être adopté en sachant qu’il faudra un jour basculer et que cela n’induit aucun cout qui ne soit réutilisable comme le LMD18200.

Dans un second temps, comme la version Railcom de DCC Ex sera disponible sur Mega (l’est peut-être déjà en Beta), je pense que ce sera une bonne évolution. Toujours avec un LMD18200

L’insertion de cette station dans le bus CAN se fera aussi simplement que montré plus haut et deviendra alors un nœud CAN également.

Et pour terminer,

4°/ Pour faire circuler les informations du can et le 12/24v, de quels câbles avons-nous besoin ?
     - RJ45 (4 paires) ou RJ12 (3 paires) ?
     - Câbles droits ou croisés ?
     - Blindés ou non ? (J'ai bien vu toutes les interventions et croisements de fers, mais je n'ai pas réussi à me faire une opinion...
     - Quelles sont les identifications de chaque fil ?

Pour tous ceux qui le souhaiteraient, je suis prêt à m'associer à une commande de PCB, avec ou sans les fournitures concernées,
pour la fabrication de 3 ou 5 cartes satellites,
la même quantité pour les cartes de détection du signal Railcom©
et 2 pcb pour la Main et la Watchdog... Et plus si affinités...

Il s’agit de câbles RJ45 de catégorie 5 ou 6. Pas de câble croisé (mais cela existe-t-il encore ?). En catégorie 5 ou 6 je crois qu’ils sont d’office blindés. C’est du basique, ce qu’il y a de plus courant et de moins cher (moins d’un €).

En utilisant ces câbles tu n’as pas de soucis d’identification des fils, sauf option particulière que je ne recommande pas mais je te donnerai alors l’identification si tu procèdes ainsi.

Comme tu es le premier à te lancer, je te propose de t’accompagner pas à pas et effectivement de faire des commandes groupées. J’allais justement envoyer une commande de PCB, je peux en mettre 5 de plus.

Par ailleurs, j’ai tous les composants en quantité et je dois envoyer une nouvelle commande (pour ce projet et d’autres).

Ce que je te propose pour tout ce qui est de nature perso, c’est d’échanger en MP.

Christophe

50
Vos projets / Re : Les SATELLITES AUTONOMES: évolutions du socle initial
« le: février 20, 2024, 03:03:43 pm »
Bonjour Laurent,

Comme je te l’ai déjà dit plusieurs fois j’ai vraiment du mal à te suivre. Tu nous présente des cartes mais dont on ne sait pas exactement ce qu’elles font et comment elles fonctionnent. Je ne sais pas faire de schémas électroniques mais je sais les comprendre.

Tu nous dit : Il sera plus simple d'en équiper les extrémités de canton plutôt que de tirer du fil d'un bout à l autre pour les sonde PT19 ou PT204.

Je ne sais pas ce qu’est un PT19 ni même un PT24.

Alors si tu ne tires pas de fils, comment exploite t’on le signal ?

Et puis tu nous dit que tout de même il faut tirer des fils, alimentation, certes mais tout de même.

Comme suggérer par Dominique, je crois qu’il faut isoler ce qui est de la recherche pure du fil du forum. Et il faut poser un peu plus les choses. Comme cette carte par exemple, je ne doute pas qu’elle soit intéressante mais elle arrive comme cela, sans prévenir. Je ne savais pas qu’il y avait un problème avec les capteurs ?

Quant à la question sur les leds ? Que puis-je te répondre si ce n’est que OUI cette led est importante. Je pense que cela se comprend à la lecture de l’article sur le processus de découverte.

Christophe

51
Vos projets / Re : Les SATELLITES AUTONOMES: évolutions du socle initial
« le: février 20, 2024, 01:44:18 am »
Laurent,

Je poursuit sur ton fil pour ne pas polluer celui de la Box. Donc je pense que tu comprends bien que le problème est côté génération du cutout, espace de quelques centaines de µs inséré dans la trame DCC.

Extrait de l'article sur Railcom : Railcom© nécessite que les trames DCC envoyées sur le réseau contiennent un « cutout », c’est-à-dire une suspension de l’alimentation d’environ 460 µs pendant laquelle le décodeur transmet un court message (généralement deux ou quatre octets) incluant son adresse. Ce cutout est réalisable assez simplement avec une centrale DCC en DIY.

Par ailleurs, il faut une carte moteur qui dispose d'une entrée break, il n'y en a pas tant que cela mais le LMD18200 en fait partie. Carte dont il faut dire au passage que les gens de DCC-Ex la trouve ringarde et obsolète. Mais je crois qu'ils n'aiment pas grand choses en dehors de ce qui sort de chez eux.

Pour les satellites, pas de problème, on changera de centrale au besoin, probablement Mega + (pour moi) shield Ethernet + LMD18200.

Pour l'instant, ma centrale fait le job, mais je ne souhaite pas faire le support, donc pour de multiples raisons, il était préférable que Railcom fonctionne avec la Box.

Ai-je bien répondu à ta préoccupation ?

Christophe

52
Vos projets / Re : LaBox : Evolutions ?
« le: février 20, 2024, 01:31:03 am »
Laurent,

Je veux être bien sûr que tu ne fais pas une confusion et c'est vrai que mon dernier post n'a pas bien précisé ce point.

Pour ce qui est des satellites, il n'y a aucun problème pour lire les informations Railcom. J'ai même, sur le même ESP32 réussi à lire (Michel précisément) les envois de 3 locomotive simultanément. Trois car il n'y a que 3 ports Série sur un ESP32.

C'est la centrale DCC qui pose problème. Elle doit envoyer, pour que la locomotive se mette en mode Railcom, un cutout à l'intérieur de la trame DCC. Rien de très compliqué en soit. Mais comme à priori DCC-Ex ne va pas plus s'engager sur la plateforme ESP32, il semble, du moins nous craignons, qu'ils ne fasse pas le job comme ils commencent à le faire sur Mega.

Mais je te redis, les satellites fonctionne parfaitement pour lire Railcom.

Christophe

53
Vos projets / Re : LaBox : Evolutions ?
« le: février 19, 2024, 07:01:44 pm »
C’est une bonne question pour laquelle la réponse est un peu complexe.

La Box s’appuie sur le noyau logiciel de DCC-EX. Les responsables de DCC-Ex jugent avec raisons que le hard de l’ESP32 (je fais court) n’apporte pas les performances qu’ils souhaitent. L’ESP32 étant un peu dirons-nous hollé hollé !

Ils sont aussi assez critiques vis-à-vis d’Espressif. Bref, il est, je crois, assez clair qu’il ne souhaitent pas investir de l’énergie là-dessus d’autant que le STM32 semble être vraiment leur chou-chou en ce moment.

Voilà ce que je comprends par exemple des déclarations de DCC-Ex et de leurs prises de position très intéressantes :

https://www.trainboard.com/highball/index.php?threads/a-simple-question-dcc-ex-esp8266.153177/

et ici sur leur site :

https://dcc-ex.com/reference/hardware/microcontrollers/microcontrollers.html#espressif-esp32-series

Par ailleurs, dans la branche devel de leur GitHub, il y a des choses concernant Railcom mais pas dans les fichiers liés à l'ESP32.

https://github.com/DCC-EX/CommandStation-EX/tree/devel

Voici une ligne du fichier de versions : // 5.2.32 - Railcom Cutout (Initial trial Mega2560 only)

Concernant ma station, je m'en suis expliqué récemment, j'ai 25 à 30% de mes trames DCC qui sont hors des recommandations NMRA. Pour DCC-Ex (hors Railcom bien sûr) 100% des trames sont dans les clous et c'est ce qu'ils visent.

J'utilise un timer réglé sur 28µs dans une fonction chargée en mémoire flash (IRAM_ATTR), solution qu'ils n'ont pas retenue, et je fais pourtant fonctionner le wifi et un serveur web en même temps. Mais mon code est beaucoup plus léger.

Christophe



54
Vos projets / Re : Les SATELLITES AUTONOMES: évolutions du socle initial
« le: février 19, 2024, 03:59:46 pm »
Hormis le futur ESP32 P4 qui doit arriver cette année et qui sera un monstre coté CPU en sacrifiant au passage le WIFI!... on reste bien dans le besoin absolu de 2 cœurs ( jusqu'à démo du contraire)

Donc tout module de type "S3" peut convenir.( ou module ESP32 " historique" à base de double cœur)

Attention, tu vas trop vite parfois. Il faut prendre un peu de temps de réflexion ou de recherches. Ou regrouper tes questions.

Tous les S3 ne sont pas double cœurs !!! Du moins je crois mais j'avoue être un peu dépassé par le rythme !!!

Bon, si, il semble bien que tous les S3 soient double cœur : https://www.espressif.com/en/products/socs

55
Vos projets / Re : Les SATELLITES AUTONOMES: évolutions du socle initial
« le: février 19, 2024, 03:47:21 pm »
Question subsidiaire:
 @Christophe: tu penses que de mettre les servos 1 et 2 sur les pins 16 et 17 du WROOM passe finalement? Tu semblais laisser entendre que non...

En fait, il ne se passe rien ! Si tu fais par exemple un digitalWrite sur l'une ou l'autre de ces deux pins, et bien rien ne changera !!!

Par contre, tu peux les utiliser pour certaines instances comme justement Serial.begin() qui peut n'avoir que le paramètre de débit comme c'est souvent le cas ou quatre paramètres comme mySerial->begin(250000, SERIAL_8N1, m_rxPin, m_txPin); pour Serial1 et Serial2 mais pas trois paramètres.

Christophe

56
Vos projets / Re : Les SATELLITES AUTONOMES: évolutions du socle initial
« le: février 19, 2024, 03:44:48 pm »
Le double cœur est primordial mais la mémoire flash ne constitue normalement pas un problème. 4Mb, c'est peu et beaucoup.

De plus il existe des moyens pour répartir la mémoire flash différemment, en prenant par exemple sur la mémoire allouée par défaut à l'OTA qui est je crois de l'ordre d'1Mb. Pas d'OTA donc, mais de toutes façons, en exploitation, le satellite autonome n'a pas de WiFi !!!

Dans ton calcul de la mémoire flash, il faudrait aussi prendre en compte les fonctions qui sont programmées pour "tourner" en mémoire flash et il y en a quelques unes dont la plus importante "void IRAM_ATTR GestionReseau::loopTask(void *pvParameters)" signalé par "IRAM_ATTR"

Evaluer cela sur ESP32 n'est pas très simple et, pour moi en tous cas, plutôt empirique et résultat de tests avec des "charges" de plus en plus importantes pour trouver les limites.

Christophe

57
Vos projets / Re : Les SATELLITES AUTONOMES: évolutions du socle initial
« le: février 19, 2024, 03:37:46 am »
Attention avec le mapping. On parle ici du WROOM. Tu ne donnes pas le bon lien qui est celui-ci :

https://lastminuteengineers.com/esp32-wroom-32-pinout-reference/

J'ai attribué GPIO17 à Railcom TX (qui ne sert pas) car elle n'est pas utilisable autrement. Pas plus que GPIO16 sans que l'on sache vraiment pourquoi mais je l'ai moi-même constaté !!!

Voir ici : https://esp32.com/viewtopic.php?t=3390

Et quand tu regardes ici : https://www.upesy.com/blogs/tutorials/esp32-pinout-reference-gpio-pins-ultimate-guide

il est bien spécifié :

16 YES YES Not available on WROVER
17 YES YES Not available on WROVER

58
Bonjour à tous,

Je viens de publier le 5° article qui commence à aborder le programme mais qui précise aussi où et comment renseigner les identifiants de votre box.

https://www.locoduino.org/spip.php?article352

Bonne lecture.

59
Vos projets / Re : Les SATELLITES AUTONOMES: évolutions du socle initial
« le: février 19, 2024, 12:01:01 am »
Ah je trouve ça super pour l'extender des 74HC. Et celui qui ne veut pas mettre de signalisation ou pas tout de suite n'est pas pénalisé.

Du coup avec la place gagnée, peux tu mettre les RJ45 sur la carte principale. Mieux selon moi pour des raisons de fiabilité de connexions.

60
Vos projets / Re : Les SATELLITES AUTONOMES: évolutions du socle initial
« le: février 18, 2024, 11:09:33 pm »
Bon tu vas vraiment me prendre pour un ch*eur mais l'avantage du RJ45 (dans la version initiale) c'est que l'on fait passer également le courant. Dans la dernière version, j'utilise 6 fils sur 8 pour cela (les 2 autres pour le CAN).

Mais bon, je donne juste mon avis !

Christophe

Pages: 1 2 3 [4] 5 6 ... 57