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 - laurentr

Pages: [1] 2 3 ... 42
1
Discussions ouvertes / Re : La Cockerill au travail
« le: Aujourd'hui à 12:33:42 pm »
MAGNIFIQUE!

Du grand art (même si les mouvements paraissent à mon gout trop rapide...)

Bravo.

2
Discussions ouvertes / Re : Distrubution du Signal DCC
« le: Aujourd'hui à 12:30:39 pm »
Bonjour Bruno

On peut considérer plusieurs approches sur la problématique que tu soulignes.

Dans chacune des implémentations il y a toujours des avantages et des inconvénients.

Américains et européens ont d ailleurs des pratiques différentes.

Dans tous les cas il faut adapter les protection au niveau le plus adéquat et donc garantir que celles si sont calibrées au plus juste sur l ensemble de la chaine.

Si pour certains composants il y a des plages étendues de puissance ou de dissipation, leurs congénères dans les montages n'offrent pas toujours cette possibilité/facilité d intégration.

Protéger de 2 à 4A est souvent plus simple que de protéger au delà. (cout, choix de composants, volumes, ...)

Il faut éviter les puissance trop "excessives".
Etudier et estimer les besoins finement est une étape facteur clé de succès.
On peut pour des raisons de cout planifier des mises en œuvres intermédiaires et itératives.

