LPP » INSTRU » Solar Orbiter LFR » LFR-FSW

thomas chust wrote in #note-2:

Bruno, ce sont les matrices par défaut que tu as jouées et non les unitaires ... ? Ah j'y suis, c'est juste une question du nom des fichiers qui m'a confondu ...

Oui j'ai laissé le nom DefaultKCOEFF juste pour dire que j'ai laissé les KCOEFF par défaut du boot de LFR. En 3.2.0.24 il n'y a pas de notion de matrices unitaires, ce sont encore des KCOEFF.

J'ai vérifié quand même que mon tableau python du script en 3.3.0.7 chargeait bien les bonnes valeurs pour les matrices unitaires : testé OK, les valeurs sont exactement celle du tableau de Thomas.

J'ai du mal à voir où peut se trouver le bug vu que le code est pas mal partagé entre F0 et F1.
J'ai créé un branche avec des matrices unitaires par défaut, ça devrait permettre de discriminer entre un bug au niveau calcul Vs niveau upload des matrices.
Bruno, peux-tu tester avec ça sans faire d'upload des matrices:
https://hephaistos.lpp.polytechnique.fr/teamcity/buildConfiguration/LfrFlightSoftware_BuildLpp?branch=unit_cal_matrices&mode=builds

Pour info, voici les modifs dans le notebook:
https://github.com/LaboratoryOfPlasmaPhysics/LFR_Flight_Software/blob/83a04417630b7bfe1feb46769f2bd63e37d699b5/python_scripts/CalibrationMatricesInit_codeGen.ipynb
Et le fichier de matrices résultant:
https://github.com/LaboratoryOfPlasmaPhysics/LFR_Flight_Software/blob/83a04417630b7bfe1feb46769f2bd63e37d699b5/src/processing/calibration_matrices.c

Alexis, pourquoi ces matrices unitaires ont la dimension nfreq+1 alors qu'il n'y pas d'interpolation à partir de celles-ci, non ?

Je comprends pas ta question.

Alexis Jeandet wrote in #note-9:

Je comprends pas ta question.

Dans le notebook:

START_INDEXES=[16, 5, 6]
#+1 on sizes for interpolation with TC LOAD KCOEFS
SIZES=[88+1, 104+1, 96+1]

Comme si tu envisageais d'interpoler. ?

thomas chust wrote in #note-11:

Alexis Jeandet wrote in #note-9:

Je comprends pas ta question.

Dans le notebook:

START_INDEXES=[16, 5, 6]
#+1 on sizes for interpolation with TC LOAD KCOEFS
SIZES=[88+1, 104+1, 96+1]

Comme si tu envisageais d'interpoler. ?

Je vois vraiment pas ce qui te fait dire ça, justement SIZES⁰ c'est 88+1 et pas 88/8.

Si tu n'interpoles pas normalement 88 c'est suffisant, non ?

thomas chust wrote in #note-14:

bruno katra wrote in #note-10:

Alexis Jeandet wrote in #note-6:

J'ai du mal à voir où peut se trouver le bug vu que le code est pas mal partagé entre F0 et F1.
J'ai créé un branche avec des matrices unitaires par défaut, ça devrait permettre de discriminer entre un bug au niveau calcul Vs niveau upload des matrices.
Bruno, peux-tu tester avec ça sans faire d'upload des matrices:
https://hephaistos.lpp.polytechnique.fr/teamcity/buildConfiguration/LfrFlightSoftware_BuildLpp?branch=unit_cal_matrices&mode=builds

J'ai refait les runs avec la version 3.3.0.7 "speciale" compilée par Alexis c'est ici :

https://ao.lpp.polytechnique.fr/index.php/apps/files/?dir=/LFR/3.3.0.7/PREL-10&fileid=2508328

Analyse faite (notebook VERIF_LFR_FSW_R3_3_Bruno_20220317.html attaché): pas de changement par rapport au run avec 3.3.0.7 et KCOEFF unitaires
=> bug dans l'implémentation des matrices de calibration ou dans le stockage des résultats ?

J'ai eu ALexis au téléphone qui a décommuté les données : en regardant les ascii il trouve qu'il n'y a pas tant de 0 que ça dans les termes non-diagonaux de F1. Les matrices F1 sont d'ailleurs assez similaires aux matrices à F2 et F0.
J'ai regardé aussi de mon côté, voici mes observations :

1. PA_LFR_PKT_NR_ASM: ) ==> Il faut donc 3 blocs ascii pour reconstituer les 88 ASM de F0 par exemple.

