Bug #480
closed
R3 *** HK_LFR_MAG_FIELDS_FLAG never updated
100%
Description
METTRE A JOUR LA SRS AVEC LA REPONSE DE PHILIPPE
le champ HK_LFR_MAG_FIELDS_FLAG est codé sur sur 1 bit. Au démarrage de LFR HK_LFR_MAG_FIELDS_FLAG = 0
Paul me précise qu il est mis à jour quand les données magnétiques sont présentes (SY_LFR_N_CWF_LONG_F3=1).
J'utilise le script /opt/VALIDATION_R3/lfrverif/LFR_SVS/SVS-0029/normal_mode_parameter_set.py
Ici la trace
17:57:17.849348, 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 = 6, (PACKET_ID=0xcc6), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=6, (PACKET_SEQUENCE_CONTROL=0xc006), PACKET_LENGTH=77, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: EQ_CONFIGURATION = 181, SERVICE_SUBTYPE: PARAMETER_DUMP = 32, DESTINATION_ID: GROUND = 0, TIME=0x80001533aa3b, 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_R2=0, SY_LFR_N_SWF_L=2048, /!\SY_LFR_N_SWF_P=65535(s), SY_LFR_N_ASM_P=65535(s), SY_LFR_N_BP_P0=255(s), SY_LFR_N_BP_P1=255(s), SPARE=0x0, SY_LFR_N_CWF_LONG_F3=1, 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), SY_LFR_FBINS_F0_WORD1=0xffffffff, SY_LFR_FBINS_F0_WORD2=0xffffffff, SY_LFR_FBINS_F0_WORD3=0xffffffff, SY_LFR_FBINS_F0_WORD4=0xffffffff, SY_LFR_FBINS_F1_WORD1=0xffffffff, SY_LFR_FBINS_F1_WORD2=0xffffffff, SY_LFR_FBINS_F1_WORD3=0xffffffff, SY_LFR_FBINS_F1_WORD4=0xffffffff, SY_LFR_FBINS_F2_WORD1=0xffffffff, SY_LFR_FBINS_F2_WORD2=0xffffffff, SY_LFR_FBINS_F2_WORD3=0xffffffff, SY_LFR_FBINS_F2_WORD4=0xffffffff, SPARE8_2=0x0
17:57:18.038364, TC_LFR_ENTER_MODE (CP_LFR_MODE=1), 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=13, 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: ENTER_MODE = 41, SOURCE_ID: MISSION_TIMELINE = 110, SPARE=0, CP_LFR_MODE: NORMAL = 1, CP_LFR_ENTER_MODE_TIME=0x000000000000, CRC = 0xca9b
17:57:18.061269, TM_LFR_TC_EXE_SUCCESS, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: ACKNOWLEDGE = 1, (PACKET_ID=0xcc1), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=24, (PACKET_SEQUENCE_CONTROL=0xc018), PACKET_LENGTH=13, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: TELECOMMAND_VERIFICATION = 1, SERVICE_SUBTYPE: TC_EXECUTION_COMPLETION_SUCCESS = 7, DESTINATION_ID: MISSION_TIMELINE = 110, TIME=0x80001533e0f4, PA_RPW_TELECOMMAND_PKT_ID=0x1ccc, PA_RPW_PKT_SEQ_CONTROL=0xc000
17:57:18.385053, TM_LFR_HK, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: HK_ROUTINE = 4, (PACKET_ID=0xcc4), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=5426, (PACKET_SEQUENCE_CONTROL=0xd532), PACKET_LENGTH=129, 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=0x8000153433da, PA_LFR_HK_REPORT_SID: LFR_HK_SID = 1, HK_LFR_MODE: NORMAL = 1, HK_LFR_DPU_SPW_ENABLED: ENABLED = 1, HK_LFR_DPU_SPW_LINK_STATE: RUN = 5, SPARE=0x0, HK_LFR_SC_POTENTIEL_FLAG: ON = 1, HK_LFR_MAG_FIELDS_FLAG: OFF = 0,
Ce champ n'est jamais mis à jour car pas pris en compte.
le fichier de trace est dans /home/validation/data/R3/3.0.0.8/1.1.88/SVS-0029/2015_07_28-18_32_00-Detail.txt
Contexte du test
----------------
FSW 3.0.0.8
VHDL 1.1.88
EM sans Timegen
SocExplorerEngine.getSocExplorer: Version = 0.6.2, Branch = default, Changeset = 819d0376d481
StarDundee
Updated by paul leroy about 9 years ago
- Status changed from New to Feedback
- Assignee changed from paul leroy to Veronique bouzid
J'ai reconsidéré ma position. Le champ HK_LFR_MAG_FIELDS_FLAG ne devrait plus exister (faire remonter à Philippe?). Il date de l'époque où les données magnétiques étaient censées être recopiées dans les HK. Ce n'est plus le cas.
Updated by bruno katra about 9 years ago
- Assignee changed from Veronique bouzid to paul leroy
Est-ce sûr ?
Je ne trouve nul part la définition de ce champs (ICD, SSS, IDB) ni son comportement. Je vois juste que c'est un champ ajouté dans l'ICD 3.1.
Updated by paul leroy about 9 years ago
- Assignee changed from paul leroy to bruno katra
Je pense qu'il faut remonter l'info à Philippe.
Updated by bruno katra about 9 years ago
- Description updated (diff)
- Status changed from Feedback to Resolved
- % Done changed from 0 to 100
Le 29 septembre 2015 11:29, Bruno Katra
<bruno.katra@lpp.polytechnique.fr> a écrit :
Re-bonjour Philippe, je viens t'embêter à nouveau concernant cette fois le
champs HK_LFR_MAG_FIELDS_FLAG dans les paquets HK de LFR.
Le logiciel de vol ne met pas à jour ce champs actuellement. Après échanges
et analyse avec Paul, nous n'avons pas trouvé la description du comportement
de ce champs à part qu'il a été introduit dans l'ICD 3.1. J'ai cherché dans
la SSS3.5, IDB3.11 et ICD 3.11.
J'imagine que l'info est quelque part et que je l'ai raté, tu pourras sans
doute nous éclairer.
C'est un champ qui n'est plus utilisé (obsolète) mais qu'on va laisser
dans les HK de LFR. Il aurait fallu nous le signaler plus tôt !
Updated by bruno katra about 9 years ago
- Status changed from Resolved to Closed
Mis à jour dans SRS 1.9