Bug #65
closed
TC_LFR_LOAD_NORMAL_PAR: pas de vérif sur SY_LFR_N_ASM_P, S_LFR_N_BP_P0, SY_LFR_N_BP_P1.
0%
Description
Cette issue reprend l'issue Bug #905 (TC_LFR_LOAD_NORMAL_PAR: pas de vérif sur SY_LFR_N_ASM_P, S_LFR_N_BP_P0, SY_LFR_N_BP_P1).
Pour TC_LFR_LOAD_NORMAL_PAR, les champs SY_LFR_N_ASM_P, S_LFR_N_BP_P0, SY_LFR_N_BP_P1 ne sont pas controlés.
La valeur 0 devrait être un moyen simple d'obtenir un rejet (il s'agit de périodes).
LFR retourne TM_LFR_TC_EXE_SUCCESS.
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
Brique Star-Dundee S/N 46120065.
Soft:1.0.0.1 (variante sur carte finale)
TEST CASE = SVS_0008
RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev0
RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev1
Related issues
Updated by paul leroy about 10 years ago
- Status changed from New to In Progress
les paramètres concernant les matrices spectrales (ASM) et les paramètres basiques (BP) ne sont pas implémentés pour l'instant. le design VHDL n'est pas suffisament mature.
Updated by bruno katra almost 10 years ago
Discussions avec Thomas Chust : SY_LFR_N_ASM_P devrait être minimum à 4 et un multiple de 4.
Or il est possible de demander SY_LFR_N_ASM_P = 0, SY_LFR_N_ASM_P=1 et SY_LFR_N_ASM_P=2 qui sont acceptés :
15:02:49.807246, 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=7, (PACKET_SEQUENCE_CONTROL=0xc007), 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=0x800004d9750c, 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=16(s), SY_LFR_N_ASM_P=0(s), SY_LFR_N_BP_P0=1(s), SY_LFR_N_BP_P1=1(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
14:46:25.392409, 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=4, (PACKET_SEQUENCE_CONTROL=0xc004), 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=0x8000010108c8, 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=16(s), SY_LFR_N_ASM_P=1(s), SY_LFR_N_BP_P0=1(s), SY_LFR_N_BP_P1=1(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
MAIS ces valeurs sont refusés si demandées via LPPMON : 0 et 1 sont impossibles à entrer dans l'IHM et la valeur 2 génère un TM_LFR_TC INCONSISTENT :
Détail en csv de l'ack :
2014 6 10 14:51:48:650 1 2 0 0 12 193 192 20 0 19 16 1 8 254 128 0 2 68 75 127 0 5 28 204 192 0 181 13 14 2
Est-il normal d'avoir cette différence de comportement.
--------------------------------------------
Contexte:
LPPMON: Version=0.2.2 Branch=default Changeset=835955994d5f
Carte mini-LFR: LFR-172200 dev V1.0; No série 5
Vhdl: mini-lfr_0.1.9
Brique Star-Dundee S/N 46120065
Soft:1.0.0.7 (variante sur carte finale)
TEST CASE = SVS-0019
script : just_mode_counter_loop.py
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
Updated by bruno katra almost 10 years ago
- Assignee set to paul leroy
- Priority changed from Normal to Immediate
Updated by paul leroy almost 10 years ago
- Status changed from In Progress to Resolved
- Assignee changed from paul leroy to bruno katra
fsw >= 1.0.0.9, tous les paramètres sont contrôlés.
Pour l'instant, le minimum est à 4 pour sy_lfr_n_asm_p (c'est à dire égal à sy_lfr_n_bp_p0). sy_lfr_n_asm_p doit être un multiple de sy_lfr_n_bp_p0 sinon le paramètre est rejeté.
L'interface lppmon est une interface d'utilisation rapide du système, elle n'a pas le niveau de détails obtenu avec des scripts Python, et notamment certaines valeurs de paramètres sont bridées. Ca peut être modifié si il y a un besoin, ne pas hésiter à demander.
Pour le multiple de 4, si c'est une demande explicite, il faut qu'on ajoute cela dans l'ICD.
Updated by bruno katra almost 10 years ago
- Status changed from Resolved to Closed
Retesté en 1.0.0.9 avec des périodes ASM de 0, 1, 2, 3 et 5 :
Le bug semble corrigé sauf pour 0 (bug tracée dabs l'issue #85).
15:59:36.606746, TC_LFR_LOAD_NORMAL_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=4076, (PACKET_SEQUENCE_CONTROL=0xcfec), PACKET_LENGTH=15, 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_NORMAL_PARAMETERS_1 = 13, SOURCE_ID: MISSION_TIMELINE = 110, SY_LFR_N_SWF_L = 2048, SY_LFR_N_SWP_P = 16(s), SY_LFR_N_ASM_P = 1(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, CRC = 0xfddc
15:59:36.60918, TM_LFR_TC_EXE_INCONSISTENT
idem pour 2, 3 et 5.
Je note qu'il faudra faire remonter au niveau de l'ICD les valeurs min/max et cohérentes entre elles. Il faut remplir l'issue #62 en conséquence.