Bug #955
closedHK_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
0%
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
Updated by paul leroy almost 8 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
Updated by Veronique bouzid almost 8 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.
Updated by paul leroy almost 8 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?
Updated by Veronique bouzid almost 8 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.
Updated by paul leroy almost 8 years ago
Pas de problème, c'est pour ça que je demandais des précisions.
Updated by paul leroy almost 8 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.
Updated by Veronique bouzid almost 8 years ago
- Assignee changed from Veronique bouzid to Alexis Jeandet
Updated by bruno katra over 7 years ago
- File LFR_reset_impact_on_HK_mean.png LFR_reset_impact_on_HK_mean.png added
- Assignee changed from Alexis Jeandet to thomas chust
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.
Updated by bruno katra over 7 years ago
- File 3.2.0.15-HK-CTC-800.png 3.2.0.15-HK-CTC-800.png added
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)
Updated by thomas chust over 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.