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 ... 54
1
A mes heures perdues (trop peu nombreuses...) je tente de controler Labox via le CAN,

C'est mieux que d'aller au bistrot !

- Je pense qu'il est nécessaire d'établir un protocole CAN défini, même si il l'est uniquement à l'échelle de locoduino. Cela permet à chacun de pouvoir apporter sa petite pierre à l'édifice à coté des développeurs chevronnés qui sévissent ici et de s'assurer de la compatibilité du code dans le temps.  (une petite manette CAN, un TCO, un accessoire,....)

C'est ce que nous sommes en train de réaliser. Cela fait un petit moment que nous échangeons après avoir étudier de nombreux autres protocoles dont celui de Marklin qui m'a le plus inspiré. En fait, l'implantation du CAN dans la Box avec la structure de messages que je propose doit valider (ou non) cette proposition, ce pourquoi j'ai profité de la perche tendue par Thierry pour relancer le sujet.

- Le protocole doit rester abordable: le gros avantage de DCCex était quand même d'être controlé par des instructions simplissimes <1 xx xxx ....> Un débutant sait très vite envoyer une instruction sur un port série. Son principal inconvénient était de ne communiquer que dans un sens.
La nécessité initiale du CAN était d'apporter cette communication bidirectionnelle au gestionaire.

Non le protocole sous forme <1 xx xxx ....> ne communique pas que dans un sens. Pour les commandes CAN de la Box, j'ai également programmé les confirmations de réception de commandes avec le CAN mais je me suis limité à celle qui sont d'origine dans DCC++ /DCC Ex ! On pourra élargir si le besoin est exprimé.

