Messages

16

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

« le: mars 22, 2024, 06:18:55 pm »

@trimarco232

La gestion d'itinéraire n'a aucun a priori sur le fait qu'on soit en analogique ou DCC.
certes , mais en analogique , il faut une alim traction dédiée à chaque itinéraire compatible , j'ai restreint pour éviter ça
Personnellement, je ne suis pas un fan absolu du DCC, étant en N. Le DCC a des avantages, c'est certain, dont le son, mais c'est hors de prix.
c'est pour cela que je planche sur ça https://forum.locoduino.org/index.php?topic=1601.0
et donc pour ça que je suis ce que tu fais , car il me faudra quelque chose pour le piloter , tout en haut

Ce que j'appelle "itinéraires compatibles", c'est, par exemple :
(TH - H5) et (H3 - D) et (M - H1) et (Ep4 - Tep) qui peuvent très bien être simultanés.
L'autre chose que j'aime bien dans les gares terminus c'est que toutes les voies sont banalisées.
mon principe perso , c'est de banaliser tout le réseau , et d'ailleurs d'avoir tout en VU , pour économiser de la place

Denis

17

Modélisation, Architectures logicielles et matérielles / Re : DCC : Détection Railcom

« le: mars 22, 2024, 04:25:20 pm »

Hi Laurent , canal RC n°2 !
je te réponds rapidement , car d'une part il n'est pas en service , donc pas de certitude , d'autre part car il ne me semble pas que cela puisse apporter quelque chose au présent projet (quoi que + on en sait , mieux ça vaut , je vais d'ailleurs la compléter suite à votre idée de mettre un fusible)
la paternité du projet , HW et SW , appartient à Philipp Gahtow , qui a lui-même repris le principe d'un certain Uwe : https://pgahtow.de/w/R%C3%BCckmeldung#8x_RailCom-Detektor
l'idée est simple et astucieuse : le nano décode les packets dcc , donc il sait quelle est l'adresse émise ; puis il va mesurer le courant RC produit sur chaque voie , dans le timing de l'émission du canal RC n°2 : si un tel courant est présent , c'est que le décodeur correspondant à l'adresse est présent sur cette voie !
au niveau HW , pour simplifier les choses , le potentiel de référence GND est pris directement sur 1 des 2 rails , cela oblige à quelques précautions , notamment communiquer vers l'extérieur par optocoupleurs (ici , c'est Loconet , mais d'autres sont également envisageables)
par rapport à votre schéma , il y aussi 2 schottky tête-bêche et une résistance ; j'ai porté la valeur de celle-ci à 12R , pour augmenter la tension RC afin qu'elle soit plus facilement mesurable , et pour limiter la puissance aux175mW permis par la taille 0805 ; il y a de + , par voie , deux autres résistances , elles servent à tirer les tensions négatives vers le domaine où elles peuvent être mesurées par l'ADC du nano ; cela nécessite un calibrage , car le nano doit savoir à quelle valeur ADC correpond le 0v sur la voie
j'ai dessiné un PCB jlcpcbisable , pour s'éviter les affres du raccordement de ce grand nombre de composants ; avec un peu d'organisation , la carte est plutôt compacte

18

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

« le: mars 21, 2024, 05:00:07 pm »

oui , c'est une gare terminus , mais c'est en analogique , donc à priori , il n'y a pas d'itinéraires compatibles , sauf cas particuliers : par exemple la voie TEP est commutable par relais , soit sur l'alim analogique du reste de la gare , soit sur l'alim des voies EP1 à EP4 ; c'est en fonction des itinéraires formés que l'arduino commute par relais , les alims analogiques , et également coupe l'alim des voies non prises dans un itinéraire ; ce dernier point permet de garer des trains sans avoir à utiliser d'interrupteur

19

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

« le: mars 21, 2024, 09:39:34 am »

pour illustrer , le tableau des LEDs en fonction de l'itinéraire :

