1
Vos projets / Re : Une manette PlayStation PS3 sans fil pour LaBox.
« le: septembre 09, 2025, 09:12:39 pm »
Joli projet. Comme quoi Labox est un programme bien extensible !
L'Arduino pour le train miniature
Nouvelles:
Le forum LOCODUINO est consacré aux discussions ayant trait à l'utilisation de l'Arduino dans les automatismes et les animations pour le train miniature. Nous avons eu récemment quelques inscriptions de personnes ayant des projets plus généraux mais surtout inapplicables au train miniature. Si votre projet ou vos questions ne concernent pas le modélisme ferroviaire, ne vous inscrivez pas, vous perdriez votre temps et nous aussi.
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.
2
Vos projets / Re : LaBox" : Une Centrale DCC polyvalente et abordable
« le: août 29, 2025, 10:16:06 pm »
C'est le PINHD 1x13 tout à gauche du schéma. On peut y connecter deux voies supplémentaires sur des broches inutilisées par l'ESP32 .
3
Vos projets / Re : LaBox" : Une Centrale DCC polyvalente et abordable
« le: août 29, 2025, 09:15:33 pm »
Il est utile de rappeler que si Labox ne dispose que d'une seule sortie DCC, elle peut servir à piloter via son port d'extension un second circuit qui ne serait équipé que de la puissance (L6203, condensateur, Leds, connecteurs alim et DCC) qui peut être connecté via son port Booster sous les emplacements des prises RJ, à une Labox bien paramétrée.
On peut ainsi aller jusqu'à une voie principale, une voie de programmation et un booster pilotés par une seule Labox et disposant de 4A maxi pour chaque voie.
On peut ainsi aller jusqu'à une voie principale, une voie de programmation et un booster pilotés par une seule Labox et disposant de 4A maxi pour chaque voie.
4
Vos projets / Re : LaBox" : Une Centrale DCC polyvalente et abordable
« le: août 25, 2025, 03:17:57 pm »
Suite aux tests et aux corrections apportées, la version 2.4.11.0 est poussée sur Github.
Pour voir la liste des modifications apportées depuis les versions précédentes, consulter version_labox.h .
Parmi ces modifications, il y a le passage à la dernière version de EX-CommandStation, la 5.4.15. Consulter version.h pour les nouveautés. En résumé; rien qui nous concerne
.
Pour voir la liste des modifications apportées depuis les versions précédentes, consulter version_labox.h .
Parmi ces modifications, il y a le passage à la dernière version de EX-CommandStation, la 5.4.15. Consulter version.h pour les nouveautés. En résumé; rien qui nous concerne
.
5
Vos projets / Re : LaBox" : Une Centrale DCC polyvalente et abordable
« le: août 25, 2025, 01:10:30 pm »
C'est quel modèle le grand écran ?
6
Vos projets / Re : LaBox" : Une Centrale DCC polyvalente et abordable
« le: août 25, 2025, 11:54:31 am »
Nouvelle version qui corrige WebThrottle et plus généralement les manettes reliées à la sortie série...
7
Vos projets / Re : LaBox" : Une Centrale DCC polyvalente et abordable
« le: août 24, 2025, 02:14:38 pm »
Super ! Modification intégrées. J'attends quelques tests supplémentaires sur le fonctionnement normal et programmation avec ou sans Railcom avant de pousser cette version 2.11.0 .
8
Vos projets / Re : LaBox" : Une Centrale DCC polyvalente et abordable
« le: août 23, 2025, 08:40:13 pm »
Ben si, parce que c'est aussi la voie de programmation qui est utilisée lorsque l'on est en pilotage normal.
9
Vos projets / Re : LaBox" : Une Centrale DCC polyvalente et abordable
« le: août 23, 2025, 06:37:07 pm »
Le problème comme je l'ai dit plus tôt, c'est que là on essaie de mettre du Railcom sur la voie de programmation, donc forcément ça change...
10
Vos projets / Re : LaBox" : Une Centrale DCC polyvalente et abordable
« le: août 23, 2025, 06:17:24 pm »
Est ce que ce ne serait pas lié au constructeur du RMT channel de programmation ?
avec une longueur de preamble plus importante ?
Code: [Sélectionner]
if (isMain) {
ch = 0;
plen = PREAMBLE_BITS_MAIN;
static_assert (DATA_LEN(MAX_PACKET_SIZE+1) + PREAMBLE_BITS_MAIN + 2 <= RMT_CHAN_PER_DCC_CHAN * SOC_RMT_MEM_WORDS_PER_CHANNEL,
"Number of DCC packet bits greater than ESP32 RMT memory available");
} else {
ch = RMT_CHAN_PER_DCC_CHAN; // number == offset
plen = PREAMBLE_BITS_PROG;
static_assert (DATA_LEN(MAX_PACKET_SIZE+1) + PREAMBLE_BITS_PROG + 2 <= RMT_CHAN_PER_DCC_CHAN * SOC_RMT_MEM_WORDS_PER_CHANNEL,
"Number of DCC packet bits greater than ESP32 RMT memory available");
}
avec une longueur de preamble plus importante ?
11
Vos projets / Re : LaBox" : Une Centrale DCC polyvalente et abordable
« le: août 23, 2025, 05:00:17 pm »
Oui tu as raison.
L'astuce utilisée dans le mode 'BASE' est de ne déclarer QUE une voie de programmation, ce qui explique les messages de lancement. Mais sur cette voie j'utilise le mode 'Joined' de EX-CommandStation pour la faire passer en mode 'Main' la plupart du temps, ce qui permet le pilotage et j'espère le Railcom. Je ne retire le 'Join' que lorsque l'on passe en mode programmation via les commandes idoines du menu.
En tout cas la version jointe devrait corriger le tir.
L'astuce utilisée dans le mode 'BASE' est de ne déclarer QUE une voie de programmation, ce qui explique les messages de lancement. Mais sur cette voie j'utilise le mode 'Joined' de EX-CommandStation pour la faire passer en mode 'Main' la plupart du temps, ce qui permet le pilotage et j'espère le Railcom. Je ne retire le 'Join' que lorsque l'on passe en mode programmation via les commandes idoines du menu.
En tout cas la version jointe devrait corriger le tir.
12
Vos projets / Re : LaBox" : Une Centrale DCC polyvalente et abordable
« le: août 23, 2025, 10:18:39 am »
Tu as bien adapté ton .ino, notamment en utilisant LABOX_BASE_MOTOR_SHIELD ? Parce que je ne vois rien dans les différences avec l'ancienne version qui pourrait affecter Railcom...
13
Vos projets / Re : LaBox" : Une Centrale DCC polyvalente et abordable
« le: août 22, 2025, 02:07:45 pm »
Bonjour à tous
Après quelques déboires, je vous ai préparé une version 2.11.0 qui devrait améliorer les choses :
- Pour une question de praticité, j'ai autorisé la définition d'une adresse IP fixe pour le Wifi. Fini de devoir se reconnecter sans arrêt sur l'app parce que l'adresse change à chaque connexion. C'est dispo aussi bien en AP qu'en STA via un routeur.
- Suite à la proposition de Lebelge2 de pouvoir fixer l'adresse d'une CV avec WiThrottle ou l'app Z21, j'ai repris l'idée en l'amendant fortement (forcément...). Il est donc possible maintenant de se servir d'une commande de vitesse et direction de loco sur une app pour fixer le numéro de CV, mais aussi sa valeur.
- Dans l'interface Sprog, l'interface Serial utilisée est définie par un define dans config.h .
- Et enfin ce que vous attendez tous, il n'y a plus de besoin de rebooter l'ESP pour lire ou écrire des CVs lorsque l'on utilise seulement la sortie DCC de Labox. J'ai tiré parti d'une possibilité de EX-CommandStation qui permet à la voie de programmation de 'rejoindre' la voie principale. Le but étant de sortir l'engin moteur de cette voie de programmation qui normalement n'autorise pas les commandes autres que la programmation. La conséquence que je n'ai pas pu mesurer concerne l'étendue des possibilités qui est peut-être réduite à cause du 'join'. Si des choses ne sont plus possibles (fonctions étendues, commandes externes sur des accessoires...), dites le moi je verrai si le vérrou peut être retiré. Pour comprendre le nouveau fonctionnement, je vous met en copie le commentaire de l'enum ProgBehavior :
La version jointe n'est pas dans Github, j'attend vos tests. Attention, le config.labox.h a changé, et le .ino aussi !
Après quelques déboires, je vous ai préparé une version 2.11.0 qui devrait améliorer les choses :
- Pour une question de praticité, j'ai autorisé la définition d'une adresse IP fixe pour le Wifi. Fini de devoir se reconnecter sans arrêt sur l'app parce que l'adresse change à chaque connexion. C'est dispo aussi bien en AP qu'en STA via un routeur.
- Suite à la proposition de Lebelge2 de pouvoir fixer l'adresse d'une CV avec WiThrottle ou l'app Z21, j'ai repris l'idée en l'amendant fortement (forcément...). Il est donc possible maintenant de se servir d'une commande de vitesse et direction de loco sur une app pour fixer le numéro de CV, mais aussi sa valeur.
- Dans l'interface Sprog, l'interface Serial utilisée est définie par un define dans config.h .
- Et enfin ce que vous attendez tous, il n'y a plus de besoin de rebooter l'ESP pour lire ou écrire des CVs lorsque l'on utilise seulement la sortie DCC de Labox. J'ai tiré parti d'une possibilité de EX-CommandStation qui permet à la voie de programmation de 'rejoindre' la voie principale. Le but étant de sortir l'engin moteur de cette voie de programmation qui normalement n'autorise pas les commandes autres que la programmation. La conséquence que je n'ai pas pu mesurer concerne l'étendue des possibilités qui est peut-être réduite à cause du 'join'. Si des choses ne sont plus possibles (fonctions étendues, commandes externes sur des accessoires...), dites le moi je verrai si le vérrou peut être retiré. Pour comprendre le nouveau fonctionnement, je vous met en copie le commentaire de l'enum ProgBehavior :
Code: [Sélectionner]
/*
According to the kind of track configuration, there is 3 possible behaviors :
- The base configuration is a prog track only, which joins the main track for normal operations.
In that case, the program behavior is "joining". This is the default configuration.
- If there is a Main track and boosters, the program behavior is "rebooting" the system to change
the configuration. This does not always work with Railcom.
- If there is a Main and a Prog track, the program behavior is "normal".
A Main track only configuration is not anymore necessary, as the prog track can join the main track.
Name Config main prog
Prog only NULL PROG NULL NULL joined unjoined
Main only MAIN NULL NULL NULL reboot (not railcom) reboot
Main+boosts MAIN NULL BOOST1 BOOST2 reboot (not railcom) reboot
Both MAIN PROG NULL NULL normal normal
Both+boost MAIN PROG BOOST NULL normal normal
*/
Le seul cas litigieux concerne l'usage de boosters sans voie de programmation. Ce mode réclame encore de rebooter (c'est géré), mais ça ne marche pas toujours... Le seule solution reste de rebooter physiquement l'ESP.La version jointe n'est pas dans Github, j'attend vos tests. Attention, le config.labox.h a changé, et le .ino aussi !
14
Vos projets / Re : Re : LaBox" : Une Centrale DCC polyvalente et abordable
« le: août 19, 2025, 10:47:37 am »2) Réutilisé la variable dp_rc comme sur la version précédente (+/- ligne 151)
Je l'ai retirée parce qu'elle me semblait inutilisée... Quel est son rôle ?
15
Vos projets / Re : LaBox" : Une Centrale DCC polyvalente et abordable
« le: août 19, 2025, 10:44:04 am »
La correction demandée répondait seulement au second point de problème, soit le fonctionnement normal de Labox en version sans Railcom.
Pour le reboot avec Railcom, je n'ai pas trouvé, je continue de chercher.
Ce que je sais :
- Esp.restart qui est utilisé pour redémarrer l'ESP ne fait pas un reset complet, dixit le commentaire dans le fichier .h de la fonction :
ce qui explique qu'un reset au bouton corrige le problème.
- J'ai construit des fonctions end() pour à peu près tout pour clôturer WIFI, RMT, HMI, les Tracks, l'EEPROM, la liaison série, et d'autres choses que j'oublie, plus un délai de 6 secondes nécessaires d'après plusieurs sources avant de lancer le restart mais ça ne corrige pas le problème.
- Selon les évolutions que je fais subir à mon code, j'ai des messages type WatchDog sur CPU1 qui semblerait lié à la routine d'interruption de Railcom, ou des plantages francs dès l'appel de la réinitialisation de Railcom par RailcomBegin().
- Mes tentatives de débrancher cette interruption avant le restart ne fonctionnent pas...
Pour le reboot avec Railcom, je n'ai pas trouvé, je continue de chercher.
Ce que je sais :
- Esp.restart qui est utilisé pour redémarrer l'ESP ne fait pas un reset complet, dixit le commentaire dans le fichier .h de la fonction :
Code: [Sélectionner]
/**
* @brief Restart PRO and APP CPUs.
*
* This function can be called both from PRO and APP CPUs.
* After successful restart, CPU reset reason will be SW_CPU_RESET.
* Peripherals (except for WiFi, BT, UART0, SPI1, and legacy timers) are not reset.
* This function does not return.
*/
void esp_restart(void) __attribute__ ((noreturn));
ce qui explique qu'un reset au bouton corrige le problème.
- J'ai construit des fonctions end() pour à peu près tout pour clôturer WIFI, RMT, HMI, les Tracks, l'EEPROM, la liaison série, et d'autres choses que j'oublie, plus un délai de 6 secondes nécessaires d'après plusieurs sources avant de lancer le restart mais ça ne corrige pas le problème.
- Selon les évolutions que je fais subir à mon code, j'ai des messages type WatchDog sur CPU1 qui semblerait lié à la routine d'interruption de Railcom, ou des plantages francs dès l'appel de la réinitialisation de Railcom par RailcomBegin().
- Mes tentatives de débrancher cette interruption avant le restart ne fonctionnent pas...