Messages

1

Vos projets / Re : LaBox" : Une Centrale DCC polyvalente et abordable

« le: septembre 17, 2024, 09:38:44 am »

Bonjour,

Plus de problème non plus de reboot cyclique avec la nouvelle version.

Merci.

Je ne peux pas tester plus pour le moment.

2

Vos projets / Re : LaBox" : Une Centrale DCC polyvalente et abordable

« le: septembre 12, 2024, 12:23:53 pm »

Merci Christophe,

(mon prénom est dans la signature)

J'ai continué les tests, avec ton programme et avec l'autre, sur plusieurs "boards", tous les mêmes.
Parfois ça fonctionne, parfois non.
Parfois ça fonctionne après chargement du programme, mais plus après un redémarrage.
Parfois c'est l'inverse.
Avec ton programme, la trame DCC avec Railcom semble plus stable.

J'avoue que je n'y comprends plus rien.

3

Vos projets / Re : LaBox" : Une Centrale DCC polyvalente et abordable

« le: septembre 12, 2024, 09:39:17 am »

Bonjour,

Je suis cette discussion avec intérêt depuis quelques temps car l'association RAILCOM et CAN m'intéresse pour mon futur réseau.
Je n'ai pas de hardware Labox mais j'ai voulu voir si je pouvais compiler et charger le programme dans un de mes ESP32 (ESP-32 DevKit C V4 de AZ-Delivery).