- Je vois en effet des grosses sections de 0 mais toujours dans le bloc 2/3 des matrices.

- Je pense que ce que Thomas voulait dire c'est que l'on voit des 0 dans les termes non-diagonaux * mais de l'ASM correspondant à la frequence injectée* : Thomas?

- Même dans ce cas : je ne vois pas que ce soit spécialement les termes non-diagonaux exactement, si on prend l'exemple de de l' ASM@F1 (5x5) correspondant aux 912Hz injecté, on a :

20753868.000 0.0000000000 0.0000000000 0.0000000000 0.0000000000
0.0000000000 0.0000000000 0.0000000000 0.0000000000 20575776.00000
0.0000000000 0.0000000000 0.0000000000 0.0000000000 0.0000000000
0.0000000000 20704210.00 0.0000000000 0.0000000000 0.0000000000
0.0000000000 20396636.00 0.0000000000 0.0000000000 20595084.00000

Maintenant en effet il y a beaucoup de 0!

bruno katra wrote in #note-15:

- Je pense que ce que Thomas voulait dire c'est que l'on voit des 0 dans les termes non-diagonaux * mais de l'ASM correspondant à la frequence injectée* : Thomas?

oui

- Même dans ce cas : je ne vois pas que ce soit spécialement les termes non-diagonaux exactement, si on prend l'exemple de de l' ASM@F1 (5x5) correspondant aux 912Hz injecté, on a :

20753868.000 0.0000000000 0.0000000000 0.0000000000 0.0000000000
0.0000000000 0.0000000000 0.0000000000 0.0000000000 20575776.00000
0.0000000000 0.0000000000 0.0000000000 0.0000000000 0.0000000000
0.0000000000 20704210.00 0.0000000000 0.0000000000 0.0000000000
0.0000000000 20396636.00 0.0000000000 0.0000000000 20595084.00000

Maintenant en effet il y a beaucoup de 0!

Bah si c'est exactement ce que je dis: dans les 25 floats d'une asm à la fréquence visée, seules les termes non-diagonaux (les 1er, 10ème, 17ème, 22ème, et 25ème) ne sont pas nulles

Pour rappel ces 25 floats par fréquence sont rangés de la manière suivante:

NaN   B1       B2       B3       E1      E2   
 B1 00       01-02  03-04  05-06  07-08  
 B2 cc-cc   09     10-11  12-13  14-15  
 B3 cc-cc   cc-cc  16     17-18  19-20  
 E1 cc-cc   cc-cc  cc-cc  21     22-23  
 E2 cc-cc   cc-cc  cc-cc  cc-cc  24

Bah si c'est exactement ce que je dis: dans les 25 floats d'une asm à la fréquence visée, seules les termes non-diagonaux (les 1er, 10ème, 17ème, 22ème, et 25ème) ne sont pas nulles

Pour rappel ces 25 floats par fréquence sont rangés de la manière suivante:

NaN B1 B2 B3 E1 E2
B1 00 01-02 03-04 05-06 07-08
B2 cc-cc 09 10-11 12-13 14-15
B3 cc-cc cc-cc 16 17-18 19-20
E1 cc-cc cc-cc cc-cc 21 22-23
E2 cc-cc cc-cc cc-cc cc-cc 24

Ah oui pardon c'est vrai j'avais oublié comment était foutu les matrices avec juste la moitié... Du coup en effet TOUS les non diagonaux sont à 0.
D'ailleurs je remarque que cela concerne en gros aussi les ASM "autour" de la frequence injectée : un effet de la fenêtre de Hanning??

bruno katra wrote in #note-18:

Ah oui pardon c'est vrai j'avais oublié comment était foutu les matrices avec juste la moitié... Du coup en effet TOUS les non diagonaux sont à 0.
D'ailleurs je remarque que cela concerne en gros aussi les ASM "autour" de la frequence injectée : un effet de la fenêtre de Hanning??

oui (pour la fréquence centrale correspond aussi une fréquence juste avant et juste après plus faible)

Ah oui pardon c'est vrai j'avais oublié comment était foutu les matrices avec juste la moitié... Du coup en effet TOUS les non diagonaux sont à 0.
D'ailleurs je remarque que cela concerne en gros aussi les ASM "autour" de la frequence injectée : un effet de la fenêtre de Hanning??

oui (pour la fréquence centrale correspond aussi une fréquence juste avant et juste après plus faible)

Oui mais là ça a l'air un peu plus "large" : on voit bien les ASM juste à gauche et à droite à 0. + les 9 suivantes ?!?