Code: [Sélectionner]

#define leds_iti  (1 + 14)// 1 + nombre max de leds dans l'itinéraire
// la 1ère colonne donne le nombre de leds dans le chenillard
// les leds hors chenillard (aiguilles protégeante) sont à ajouter à la fin
const uint8_t led_iti[itis * leds_iti] PROGMEM = { /// protégeantes à revoir /// problématique du sas ?
  // ↓ iti       ↓nb   1       2       3       4       5       6       7       8       9       /*-*/   10      11      12      13      14 <- led
  /*  h6_sa  */  5,  d_h6,    d_h6a,   d_h5r,  d_h4r,  d_s_n,  /*-*/   d_h3n,  o_,     o_,     o_,     o_,     o_,     o_,     o_,     o_,     //  0
  /*  h5_sa  */  5,  d_h5,    d_h5a,   d_h5n,  d_h4r,  d_s_n,  /*-*/   d_h3n,  o_,     o_,     o_,     o_,     o_,     o_,     o_,     o_,     //  1
  /*  h4_sa  */  4,  d_h4,    d_h4a,   d_h4n,  d_s_n,  /*-*/   d_h3n,  o_,     o_,     o_,     o_,     o_,     o_,     o_,     o_,     o_,     //  2
  /*  sa_th  */  3,  d_s_n,   d_t_n,   d_th,   /*-*/   d_s2n,  o_,     o_,     o_,     o_,     o_,     o_,     o_,     o_,     o_,     o_,     //  3
  /*  h6_th  */  9,  d_h6,    d_h6a,   d_h5r,  d_h4r,  d_s_r,  d_h3b,  d_e2n,  d_s2r,  d_th,   /*-*/   d_h3n,  d_s3n,  d_e1n,  o_,     o_,     //  4
  /*  h5_th  */  9,  d_h5,    d_h5a,   d_h5n,  d_h4r,  d_s_r,  d_h3b,  d_e2n,  d_s2r,  d_th,   /*-*/   d_h3n,  d_s3n,  d_e1n,  o_,     o_,     //  5
  /*  h4_th  */  8,  d_h4,    d_h4a,   d_h4n,  d_s_r,  d_h3b,  d_e2n,  d_s2r,  d_th,   /*-*/   d_h3n,  d_s3n,  d_e1n,  o_,     o_,     o_,     //  6
  /*  h3_th  */  8,  d_h3,    d_b3n,   d_h3a,  d_h3n,  d_h3b,  d_e2n,  d_s2r,  d_th,   /*-*/   d_b2n,  d_s_n,  d_s3n,  d_e1n,  o_,     o_,     //  7
  /*  h2_th  */  7,  d_h2,    d_b2n,   d_h2a,  d_h2r,  d_s3r,  d_s2r,  d_th,   /*-*/   d_b3n,  d_p_r,  o_,     o_,     o_,     o_,     o_,     //  8
  /*  h1_th  */  8,  d_h1,    d_h1a,   d_h1b,  d_h1r,  d_h2n,  d_s3r,  d_s2r,  d_th,   /*-*/   d_p_r,  o_,     o_,     o_,     o_,     o_,     //  9
  /*  tp_th  */  8,  d_tp,    d_tp1,   d_tp2,  d_p_n,  d_h2n,  d_s3r,  d_s2r,  d_th,   /*-*/   o_,     o_,     o_,     o_,     o_,     o_,     //  10
  /*  h6_hd  */ 10,  d_h6,    d_h6a,   d_h5r,  d_h4r,  d_s_r,  d_h3b,  d_e2n,  d_s2n,  d_s1n,  d_hd,   /*-*/   d_t_n,  d_s3n,  d_e1n,  o_,     //  11
  /*  h5_hd  */ 10,  d_h5,    d_h5a,   d_h5n,  d_h4r,  d_s_r,  d_h3b,  d_e2n,  d_s2n,  d_s1n,  d_hd,   /*-*/   d_t_n,  d_s3n,  d_e1n,  o_,     //  12
  /*  h4_hd  */  9,  d_h4,    d_h4a,   d_h4n,  d_s_r,  d_h3b,  d_e2n,  d_s2n,  d_s1n,  d_hd,   /*-*/   d_t_n,  d_s3n,  d_e1n,  o_,     o_,     //  13
  /*  h3_hd  */  9,  d_h3,    d_b3n,   d_h3a,  d_h3n,  d_h3b,  d_e2n,  d_s2n,  d_s1n,  d_hd,   /*-*/   d_b2n,  d_s_n,  d_t_n,  d_s3n,  d_e1n,  //  14
  /*  h2_hd  */  8,  d_h2,    d_b2n,   d_h2a,  d_h2r,  d_s3r,  d_s2n,  d_s1n,  d_hd,   /*-*/   d_b3n,  d_p_r,  d_t_n,  o_,     o_,     o_,     //  15
  /*  h1_hd  */  9,  d_h1,    d_h1a,   d_h1b,  d_h1r,  d_h2n,  d_s3r,  d_s2n,  d_s1n,  d_hd,   /*-*/   d_p_r,  d_t_n,  o_,     o_,     o_,     //  16
  /*  tp_hd  */  9,  d_tp,    d_tp1,   d_tp2,  d_p_n,  d_h2n,  d_s3r,  d_s2n,  d_s1n,  d_hd,   /*-*/   d_t_n,  o_,     o_,     o_,     o_,     //  17
  /*  h6_hm  */ 10,  d_h6,    d_h6a,   d_h5r,  d_h4r,  d_s_r,  d_h3b,  d_e2n,  d_s2n,  d_s1r,  d_hm,  /*-*/    d_p_r,  d_t_n,  o_,     o_,     //  18
  /*  h5_hm  */ 10,  d_h5,    d_h5a,   d_h5n,  d_h4r,  d_s_r,  d_h3b,  d_e2n,  d_s2n,  d_s1r,  d_hm,  /*-*/    d_p_r,  d_t_n,  o_,     o_,     //  19
  /*  h4_hm  */ 10,  d_h4,    d_h4a,   d_h4n,  d_s_r,  d_s_r,  d_h3b,  d_e2n,  d_s2n,  d_s1r,  d_hm,  /*-*/    d_p_r,  d_t_n,  o_,     o_,     //  20
  /*  h3_hm  */  9,  d_h3,    d_b3n,   d_h3a,  d_h3n,  d_h3b,  d_e2n,  d_s2n,  d_s1r,  d_hm,   /*-*/   d_b2n,  d_s_n,  d_p_r,  d_t_n,  o_,     //  21
  /*  h2_hm  */  8,  d_h2,    d_b2n,   d_h2a,  d_h2r,  d_s3r,  d_s2n,  d_s1r,  d_hm,   /*-*/   d_b3n,  d_p_r,  d_e2n,  d_s1n,  o_,     o_,     //  22
  /*  h1_hm  */  9,  d_h1,    d_h1a,   d_h1b,  d_h1r,  d_h2n,  d_s3r,  d_s2n,  d_s1r,  d_hm,   /*-*/   d_p_r,  d_e2n,  d_s1n,  o_,     o_,     //  23

  /*  tp_hm  */  9,  d_tp,    d_tp1,   d_tp2,  d_p_n,  d_h2n,  d_s3r,  d_s2n,  d_s1r,  d_hm,   /*-*/   d_e2n,  d_s1n,  o_,     o_,     o_,     //  24
  /*  h3_se  */  5,  d_h3,    d_b3r,   d_h2a,  d_h2r,  d_s3n,  /*-*/   d_p_r,  d_e2n,  o_,     o_,     o_,     o_,     o_,     o_,     o_,     //  25
  /*  h2_se  */  5,  d_h2,    d_b2n,   d_h2a,  d_h2r,  d_s3n,  /*-*/   d_p_r,  d_e2n,  o_,     o_,     o_,     o_,     o_,     o_,     o_,     //  26
  /*  h1_se  */  6,  d_h1,    d_h1a,   d_h1b,  d_h1r,  d_h2n,  d_s3n,  /*-*/   d_p_r,  d_e2n,  o_,     o_,     o_,     o_,     o_,     o_,     //  27
  /*  tp_se  */  6,  d_tp,    d_tp1,   d_tp2,  d_p_n,  d_h2n,  d_s3n,  /*-*/   d_e2n,  o_,     o_,     o_,     o_,     o_,     o_,     o_,     //  28
  /*  se_hm  */  2,  d_e1n,   d_hm,    /*-*/   d_s1n,  o_,     o_,     o_,     o_,     o_,     o_,     o_,     o_,     o_,     o_,     o_,     //  29

  /*  tp_p1  */  7,  d_tp,    d_tp1,   d_tp2,  d_p_r,  d_p1n,  d_p1a,  d_p1,   /*-*/   d_h1r,  o_,     o_,     o_,     o_,     o_,     o_,     //  30
  /*  tp_p2  */  8,  d_tp,    d_tp1,   d_tp2,  d_p_r,  d_p1r,  d_p2a,  d_p2r,  d_p2,   /*-*/   d_h1r,  o_,     o_,     o_,     o_,     o_,     //  31
  /*  tp_p3  */  8,  d_tp,    d_tp1,   d_tp2,  d_p_r,  d_p1r,  d_p2a,  d_p4n,  d_p3,   /*-*/   d_h1r,  o_,     o_,     o_,     o_,     o_,     //  32
  /*  tp_p4  */  8,  d_tp,    d_tp1,   d_tp2,  d_p_r,  d_p1r,  d_p2a,  d_p4r,  d_p4,   /*-*/   d_h1r,  o_,     o_,     o_,     o_,     o_,     //  33
  /*  h3_h2  */  3,  d_h3,    d_b3r,   d_h2a,  /*-*/   o_,     o_,     o_,     o_,     o_,     o_,     o_,     o_,     o_,     o_,     o_      //  34

} ;