La compilation se passe bien (j'utilise PlateformIO).
Quand je teste le signal DCC avec RAILCOM sans CAN, la trame est correcte avec interruption RAILCOM.
Quand je teste le signal DCC avec CAN sans RAILCOM, la trame est correcte sans interruption RAILCOM.
Mais quand les deux sont activés, je vois passer la trame DCC (avec interruption) une fraction de seconde, puis le programme plante, l'ESP reboote, et ça recommence indéfiniment.

Le terminal affiche ceci :

Code: [Sélectionner]

09:31:44.566 > <* License GPLv3 fsf.org (c) Locoduino.org *>
09:31:44.571 > <* LaBox             : 2.6.3 *>
09:31:44.573 > <* CommandStation-EX : 5.0.9 *>
09:31:44.576 > <* LaBox Main mode. *>
09:31:44.577 > <* Pin 36 Max 2249mA (2823) *>
09:31:44.580 > <= A MAIN>
09:31:44.581 > <* new MAIN channel with pins 33 27 *>
09:31:44.585 > <* Channel 0 DCC signal for MAIN start *>
09:31:44.588 > finGuru Meditation Error: Core  1 panic'ed (LoadProhibited). Exception was unhandled.
09:31:44.596 >
09:31:44.596 > Core  1 register dump:
09:31:44.598 > PC      : 0x400ddb9f  PS      : 0x00060033  A0      : 0x800d70a9  A1      : 0x3ffbf38c 
09:31:44.607 > A2      : 0x00000000  A3      : 0x00000003  A4      : 0x000000a0  A5      : 0x00000000 
09:31:44.614 > A6      : 0x00000001  A7      : 0x003fffff  A8      : 0x0000000f  A9      : 0x00000000 
09:31:44.621 > A10     : 0x00ff0000  A11     : 0xff000000  A12     : 0x3ffc6bf0  A13     : 0x3ffc6bd0 
09:31:44.629 > A14     : 0x00000000  A15     : 0x3ffc376c  SAR     : 0x00000020  EXCCAUSE: 0x0000001c 
09:31:44.637 > EXCVADDR: 0x00000001  LBEG    : 0x00000000  LEND    : 0x00000000  LCOUNT  : 0x00000000 
09:31:44.645 > Backtrace: 0x400ddb9c:0x3ffbf38c |<-CORRUPTED
09:31:44.650 > ELF file SHA256: 4a4635deba44289e
09:31:44.767 > Rebooting...

Est-ce que ça parle à quelqu'un ?

4

Vos projets / Re : Re : Les SATELLITES AUTONOMES : Une solution simple pour la gestion de réseaux.

« le: janvier 18, 2024, 11:00:44 pm »

Le nombre d I/O sur l ESP 32 et leur utilisation rend l'utilisation du bus I2C comme une alternative à leur extension de façon simple.

Pour ma part j aime bien la SX1509 très polyvalente mais un PCA9685 offre aussi son lot de possibilités!

pour le SX1509: https://learn.sparkfun.com/tutorials/sx1509-io-expander-breakout-hookup-guide/all
ex PCA9685: https://www.aranacorp.com/fr/utilisation-dun-module-pca9685-avec-arduino/

Je suis peut-être hors sujet, mais je comprends qu'il faut augmenter le nombre d'I/O sur l'ESP32. Pour des entrées numériques, j'ai développé une carte relativement simple basée sur des registres à décalage qui permet d'ajouter au choix 8, 16, 24 ou 32 entrées.
On doit pouvoir faire de même pour des sorties. Je ne l'ai pas encore réalisée mais je l'ai testée sur des plaques de montage rapide.

5

Vos projets / Re : Re : Re : Re : Les SATELLITES AUTONOMES : Une solution simple pour la gestion de réseaux.

« le: janvier 16, 2024, 11:42:57 am »

@Dominique. Laurent répond bien à ta question. Moins on a de câbles sur le réseau et mieux c'est. Moins on a de longueur pour chaque câble et mieux.

Tout à fait d'accord, mais l'âge avançant très vite, moins on a d'équipements sous la table et mieux c'est.

6

Vos projets / Re : Re : Les SATELLITES AUTONOMES : Une solution simple pour la gestion de réseaux.

« le: janvier 15, 2024, 11:17:25 pm »

En ce qui concerne les capteurs ponctuels pour les points d’arrêt, j’ai aussi tout essayé et finalement j’ai retenu ceux-ci, optiques aussi mais simples et discrets, surtout pour l’échelle N.

Sur mon réseau (N) j'utilise des capteurs équivalents (ITR9909) mais pour les positionner au raz des traverses, ça oblige à en couper 2.
Dans les parties cachées (il n'y en a que là) ce n'est pas gênant, mais ailleurs ce serait quand même un peu voyant.

@bobyAndCo
Pour la programmation et les cartes électroniques, je me débrouille.
Le haut niveau est pour moi le suivi des trains sur le réseau par le gestionnaire.
Mon petit réseau actuel est exploité entièrement en manuel (à partir d'une tablette), à part quelques sécurités dans la gare cachée.
Mais le futur réseau est beaucoup plus ambitieux, et je n'échapperai pas à me triturer le cerveau pour comprendre comment gérer la circulation des trains.
Ce qui m'inquiète c'est la multiplication des cartes électroniques : cartes RailCom, cartes pour décoder les messages Railcom, cartes de détection de présence... Quand il y a beaucoup de cantons, ça fait beaucoup de cartes.

Tu veux des questions, en voici une.
Je comprends que la détection RailCom génère un signal relativement faible. Je suppose que les cartes doivent être proches de la voie.

7

Vos projets / Re : Les SATELLITES AUTONOMES : Une solution simple pour la gestion de réseaux.

« le: janvier 15, 2024, 01:33:31 pm »

Bonjour,

J’ai découvert les TCRT5000 (seuls) il y a déjà un petit moment, je les ai testés dans différentes configurations. Ca fonctionnait bien mais c’était très délicats de trouver le bon réglage.

Et puis j’ai testé des modules chinois tout assemblés qui me coutaient moins cher que le seul TCRT5000, très simples à régler avec la résistance variable et surtout très fiables.

Comment installes-tu ces capteurs ? Sous la voie ? Sous la plateforme ?
Tu es en HO ?

Je ne suis pas le seul intéressé mais il y a beaucoup de timides

On n'est pas timides, mais c'est du haut niveau !

8

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

« le: janvier 07, 2024, 12:42:32 pm »

Bonjour,

Une ZONE correspond à une détection de présence. Ce peut être un rail avec des coupures, une aiguille seule, plusieurs aiguilles.

Comment fait-on pour détecter une présence sur une aiguille ?
Faut-il isoler l'aiguille complètement ?
Faut-il un ou deux capteurs ?
...?

9

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

« le: janvier 04, 2024, 02:26:08 pm »

Ces périphériques n’ayant même pas de communication avec le gestionnaire ou sans doute très peu. La manette de gaz par exemple agit directement sur la centrale DCC qui en confirmant la réception de la commande, met à jour le gestionnaire.

De même pour les aiguilles, l’ordre est donné par un bouton physique ou logiciel et seul un message informe le gestionnaire du changement. Dans ce cas précis, on voit bien l’intérêt d’un interrupteur en butée de servo d’aiguille qui est le meilleur moyen de s’assurer du changement d’état.

Si le gestionnaire assure la sécurité, est-ce qu'il ne doit pas filtrer toute commande manuelle, par exemple interdire d'accélérer sur un canton au ralenti, ou interdire d'actionner une aiguille occupée par un train ?

10

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

« le: janvier 04, 2024, 10:37:45 am »

Bonjour à tous,

Je viens de lire avec grand intérêt ce lancement de projet, d'autant plus grand que j'ai en projet un nouveau réseau.
Il y a eu beaucoup de remarques pertinentes et mes connaissances "limitées" dans ce domaine ne me permettent pas de commenter.
Le seul point pour lequel j'interviens est qu'on a parlé de PC et Mac, mais il ne faut pas oublier qu'il y a PC-Windows et PC-Linux (qui est mon cas).
Je pense que s'il y a une interface sur ordinateur, elle doit être "universelle", comme un navigateur web.

11

Shields et Modules / Re : Module de détection par induction pour canton DCC

« le: février 24, 2023, 10:18:44 am »

Merci nopxor.

12

Shields et Modules / Re : Module de détection par induction pour canton DCC

« le: février 23, 2023, 07:42:12 pm »

Bonsoir,
J'ai lu tout le fil de discussion avec intérêt et je me pose une question au sujet de la remarque sur le fait que le capteur doit être proche de la voie.
Je pensait que le principe de ce capteur était de réagir à l'intensité qui passe dans le fil d'alimentation de la voie.
Or qu'on soit près ou loin de la voie, l'intensité est la même.
Donc quel est le problème de l'éloignement ?

13

Présentez vous ! / Re : Presentation de HubertGAUT

« le: octobre 05, 2022, 11:50:58 pm »

Bonjour,

les PIC ne le sont pas car leur mise en œuvre nécessite une programmation en assembleur

Quand j'utilisais des PIC, je les programmais en C .

14

Vos projets / Re : Nouveau satellite à 2 composants

« le: avril 08, 2022, 04:28:30 pm »

Je commençais tout juste à m'intéresser au bus CAN pour pallier les limitations de la communication WiFi telle que je l'ai développée pour mon petit réseau.
Cette solution ESP-NOW mérite d'être considérée même pour un grand réseau.

Merci pour ces tests.

15

Vos projets / Re : Nouveau satellite à 2 composants

« le: avril 07, 2022, 07:17:57 pm »

Bonjour Antoine,

Personnellement j'utilise un ESP8266 sur ma centrale pour recevoir les données de modules de rétro-signalisation par WiFi (position d'aiguilles, capteurs, ..) mais je crois savoir que l'ESP8266 est limité à 4 clients simultanés.
Comment gère-tu les 9 satellites simultanément ?

Cordialement,
Dominique