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.

Sujets - bobyAndCo

Pages: [1] 2

Bus DCC / EX-DCCInspector

« le: septembre 28, 2023, 11:25:42 am »

Bonjour à tous,

Catplus et moi travaillons sur un projet qui nécessite de « sniffer » les trames DCC envoyées sur un réseau. En précisant que nous souhaitons utiliser l’ESP32 comme plateforme.

EX-DCCInspector semble faire l’unanimité pour le job. Il en est plusieurs fois question sur le forum mais rien pour en parler de manière un peu exhaustive. C’est l’ambition de ce fil.

Tout d’abord, la page traitant de EX-DCCInspector se trouve ici : https://dcc-ex.com/ex-dccinspector/index.html#gsc.tab=0

Il y a deux manières de se procurer le fichier, soit en téléchargeant un fichier .zip, soit sur le GitHub.

J’ai rencontré plusieurs problèmes :

1° - Le scketch ne compile pas avec une version de l’IDE Arduino inférieure à 2.0
2° - J’essaye alors avec PlatformIO et je rencontre aussi un problème à la compilation.

Avec l’IDE Arduino, la solution a été d’installer la dernière version, pour moi la 2.2.2 (au 28 sept 2023)

Avec PlatformIO, les fonctions doivent être déclarées avant leur première utilisation. Or plusieurs fonctions utilisées dans le loop() sont définie après dans le code.

J’ai donc ajouté le prototype des fonctions juste avant le setup() et ça fonctionne.

Code: [Sélectionner]

void clearHashList();
bool processCommands();
void UpdateLED();
void DecodePacket(Print &, int, bool);
bool processDCC(Print &);

