Project

General

Profile

Actions
Copy link

Bug #955

closed

HK_LFR_SC_V_F3 , HK_LFR_SC_E1_F3, HK_LFR_SC_E2_F3 have amazing values when a TC_LFR_ENTER_MODE is executed

Added by Veronique bouzid about 7 years ago. Updated almost 7 years ago.

Status:
Closed
Priority:
Normal
Assignee:
bruno katra
Category:
-
Target version:
-
Start date:
02/03/2017
Due date:
% Done:

0%

Estimated time:
revision:
r0

Description

En R3++, le requirement SSS-CP-EQS-526 doit calculer la moyenne des 16 dernieres valeurs du champ electrique echantilloné à F3.
Cela concerne les champs HK_LFR_SC_V_F3 , HK_LFR_SC_E1_F3, HK_LFR_SC_E2_F3 stockés dans TM_LFR_HK.

Actuellement on observe sur ses sensors le bruits de fond et les valeurs varient peu.

Lors des changements de modes, on observe une grosse variation des valeurs suivantes soit sur la transition standby vers mode soit sur la transition mode vers standby.
Ici un exemple de la transition normal mode vers standby vers burst
11:20:39.823949, TM_LFR_HK, TIME=0x8000007d3a8a, HK_LFR_MODE: NORMAL = 1, HK_LFR_SC_V_F3=431, HK_LFR_SC_E1_F3=428, HK_LFR_SC_E2_F3=382
11:20:40.822544, TM_LFR_HK, TIME=0x8000007e3a78, HK_LFR_MODE: NORMAL = 1, HK_LFR_SC_V_F3=430, HK_LFR_SC_E1_F3=429, HK_LFR_SC_E2_F3=382
11:20:41.822561, TM_LFR_HK, TIME=0x8000007f3a77, HK_LFR_MODE: NORMAL = 1, HK_LFR_SC_V_F3=429, HK_LFR_SC_E1_F3=429, HK_LFR_SC_E2_F3=383
11:20:42.822307, TM_LFR_HK, TIME=0x800000803a61, HK_LFR_MODE: STANDBY = 0, HK_LFR_SC_V_F3=4459, HK_LFR_SC_E1_F3=12623, HK_LFR_SC_E2_F3=9087
11:20:43.822065, TM_LFR_HK, TIME=0x800000813a50, HK_LFR_MODE: STANDBY = 0, HK_LFR_SC_V_F3=421, HK_LFR_SC_E1_F3=450, HK_LFR_SC_E2_F3=8662
11:20:44.822052, TM_LFR_HK, TIME=0x800000823a51, HK_LFR_MODE: BURST = 2, HK_LFR_SC_V_F3=16161, HK_LFR_SC_E1_F3=4477, HK_LFR_SC_E2_F3=12067
11:20:45.822391, TM_LFR_HK, TIME=0x800000833a64,* HK_LFR_MODE: BURST = 2, HK_LFR_SC_V_F3=4565, HK_LFR_SC_E1_F3=412, HK_LFR_SC_E2_F3=4516*
11:20:46.823081, TM_LFR_HK, TIME=0x800000843a50, HK_LFR_MODE: BURST = 2, HK_LFR_SC_V_F3=431, HK_LFR_SC_E1_F3=429, HK_LFR_SC_E2_F3=383

Les transitions qui posent problemes sont
normal -> standby
burst -> standby
sbm1 -> standby
sbm2 -> standby
et
standby -> burst

le script utilisé est /home/validation/SCRIPT/R3++/just_all_mode.py.
Les fichiers de logs (2017_03_02-11_26_58-*) sont dans /home/validation/data/R3++/3.2.0.2/1.1.91/TEST-UNITAIRES/just_all_mode.

je joins le fichier resultat qui baliant les transitions de mode.

Contexte du test
----------------
FSW 3.2.0.2
VHDL 1.1.91
EM1 sans Timegen
SocExplorerEngine.getSocExplorer: Version = 0.7.0, Branch = 0.6, Changeset = c459540a6dbd+
StarDundee

Files

Download all files
2017_03_02-11_26_58-values_f3.txt (65.6 KB) 2017_03_02-11_26_58-values_f3.txt Veronique bouzid, 02/03/2017 01:27 PM
LFR_reset_impact_on_HK_mean.png (200 KB) LFR_reset_impact_on_HK_mean.png bruno katra, 30/03/2017 03:27 PM
3.2.0.15-HK-CTC-800.png (41.7 KB) 3.2.0.15-HK-CTC-800.png bruno katra, 05/05/2017 05:16 PM
Actions
Copy link
 #1

Updated by Veronique bouzid about 7 years ago

  • Description updated (diff)
Actions
Copy link
 #2

Updated by paul leroy about 7 years ago

  • Assignee changed from paul leroy to Veronique bouzid

