LaBox" : Une Centrale DCC polyvalente et abordable

[Jozef]

Bonjour,
Je n'arrive pas a diriger deux train avec ma BOX connecté à un smartphone et son application Z21.
Il y a t il une raison ?

[Thierry]

Bonjour.
Non pas de raison. Si les deux locos ont une adresse différente, je les pilote sans problème.

[gbo95]

Nous utilisons LaBox au club sur notre réseau N. Samedi dernier nous avions une douzaine de locos activées, dont 8 simultanément présentes sur les voies, pilotées par un smartphone et une tablette à double commande, soit  3 simultanées en pilotage direct.

[lebelge2]

Bonjour.

Je viens de recevoir un ESP32 pour construire « La Box »
Pressé d’explorer le code pour la rendre compatible RailCom.

La modification est très simple, ajout de deux delay au bon endroit.
Dans le fichier DCCRMT.cpp, chercher :

void IRAM_ATTR interrupt(rmt_channel_t channel, void *t) {

La modifier comme ci-dessous.

Code: [Sélectionner]

void IRAM_ATTR interrupt(rmt_channel_t channel, void *t) {             
  delayMicroseconds(22);
  digitalWrite(25,1);
  delayMicroseconds(412);  //  ___________---___________
  digitalWrite(25,0);
  RMTChannel *tt = channelHandle[channel];
  if (tt) tt->RMTinterrupt();
  if (channel == 0)
    DCCTimer::updateMinimumFreeMemoryISR(0);
}
et dans le setup(), mettre la pin D25 en sortie :
pinMode(25, OUTPUT);

L’introduction du CutOut dans la trame DCC se fait de manière matérielle avec un circuit TTL logique 7400 (4 portes Nand) ,  voir les photos en pièces jointes.
De cette façon le signal DCC original n’est pas altéré, que du contraire, il est temponné.
Placer des Delay dans une interruption, n’est pas très élégant, il est possible de les remplacer par des Timers.

Bien à vous.

[Brunotoutsimple]

Bonjour.

Je viens de recevoir un ESP32 pour construire « La Box »
Pressé d’explorer le code pour la rendre compatible RailCom.

La modification est très simple, ajout de deux delay au bon endroit.
Dans le fichier DCCRMT.cpp, chercher :

void IRAM_ATTR interrupt(rmt_channel_t channel, void *t) {

La modifier comme ci-dessous.

Code: [Sélectionner]

void IRAM_ATTR interrupt(rmt_channel_t channel, void *t) {             
  delayMicroseconds(22);
  digitalWrite(25,1);
  delayMicroseconds(412);  //  ___________---___________
  digitalWrite(25,0);
  RMTChannel *tt = channelHandle[channel];
  if (tt) tt->RMTinterrupt();
  if (channel == 0)
    DCCTimer::updateMinimumFreeMemoryISR(0);
}
et dans le setup(), mettre la pin D25 en sortie :
pinMode(25, OUTPUT);

L’introduction du CutOut dans la trame DCC se fait de manière matérielle avec un circuit TTL logique 7400 (4 portes Nand) ,  voir les photos en pièces jointes.
De cette façon le signal DCC original n’est pas altéré, que du contraire, il est tamponné.
Placer des Delay dans une interruption, n’est pas très élégant, il est possible de les remplacer par des Timers.

Bien à vous.

Bonsoir

Super Lebelge2!
Etant novice, Vous dites que c'est pas très élégant de mettre des delays pour des interruptions et c'est ce que j'avais lu pour les interruptions pour Arduino. Est-ce que vous serait possible de modifier le programme afin d'introduire les Timers que vous le suggérez.
Vous dites d'ajouter la ligne suivante dans le setup(), c'est où? SVP

Code: [Sélectionner]

dans le setup(), mettre la pin D25 en sortie :
pinMode(25, OUTPUT);

[trimarco232]

Bonjour ,
j'ai des questions (voir des doutes) quant-à la fiabilité d'un tel montage (mais c'est peut-être juste parce que je suis loin d'avoir tout compris) :
- les gens de DCC-EX , c'est des costauds , si on pouvait implémenter le cutout de manière assez fiable dans l'ESP32 , pourquoi ne l'auraient-ils pas fait ?
- c'est le RMT qui est utilisé , car il permet de dérouler le packet indépendamment des errances des cores
- à la fin d'un RMT , il faut recharger les données (pour le packet suivant) , dans le cadre d'une interruption : il vaut mieux que cette interruption se fasse au cours d'un bit dcc 0 , par exemple le packet start bit , car c'est le moment où on peut se permettre des libertés dans les délais , moyennant le stretch de ce bit , ce qui est permis par la norme
- ce code créé plusieurs approximations dans le timing :
- - la latence de l'interruption : 4 à 8us , et pire si des opérations wifi sont en cours
- - les delayMicroseconds() , c'est pas des sciences exactes , en particulier pour un ESP32
- - le digitalWrite , pareil
.
donc , je ne doute pas que tu trouves des signaux acceptables à l'analyseur logique , mais qu'en est-il quand l'ESP32 est un peu sollicité , notamment s'il fait des opérations wifi ?

[lebelge2]

Trimarco.
Je vais tester la fiabilité de mon système dans les prochains jours.
Il y a quand même une tolérance de 6µs (26 à 32µs après le bit de stop).
Je vais mesurer si je reste dans cette fenêtre avec le µp en charge (WiFi)