INSTRU: Issueshttps://hephaistos.lpp.polytechnique.fr/redmine/https://hephaistos.lpp.polytechnique.fr/redmine/redmine/favicon.ico?15080976012023-01-30T15:34:47ZRedmine
Redmine LFR-FSW - Bug #4021 (Closed): FSW 3.3.0.14 : Valeurs moyennage potentiel s/c dans HK dupliquées e...https://hephaistos.lpp.polytechnique.fr/redmine/issues/40212023-01-30T15:34:47Zbruno katra
<p>Dans FSW 3.3.0.14 : le moyennage dans les HK de E1 et E2 est identique alors que des signaux différents sont appliqués. En fait peu importe ce que l'on met comme signal sur E1 ses valeurs sont identiques à celle de E2. Si on change le signal sur E2, E1 change aussi pour être =E2.</p>
<p>Dans la capture en PJ (HKmeaning3.3.0.14) on injecte des signaux différents sur E1 et sur E2 et on voit que la réponse est la même dans les HK.</p> LFR-FSW - Bug #4020 (Closed): FSW 3.3.0.13 crashe avec certaines combinaisons de paramètres pour ...https://hephaistos.lpp.polytechnique.fr/redmine/issues/40202023-01-28T17:14:53Zbruno katra
<p>J'ai testé 29 combinaisons de paramètres pour PAS_FILTER plusieurs fois pour essayer de déterminer un critère de reproductibilité.</p>
<p>Les paramètres PAS par défaut sont pour rappel :<br />sy_lfr_pas_filter_modulus = 4<br />sy_lfr_pas_filter_tbad = 1<br />sy_lfr_pas_filter_offset = 0<br />sy_lfr_pas_filter_shift = 0.5</p>
<p><ins>Pour certaines combinaisons :</ins> * le FSW crashe (plus de HK) dès que des ASM doivent être produites pour être envoyées*</p>
<p><ins>Voici les résultats :</ins></p>
<ul>
<li>PARAMETRES PAS PAR DEFAUT : OK, pas de carsh</li>
<li>TOUTES LES COMBINAISONS AVEC sy_lfr_pas_filter_modulus = sy_lfr_pas_filter_tbad = 4 : NOK, crashe systématiquement dès que les ASM doivent être envoyées (testé avec ASM à 4/8/12/16s)</li>
<li>COMBINAISONS AVEC sy_lfr_pas_filter_modulus = 8 et sy_lfr_pas_filter_tbad = 4 : POK, crashe des fois mais pas tout le temps, en fonction des paramètres précédemment entrés j'ai l'impression, reproductibilité aléatoire mais toujours quand les ASM doivent être envoyées (testé avec ASM à 4/8/16s)</li>
<li>TOUTES LES AUTRES COMBINAISONS testées : OK, pas de crash</li>
</ul>
<ul>
<li>Les crashs ne se produisent que si le filtrage est activé (sy_lfr_pas_filter_enabled = 1 ) = si on envoie les combinaisons qui font crasher mais sans activer le filtrage : pas de crash</li>
</ul>
<ul>
<li>Test refait en 3.2.0.24 : pas de crash</li>
</ul> LFR-FSW - Bug #984 (Closed): FFT retirée alors que en dehors du TBAD https://hephaistos.lpp.polytechnique.fr/redmine/issues/9842017-03-16T15:26:31Zbruno katra
<p>Injection du signal suivant synchronisé avec le modulus du filtre PAS (enabled) : <br />première seconde : signal à 16Hz<br />3 secondes suivantes : 100Hz</p>
<p><img src="https://hephaistos.lpp.polytechnique.fr/redmine/attachments/download/2140/signal01.png" alt="" /></p>
<p>Avec les paramètres PAS suivants on obtient le comportement attendu : la première seconde (16hz ) est bien filtrée<br />TBAD = 1.0<br />SHIFT = 0<br />OFFSET = 0<br />MODULUS = 0</p>
<p><img src="https://hephaistos.lpp.polytechnique.fr/redmine/attachments/download/2142/asmf2-01.png" alt="" /></p>
<p>On met ensuite le TBAD = 0.0, on obtient le comportement attendu : on voit bien les 2 pics à 16Hz et 100Hz :</p>
<p><img src="https://hephaistos.lpp.polytechnique.fr/redmine/attachments/download/2143/asmf2-02.png" alt="" /></p>
<p>Par contre après, on met un OFFSET = 1 en laissant le TBAD = 0.0 : le pic de 16 Hz est filtré alors qu'il ne devrait pas :</p>
<p><img src="https://hephaistos.lpp.polytechnique.fr/redmine/attachments/download/2144/asmf2-03.png" alt="" /></p>
<p><strong>NB1</strong> : <br />on peut observer le même comportement avec une conf analogue : OFFSET =0 / SHIFT =1.0 / TBAD = 0.0</p>
<p><strong>NB2</strong> :</p>
<p>Si l'on met un TBAD = 1.0 avec les conf citées on voit bien le pic de 100 Hz qui diminue comme attendu mais le pic de 16Hz reste filtré.</p>
<p>Contexte du test<br />----------------<br />FSW 3.2.0.2<br />VHDL 1.1.91<br />EM1 AVEC Timegen<br />StarDundee<br />Analog discovery</p> LFR-FSW - Bug #182 (Closed): [JIRA] (RPWMEB-283) The content of the PA_LFR_ACQUISITION_TIME ...https://hephaistos.lpp.polytechnique.fr/redmine/issues/1822014-07-09T08:39:49ZVeronique bouzid
<p>Suite à la remontée par Philippe Plasson de l incident RPWMEB-283</p>
<p>J ai ecrit un test pour reproduire le bug.Ce script se nomme <strong>my_timeissue_normal.py</strong>. Il se trouve sous /home/validation.Il est en piece jointe.</p>
<p>J'ai envoyé un <strong>UPDATE_TIME</strong> avec comme temps de réference <strong>CP_RPW_TIME=0x1b45fd970000</strong><br />qui correspond au 1er juillet 2014 vers 23h10 . J ai mis le temps indiqué par Philippe sans vérifier que cela correspondait bien au 1er juillet 2014.<br />Je leur fais confiance.</p>
<p>Je vois bien la mise à l heure de LFR apres reception du time code<br />09:30:22.591245, TM_LFR_HK,TIME=0x8000000346da</p>
<p><strong>09:30:23.591236, TM_LFR_HK,TIME=0x1b45fd976093</strong></p>
<p>la premiere données scientifique qui arrive<br />09:30:23.991365, TM_LFR_SCIENCE_NORMAL_BP1_F0,*TIME=0x1b44fd97a7e4,PA_LFR_ACQUISITION_TIME=0x1b44fd97a7e4*</p>
<p><strong>et la BINGO, on voit 0x1b44 au lieu de 0x1b45</strong>*
*<br />idem pour toutes le TM</p>
<p>09:35:26.392595, TM_LFR_SCIENCE_NORMAL_SWF_F0, TIME=0x9b44febfa146,PA_LFR_ACQUISITION_TIME=0x9b44febfa146<br />09:35:28.59267, TM_LFR_SCIENCE_NORMAL_SWF_F1,TIME=0x9b44febf6c3e,PA_LFR_ACQUISITION_TIME=0x9b44febf6c3e</p>
<p>--------------------------------------------------------------------------------------<br />Contexte:</p>
<p>SocExplorerEngine.getSocExplorer: Version = 0.2.2, Branch = default, Changeset = c839740ef520<br />Carte EM<br />Vhdl: 1.1.23<br />Soft: 2.0.0.0 <br />Brique Star-Dundee S/N 46120065.</p>
<p>script: /home/validation/my_timeissue.py</p>
<p>RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev0<br />RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue3_rev0</p> LFR-FSW - Bug #177 (Closed): EM : Envoi TC_LFR_LOAD_SBMx_PARAM est interdit en mode SBM1 et SBM2 https://hephaistos.lpp.polytechnique.fr/redmine/issues/1772014-06-20T07:43:37ZVeronique bouzid
<p>EN mode SBM1 et SBM2, on ne peut envoyer de TC_LFR_LOAD_SBM1_PARAM et TC_LFR_LOAD_SBM2_PARAM.<br />Gérald a décrit un tableau dans le requirement REQ-LFR-SRS-5207_Ed1 qui récapitule<br />ce que les TC autorisées en fct du mode de LFR et celui du DAS.</p>
<p>--> Il faut donc générer des TM_LFR_TC_EXE_NOT_EXECUTABLE au lieu des TM_LFR_TC_EXE_SUCCESS<br />Voici les traces<br />en SBM1<br />on ne doit pas accepter de changer les parametres du SBM2<br />--> repondre TM_LFR_TC_EXE_NOT_EXECUTABLE et non une TM_LFR_TC_EXE_SUCCESS</p>
<p>14:21:30.394448, TM_LFR_HK, HK_LFR_MODE: SBM1 = 3<br />14:21:30.803258, TC_LFR_LOAD_SBM2_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=9018, (PACKET_SEQUENCE_CONTROL=0xe33a), PACKET_LENGTH=7, CCSDS_SECONDARY_HEADER_FLAG=0, PUS_VERSION = 1, ACK_EXECUTION_COMPLETION=0, ACK_EXECUTION_PROGRESS=0, ACK_EXECUTION_START=0, ACK_ACCEPTANCE=0, SERVICE_TYPE: EQ_CONFIGURATION = 181, SERVICE_SUBTYPE: LOAD_SBM2_PARAMETERS = 27, SOURCE_ID: MISSION_TIMELINE = 110, SY_LFR_S2_BP_P0 = 1, SY_LFR_S2_BP_P1 = 5, CRC = 0x76fa</p>
<p>14:21:30.894486, TM_LFR_TC_EXE_SUCCESS, 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=111, (PACKET_SEQUENCE_CONTROL=0xc06f), PACKET_LENGTH=13, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: TELECOMMAND_VERIFICATION = 1, SERVICE_SUBTYPE: TC_EXECUTION_COMPLETION_SUCCESS = 7, DESTINATION_ID: MISSION_TIMELINE = 110, TIME=0x8000001cbbc3, PA_RPW_TELECOMMAND_PKT_ID=0x1ccc, PA_RPW_PKT_SEQ_CONTROL=0xe33a</p>
<p>on ne doit pas accepter de changer les parametres du SBM1<br />--> repondre TM_LFR_TC_EXE_NOT_EXECUTABLE et non une TM_LFR_TC_EXE_SUCCESS</p>
<p>14:21:33.294332, TM_LFR_HK, HK_LFR_MODE: SBM2 = 4<br />14:21:33.697692, TC_LFR_LOAD_SBM1_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=6413, (PACKET_SEQUENCE_CONTROL=0xd90d), PACKET_LENGTH=7, CCSDS_SECONDARY_HEADER_FLAG=0, PUS_VERSION = 1, ACK_EXECUTION_COMPLETION=0, ACK_EXECUTION_PROGRESS=0, ACK_EXECUTION_START=0, ACK_ACCEPTANCE=0, SERVICE_TYPE: EQ_CONFIGURATION = 181, SERVICE_SUBTYPE: LOAD_SBM1_PARAMETERS = 25, SOURCE_ID: MISSION_TIMELINE = 110, SY_LFR_S1_BP_P0 = 0.25(s), SY_LFR_S1_BP_P1 = 1(s), CRC = 0xa7e5</p>
<p>14:21:33.794294, TM_LFR_TC_EXE_SUCCESS, 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=121, (PACKET_SEQUENCE_CONTROL=0xc079), PACKET_LENGTH=13, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: TELECOMMAND_VERIFICATION = 1, SERVICE_SUBTYPE: TC_EXECUTION_COMPLETION_SUCCESS = 7, DESTINATION_ID: MISSION_TIMELINE = 110, TIME=0x8000001f9e39, PA_RPW_TELECOMMAND_PKT_ID=0x1ccc, PA_RPW_PKT_SEQ_CONTROL=0xd90d</p>
<hr />
<p>Contexte:<br />SocExplorerEngine.getSocExplorer: Version = 0.2.2, Branch = default, Changeset = c839740ef520<br />Carte EM<br />Vhdl: EM_1.1.23<br />Brique Star-Dundee S/N <illisible>.<br />Soft:1.0.0.11 (variante sur carte finale)</p>
<p>TEST CASE = SVS-0007<br />le fichierd'analyse est /home/validation/data/R2/SVS-0007/2014_06_19-14_21_35-Detail.txt</p> LFR-FSW - Bug #171 (Closed): TM_LFR_PARAMETER_DUMP et TM_LFR_HK est reçue avec CONTINUATION_PACKE...https://hephaistos.lpp.polytechnique.fr/redmine/issues/1712014-06-16T12:56:47Zbruno katra
<p>D'après SSS-CP-EQS-415 : le segmentation grouping flag doit toujours être placé à 3 (standalone).<br />Ce n'est pas le cas pour TM_LFR_PARAMETER_DUMP et TM_LFR_HK</p>
<p>14:29:47.876692, TM_LFR_PARAMETER_DUMP, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: DUMP = 9, (PACKET_ID=0xcc9), <strong>SEGMENTATION_GROUPING_FLAG: /!\CONTINUATION_PACKET = 0,</strong></p>
<p>14:29:47.325072, 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), <strong>SEGMENTATION_GROUPING_FLAG: /!\CONTINUATION_PACKET = 0,</strong></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 III (sans connecteurs sub-click)<br />Vhdl: mini-lfr_0.1.16<br />Brique Star-Dundee S/N 46120065<br />Soft:1.0.0.9b (variante sur carte finale)</p>
<p>TEST CASE = SVS-0065<br />Req = SSS-CP-EQS-415</p>
<p>RPW-SYS-IDB-00067-LES_Issue2_Rev2<br />RPW-SYS-MEB-LFR-ICD-00097 Issue3_Rev0<br />RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev2</p> LFR-FSW - Bug #169 (Closed): En SBM1, l'arrivée d'un SWF fait planter le soft de vol.https://hephaistos.lpp.polytechnique.fr/redmine/issues/1692014-06-12T10:13:28Zbruno katra
<p>Le test SVS-0019 plante systématiquement le soft de vol au même moment (compteur HK = 543).<br />L'analyse du test de Gérald montre que cela se passe lorsqu'on est en SBM1.</p>
<p>Véro et Bruno sont en train de chercher plus précisément le contexte des paramètres qui provoque ce bug et sa reproductibilité.</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 III (sans connecteurs sub-click)<br />Vhdl: mini-lfr_0.1.16<br />Brique Star-Dundee S/N 46120065.<br />Soft:1.0.0.8 (variante sur carte finale)</p>
<p>TEST CASE : SVS-0019</p> LFR-FSW - Bug #167 (Closed): TC_LFR_LOAD_NORMAL_PAR avec SY_LFR_N_BP_P0 = 0 fait planter le soft ...https://hephaistos.lpp.polytechnique.fr/redmine/issues/1672014-06-11T14:41:44Zbruno katra
<p>L'envoi de TC_LFR_LOAD_NORMAL_PAR avec SY_LFR_N_BP_P0 = 0 devrait renvoyé TM_LFR_TC_EXE_ERROR_INCONSISTENT (vf bug <a class="issue tracker-1 status-5 priority-5 priority-highest closed" title="Bug: TC_LFR_LOAD_NORMAL_PAR: SY_LFR_N_ASM_P, SY_LFR_N_BP_P0 et , SY_LFR_N_BP_P1 = 0 acceptés (Closed)" href="https://hephaistos.lpp.polytechnique.fr/redmine/issues/85">#85</a>) mais au lieu de ça le soft freeze :<br />- plus d'ack<br />- plus de HK</p>
<p>La vidéo jointe à cette issue montre ce qui se passe.</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 III (sans connecteurs sub-click)<br />Vhdl: mini-lfr_0.1.16<br />Brique Star-Dundee S/N 46120065.<br />Soft:1.0.0.8 (variante sur carte finale)</p>
<p>TEST CASE : script SY_LFR_N_BP_P0_failure.py dans SVS-0008</p> LFR-FSW - Bug #166 (Closed): PACKET LENGTH erroné pour TM_LFR_SCIENCE_BURST_BP1_F1 et TM_LFR_SCIE...https://hephaistos.lpp.polytechnique.fr/redmine/issues/1662014-06-10T06:15:20ZVeronique bouzid
<p>EN analysant le fichier 2014_06_05-12_11_54-Detail.txt correspondant au test<br />SVS-0090/generate_science_all_modes.py<br />2 pbs sur le parametre PACKET LENGTH, la longueur du packet de telemetry ne correspond pas au champ contenu dans PACKET_LENGTH</p>
<p>- 16:42:38.053034, 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=3, (PACKET_SEQUENCE_CONTROL=0xc003), 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=0x80000025ac28, 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=0x80000025ac28, PA_LFR_B_BP1_BLK_NR_F0=22<br />16:42:38.064438, TM_LFR_SCIENCE_BURST_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=4, (PACKET_SEQUENCE_CONTROL=0xc004), <strong>/!\PACKET_LENGTH=217(exp=(Number of bytes in Packet Data Field)-1=253)</strong>.....</p>
<p>- 16:42:38.053034, 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=3, (PACKET_SEQUENCE_CONTROL=0xc003), 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=0x80000025ac28, 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=0x80000025ac28, PA_LFR_B_BP1_BLK_NR_F0=22<br />16:42:38.064438, TM_LFR_SCIENCE_BURST_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=4, (PACKET_SEQUENCE_CONTROL=0xc004), <strong>/!\PACKET_LENGTH=217(exp=(Number of bytes in Packet Data Field)-1=253)</strong>,</p>
<p>Ce probleme est présent sur d'autres tests (vu egalement sur 1.0.0.6)</p>
<p>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: 0.0.16<br />Soft: 1.0.0.7 (variante sur carte finale)</p>
<p>Brique Star-Dundee S/N <strong>XX</strong>.</p> LFR-FSW - Bug #117 (Closed): Gestion de SEQUENCE_CNT dans les TM_LFR_*https://hephaistos.lpp.polytechnique.fr/redmine/issues/1172014-04-09T14:59:58ZGerald Saule
<p>Le champ SEQUENCE_CNT des TM correspond au nombre de TM pour chaque couple (PACKET_ID,DESTINATION_ID).<br />Il y a un pb d'homogénéïté lors de l'implémentation de cette affectation:<br />-Pour PACKET_ID=0xcfc et DESTINATION_ID: GROUND = 0 (TM_LFR_SCIENCE_SBM1_CWF_F1), la premier paquet est en SEQUENCE_CNT=0.<br />-Pour les autres couples, le premier paquet est en SEQUENCE_CNT=1.</p>
<p><strong>Les SEQUENCE_CNT doivent commencer à 0 dès la première TM (cf. mail Philippe Plasson 4/06/2014)</strong></p>
<p>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.</p>
<p>Contexte:<br />LPPMON: Version=0.2.2 Branch=default Changeset=835955994d5f<br />Carte mini-LFR: LFR-172200 dev V1.0; No série III (sans connecteurs sub-click)<br />Vhdl: mini-lfr_0.1.9<br />Brique Star-Dundee S/N <illisible>.<br />Soft:1.0.0.5 (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 #108 (Closed): Champs TIME et ACQUISITION_TIME différents dans les TM_LFR_SCIENCE_*https://hephaistos.lpp.polytechnique.fr/redmine/issues/1082014-03-31T14:59:04Zbruno katra
<p>Dans les TM science, les 2 champs TIME ont des valeurs différentes alors que ceux-ci devraient avoir la même valeur ACQUISITION_TIME qui est le temps du premier échantillon du paquet (SSS-CP-EQS-410).</p>
<p>15:31:35.368491, TM_LFR_SCIENCE_BURST_CWF_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=0, (PACKET_SEQUENCE_CONTROL=0xc000), PACKET_LENGTH=4051, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: SCIENCE_DATA_TRANSFER = 21, SERVICE_SUBTYPE: SCIENCE_REPORT = 3, DESTINATION_ID: GROUND = 0, <strong>TIME=0x800001fd7f1b</strong>, PA_LFR_SID_PKT: SC_B_CWF_F2 = 2, 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, SPARE: 0x0, <strong>PA_LFR_ACQUISITION_TIME=0x800001f30000</strong>, PA_LFR_CWF_BLK_NR=336</p>
<p>Contexte:<br />LPPMON Version=0.2.2 - Branch=default - Changeset=835955994d5f</p>
<p>Carte mini-LFR: LFR-172200 dev V1.0; No série 5<br />Vhdl: 0.0.16<br />Soft: 1.0.0.3 (variante sur carte finale) = r109</p>
<p>Brique Star-Dundee S/N illisible.</p>
<p>RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev2<br />RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev2<br />RPW-SYS---ICD-00067-LES_Issue2_Rev2_RPW_IDB_Parameter_Definition</p> LFR-FSW - Bug #104 (Closed): SY_LFR_FPGA_VERSION_N3 de TM_LFR_HK erronéhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/1042014-03-28T13:17:19ZGerald Saule
<p>TM_LFR_HK, SY_LFR_FPGA_VERSION_N3=255 est une coquille.<br />On attend SY_LFR_FPGA_VERSION_N3=7.</p>
<p>Contexte:<br />LPPMON Version=0.2.2 Branch=default Changeset=835955994d5f<br />Carte mini-LFR:LFR-172200 dev V1.0; No série III (sans connecteurs sub-click)<br />Vhdl: mini-lfr_0.1.7<br />Soft: 1.0.0.4 (variante sur carte finale)<br />Brique Star-Dundee S/N <blank>.</p>
<p>TEST CASE = s.o.</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 #85 (Closed): TC_LFR_LOAD_NORMAL_PAR: SY_LFR_N_ASM_P, SY_LFR_N_BP_P0 et , SY_LFR_N_...https://hephaistos.lpp.polytechnique.fr/redmine/issues/852014-03-12T09:35:44ZGerald Saule
<p>Le LFR FSW accepte des périodes nulles. Ce n'est pas interdit par l'ICD; néanmoins, le comportement associé est indéfini.</p>
<blockquote>
<p>09:51:24.915628, TC_LFR_LOAD_NORMAL_PAR, SY_LFR_N_SWF_L = 2048, SY_LFR_N_SWP_P = 300(s), <strong>SY_LFR_N_ASM_P = 0(s)</strong>, SY_LFR_N_BP_P0 = 4(s), SY_LFR_N_BP_P1 = 20(s)<br />09:51:24.918065, TM_LFR_TC_EXE_SUCCESS</p>
<p>09:51:25.116246, TC_LFR_LOAD_NORMAL_PAR, SY_LFR_N_SWF_L = 2048, SY_LFR_N_SWP_P = 300(s), SY_LFR_N_ASM_P = 4(s), <strong>SY_LFR_N_BP_P0 = 0(s)</strong>, SY_LFR_N_BP_P1 = 20(s)<br />09:51:25.119052, TM_LFR_TC_EXE_SUCCESS</p>
<p>09:51:25.320007, TC_LFR_LOAD_NORMAL_PAR, SY_LFR_N_SWF_L = 2048, SY_LFR_N_SWP_P = 300(s), SY_LFR_N_ASM_P = 4(s), SY_LFR_N_BP_P0 = 4(s), <strong>SY_LFR_N_BP_P1 = 0(s)</strong><br />09:51:25.321911, TM_LFR_TC_EXE_SUCCESS</p>
</blockquote>
<p><ins>Contexte:</ins><br />LPPMON Version=0.2.2 - Branch=default - Changeset=835955994d5f</p>
<p>Carte mini-LFR: LFR-172200 dev V1.0; No série III (sans connecteurs sub-click)<br />Vhdl: mini-lfr_0.0.0.15<br />Soft: 1.0.0.2 (variante sur carte finale) = r104</p>
<p>Brique Brique Star-Dundee S/N 46120065.</p>
<p>TEST CASE associé(s) = SVS-0029.</p>
<p>RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev0<br />RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev1</p> LFR-FSW - Bug #65 (Closed): TC_LFR_LOAD_NORMAL_PAR: pas de vérif sur SY_LFR_N_ASM_P, S_LFR_N_BP_...https://hephaistos.lpp.polytechnique.fr/redmine/issues/652014-02-24T14:13:06ZGerald Saule
<p>Cette issue reprend l'issue Bug <a class="issue tracker-4 status-5 priority-3 priority-high3 closed" title="Task: Delivery 3.1.0.5 (Closed)" href="https://hephaistos.lpp.polytechnique.fr/redmine/issues/905">#905</a> (TC_LFR_LOAD_NORMAL_PAR: pas de vérif sur SY_LFR_N_ASM_P, S_LFR_N_BP_P0, SY_LFR_N_BP_P1).</p>
<p>Pour TC_LFR_LOAD_NORMAL_PAR, les champs SY_LFR_N_ASM_P, S_LFR_N_BP_P0, SY_LFR_N_BP_P1 ne sont pas controlés.<br />La valeur 0 devrait être un moyen simple d'obtenir un rejet (il s'agit de périodes).<br />LFR retourne TM_LFR_TC_EXE_SUCCESS.</p>
<p>Contexte:<br />LPPMON: Version=0.2.2 Branch=default Changeset=835955994d5f<br />Carte mini-LFR: LFR-172200 dev V1.0; No série III (sans connecteurs sub-click)<br />Vhdl: mini-lfr_0.0.0.15<br />Brique Star-Dundee S/N 46120065.<br />Soft:1.0.0.1 (variante sur carte finale)</p>
<p>TEST CASE = SVS_0008</p>
<p>RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev0<br />RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev1</p> LFR-FSW - Bug #57 (Closed): TC_LFR_LOAD_NORMAL_PAR renvoie TM_LFR_TC_EXE_NOT_IMPLEMENTED si SY_LF...https://hephaistos.lpp.polytechnique.fr/redmine/issues/572014-02-19T16:31:00ZGerald Saule
<p>Pour TC_LFR_LOAD_NORMAL_PAR, SY_LFR_N_SWF_L affecté conformément à Bug #816 (SY_LFR_N_SWF_L: >=16, multiple de 16, <= 2048), mais différent de la valeur par défaut (2048).<br />L'acquittement retourne TM_LFR_TC_EXE_NOT_IMPLEMENTED (excepté en NORMAL).</p>
<blockquote>
<p>16:44:52.151797, 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=830, (PACKET_SEQUENCE_CONTROL=0xc33e), PACKET_LENGTH=15, CCSDS_SECONDARY_HEADER_FLAG=0, PUS_VERSION = 1, ACK_EXECUTION_COMPLETION=0, ACK_EXECUTION_PROGRESS=0, ACK_EXECUTION_START=0, ACK_ACCEPTANCE=0, SERVICE_TYPE: EQ_CONFIGURATION = 181, SERVICE_SUBTYPE: LOAD_NORMAL_PARAMETERS_1 = 13, SOURCE_ID: TC_SEQUENCES = 111, SY_LFR_N_SWF_L = 16, SY_LFR_N_SWP_P = 300(s), SY_LFR_N_ASM_P = 3600(s), SY_LFR_N_BP_P0 = 4(s), SY_LFR_N_BP_P1 = 20(s), SPARE=0x0, SY_LFR_N_CWF_LONG_F3 = 1, SPARE=0x0, CRC = 0x4b87</p>
<p>16:44:52.15462, TM_LFR_TC_EXE_NOT_IMPLEMENTED, 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=228, (PACKET_SEQUENCE_CONTROL=0xc0e4), PACKET_LENGTH=17, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: TELECOMMAND_VERIFICATION = 1, SERVICE_SUBTYPE: TC_EXECUTION_COMPLETION_FAILURE = 8, DESTINATION_ID: TC_SEQUENCES = 111, TIME=0x80016c046b62, PA_RPW_TC_FAILURE_CODE: FUNCT_NOT_IMPL = 42002, PA_RPW_TELECOMMAND_PKT_ID=0x1ccc, PA_RPW_PKT_SEQ_CONTROL=0xc33e, PA_RPW_TC_SERVICE=181, PA_RPW_TC_SUBTYPE=13</p>
</blockquote>
<p>(Cette issue reprend Bug #835 de pc-instru)</p>
<p>Contexte:</p>
<p>LPPMON Version=0.2.2 Branch=default Changeset=835955994d5f<br />Carte mini-LFR: LFR-172200 dev V1.0; No série III (sans connecteurs sub-click)<br />Vhdl: mini-lfr_0.0.0.15<br />Soft: 1.0.0.1 (variante sur carte finale)<br />Brique Star-Dundee S/N 46120065.</p>
<p>TEST CASE = SVS_0001_step03</p>
<p>RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev0<br />RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev1</p>