Project

General

Profile

Actions

Bug #3936

open

Comparaison/validation FSW 3.2.0.24 vs 3.3.0.7 avec matrices unitaires.

Added by bruno katra 4 months ago. Updated about 15 hours ago.

Status:
In Progress
Priority:
Normal
Category:
-
Target version:
Start date:
15/03/2022
Due date:
% Done:

0%

Estimated time:
revision:
r0

Description

En relation avec #3877 il est pertinent de vérifier la cohérence entre 3.2.0.24 vs (3.3.0.7 avec matrices unitaires). Les comportements attendus doivent être similaires entre les 2 (à la différence près de la correction de la moyenne des ASM qui ne doit pas trop se voir dans le cadre de signaux constants).

J'ai rejoué les runs PREL-08 ( #3877 ) mais en 3.2.0.24, les datadumps sont ici :
https://ao.lpp.polytechnique.fr/index.php/apps/files/?dir=/LFR/3.2.0.24/PREL-09&fileid=2507041


Files

VERIF_LFR_FSW_R3_3_Bruno_20220315.html (770 KB) VERIF_LFR_FSW_R3_3_Bruno_20220315.html thomas chust, 15/03/2022 06:29 PM
VERIF_LFR_FSW_R3_3_Bruno_20220317.html (822 KB) VERIF_LFR_FSW_R3_3_Bruno_20220317.html thomas chust, 17/03/2022 03:49 PM
ASM_F1_bug.png (193 KB) ASM_F1_bug.png Alexis Jeandet, 18/03/2022 04:44 PM
load_asm.ipynb (26.2 KB) load_asm.ipynb Alexis Jeandet, 18/03/2022 04:52 PM
ctc-901_2022_03_21_12_45_32_packet_record_NORMAL_SWF_5_F1.svg (287 KB) ctc-901_2022_03_21_12_45_32_packet_record_NORMAL_SWF_5_F1.svg thomas chust, 21/03/2022 05:39 PM
ctc-901_diff_ASM-SWF_F1.svg (286 KB) ctc-901_diff_ASM-SWF_F1.svg thomas chust, 21/03/2022 05:39 PM
ctc-901_diff_ASM-SWF_zoom_F1.svg (260 KB) ctc-901_diff_ASM-SWF_zoom_F1.svg thomas chust, 21/03/2022 05:39 PM
ctc-901_2022_03_21_12_45_32_packet_record_NORMAL_ASM_F1.svg (287 KB) ctc-901_2022_03_21_12_45_32_packet_record_NORMAL_ASM_F1.svg thomas chust, 21/03/2022 06:00 PM
CALIB_analysis_Bruno_2_20220322.html (6.04 MB) CALIB_analysis_Bruno_2_20220322.html thomas chust, 22/03/2022 03:40 PM
CALIB_analysis_Bruno_2_ctc-900_20220322.html (6.3 MB) CALIB_analysis_Bruno_2_ctc-900_20220322.html thomas chust, 22/03/2022 05:45 PM
ctc-900_2022_03_22_13_49_52_packet_record_NORMAL_ASM_F0.svg (257 KB) ctc-900_2022_03_22_13_49_52_packet_record_NORMAL_ASM_F0.svg thomas chust, 22/03/2022 05:46 PM
ctc-900_2022_03_22_13_49_52_packet_record_NORMAL_SWF_5_F0.svg (257 KB) ctc-900_2022_03_22_13_49_52_packet_record_NORMAL_SWF_5_F0.svg thomas chust, 22/03/2022 05:46 PM
ctc-902_2022_03_23_09_21_35_packet_record_NORMAL_SWF_5_F2.svg (264 KB) ctc-902_2022_03_23_09_21_35_packet_record_NORMAL_SWF_5_F2.svg thomas chust, 24/03/2022 06:12 AM
ctc-902_2022_03_23_09_21_35_packet_record_NORMAL_ASM_F2.svg (264 KB) ctc-902_2022_03_23_09_21_35_packet_record_NORMAL_ASM_F2.svg thomas chust, 24/03/2022 06:12 AM
CALIB_analysis_Bruno_2_ctc-902_20220323.html (5.64 MB) CALIB_analysis_Bruno_2_ctc-902_20220323.html thomas chust, 24/03/2022 06:12 AM
ctc-910_2022_03_28_10_40_40_packet_record_NORMAL_SWF_5_F0.svg (257 KB) ctc-910_2022_03_28_10_40_40_packet_record_NORMAL_SWF_5_F0.svg thomas chust, 28/03/2022 02:58 PM
ctc-910_2022_03_28_10_40_40_packet_record_NORMAL_ASM_F0.svg (257 KB) ctc-910_2022_03_28_10_40_40_packet_record_NORMAL_ASM_F0.svg thomas chust, 28/03/2022 02:58 PM
ctc-912_2022_03_28_12_20_41_packet_record_NORMAL_SWF_5_F2.svg (264 KB) ctc-912_2022_03_28_12_20_41_packet_record_NORMAL_SWF_5_F2.svg thomas chust, 28/03/2022 03:09 PM
ctc-912_2022_03_28_12_20_41_packet_record_NORMAL_ASM_F2.svg (264 KB) ctc-912_2022_03_28_12_20_41_packet_record_NORMAL_ASM_F2.svg thomas chust, 28/03/2022 03:09 PM
ctc-911_2022_03_28_13_50_34_packet_record_NORMAL_ASM_F1.svg (287 KB) ctc-911_2022_03_28_13_50_34_packet_record_NORMAL_ASM_F1.svg thomas chust, 28/03/2022 04:46 PM
ctc-911_2022_03_28_13_50_34_packet_record_NORMAL_SWF_5_F1.svg (287 KB) ctc-911_2022_03_28_13_50_34_packet_record_NORMAL_SWF_5_F1.svg thomas chust, 28/03/2022 04:46 PM
video_2022-04-01_10-05-12.mp4 (3.63 MB) video_2022-04-01_10-05-12.mp4 bruno katra, 01/04/2022 11:32 AM
4_5924609361346300113.mp4 (4.42 MB) 4_5924609361346300113.mp4 bruno katra, 01/04/2022 12:09 PM
diff_F2_swf_versus_asm_7.png (48.7 KB) diff_F2_swf_versus_asm_7.png thomas chust, 04/04/2022 05:01 PM
diff_F2_swf_versus_asm_0.png (58.2 KB) diff_F2_swf_versus_asm_0.png thomas chust, 04/04/2022 05:01 PM
diff_F2_swf_versus_asm_3.png (52.2 KB) diff_F2_swf_versus_asm_3.png thomas chust, 04/04/2022 05:02 PM

