Project

General

Profile

Actions

Bug #1005

closed

HK_LFR_SC_V_F3 , HK_LFR_SC_E1_F3 , HK_LFR_SC_E2_F3 see a differentnoise signal

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

Status:
Closed
Priority:
High
Assignee:
Category:
-
Target version:
-
Start date:
21/03/2017
Due date:
% Done:

0%

Estimated time:
revision:
r0

Description

Pourquoi les valeurs observées sur les champs suivants ne montrent plus le bruit de fond qui oscillait autour de 500 counts dans la version 3.2.0.3.
Le test a été fait sur EM1 sans les harnais.

Le LFR SGSE montrent des valeurs
v_f3 autour de -20000
e1_f3 autour de -21500
e2_f3 autour de 31500

mes logs montrent sur la derniere HK en standby
HK_LFR_SC_V_F3= 46096 --> en hexa B410 car on lit les 16 bits
HK_LFR_SC_E1_F3=43552, --> en hexa AA20
HK_LFR_SC_E2_F3=30992 --> en hexa 7910

EST CE NORMAL?????
Si oui mettre l explication.

Contexte du test
---------------------
FSW 3.2.0.7
VHDL 1.1.91
SocExplorerEngine.getSocExplorer: Version = 0.7.0, Branch = default, Changeset = c459540a6dbdcbb4e17f204685fce02c070ba971+
EM1 sans Timegen
StarDundee


Files

HK_SC_V_E1_E2-3.2.0.7.png (248 KB) HK_SC_V_E1_E2-3.2.0.7.png bruno katra, 22/03/2017 10:26 AM
3.2.0.7-CWFvsHK.png (87 KB) 3.2.0.7-CWFvsHK.png bruno katra, 24/03/2017 11:45 AM
3.2.0.8-cwf3.png (80.2 KB) 3.2.0.8-cwf3.png bruno katra, 24/03/2017 03:20 PM
3.2.0.8-HK.png (74.1 KB) 3.2.0.8-HK.png bruno katra, 24/03/2017 03:20 PM
3.2.0.9-hk.png (102 KB) 3.2.0.9-hk.png bruno katra, 27/03/2017 11:01 AM
3.2.0.9-cf3.png (176 KB) 3.2.0.9-cf3.png bruno katra, 27/03/2017 11:01 AM
3.2.0.9-hk2.png (98.4 KB) 3.2.0.9-hk2.png bruno katra, 27/03/2017 11:51 AM
cwf_f3_hk.png (18.5 KB) cwf_f3_hk.png paul leroy, 27/03/2017 02:25 PM
cwf_f3 filtered.png (16.7 KB) cwf_f3 filtered.png paul leroy, 27/03/2017 02:25 PM
3.2.0.9-hk3.png (76.4 KB) 3.2.0.9-hk3.png bruno katra, 27/03/2017 03:50 PM
Actions #1

Updated by paul leroy about 7 years ago

  • Assignee changed from paul leroy to Veronique bouzid

Pour comparer, il faudrait convertir tes données HK en int16, là, tu es en uint16.
46096 => -19440
43552 => -21984
30992 => 30992
Pour ce qui es du bruit de fond, je ne sais pas pour l'instant.

Actions #2

Updated by thomas chust about 7 years ago

  • Assignee changed from Veronique bouzid to paul leroy

En fait la question n'est pas le bruit de fond ce sont ces "offsets moyens" (même sans signal d'entrée) énormes.

Actions #3

Updated by paul leroy about 7 years ago

  • Assignee changed from paul leroy to Veronique bouzid

Je n'avais pas compris la question.
Il faudrait consulter Alexis, avec des entrées ouvertes c'est pas forcément étonnant.

Actions #4

Updated by paul leroy about 7 years ago

Est-ce cohérent avec les formes d'onde continues?

Actions #5

Updated by Veronique bouzid about 7 years ago

  • Assignee changed from Veronique bouzid to bruno katra

Je re-assigne le probleme à Bruno avec Alexis en Watcher.

Actions #6

Updated by bruno katra about 7 years ago

Je répond à tous les échanges ci - dessous :

Est-ce cohérent avec les formes d'onde continues?

Non les formes d'ondes à F3 et les snapshots sont représentatifs du signal injecté. Pour ce qui est du bruit : les CWF montrent des valeurs autour de 400 pour E1 et E2 qui ne sont pas relié à une ANALOG DISCOVERY alors que les HK montrent des valeurs très différentes :

Exemple en 3.2.0.6 avec un sinus de 5Hz sur V et rien sur E1/E2:
CWF@F3 :
V E1 E2
6322 426 376
21400 426 376
-21751 426 376
-3803 426 376
25611 426 376
-14845 426 376
-13288 426 374
25981 426 376
-5630 426 376
-20708 426 379

HK correspondants :
SC V F3 | SC E1 F3 | SC E2 F3
-6864 -22272 31296
-8064 -22224 31280
-5728 -22064 30704

Pour comparer, il faudrait convertir tes données HK en int16, là, tu es en uint16.

Les valeurs lues dans le SGSE sont bien converties en int16 et tournent bien autour de +/- 20000 avec aucun signal injecté.

Actions #7

Updated by bruno katra about 7 years ago

J'ai refait des tests en 3.2.0.7, les résultats sont identiques à ceux que j'ai donné hier en 3.2.0.6 :

J'injecte un SInus à 5 Hz de -3/3V SUR V UNIQUEMENT :

Les valeurs du CWF @F3 sont cohérentes :

V    E1      E2
-12297     425     375
-10025 422 375
24997 425 375
-7839 422 375
-19709 424 375

On voit bien d'ailleurs le fameux noise dont parlait Véro sur E1/E2 : ces valeurs sont stables sur tout le CWF@F3

Les fichiers HK correspondants correspondants sont assez innatendues :

- Les valeurs pour V ne sont pas du tout raccord avec le signal injecté
- Les valeurs de E1 et E2 sont en opposition de phase l'un dans les positifs l'autre dans les negatifs. D'ailleurs les valeurs n'ont plus rien à voir avec celles du noise vu sur le CWF @F3 (~425).

Actions #8

Updated by bruno katra about 7 years ago

  • Assignee changed from bruno katra to paul leroy
Actions #9

Updated by bruno katra about 7 years ago

Afin de voir jusqu'où va la rgression j'ai refait le test en 3.2.0.7 avec un sinus à 0.1Hz qui était un cas où le moyannage était assez joli en 3.2.0.5. Il se trouve que cela ne marche plus. Ci dessous, la superposition du CWF @F3 et des HK :

En espérant que cela donne une piste.

Actions #10

Updated by paul leroy about 7 years ago

  • Assignee changed from paul leroy to bruno katra

Je pense que ce que j'ai mis en place (n'accepter de continuer la moyenne que si les trois valeurs, v, e1 et e2 ont changé) a fait plus de mal que de bien. Pour en être convaincu, je voudrais savoir si si j'enlève ce test, le comportement redevient comme celui que Thomas a réussi à expliciter (effet collatéral de la periode de 60ms de la tâche AVGV).
On peut refaire ton test avec la version 3.2.0.8 que je mets en ligne de suite?

Actions #11

Updated by bruno katra about 7 years ago

Bug toujours présent

Test rejoué en 3.2.0.8 en injectant 0.1Hz sur V et 5Hz sur E1 :
Les CWF F3 sont comme attendus :

Les HK montrent des courbes abérrantes :

Actions #12

Updated by paul leroy about 7 years ago

  • Assignee changed from paul leroy to bruno katra

cf bug #982 en cours de résolution. Refaire des tests avec 3.2.0.9.

Actions #13

Updated by bruno katra about 7 years ago

Tests rejoués en 3.2.0.9 : c'est mieux on retrouve une jolie moyenne sur le V à 0.1Hz, de même la moyenne sur le bruit de E2 est cohérent avec le CWF@F3. Le signal à 5Hz envoyé sur E1 quant à lui a une moyenne un peu étrange (Voir images ci-dessous):

Référence CWF @F3 :

Résultats HK correspondants :

Actions #14

Updated by paul leroy about 7 years ago

  • Assignee changed from paul leroy to thomas chust

Pour le E1, l'analyse de Thomas à partir de la forme d'onde donnerait peut-être une explication?

Actions #15

Updated by bruno katra about 7 years ago

  • Assignee changed from thomas chust to paul leroy

On a regardé les données avecThomas :

la moyenne autour de 500 counts est réglée (plus d'oscillation) MAIS les pics à ~2000 counts font effectivement penser au bug d'avant (du à prendre 2 fois le même échantillon).
Il y a donc encore un pb sous-jacent car la vraie moyenne à 16 Hz ne montre pas de pics dans la simu. Or le fait de détecter les changements devrait produire le même comportement qu'une moyenne à 16Hz.

Actions #16

Updated by bruno katra about 7 years ago

Test rejoué avec 2 sinus synchro à 4.5Hz injecté sur V et E1 (bruit sur E2) :

Il s'avère que le bug est toujours identique au comportement de la 3.2.0.3 (le semblant d'amélioration évoqué sur E1 est en fait surement du au choix de la frequence)

Suggestion de Thomas :

Il se pourrait qu'alors que la moyenne glissante ne s'effectue que lors d'un changement effectif des valeurs, les LIFO des 3 buffers de 16 échantillons soient toujours alimentées avec les valeurs dupliquées ?

Actions #17

Updated by paul leroy about 7 years ago

  • Assignee changed from paul leroy to thomas chust

Que donne la moyenne glissante sur CWF_F3? Je ne suis pas certain qu'on soit dans le même cas que 3.2.0.3.
J'ai fait quelques tests préliminaires sur des données CWF_F3 et avec 4.5 Hz, le résultat des moyennes glissantes ressemble à ce que vous obtenez. Bon, il faut avoir un peu d'imagination, mais la tendance est là (l'enveloppe des données semble correcte et on oscille). C'est pas évident de comparer puisque la période des HK (1s) n'est pas synchrone de la période d'échantillonnage (pas le même oscillateur), ni de la période de la tâche AVGV (60ms, même oscillateur que les HK mais pas un nombre entier de périodes par seconde).

Actions #19

Updated by bruno katra about 7 years ago

Mea Culpa : la figure de ce matin est fausse car j'avais laissé le générateur en auto-synchro entre les 2 canaux (0.1Hz sur V et 5Hz sur E1):

Nous avons refait des tests avec Thomas avec une config de générateur propre : ci -dessous aussi 0.1Hz sur V et 5Hz sur E1

C'est bien le résultat attendu. Sauf un pic au début qui semble lié au changement de mode standby vers normal déjà obervé par Véro (#955). Aussi on a l'impression que la moyenne n'est pas faite en mode STANDBY (je rédige un nouveau redmine pour ça)

D'autres tests avec 1.5 Hz, 2.5Hz, 3.5Hz montrent aussi un comprtement attendu : on observe effectivement une oscillation en accord avec la FT théorique (sinus cardinal).

Donc le pb ici est considéré comme clos

Actions

Also available in: Atom PDF