Project

General

Profile

Bug #172

Perte SEQUENCE_CNT dans APID=0xccc

Added by Veronique bouzid over 7 years ago. Updated over 7 years ago.

Status:
Closed
Priority:
Normal
Category:
-
Target version:
-
Start date:
16/06/2014
Due date:
% Done:

0%

Estimated time:
revision:
r0

Description

Sur le test SVS-0019 (tous les produits sont utilisés excepté CWF_F3_LONG).

j ai observé 2 pertes de TM (j en ai trouvé d'autres que j'ai réussi à expliquer, chgt de mode par exemple)

1- le SEQUENCE_CNT passe de 17 à 19

15:18:54.859535, TM_LFR_SCIENCE_NORMAL_BP1_F1, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: PRIVATE_SCIENCE_OR_TELECOMMAND = 12, (PACKET_ID=0xccc), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=17, (PACKET_SEQUENCE_CONTROL=0xc011), PACKET_LENGTH=137, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: SCIENCE_DATA_TRANSFER = 21, SERVICE_SUBTYPE: SCIENCE_REPORT = 3, DESTINATION_ID: GROUND = 0, TIME=0x80000061f589, PA_LFR_SID_PKT: SC_N_BP1_F1 = 15, PA_BIA_MODE_MUX_SET: SET_0 = 0, PA_BIA_MODE_HV_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS1_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS2_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS3_ENABLED: DISABLED = 0, PA_BIA_ON_OFF: OFF = 0, PA_LFR_ACQUISITION_TIME=0x80000061f589, SPARE=0x0, PA_LFR_N_BP1_BLK_NR_F1=13

15:18:54.90454, TM_LFR_SCIENCE_NORMAL_BP1_F2, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: PRIVATE_SCIENCE_OR_TELECOMMAND = 12, (PACKET_ID=0xccc), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=19, (PACKET_SEQUENCE_CONTROL=0xc013), PACKET_LENGTH=127, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: SCIENCE_DATA_TRANSFER = 21, SERVICE_SUBTYPE: SCIENCE_REPORT = 3, DESTINATION_ID: GROUND = 0, TIME=0x80000061fbfb, PA_LFR_SID_PKT: SC_N_BP1_F2 = 16, PA_BIA_MODE_MUX_SET: SET_0 = 0, PA_BIA_MODE_HV_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS1_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS2_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS3_ENABLED: DISABLED = 0, PA_BIA_ON_OFF: OFF = 0, PA_LFR_ACQUISITION_TIME=0x80000061fbfb, PA_LFR_N_BP1_BLK_NR_F2=12

Je n ai pas trouvé d 'explication.

2- Dans cette perte, les sequences_cnt passent de 4647 à 4649 à 4647 à 4649 ....; donc pas de trous juste une chronologie modifiée.

15:41:12.292998, TM_LFR_SCIENCE_NORMAL_ASM_F1, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: PRIVATE_SCIENCE_OR_TELECOMMAND = 12, (PACKET_ID=0xccc), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=4646, (PACKET_SEQUENCE_CONTROL=0xd226), PACKET_LENGTH=2621, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: SCIENCE_DATA_TRANSFER = 21, SERVICE_SUBTYPE: SCIENCE_REPORT = 3, DESTINATION_ID: GROUND = 0, TIME=0x8000059b67cb, PA_LFR_SID_PKT: SC_N_ASM_F1 = 12, PA_BIA_MODE_MUX_SET: SET_0 = 0, PA_BIA_MODE_HV_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS1_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS2_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS3_ENABLED: DISABLED = 0, PA_BIA_ON_OFF: OFF = 0, PA_LFR_PKT_CNT_ASM=2, PA_LFR_PKT_NR_ASM=1, PA_LFR_ACQUISITION_TIME=0x8000059b67cb, PA_LFR_ASM_F1_BLK_NR=52

15:41:12.297887, TM_LFR_SCIENCE_NORMAL_SWF_F0, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: PRIVATE_SCIENCE_OR_TELECOMMAND = 12, (PACKET_ID=0xccc), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=4648, (PACKET_SEQUENCE_CONTROL=0xd228), PACKET_LENGTH=3669, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: SCIENCE_DATA_TRANSFER = 21, SERVICE_SUBTYPE: SCIENCE_REPORT = 3, DESTINATION_ID: GROUND = 0, TIME=0x800005937f4c, PA_LFR_SID_PKT: SC_N_SWF_F0 = 3, PA_BIA_MODE_MUX_SET: SET_0 = 0, PA_BIA_MODE_HV_ENABLED: ENABLED = 1, PA_BIA_MODE_BIAS1_ENABLED: ENABLED = 1, PA_BIA_MODE_BIAS2_ENABLED: ENABLED = 1, PA_BIA_MODE_BIAS3_ENABLED: ENABLED = 1, PA_BIA_ON_OFF: OFF = 0, PA_LFR_PKT_CNT=7, PA_LFR_PKT_NR=4, PA_LFR_ACQUISITION_TIME=0x800005937f4c, PA_LFR_SWF_BLK_NR=304