Related issues

Related to Task #3877: Matrices de passage par défaut pour les ASM : à valider In ProgressAlexis Jeandet17/09/2021

Actions
Related to Task #3897: Faire un test avec les matrices de chgt de repère/calibration mises à 1 et 0 pour reproduire le comportement du FSW <=3.2.0.24In Progressbruno katra18/11/2021

Actions
Related to Bug #3941: Calcul des BP2 erroné pour F2 [3.3.0.7 avec matrices unitaires]NewAlexis Jeandet28/03/2022

Actions
Related to Task #3946: Vérifier si #3936 apparait aussi en 3.3.0.4 (avant modifs SonarCoud 02/2022)Closedbruno katra01/04/2022

Actions
Related to Bug #3948: FSW <= 3.3.0.7 : fluctuation de l'amplitude des ASM avec signal stationnaireIn ProgressAlexis Jeandet04/04/2022

Actions
Actions #1

Updated by bruno katra 4 months ago

  • Related to Task #3877: Matrices de passage par défaut pour les ASM : à valider added
Actions #2

Updated by thomas chust 4 months ago

  • Assignee changed from thomas chust to bruno katra

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 ... :)

Actions #3

Updated by bruno katra 4 months ago

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.

Actions #4

Updated by thomas chust 4 months ago

Première analyse faite (cf notebook attaché):
- à F2 la comparaison entre 3.2.0.24 vs 3.3.0.7 (avec matrices unitaires) est quasi parfaite
- à F0 également pour ce qui concerne toutes les magnitudes (des auto- et des cross-correllations); les différences de phase sont aussi quasi nulles pour les paires de sigaux d'une même carte mais notables pour les signaux qui se déphasent sur le temps de la manip (les 2 runs ne sont alors pas comparables ...)
- à F1 on retrouve le problème des termes non diagonaux (les cross-corrélations) qui valent 0 avec la 3.3.0.7 (et pas avec la 3.2.0.24 heureusement ...)

Encore un petit effort Alexis ! :)