void setup() {

Pour utilisation avec un ESP32, il vous faut renseigner le réseau WiFi utilisé ainsi que son mot de passe dans le fichier Config.h

Code: [Sélectionner]

#define WIFI_SSID "myssid"
#define WIFI_PASSWORD "mypassword"

Nous commentons la ligne

Code: [Sélectionner]

//#define USE_OLED car nos n(utiliserons pas d’écran OLED.

En contrepartie, l’ESP32 autorise l’affichage des données dans un navigateur web à l’adresse http://DccInspector.local/

Voilà quelques précisions pour pouvoir utiliser EX-DCCInspector sur un ESP32 avec visualisation des données dans une page web.

Vie du forum / Il y a des jours où chatGPT est fatigué ! Ou quand c'est nous qui faisons le taf

« le: juin 23, 2023, 12:47:50 pm »

J'utilise assez souvent chatGPT pour avoir un retour sur du code que j'ai pu écrire et je dois avouer que souvent, je trouve des suggestions intéressantes. Mais alors ce matin, je lui ai soumis un vieux code (2012) qui n'incorporait pas des évolutions intéressantes de C++ 11 comme les listes d'initialisation par exemple. Voici le texte de nos échanges (sans le code que je pourrais poster si cela vous semble intéressant). C'est assez éloquent :

Moi
Bonjour Chat

ChatGPT
Bonjour! Comment puis-je vous aider aujourd'hui?

User
Dis moi comment tu écrirais ceci en C++ moderne ?

ChatGPT
Voici le code en C++ moderne pour la classe TrackController que vous avez fournie :

Ce code utilise les fonctionnalités du langage C++ moderne, telles que l'initialisation de membres dans la liste d'initialisation du constructeur (mHash(hash), mDebug(debug), etc.), ainsi que l'inclusion de la bibliothèque Arduino (<Arduino.h>) pour utiliser Serial.println(F(...)) avec la macro F() pour économiser de la mémoire.

User
Je suis d'accord avec toi qu'il faut utiliser des listes d'initialisation mais tu ne le fais pas !

ChatGPT
Je m'excuse pour l'omission dans ma réponse précédente. Vous avez raison, il est préférable d'utiliser des listes d'initialisation pour initialiser les membres de la classe. Voici le code mis à jour en utilisant des listes d'initialisation :

Dans ce code mis à jour, les membres mHash, mDebug, mLoopback et mGbxBoot sont initialisés dans les listes d'initialisation des constructeurs correspondants, plutôt que d'être assignés dans le corps du constructeur init(). Cela améliore l'efficacité et la lisibilité du code.

User
tu dois être fatigué aujourd'hui car la fonction init n'est plus nécessaire : void init(word hash, boolean debug, boolean loopback, boolean gbxBoot) {
mHash = hash;
mDebug = debug;
mLoopback = loopback;
mGbxBoot = gbxBoot;
}

ChatGPT
Je m'excuse pour la confusion précédente. Vous avez tout à fait raison, la fonction init() n'est plus nécessaire puisque nous pouvons initialiser directement les membres dans les listes d'initialisation des constructeurs. Voici le code mis à jour sans la fonction init() :

Je m'excuse à nouveau pour l'erreur précédente et je vous remercie de votre patience. Le code ci-dessus initialise maintenant directement les membres dans les listes d'initialisation des constructeurs, sans avoir besoin de la fonction init().

User
Je me demande si je peux te faire confiance

ChatGPT
Je comprends que mes erreurs précédentes ont semé le doute. En tant qu'IA, je m'efforce de fournir des réponses précises et fiables, mais il peut arriver que des erreurs se produisent. Je suis constamment en apprentissage et j'essaie d'améliorer mes performances.

Je vous recommande de toujours vérifier les réponses que je vous donne et d'utiliser votre propre jugement et connaissance pour prendre des décisions. N'hésitez pas à poser des questions de suivi ou à demander des éclaircissements si quelque chose ne semble pas correct.

Mon objectif est de vous aider du mieux possible, et je ferai de mon mieux pour répondre à vos demandes.

Bus CAN / Pénurie de MCP2562

« le: août 01, 2022, 07:56:09 am »

Bonjour à tous,

Comme il est écrit dans le titre du sujet, il y a depuis quelques semaines une pénurie sur les approvisionnements des petits MCP2562, transceiver bien pratiques et économiques sur nos montages à base d'ESP32 entre autres.

Quelqu'un a t'il une proposition d'approvisionnement (fiable et économique) ou une solution de remplacement ? Plus particulièrement en montage traversant.

Merci par avance

Discussions ouvertes / Economies d'énergie !

« le: mars 12, 2022, 10:12:57 am »

La SNCF ne manque pas d'humour ! Du coup, je me suis adapté et j'ai réduit l'intensité sur mon réseau de 12 à 9 volts Et les vaches vont à nouveau pouvoir contempler les trains.

Bus DCC / Une station DCC compatible RailCom

« le: janvier 09, 2022, 02:58:44 pm »

Bonjour à tous,

Ce nouveau fil pour la réalisation d’une centrale DCC compatible RailCom (oui je sais c’est déjà dans le titre).

Pour beaucoup de modélistes ferroviaires et en particulier à Locoduino, la découverte de DCC++ a été une véritable révélation. Que son concepteur Gregg E. Berman en soit une fois une nouvelle fois ici remercié.

Mais au fil des ans, DCC++ a montré ses limites. A Locoduino, Thierry en particulier, nous avons beaucoup travaillé à y apporter des améliorations. Ainsi est né par exemple DCCpp écrit sur la base de classes C++ rendant la programmation de base universelle et donc les utilisations potentielles plus larges et simplifiées.

Le projet La Box sur base d’ESP32 est aussi l’une de ces évolutions.

Récemment, à l’occasion de la sortie de la seconde édition du livre de Pascal Barlier, nous avons découvert une nouvelle centrale (non plus sur base de DCC++) mais qui m’a tout de suite intéressée car elle promet de permettre la détection RailCom (qui est aussi absente dans DCC++).

La licence GNU autorisant la modification et la publication du code modifié, j’ai souhaité « élargir » les utilisations de cette nouvelle centrale pour pouvoir la rendre compatible avec les multiples applications open source que nous avons développées ou adoptées autour de DCC++ comme JMRI par exemple.

L’objectif étant de pouvoir bénéficier à terme de la détection RailCom sans avoir à remettre en cause ces différentes configurations existantes.

Je mets en téléchargement un programme de test mais opérationnel qui permet de réaliser une station sur Arduino avec un LMD18200 (dans cet exemple) et qui peut (pour l’instant) être pilotée par le port série par JMRI par exemple mais aussi par toute application capable d’envoyer de informations par le port série.

Toujours pour des raisons de compatibilité, j’ai adopté le protocole de communication de DCC++ tellement connu du type <t 1 12 100 1>. Reportez-vous à l'entête du fichier principal plus d'informations.

L’ambition à ce stade du projet que je soumets n’est autre que de tester le retour d’information RailCom au travers des détecteurs également conçus par Pascal Barlier. Les PCB sont en fabrication et quelques uns d’entre nous se sont déjà proposés pour les tester.

L’autre espoir que j’ai est que la lecture et l’écriture des CVs soient améliorées par rapport à DCC++. Mais ce sera pour plus tard.

Si donc vous utilisez DCC++ et que vous souhaitez en plus pouvoir profiter de la détection RailCom, ce fil devrait vous intéresser et nous comptons sur vous pour nous aider à améliorer le projet.

Bien cordialement

Christophe

Trucs & astuces / La fonction printf() en Arduino

« le: décembre 31, 2021, 06:31:51 pm »

Bonjour à tous,

Pour bien terminer l’année, je vous propose la petite astuce suivante : Tous ceux qui connaissent la fonction printf() en langage C sont sans doute frustrés comme je l’étais qu’elle ne soit pas disponible dans le langage Arduino.

Je précise rapidement que la fonction printf() correspond à la fonction Serial.print() de l’Arduino mais offre l’avantage de pouvoir inclure en même temps que du texte, des variables dans les paramètres.

Voici un exemple simple : si vous souhaitez écrire un texte plus la valeur de i dans la boucle ci-dessous, vous devrez appeler deux fois la fonction Serial.print() (ou Serial.println() pour avoir un retour à la ligne).

Code: [Sélectionner]

for(byte i = 0; i < 10; i++) {
  Serial.print("La valeur de i est ");
  Serial.print(i);
}

Avec la fonction printf, le code devient :

Code: [Sélectionner]

for(byte i = 0; i < 10; i++) {
  printf("La valeur de %d est ", i);
}

C’est plus compact et avec l’habitude, plus facile à écrire d’autant que l’on peut placer plusieurs variables sur une seule ligne comme nous le verrons dans l’exemple suivant.

J’ai repris pour l'essentiel un code que j’ai trouvé sur internet mais que j’ai placé dans un fichier distinct pour qu’il ne vienne pas « polluer » le code du fichier principal (.ino)

Il suffit donc d’ajouter un nouvel onglet dans l’IDE Arduino, d’appeler ce fichier « Printf.h » et de copier le code suivant :

Code: [Sélectionner]

#ifndef printf_h
#define printf_h

// Define a file descriptor for the serial output:
static FILE uartout = { 0 };

// Declare our put-character function:
static int uart_putchar (char c, FILE *stream);

// My char output function
static int uart_putchar (char c, FILE *stream) {
  if ( c == '\n' )
    Serial.write('\r');
  Serial.write(c) ;
  return 0 ;
}

struct Printf {
  static void begin(long);
};

void Printf::begin(long baud) {
   // Fill in UART file descriptor with pointer to my char-out func.
  fdev_setup_stream(&uartout, uart_putchar, NULL, _FDEV_SETUP_WRITE);
  stdout = &uartout;
  Serial.begin(baud);
}

#endif

Dans le fichier principal (.ino), il faut tout d’abord ajouter le lien #include "Printf.h" et dans le setup() placer Printf::begin(xxxxxx); au lieu du traditionnel Serial.begin(xxxxxx) ;

Enfin, je vous donne un exemple complet. Pour l’utilisation optimale de cette fonction printf(), je vous renvoie au nombreux tutos d’internet comme celui-ci : https://www.gladir.com/CODER/C/printf.htm

Code: [Sélectionner]

#include "Printf.h"

void setup() {

  Printf::begin(115200);
  printf("Hello world\n");
}

void loop( void ) {
  long compt = 0;
  for (byte i = 'A'; i <= 'z'; i++) {
    compt++;
    printf("Le code ASCII de %c est %d et le nombre de caractères lus est %ld\n", i, i, compt);
    delay(1000);
  }
}

Trucs & astuces / Continuité de l’alimentation en courant des locomotives.

« le: avril 16, 2021, 01:17:08 pm »

Bonjour à tous.

J’ai ouvert ce nouveau fil pour, je l’espère, que de nombreux contributeurs puissent apporter leur point de vue et leur expérience sur un sujet important pour notre hobby à savoir la continuité de l’alimentation en courant des locomotives.

Quoi de plus désagréable que le convoi qui s’arrête au passage d’une aiguille ou le petit locotracteur qui peine à avancer correctement parce que sa prise de courant est insatisfaisante.

Je sais que de nombreuses « écoles » défendent des points de vue souvent très différents et c’est justement pour cela que l’exercice est intéressant et instructif si chacun peut présenter ses choix tout en acceptant ceux des autres pour arriver à un résultat constructif.

L’objectif visé au final est qu’un modéliste néophyte puisse avoir une vision globale et éclairée du sujet et puisse ensuite appliquer ses propres solutions en fonction de sa sensibilité, ses compétences et son budget.

Alors on entend beaucoup que, si les rails sont propres, si les roues des locomotives sont nettoyées, si les cœurs d’aiguilles sont alimentés, si chaque tronçon est lui aussi alimenté… alors tout se passe bien.

Personnellement, je pense qu’il y a là de nombreuses vérités, mais que de nouvelles solutions techniques se font jour qui s’ajoutent à cela avec bénéfice.

Tout ceux qui ont pu voir par exemple le Moyse DCC + Power Pack de REE à l’œuvre sont restés époustouflés. Nos petits locotracteurs ont souvent des comportements très éradiques dû principalement au faible nombre de prises de courant et à la faible inertie. Le petit Moyse de REE se joue totalement des passages d’aiguilles délicats ou des tronçons mal alimentés. Il est capable de stocker environ 20 secondes de roulage avec absence totale de courant !

REE reste très discret sur la technologie qui équipe le Moyse. De ce que j’ai compris, ce sont 2 super capa de 2,7 volts qui produisent 1 Farad. Mais 5,4 volts au total cela est loin de suffire. Il y a donc une électronique pointue en sus, d’autant que les super capa ont la particularité de baisser très vite en tension quand elles se déchargent.

Sommes-nous capables cette fois encore d’apporter en DIY des solutions qui rivalisent ?

Pour ma part, j’ai essayé pas mal de choses dont je parlerai dans des posts à suivre. Je propose pour commencer ce montage, sans énormes prétentions, mais qui améliore très significativement le comportement de mon Y6400 de chez EPM.

A vous d’apporter ici vos propres expériences et contributions.

Vos projets / AUTOMATISATION D’UN PONT FLEISCHMANN 6152 (HO) AVEC UN ESP32

« le: avril 19, 2020, 02:13:33 pm »

Bonjour à tous,

Il y a deux ans déjà, je vous parlais de l’automatisation d’un pont tournant FLEISCHMANN 6152 que j’étais en train de réaliser.

https://forum.locoduino.org/index.php?topic=371.msg8971#msg8971

Ce pont fonctionne depuis un moment, mais, confinement aidant, j’ai repris l’ouvrage pour en faire un article, simplifier et optimiser autant que faire ce peut pour que ce projet puisse être réalisé par d’autres. C’est tout de même le but des publications sur Locoduino.

J’ai une question d’électronique qui n’est pas mon domaine de prédilection. Le changement de polarité sur les rails du pont est une nécessité en fonction du sens de sortie de la locomotive. Alors que dans mon projet initial, le changement de polarité dans les rails était assuré par un relais à l’extérieur, je voudrais ici réaliser ce changement de polarité avec des mosfet (BS170) placés sur le PCB qui lui-même est sous le pont.

La commutation serait assurée par deux broches d’un micro contrôleur. Alors qu’une broche est à HIGH, l’autre est à LOW et vis et versa.

Le montage ci-dessous est-il correct ? Faut-il que je prévoie des diodes roues libres ?

Merci par avance pour vos contributions.

PS : J'ai ouvert un nouveau fil où pourront être déposées toutes les discussions sur ce sujet quand l'article sera publié (ou avant pour ceux qui le souhaitent)

Christophe

Bus DCC / Passerelle CAN/WiFi-TCP/Serial

« le: novembre 05, 2019, 03:05:08 pm »

Bonjour à tous,

Je viens de finir ma passerelle entre les réseaux CAN et TCP (WiFi) et aussi série sur base d'ESP32. L'ensemble est disponible sur le Github de Locoduino : https://github.com/Locoduino/CAN_WiFi_gateway32

Ce projet avait été initialisé pour Orléans 2018 sur la base d'ESP8266. Ici, il s'agit d'un ESP32 et d'un module CAN SN65HVD230 qui simplifient considérablement le montage et son cout puisque cette passerelle me revient à 6€ au total !

Il est donc possible de lire les trames CAN qui circulent sur un bus avec des applications reliées, soit en WiFi, soit en Ethernet ou soit encore en série. Et il est inversement possible d'envoyer des trames CAN avec ces mêmes applications.

J'avais présenté à l'époque un TCO sous forme de page Web qui, relié avec les 8 satellites du Locoduinodrome, se mettait à jour dynamiquement. J'utilise toujours ce projet qui est visible ici

J'utilise pour cette vidéo un sketch chargé sur un autre Arduino qui envoi en boucle et à raison d'un message par seconde les mêmes messages que les satellites avec les détecteurs d'occupation (consommation et ponctuels). J'ai poussé le débit des messages au rythme de 1 message toutes les 100ms et la réception TCP n'a pas bronchée.

J'avais aussi montré comment il était possible de faire les réglages des satellites à partir d'une page web :

Pour ma part, c'est un outil très important et mes futurs recherches vont aller dans le sens d'une gestion automatisée de mon réseau sur une base de données (qui existe déjà) et qui va être en interaction directe avec les périphériques CAN (satellites).

C'est aussi ce type de passerelle qui pourra être mise en œuvre par ceux qui voudraient interfacer JMRI avec le bus CAN et les satellites par exemple.

Je ne dispose que peu de temps malheureusement pour faire des présentations plus détaillées (voir cependant sur le Github), mais je peux au travers de ce fil apporter des précisions à tous ceux qui souhaiteraient mettre en œuvre une telle architecture.

Je suis intéressé également par toutes les propositions d'amélioration.

Christophe.

Trucs & astuces / Cohabitation 5V - 3,3V

« le: août 22, 2019, 08:49:42 am »

Bonjour à tous,

Ma question concerne la cohabitation de courants en 5 et 3,3V dans un même montage et devrait concerner de plus en plus de monde avec le développement des cartes en 3,3V.

Je viens de terminer l'automatisation de mon pont tournant avec un ESP32 (en 3,3V donc).

J'utilise comme carte moteur un Pololu 4990 qui peut s'alimenter de 2 à 5,5V pour ce qui est du courant de commande (VCC).

https://www.pololu.com/product/2137/pictures#lightbox-picture0J5015

J'ai placé sur mon montage (alimenté en 12V) deux convertisseurs, un en 5V, l'autre en 3,3V. Le 5V me sert pour 2 capteurs à effet Hall et 2 LEDs. Jusqu'ici, j'ai fait touts mes tests en alimentant la carte Pololu à la même tension que l'ESP32 (3,3V) mais il serait bien que je puisse mieux équilibrer les charges et j'ai pensé alimenter la carte Pololu en 5V.

Pour mes capteurs à effet Hall (5V) vers ESP et mes LEDs, j'ai des transistors, mais pour les quatre sorties moteur de l'ESP vers Pololu, je n'ai pas vraiment la place pour mettre des transistors.

Pensez vous que ce soit dommageable pour l'ESP si j'alimente la carte Pololu en 5V sachant que le courant est "sortant" de l'ESP vers le Pololu ? Est-ce que les broches de l'ESP sont tout de même exposées au 5V ?

Merci pour vos réponses ou autres propositions.

Bien cordialement.

Christophe

Le logiciel DCC++ / Problème de lecture et programmation de CVs avec DCC++

« le: août 05, 2019, 07:14:01 am »

Bonjour à tous,

J’ouvre ce nouveau fil suite à un commentaire à l’article sur Une station DCC complète, polyvalente et économique avec JMRI : http://www.locoduino.org/spip.php?article253 où Jean évoque des problèmes de lecture et de programmation de CV avec JMRI, mais qui est en réalité relèvent de DCC++.

C’est un problème que j’avais soulevé il y a maintenant plus de trois ans, que Dominique aussi à rencontré, et puis comme on a toujours plus ou moins réussi à contourner le problème, c’est quelque chose que l’on a jamais approfondi et pour lequel, de fait, on n’a jamais trouvé de solution.

Si quelqu’un a la solution, nous sommes bien sûr preneur. Dans la négative, je souhaiterais que ceux qui connaissent ce problème puissent contribuer à établir un inventaire des marques de décodeurs concernés et éventuellement des modèles. Il semble bien que cela ne concerne que certains fabricants et pas d’autres.

Il est intéressant de savoir si ces problèmes sont cantonnés à la seule voie de programmation ou concernent aussi la voie principale, et de savoir également, sur la voie principale, quels sont les CVs qui peuvent être reprogrammées.

Enfin, toute proposition qui pourrait contribuer à trouver la réponse est bien sûr la bien venue.

Merci par avance.

Pages: [1] 2

Nouvelles: