Project

General

Profile

Bug #515

[JIRA] (RPWMEB-465) Status of HK_LFR_SC_POTENTIAL_FLAG in TM_LFR_HK

Added by Veronique bouzid about 6 years ago. Updated about 6 years ago.

Status:
Closed
Priority:
Normal
Category:
SRS
Target version:
-
Start date:
28/09/2015
Due date:
% Done:

0%

Estimated time:
revision:
r0

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

History

#1 Updated by paul leroy about 6 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

#2 Updated by paul leroy about 6 years ago

  • Status changed from New to Feedback
  • Assignee changed from paul leroy to Veronique bouzid

#3 Updated by bruno katra about 6 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?

#4 Updated by paul leroy about 6 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.

#5 Updated by Veronique bouzid about 6 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.

#6 Updated by Veronique bouzid about 6 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.

#7 Updated by Veronique bouzid about 6 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

#8 Updated by bruno katra about 6 years ago

  • Status changed from Feedback to Closed

Ajout fait dans SRS 1.9

Also available in: Atom PDF