Project

General

Profile

Bug #862

Valeurs des masques RW erronées dans TM_LFR_PARAMETER_DUMP

Added by bruno katra over 4 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Urgent
Assignee:
Category:
R3+
Target version:
-
Start date:
28/12/2016
Due date:
% Done:

100%

Estimated time:
revision:
r0

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 :

  1. RW_MASK_F0 :
    0xffffffffffffffffffffffffffffff f8
  2. RW_MASK_F1 :
    0xffffffffffffffffffffffffffffff 1e
  3. 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

Related to Bug #865: Fonction setFBinMask erronéeClosed2016-12-29

History

#1 Updated by bruno katra over 4 years ago

  • Description updated (diff)

#2 Updated by bruno katra over 4 years ago

  • Category set to R3+

#3 Updated by bruno katra over 4 years ago

  • Related to Bug #865: Fonction setFBinMask erronée added

#4 Updated by bruno katra over 4 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.

#5 Updated by paul leroy over 4 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

#6 Updated by bruno katra over 4 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 :

  1. RW_MASK_F0 :
    0xfffffffffffffffffffffffffffffffe
  2. RW_MASK_F1 :
    0xfffffffffffffffffffffffffffffff c
  3. RW_MASK_F2 :
    0xffffffffffffffffffffffffffffe3ff
Aussi, le masque F1 est faux pour les fréquences 92Hz à 100Hz :
  1. RW_MASK_F1 :
    0xffffffffffffffffffffffffffffff 8 f
    là où l'on attend 9f ou cf

--------------
Contexte :
FSW 3.1.0.6
sur EQM sans TIMEGEN

#7 Updated by bruno katra over 4 years ago

J'ai commenté mon point précédent avec de nouveaux exemples de masques faux...

#8 Updated by paul leroy over 4 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).

#9 Updated by bruno katra over 4 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).

#10 Updated by bruno katra over 4 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

#11 Updated by paul leroy over 4 years ago

  • Assignee changed from paul leroy to bruno katra

Correction effectuée pour fsw >= 3.1.0.7

#12 Updated by bruno katra over 4 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é.

Also available in: Atom PDF