Project

General

Profile

Bug #89

Attente de la première TM_LFR_SCIENCE_BURST_CWF_F2/TM_LFR_SCIENCE_NORMAL_SWF_Fx supérieure à sa période

Added by Gerald Saule over 7 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Low
Assignee:
Category:
-
Target version:
-
Start date:
13/03/2014
Due date:
% Done:

100%

Estimated time:
revision:
r104

Description

A partir du passage en mode BURST, la première TM_LFR_SCIENCE_BURST_CWF_F2 est envoyée 13s plus tard.
C'est inatendu, car on attend une période entre ces salves de TM_LFR_SCIENCE_BURST_CWF_F2 de 10.5s (1688/F2).
Cela ne pose pas de pb fonctionnel; ainsi, la "Priority" de cette issue est estimée à Low (en mode BURST établi, la période est correcte).

Contexte:
LPPMON Version=0.2.2 - Branch=default - Changeset=835955994d5f

Carte mini-LFR: LFR-172200 dev V1.0; No série III (sans connecteurs sub-click)

Vhdl: mini-lfr_0.0.0.15

Soft: 1.0.0.2 (variante sur carte finale) = r104

Brique: Brique Star-Dundee S/N 46120065.

TEST CASE = SVS_0041

RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev0
RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev1

History

#1 Updated by Gerald Saule over 7 years ago

  • Subject changed from Attente de la première TM_LFR_SCIENCE_BURST_CWF_F2 supérieure à sa période to Attente de la première TM_LFR_SCIENCE_BURST_CWF_F2/TM_LFR_SCIENCE_NORMAL_SWF_Fx supérieure à sa période

Le même genre de cas se reproduit avec le TM_LFR_SCIENCE_NORMAL_SWF_Fx:

16:08:30.359944, TC_LFR_LOAD_NORMAL_PAR, SY_LFR_N_SWF_L = 2048, SY_LFR_N_SWP_P = 16(s)
16:08:30.362735, TM_LFR_TC_EXE_SUCCESS
16:08:31.260803, TM_LFR_HK
16:08:31.36045, TC_LFR_DUMP_PAR
16:08:31.364025, TM_LFR_PARAMETER_DUMP, SY_LFR_N_SWF_L=2048, SY_LFR_N_SWF_P=16(s)
16:08:31.364233, TM_LFR_TC_EXE_SUCCESS
16:08:31.560941, TC_LFR_ENTER_MODE (CP_LFR_MODE=1)
16:08:31.577734, TM_LFR_TC_EXE_SUCCESS
16:08:32.26078, TM_LFR_HK
16:08:33.260819, TM_LFR_HK
16:08:34.260819, TM_LFR_HK
16:08:35.26082, TM_LFR_HK
16:08:36.260797, TM_LFR_HK
16:08:37.260785, TM_LFR_HK
16:08:38.260788, TM_LFR_HK
16:08:39.260789, TM_LFR_HK
16:08:40.260813, TM_LFR_HK
16:08:41.260794, TM_LFR_HK
16:08:42.260782, TM_LFR_HK
16:08:43.260784, TM_LFR_HK
16:08:44.260787, TM_LFR_HK
16:08:45.260811, TM_LFR_HK
16:08:46.260793, TM_LFR_HK
16:08:47.260782, TM_LFR_HK
16:08:48.260782, TM_LFR_HK
16:08:49.260662, TM_LFR_HK
16:08:50.260655, TM_LFR_HK
16:08:51.260658, TM_LFR_HK
16:08:52.260635, TM_LFR_HK
16:08:53.260639, TM_LFR_HK
16:08:54.260634, TM_LFR_HK
16:08:55.230899, TM_LFR_SCIENCE_NORMAL_SWF_F0

La salve de TM_LFR_SCIENCE_NORMAL_SWF_Fx arrive après 23,6s après l'activation du flot de TM_LFR_SCIENCE_NORMALs. En régime établi, on observe les salves à la période de ~16s.

La conséquence collatérale de ce point est une remise en cause du principe de vérification de non-émission.
En effet, pour vérifier qu'une TM de période fixée T n'est pas émise, j'attendais 1.1 * T pour vérifiée l'absence d'émission. Cette issue montre que le facteur 1.1 ne permet pas une vérification probante.
Ce coefficient ne peut pas être élevé inconsidérablement, car sur des périodes d'une heure, les tests seront trop longs.

Contexte:
LPPMON Version=0.2.2 Branch=default Changeset=835955994d5f
Carte mini-LFR:LFR-172200 dev V1.0; No série III (sans connecteurs sub-click)
Vhdl: mini-lfr_0.0.15
Soft: 1.0.0.1 (variante sur carte finale)
Brique Star-Dundee S/N <blank>.

TEST CASE = SVS_0073

RPW-SYS-IDB-00067-LES_Issue2_Rev2
RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev2
RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev2

#2 Updated by paul leroy over 7 years ago

  • Status changed from New to Resolved

avec fsw <= 1.0.0.3 et peut-être quelques versions ultérieures, voici comment démarrent les modes:
=> réception de la TC_LFR_ENTER_MODE à T0
=> préparation de l'acquisition au niveau hardware pour un démarrage à T0 + 2 secondes
=> l'acquisition démarre à T0 + 2 secondes
=> le premier paquets CWF_F2 est émis à T0 + 2 + 10.5

Pour les snapshots, en mode normal, le snapshot démarre à
T_start = (T - 1/2 * 2048 * f_sampling)
et il se finit à T_stop = T_start + 2688 * f_sampling
ATTENTION: il faut bien lire 2688 au dessus. On acquière plus d'échantillons que le minimum nécessaire (2048).

En mode SBM1 ou SBM2, les snapshots sont reconstruits à partir des données continues, et c'est encore un peu plus compliqué pour savoir quand le snapshot va être émis. Je peux vous donner les délais nominaux au cas par cas pour que vos tests d'émission des TM périodiques ne soient pas trop longs.

#3 Updated by paul leroy over 7 years ago

  • Assignee changed from paul leroy to bruno katra

#4 Updated by bruno katra over 4 years ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100

Plus d'actualité car de nombreuses modifs ont été faites sur l'algo de resynchro des SWF.

Also available in: Atom PDF