Bug #89: Attente de la première TM_LFR_SCIENCE_BURST_CWF_F2/TM_LFR_SCIENCE_NORMAL_SWF_Fx supérieure à sa période - LFR-FSW - Redmine

Actions

#1

Updated by Gerald Saule over 10 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

Actions

Copy link

#2

Updated by paul leroy over 10 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.

Actions

Copy link

#3