et le dessin :

20

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

« le: mars 20, 2024, 10:35:09 pm »

Bonjour,
Denis , il y a peut-être une chose qu'il convient également de prendre en considération , suffisamment en amont , c'est les voyants du TCO , je pense notamment à ceux qui montrent l'itinéraire , et l'occupation des zones (il me semble que tu sais bien ce que c'est) : pourquoi ?
je finalise actuellement le 4ème poste d'aiguillage analogique & TCO pour le club ; sur le TCO il y a des boutons poussoirs et des LEDs ; pour simplifier le travail de l'arduino (PRO MICRO = uno , faible puissance) , tout est fait par des tableaux , saisis manuellement ;
il y a 16 boutons et 18 aiguillages , (TCO de taille moyenne) , cela fait quand-même 35 itinéraires , dont certains peuvent comporter jusqu'à 14 LEDs , parmi les 72 LEDs des voies du TCO ; cela oblige à saisir un tableau de 35 * 14 =  490 items , qui sont soit 0 , soit une des 72 LEDs : c'est fastidieux , donc je pense qu'il serait bien que cette tâche puisse également être automatisée , si tu vois ce que je veux dire ...

21

Modélisation, Architectures logicielles et matérielles / DCC : Détection Railcom

« le: mars 17, 2024, 10:02:11 pm »

bonsoir , juste une courte récréation , si vous voulez bien
j'avais dessiné ceci , une carte de rétro-signalisation pour occupation et identification railcom , à 8voies
mais comme je ne l'ai (toujours) pas essayée , je n'en dirai pas +

22

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

« le: mars 17, 2024, 08:00:30 pm »

@ Jozef
ne le prends pas mal , mais tes soudures sont dégeulasses
il faut que changes soit ton fer , soit la soudure que tu utilises (voire la méthode)

23

Vos projets / Re : Arduino S88 compatible avec Marklin ?

« le: mars 17, 2024, 06:28:30 pm »

très belle réalisation , Tony !

24

Modélisation, Architectures logicielles et matérielles / Re : DCC : Détection par consommation avec des courants faibles

« le: février 24, 2024, 08:46:46 pm »

Bonjour ,
enlever la capa et filtrer par le soft ?

25

Vos projets / Re : LaBox : Evolutions ?

« le: février 20, 2024, 10:15:50 am »

Bonjour ,
attention , il y a ici 2 choses :
1) la recherche d'un nouveau microcontrôleur
2) l'info documentée selon laquelle , la compatibilité annoncée de LaBox avec Railcom , risque fort de ne jamais voir le jour
tant pour ceux qui se sont lancés que pour ceux qui se documentent , il ne faut peut-être pas donner l'impression qu'on cherche à dissimuler le 2) ...