J'ai étudié les liens que Christophe m'a indiqué sur le CAN avec les possibilités de filtre. Rien n'est insurmontable ..... mais a t'on besoin d'apporter de la complexité supplémentaire?
(Concernant les satellites autonomes, c'est un concept tellement différent que les besoins en communication peuvent être différents également.)

Je ne crois pas apporter de la complexité, même en CAN, tu pourrais toujours communiquer "à l'ancienne <1 xx xxx ....>". Le propre d'un protocole c'est justement de pouvoir répondre à TOUS les besoins avec la même structure. La structure pour les satellites est la même. Comme le petit programme pour le TCO que j'ai mis en ligne ce matin. C'est le propre d'un protocole, sa raison d'être que ce soit la même chose pour tout le monde.

Je ne veux surtout pas froisser les développeurs qui font un travail monstre, qui ont conçu Labox plein d'autres choses, mais en tant qu'amateur, on se sens vite largué quand on voit l'évolution impressionnante des projets, et de ce fait on se dit qu'on ne peut pas apporter grand chose... Je pense qu'il ne faut pas perdre l'aspect pédagogique et abordable pour l'amateur.
En tous cas, encore félicitations pour tout le travail accompli et aussi pour votre réactivité sur les forums quand on pose des questions. On ne reste jamais bloqué très longtemps.

Merci pour les appréciations.

Malheureusement, nous sommes actuellement essentiellement sur des projets complexes. Il n'existe pas vraiment de programmes simples pour les projets complexes. Par contre, nous faisons en sorte, Thierry en particulier, moi aussi, de faire que cela soit très simple côté utilisateur.

Pour finir, je prendrais le cas des commandes pour la Box. Les seules commandes que l'utilisateur ait besoin de connaitre sont dans le fichier .ino à partir de la ligne 110, tu avoueras que ce n'est tout de même pas très compliqué : https://github.com/BOBILLEChristophe/Test_CommCan_LaBox_2/blob/main/Test_CommCan_LaBox_2.ino

Et en plus j'ai mis des commentaires explicites.

Quand nous serons d'accord sur la structure des identifiants CAN et accessoirement des datas il faudra rédiger effectivement toute la correspondance des fonction, ce ne sera pas de la tarte.

Pour vous donner une idée, je vous joins la doc du protocole CAN de Marklin, ça va vous donner une idée du boulot à venir. Et encore, je n'ai traduit que la moitié environ ! Le lien vers le document original est au début de la traduction, il comporte 68 pages.

Christophe

PS : Peut être les responsables de ce fil préfèreront-ils ouvir un nouveau sujet pour le CAN qui n'est d'ailleurs pas spécifique à la Box ?

2
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 ?

Pour répondre au souhait de LocoFred de réaliser un TCO « physique », avec des boutons poussoirs pour changer la position des aiguilles sur les satellites autonomes, j’ai écrit ce petit programme qui fait le job.

Je suis parti d'un postulat qui est que nous avions 10 aiguilles (donc 10 boutons)
const uint8_t nb_btn = 10;           // Nombre de boutons
Que la première broche utilisée (sur un Mega) est la broche 20.
const byte firstBtnPin = 20;         // Première broche de connexion des boutons
Que les boutons actionnent dans l'ordre les aiguilles des satellites comme suit :
  btn[0].sat = 11; btn[0].aig = 0;
  btn[1].sat = 11; btn[1].aig = 1;
  btn[2].sat = 12; btn[2].aig = 0;
  btn[3].sat = 12; btn[3].aig = 1;
  btn[4].sat = 12; btn[4].aig = 2;
  btn[5].sat = 13; btn[5].aig = 0;
  btn[6].sat = 14; btn[6].aig = 0;
  btn[7].sat = 14; btn[7].aig = 1;
  btn[8].sat = 15; btn[8].aig = 0;
  btn[9].sat = 16; btn[9].aig = 0;

La bibliothèque CAN utilisée est acan2515 de Pierre Molinaro : https://github.com/pierremolinaro/acan2515/tree/master

Le shield CAN recommandé est celui de SEED Studio : https://wiki.seeedstudio.com/CAN-BUS_Shield_V2.0/
qui autorise 1Mbps de débit.

Sur un Mega, il sera nécessaire de respecter le brochage suivant :



Voici le code que vous pouvez aussi télécharger :



/*
    Etude du programme pour des commandes d'aiguilles à partir de boutons poussoirs sur un TCO (physique)
    à destination des satellites autonomes
    Ce programme est destiné à fonctionner sur Arduino Uno ou Mega.

    Les broches sont commutées sur HIGH à l'état repos de boutons poussoirs par activation des résistances PULLUP internes
    Elles sont commutées sur LOW par l'appui sur le bouton poussoir lorsqu'elles reçoivent un signal à la masse (GND)
    Cet état LOW correspond au bouton appuyé.
   
    v 0.0.1 - 21/02/2024

    copyright (c) 2022 christophe.bobille - LOCODUINO - www.locoduino.org
*/

const byte thisNodeId = 252;         // N° de nœud CAN du TCO sur le bus

const uint8_t nb_btn = 10;           // Nombre de boutons
const byte firstBtnPin = 20;         // Première broche de connexion des boutons
const uint32_t delayDebonce = 100;   // Delay du debonce (en millisecondes)
const uint32_t delaySendMsg = 2000;  // Delay entre l'envoi de messages CAN (en millisecondes)


class Button
{
private:

public:
  byte ID;
  byte pin;
  bool pressed;
  uint32_t lastDebounceTime;
  uint32_t lastTimeSendMsg;
  byte sat;
  byte aig;
  Button();
};

Button::Button()  // Constructeur
  : ID(0),
    pin(255),
    pressed(false),
    lastDebounceTime(0),
    lastTimeSendMsg(0) {}

Button btn[nb_btn];  // Instances de Button

/************************ ACAN *****************************/
// If you use CAN-BUS shield (http://wiki.seeedstudio.com/CAN-BUS_Shield_V2.0/) with Arduino Uno,
// use B connections for MISO, MOSI, SCK, #9 or #10 for CS (as you want),
// #2 or #3 for INT (as you want).
#include <ACAN2515.h>
static const byte MCP2515_CS = 53;  // CS input of MCP2515 (Arduino Mega)
static const byte MCP2515_INT = 2;  // INT output of MCP2515 (Arduino Mega)
ACAN2515 can(MCP2515_CS, SPI, MCP2515_INT);
static const uint32_t QUARTZ_FREQUENCY = 16UL * 1000UL * 1000UL;  // 16 MHz

CANMessage frame;  // Instance de CANMessage
/**********************************************************/

void setup() {
  Serial.begin(115200);

  /************************ ACAN *****************************/
  //--- Begin SPI
  SPI.begin();
  //--- Configure ACAN2515
  Serial.println("Configure ACAN2515");
  ACAN2515Settings settings(QUARTZ_FREQUENCY, 1000UL * 1000UL);  // CAN bit rate 1000 kb/s
  const uint16_t errorCode = can.begin(settings, [] {
    can.isr();
  });
  if (errorCode != 0)
  {
    Serial.print("Configuration error 0x");
    Serial.println(errorCode, HEX);
  }
  /************************ ACAN : paramètres du messages *******************/
  // Structure de l'identifiant des messages CAN : https://www.locoduino.org/IMG/png/satautonomes_messageriecan_v1.png
  const byte prio = 0x03;     // Priorité la moins élévée
  const byte commande = 0xE1; // Identifiant des commandes d'aiguilles pour les satellites autonomes
  const byte resp = 0x00;     // Ceci n'est pas une réponse


  frame.id |= prio << 27;        // Priorite 0, 1 ou 2
  frame.id |= commande << 19;    // commande appelée
  frame.id |= thisNodeId << 11;  // ID expediteur
  frame.id |= resp << 2;         // Response
  frame.ext = true;
  frame.len = 2;                 //Nombre d'octets de données du message
  /**********************************************************/


  for (byte i = 0; i < nb_btn; i++)
  {
    btn[i].ID = i;
    btn[i].pin = firstBtnPin + i;
    pinMode(btn[i].pin, INPUT_PULLUP);
    Serial.print("setup btn : ");
    Serial.println(i);
  }

  // Exemple d'aiguilles à commander
  // sat désigne sur quel satellite s'applique la commande
  // aig désigne sur quelle aiguille de ce satellite s'applique la commande
  btn[0].sat = 11; btn[0].aig = 0;
  btn[1].sat = 11; btn[1].aig = 1;
  btn[2].sat = 12; btn[2].aig = 0;
  btn[3].sat = 12; btn[3].aig = 1;
  btn[4].sat = 12; btn[4].aig = 2;
  btn[5].sat = 13; btn[5].aig = 0;
  btn[6].sat = 14; btn[6].aig = 0;
  btn[7].sat = 14; btn[7].aig = 1;
  btn[8].sat = 15; btn[8].aig = 0;
  btn[9].sat = 16; btn[9].aig = 0;
}

void loop()
{
  for (byte i = 0; i < nb_btn; i++)
  {
    // Le bouton est détecté comme appuyé
    if (LOW == digitalRead(btn[i].pin))
    {
      // L'état pressed est vrai et le delay de debonce est dépassé
      if (btn[i].pressed && millis() > btn[i].lastDebounceTime + delayDebonce)
      {
        // Le delai par rapport au dernier envoi est dépassé
        if (millis() > btn[i].lastTimeSendMsg + delaySendMsg)
        {
          // Envoi du message CAN de commande
          frame.data[0] = btn[i].sat;  // ID satellite destinataire
          frame.data[1] = btn[i].aig;  // Aiguille à commuter
          const bool ok = can.tryToSend(frame);
          if (ok)
            btn[i].lastTimeSendMsg = millis();
          else
            Serial.println("Send failure");         
        }
        btn[i].lastDebounceTime = millis();
      }
      btn[i].pressed = true;
    }
    else
      btn[i].pressed = false;
  }
}


3

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.

4
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

5
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

6
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

7
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

8
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

9
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

10
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



11
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

12
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

13
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

14
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

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

Pages: [1] 2 3 ... 54