Multisinus le paradoxe

[Lolo69]

Avec un SSR en multisinus j’ ai diminué la précision du multi sinus pour augmenter la précision de la régulation et ….. ça marche.

Pour rappel le multisinus F1ATB consiste à calculer des couples T et N pour chaque pourcentage de sortie du régulateur.
Pour avoir une précision théorique de +- 0.5% André a fixé dans son code Tmax = 100 et Tmin à 20.  Ce qui donne des périodes total de 200 à 1000ms.
Par exemple pour une sortie régulateur à 25% cela donne un couple N/T de 6/24 ce qui se traduit par 6 ON suivi de 18 OFF donc une période de 240ms
Ce qui est 24 fois plus qu en mode découpe de sinus….
Et surtout les ON sont tous en début de trame ce qui fausse beaucoup la mesure du Shelly. 

La modification que j ai implémenté part sur TMax = 50 et Tmin = 5 
Donc une période total de 50 à 500 ms et surtout je répartis les ON sur toutes la période ce qui fait une moyenne plus lisse pour une mesure Shelly bien plus précise
Par exemple pour la même sortie 25 % cela me donne 2/8 donc une période de 80 ms( au lieu de 240 pour F1ATB) répartis comme suivant
10001000
Cela donne une période beaucoup plus courte ( donc réactif) et une moyenne lissée sur 4 demi sinusoïde ( au lieu de 12)

En image cela donne les résultats suivants


Avant 
   

Après
   

[grostoto]

Valable avec une mesure shelly (assez lent) ou toutes les types de mesure ?

[Lolo69]

Pour tout type de mesure mais uniquement pour le multi sinus

[Ludovic35]

L'idée de raccourcir la période est intéressante.
Est-ce que le Tmax à 50 dégrade l'erreur sur certaines valeurs de % (il était < 0.4% avant)?
Le fait d'avoir plus de transitions, cela dégrade-t-il le résultat? (les SSR ayant un zéro cross, l'erreur au démarrage va arriver plus souvent; + un effet de glissement si ce n'est pas synchrone)

[Lolo69]

L'idée de raccourcir la période est intéressante.
Est-ce que le Tmax à 50 dégrade l'erreur sur certaines valeurs de % (il était < 0.4% avant)?
Le fait d'avoir plus de transitions, cela dégrade-t-il le résultat? (les SSR ayant un zéro cross, l'erreur au démarrage va arriver plus souvent; + un effet de glissement si ce n'est pas synchrone)

l idée etait surtout de repartir les ON
oui le TMAX degrade l'erreur , mais le regulateur recupere rapidement cette erreur... c est le paradoxe, l erreur est plus grande mais comme la boucle reagit plus vite, c est plus rapidement corrigé, donc l'erreur de façon globale à moins d'impact. 
L'erreur de demarrage arrive sans doute plus souvent mais encire une fois sur deux ou 3 trames de 50ms cela ne se voit pas sur les courbes, et dans la pratique on ne reste pas longtemps au meme pourcentage, donc le glissement possible est naturellement effacé. Je n'ai pas encore fait toutes simulations pour vous montrer les différents scenarii possible , mais mes courbes de puissance parlent d elles mêmes. J'ai eu la flemme de faire le test en 3 étapes
- Etape 1 :  on ne change pas la période, mais on repartit les ON
- Etape 2 : On change la période sans répartir
- ETape 3 : On réduit la périude et on réparti.