26

Vos projets / Re : Re : Re : Les SATELLITES AUTONOMES: évolutions du socle initial

« le: février 19, 2024, 11:36:18 pm »

1) Arduino classique à base d'AVR : 5v , convient pour 90% des besoins , manque de capacité pour certaines applis
2) ESP32 , 3v3 , la superstar , puissance , wifi CAN , prix , disponibilité , existe aussi en toute petite carte (avec USB)
perso , je n'aime pas ... : il y a un OS , cad. qu'il s'efforcera sans doute de faire ce qu'on lui demande , mais au final il fera ce qu'il veut : si on lui demande de faire des trucs précis , DCC , railcom , c'est la cata ; de + , mauvais ADC , latence d'ISR anormalement longue et variable , "poor wifi integration design"
(les gens de DCC EX l'ont laissé tomber , ils s'orientent vers du STM32 avec un ESP32 C3 en simple interface wifi)
3) STM32 , amha le top en 3v3 , CAN , mais pas de wifi

Bonjour Marc,

Merci pour cet inventaire intéressant car exhaustif.
à ton service
Je suis d’accord avec toi sur de nombreux points. Tout d’abord, concernant les Arduino, surtout les Nano. On a tendance à les oublier mais pour pas mal de choses, ils font le job. On les accuse de prendre beaucoup de place, pas trop les Nano mais les Mega par exemple. Sauf qu’un Mega c’est 3 ports série, et plus de 40 broches « vraiment » utilisables. Pas de concurrent à ma connaissance de ce point de vue. Et a-t-on toujours besoin de faire petit ?

