Bug #862
closed
Valeurs des masques RW erronées dans TM_LFR_PARAMETER_DUMP
100%
Description
Suite à l'envoi de frequences RW via TC_UPDATE_INFO, les masques retournés dans la TM_LFR_PARAMETER_DUMP sont systématiquement faux, en particulier on voit l'apparition d'un talon en 'fe' ou 'f8' à la fin des 3 masques.
Exemple : on a envoyé 96Hz comme fréqeunce pour toutes les RW et le PARAMETER_DUMP contient ceci :
- RW_MASK_F0 :
0xffffffffffffffffffffffffffffff f8 - RW_MASK_F1 :
0xffffffffffffffffffffffffffffff 1e - RW_MASK_F2 :
0xfffffffc7fffffffffffffffffffff fe
Nous avons rejoué le test SVS_0109 écrit par Gérald et Alexis sur des nouvelles acquisitions (nouveau VHDL) et le résultat rejoint notre analyse : on voit toujours le bug soulevé en septembre ( #743 ) et on voit en plus les talons sur plusieurs PARAMETER_DUMP.
Nous avons rejoué aussi le test avec l'ancienne API (pc-solar3 pour la non-regression) en n'envoyant seulement 96Hz sur RW1_F1 et le même résultat est observé.
Contexte du test
---------------------
FSW 3.1.0.4
VHDL 1.1.91
EM1 avec et sans TIMEGEN
Related issues
Updated by bruno katra over 7 years ago
- Related to Bug #865: Fonction setFBinMask erronée added
Updated by bruno katra over 7 years ago
Nouveaux tests avec Alexis : Downgrade de socecplorer et socexplorer-plugins + tests sur EQM
Le bug du talon apparait mais il y en a plus ou moins selon le contexte (version socecplorer/plugins , carte). Cela confirme que le bug est lié à #864 et qu'il a toujours été présent et serait lié au pointeur de pile sauf que la conf de cet été utilisé par Gérald et Alexis était favorable au niveau du pointeur de pile et masquait le pb.
Updated by paul leroy over 7 years ago
- Assignee changed from paul leroy to bruno katra
Suite à quelques modifications sur la fonction de calcul des masques, j'ai rejoué quelques tests en mettant notamment 96 pour toutes les roues à inertie. Les résultats semblent corrects.
A tester sur fsw >= 3.1.0.5
Updated by bruno katra about 7 years ago
- Status changed from New to In Progress
- Assignee changed from bruno katra to paul leroy
Le bug est toujours présent en 3.1.0.6 mais seulement à priori lorsque l'on injecte certaines fréquences propres F2 (7 Hz à 102 Hz).
Voici un exemple pour la fréquence 12Hz des masques générés, le masque F1 est faux il ne devrait masqué que le 1er bin car le delta_f est à 0.025Hz :
- RW_MASK_F0 :
0xfffffffffffffffffffffffffffffffe - RW_MASK_F1 :
0xfffffffffffffffffffffffffffffff c - RW_MASK_F2 :
0xffffffffffffffffffffffffffffe3ff
- RW_MASK_F1 :
0xffffffffffffffffffffffffffffff 8 f
là où l'on attend 9f ou cf
--------------
Contexte :
FSW 3.1.0.6
sur EQM sans TIMEGEN
Updated by bruno katra about 7 years ago
J'ai commenté mon point précédent avec de nouveaux exemples de masques faux...
Updated by paul leroy about 7 years ago
- Status changed from In Progress to Feedback
- Assignee changed from paul leroy to bruno katra
Peux-tu préciser le calcul que tu fais? Je n'ai peut-être pas la bonne méthode:
Je cherche d'abord la bin la plus proche de la fréquence de la roue à inertie, pour 12 Hz et le canal F1 il s'agit de la bin 1 (soit 16Hz), et j'observe la bande polluée par rapport à l'intervalle [11.44;20.56], soit 16 +/- 0.285*16.
Je calcule la bande polluée, ici [11.9875; 12.0125]. Cet intervalle est inclus dans le précédent et donc il faut enlever 3 bins, la bin 0 ne compte pas comme vous me l'avez rappelé et donc on enlève les bins 1 et 2.
C'est comme ça que j'arrive à c (1100).
Updated by bruno katra about 7 years ago
Je n'avais pas compris toutes les subtilités du masquage, c'est peut-être moi qui calcule mal, je reboucle et te tiens au courant.
paul leroy wrote:
Peux-tu préciser le calcul que tu fais? Je n'ai peut-être pas la bonne méthode:
Je cherche d'abord la bin la plus proche de la fréquence de la roue à inertie, pour 12 Hz et le canal F1 il s'agit de la bin 1 (soit 16Hz), et j'observe la bande polluée par rapport à l'intervalle [11.44;20.56], soit 16 +/- 0.285*16.
Je calcule la bande polluée, ici [11.9875; 12.0125]. Cet intervalle est inclus dans le précédent et donc il faut enlever 3 bins, la bin 0 ne compte pas comme vous me l'avez rappelé et donc on enlève les bins 1 et 2.
C'est comme ça que j'arrive à c (1100).
Updated by bruno katra about 7 years ago
- Assignee changed from bruno katra to paul leroy
Alors en fait, après discussions avec Thomas et examen attentif de la SRS de Gérald : on a tous les 2 tort sur des points différents :
1- c'est bien ton mécanisme de calcul qui est bon .
2- Mais ta façon d'utiliser le delta_f est fausse. Les discussions entre Gérald, Thomas et mails de Milan qui ont menés à a SRS livrés par Gérald stipule que la bande polluée autour d'une fréquence Frw est [Frw-delta_f, Frw+delta_f]. Or ton calcul a toi fait état de [Frw-delta_f/2, Frw+delta_f/2]
---------------
FSW 3.1.0.6 sur Mini-LFR VHDL 0.1.91
Updated by paul leroy about 7 years ago
- Assignee changed from paul leroy to bruno katra
Correction effectuée pour fsw >= 3.1.0.7
Updated by bruno katra about 7 years ago
- Status changed from Feedback to Closed
- % Done changed from 0 to 100
Testé en 3.1.0.7 sur EM 1.1.91: bug corrigé.