Project

General

Profile

Actions

Bug #1081

closed

NC 287 CNES : pb dans certains SWF durant calibration nov 2016 : la mauvaise freq apparait dans le SWF

Added by bruno katra about 7 years ago. Updated almost 6 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
25/04/2017
Due date:
% Done:

0%

Estimated time:
revision:
r0

Description

Nouvelle anomalie présentée par Emmanuel. Possible désynchronisation de snapshots LFR dans de très rares cas. Un exemple a été produit. Thomas va regarder dans ses datas. NC 287.

Salut Emmanuel,
Je viens de regarder d'un peu plus près le cas bizarre que tu nous a présenté vendredi dernier. Il s'agit du 4ème SWF_F2 dans le 3ème bloc du SWEEP "PFM_CAL_LFR_SWEEP_CONF2_F0_F1_F2_100K_2016-11-25_Run1__fd3bcc8__CNES":

Les snapshots sont réguliers et bien séparés de 22 s comme il se doit. Une FFT sur le snapshot incriminé (le 4ème dans la figure ci-dessus) montre en effet la présence de 2 fréquences, 96Hz + 100Hz:

Faire la FFT que la portion gauche du snapshot ne montre qu'une fréquence (quasi pure) à 96Hz. Inversement faire la FFT que sur la portion droite ne montre que la fréquence à 100Hz (également quasi-pure). Hormis remettre en cause la datation des données LFR je ne vois pas d'autre possibilité que de dire que le GSE a arrêté la génération des signaux à 96Hz et enclenché celle à 100Hz beaucoup plus tôt que prévu ...

J'essaie demain de voir ce que les fichiers de stimuli contiennent.

Xavier, j'ai une question. Pour ce jeu de données les HK sont enregistrés toutes les 5 s et non toutes les 1s. Est-ce normal ? Problème de version pipeline utilisé (ici 1.1.10) ?

a+
Thomas


Files

Actions #1

Updated by bruno katra about 7 years ago

Verifs effectuées dans les HK CDF :
- LFR est synchro à priori (UPDATE_TIME + Timecode)
- on n'a que 1 HK/5

Thomas a vérifié le fichier de stimuli du GSE CNES : à priori OK

Demande à Emmanuel de précisions :

Hello,

Durant les calibrations on aurait vu le bug 1 fois par sweep LFR à peu près, ce qui correspond à un bug tous les 60 snapshots.

Etant donné que nous avons fait le même test systématiquement pour toutes les configurations BIAS et pour tous les paliers de température, on peut dire que nous avons joué le même test 7x10=70 fois.

D’après Seb Tellier qui a fait les essais l’erreur interviendrai plus souvent entre le 40 et le 60ème snapshot.

Pour trouver des cas, il faut regarder les fonctions de transfert faites pendant les calibrations et quand tu vois un décrochage sur un seul point de la fonction de transfert parmi d’autres, c’est surement un moment où il y a désynchronisation. C’est comme cela que nous avons trouvé l’exemple.

A+

Actions #2

Updated by bruno katra about 7 years ago

Salut Emmanuel, merci mais je me suis mal fait comprendre : je ne sais pas lire ce fichier XML. Je demandais si par hasard vous auriez le flux binaire de LFR tel qu'il sort lorsque tu coches "Store Raw" du GSE LFR. Merci quand même.

J'ai réécrit de mon côté un scénario qui est très proche du votre (sweep 1freq par SWF) et je vais le faire tourner pour voir si on arrive à reproduire le bug mais manque de bol l'alim de l'EQM vient de nous lacher donc je n'ai plus qu'une alim que je dois partager avec le banc de test de la non-regression... Y'a des jours...

Je vous tiens au courant

A+

Bruno

Le 24/04/2017 à 16:04, Guilhem Emmanuel (ALTRAN TECHNOLOGIES) a écrit :

Hello,

Voila l’extract SGSE pour le test avec desynchronisation, vous trouverez dedans toutes les TMs notamment celles de configuration de LFR.

A+

Emmanuel

Actions #3

Updated by bruno katra almost 6 years ago

  • Status changed from In Progress to Closed

Pb corrigé par Alexis dans FSW >= 3.2.0.16. Pb causée par un bug SW dans les buffers rotatifs de Paul. Pb et solution présentée lors du Consortium meeting JUIN 2018.

Actions

Also available in: Atom PDF