Pour l’ESP32, je te trouve trop critique et là encore, tout dépend du besoin. Il est indéniable qu’à ce prix, avec les possibilités offertes, c’est absolument canon.

Sans avoir vraiment optimisé le programme, je fais du DCC avec et aussi du Railcom !!! Alors oui, j’ai 25% des trames qui sont hors des spécifications du NMRA mais tout fonctionne depuis longtemps et de façon très satisfaisante.

Et alors, concernant Railcom, je ne te suis plus du tout. Là aussi nous avons un certain recul (1 an ½) et aucun retour négatif. Michel a même testé avec succès trois lectures Railcom simultanées avec le même ESP.
il y a bien entendu une part de subjectivité de ma part (c'est pour ça que j'ai précisé "perso") ; perdre un peu de bande passante à cause de quelques messages déformés , je suis bien d'accord que c'est acceptable , mais je trouve ça dommage , dès qu'on peut faire quelque chose de nickel avec la plupart des autres microcontrôleurs
et en effet , je suis inquiet pour le railcom , je vois mal le cas d'une centrale qui pourrait se remettre à émettre intempestivement des bits DCC , alors que les décodeurs s'attendent à un cutout et commencent à envoyer leur canal 1 railcom ; sans doute les décodeurs sont protégés contre ça , mais perso je tiens à éviter à tout prix
Il y a un peu de doigté sans doute à mettre quand on développe avec l’ESP32. Chercher à utiliser les deux cœurs mais en sachant que toutes les applications asynchrones l’on fait avant nous (Serial, WiFi, CAN, Web…). Je n’ai pas de recul là-dessus mais je désactive maintenant le Wifi quand je n’en ai pas besoin et aussi le port Serie. Est-ce vraiment efficace ? Dans quelle mesure ?