A la demande de Thomas j'ai quand même vérifié les valeurs binaires dans le fichier avant décommutation et il y a bien les 0. aux mêmes positions ==> donc à priori pas de pb de decom

Autre confirmation, dans ce test, les ASMs à F1 sont/semblent différentes donc à priori calculées avec des données différentes à chaque fois.

Alexis Jeandet wrote in #note-22:

Ok, je confirme les observations et pour toutes les matrices du test

Du coup, j'ai une série de questions et de tests à faire pour mieux cerner le PB:
1. Thomas, peux tu me dire si c'est possible de valider le calcul via les BP? En gros je voudrais savoir si l'ASM qui est en mémoire dans LFR est bonne ou pas.

Je viens de regarder rapidement, visuellement, les fichiers ascii décommutés des BP2 à F2, F1 et F0:
- a priori tout semble faux car on ne voit rien (de particulier, du bruit) sur les termes diagonaux aux fréquences injectées ...

Du coup, j'ai une série de questions et de tests à faire pour mieux cerner le PB:
1. Thomas, peux tu me dire si c'est possible de valider le calcul via les BP? En gros je voudrais savoir si l'ASM qui est en mémoire dans LFR est bonne ou pas.
2. Bruno, est-il possible de faire un test plus long avec un sweep en fréquences pour balayer tous les bins (de F2 à F0) dans le même test et voir si c'est vraiment propre à F1 (ça peut être pire...).

Je vais faire un run avec sweep, mais avec quelles caractéristiques?

Ce qui est vraiment étrange, c'est que ça pourrait ressembler à une erreur stupide du genre faire un produit terme à terme au lieu d'un produit matriciel mais il n'y a qu'une seule fonction qui fait ce produit pour F0/F1/F2.

Je dirais de quoi avoir une fréquence différente pour chaque ASM et balayer tous bins de toutes les ASM.

Par exemple:
- pour F2 1Hz->128Hz par pas de 1Hz
- pour F1 128Hz->2048Hz par pas de 16Hz
- pour F0 1920Hz->9600Hz par pas de 96Hz

Dans tous les cas il faudrait maintenir le signal pendant la période de production des ASMs et toutes les enregistrer.

Je propose aussi de ne générer du signal que dans B1, B3, E1 et E2 pour aider à comprendre ce qu'il se passe.

bruno katra wrote in #note-25:

Du coup, j'ai une série de questions et de tests à faire pour mieux cerner le PB:
1. Thomas, peux tu me dire si c'est possible de valider le calcul via les BP? En gros je voudrais savoir si l'ASM qui est en mémoire dans LFR est bonne ou pas.
2. Bruno, est-il possible de faire un test plus long avec un sweep en fréquences pour balayer tous les bins (de F2 à F0) dans le même test et voir si c'est vraiment propre à F1 (ça peut être pire...).

Je vais faire un run avec sweep, mais avec quelles caractéristiques?

Vu avec Thomas : je vais refaire le même sweep que les tests de 3.2.0.24 : je balaie toutes les frequences propres de F1 une à une avec SWF et repassage en SDTBY pour chaque

Ce qui est vraiment étrange, c'est que ça pourrait ressembler à une erreur stupide du genre faire un produit terme à terme au lieu d'un produit matriciel mais il n'y a qu'une seule fonction qui fait ce produit pour F0/F1/F2.

bruno katra wrote in #note-27:

bruno katra wrote in #note-25:

Du coup, j'ai une série de questions et de tests à faire pour mieux cerner le PB:
1. Thomas, peux tu me dire si c'est possible de valider le calcul via les BP? En gros je voudrais savoir si l'ASM qui est en mémoire dans LFR est bonne ou pas.
2. Bruno, est-il possible de faire un test plus long avec un sweep en fréquences pour balayer tous les bins (de F2 à F0) dans le même test et voir si c'est vraiment propre à F1 (ça peut être pire...).

Je vais faire un run avec sweep, mais avec quelles caractéristiques?

Vu avec Thomas : je vais refaire le même sweep que les tests de 3.2.0.24 : je balaie toutes les frequences propres de F1 une à une avec SWF et repassage en SDTBY pour chaque

Test à faire en 3.3.0.7 ou 3.3.0.7 "special" (version recompilée avec les matrices identitaires au boot) ?

Ce qui est vraiment étrange, c'est que ça pourrait ressembler à une erreur stupide du genre faire un produit terme à terme au lieu d'un produit matriciel mais il n'y a qu'une seule fonction qui fait ce produit pour F0/F1/F2.

