Bug #1039
closedproblème de centrage des snapshots avec FSW 3.2.0.12
Added by thomas chust over 7 years ago. Updated over 7 years ago.
0%
Description
Bruno a fait un test de 16h hier soir en mode NORMAL pour tester la régularité des SWF à 300s de périodes:
Le 29/03/2017 à 11:12, bruno.katra@lpp.polytechnique.fr a écrit :
Il y a 195 snapshots et si la régularité est plutôt bonne (comme avant avec la 3.0.022) le centrage ne l'est plus du tout:J'ai mis sur le ftp finalement
ftp://ftp.lpp.polytechnique.fr/katra/temp/LFR_DATA/16hrs_of_NORMAL_F3LONG_nominal_EM+TIMEGEN/
Tu peux faire ton marché !
- les SWF_F0 sont centrés sur la seconde de départ des SWF_F2 (time_shift_2to0 ~ -0.041 s)
- les SWF_F1 démarrent un chouia après ldes SWF_F2 (time_shift_2to1~ 0.00032 s), ce qui est cohérent avec des SWF_F1 centrés à ~0.25 s après une seconde pile:
Files
plot_delta_SWF_F0_test.png (256 KB) plot_delta_SWF_F0_test.png | thomas chust, 29/03/2017 05:55 PM | ||
plot_delta_SWF_F1_test.png (269 KB) plot_delta_SWF_F1_test.png | thomas chust, 29/03/2017 05:55 PM | ||
plot_delta_SWF_F2_test.png (255 KB) plot_delta_SWF_F2_test.png | thomas chust, 29/03/2017 05:55 PM | ||
3.2.0.12-SWFs.png (63.7 KB) 3.2.0.12-SWFs.png | bruno katra, 30/03/2017 10:37 AM | ||
3.0.0.22-SWFs.png (90.8 KB) 3.0.0.22-SWFs.png | bruno katra, 30/03/2017 11:18 AM | ||
fsw-3-2-0-12-363-071a09d6f71c (4.05 MB) fsw-3-2-0-12-363-071a09d6f71c | paul leroy, 30/03/2017 12:50 PM | ||
3-2-0-12-363-071a09d6f71c-SWFs.png (67.9 KB) 3-2-0-12-363-071a09d6f71c-SWFs.png | bruno katra, 30/03/2017 02:00 PM |
Updated by paul leroy over 7 years ago
Possible qu'il faille ajuster la valeur du paramètre delta_f0_2 du waveform picker (se référer à la doc du VHDL pour la signification des paramètres de réglage des snapshots). La valeur actuelle date d'il y a longtemps (avant la 3.0.0.22) et le VHDL a évolué depuis. Demander à Alexis ce qu'il en pense.
void set_wfp_delta_f0_f0_2( void )
{
unsigned int delta_snapshot;
unsigned int nb_samples_per_snapshot;
float delta_f0_in_float;
delta_snapshot = waveform_picker_regs->delta_snapshot;
nb_samples_per_snapshot = (parameter_dump_packet.sy_lfr_n_swf_l[0] * CONST_256) + parameter_dump_packet.sy_lfr_n_swf_l[1];
delta_f0_in_float = (nb_samples_per_snapshot / 2.) * ( (1. / FREQ_F2) - (1. / FREQ_F0) ) * FREQ_F2;
waveform_picker_regs->delta_f0 = delta_snapshot - floor( delta_f0_in_float );
waveform_picker_regs->delta_f0_2 = DFLT_WFP_DELTA_F0_2;
}
avec
#define DFLT_WFP_DELTA_F0_2 0x30 // 48 = 11 0000, max 7 bits
Updated by paul leroy over 7 years ago
- Assignee changed from paul leroy to thomas chust
Updated by thomas chust over 7 years ago
- Assignee changed from thomas chust to Alexis Jeandet
Garder aussi à l'esprit que ce test a été fait avec l'EM.
Updated by bruno katra over 7 years ago
Petite précision aussi sur les graphes de Thomas : pour moi seul les écarts à F1 sont préoccupants. Pour F0 et F2, cela reste la caractérisation déjà obervée et utilisée pour faire la RFD (qui a été acceptée à priori).
Updated by bruno katra over 7 years ago
- File 3.2.0.12-SWFs.png 3.2.0.12-SWFs.png added
bruno katra wrote:
Petite précision aussi sur les graphes de Thomas : pour moi seul les écarts à F1 sont préoccupants. Pour F0 et F2, cela reste la caractérisation déjà obervée et utilisée pour faire la RFD (qui a été acceptée à priori).
ERRATUM : j'avais mal compris ce qu'avait écrit Thomas, rien n'est nominal en fait. Ci dessous un graphe des snapshots supersposé avec la même échelle de temps
On voit bien comme Thomas l'a dit : F1 démarre 0.25s trop tard par rapport à F0 (qui lui est bien centré sur la seconde attendu i.e. 300s après le passage en NORMAL), F2 démarre ~4s en retard
Updated by bruno katra over 7 years ago
- File 3.0.0.22-SWFs.png 3.0.0.22-SWFs.png added
Test refait en 3.0.0.22 : les swf sont correctement centrés :
Updated by bruno katra over 7 years ago
- Assignee changed from Alexis Jeandet to paul leroy
Inspection dans le code des révisions 277 (3.0.0.22) puis 317 et 318 :
La valeur DFLT_WFP_DELTA_F0_2 a toujours été 0x30 (en dur ou en DEFINE) donc le test effectué avec VHDL 1.91 + FSW 3.0.0.22 prouve que ce n'est pas cette valeur qui permet d'expliquer le décalage.
Updated by paul leroy over 7 years ago
Je viens de faire un diff sur mes fichiers wf_handler.c entre 3.0.0.22 et la révision locale. J'ai vu un gros bug, qui est apparu à l'époque où j'ai dû enlever toutes les constantes littérales du code pour satisfaire les demandes du CNES.
J'avais en local:
deltaT_F0 = DELTAT_F0;
deltaT_F1 = DELTAF_F1;
deltaT_F2 = DELTAF_F2;
Au lieu de:
deltaT_F0 = DELTAT_F0;
deltaT_F1 = DELTAT_F1;
deltaT_F2 = DELTAT_F2;
Je joins une version 3.2.0.12 modifiée pour valider ça. Normalement, ça devrait aller!
Updated by paul leroy over 7 years ago
Updated by paul leroy over 7 years ago
- Assignee changed from paul leroy to bruno katra
Updated by bruno katra over 7 years ago
paul leroy wrote:
Je viens de faire un diff sur mes fichiers wf_handler.c entre 3.0.0.22 et la révision locale. J'ai vu un gros bug, qui est apparu à l'époque où j'ai dû enlever toutes les constantes littérales du code pour satisfaire les demandes du CNES.
J'avais en local:
[...]Au lieu de:
[...]Je joins une version 3.2.0.12 modifiée pour valider ça. Normalement, ça devrait aller!
AH ! C'est une bonne piste ça !
Je teste immédiatement
Updated by bruno katra over 7 years ago
- Status changed from New to Closed
Test rejoué en fsw-3-2-0-12-363-071a09d6f71c : le centage est redevenu nominal à première vue.
Paul, peux-tu nous livrer une 3.2.0.13 pour la traçabilité?
Merci
Updated by bruno katra over 7 years ago
Updated by paul leroy over 7 years ago
Tu ne m'avais pas réattribué l'issue petit scarabée.
Je préfèrerais attendre la livraison finale du filtre pour la 3.2.0.13, ça pose un problème? Je pense qu'Alexis doit me transmettre des nouveaux coefficients.
Updated by paul leroy over 7 years ago
Détail: si l'issue est "Closed", elle n'apparaît plus dans le tableau de bord alors il faut faire gaffe à ne pas y poser de question.
Updated by paul leroy over 7 years ago
- Status changed from Closed to In Progress
Updated by bruno katra over 7 years ago
paul leroy wrote:
Tu ne m'avais pas réattribué l'issue petit scarabée.
Je préfèrerais attendre la livraison finale du filtre pour la 3.2.0.13, ça pose un problème? Je pense qu'Alexis doit me transmettre des nouveaux coefficients.
Je ne suis pas sûr que tu auras les coeff avant la livraison, j'ai causé avec Alexis et on livrera peut-être tel quel avec mise à jour des coeff pour les calibrations au CNES.
Aussi le pb avec la 3.2.0.12 c'est que j'en ai 4 versions (compilée par Alexis avec et sans -mfix-b2bst + 2 de toi). J'ai du coup beaucoup de tests avec ce numéro dans les HK alors que le soft diffère, ça commence à être limite pour la traçabilité.
Si vraiment c'est pas grand chose, je préfèrerai continuer avec une 3.2.0.13.
Merci d'avance
Updated by bruno katra over 7 years ago
- Assignee changed from bruno katra to paul leroy
Updated by paul leroy over 7 years ago
- Assignee changed from paul leroy to bruno katra
OK, c'est fait. Bon test!
Updated by bruno katra over 7 years ago
- Status changed from In Progress to Closed
3.2.0.13 livrée et centrage OK testé sur EQM: cloture