https://hephaistos.lpp.polytechnique.fr/redmine/https://hephaistos.lpp.polytechnique.fr/redmine/redmine/favicon.ico?15080976012014-05-02T12:07:02ZRedmineLFR-FSW - Bug #117: Gestion de SEQUENCE_CNT dans les TM_LFR_*https://hephaistos.lpp.polytechnique.fr/redmine/issues/117?journal_id=2412014-05-02T12:07:02Zpaul leroy
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Resolved</i></li><li><strong>Assignee</strong> changed from <i>paul leroy</i> to <i>bruno katra</i></li></ul><p>fsw >= 1.0.0.6</p>
<p>Le compteur de TM_LFR_SCIENCE_SBM1_CWF_F1 commence maintenant à 1.</p>
<p>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.</p>
<p>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 (<a class="issue tracker-1 status-5 priority-2 priority-default closed" title="Bug: perte de données par la brique StarDundee (Closed)" href="https://hephaistos.lpp.polytechnique.fr/redmine/issues/149">#149</a>) pour cet aspect qu'il faudra élucider.</p> LFR-FSW - Bug #117: Gestion de SEQUENCE_CNT dans les TM_LFR_*https://hephaistos.lpp.polytechnique.fr/redmine/issues/117?journal_id=2622014-05-13T09:36:31ZVeronique bouzid
<ul><li><strong>Status</strong> changed from <i>Resolved</i> to <i>Feedback</i></li><li><strong>Assignee</strong> changed from <i>bruno katra</i> to <i>paul leroy</i></li></ul><p>Le test SVS-0019 a été rejoué.<br />La gestion des SEQUENCE_CNT est correcte excepté pour la famille des BP où SEQUENCE_CNT=0</p>
<p>TM_LFR_SCIENCE_NORMAL_BP1_F0 TM_LFR_SCIENCE_NORMAL_BP1_F1 TM_LFR_SCIENCE_NORMAL_BP1_F2<br />TM_LFR_SCIENCE_NORMAL_BP2_F0 TM_LFR_SCIENCE_NORMAL_BP2_F1 TM_LFR_SCIENCE_NORMAL_BP2_F2<br />TM_LFR_SCIENCE_BURST_BP1_F0 TM_LFR_SCIENCE_BURST_BP1_F1<br />TM_LFR_SCIENCE_BURST_BP2_F0 TM_LFR_SCIENCE_BURST_BP2_F1<br />TM_LFR_SCIENCE_SBM1_BP1_F0 TM_LFR_SCIENCE_SBM1_BP1_F1<br />TM_LFR_SCIENCE_SBM1_BP2_F0 TM_LFR_SCIENCE_SBM1_BP2_F1<br />TM_LFR_SCIENCE_SBM2_BP1_F0 TM_LFR_SCIENCE_SBM2_BP1_F1<br />TM_LFR_SCIENCE_SBM2_BP2_F0 TM_LFR_SCIENCE_SBM2_BP2_F1</p>
<p>Ici un exemple extrait du fichier 2014_05_07-16_31_43-Detail.txt après post-traitement<br />16:06:25.852599, TM_LFR_SCIENCE_NORMAL_SWF_F0, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=19<br />16:06:26.153318, TM_LFR_SCIENCE_NORMAL_SWF_F1, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=20<br />16:06:26.453487, TM_LFR_SCIENCE_NORMAL_SWF_F1, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=21<br /><strong>16:06:26.55209, TM_LFR_SCIENCE_NORMAL_BP1_F0, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=0<br />16:06:26.56484, TM_LFR_SCIENCE_NORMAL_BP1_F1, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=0<br />16:06:26.596044, TM_LFR_SCIENCE_NORMAL_BP1_F2, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=0</strong><br />16:06:26.770523, TM_LFR_SCIENCE_NORMAL_SWF_F1, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=22<br />16:06:27.063365, TM_LFR_SCIENCE_NORMAL_SWF_F1, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=23</p>
<p>Au sujet des HK, on a observé la perte de 2 paquets HK sur 1968 paquets générés par le test.<br />J'ai ecrit un script pour extraire les SEQUENCE_CNT et ensuite un prog en idl qui identifie les trous.<br />Paul propose de rejouer ce test sur la brique GRESB. Voir pt 149.<br />J'ai joué le test SVS-0090 qui génére 7494 paquets et aucune perte n'est observée.</p> LFR-FSW - Bug #117: Gestion de SEQUENCE_CNT dans les TM_LFR_*https://hephaistos.lpp.polytechnique.fr/redmine/issues/117?journal_id=2712014-05-15T08:54:44Zpaul leroy
<ul><li><strong>Status</strong> changed from <i>Feedback</i> to <i>Resolved</i></li><li><strong>Assignee</strong> changed from <i>paul leroy</i> to <i>bruno katra</i></li></ul><p>fsw >= 1.0.0.7<br />bug identifié et corrigé<br />Les paquets ASM et BP ont maintenant leur paramètre sequence_cnt correctement incrémenté.</p> LFR-FSW - Bug #117: Gestion de SEQUENCE_CNT dans les TM_LFR_*https://hephaistos.lpp.polytechnique.fr/redmine/issues/117?journal_id=3302014-06-04T10:43:45Zbruno katra
<ul></ul><p>Demande de précisions à P.Plasson par mail le 4/06 :</p>
<p>Bonjour Philippe, juste un petit éclaircissement sur le requirement SSS-CP-FS-590.</p>
<p>SSS-CP-FS-590 :<br />The RPW Flight Software shall maintain, for each couple of APID and Destination ID, a TM<br />sequence counter incremented by 1 when a packet is released.<br />- The sequence counters shall wrap around from 2^14-1 to zero.<br />- The sequence counter shall start at zero at startup.</p>
<p>Nous avons un petit dilemme d'interprétation :</p>
<p>"The sequence counter shall start at zero at startup" <br />et<br />"sequence counter incremented by 1 when a packet is released"</p>
<p>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.<br />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.</p>
<p>Notre interprétation est-elle correcte?</p>
<p>Merci d'avance de ta réponse.</p>
<p>Bruno</p>
<p><strong>REPONSE P.PLASSON :</strong></p>
<p>Bonjour Bruno,</p>
<p>Le premier paquet TM d'un couple APID/Dest.ID après lancement initial<br />du soft de vol doit avoir un SEQUENCE_CNT = 0.</p>
<p>Cordialement,</p>
<p>Philippe</p> LFR-FSW - Bug #117: Gestion de SEQUENCE_CNT dans les TM_LFR_*https://hephaistos.lpp.polytechnique.fr/redmine/issues/117?journal_id=3312014-06-04T15:43:14Zbruno katra
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/redmine/journals/331/diff?detail_id=390">diff</a>)</li></ul> LFR-FSW - Bug #117: Gestion de SEQUENCE_CNT dans les TM_LFR_*https://hephaistos.lpp.polytechnique.fr/redmine/issues/117?journal_id=3322014-06-06T12:01:12Zbruno katra
<ul><li><strong>Assignee</strong> changed from <i>bruno katra</i> to <i>paul leroy</i></li></ul><p>REPONSE P.PLASSON CONCERNANT LE SEQUENCE_CNT:</p>
<p>Bonjour Bruno,</p>
<p>Le premier paquet TM d'un couple APID/Dest.ID après lancement initial<br />du soft de vol doit avoir un SEQUENCE_CNT = 0.</p>
<p>Cordialement,</p>
<p>Philippe</p>
<hr />
<p>Or actuellement tous couples APID/Dest.ID suivants ont SEQUENCE_CNT=1 la première fois :</p>
<p>Packet Name APID DESTINATION ID<br />TM_LFR_TC* 0x0cc1 <br />[0,110,111,112,113,120,121,122,15,14,11,254]<br />TM_LFR_HK 0x0cc4 0 (GROUND)<br />TM_LFR_PARAMETER_DUMP 0x0cc9 0</p>
<p>TM_LFR_SCIENCE_L1 0x0ccc 0<br />TM_LFR_SCIENCE_L2 0x0cfc 0 (Mode SBMx)</p>
<p>------------------------------------<br />Contexte:<br />LPPMON: Version=0.2.2 Branch=default Changeset=835955994d5f<br />Carte mini-LFR: LFR-172200 dev V1.0; No série 5<br />Vhdl: mini-lfr_0.1.9<br />Brique Star-Dundee S/N 46120065<br />Soft:1.0.0.7 (variante sur carte finale)</p>
<p>TEST CASE = SVS-0019<br />Req = SSS-CP-FS-590</p>
<p>RPW-SYS-IDB-00067-LES_Issue2_Rev2<br />RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev2<br />RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev2</p> LFR-FSW - Bug #117: Gestion de SEQUENCE_CNT dans les TM_LFR_*https://hephaistos.lpp.polytechnique.fr/redmine/issues/117?journal_id=3352014-06-10T10:31:24Zbruno katra
<ul><li><strong>Priority</strong> changed from <i>Normal</i> to <i>Immediate</i></li></ul> LFR-FSW - Bug #117: Gestion de SEQUENCE_CNT dans les TM_LFR_*https://hephaistos.lpp.polytechnique.fr/redmine/issues/117?journal_id=3442014-06-11T12:09:36Zbruno katra
<ul><li><strong>Status</strong> changed from <i>Resolved</i> to <i>Feedback</i></li></ul> LFR-FSW - Bug #117: Gestion de SEQUENCE_CNT dans les TM_LFR_*https://hephaistos.lpp.polytechnique.fr/redmine/issues/117?journal_id=3512014-06-12T06:09:37Zpaul leroy
<ul><li><strong>Status</strong> changed from <i>Feedback</i> to <i>Resolved</i></li><li><strong>Assignee</strong> changed from <i>paul leroy</i> to <i>bruno katra</i></li></ul><p>fsw >= 1.0.0.9<br />modification du traitement des SEQUENCE_CNT pour que la valeur du paramètre dans le premier paquet émis soit égale à 0.</p> LFR-FSW - Bug #117: Gestion de SEQUENCE_CNT dans les TM_LFR_*https://hephaistos.lpp.polytechnique.fr/redmine/issues/117?journal_id=3842014-06-16T06:36:00ZVeronique bouzid
<ul><li><strong>Status</strong> changed from <i>Resolved</i> to <i>Feedback</i></li><li><strong>Assignee</strong> changed from <i>bruno katra</i> to <i>paul leroy</i></li></ul><p>Test rejoué en 1.0.0.9:Ttj pas conforme</p>
<p><strong>Pour les <abbr title="*PACKET_ID=0xcc4">HK</abbr></strong> ,<br />1- le SEQUENCE_CNT des HK commence bien à 0 mais c'est la dummy-hk<br />2- Le SEQUENCE_CNT ne s'incremente plus<br />15:01:10.91966 TM_LFR_HK (PACKET_ID=0xcc4) SEQUENCE_CNT=0 DESTINATION_ID: GROUND = 0<br />15:01:12.829795 TM_LFR_HK (PACKET_ID=0xcc4) SEQUENCE_CNT=0 DESTINATION_ID: GROUND = 0<br />15:01:13.830461 TM_LFR_HK (PACKET_ID=0xcc4) SEQUENCE_CNT=0 DESTINATION_ID: GROUND = 0<br />15:01:14.836327 TM_LFR_HK (PACKET_ID=0xcc4) SEQUENCE_CNT=0 DESTINATION_ID: GROUND = 0<br />15:01:15.829693 TM_LFR_HK (PACKET_ID=0xcc4) SEQUENCE_CNT=0 DESTINATION_ID: GROUND = 0</p>
<p><strong>Pour les TM_LFR_EXE_SUCCESS (INCONSISTENT, NOT_EXECUTABLE,NOT_IMPLEMENTED) (PACKET_ID=0xcc1)</strong><br />1- le SEQUENCE_CNT commence bien à 0<br />2- Le SEQUENCE_CNT s'incremente bien de 1 correctement<br />15:01:11.40512, TM_LFR_TC_EXE_SUCCESS, PACKET_ID=0xcc1, DESTINATION_ID: TC_SEQUENCES = 111, SEQUENCE_CNT=0<br />15:01:11.605252, TM_LFR_TC_EXE_SUCCESS, PACKET_ID=0xcc1, DESTINATION_ID: TC_SEQUENCES = 111, SEQUENCE_CNT=1<br />15:01:11.805927, TM_LFR_TC_EXE_SUCCESS, PACKET_ID=0xcc1, DESTINATION_ID: RECOVERY_ACTION_CMD = 112, SEQUENCE_CNT=0<br />15:01:12.00831, TM_LFR_TC_EXE_SUCCESS, PACKET_ID=0xcc1, DESTINATION_ID: RECOVERY_ACTION_CMD = 112, SEQUENCE_CNT=1<br />15:01:12.209312, TM_LFR_TC_EXE_SUCCESS, PACKET_ID=0xcc1, DESTINATION_ID: RECOVERY_ACTION_CMD = 112, SEQUENCE_CNT=2<br />15:01:12.410186, TM_LFR_TC_EXE_SUCCESS, PACKET_ID=0xcc1, DESTINATION_ID: BACKUP_MISSION_TIMELINE = 113, SEQUENCE_CNT=0<br />15:01:12.610766, TM_LFR_TC_EXE_SUCCESS, PACKET_ID=0xcc1, DESTINATION_ID: BACKUP_MISSION_TIMELINE = 113, SEQUENCE_CNT=1<br />15:01:12.811838, TM_LFR_TC_EXE_SUCCESS, PACKET_ID=0xcc1, DESTINATION_ID: BACKUP_MISSION_TIMELINE = 113, SEQUENCE_CNT=2</p>
<p><strong>il faut que je verifie pour les autres type EXE (INCONSISTENT, NOT_EXECUTABLE,NOT_IMPLEMENTED)</strong> ++</p>
<p><strong>Pour les TM_LFR_PARAMETER_DUMP (PACKET_ID=0xcc9)</strong><br />1- la sequence commence à ZERO<br />2- Le SEQUENCE_CNT ne s'incremente plus (AVANT c 'etait bon)<br />15:03:10.670414, TM_LFR_PARAMETER_DUMP, PACKET_ID=0xcc9, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=0<br />15:03:10.870168, TM_LFR_PARAMETER_DUMP, PACKET_ID=0xcc9, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=0<br />15:03:11.08649, TM_LFR_PARAMETER_DUMP, PACKET_ID=0xcc9, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=0</p>
<p><strong>Pour les SCIENCE DATA</strong><br />1- la sequence ne commence pas a ZERO<br />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<br />15:02:18.473355, TM_LFR_SCIENCE_SBM1_BP1_F0, PACKET_ID=0xcfc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=1<br />15:02:18.748081, TM_LFR_SCIENCE_SBM1_BP1_F0, PACKET_ID=0xcfc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=2<br />15:02:22.88329, TM_LFR_SCIENCE_BURST_BP1_F0, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=3<br />15:02:22.895342, TM_LFR_SCIENCE_BURST_BP1_F1, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=4<br />15:02:23.49797, TM_LFR_SCIENCE_SBM1_BP1_F0, PACKET_ID=0xcfc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=5<br />15:02:23.774002, TM_LFR_SCIENCE_SBM1_BP1_F0, PACKET_ID=0xcfc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=6<br />15:02:23.904348, TM_LFR_SCIENCE_SBM1_CWF_F1, PACKET_ID=0xcfc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=7<br />15:02:23.915794, TM_LFR_SCIENCE_SBM1_CWF_F1, PACKET_ID=0xcfc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=8<br />15:02:23.919362, TM_LFR_SCIENCE_SBM1_CWF_F1, PACKET_ID=0xcfc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=9<br />15:02:23.922545, TM_LFR_SCIENCE_SBM1_CWF_F1, PACKET_ID=0xcfc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=10</p>
<p>avec PACKET_ID=0xccc<br />15:02:32.708797, TM_LFR_SCIENCE_NORMAL_BP1_F0, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=1<br />15:02:32.721777, TM_LFR_SCIENCE_NORMAL_BP1_F1, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=2<br />15:02:32.75589, TM_LFR_SCIENCE_NORMAL_BP1_F2, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=3<br />15:02:36.714636, TM_LFR_SCIENCE_NORMAL_BP1_F0, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=4<br />15:02:36.721473, TM_LFR_SCIENCE_NORMAL_BP1_F1, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=5<br />15:02:36.755311, TM_LFR_SCIENCE_NORMAL_BP1_F2, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=6<br />15:02:40.71389, TM_LFR_SCIENCE_NORMAL_BP1_F0, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=7<br />15:02:40.716315, TM_LFR_SCIENCE_NORMAL_BP1_F1, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=8<br />15:02:40.755412, TM_LFR_SCIENCE_NORMAL_BP1_F2, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=9<br />15:02:44.70514, TM_LFR_SCIENCE_NORMAL_BP1_F0, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=10</p>
<p>Voici le tableau qu il faut respecter<br /><strong>On doit avoir le compteur de sequence qui s incremente pour PACKET_ID=0xcfc</strong><br />TM_LFR_SCIENCE_SBM1_CWF_F1<br />TM_LFR_SCIENCE_SBM2_CWF_F2<br />TM_LFR_SCIENCE_SBM1_BP1_F0<br />TM_LFR_SCIENCE_SBM1_BP2_F0<br />TM_LFR_SCIENCE_SBM2_BP1_F0<br />TM_LFR_SCIENCE_SBM2_BP2_F0<br />TM_LFR_SCIENCE_SBM2_BP1_F1<br />TM_LFR_SCIENCE_SBM2_BP2_F1</p>
<p><strong>On doit avoir le compteur de sequence qui s incremente pour PACKET_ID=0xccc</strong><br />TM_LFR_SCIENCE_NORMAL_*<br />TM_LFR_SCIENCE_BURST_CWF_F2<br />TM_LFR_SCIENCE_BURST_BP1_F0<br />TM_LFR_SCIENCE_BURST_BP1_F1<br />TM_LFR_SCIENCE_BURST_BP2_F0<br />TM_LFR_SCIENCE_BURST_BP2_F1</p> LFR-FSW - Bug #117: Gestion de SEQUENCE_CNT dans les TM_LFR_*https://hephaistos.lpp.polytechnique.fr/redmine/issues/117?journal_id=3852014-06-16T10:45:30ZVeronique bouzid
<ul></ul><p>Suite à l installation d'une version temporaire<br />Voici les problemes rencontrés:</p>
<p><strong>TM_LFR_HK</strong><br />1- Le champ SEGMENTATION_GROUPING_FLAG:CONTINUATION_PACKET = 0 ce n est pas bon, il faut SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3<br />10:19:06.010561, <strong>TM_LFR_HK</strong>, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = *1, PROCESS_ID:<br />RPW_PID_2 = 76, PACKET_CATEGORY: HK_ROUTINE = 4, (PACKET_ID=0xcc4),*SEGMENTATION_GROUPING_FLAG: /!\CONTINUATION_PACKET = 0, SEQUENCE_CNT=255,</p>
<p>2- Le SEQUENCE_CNT repasse à 0 une fois 255 atteint<br />10:19:06.010561, <strong>TM_LFR_HK</strong>, 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, <strong>SEQUENCE_CNT=255</strong>,<br />10:19:07.010703, <strong>TM_LFR_HK</strong>, 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, <strong>SEQUENCE_CNT=0</strong>,</p>
<p>Par contre, le SEQUENCE_CNT commence bien à 0 et il s'incremente de 1.<br />10:14:50.994548, <strong>TM_LFR_HK</strong>, 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, <strong>SEQUENCE_CNT=0</strong>,
<strong><br />Pour packet PACKET_ID=0xccc</strong><br />1- le SEQUENCE_CNT ne commence pas à 1<br />0:16:01.084524, <strong>TM_LFR_SCIENCE_BURST_BP1_F0</strong>, 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, <strong>SEQUENCE_CNT=1</strong>, (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<br />Je n ai pas de produits ASM ni de CWF_LONG_F3.</p>
<p>L'absence de produits ASM vient de mon mauvais parametrage,<br />10:17:55.429341, <strong>TC_LFR_LOAD_NORMAL_PAR</strong>, 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, <strong>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</strong>, SPARE=0x0, CRC = 0xbc31</p>
<p>j ai obtenu <br />10:17:55.444943, <strong>TM_LFR_TC_EXE_INCONSISTENT</strong>, 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, <strong>PA_RPW_BYTE_POSITION=16, PA_RPW_RCV_VALUE=1</strong><br />EN fait, PA_RPW_BYTE_POSITION=16 correspond à SY_LFR_N_BP_P0. <br />J ouvre un point redmine pour moi.</p>
<p>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</p>
<p><strong>Pour packet PACKET_ID=0xcfc</strong><br />1- le SEQUENCE_CNT ne commence pas à 1<br />10:15:56.673802, <strong>TM_LFR_SCIENCE_SBM1_BP1_F0</strong>, 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, <strong>SEQUENCE_CNT=1</strong>,</p>
<p>La bonne nouvelle, les TM_SCIENCE semblent etre correctement affectées dans les bonnes séquences.<br />J'ai pu observé le passage SEQUENCE_CNT=16383 vers SEQUENCE_CNT=0 <br />10:39:25.097842, TM_LFR_SCIENCE_SBM1_BP1_F0, <strong>PACKET_ID=0xcfc</strong>, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=16382<br />10:39:25.379425, TM_LFR_SCIENCE_SBM1_BP1_F0, PACKET_ID=0xcfc, DESTINATION_ID: GROUND = 0, <strong>SEQUENCE_CNT=16383</strong><br />10:39:25.381991, TM_LFR_SCIENCE_SBM1_BP2_F0, PACKET_ID=0xcfc, DESTINATION_ID: GROUND = 0, <strong>SEQUENCE_CNT=0</strong><br />10:39:25.628368, TM_LFR_SCIENCE_SBM1_CWF_F1, PACKET_ID=0xcfc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=1</p> LFR-FSW - Bug #117: Gestion de SEQUENCE_CNT dans les TM_LFR_*https://hephaistos.lpp.polytechnique.fr/redmine/issues/117?journal_id=3952014-06-17T06:02:56Zpaul leroy
<ul><li><strong>Assignee</strong> changed from <i>paul leroy</i> to <i>Veronique bouzid</i></li></ul><p>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?</p> LFR-FSW - Bug #117: Gestion de SEQUENCE_CNT dans les TM_LFR_*https://hephaistos.lpp.polytechnique.fr/redmine/issues/117?journal_id=3962014-06-17T07:26:52ZVeronique bouzid
<ul></ul><p>Au sujet du passage SEQUENCE_CNT=255 vers 0 sur TM_LFR_HK (2014_06_16-11_18_37-Detail.txt)</p>
<p>2- Le SEQUENCE_CNT repasse à 0 une fois 255 atteint<br />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,<br />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,</p>
<p>Je regarde le contenu du <ins>fichier 2014_06_16-11_18_37-Tm.csv</ins> pour vérifier si le pb ne vient pas du décodage des octest contenant le SEQUENCE_CNT.<br />Voici les 2 buffers TM correspond aux traces ci-dessus</p>
<p>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)</p>
<p>10:19:06.010561, 1, 2, 0, 0, 12, 196, <strong>0, 255</strong>, 0, 117, 16, <strong>3, 25</strong>, 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</p>
<p>les octets 0,255 montrent que <br />- le SEGMENTATION_GROUPING_FLAG = 0 ( faux mais pb identifié et corrigé) (b0 b1)<br />- le SEQUENCE_CNT=255 (b2 à b15)</p>
<p>Le pbloc suivant de HK<br />10:19:07.010703, 1, 2, 0, 0, 12, 196, <strong>0, 0,</strong> 0, 117, 16, <strong>3, 25</strong>, 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</p>
<p>les octets 0,0 montrent que <br />- le SEGMENTATION_GROUPING_FLAG = 0 ( faux mais pb identifié et corrigé) (b0 b1)<br />- le SEQUENCE_CNT=0 (b2 à b15)</p>
<p>Conclusion, le probleme existe bien et n'est pas du au décodage des octets.<br />Paul ayant corrigé le bug sur SEGMENTATION_GROUPING_FLAG, on pense que cela peut corriger celui du SEQUENCE_CNT.</p>
<p>A valider sur 1.0.0.10</p>
<p>Je ne mets pas le fichier 2014_06_16-11_18_37-Tm.csv en piece jointe car il est trop volumineaux.</p> LFR-FSW - Bug #117: Gestion de SEQUENCE_CNT dans les TM_LFR_*https://hephaistos.lpp.polytechnique.fr/redmine/issues/117?journal_id=4022014-06-17T10:54:59ZVeronique bouzid
<ul><li><strong>File</strong> <a href="/redmine/attachments/341">2014_06_17-11_32_21-Detail.txt</a> <a class="icon-only icon-download" title="Download" href="/redmine/attachments/download/341/2014_06_17-11_32_21-Detail.txt">2014_06_17-11_32_21-Detail.txt</a> added</li><li><strong>Assignee</strong> changed from <i>Veronique bouzid</i> to <i>paul leroy</i></li></ul><p>Test rejoué sur 1.0.0.10<br />Le fichier 2014_06_17-11_32_21-Detail.txt contient le test SVS-0019. Tous les TM_LFR_SCIENCE sont présentes.</p>
<p><ins><strong>Voici les bugs qui restent</strong></ins></p>
<p><strong>TM_LFR_HK</strong><br />1- Le SEQUENCE_CNT commence bien à 0 mais il n 'y a pas de SEQUENCE_CNT=1</p>
<p>11:00:11.541031, TM_LFR_HK, PACKET_ID=0xcc4, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=0 -- Dummy-hk<br />11:00:13.445752, TM_LFR_HK, PACKET_ID=0xcc4, DESTINATION_ID: GROUND = 0, <strong>SEQUENCE_CNT=0</strong><br />11:00:15.435841, TM_LFR_HK, PACKET_ID=0xcc4, DESTINATION_ID: GROUND = 0, <strong>SEQUENCE_CNT=2</strong><br />11:00:16.435868, TM_LFR_HK, PACKET_ID=0xcc4, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=3</p>
<p><strong>Pour packet PACKET_ID=0xccc</strong><br />1- le SEQUENCE_CNT ne commence pas à 0<br />11:01:23.472966, TM_LFR_SCIENCE_BURST_BP1_F0, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0,* SEQUENCE_CNT=1*<br />11:01:33.322838, TM_LFR_SCIENCE_NORMAL_BP1_F0, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=2<br />11:01:37.322988, TM_LFR_SCIENCE_NORMAL_BP1_F1, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=3</p>
<p><strong>Pour packet PACKET_ID=0xcfc</strong><br />1- le SEQUENCE_CNT ne commence pas à 0<br />11:01:19.092192, TM_LFR_SCIENCE_SBM1_BP1_F0, PACKET_ID=0xcfc, DESTINATION_ID: GROUND = 0, <strong>SEQUENCE_CNT=1</strong><br />11:01:19.342517, TM_LFR_SCIENCE_SBM1_BP1_F0, PACKET_ID=0xcfc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=2<br />11:01:24.112411, TM_LFR_SCIENCE_SBM1_BP1_F0, PACKET_ID=0xcfc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=3</p> LFR-FSW - Bug #117: Gestion de SEQUENCE_CNT dans les TM_LFR_*https://hephaistos.lpp.polytechnique.fr/redmine/issues/117?journal_id=4052014-06-17T11:39:03Zpaul leroy
<ul><li><strong>Assignee</strong> changed from <i>paul leroy</i> to <i>Veronique bouzid</i></li></ul><p>fsw >= 1.0.0.11</p>
<p>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.</p> LFR-FSW - Bug #117: Gestion de SEQUENCE_CNT dans les TM_LFR_*https://hephaistos.lpp.polytechnique.fr/redmine/issues/117?journal_id=4112014-06-17T16:32:42ZVeronique bouzid
<ul><li><strong>Status</strong> changed from <i>Feedback</i> to <i>Closed</i></li></ul><p>Test rejoué en 1.0.0.11</p>
<p>Tout est bon.<br />TM_LFR_HK<br />17:03:38.881752, TM_LFR_HK, PACKET_ID=0xcc4, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=0 -DUMMY-HK<br />17:03:40.797768, TM_LFR_HK, PACKET_ID=0xcc4, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=0<br />17:03:41.79776, TM_LFR_HK, PACKET_ID=0xcc4, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=1</p>
<p>Pour packet PACKET_ID=0xccc <br />17:04:50.813182, TM_LFR_SCIENCE_BURST_BP1_F0, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=0<br />17:04:50.868992, TM_LFR_SCIENCE_BURST_BP1_F1, PACKET_ID=0xccc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=1</p>
<p>Pour packet PACKET_ID=0xcfc<br />17:04:46.381785, TM_LFR_SCIENCE_SBM1_BP1_F0, PACKET_ID=0xcfc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=0<br />17:04:46.659375, TM_LFR_SCIENCE_SBM1_BP1_F0, PACKET_ID=0xcfc, DESTINATION_ID: GROUND = 0, SEQUENCE_CNT=1</p>
<p>-------------------------------------------------------------------------------------------------<br />Contexte:<br />LPPMON: Version=0.2.2 Branch=default Changeset=835955994d5f<br />Carte mini-LFR: LFR-172200 dev V1.0; No série 5<br />Vhdl: mini-lfr_0.1.23<br />Brique Star-Dundee S/N 46120065<br />Soft:1.0.0.11 (variante sur carte finale)</p>
<p>TEST CASE = SVS-0019<br />Req = SSS-CP-FS-590</p>
<p>RPW-SYS-IDB-00067-LES_Issue2_Rev2<br />RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev2<br />RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev2</p>