On aura intérêt aussi à privilégier une uniformité dans les solutions ( bien qu'inter compatibles entre elles ( le plus souvent) , préférer rester au sein d une marque qui donne satisfaction ne présente pas que des désavantages!)

Plus pragmatiquement le problème des puissances repartie repose sur leur synchronisation inter zones. Il y a des solutions (ex le BTM-SG de LDT: https://www.ldt-infocenter.com/dokuwiki/doku.php?id=fr:ldt-infocenter)
Il faut donc étudier les mises en œuvre et viser à se simplifier les choses autant que possible.

Au niveau "bonnes pratiques" on peut considérer que l'approche 1 BOOSTER pour la TRACTION + 1 BOOSTER pour les accessoires +1 centrale est une base solide dont l'évolution et la maintenance sont simplifiés.
On ne se sert pas de la sortie track/voie de la centrale et on ne confie les conso que sur des boosters similaires pour des usages identiques.
On renforce au besoin par des boosters additionnels par secteurs.

A 20A pas de doute qu'on arrivera facilement à souder sur la voie le matériel moteur/capteur si les protections sont inadaptées.
Il faut surement se montrer plus raisonnable à ce niveau.
Quel est le bon calibre? 3A 4A 5A 8A? a chacun d y regarder de plus prêt avec les équipements mis en œuvre

Au plus prêt de la voie il est rare de dépasser 3A.( toutes échelles confondues <= au O) et on se situera plutôt à 50% de cette valeur mais plus on remonte et on consolide des sections et plus les appels peuvent arriver sur un chiffre élevé.
Il faut donc équilibrer au plus juste et plutôt "vers le bas"

Quelques dessins pourraient aider mais je n ai pas le temps la de m y coller...

Dsl
Ltr


3
Vos projets / Re : RailCom: Générateur de CutOut avec booster
« le: mai 22, 2024, 05:17:28 pm »
Bonjour

Comme je l'ai explique sur le post de présentation des fonctionnalités des AVR avec les librairies DXCORE MEGATINYCORE et MEGACOREX, je poursuis les tests en vue de la mise en œuvre.

Quelques corrections de syntaxes ont été rendues nécessaires.

Quelques tests aussi ont montré une impossibilité de combiner certains éléments (sortie PA7 du CCL0 (LUT0) sur un ATTINY826. Pas de raison identifiée. Elle est cependant opérationnelle sur un autre bloc.

Ces tests très utiles sont la pour bien vérifier le bon comportement comme attendu.

A suivre donc...

4
Bonjour

Malgré un emploi du temps pro bien chargé les tests se poursuivent.

J ai d abord des corrections à apporter dans les exemples fournis sur la partie EVENT.

Il faut en effet utiliser set_generator() en lieu et place de assign_generator() dans la syntaxe fournie


#include "Event.h"

void INIT_EVENT()
{
  //Event0.set_generator(gen0::pin_pa1); // OK BUT USE NEXT LINE FOR BETTER EFFCIENTCY
  Event0.set_generator(PIN_PA1); //BETTER & FASTER
  Event0.set_user(user::ccl2_event_a);          //EVENT A OF LUT2

  Event0.start();

  Event1.set_generator(gen::ccl2_out);
  //Event1.set_user_pin(user::evouta_pin_pa2); //route on PA2
  //Event1.set_user_pin(user::evouta_pin_pa7); //route on PA7
  Event1.set_user_pin(PIN_PA7); //route on PA7

  Event1.start();
 
}




Il est recommandé lorsque cela est possible de "passer en dur" certains éléments comme les broches d'entrée ou de sortie. ( on peut mettre des alias si besoin de portabilité et des simplifications de modifications en volume)( sinon se tourner vers assign_generator() (se rapporter aux notices des librairies)

Les tests se poursuivent.

Notez que lors de mes tests sur un ATTINY826 je ne suis pas parvenu à utiliser la sortie "MUX" vers PA7 du bloc CCL0 ( LUT0). BUG? 
Attention peu de PIN sont utilisables pour ces usages. (PORTx PIN 2 et PIN 7 si présentes!)
(voir datahseet du composant)

De plus si vous utiliser 1 sortie EVENOUTx c est exclusif sur le port en question, vous ne pouvez pas utiliser la pin alternative sur un autre event. ( en gros c est dessert OU fromage MAIS PAS LES DEUX!)
Donc vigilance dans les usages d'attribution!!

Il est donc prudent de tester unitairement aussi chaque élément!...



5
Attention dans le cas d usage du CPU vs le NE55X je ne suis pas certain de ton schéma

Voici la version de travail de laquelle j étais partie.( et qu il faut éprouver et reprendre au besoin)

Ltr


6
C est paracerque j ai déjà beaucoup travaillé en amont rien de plus!

Cette version dispose d un petit potentiomètre pour régler de façon externe au code la sensibilité du seuil de bascule ( dans le montage à base de NE555/NE556 cela se fait au 2/3 et 1/3 de V alim sur la lecture de la tension en entrée du NE55X.

Ici l idée est placer une valeur dans le code et de régler la tension lue en entrée via cet outils de réglage
Ainsi le CPU est une "boite noire" et tout se fait de façon externe.

Ce dispositif est tout aussi valable que le précèdent au rapport économique légèrement plus élevé.
Il aura peut être en revanche plus de réussite sur la bascule des led d indication que mon montage précèdent perfectible sur ce point.

7
Voila ce a quoi ressemble cette version à l étape de prototype à éprouver et completer


8
Bonjour Bruno

C est en effet une possibilité que j avais moi même aussi réalisé ( mais non publiée)

Economiquement elle semble toutefois plus onéreuse que la solution à base de NE555 que l'on va lui préféré dans ce cas.

Il faut vérifier que le montage dispose d un plot de programmation pour la broche UDPI pour un programme "in situ"

Cote code il n y a me semble t il pas trop de piège, on crée une boucle de lecture sur la broche d entrée venant de coil via le transistor et on permute les états en fonction d un seuil donné.( avec éventuellement un tempo si besoin)

On va regarder cote code ce que l on peut imaginer dessus.
Ce qui permettra de se familiariser aussi une fois encore avec cette famille de CPU.

Ltr

9
Bonjour

Le fonctionnement global de la carte de détection est validé.

Seul l inversion des leds selon l état est récalcitrant et n'est pas conforme à ce qui était attendu.
Toutefois le montage fonctionne avec un coil 1000 tours pour 1 à 4 passages sans soucis
L inversion d état en sortie se réalise bien avec la fermeture du pont de sélection.
La bascule s'opère au bout de 2.5 sec environ pour passer d'un état occupé à libre et d environ 1 sec pour un passage de libre à occupé.

Les tensions commuent alors de 0.5V à 5v et réciproquement.

Hormis donc la bascule des états des  leds selon les états qui devra être modifié au besoin tout fonctionne bien pour ce bouclier.



10
Vos projets / Re : RailCom: Générateur de CutOut avec booster
« le: mai 21, 2024, 10:49:32 am »
Bonjour Bruno

C est une option mais la mise en œuvre n'est pas si trivial.

Ltr

11
Vos projets / Re : RailCom: Générateur de CutOut avec booster
« le: mai 20, 2024, 08:21:05 pm »
Bonsoir Bruno

Je teste actuellement cette solution.
Je n'ai pas encore assez avancé pour publier le résultat ( autant ne publier que ce qui fonctionne!?) mais cela sera fait des que possible.

En effet on a bien l'équivalent des plots C et D.
Convertir les tensions ajoute de la complexité mais reste une option (à tester aussi)

Je n'ai pas travaillé sur une refonte de Labox intégrant un dispositif de cutout mais d autres membres du forum s'y consacrent.

Cela devrait aboutir dans de nouvelles propositions.

Ltr

12
Bnjour à tous.

J'ai corrige une petite erreur typographique présente dans les exemples donnés.

Sur les blocs logiques j avais simplement mi:

LogicN.enable;
Ce qui est faux et doit etre remplacé par:

LogicN.enable = true;
Ex
Logic2.enable = true;
Mea culpa!




13
Bonsoir

Oui cela me semble correcte.

Il n y a pas de plot equivalent E sur la BOX.

Sinon cela aurait cette forme:

https://usuaris.tinet.cat/fmco/railcom_en.html#booster


14
Vos projets / Re : Éclairage voitures
« le: mai 19, 2024, 08:16:04 pm »
Bonsoir Fred

Tu t'attaques a un "gros morceau".

Je pense que ton idée est valable mais qu'elle va se heurter à quelques déconvenues.
Aussi je pense te donner des indications pour éviter de "dérailler". Cela ne doit pas te décourager ou t empêcher de tester tes montages.

Théoriquement le concept 1 fil parait possible mais il n est pas recommandé car il y a des conditions très particulières pour que cela soit opérationnel. Il vaut mieux "oublier".

Dans mon montage tu as vu 2 transistors l un passe la puissance pour les bandeaux de leds ( je ne recommande pas les rubans 12v... mais ca reste une option valable)  l'autre les instructions de commande venant d un décodeur DCC.

Ces 2 montages n ont pas les mêmes entrées sorties et tensions c est la raison de la présence de ces 2 composants ( l un est un NPN (rouge noir)
l autre un NMOSFET type (BSS138 par exemple).
Le second pilote le 1er.

Chacun agissant dans une boucle (presque) dédiée en quelque sorte.

Les rectangles sont des résistances dont il faudra calculer les valeurs.

Le BUS a forcement 2 fils le + et le -.( départ et retour si tu préfères.)

Rassure toi il m'arrive toujours d'avoir des montages qui ne fonctionnent pas toujours comme attendus.
A défaut de maitriser des outils de simulation il faut tester "en live" et reprendre ce qui ne fonctionne pas comme attendu.

Tu as de quoi expérimenter!
Lance toi sur un montage a blanc sur un plaque d essai. Tu eprouveras ainsi mieux les solutions.



15
C est la méthode que je teste actuellement. (sur un ATTINY826) ( avec la partie "logic", "event" n cie)

Dans l'ISR du TIMER affecté au décodage des trames DCC:


//------------------------------------------- ISR ----------------------------------------------------
ISR(DCC_TIMER_INT_vect) {

  DCC_TIMER.EVCTRL ^= TCB_EDGE_bm;                          // Change the event edge at which we trigger
  uint16_t  delta = DCC_TIMER.CCMP;                        // Delta holds the time since the previous interrupt
  uint8_t DccBitVal;

  if ((delta >= ONE_BIT_MIN) && (delta <= ONE_BIT_MAX)) {
    if (dccHalfBit & EXPECT_ONE) {                     // This is the second part of the 1 bit
      dccHalfBit = EXPECT_ANYTHING;
      DccBitVal = 1;
    }
    else if (dccHalfBit & EXPECT_ANYTHING) {           // This is the first part of the 1 bit
      dccHalfBit = EXPECT_ONE;
      return;
    }
    else {                                             // We expected a 1, but received 0 => abort
      DCC_TIMER.EVCTRL ^= TCB_EDGE_bm;                     // Likely J/K should be changed
      dccHalfBit = EXPECT_ANYTHING;
      dccrecState = WAIT_PREAMBLE;
      dccrec.bitCount = 0;
      return;
    }
  }
  else if ((delta >= ZERO_BIT_MIN) && (delta <= ZERO_BIT_MAX)) {
    if (dccHalfBit & EXPECT_ZERO) {                    // This is the second part of the 0 bit
      dccHalfBit = EXPECT_ANYTHING;
      DccBitVal = 0;
      }
    else if (dccHalfBit & EXPECT_ANYTHING) {           // This is the first part of the 0 bit
      dccHalfBit = EXPECT_ZERO;
      return;
    }
    else {                                             // We expected a 0, but received 1 => abort
      dccHalfBit = EXPECT_ANYTHING;
      dccrecState = WAIT_PREAMBLE;
      dccrec.bitCount = 0;
      return;
    }
  }
  else {
    // We ignore other halfbits, to avoid interference with orther protocols.
    // In case railcom would be implemented, here we could detect the cutout start (26..32us)
    return;
  } 


  dccrec.bitCount++;

  switch( dccrecState )
  {
    // According to NMRA standard S9.2, a packet consists of:
    // - Preamble
    // - Packet Start Bit
    // - Address Data Byte:
    // - Data Byte Start Bit + Data Byte [0 or more times]
    // - Packet End Bit

    case WAIT_PREAMBLE:
        // The preamble to a packet consists of a sequence of "1" bits.
        // A digital decoder must not accept as a valid, any preamble
        // that has less then 10 complete one bits
        if( DccBitVal )                                   // a "1" bit is received
        {
          if( dccrec.bitCount > 10 )
            dccrecState = WAIT_START_BIT;
        }
        else
        {
          dccrec.bitCount = 0;                            // not a valid preamble.
        }
    break;

    case WAIT_START_BIT:
      // The packet start bit is the first bit with a value of "0"
      // that follows a valid preamble. The packet start bit terminates the preamble
      // and indicates that the next bits are an address data byte
      if( !DccBitVal )                                  // a "0" bit is received
      {
        dccrecState = WAIT_DATA;
        dccrec.tempMessageSize = 0;
        // Initialise all fields
        uint8_t i;
        for(i = 0; i< MaxDccSize; i++ )
        {
          dccrec.tempMessage[i] = 0;
        } 
        dccrec.bitCount = 0;     
      }

    break;

    case WAIT_DATA:
      //==================
      if( dccrec.bitCount == 8 )                        // byte is complete
      {
        if(dccrec.tempMessageSize == MaxDccSize )       // Packet is too long - abort
        {
          dccrecState = WAIT_PREAMBLE;
          dccrec.bitCount = 0;
        }
        else
        {
          dccrecState = WAIT_END_BIT;                  // Wait for next byte or end of packet
        }
      }

    break;

    case WAIT_END_BIT:
      // The next bit is either a Data Byte Start Bit or a Packet End Bit
      // Data Byte Start Bit: precedes a data byte and has the value of "0"
      // Packet End Bit: marks the termination of the packet and has a value of "1"
 
      if(DccBitVal) // End of packet?
      {
        // Complete packet received and no errors
        // we are in a CUTOUT AREA NOW
        noInterrupts();
        //no new external event change the sequence actions queue above till queue is over,
        //just add ~500ms latency on any AC0 notifications by interrupt
       
          CUTOUT(bitRead(RAILCOM,0)); //proceed cutout till end of it
         
          //cutout is over now, continue

          dccrecState = WAIT_PREAMBLE; //next step will be at this state

        interrupts();   
     
      }
      else  // Get next Byte   
      {
        dccrecState = WAIT_DATA;
        dccrec.bitCount = 0;                              // prepare for the next byte 
      }   
   
    break;
  }
}


fonction CUTOUT:


void CUTOUT(bool RAILCOM_ACTIV_OR_NOT){
 
  if(RAILCOM_ACTIV_OR_NOT == false) //NO RAILCOM CUTOUT TO INSERT
  {
    //BY PASS CUTOUT: FORCE SOME PINS STATE ON:
    LOGIC_ENABLE_OUT_PIN_ON;
    LOGIC_CUTOUT_OUT_PIN_ON;

    return;
  }

  //RAILCOM ACTIV: NEED TO INSERT CUTOUT
 
  //TIMER B IS ALREADY STARTED AND CNT GO UP     
  if(DCC_TIMER.CNT < ENABLE_STOP_TIME) //< 26us
  {
    //ENABLE ON
    LOGIC_ENABLE_OUT_PIN_ON;
    while(DCC_TIMER.CNT < ENABLE_STOP_TIME) {;}; //WAIT TILL IS OVER
  }
  else if((DCC_TIMER.CNT < CUTOUT_START_TIME) && (DCC_TIMER.CNT >= ENABLE_STOP_TIME)) // >=26us & <30us
  {
    //ENABLE OFF
    LOGIC_ENABLE_OUT_PIN_OFF;
    while(DCC_TIMER.CNT < CUTOUT_START_TIME) {;}; //WAIT TILL IS OVER
  }
  else if((DCC_TIMER.CNT < CUTOUT_STOP_TIME) && (DCC_TIMER.CNT >= CUTOUT_START_TIME)) // >=30us & <484us
  {
    //MAKE CUTOUT:
    LOGIC_CUTOUT_OUT_PIN_ON;
    while(DCC_TIMER.CNT < CUTOUT_STOP_TIME) {;}; //WAIT TILL IS OVER
  }
  else if((DCC_TIMER.CNT < ENABLE_START_TIME) && (DCC_TIMER.CNT >= CUTOUT_STOP_TIME)) // >=484 us & < 488us
  {
    //STOP CUTOUT
    LOGIC_CUTOUT_OUT_PIN_OFF;
    while(DCC_TIMER.CNT < ENABLE_START_TIME) {;}; //WAIT TILL IS OVER
  }
  else if ((DCC_TIMER.CNT >= ENABLE_START_TIME)) // >=488us
  {
    //ENABLE PIN ON:
    LOGIC_ENABLE_OUT_PIN_ON;

    //CUTOUT IS OVER

  }
}




Comme tu le soulignes on a en fait une sortie cote ESP32 qui est une source DCC "universelle" ( voir non amplifiée)  qui peut ensuite être distribuée à tous les CPU effectuant le CUTOUT qui pilotent eux les ponts en H. (L6203 pour  mon cas)
On est alors aligné sur tous les segments.
Les sorties de l'ESP32 sont alors assimilables aux plots CD sur les centrales LENZ pour la synchro inter booster

Pour moi le Security Gap reste de mise pour écarter tout écart restant inter booster lorsqu'un véhicule reste à cheval puisque chaque électronique peut encore varier d'un pouillième...

Il y a donc bien une recomposition du signal entre l'émetteur (EP32) et tous les consommateurs (derrière le(s) pont(s) H) d'un un léger décalage mais qui est constant entre la source unique et tous les consommateurs.

Pages: [1] 2 3 ... 42