Test CTC-901 joué :

Je balaie toutes les frequences F1 de LFR :

[ 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320
336 352 368 384 400 416 432 448 464 480 496 512 528 544 560
576 592 608 624 640 656 672 688 704 720 736 752 768 784 800
816 832 848 864 880 896 912 928 944 960 976 992 1008 1024 1040
1056 1072 1088 1104 1120 1136 1152 1168 1184 1200 1216 1232 1248 1264 1280
1296 1312 1328 1344 1360 1376 1392 1408 1424 1440 1456 1472 1488 1504 1520
1536 1552 1568 1584 1600 1616 1632 1648 1664 1680 1696 1712 1728 1744]

Pour chacune :
- on injecte la fréquences pendant 47s (plusieurs ASM + 1 SWF) sur V, E1, E2, B1, B2 et B3.
- on n'enregistre qu'à partir de la 10eme seconde pour être sur de ne pas enregistrer les 2 premières ASM
- On repasse en SDTBY
- On passe à la fréquence suivante.

Chaque fréquence est dans un fichier différent.

Les dumps sont là :
https://ao.lpp.polytechnique.fr/index.php/apps/files/?dir=/LFR/3.3.0.7-unit/CTC-901&fileid=2509679

J'ai refait le run du sweep @F1 avec cette fois des amplitudes différentes pour les différentes entrées (demande d'Alexis), les résultats sont ici :

https://ao.lpp.polytechnique.fr/index.php/apps/files/?dir=/LFR/3.3.0.7-unit/CTC-901/run02&fileid=2511060

Voici le mapping Entrée/amplitude :
E1 : 0.5V
E2 : 1.0V
B1 : 1.5V
B2 : 2.0V
B3 : 2.5V

Le réperoire 'inputs' contient les fichiers de contexte pour trace.