Actions #5

Updated by bruno katra 3 months ago

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.

Actions #6

Updated by Alexis Jeandet 3 months ago

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

Actions #7

Updated by bruno katra 3 months ago

  • Assignee changed from Alexis Jeandet to bruno katra
Actions #8

Updated by thomas chust 3 months ago

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

Actions #9

Updated by Alexis Jeandet 3 months ago

Je comprends pas ta question.

Actions #10

Updated by bruno katra 3 months ago

  • Assignee changed from bruno katra to thomas chust

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

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

Actions #11

Updated by thomas chust 3 months ago

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. ?

Actions #12

Updated by Alexis Jeandet 3 months ago

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 SIZES0 c'est 88+1 et pas 88/8.

Actions #13

Updated by thomas chust 3 months ago

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

Actions #14

Updated by thomas chust 3 months ago

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 ?

Actions #15

Updated by bruno katra 3 months ago

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 :

- les fichiers ascii des ASM contiennent les matrices décommutées brutes issues directement des paquets LFR qui sont segmentées en 3 paquets (voir champs ##### PA_LFR_PKT_CNT_ASM: 3 et
  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!

Actions #16

Updated by thomas chust 3 months ago

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
Actions #17

Updated by thomas chust 3 months ago

  • Assignee changed from thomas chust to Alexis Jeandet

Je viens de vérifier moi aussi dans le fichier ascii décommuté:

pour l' ASM@F1 (5x5) [avec signal à 912Hz]:
20750388.0000000000           0.0000000000           0.0000000000           0.0000000000           0.0000000000           0.0000000000           0.0000000000           0.0000000000           0.0000000000    20575870.0000000000           0.0000000000           0.0000000000           0.0000000000           0.0000000000           0.0000000000           0.0000000000    20704086.0000000000           0.0000000000           0.0000000000           0.0000000000           0.0000000000    20393340.0000000000           0.0000000000           0.0000000000    20593344.0000000000

pour l' ASM@F0 (5x5) [avec signal à 3168Hz]:

20164214.0000000000    20674516.0000000000      131012.6015625000    15517221.0000000000    11564152.0000000000    13698939.0000000000    12804424.0000000000    13783375.0000000000    12859889.0000000000    21198574.0000000000    15985155.0000000000    11755913.0000000000    14128959.0000000000    13039383.0000000000    14215889.0000000000    13095701.0000000000    21063614.0000000000    20871266.0000000000     2329697.0000000000    20984250.0000000000     2323167.2500000000    21066954.0000000000    21178874.0000000000      -19043.0859375000    21291406.0000000000
Actions #18

Updated by bruno katra 3 months ago

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

Actions #19

Updated by thomas chust 3 months ago

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)

Actions #20

Updated by bruno katra 3 months ago

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 ?!?

Actions #21

Updated by bruno katra 3 months ago

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

Actions #22

Updated by Alexis Jeandet 3 months ago

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.
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...).

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.

Actions #23

Updated by Alexis Jeandet 3 months ago

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

Actions #24

Updated by thomas chust 3 months ago

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

Actions #25

Updated by bruno katra 3 months ago

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.

Actions #26

Updated by Alexis Jeandet 3 months ago

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.

Actions #27

Updated by bruno katra 3 months ago

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.

Actions #28

Updated by bruno katra 3 months ago

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.

Actions #29

Updated by bruno katra 3 months ago

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

Actions #30

Updated by thomas chust 3 months ago

bruno katra wrote in #note-29:

Test CTC-901 joué :

Je balaie toutes les frequences F1 de LFR :

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

Résultats conforment à ce que nous avons obtenu en 2018/12/04 avec la 3.2.024 (CTC-511) SAUF pour une plage de fréquence entre 896Hz et 1056Hz (11 fréquences). Voir les plots attachés.

Actions #31

Updated by thomas chust 3 months ago

  • File deleted (ctc-901_2022_03_21_12_45_32_packet_record_NORMAL_SWF_F1.svg)
Actions #33

Updated by bruno katra 3 months ago

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.

Actions #34

Updated by thomas chust 3 months ago

bruno katra wrote in #note-33:

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.

Analyse refaite comme hier: résultats quasi identiques (voir notebook joint)

Actions #35

Updated by bruno katra 3 months ago

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.

Actions #36

Updated by thomas chust 3 months ago