15:41:12.301316, TM_LFR_SCIENCE_NORMAL_ASM_F1, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: PRIVATE_SCIENCE_OR_TELECOMMAND = 12, (PACKET_ID=0xccc), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=4647, (PACKET_SEQUENCE_CONTROL=0xd227), PACKET_LENGTH=2621, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: SCIENCE_DATA_TRANSFER = 21, SERVICE_SUBTYPE: SCIENCE_REPORT = 3, DESTINATION_ID: GROUND = 0, TIME=0x8000059b68dc, PA_LFR_SID_PKT: SC_N_ASM_F1 = 12, PA_BIA_MODE_MUX_SET: SET_0 = 0, PA_BIA_MODE_HV_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS1_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS2_ENABLED: DISABLED = 0, PA_BIA_MODE_BIAS3_ENABLED: DISABLED = 0, PA_BIA_ON_OFF: OFF = 0, PA_LFR_PKT_CNT_ASM=2, PA_LFR_PKT_NR_ASM=2, PA_LFR_ACQUISITION_TIME=0x8000059b68dc, PA_LFR_ASM_F1_BLK_NR=52

On voit bien que les 2 TM ASM sont bien retrouvées (4646 et 4647) avec un bloc SWF enchevetré mais cohérent avec la sequence des SWF
15:41:11.999557, TM_LFR_SCIENCE_NORMAL_SWF_F0, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: PRIVATE_SCIENCE_OR_TELECOMMAND = 12, (PACKET_ID=0xccc), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=4641, (PACKET_SEQUENCE_CONTROL=0xd221), PACKET_LENGTH=3669, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: SCIENCE_DATA_TRANSFER = 21, SERVICE_SUBTYPE: SCIENCE_REPORT = 3, DESTINATION_ID: GROUND = 0, TIME=0x800005937c21, PA_LFR_SID_PKT: SC_N_SWF_F0 = 3, PA_BIA_MODE_MUX_SET: SET_0 = 0, PA_BIA_MODE_HV_ENABLED: ENABLED = 1, PA_BIA_MODE_BIAS1_ENABLED: ENABLED = 1, PA_BIA_MODE_BIAS2_ENABLED: ENABLED = 1, PA_BIA_MODE_BIAS3_ENABLED: ENABLED = 1, PA_BIA_ON_OFF: OFF = 0, PA_LFR_PKT_CNT=7, PA_LFR_PKT_NR=3, PA_LFR_ACQUISITION_TIME=0x800005937c21, PA_LFR_SWF_BLK_NR=304
et
15:41:12.59045, TM_LFR_SCIENCE_NORMAL_SWF_F0, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: PRIVATE_SCIENCE_OR_TELECOMMAND = 12, (PACKET_ID=0xccc), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=4652, (PACKET_SEQUENCE_CONTROL=0xd22c), PACKET_LENGTH=3669, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: SCIENCE_DATA_TRANSFER = 21, SERVICE_SUBTYPE: SCIENCE_REPORT = 3, DESTINATION_ID: GROUND = 0, TIME=0x800005938276, PA_LFR_SID_PKT: SC_N_SWF_F0 = 3, PA_BIA_MODE_MUX_SET: SET_0 = 0, PA_BIA_MODE_HV_ENABLED: ENABLED = 1, PA_BIA_MODE_BIAS1_ENABLED: ENABLED = 1, PA_BIA_MODE_BIAS2_ENABLED: ENABLED = 1, PA_BIA_MODE_BIAS3_ENABLED: ENABLED = 1, PA_BIA_ON_OFF: OFF = 0, PA_LFR_PKT_CNT=7, PA_LFR_PKT_NR=5, PA_LFR_ACQUISITION_TIME=0x800005938276, PA_LFR_SWF_BLK_NR=304

Je ne pense pas que c'est une erreur.

Paul dis-nous ce que tu en penses pour ces 2 cas.

Peut-etre relancer le test pour voir si reproductible.

-------------------------------------------------------------------------
Contexte
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
Brique Star-Dundee S/N 46120065
Soft:1.0.0.9b (variante sur carte finale)

TEST CASE = SVS-0019

RPW-SYS-IDB-00067-LES_Issue2_Rev2
RPW-SYS-MEB-LFR-ICD-00097 Issue3_Rev0
RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev2

History

#1 Updated by paul leroy over 7 years ago

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

1-
Si le packet avec sequence_cnt = 18 n'est pas dans les traces, un peu avant ou un peu après (cf point 2 pour l'explication), la brique a perdu un packet ou LFR n'a pas émis le packet. Cette deuxième possibilité n'ayant jamais été constatée, je penche pour une arrivée du packet 18 avant les BP

2-
La différence au niveau temporalité s'explique par la priorité des tâches temps réel affectées aux différents produits scientifiques. Les tâches waveform sont prioritaires sur les tâches de calcul des basic parameters, le sequence_cnt reflète le moment où sequence_cnt a été affecté au packet, pas la transmission du packet. Je peux essayer de changer le fonctionnement si c'est perturbant pour les analyses, par exemple en jouant sur les possibilités de préemption des tâches

#2 Updated by Veronique bouzid over 7 years ago

  • Status changed from Feedback to Closed

Test rejoué sur 1.0.0.10
Le fichier 2014_06_17-11_32_21-Detail.txt contient le test SVS-0019

1- Cette fois pas de perte de packets.
En fait c'etait le TM_LFR_SCIENCE_NORMAL_BP2_F1 qui n'avait pas été perdu (associé au SEQUENCE_CNT=18).

Sur le test total, on n a aucune perte de paquet TM_LFR_SCIENCE
11:02:09.296766, TM_LFR_SCIENCE_NORMAL_BP1_F0, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=16
11:02:09.299828, TM_LFR_SCIENCE_NORMAL_BP2_F0, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=17
11:02:09.889498, TM_LFR_SCIENCE_NORMAL_BP1_F1, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=18
11:02:09.89243, TM_LFR_SCIENCE_NORMAL_BP2_F1, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=19
11:02:13.307623, TM_LFR_SCIENCE_NORMAL_BP1_F0, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=20

Also available in: Atom PDF