Pour les habitués de l Arduino , les modifs de codes sont les suivantes ( difficile de vous donner les num de lignes car je suis parti depuis ma propre version derivée de la 15.08 d André

pour la période ca si situe autour des lignes 730  

Code :

//lbe VALEUR D ORIGINE for (int I = 0; I < 101; I++) {
  for (int I = 0; I < 101; I++) {
    tabPulseSinusTotal[I] = 3;
    tabPulseSinusOn[I] = 0;
    target = float(I) / 100.0;
    //lbe VALEUR D ORIGINE for (int T = 20; T < 101; T++) {
    for (int T = 3; T < 51; T++) { //Réduit la précision , augmente la réactivité
      for (int N = 1; N <= T; N++) {
        if (T % 2 == 1 || N % 2 == 0) {  // Valeurs impaires du total ou pulses pairs pour éviter courant continu
          vrai = float(N) / float(T);
          erreur = abs(vrai - target);
          if (erreur < 0.003) {
            tabPulseSinusTotal[I] = T;
            tabPulseSinusOn[I] = N;
            // lbe valeur origine N = 101;
            // lbe valeur origineT = 101;
            N = 51;
            T = 51;
          }
        }
      }
    }
  }

pour la repartiton c est autour des lignes 640 

Code :

      default:              // Multi Sinus ou Train de sinus
        //if (Gpio[i] > 0) {  //Gpio valide
        //  if (PulseComptage[i] < PulseOn[i]) {
        //    digitalWrite(Gpio[i], OutOn[i]);
        //  } else {
        //    digitalWrite(Gpio[i], OutOff[i]);  //Stop
        //  }
        //  PulseComptage[i] = PulseComptage[i] + 1;
        //  if (PulseComptage[i] >= PulseTotal[i]) {
        //    PulseComptage[i] = 0;
        //  }
        //}
        // lbe REPARTITION DES ON
        if (Gpio[i] > 0 && PulseTotal[i] > 0) {
  // Répartition uniforme des ON dans la trame complète
  // Exemple : PulseOn = 4, PulseTotal = 10 -> ON sur les index 0,2,5,7
  int on_count = PulseOn[i];
  int total = PulseTotal[i];
  int pos = PulseComptage[i];

  // Répartition uniforme avec espacement : version simple sans tableau
  if ((pos * on_count) % total < on_count) {
    digitalWrite(Gpio[i], OutOn[i]);
  } else {
    digitalWrite(Gpio[i], OutOff[i]);  //Stop
  }

  PulseComptage[i]++;
  if (PulseComptage[i] >= total) {
    PulseComptage[i] = 0;
  }

[Ludovic35]

Bien vérifier que la condition (erreur < 0.003) est bien trouvée pour chaque valeur de % (sinon, il y aurait un trou).
Ca pourra être un moyen d'améliorer le multi-sinus.
Je suis curieux de savoir quelle partie a le plus d'impact sur le résultat.
Les 2 questions que je me pose:
- est-ce qu'il y a une différence au niveau des harmoniques?
- y a-t-il une différence entre ZC SSR et random SSR?

[Lolo69]

Bien vérifier que la condition (erreur < 0.003) est bien trouvée pour chaque valeur de %  (sinon, il y aurait un trou).
Ca pourra être un moyen d'améliorer le multi-sinus.
Je suis curieux de savoir quelle partie a le plus d'impact sur le résultat.
Les 2 questions que je me pose:
  - est-ce qu'il y a une différence au niveau des harmoniques?
  - y a-t-il une différence entre ZC SSR et random SSR?

tu as tout à fait raison car meme avec une erreur à 0.004 j'ai 4 trous dans la raquette, pour 1,99,33,67 % que j ai bouché à la main dans le tableau.
En tout cas je suis hyper content du résultat, mon routeur fonctionne beaucoup mieux qu'avant, du coup j ai deplacé le seuil pw à -15 , et je consomme moins de 4w/h edf pendant le routage et j injecte ....15w/h vers EDF. Mes resistances ne font aucune vibration audible, et la led du SSR clignote très régulièrement que je sois à 5 ou à 70% d'injection
Avant les modifs c etait au mieux consomme de 60w/h avev un seuil à -60  pour 80w/h d 'injection ( toujours moyenne pendant les heures de routage)

A l'occasion je referai des tests pour savoir si cette amélioration provient plutot de la repartition des ON ou plutot de la reduction du cycle ou alors lesdeux combinés

[grostoto]

Tu commences donc a obtenir les mêmes résultats qu'avec un uxi2 non bidouillé..(code j'entends).
C'est une bonne nlle pour les utilisateurs de Shelly.

[Lolo69]

Bien vérifier que la condition (erreur < 0.003) est bien trouvée pour chaque valeur de %  (sinon, il y aurait un trou).
Ca pourra être un moyen d'améliorer le multi-sinus.
Je suis curieux de savoir quelle partie a le plus d'impact sur le résultat.
Les 2 questions que je me pose:
  - est-ce qu'il y a une différence au niveau des harmoniques?
  - y a-t-il une différence entre ZC SSR et random SSR?

Pour le niveau d'harmoniques je ne suis pas assez expert pour faire un simulateur et je n'ai pas de materiel pour les mesurer......en tout cas je ne vois pas d'effet même sur des ampoules basse consommations , ni de vibration mecanique suspens meme sur un tromblon de convecteur ou les resistances sont à peines fixées. Sur le CE je n'entend plus rien ( ce qui ne prouve pas l absence de vibrations car elles sont surement à plus hautes fréquences) 

comme la très grande majorité des SSR sont des ZC je je ne pense pas que ca soit plus mauvais car de toutes façon le triac interne est amorcé au passage à zero.
je n ' ai pas de SSR random sous la main , mais je pense qu'avec un SSR random ce serait meilleur en précision mais moins bon en harmoniques...

---

Tu commences donc a obtenir les mêmes résultats qu'avec un uxi2 non bidouillé..(code j'entends).
C'est une bonne nlle pour les utilisateurs de Shelly.

Oui c 'est tout à fait ça, car je trouve un certain nombre d'avantages au Shelly et là je rabote ses inconvénients.

S'il y a des volontaires qui veulent tester je peux les aiguiller pour avoir plusieurs avis sur le sujet.

[Juju67]

Salut,

Je suis tombé sur ce fil un peu par chance car je suis exactement dans la même configuration matérielle: lecture de puissance avec un Shelly EM, pilotage avec un SSR (non random)

Et je suis également un peu gêné par la régulation de base:
- Si la lecture de puissance se fait au moment où la trame multi-sinus est envoyées, le routeur voit une puissance consommée trop élevée et diminue donc le pilotage
- Au contraire si la lecture de puissance se fait pendant une période de non routage, le routeur voit une puissance injectée est trop élevée et donc augment le pilotage 

J'avais pensé implémenter un moyennage des puissances lues pour lisser les aléas de lecture, mais ce fil me donne une autre approche qui me plait bien.
Je voudrais avoir un petit retour d'expérience avant de me lancer dans la modification du code, histoire d'implémenter la meilleure version

Pour info, je suis sous version 13.03 du routeur f1atb