Bug #172
closed
Perte SEQUENCE_CNT dans APID=0xccc
0%
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
Updated by paul leroy almost 10 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
Updated by Veronique bouzid almost 10 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