Quant à DCC-Ex, tu confirmes ce qui se présentait qui est qu’ils ne développeront pas Railcom sur ESP32 ce qui n’est pas forcément une bonne nouvelle pour la Box. Ni pour moi, car même si je dispose d’une solution alternative, j’aurais préféré utiliser la Box avec les satellites autonomes.
je ne suis pas dans le secret de DCC EX , donc je ne peux rien confirmer je peux juste constater que ce n'est toujours pas fait , et supputer que vu leur niveau , ce serait déjà fait si c'était possible . Par ailleurs mes connaissances de la bête (RMT , interruptions) font que que ce n'est pas possible en l'état actuel  ; on peut espérer une suite favorable , car l'ESP32 sait intrinsèquement le faire , mais je suis pessimiste

Que l’on se comprenne bien, je ne dis pas, loin s’en faut, que l’ESP32 est exempt de défauts, mais qu’on ne peut pas l’exclure car il répond à de très nombreux besoins.

Et une fois encore, c’est le besoin puis le prix qui doivent nous guider. N’est-il pas par exemple plus judicieux de mettre deux ESP sur une carte en répartissant les tâches qu’un seul microcontrôleur qui vaut deux fois le prix.

chacun fait comme il veut , maintenir 2 logiciels différent me gênerait , je me braque sur certaines choses qu'un ESP32 ne peut pas faire , et 2 ne pourront pas non plus ...
j'ai dit ce que je pensais devoir dire , mais je pense que le choix du microcontrôleur n'est pas si crique à ce stade ; vous preniez la décision de migrer , tu aurais vite fait d'adapter ton sauf au nouvel élu , et entre temps Laurent , (qui me pardonnera mes intrusions ? ) aura déjà dessiné la nouvelle carte
il faut que je vous laisse travailler maintenant (pareil pour moi , j'ai tant de choses en retard) !



Christophe

27

Vos projets / Re : Les SATELLITES AUTONOMES: évolutions du socle initial

« le: février 15, 2024, 10:50:02 pm »

Bonsoir ,
(j'étais absent de vos topics et le temps passe vite , alors n'hésitez pas à me (re)poser des questions)
je reviens vers vous pour vous faire part de mes expériences et réflexions quant au choix de différents arduinos selon le besoin (et l'envie) ... pour tout de suite dire qu'il n'y a pas de solution évidente
perso , j'utilise plutôt des arduino complets , avec USB et bootloader , c'est plus facile à téléverser , à paramétrer , et à interfacer avec un PC ; il est placé en carte fille sur le circuit imprimé , qui comporte les autres composants nécessaires au montage
je les classe très subjectivement en 2 catégories : les 5v et les 3v3 ...
- les 3v3 , qui ont l'avantage de la compatibilité avec certains périphériques modernes
- les 5v ont l'avantage d'une meilleure commande des mosfet , d'une meilleure immunité aux parasites , quand on commande par exemple des circuits externes du genre 74HC165 ou 74HC595 , et une compatibilités avec des périphériques classiques capteurs , etc.) en général , les 5v marchent aussi en 3v3
dans un ordre quelconque :
1) Arduino classique à base d'AVR : 5v , convient pour 90% des besoins , manque de capacité pour certaines applis
2) ESP32 , 3v3 , la superstar , puissance , wifi CAN , prix , disponibilité , existe aussi en toute petite carte (avec USB)
perso , je n'aime pas ... : il y a un OS , cad. qu'il s'efforcera sans doute de faire ce qu'on lui demande , mais au final il fera ce qu'il veut : si on lui demande de faire des trucs précis , DCC , railcom , c'est la cata ; de + , mauvais ADC , latence d'ISR anormalement longue et variable , "poor wifi integration design"
(les gens de DCC EX l'ont laissé tomber , ils s'orientent vers du STM32 avec un ESP32 C3 en simple interface wifi)
3) STM32 , amha le top en 3v3 , CAN , mais pas de wifi
4) pi pico , 3v3 , wifi , n'a pas tous les défauts de l'ESP32 , mais des faiblesses comparé au STM32 , pas de CAN
5) les nouveaux AVR de Laurent , 5v , bien , mais désespérément pas de petite carte bon marché
6) UNO R4 , 5v , wifi , CAN , pas de défaut comme ESP32 et pi pico , un peu cher mais il existe des clones acceptables
...

