Bug #54
closed
TM_LFR_PARAMETER_DUMP: affectation de SY_LFR_S1_BP_P0 par défaut
0%
Description
Cette issue est associée à l'issue Bug#53 ('TM_LFR_PARAMETER_DUMP incohérent avec l'ICD').
Dans un 'TM_LFR_PARAMETER_DUMP', le champ SY_LFR_S1_BP_P0 par défaut (/SOURCE_DATA/LFR_SBM1_PARAMETERS) est affecté à 1.
Le LSB étant de 0.25, on en déduit la valeur 0.25s.
La valeur spécifiée par défaut est 1s.
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
LFR FSW: 1.0.0.1 (variante sur carte finale)
Brique Star-Dundee S/N 46120065.
TEST CASE = SVS_0001
RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev0
RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev1
Updated by paul leroy about 10 years ago
- Status changed from New to Resolved
Il y a une erreur dans l'ICD. Si on se réfère à la spécification LFR, RPW-MEB-LFR-00003, la valeur par défaut du paramètre est 0.25 s.
J'ai transféré l'info dans l'issue #62.
Updated by Gerald Saule about 10 years ago
- Status changed from Resolved to Closed
- revision changed from r98 to r104
Sans TC_LFR_LOAD_NORMAL_PAR préalable, un TC_LFR_DUMP_PAR accepté provoque:
14:01:58.571041, 1, 2, 0, 0, 12, 201, 192, 1, 0, 29, 16, 3, 25, 0, 0, 0, 0, 16, 165, 173, 10, 0, 16, 8, 0, 1, 44, 14, 16, 4, 20, 0, 0, 1, 5, 1, 1, 1, 5, 0
14:01:58.571041, TM_LFR_PARAMETER_DUMP, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: DUMP = 9, (PACKET_ID=0xcc9), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=1, (PACKET_SEQUENCE_CONTROL=0xc001), PACKET_LENGTH=29, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: HOUSEKEEPING_AND_DIAGNOSTIC_DATA_REPORTING = 3, SERVICE_SUBTYPE: HK_PARAMETER_REPORT = 25, DESTINATION_ID: GROUND = 0, TIME=0x00000010a5ad, PA_LFR_HK_SID: LFR_DUMP_SID = 10, SPARE=0x0, SY_LFR_BW=1, SY_LFR_SP0=0, SY_LFR_SP1=0, SY_LFR_R0=0, SY_LFR_R1=0, SY_LFR_N_SWF_L=2048, SY_LFR_N_SWF_P=300(s), SY_LFR_N_ASM_P=3600(s), SY_LFR_N_BP_P0=4(s), SY_LFR_N_BP_P1=20(s), SPARE=0x0, SY_LFR_N_CWF_LONG_F3=0, SPARE=0x0, SY_LFR_B_BP_P0=1(s), SY_LFR_B_BP_P1=5(s), SY_LFR_S1_BP_P0=0.25(s), SY_LFR_S1_BP_P1=1(s), SY_LFR_S2_BP_P0=1(s), SY_LFR_S2_BP_P1=5(s), SPARE=0x0
Cela montre l'ambiguité des valeurs par défaut pour tout champ avec le LSB<>1; la valeur de l'ICD est-elle la valeur du champ transmis, ou la valeur numérique de la grandeur. L'issue Bug #62 (Mise à jour ICD) trace ce risque d'incompréhension.
=>Le fonctionnement initialement reproché est finalement le fonctionnement voulu. N'ayant pas été rejetée, cette issue peut donc être fermée.
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_VHDLib206 (Carte mini-LFR)
Soft: 1.0.0.2 (variante sur carte finale) = r104
Brique Brique Star-Dundee S/N 46120065.
RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev0
RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev1
Updated by bruno katra almost 10 years ago
- Status changed from Closed to In Progress
- Assignee changed from paul leroy to bruno katra
Le comportement de LFR est correct (dépouillement des TM OK : SY_LFR_S1_BP_P0=1 soit 0.25s) mais les script de Gérald fabrique mal la TC_LOAD_SBM1_PAR (avec 4 au lieu de 1) + il les decrypte mal (4x4).
Il faut corriger les scripts Python de Gérald.
---------------------------
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.1.16
LFR FSW: 1.0.0.8 (variante sur carte finale)
Brique Star-Dundee S/N 46120065.
TEST CASE = SVS_0065
Updated by bruno katra almost 10 years ago
- Status changed from In Progress to Closed
- Assignee changed from bruno katra to Veronique bouzid
Les fichiers de Gérald ont été modifés afin de corriger le bug cité sur la TC :
tc_lfr_load_sbm1_par_analyze.py corrigé
tc_def.py corrigé.
12:43:41.799091, TC_LFR_LOAD_SBM1_PAR, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TC_PACKET = 1, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: PRIVATE_SCIENCE_OR_TELECOMMAND = 12, (PACKET_ID=0x1ccc), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=0, (PACKET_SEQUENCE_CONTROL=0xc000), PACKET_LENGTH=7, CCSDS_SECONDARY_HEADER_FLAG=0, PUS_VERSION = 1, ACK_EXECUTION_COMPLETION=1, ACK_EXECUTION_PROGRESS=0, ACK_EXECUTION_START=0, ACK_ACCEPTANCE=1, SERVICE_TYPE: EQ_CONFIGURATION = 181, SERVICE_SUBTYPE: LOAD_SBM1_PARAMETERS = 25, SOURCE_ID: MISSION_TIMELINE = 110, SY_LFR_S1_BP_P0 = 0.25(s), SY_LFR_S1_BP_P1 = 1(s), CRC = 0xac
12:43:42.20445, TM_LFR_PARAMETER_DUMP, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: DUMP = 9, (PACKET_ID=0xcc9), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=1, (PACKET_SEQUENCE_CONTROL=0xc001), PACKET_LENGTH=29, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: HOUSEKEEPING_AND_DIAGNOSTIC_DATA_REPORTING = 3, SERVICE_SUBTYPE: HK_PARAMETER_REPORT = 25, DESTINATION_ID: GROUND = 0, TIME=0x8000000ac7be, PA_LFR_HK_SID: LFR_DUMP_SID = 10, SPARE=0x0, SY_LFR_BW=1, SY_LFR_SP0=0, SY_LFR_SP1=0, SY_LFR_R0=0, SY_LFR_R1=0, SY_LFR_N_SWF_L=2048, SY_LFR_N_SWF_P=300(s), SY_LFR_N_ASM_P=3600(s), SY_LFR_N_BP_P0=4(s), SY_LFR_N_BP_P1=20(s), SPARE=0x0, SY_LFR_N_CWF_LONG_F3=0, SPARE=0x0, SY_LFR_B_BP_P0=1(s), SY_LFR_B_BP_P1=5(s), SY_LFR_S1_BP_P0=0.25(s), SY_LFR_S1_BP_P1=1(s), SY_LFR_S2_BP_P0=1(s), SY_LFR_S2_BP_P1=5(s), SPARE=0x0