Le run du sweep @F0 avecdes amplitudes différentes pour les différentes entrées (demande d'Alexis), les résultats sont ici :

https://ao.lpp.polytechnique.fr/index.php/apps/files/?dir=/LFR/3.3.0.7-unit/CTC-900&fileid=2511326

Voici le mapping Entrée/amplitude :
E1 : 0.5V
E2 : 1.0V
B1 : 1.5V
B2 : 2.0V
B3 : 2.5V

Le réperoire 'inputs' contient les fichiers de contexte pour trace.

Ok, donc, si je comprends bien, on a bien aussi le même bug à F0? Si c'est le cas, Bruno peux tu balayer aussi les fréquences à F2? Selon le résultat, ça pourra nous pointer un bug coté calcul ou TM.

Alexis Jeandet wrote in #note-37:

Ok, donc, si je comprends bien, on a bien aussi le même bug à F0? Si c'est le cas, Bruno peux tu balayer aussi les fréquences à F2? Selon le résultat, ça pourra nous pointer un bug coté calcul ou TM.

Oui il y a bien le même bug à F0.
Le test @F2 est en cours depuis ce matin 9h. Les résultats dans la matinée.

Génial!

Le run du sweep @F2 avecdes amplitudes différentes pour les différentes entrées (demande d'Alexis), les résultats sont ici :

https://ao.lpp.polytechnique.fr/index.php/apps/files/?dir=/LFR/3.3.0.7-unit/CTC-902&fileid=2512990

Voici le mapping Entrée/amplitude :
    E1 : 0.5V
    E2 : 1.0V
    B1 : 1.5V
    B2 : 2.0V
    B3 : 2.5V

Le réperoire 'inputs' contient les fichiers de contexte pour trace.

Idée Alexis : on relance en SBM1 pour voir si ça fait pareil.
Test en cours.

bruno katra wrote in #note-42:

Idée Alexis : on relance en SBM1 pour voir si ça fait pareil.
Test en cours.

Sweep F0 à SBM1 avec des amplitudes différentes pour les différentes entrées (demande d'Alexis), les résultats sont ici :

https://ao.lpp.polytechnique.fr/index.php/apps/files/?dir=/LFR/3.3.0.7-unit/CTC-910&fileid=2514147

Voici le mapping Entrée/amplitude :
E1 : 0.5V
E2 : 1.0V
B1 : 1.5V
B2 : 2.0V
B3 : 2.5V

Sweep F2 à SBM1 avec des amplitudes différentes pour les différentes entrées (demande d'Alexis), les résultats sont ici :

https://ao.lpp.polytechnique.fr/index.php/apps/files/?dir=/LFR/3.3.0.7-unit/CTC-912&fileid=2514400

Voici le mapping Entrée/amplitude :
E1 : 0.5V
E2 : 1.0V
B1 : 1.5V
B2 : 2.0V
B3 : 2.5V

thomas chust wrote in #note-46:

bruno katra wrote in #note-43:

Sweep F0 à SBM1 avec des amplitudes différentes pour les différentes entrées (demande d'Alexis), les résultats sont ici :

https://ao.lpp.polytechnique.fr/index.php/apps/files/?dir=/LFR/3.3.0.7-unit/CTC-910&fileid=2514147

Voici le mapping Entrée/amplitude :
E1 : 0.5V
E2 : 1.0V
B1 : 1.5V
B2 : 2.0V
B3 : 2.5V

Mêmes résultats (même bug) que pour CTC-900 (NM)

Question : Comment sont les ASM@F1 dans ce sweep qui couvre les freq @F0 ? Voit-on des termes non-diag à 0 aussi?

Sweep F1 à SBM1 avec des amplitudes différentes pour les différentes entrées (demande d'Alexis), les résultats sont ici :

https://ao.lpp.polytechnique.fr/index.php/apps/files/?dir=/LFR/3.3.0.7-unit/CTC-911&fileid=2514755

Voici le mapping Entrée/amplitude :
    E1 : 0.5V
    E2 : 1.0V
    B1 : 1.5V
    B2 : 2.0V
    B3 : 2.5V

Donc si je comprends bien, actuellement on peut dire que:

1. Le bug semble apparaître seulement à F0 et F1
2. Le bug semble déterministe et ne pas dépendre du mode

Par contre peux-tu confirmer les points suivants:

1. est-ce toujours exactement les mêmes fréquences qui sont impactées à F0 et F1 (tout le temps et dans tous les modes)
2. dans le cas de matrices de correction non unitaires, le reste du calcul est-il correcte?
3. Peut-on confirmer que pour toutes les fréquences qui semblent correctes avec des matrices unitaires, on a bien appliqué la bonne matrice et pas celle d'une autre fréquence (question similaire à la question précédente)?
4. Peux-tu donner les plages d'indices exactes où le bug apparaît à F0 et F1?

Alexis Jeandet wrote in #note-53:

Donc si je comprends bien, actuellement on peut dire que:

1. Le bug semble apparaître seulement à F0 et F1
2. Le bug semble déterministe et ne pas dépendre du mode

Oui

Par contre peux-tu confirmer les points suivants:

1. est-ce toujours exactement les mêmes fréquences qui sont impactées à F0 et F1 (tout le temps et dans tous les modes)

Oui jusqu'à présent

1. dans le cas de matrices de correction non unitaires, le reste du calcul est-il correcte?

Je sais pas. En tout cas dans le cas de matrices de correction unitaires, les termes diagonaux sont correctes (seuls les termes non-diagonaux sont à 0)

1. Peut-on confirmer que pour toutes les fréquences qui semblent correctes avec des matrices unitaires, on a bien appliqué la bonne matrice et pas celle d'une autre fréquence (question similaire à la question précédente)?

Je sais pas comment faire ... ?

1. Peux-tu donner les plages d'indices exactes où le bug apparaît à F0 et F1?

A F0: les termes non-diagonaux à 0 concernent 20 fréquences de la 32+5ème à la 32+24ème inclus
A F1: les termes non-diagonaux à 0 concernent 11 fréquences de la 36+15ème à la 36+25ème inclus (la 36+14ème et la 36+26ème sont également concernées pour certaines paires de signaux, pas toutes)

1. dans le cas de matrices de correction non unitaires, le reste du calcul est-il correcte?

Je sais pas. En tout cas dans le cas de matrices de correction unitaires, les termes diagonaux sont correctes (seuls les termes non-diagonaux sont à 0)

Pour une première idée : je vais regarder les ASM dans un des runs 3.3.0.7 avec les matrices par défaut pour voir déjà si on voit des 0.

thomas chust wrote in #note-54:

Alexis Jeandet wrote in #note-53:

Donc si je comprends bien, actuellement on peut dire que:

1. Le bug semble apparaître seulement à F0 et F1
2. Le bug semble déterministe et ne pas dépendre du mode

Oui

Par contre peux-tu confirmer les points suivants:

1. est-ce toujours exactement les mêmes fréquences qui sont impactées à F0 et F1 (tout le temps et dans tous les modes)

Oui jusqu'à présent

1. dans le cas de matrices de correction non unitaires, le reste du calcul est-il correcte?

Je sais pas. En tout cas dans le cas de matrices de correction unitaires, les termes diagonaux sont correctes (seuls les termes non-diagonaux sont à 0)

1. Peut-on confirmer que pour toutes les fréquences qui semblent correctes avec des matrices unitaires, on a bien appliqué la bonne matrice et pas celle d'une autre fréquence (question similaire à la question précédente)?

Je sais pas comment faire ... ?

Je dirais à partir des résultats avec les matrices par défaut. Soit c'est OK, soit c'est n'importe quoi. Dans ce cas avec les matrices unitaires ce serait tout aussi faux mais par chance, ça donnerait des résultats "corrects".

1. Peux-tu donner les plages d'indices exactes où le bug apparaît à F0 et F1?

A F0: les termes non-diagonaux à 0 concernent 20 fréquences de la 32+5ème à la 32+24ème inclus
A F1: les termes non-diagonaux à 0 concernent 11 fréquences de la 36+15ème à la 36+25ème inclus (la 36+14ème et la 36+26ème sont également concernées pour certaines paires de signaux, pas toutes)

1. Peut-on confirmer que pour toutes les fréquences qui semblent correctes avec des matrices unitaires, on a bien appliqué la bonne matrice et pas celle d'une autre fréquence (question similaire à la question précédente)?

Je sais pas comment faire ... ?

Je dirais à partir des résultats avec les matrices par défaut. Soit c'est OK, soit c'est n'importe quoi. Dans ce cas avec les matrices unitaires ce serait tout aussi faux mais par chance, ça donnerait des résultats "corrects".

Je viens de regarder les fichiers ascii du run du 10 mars à F0 avec kcoeff par défaut, "F0-3168Hz-2Vpp_on_E1E2B1B2B3-DefaultKCOEFFMatrices". J'observe pareil les termes non-diagonaux des fréquences de la 32+5ème à la 32+24ème inclus sont à 0 mais que pour
B1E1
B1E2
B2E1
B2E2
B3E1
B3E2
Im(E1E2)

Idem pour le fichier à F1 (du même run): J'observe pareil les termes non-diagonaux des fréquences de la 36+15ème à la 36+25ème inclus sont à 0 mais que pour
B1E1
B1E2
B2E1
B2E2
B3E1
B3E2
Im(E1E2)

thomas chust wrote in #note-57:

1. Peut-on confirmer que pour toutes les fréquences qui semblent correctes avec des matrices unitaires, on a bien appliqué la bonne matrice et pas celle d'une autre fréquence (question similaire à la question précédente)?

Je sais pas comment faire ... ?

Je dirais à partir des résultats avec les matrices par défaut. Soit c'est OK, soit c'est n'importe quoi. Dans ce cas avec les matrices unitaires ce serait tout aussi faux mais par chance, ça donnerait des résultats "corrects".

Je viens de regarder les fichiers ascii du run du 10 mars à F0 avec kcoeff par défaut, "F0-3168Hz-2Vpp_on_E1E2B1B2B3-DefaultKCOEFFMatrices". J'observe pareil les termes non-diagonaux des fréquences de la 32+5ème à la 32+24ème inclus sont à 0 mais que pour
B1E1
B1E2
B2E1
B2E2
B3E1
B3E2
Im(E1E2)

Idem pour le fichier à F1 (du même run): J'observe pareil les termes non-diagonaux des fréquences de la 36+15ème à la 36+25ème inclus sont à 0 mais que pour
B1E1
B1E2
B2E1
B2E2
B3E1
B3E2
Im(E1E2)

Ok, à l'inverse tu confirmes que le reste des termes sont bons? Ou juste qu'ils ne sont pas égaux à 0?

Alexis Jeandet wrote in #note-58:

thomas chust wrote in #note-57:

1. Peut-on confirmer que pour toutes les fréquences qui semblent correctes avec des matrices unitaires, on a bien appliqué la bonne matrice et pas celle d'une autre fréquence (question similaire à la question précédente)?

Je sais pas comment faire ... ?

Je dirais à partir des résultats avec les matrices par défaut. Soit c'est OK, soit c'est n'importe quoi. Dans ce cas avec les matrices unitaires ce serait tout aussi faux mais par chance, ça donnerait des résultats "corrects".

Je viens de regarder les fichiers ascii du run du 10 mars à F0 avec kcoeff par défaut, "F0-3168Hz-2Vpp_on_E1E2B1B2B3-DefaultKCOEFFMatrices". J'observe pareil les termes non-diagonaux des fréquences de la 32+5ème à la 32+24ème inclus sont à 0 mais que pour
B1E1
B1E2
B2E1
B2E2
B3E1
B3E2
Im(E1E2)

Idem pour le fichier à F1 (du même run): J'observe pareil les termes non-diagonaux des fréquences de la 36+15ème à la 36+25ème inclus sont à 0 mais que pour
B1E1
B1E2
B2E1
B2E2
B3E1
B3E2
Im(E1E2)

Ok, à l'inverse tu confirmes que le reste des termes sont bons? Ou juste qu'ils ne sont pas égaux à 0?

Il ne sont pas à 0 (du bruit). Je peux rien dire de plus, car pas de signal test ...

thomas chust wrote in #note-59:

Alexis Jeandet wrote in #note-58:

thomas chust wrote in #note-57:

1. Peut-on confirmer que pour toutes les fréquences qui semblent correctes avec des matrices unitaires, on a bien appliqué la bonne matrice et pas celle d'une autre fréquence (question similaire à la question précédente)?

Je sais pas comment faire ... ?

Je dirais à partir des résultats avec les matrices par défaut. Soit c'est OK, soit c'est n'importe quoi. Dans ce cas avec les matrices unitaires ce serait tout aussi faux mais par chance, ça donnerait des résultats "corrects".

Je viens de regarder les fichiers ascii du run du 10 mars à F0 avec kcoeff par défaut, "F0-3168Hz-2Vpp_on_E1E2B1B2B3-DefaultKCOEFFMatrices". J'observe pareil les termes non-diagonaux des fréquences de la 32+5ème à la 32+24ème inclus sont à 0 mais que pour
B1E1
B1E2
B2E1
B2E2
B3E1
B3E2
Im(E1E2)

Idem pour le fichier à F1 (du même run): J'observe pareil les termes non-diagonaux des fréquences de la 36+15ème à la 36+25ème inclus sont à 0 mais que pour
B1E1
B1E2
B2E1
B2E2
B3E1
B3E2
Im(E1E2)

Ok, à l'inverse tu confirmes que le reste des termes sont bons? Ou juste qu'ils ne sont pas égaux à 0?

Il ne sont pas à 0 (du bruit). Je peux rien dire de plus, car pas de signal test ...

Ok, du coup, ça aide pas trop au final on sait pas ce qui marche vraiment :/.

Je viens de regarder les fichiers ascii du run du 10 mars à F0 avec kcoeff par défaut, "F0-3168Hz-2Vpp_on_E1E2B1B2B3-DefaultKCOEFFMatrices". J'observe pareil les termes non-diagonaux des fréquences de la 32+5ème à la 32+24ème inclus sont à 0 mais que pour
B1E1
B1E2
B2E1
B2E2
B3E1
B3E2
Im(E1E2)

Idem pour le fichier à F1 (du même run): J'observe pareil les termes non-diagonaux des fréquences de la 36+15ème à la 36+25ème inclus sont à 0 mais que pour
B1E1
B1E2
B2E1
B2E2
B3E1
B3E2
Im(E1E2)

Ok, à l'inverse tu confirmes que le reste des termes sont bons? Ou juste qu'ils ne sont pas égaux à 0?

Il ne sont pas à 0 (du bruit). Je peux rien dire de plus, car pas de signal test ...

Ok, du coup, ça aide pas trop au final on sait pas ce qui marche vraiment :/.

Est ce que je rejouerai pas les sweeps avec la 3.3.0.7 avec les KCOEFF par défaut?

Sweep @F0 en 3.3.0.7 avec matrices par défaut : fluctuation des amplitudes ASM anormale (voir vidéo video_2022-04-01_10-05-12.mp4 ).

NOTE : On ne voit plus la fluctuation lorsque l'on est dans la bande de fréquences où il y a le bug des non-diagonaux nuls.

Les données sont là :
https://ao.lpp.polytechnique.fr/index.php/apps/files/?dir=/LFR/3.3.0.7/CTC-900&fileid=2516179

bruno katra wrote in #note-64:

Sweep à F2 en 3.3.0.7 avec matrices par défaut : la fluctuation est quand même présente mais moins flagrante qu'en F0 (voir vidéo 4_5924609361346300113.mp4) : à chaque ASM on voit l'amplitude qui diminue d'un pas régulier puis ça remonte au bout d'un moment d'un pas régulier aussi.

Les résultats sont ici :

https://ao.lpp.polytechnique.fr/index.php/apps/files/?dir=/LFR/3.3.0.7/CTC-902&fileid=2516283

Je déplace dans une nouvelle issue : #3948

Test court préliminaire en 3.3.0.8@F1 : 2V@912Hz injecté sur E1E2B1B2B3 avec MATRICES UNITAIRES

Résultats ici :
https://ao.lpp.polytechnique.fr/index.php/apps/files/?dir=/LFR/3.3.0.8/F1-912Hz-2Vpp_on_E1E2B1B2B3-UnitKCOEFFMatrices&fileid=2595713

Ceci afin de valider si il y a toujours les non-diag à 0.

bruno katra wrote in #note-69:

Test court préliminaire en 3.3.0.8@F1 : 2V@912Hz injecté sur E1E2B1B2B3 avec MATRICES UNITAIRES

Résultats ici :
https://ao.lpp.polytechnique.fr/index.php/apps/files/?dir=/LFR/3.3.0.8/F1-912Hz-2Vpp_on_E1E2B1B2B3-UnitKCOEFFMatrices&fileid=2595713

Ceci afin de valider si il y a toujours les non-diag à 0.

J'ai décommuté et regardé les ASCII : à première vue toujours pleins de non-diag à 0 mais je laisse Thomas faire son analyse plus fine.

J'ai décommuté et regardé les ASCII : à première vue toujours pleins de non-diag à 0 mais je laisse Thomas faire son analyse plus fine.

Je confirme, tous les termes non-diagonaux sont strictement à 0.

CTC-900 (sweep F0 mode normal) rejoué avec FSW 3.3.0.8 "debug". Datadumps ici :

https://ao.lpp.polytechnique.fr/index.php/apps/files/?dir=/LFR/3.3.0.8-debug&fileid=2603459

Test CTC-901 rejoué en 3.3.0.8 "debug" (sweep @F1 en NORMAL), datadumps ici :

https://ao.lpp.polytechnique.fr/index.php/apps/files/?dir=/LFR/3.3.0.8-debug/CTC-901&fileid=2603909

Test CTC-902 rejoué en 3.3.0.8 "debug" (sweep @F2 en NORMAL), datadumps ici :

https://ao.lpp.polytechnique.fr/index.php/apps/files/?dir=/LFR/3.3.0.8-debug/CTC-902&fileid=2604572

CTC-900 (sweep F0 mode normal) rejoué avec FSW 3.3.0.8 "debug" du 29/06/2022. Datadumps ici :

https://ao.lpp.polytechnique.fr/index.php/apps/files/?dir=/LFR/3.3.0.8-debug29062022&fileid=2605023

Version FSW avec correction des indices du moyennage + bypass des matrices de passage sur F0.

thomas chust wrote in #note-78:

bruno katra wrote in #note-76:

CTC-900 (sweep F0 mode normal) rejoué avec FSW 3.3.0.8 "debug" du 29/06/2022. Datadumps ici :

https://ao.lpp.polytechnique.fr/index.php/apps/files/?dir=/LFR/3.3.0.8-debug29062022&fileid=2605023

Version FSW avec correction des indices du moyennage + bypass des matrices de passage sur F0.

Pas mal du tout ! A première vue cela est tout bon !

Bon bah Alexis : vas-y pour une 3.3.0.9 candidate !

bruno katra wrote in #note-79:

thomas chust wrote in #note-78:

bruno katra wrote in #note-76:

CTC-900 (sweep F0 mode normal) rejoué avec FSW 3.3.0.8 "debug" du 29/06/2022. Datadumps ici :

https://ao.lpp.polytechnique.fr/index.php/apps/files/?dir=/LFR/3.3.0.8-debug29062022&fileid=2605023

Version FSW avec correction des indices du moyennage + bypass des matrices de passage sur F0.

Pas mal du tout ! A première vue cela est tout bon !

Bon bah Alexis : vas-y pour une 3.3.0.9 candidate !

Voici la 3.3.0.9 https://hephaistos.lpp.polytechnique.fr/teamcity/buildConfiguration/LfrFlightSoftware_BuildLpp/75291?hideProblemsFromDependencies=false&hideTestsFromDependencies=false&expandBuildChangesSection=true

Résultats CTC-951 ici :

https://ao.lpp.polytechnique.fr/index.php/apps/files/?dir=/LFR/3.3.0.9&fileid=2605950

CTC-901 en FSW 3.3.0.9 (sweep @F1 avec KCOEFF par défaut en NORMAL), résultats ici :

https://ao.lpp.polytechnique.fr/index.php/apps/files/?dir=/LFR/3.3.0.9&fileid=2605950