bruno katra wrote in #note-35:

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.

Analyse faite: résultats similaires que ceux à F1, c-à-d qu'il y a une bande de fréquence située environ au milieu pour laquelle les termes non diagonaux (crosscorrelations) sont à 0 !

Actions #37

Updated by Alexis Jeandet 3 months ago

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.

Actions #38

Updated by bruno katra 3 months ago

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.

Actions #39

Updated by Alexis Jeandet 3 months ago

Génial! :)

Actions #40

Updated by bruno katra 3 months ago

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.
Actions #41

Updated by thomas chust 3 months ago

bruno katra wrote in #note-40:

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.

Analyse faite: résultats conformes; tout ce qui est obtenu à partir des SWF est aussi très précisément obtenu à partir des ASM (courbes bien superposables) :)

Conclusion: le bug n'apparait pas à F2 mais seulement à F0 et F1

Actions #42

Updated by bruno katra 3 months ago

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

Actions #43

Updated by bruno katra 3 months ago

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

Actions #44

Updated by bruno katra 3 months ago

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

Actions #45

Updated by bruno katra 3 months ago

  • Related to Task #3897: Faire un test avec les matrices de chgt de repère/calibration mises à 1 et 0 pour reproduire le comportement du FSW <=3.2.0.24 added
Actions #46

Updated by thomas chust 3 months ago

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)

Actions #47

Updated by thomas chust 3 months ago

bruno katra wrote in #note-44:

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

Pareil que pour CTC-902: pas de bug à F2

Actions #48

Updated by bruno katra 3 months ago

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?

Actions #49

Updated by bruno katra 3 months ago

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
Actions #50

Updated by thomas chust 3 months ago

bruno katra wrote in #note-49:

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

Pareil que CTC-901(NM) : même bug à F1

Actions #51

Updated by thomas chust 3 months ago

  • Related to Bug #3941: Calcul des BP2 erroné pour F2 [3.3.0.7 avec matrices unitaires] added
Actions #52

Updated by bruno katra 3 months ago

  • Tracker changed from Task to Bug
Actions #53

Updated by Alexis Jeandet 3 months ago

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?
Actions #54

Updated by thomas chust 3 months ago

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)

Actions #55

Updated by bruno katra 3 months ago

  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.

Actions #56

Updated by Alexis Jeandet 3 months ago

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)

Actions #57

Updated by thomas chust 3 months ago

  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)

Actions #58

Updated by Alexis Jeandet 3 months ago

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?

Actions #59

Updated by thomas chust 3 months ago

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

Actions #60

Updated by Alexis Jeandet 3 months ago

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 :/.

Actions #61

Updated by bruno katra 3 months ago

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?

Actions #62

Updated by bruno katra 3 months ago

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

Actions #64

Updated by bruno katra 3 months ago

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

Actions #65

Updated by bruno katra 3 months ago

  • Related to Task #3946: Vérifier si #3936 apparait aussi en 3.3.0.4 (avant modifs SonarCoud 02/2022) added
Actions #66

Updated by bruno katra 3 months ago

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

Actions #67

Updated by bruno katra 3 months ago

  • Related to Bug #3948: FSW <= 3.3.0.7 : fluctuation de l'amplitude des ASM avec signal stationnaire added
Actions #68

Updated by thomas chust 3 months ago

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.

Fluctuation effectivement moins forte. J'ai ainsi pu chercher à vérifier si l'opération de calibration à bord était correcte. Pour cela, pour chacun des fichiers (c-à-d pour chaque fréquence injectée) j'ai calculé une matrice spectrale à partir du SWF et comparé avec l'ASM calculé à bord. Résultat: on retrouve ce qu'il faut avec les SWF avec parfois de gros écarts selon la fréquence injectée et l'ASM de référence (j'ai le choix parmi 9 ASM). Pour l'ASM d'indice 3 j'obtiens le meilleur résultat avec au pire environ 5% d'écart relatif (voir la figure diff_F2_swf_versus_asm_3.png). Pour l'ASM d'indice 7 les écarts se creusent ... (500% vers 100Hz).

Actions #69

Updated by bruno katra 14 days ago

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.

Actions #70

Updated by bruno katra 14 days ago

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.

Actions #71

Updated by thomas chust 14 days ago

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.

Actions #72

Updated by bruno katra about 15 hours ago

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

Actions

Also available in: Atom PDF