Peux-tu préciser un peu plus les transitions qui sont valides et celles qui ne le sont pas?

Tu dis

on observe une grosse variation des valeurs suivantes soit sur la transition standby vers mode soit sur la transition mode vers standby

Et ensuite tu ne listes pas les transitions standby vers mode x. La seule qui ne fonctinone pas est standby vers burst? Si c'est le cas, j'ai peut-être une piste.

Les transitions qui posent problemes sont
normal -> standby
burst -> standby
sbm1 -> standby
sbm2 -> standby
et
standby -> burst
Actions
Copy link
 #3

Updated by Veronique bouzid about 7 years ago

  • Assignee changed from Veronique bouzid to paul leroy

hello
Elles sont la les transitions qui posent problemes

Les transitions qui posent problemes sont
normal -> standby
burst -> standby
sbm1 -> standby
sbm2 -> standby
et
standby -> burst

Et dans le fichier de log que j ai joint tu peux retrouver les problemes car j ai affiché le mode curourant et les valeurs *_F3 associées extraites des HK.

Actions
Copy link
 #4

Updated by paul leroy about 7 years ago

  • Status changed from New to Feedback
  • Assignee changed from paul leroy to Alexis Jeandet

Je pense que la liste n'est pas complète, toutes les transitions vers BURST devraient en faire partie il me semble. Ce qui donnerait:
NORM, SBM1, SBM2, BURST => STANDBY
NORM, SBM1, SBM2, STANDBY => BURST

Je pense que ça vient du fait que je reset LFR pour relancer la période des snapshots correctement. Pour les transitions vers BURST on pourrait s'en passer, mais pour certaines transitions vers NORMAL, SBM1 et SBM2, il faut faire un reset LFR à un moment.

Proposition: arrêter la moyenne le temps du reset LFR et la relancer juste après.

Alexis: après un soft reset LFR, on peut considérer que les données à f3 lues directement dans les registres du waveform picker sont valides à partir de quand?

Actions
Copy link
 #5

Updated by Veronique bouzid about 7 years ago

Je n ai jamais dit que toutes les transitions etaient testées. J ai juste fait un test pour cerner un peu plus le bug
que j avais détecté lors de la transition Normal Mode vers Standby.

Actions
Copy link
 #6

Updated by paul leroy about 7 years ago

Pas de problème, c'est pour ça que je demandais des précisions.

Actions
Copy link
 #7

Updated by paul leroy about 7 years ago

  • Assignee changed from Alexis Jeandet to Veronique bouzid

L'origine du comportement est à chercher du côté des reset LFR que je fais quand je passe en STANDBY, quel que soit le mode d'origine, et quand je passe en BURST.

Alexis a proposé de geler les valeurs de v, e1 et e2 dans les HK pendant un certain nombre de secondes après une commutation de mode. Ce temps de gel et les transitions devront être documentés dans la SRS je pense. Si le comportement vous convient, il suffit juste de me donner le temps pendant lequel on gèle les valeurs v, e1 et e2 des HK suite à un reset LFR.

Actions
Copy link
 #8

Updated by Veronique bouzid about 7 years ago

  • Assignee changed from Veronique bouzid to Alexis Jeandet
Actions
Copy link
 #9

Updated by bruno katra about 7 years ago

Depuis l'implémentation du filtre IIR (fsw >=3.2.0.10) les artefacts liés à la réponse impulsionelle sont très amoindris (voir cercle rouge sur graphe ci-dessous) : Alexis pense que l'on pourrait considérer de laisser tel quel (je rajouterai alors quelque chose dans le SUM pour expliquer ça)

(Le graphe montre le plots des HK avec EQM avec fsw-3-2-0-12-363-071a09d6f71c + dizaines de changements de tous les modes dans tous les sens, avec injection de 100mHz, 50mHz et 10mHz avec +/-1V et +/-3V)

Si Thomas est d'accord je cloture.

Actions
Copy link
 #10

Updated by bruno katra about 7 years ago

  • Priority changed from High to Normal
Actions
Copy link
 #11

Updated by Veronique bouzid about 7 years ago

  • Description updated (diff)
Actions
Copy link
 #12

Updated by bruno katra almost 7 years ago

Ajout d'une image montant l'effet du filtre lorsque l'on injecte une freq > 0.5Hz.
Pour mettre dans le rapport de calibration (BKA)

Actions
Copy link
 #13

Updated by thomas chust almost 7 years ago

  • Status changed from Feedback to Closed
  • Assignee changed from thomas chust to bruno katra

Après discussion hier avec Alexis, le filtre IIR implémenté a une réponse en fréquence beaucoup plus sélective que celle du filtre moyenneur, ce qui explique des artefacts (réponses à un changement de mode) amoindris.

Actions
Copy link

Also available in: Atom PDF