Bug #515
closed
[JIRA] (RPWMEB-465) Status of HK_LFR_SC_POTENTIAL_FLAG in TM_LFR_HK
0%
Description
During the last acceptance test compaign, an anomaly in TM_LFR_HK telemetry packet has been detected.
The value of parameter HK_LFR_SC_POTENTIAL_FLAG (related to spacecraft potential) is always FALSE, even during the production of TM_LFR_SCIENCE_NORMAL_CWF_F3 telemetry packets.
see: [RPWDPU-715_Test143_LFR_R3_Acceptance_Test_001]
LFR Software version 3.0.0.1
DAS Software version 2.5.3.0
IDB version 3.8.0
Updated by paul leroy over 8 years ago
corrigé dans fsw >= 3.0.0.9
dès le démarrage, en mode STANDY, les données sc_potentials sont remontées dans les paquets housekeeping
Updated by paul leroy over 8 years ago
- Status changed from New to Feedback
- Assignee changed from paul leroy to Veronique bouzid
Updated by bruno katra over 8 years ago
- Assignee changed from Veronique bouzid to paul leroy
Quelle est la signification de ce champs HK_LFR_SC_POTENTIAL_FLAG?
Nous ne comprenons pas bien quel doit être le comprtement de ce champs et donc comment le valider?
Nous comprenons que à partir de fsw 3.0.0.9 il est toujours ON. Quid de la pertinence?
Updated by paul leroy over 8 years ago
- Assignee changed from paul leroy to Veronique bouzid
Ce champ sert à valider la présence des mesures dans les HK. De notre côté, les mesures sont disponibles tout de suite après le boot qui se charge de resetter la partie acquisition durant l'initialisation.
Updated by Veronique bouzid over 8 years ago
- Category set to SRS
Voici quelques précisions fournies par Paul, à METTRE dans la SRS
Actuellement le bit ne passe jamais à zéro, ce que tu as remarqué en faisant ton travail de validatin. En fait, en STANDBY, l'acquisition tourne mais les données sont oubliées et non utilisées. Par contre, la valeur des f3 est mise à jour dans un registre spécifique, qu'on peut lire ou pas. Comme c'est dispo, je lis le registre.
Le flag HK_LFR_SC_POTENTIAL_FLAG est associé aux champs suivants:
- HK_LFR_SC_V_F3, HK_LFR_SC_E1_F3, HK_LFR_SC_E2_F3
Pour la vérif, ce que tu peux tester est qu'effectivement, si tu mets du signal, les housekeeping renvoient les bonnes valeurs, ce qui confirmerait que le flag est utilisé à bon escient: si il est à 1, les données sont valides.
Updated by Veronique bouzid over 8 years ago
Pour valider ce point,
Mettre un signal carré sur V (periode de 5s) idem pour E1 E2
Lire dans les housekeeping le champs HK_LFR_SC_V_F3, (HK_LFR_SC_E1_F3, HK_LFR_SC_E2_F3) durant 30 secondes
On doit retrouver le signal sur HK_LFR_SC_V_F3, (HK_LFR_SC_E1_F3, HK_LFR_SC_E2_F3).
Le signal ne sera pas parfaitement carré à cause du filtrage.
Updated by Veronique bouzid over 8 years ago
1- Mettre à jour JIRA avec les conclusions décrites si dessous
2- Les tests joués sur 3.0.0.9 montrent que quelque soit le mode (0,1,2,3,4) HK_LFR_SC_POTENTIEL_FLAG est ON.
le script utilisé est /opt/VALIDATION_R3/lfrverif/LFR_SVS/SVS-0019/tm_sequence_counter_loop.py mais n'importe quel test peut etre utilisé
Les fichiers (2015_10_01-12_30_34*) sont rangés dans /home/validation/data/R3/3.0.0.9/1.1.89/SVS-0019.
Voici un extrait des traces pour chacun des modes.
11:57:56.680058, 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=8, (PACKET_SEQUENCE_CONTROL=0xc008), 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=0x8000000a31b3, PA_LFR_HK_REPORT_SID: LFR_HK_SID = 1, HK_LFR_MODE: STANDBY = 0, 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
11:59:06.680175, 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=78, (PACKET_SEQUENCE_CONTROL=0xc04e), 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=0x8000005031b4, 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
11:59:07.680187, 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=79, (PACKET_SEQUENCE_CONTROL=0xc04f), 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=0x8000005131b4, PA_LFR_HK_REPORT_SID: LFR_HK_SID = 1, HK_LFR_MODE: BURST = 2, 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
11:59:08.680027, 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=80, (PACKET_SEQUENCE_CONTROL=0xc050), 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=0x8000005231b4, PA_LFR_HK_REPORT_SID: LFR_HK_SID = 1, HK_LFR_MODE: SBM1 = 3, 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,
11:59:10.680791, 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=82, (PACKET_SEQUENCE_CONTROL=0xc052), 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=0x8000005431b4, PA_LFR_HK_REPORT_SID: LFR_HK_SID = 1, HK_LFR_MODE: SBM2 = 4, 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,
Le script de validation (hk_reporting.py) remontera un warning si le champ HK_LFR_SC_POTENTIAL_FLAG = 0.
Contexte du test
----------------
FSW 3.0.0.9
VHDL 1.1.89
EM sans Timegen
SocExplorerEngine.getSocExplorer: Version = 0.6.2, Branch = default, Changeset = 819d0376d481
StarDundee
Updated by bruno katra over 8 years ago
- Status changed from Feedback to Closed
Ajout fait dans SRS 1.9