28

Vos projets / Re : BASIC_AUTO_LOOP_REVERSER

« le: février 01, 2024, 04:36:37 pm »

(...)
Il se peut toutefois que vos décodeurs de locomotive n'apprécient pas à outrance ce genre de situation...

peux-tu développer , stp ?

Le principe repose sur le bypass des diodes de l'opto coupleur bidirectionnel ( BA354 par exemple)  par le premier essieux franchissant cette séparation en cas de polarites opposées entre les parties de rail fixe et  inversable qui va générer une interruption sur une entrée d'un CPU qui commute alors les sorties d un relais pour procéder aux alignements des polarités des deux zones.

je ne vois pas comment le dispositif se raccorde dans la boucle ; comment fait-il pour revenir en position initiale ?

L'alimentation n'est pas prélevée sur le courant DCC

c'est bien domage

29

Vos projets / Re : Les SATELLITES AUTONOMES: évolutions du socle initial

« le: janvier 25, 2024, 11:15:55 am »

Bonjour
bien entendu , il faut une double coupure entre 2 secteurs chacun alimenté par son propre booster
mais dans un secteur alimenté par un booster donné , il faut absolument laisser une des 2 files de rail sans coupure :
1) parce que la double coupure est inutile , Laurent n'a rien démontré
2) parce que pour le fonctionnement du railcom , il faut que le courant émis par le décodeur puisse se reboucler vers le court-circuit (cutout) créé par le booster entre les 2 files de rail , c'est le béaba !

si tu as par exemple un évitement sur voie unique avec un aiguillage electrofrog à chaque extrémité , il y a déjà , d'office , 2 coupures au talon de chaque appareil : il suffit donc d'utiliser ces 2 coupures pour les 2 cantons situés entre les 2 appareils ; notons toutefois que dans ce cas , les 2 coupures se situent sur 2 files de railles différentes , il faut donc gérer ceci au niveau du module de rétrosignalisation
c'est à la technique de s'adapter au réseau , aux choses , pas l'inverse

par ailleurs , les modules qui créent une zone tampon entre 2 boosters sont généralement inutiles , car la désynchronisation des boosters reste dans les deadtime des 2 ponts en H ; citer des publications commerciales n'a pas de sens , si on n'en explique pas le réel intérêt

30

Vos projets / Re : Re : Les SATELLITES AUTONOMES: évolutions du socle initial

« le: janvier 21, 2024, 11:18:15 am »

(...)
ZAP = Zone d'APpareils.
Toutes les coupures se font sur les 2 rails

Bonjour ,
de mon temps , ZAp = Zone d'Approche : il y a malheureusement une confusion possible
https://www.roverch.net/modelisme/EnclApproche.htm

(...)
Toutes les coupures se font sur les 2 rails

c'est sans doute dommage , si ce n'est pas forcément utile