Bug #117
closed
Gestion de SEQUENCE_CNT dans les TM_LFR_*
Added by Gerald Saule over 10 years ago. Updated over 10 years ago.
Description
Le champ SEQUENCE_CNT des TM correspond au nombre de TM pour chaque couple (PACKET_ID,DESTINATION_ID).
Il y a un pb d'homogénéïté lors de l'implémentation de cette affectation:
-Pour PACKET_ID=0xcfc et DESTINATION_ID: GROUND = 0 (TM_LFR_SCIENCE_SBM1_CWF_F1), la premier paquet est en SEQUENCE_CNT=0.
-Pour les autres couples, le premier paquet est en SEQUENCE_CNT=1.
Les SEQUENCE_CNT doivent commencer à 0 dès la première TM (cf. mail Philippe Plasson 4/06/2014)
D'autre part, il y a aussi un pb sur le pivot pour TM_LFR_SCIENCE_SBM1_CWF_F1 (PACKET_ID=0xcfc, DESTINATION_ID: GROUND = 0): après SEQUENCE_CNT=255, on repasse malheureusement à SEQUENCE_CNT=0.
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.9
Brique Star-Dundee S/N <illisible>.
Soft:1.0.0.5 (variante sur carte finale)
TEST CASE = SVS-0019
Req = SSS-CP-FS-590
RPW-SYS-IDB-00067-LES_Issue2_Rev2
RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev2
RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev2
Files
| 2014_06_17-11_32_21-Detail.txt (23.6 MB) 2014_06_17-11_32_21-Detail.txt | Veronique bouzid, 17/06/2014 12:53 PM |
Updated by paul leroy over 10 years ago
- Status changed from New to Resolved
- Assignee changed from paul leroy to bruno katra
fsw >= 1.0.0.6
Le compteur de TM_LFR_SCIENCE_SBM1_CWF_F1 commence maintenant à 1.
Le passage de 255 à 256 se fait correctement. Je pense qu'à ce niveau, le bug était côté analyse et pas côté flight software. Il faut vérifier l'analyse du champ sequence_cnt.
Pendant les tests, il apparaît que des paquets TM sont perdus par la brique Star Dundee. La vérification effectuée avec la brique GRESB montre que la brique Star Dundee est en cause. Le problème vient soit de la brique soit de son utilisation par le RMAPPlugin. Je crée une nouvelle issue (#149) pour cet aspect qu'il faudra élucider.
Updated by Veronique bouzid over 10 years ago
- Status changed from Resolved to Feedback
- Assignee changed from bruno katra to paul leroy
Le test SVS-0019 a été rejoué.
La gestion des SEQUENCE_CNT est correcte excepté pour la famille des BP où SEQUENCE_CNT=0
TM_LFR_SCIENCE_NORMAL_BP1_F0 TM_LFR_SCIENCE_NORMAL_BP1_F1 TM_LFR_SCIENCE_NORMAL_BP1_F2
TM_LFR_SCIENCE_NORMAL_BP2_F0 TM_LFR_SCIENCE_NORMAL_BP2_F1 TM_LFR_SCIENCE_NORMAL_BP2_F2
TM_LFR_SCIENCE_BURST_BP1_F0 TM_LFR_SCIENCE_BURST_BP1_F1
TM_LFR_SCIENCE_BURST_BP2_F0 TM_LFR_SCIENCE_BURST_BP2_F1
TM_LFR_SCIENCE_SBM1_BP1_F0 TM_LFR_SCIENCE_SBM1_BP1_F1
TM_LFR_SCIENCE_SBM1_BP2_F0 TM_LFR_SCIENCE_SBM1_BP2_F1
TM_LFR_SCIENCE_SBM2_BP1_F0 TM_LFR_SCIENCE_SBM2_BP1_F1
TM_LFR_SCIENCE_SBM2_BP2_F0 TM_LFR_SCIENCE_SBM2_BP2_F1
Ici un exemple extrait du fichier 2014_05_07-16_31_43-Detail.txt après post-traitement
16:06:25.852599, TM_LFR_SCIENCE_NORMAL_SWF_F0, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=19
16:06:26.153318, TM_LFR_SCIENCE_NORMAL_SWF_F1, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=20
16:06:26.453487, TM_LFR_SCIENCE_NORMAL_SWF_F1, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=21
16:06:26.55209, TM_LFR_SCIENCE_NORMAL_BP1_F0, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=0
16:06:26.56484, TM_LFR_SCIENCE_NORMAL_BP1_F1, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=0
16:06:26.596044, TM_LFR_SCIENCE_NORMAL_BP1_F2, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=0
16:06:26.770523, TM_LFR_SCIENCE_NORMAL_SWF_F1, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=22
16:06:27.063365, TM_LFR_SCIENCE_NORMAL_SWF_F1, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=23
Au sujet des HK, on a observé la perte de 2 paquets HK sur 1968 paquets générés par le test.
J'ai ecrit un script pour extraire les SEQUENCE_CNT et ensuite un prog en idl qui identifie les trous.
Paul propose de rejouer ce test sur la brique GRESB. Voir pt 149.
J'ai joué le test SVS-0090 qui génére 7494 paquets et aucune perte n'est observée.
Updated by paul leroy over 10 years ago
- Status changed from Feedback to Resolved
- Assignee changed from paul leroy to bruno katra
fsw >= 1.0.0.7
bug identifié et corrigé
Les paquets ASM et BP ont maintenant leur paramètre sequence_cnt correctement incrémenté.
Updated by bruno katra over 10 years ago
Demande de précisions à P.Plasson par mail le 4/06 :
Bonjour Philippe, juste un petit éclaircissement sur le requirement SSS-CP-FS-590.
SSS-CP-FS-590 :
The RPW Flight Software shall maintain, for each couple of APID and Destination ID, a TM
sequence counter incremented by 1 when a packet is released.
- The sequence counters shall wrap around from 2^14-1 to zero.
- The sequence counter shall start at zero at startup.
Nous avons un petit dilemme d'interprétation :
"The sequence counter shall start at zero at startup"
et
"sequence counter incremented by 1 when a packet is released"
voudrait dire que le compteur est initialisé à 0 mais incrémenté de 1 lorsque la TM est délivrée i.e. le premier paquet TM d'un couple APID/Dest.ID après lancement initial du soft de vol aura un SEQUENCE_CNT = 1.
Par contre, une fois le compteur arrivé au bout (2^14-1) on reviendra bien à 0 i.e. le 16384ème paquet TM d'un couple APID/Dest.ID après lancement initial du soft de vol aura un SEQUENCE_CNT = 0.
Notre interprétation est-elle correcte?
Merci d'avance de ta réponse.
Bruno
REPONSE P.PLASSON :
Bonjour Bruno,
Le premier paquet TM d'un couple APID/Dest.ID après lancement initial
du soft de vol doit avoir un SEQUENCE_CNT = 0.
Cordialement,
Philippe
Updated by bruno katra over 10 years ago
- Assignee changed from bruno katra to paul leroy
REPONSE P.PLASSON CONCERNANT LE SEQUENCE_CNT:
Bonjour Bruno,
Le premier paquet TM d'un couple APID/Dest.ID après lancement initial
du soft de vol doit avoir un SEQUENCE_CNT = 0.
Cordialement,
Philippe
Or actuellement tous couples APID/Dest.ID suivants ont SEQUENCE_CNT=1 la première fois :
Packet Name APID DESTINATION ID
TM_LFR_TC* 0x0cc1
[0,110,111,112,113,120,121,122,15,14,11,254]
TM_LFR_HK 0x0cc4 0 (GROUND)
TM_LFR_PARAMETER_DUMP 0x0cc9 0
TM_LFR_SCIENCE_L1 0x0ccc 0
TM_LFR_SCIENCE_L2 0x0cfc 0 (Mode SBMx)
------------------------------------
Contexte:
LPPMON: Version=0.2.2 Branch=default Changeset=835955994d5f
Carte mini-LFR: LFR-172200 dev V1.0; No série 5
Vhdl: mini-lfr_0.1.9
Brique Star-Dundee S/N 46120065
Soft:1.0.0.7 (variante sur carte finale)
TEST CASE = SVS-0019
Req = SSS-CP-FS-590
RPW-SYS-IDB-00067-LES_Issue2_Rev2
RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev2
RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev2
Updated by bruno katra over 10 years ago
- Priority changed from Normal to Immediate
Updated by bruno katra over 10 years ago
- Status changed from Resolved to Feedback
Updated by paul leroy over 10 years ago
- Status changed from Feedback to Resolved
- Assignee changed from paul leroy to bruno katra
fsw >= 1.0.0.9
modification du traitement des SEQUENCE_CNT pour que la valeur du paramètre dans le premier paquet émis soit égale à 0.
Updated by Veronique bouzid over 10 years ago
- Status changed from Resolved to Feedback
- Assignee changed from bruno katra to paul leroy
Test rejoué en 1.0.0.9:Ttj pas conforme
Pour les HK ,
1- le SEQUENCE_CNT des HK commence bien à 0 mais c'est la dummy-hk
2- Le SEQUENCE_CNT ne s'incremente plus
15:01:10.91966 TM_LFR_HK (PACKET_ID=0xcc4) SEQUENCE_CNT=0 DESTINATION_ID: GROUND = 0
15:01:12.829795 TM_LFR_HK (PACKET_ID=0xcc4) SEQUENCE_CNT=0 DESTINATION_ID: GROUND = 0
15:01:13.830461 TM_LFR_HK (PACKET_ID=0xcc4) SEQUENCE_CNT=0 DESTINATION_ID: GROUND = 0
15:01:14.836327 TM_LFR_HK (PACKET_ID=0xcc4) SEQUENCE_CNT=0 DESTINATION_ID: GROUND = 0
15:01:15.829693 TM_LFR_HK (PACKET_ID=0xcc4) SEQUENCE_CNT=0 DESTINATION_ID: GROUND = 0
Pour les TM_LFR_EXE_SUCCESS (INCONSISTENT, NOT_EXECUTABLE,NOT_IMPLEMENTED) (PACKET_ID=0xcc1)
1- le SEQUENCE_CNT commence bien à 0
2- Le SEQUENCE_CNT s'incremente bien de 1 correctement
15:01:11.40512, TM_LFR_TC_EXE_SUCCESS, PACKET_ID=0xcc1, DESTINATION_ID: TC_SEQUENCES = 111, SEQUENCE_CNT=0
15:01:11.605252, TM_LFR_TC_EXE_SUCCESS, PACKET_ID=0xcc1, DESTINATION_ID: TC_SEQUENCES = 111, SEQUENCE_CNT=1
15:01:11.805927, TM_LFR_TC_EXE_SUCCESS, PACKET_ID=0xcc1, DESTINATION_ID: RECOVERY_ACTION_CMD = 112, SEQUENCE_CNT=0
15:01:12.00831, TM_LFR_TC_EXE_SUCCESS, PACKET_ID=0xcc1, DESTINATION_ID: RECOVERY_ACTION_CMD = 112, SEQUENCE_CNT=1
15:01:12.209312, TM_LFR_TC_EXE_SUCCESS, PACKET_ID=0xcc1, DESTINATION_ID: RECOVERY_ACTION_CMD = 112, SEQUENCE_CNT=2
15:01:12.410186, TM_LFR_TC_EXE_SUCCESS, PACKET_ID=0xcc1, DESTINATION_ID: BACKUP_MISSION_TIMELINE = 113, SEQUENCE_CNT=0
15:01:12.610766, TM_LFR_TC_EXE_SUCCESS, PACKET_ID=0xcc1, DESTINATION_ID: BACKUP_MISSION_TIMELINE = 113, SEQUENCE_CNT=1
15:01:12.811838, TM_LFR_TC_EXE_SUCCESS, PACKET_ID=0xcc1, DESTINATION_ID: BACKUP_MISSION_TIMELINE = 113, SEQUENCE_CNT=2
il faut que je verifie pour les autres type EXE (INCONSISTENT, NOT_EXECUTABLE,NOT_IMPLEMENTED) ++
Pour les TM_LFR_PARAMETER_DUMP (PACKET_ID=0xcc9)
1- la sequence commence à ZERO
2- Le SEQUENCE_CNT ne s'incremente plus (AVANT c 'etait bon)
15:03:10.670414, TM_LFR_PARAMETER_DUMP, PACKET_ID=0xcc9, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=0
15:03:10.870168, TM_LFR_PARAMETER_DUMP, PACKET_ID=0xcc9, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=0
15:03:11.08649, TM_LFR_PARAMETER_DUMP, PACKET_ID=0xcc9, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=0
Pour les SCIENCE DATA
1- la sequence ne commence pas a ZERO
2- les sequences par packet id ne sont pas corrects, ici on voit que les TM_LFR_SCIENCE_BURST_BP1_F0 (PACKET_ID=0xccc) sont comptabilisés avec les paquets PACKET_ID=0xcfc
15:02:18.473355, TM_LFR_SCIENCE_SBM1_BP1_F0, PACKET_ID=0xcfc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=1
15:02:18.748081, TM_LFR_SCIENCE_SBM1_BP1_F0, PACKET_ID=0xcfc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=2
15:02:22.88329, TM_LFR_SCIENCE_BURST_BP1_F0, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=3
15:02:22.895342, TM_LFR_SCIENCE_BURST_BP1_F1, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=4
15:02:23.49797, TM_LFR_SCIENCE_SBM1_BP1_F0, PACKET_ID=0xcfc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=5
15:02:23.774002, TM_LFR_SCIENCE_SBM1_BP1_F0, PACKET_ID=0xcfc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=6
15:02:23.904348, TM_LFR_SCIENCE_SBM1_CWF_F1, PACKET_ID=0xcfc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=7
15:02:23.915794, TM_LFR_SCIENCE_SBM1_CWF_F1, PACKET_ID=0xcfc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=8
15:02:23.919362, TM_LFR_SCIENCE_SBM1_CWF_F1, PACKET_ID=0xcfc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=9
15:02:23.922545, TM_LFR_SCIENCE_SBM1_CWF_F1, PACKET_ID=0xcfc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=10
avec PACKET_ID=0xccc
15:02:32.708797, TM_LFR_SCIENCE_NORMAL_BP1_F0, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=1
15:02:32.721777, TM_LFR_SCIENCE_NORMAL_BP1_F1, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=2
15:02:32.75589, TM_LFR_SCIENCE_NORMAL_BP1_F2, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=3
15:02:36.714636, TM_LFR_SCIENCE_NORMAL_BP1_F0, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=4
15:02:36.721473, TM_LFR_SCIENCE_NORMAL_BP1_F1, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=5
15:02:36.755311, TM_LFR_SCIENCE_NORMAL_BP1_F2, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=6
15:02:40.71389, TM_LFR_SCIENCE_NORMAL_BP1_F0, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=7
15:02:40.716315, TM_LFR_SCIENCE_NORMAL_BP1_F1, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=8
15:02:40.755412, TM_LFR_SCIENCE_NORMAL_BP1_F2, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=9
15:02:44.70514, TM_LFR_SCIENCE_NORMAL_BP1_F0, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=10
Voici le tableau qu il faut respecter
On doit avoir le compteur de sequence qui s incremente pour PACKET_ID=0xcfc
TM_LFR_SCIENCE_SBM1_CWF_F1
TM_LFR_SCIENCE_SBM2_CWF_F2
TM_LFR_SCIENCE_SBM1_BP1_F0
TM_LFR_SCIENCE_SBM1_BP2_F0
TM_LFR_SCIENCE_SBM2_BP1_F0
TM_LFR_SCIENCE_SBM2_BP2_F0
TM_LFR_SCIENCE_SBM2_BP1_F1
TM_LFR_SCIENCE_SBM2_BP2_F1
On doit avoir le compteur de sequence qui s incremente pour PACKET_ID=0xccc
TM_LFR_SCIENCE_NORMAL_*
TM_LFR_SCIENCE_BURST_CWF_F2
TM_LFR_SCIENCE_BURST_BP1_F0
TM_LFR_SCIENCE_BURST_BP1_F1
TM_LFR_SCIENCE_BURST_BP2_F0
TM_LFR_SCIENCE_BURST_BP2_F1
Updated by Veronique bouzid over 10 years ago
Suite à l installation d'une version temporaire
Voici les problemes rencontrés:
TM_LFR_HK
1- Le champ SEGMENTATION_GROUPING_FLAG:CONTINUATION_PACKET = 0 ce n est pas bon, il faut SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3
10:19:06.010561, 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: /!\CONTINUATION_PACKET = 0, SEQUENCE_CNT=255,
2- Le SEQUENCE_CNT repasse à 0 une fois 255 atteint
10:19:06.010561, 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: /!\CONTINUATION_PACKET = 0, SEQUENCE_CNT=255,
10:19:07.010703, 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: /!\CONTINUATION_PACKET = 0, SEQUENCE_CNT=0,
Par contre, le SEQUENCE_CNT commence bien à 0 et il s'incremente de 1.
10:14:50.994548, 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: /!\CONTINUATION_PACKET = 0, SEQUENCE_CNT=0,
Pour packet PACKET_ID=0xccc
1- le SEQUENCE_CNT ne commence pas à 1
0:16:01.084524, TM_LFR_SCIENCE_BURST_BP1_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=1, (PACKET_SEQUENCE_CONTROL=0xc001), PACKET_LENGTH=217, 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=0x8000004838c5, PA_LFR_SID_PKT: SC_B_BP1_F0 = 17, 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=0x8000004838c5, PA_LFR_B_BP1_BLK_NR_F0=22
Je n ai pas de produits ASM ni de CWF_LONG_F3.
L'absence de produits ASM vient de mon mauvais parametrage,
10:17:55.429341, TC_LFR_LOAD_NORMAL_PAR, 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=9451, (PACKET_SEQUENCE_CONTROL=0xe4eb), PACKET_LENGTH=15, 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: LOAD_NORMAL_PARAMETERS_1 = 13, SOURCE_ID: MISSION_TIMELINE = 110, SY_LFR_N_SWF_L = 2048, SY_LFR_N_SWP_P = 16(s), SY_LFR_N_ASM_P = 4(s), SY_LFR_N_BP_P0 = 1(s), SY_LFR_N_BP_P1 = 1(s), SPARE=0x0, SY_LFR_N_CWF_LONG_F3 = 0, SPARE=0x0, CRC = 0xbc31
j ai obtenu
10:17:55.444943, TM_LFR_TC_EXE_INCONSISTENT, 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=11, (PACKET_SEQUENCE_CONTROL=0xc00b), PACKET_LENGTH=19, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: TELECOMMAND_VERIFICATION = 1, SERVICE_SUBTYPE: TC_EXECUTION_COMPLETION_FAILURE = 8, DESTINATION_ID: MISSION_TIMELINE = 110, TIME=0x800000ba9ede, PA_RPW_TC_FAILURE_CODE: WRONG_APP_DATA = 5, PA_RPW_TELECOMMAND_PKT_ID=0x1ccc, PA_RPW_PKT_SEQ_CONTROL=0xe4eb, PA_RPW_TC_SERVICE=181, PA_RPW_TC_SUBTYPE=13, PA_RPW_BYTE_POSITION=16, PA_RPW_RCV_VALUE=1
EN fait, PA_RPW_BYTE_POSITION=16 correspond à SY_LFR_N_BP_P0.
J ouvre un point redmine pour moi.
Il faut egalement modifier le script pour obtenir des produits CWF_LONG_F3 ou bien utiliser le script SVS-0090 pour valider le sequence_cnt
Pour packet PACKET_ID=0xcfc
1- le SEQUENCE_CNT ne commence pas à 1
10:15:56.673802, TM_LFR_SCIENCE_SBM1_BP1_F0, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_5 = 79, PACKET_CATEGORY: PRIVATE_SCIENCE_OR_TELECOMMAND = 12, (PACKET_ID=0xcfc), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=1,
La bonne nouvelle, les TM_SCIENCE semblent etre correctement affectées dans les bonnes séquences.
J'ai pu observé le passage SEQUENCE_CNT=16383 vers SEQUENCE_CNT=0
10:39:25.097842, TM_LFR_SCIENCE_SBM1_BP1_F0, PACKET_ID=0xcfc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=16382
10:39:25.379425, TM_LFR_SCIENCE_SBM1_BP1_F0, PACKET_ID=0xcfc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=16383
10:39:25.381991, TM_LFR_SCIENCE_SBM1_BP2_F0, PACKET_ID=0xcfc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=0
10:39:25.628368, TM_LFR_SCIENCE_SBM1_CWF_F1, PACKET_ID=0xcfc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=1
Updated by paul leroy over 10 years ago
- Assignee changed from paul leroy to Veronique bouzid
Pour les TM_LFR_HK, avec fsw = 1.0.0.10, je ne reproduis pas le problème en regardant les enregistrements que j'ai au format CSV. Ca s'incrémente correctement après 255, l'octet de poids fort est incrémenté de 1 et l'octet de poids faible repasse à 0. Il n'y a pas un problème dans ton analyse?
Updated by Veronique bouzid over 10 years ago
Au sujet du passage SEQUENCE_CNT=255 vers 0 sur TM_LFR_HK (2014_06_16-11_18_37-Detail.txt)
2- Le SEQUENCE_CNT repasse à 0 une fois 255 atteint
10:19:06.010561, 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: /!\CONTINUATION_PACKET = 0, SEQUENCE_CNT=255,
10:19:07.010703, 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: /!\CONTINUATION_PACKET = 0, SEQUENCE_CNT=0,
Je regarde le contenu du fichier 2014_06_16-11_18_37-Tm.csv pour vérifier si le pb ne vient pas du décodage des octest contenant le SEQUENCE_CNT.
Voici les 2 buffers TM correspond aux traces ci-dessus
Les octets 3,25 indiquent bien que cela correspond au TM_LFR_HK, idem pour 117 = lg du packet de TM_LFR_HK (117 +1 +6 =124)
10:19:06.010561, 1, 2, 0, 0, 12, 196, 0, 255, 0, 117, 16, 3, 25, 0, 128, 0, 1, 1, 47, 171, 1, 29, 0, 1, 0, 0, 10, 0, 1, 16, 44, 59, 0, 0, 0, 0, 0, 1, 199, 1, 237, 28, 204, 0, 181, 0, 41, 128, 0, 0, 186, 211, 86, 28, 204, 0, 181, 0, 13, 128, 0, 0, 186, 158, 222, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 158, 7, 108, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 227, 173, 227, 148, 227, 181, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
les octets 0,255 montrent que
- le SEGMENTATION_GROUPING_FLAG = 0 ( faux mais pb identifié et corrigé) (b0 b1)
- le SEQUENCE_CNT=255 (b2 à b15)
Le pbloc suivant de HK
10:19:07.010703, 1, 2, 0, 0, 12, 196, 0, 0, 0, 117, 16, 3, 25, 0, 128, 0, 1, 2, 47, 169, 1, 29, 0, 1, 0, 0, 10, 0, 1, 16, 45, 59, 0, 0, 0, 0, 0, 1, 199, 1, 237, 28, 204, 0, 181, 0, 41, 128, 0, 0, 186, 211, 86, 28, 204, 0, 181, 0, 13, 128, 0, 0, 186, 158, 222, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 158, 7, 112, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 227, 175, 227, 143, 227, 178, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
les octets 0,0 montrent que
- le SEGMENTATION_GROUPING_FLAG = 0 ( faux mais pb identifié et corrigé) (b0 b1)
- le SEQUENCE_CNT=0 (b2 à b15)
Conclusion, le probleme existe bien et n'est pas du au décodage des octets.
Paul ayant corrigé le bug sur SEGMENTATION_GROUPING_FLAG, on pense que cela peut corriger celui du SEQUENCE_CNT.
A valider sur 1.0.0.10
Je ne mets pas le fichier 2014_06_16-11_18_37-Tm.csv en piece jointe car il est trop volumineaux.
Updated by Veronique bouzid over 10 years ago
- File 2014_06_17-11_32_21-Detail.txt 2014_06_17-11_32_21-Detail.txt added
- Assignee changed from Veronique bouzid to paul leroy
Test rejoué sur 1.0.0.10
Le fichier 2014_06_17-11_32_21-Detail.txt contient le test SVS-0019. Tous les TM_LFR_SCIENCE sont présentes.
Voici les bugs qui restent
TM_LFR_HK
1- Le SEQUENCE_CNT commence bien à 0 mais il n 'y a pas de SEQUENCE_CNT=1
11:00:11.541031, TM_LFR_HK, PACKET_ID=0xcc4, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=0 -- Dummy-hk
11:00:13.445752, TM_LFR_HK, PACKET_ID=0xcc4, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=0
11:00:15.435841, TM_LFR_HK, PACKET_ID=0xcc4, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=2
11:00:16.435868, TM_LFR_HK, PACKET_ID=0xcc4, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=3
Pour packet PACKET_ID=0xccc
1- le SEQUENCE_CNT ne commence pas à 0
11:01:23.472966, TM_LFR_SCIENCE_BURST_BP1_F0, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0,* SEQUENCE_CNT=1*
11:01:33.322838, TM_LFR_SCIENCE_NORMAL_BP1_F0, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=2
11:01:37.322988, TM_LFR_SCIENCE_NORMAL_BP1_F1, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=3
Pour packet PACKET_ID=0xcfc
1- le SEQUENCE_CNT ne commence pas à 0
11:01:19.092192, TM_LFR_SCIENCE_SBM1_BP1_F0, PACKET_ID=0xcfc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=1
11:01:19.342517, TM_LFR_SCIENCE_SBM1_BP1_F0, PACKET_ID=0xcfc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=2
11:01:24.112411, TM_LFR_SCIENCE_SBM1_BP1_F0, PACKET_ID=0xcfc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=3
Updated by paul leroy over 10 years ago
- Assignee changed from paul leroy to Veronique bouzid
fsw >= 1.0.0.11
Bug identifié et corrigé. Vérification effectuée sur un mode SBM1 avec enregistrement en CSV. Le premier paquet de type 21 a un sequence_cnt valant 0.
Updated by Veronique bouzid over 10 years ago
- Status changed from Feedback to Closed
Test rejoué en 1.0.0.11
Tout est bon.
TM_LFR_HK
17:03:38.881752, TM_LFR_HK, PACKET_ID=0xcc4, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=0 -DUMMY-HK
17:03:40.797768, TM_LFR_HK, PACKET_ID=0xcc4, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=0
17:03:41.79776, TM_LFR_HK, PACKET_ID=0xcc4, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=1
Pour packet PACKET_ID=0xccc
17:04:50.813182, TM_LFR_SCIENCE_BURST_BP1_F0, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=0
17:04:50.868992, TM_LFR_SCIENCE_BURST_BP1_F1, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=1
Pour packet PACKET_ID=0xcfc
17:04:46.381785, TM_LFR_SCIENCE_SBM1_BP1_F0, PACKET_ID=0xcfc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=0
17:04:46.659375, TM_LFR_SCIENCE_SBM1_BP1_F0, PACKET_ID=0xcfc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=1
-------------------------------------------------------------------------------------------------
Contexte:
LPPMON: Version=0.2.2 Branch=default Changeset=835955994d5f
Carte mini-LFR: LFR-172200 dev V1.0; No série 5
Vhdl: mini-lfr_0.1.23
Brique Star-Dundee S/N 46120065
Soft:1.0.0.11 (variante sur carte finale)
TEST CASE = SVS-0019
Req = SSS-CP-FS-590
RPW-SYS-IDB-00067-LES_Issue2_Rev2
RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev2
RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev2