INSTRU: Issueshttps://hephaistos.lpp.polytechnique.fr/redmine/https://hephaistos.lpp.polytechnique.fr/redmine/redmine/favicon.ico?15080976012014-04-11T15:03:25ZRedmine
Redmine DECOM LFR - Bug #123 (Closed): Typage du temps dans le calcul du CUC time.https://hephaistos.lpp.polytechnique.fr/redmine/issues/1232014-04-11T15:03:25Zbruno katra
<p>Actuellement, le résultat final du calcul du temps :<br />coarse + fine est casté dans un double.<br />Selon Thomas pas suffisant pour garder assez de précision (14 chiffres significatifs alors qu'on en voudrait 16 = 10+6 digits)</p>
<p>Il faudrait maintenir le calcul et l'affichage séparé en integer pour le coarse et float pour le fine time.</p>
<p><ins>Update :</ins> on fait le double affichage dans le fichier de sortie : integer (2^-16 unit) + temps en float avec affichage séparé pour garder toute la précision car cet affichage pourra être utile pour la validation</p> LFR-FSW - Bug #118 (Closed): TC_LFR_ENTER_MODE: prise en compte de CP_LFR_ENTER_MODE_TIMEhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/1182014-04-10T08:47:15ZGerald Saule
<p>CP_LFR_ENTER_MODE_TIME n'est actuellement pas prise en compte correctement:</p>
<blockquote>
<p>10:23:31.251123, TM_LFR_HK, TIME=0x0000020844d5, HK_LFR_MODE: SBM2 = 4, SY_LFR_SW_VERSION_N1=1, SY_LFR_SW_VERSION_N2=0, SY_LFR_SW_VERSION_N3=0, SY_LFR_SW_VERSION_N4=5, SY_LFR_FPGA_VERSION_N1=0, SY_LFR_FPGA_VERSION_N2=1, SY_LFR_FPGA_VERSION_N3=9<br />10:23:31.983833, TC_LFR_ENTER_MODE (CP_LFR_MODE=0), CP_LFR_MODE: STANDBY = 0, CP_LFR_ENTER_MODE_TIME=0x0000020a0000<br />10:23:32.001456, TM_LFR_TC_EXE_SUCCESS<br />10:23:32.251109, TM_LFR_HK, <strong>TIME=0x0000020944db, HK_LFR_MODE: STANDBY = 0</strong></p>
</blockquote>
<p>La transition ne doit être immédiate que si CP_LFR_ENTER_MODE_TIME=0x000000000000.</p>
<p><ins>Contexte:</ins><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-0034<br />Req = REQ-LFR-SRS-5509/SSS-CP-FS-320</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> DECOM LFR - Bug #92 (Closed): Gestion du coarse time avec bit de synchrohttps://hephaistos.lpp.polytechnique.fr/redmine/issues/922014-03-14T16:29:59Zbruno katra
<p>CUC LFR différent du CUC standard :<br />Le MSB du coarse time est utilisé comme flag de synchro</p>
<p>Il faut le prendre en compte dans la decom.</p> LFR-FSW - Bug #83 (Closed): Talon dans la période de génération des TM_LFR_SCIENCE_NORMAL_SWF_Fxhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/832014-03-11T18:08:04ZGerald Saule
<p>Cette issue fait suite à Bug <a class="issue tracker-1 status-5 priority-1 priority-lowest closed" title="Bug: Analyse Logiscope LFR_3.1.0.4 : Tr_Parenthèses Severity is Medium (Closed)" href="https://hephaistos.lpp.polytechnique.fr/redmine/issues/809">#809</a> (Fluctuation du délai entre deux TM_LFR_SCIENCE_NORMAL_SWF_Fx (FIRST_PACKET_OF_A_GROUP_OF_PACKETS) consécutives).</p>
<p>Actuellement, la période des TM_LFR_SCIENCE_NORMAL_SWF_Fx est 300s par défaut. C'est un paramètre modifiable; des essai sont faits avec 16s.<br />On n'observe pas de différence de cadence entre TM_LFR_SCIENCE_NORMAL_SWF_F1, TM_LFR_SCIENCE_NORMAL_SWF_F2, ou TM_LFR_SCIENCE_NORMAL_SWF_F3.</p>
<p>En utilisant le champ PA_LFR_ACQUISITION_TIME:<br />-exp=300s: sur 2 périodes, on mesure res=300.00390625s<br />-exp=16: sur 61 périodes, on mesure res=16.00390625s</p>
<p>L'écart est satisfaisant; mais ce talon est toujours rigoureusement identique. Il pourrait y avoir un pb de principe à améliorer.<br />Notons que sur TM_LFR_SCIENCE_NORMAL_CWF_F3, on attend nom=168.0s. PA_LFR_ACQUISITION_TIME nous mène à 168.0s exactement.</p>
<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 #71 (Closed): Initialisation de SEQUENCE_CNT des TM_LFR_*https://hephaistos.lpp.polytechnique.fr/redmine/issues/712014-02-26T15:30:45ZGerald Saule
<p>Suite au démarage (HW&SW), on obtient les traces:</p>
<blockquote>
<p>10:55:39.444599, TC_LFR_LOAD_COMMON_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=2802, (PACKET_SEQUENCE_CONTROL=0xcaf2), PACKET_LENGTH=7, 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_COMMON_PARAMETERS = 11, SOURCE_ID: MISSION_TIMELINE = 110, SPARE = 0x0, SY_LFR_BW = 1, SY_LFR_SP0 = 0, SY_LFR_SP1 = 0, SY_LFR_R0 = 0, SY_LFR_R1 = 0, CRC = 0x818d</p>
<p>10:55:39.446617, 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=0, (PACKET_SEQUENCE_CONTROL=0xc000), 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=0x800003adf1b9, PA_RPW_TELECOMMAND_PKT_ID=0x1ccc, PA_RPW_PKT_SEQ_CONTROL=0xcaf2</p>
</blockquote>
<p>Le champ SEQUENCE_CNT correspond à la valeur initiale incrémentée de 1, d'après la SSS.<br />L'initialisation étant à 0, n attend donc un première valeur à 1.</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_0019<br />Req: SSS-CP-FS-590</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 #70 (Closed): SOURCE_ID = 0 doit être rejeté pour toute TC_LFR_ de V2.https://hephaistos.lpp.polytechnique.fr/redmine/issues/702014-02-26T14:21:02ZGerald Saule
<p>SOURCE_ID à 0 était possible pour les TC_LFR_* de V1. Cette valeur n'est plus acceptable pour V2.</p>
<blockquote>
<p>10:56:54.792441, TC_LFR_ENTER_MODE (CP_LFR_MODE=1), 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=6650, (PACKET_SEQUENCE_CONTROL=0xd9fa), PACKET_LENGTH=13, 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: ENTER_MODE = 41, /!\SOURCE_ID: 0, SPARE=0, CP_LFR_MODE: NORMAL = 1, CP_LFR_ENTER_MODE_TIME=0x000000000000, CRC = 0x1c7b<br />10:56:54.810542, 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=1, (PACKET_SEQUENCE_CONTROL=0xc001), 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: GROUND = 0, TIME=0x800003f94ae7, PA_RPW_TELECOMMAND_PKT_ID=0x1ccc, PA_RPW_PKT_SEQ_CONTROL=0xd9fa</p>
</blockquote>
<p>On attends donc un rejet pour l'exemple ci-dessus.</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_0019</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 #64 (Closed): PA_LFR_ACQUISITION_TIME de TM_LFR_SCIENCE_SBM1_CWF_F1https://hephaistos.lpp.polytechnique.fr/redmine/issues/642014-02-21T16:58:50ZGerald Saule
<p>Le champ PA_LFR_ACQUISITION_TIME de TM_LFR_SCIENCE_SBM1_CWF_F1, en plus d'évoluer perpétuellement, est parfois erroné.</p>
<p>14:28:38.876624, TM_LFR_SCIENCE_SBM1_CWF_F1, TIME=0x1360b, PA_LFR_ACQUISITION_TIME=0xc2b00<br />14:28:39.481475, TM_LFR_SCIENCE_SBM1_CWF_F1, TIME=0x1ddc1, PA_LFR_ACQUISITION_TIME=0x135b8</p>
<p>Calcul des deltas:<br />PC=0,604851s<br />TIME=0,65512085s<br />PA_LFR_ACQUISITION_TIME décroissant!</p>
<p>La période est fonctionnellement correcte; les mesures faites par l'horloge du PC (potentiellement dégradées par d'éventuelles variations de charge CPU) sont très satisfaisantes.<br />Le champ TIME est tout à fait vraisemblable.<br />NB: Issue à rapprochée de Bug <a class="issue tracker-1 status-5 priority-2 priority-default closed" title="Bug: Le champ PA_LFR_ACQUISITION_TIME de TM_LFR_SCIENCE_BURST_CWF_F2 est erroné (Closed)" href="https://hephaistos.lpp.polytechnique.fr/redmine/issues/60">#60</a> (Le champ PA_LFR_ACQUISITION_TIME de TM_LFR_SCIENCE_BURST_CWF_F2 est erroné)</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_0007</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 #61 (Closed): Traitement des PID, CAT, TYPE, et SUB-TYPE pour identifier les TM.https://hephaistos.lpp.polytechnique.fr/redmine/issues/612014-02-21T15:15:41ZGerald Saule
<p>Cette issue reprend l'issue Bug#585 ('Pas de Verification packet "TM_LFR_TC_EXE_CORRUPTED" sur SUB-TYPE erroné') de pc-instru.</p>
<p>Pour chaque TC, si l'on change les PID, CAT, TYPE, et SUB-TYPE en restant dans les valeurs possibles, on n'obtient pas un TM_LFR_TC_EXE_CORRUPTED.<br />Exemple avec TC_LFR_DUMP_PAR (PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: PRIVATE_SCIENCE_OR_TELECOMMAND = 12, SERVICE_TYPE: EQ_CONFIGURATION = 181, SERVICE_SUBTYPE: DUMP_PARAMETERS = 31)</p>
<blockquote>
<p>14:27:28.912202, /!\[254, 2, 0, 0, 28, 204, 192, 0, 0, 5, 16, 9, 31, 110, 244, 191](tc unknown) PID=76 CAT=12 TYPE=9 SUB-TYPE=31 Length(ccsds)=12<br />14:27:28.91512, TM_LFR_PARAMETER_DUMP<br />14:27:28.915266, TM_LFR_TC_EXE_SUCCESS</p>
</blockquote>
<p>Contexte:</p>
<p>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 />LFR FSW: 1.0.0.1 (variante sur carte finale)</p>
<p>Brique Star-Dundee S/N 46120065.</p>
<p>TEST CASE = SVS_0001</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 #60 (Closed): Le champ PA_LFR_ACQUISITION_TIME de TM_LFR_SCIENCE_BURST_CWF_F2 est e...https://hephaistos.lpp.polytechnique.fr/redmine/issues/602014-02-20T17:18:42ZGerald Saule
<p>Le champ PA_LFR_ACQUISITION_TIME de TM_LFR_SCIENCE_BURST_CWF_F2 est erroné:<br />-Il ne semble pas lié à TIME; pour chaque salve de 8 TM_LFR_SCIENCE_BURST_CWF_F2, on attend une valeur unique (légèrement) inférieure à celle de TIME.<br />-La salve de 17:31:50.6 est datée "antérieure" à celle de 17:31:40.1, ce qui n'est pas plausible.</p>
<p>A priori, il ne s'agit que d'un pb à la construction du contenu des TM_LFR_SCIENCE_BURST_CWF_F2.<br />En revanche, la période des TM_LFR_SCIENCE_BURST_CWF_F2 est fonctionnellement correctement implémentées; les mesures faites par l'horloge du PC (potentiellement dégradées par d'éventuelles variations de charge CPU) sont très satisfaisantes.<br />Le champ TIME est tout à fait vraisemblable.</p>
<blockquote>
<p>17:31:40.143644, TM_LFR_SCIENCE_BURST_CWF_F2, SEQUENCE_CNT=1739, TIME=0x7392b, PA_LFR_ACQUISITION_TIME=0x1400f5<br />17:31:40.153124, TM_LFR_SCIENCE_BURST_CWF_F2, SEQUENCE_CNT=1740, TIME=0x73936, PA_LFR_ACQUISITION_TIME=0x1400f5<br />17:31:40.162204, TM_LFR_SCIENCE_BURST_CWF_F2, SEQUENCE_CNT=1741, TIME=0x73940, PA_LFR_ACQUISITION_TIME=0x1400f5<br />17:31:40.170941, TM_LFR_SCIENCE_BURST_CWF_F2, SEQUENCE_CNT=1742, TIME=0x73948, PA_LFR_ACQUISITION_TIME=0x1400f5<br />17:31:40.181347, TM_LFR_SCIENCE_BURST_CWF_F2, SEQUENCE_CNT=1743, TIME=0x73950, PA_LFR_ACQUISITION_TIME=0x1400f5<br />17:31:40.188468, TM_LFR_SCIENCE_BURST_CWF_F2, SEQUENCE_CNT=1744, TIME=0x73959, PA_LFR_ACQUISITION_TIME=0x1400f5<br />17:31:40.197878, TM_LFR_SCIENCE_BURST_CWF_F2, SEQUENCE_CNT=1745, TIME=0x73961, PA_LFR_ACQUISITION_TIME=0x1400f5<br />17:31:40.205386, TM_LFR_SCIENCE_BURST_CWF_F2, SEQUENCE_CNT=1746, TIME=0x73969, PA_LFR_ACQUISITION_TIME=0x1400f5<br />(...)<br />17:31:50.643548, TM_LFR_SCIENCE_BURST_CWF_F2, SEQUENCE_CNT=1747, TIME=0x11b92b, PA_LFR_ACQUISITION_TIME=0x73a12<br />17:31:50.653128, TM_LFR_SCIENCE_BURST_CWF_F2, SEQUENCE_CNT=1748, TIME=0x11b936, PA_LFR_ACQUISITION_TIME=0x73a12<br />17:31:50.66027, TM_LFR_SCIENCE_BURST_CWF_F2, SEQUENCE_CNT=1749, TIME=0x11b940, PA_LFR_ACQUISITION_TIME=0x73a12<br />17:31:50.670481, TM_LFR_SCIENCE_BURST_CWF_F2, SEQUENCE_CNT=1750, TIME=0x11b948, PA_LFR_ACQUISITION_TIME=0x73a12<br />17:31:50.677548, TM_LFR_SCIENCE_BURST_CWF_F2, SEQUENCE_CNT=1751, TIME=0x11b950, PA_LFR_ACQUISITION_TIME=0x73a12<br />17:31:50.68816, TM_LFR_SCIENCE_BURST_CWF_F2, SEQUENCE_CNT=1752, TIME=0x11b959, PA_LFR_ACQUISITION_TIME=0x73a12<br />17:31:50.69576, TM_LFR_SCIENCE_BURST_CWF_F2, SEQUENCE_CNT=1753, TIME=0x11b961, PA_LFR_ACQUISITION_TIME=0x73a12<br />17:31:50.705299, TM_LFR_SCIENCE_BURST_CWF_F2, SEQUENCE_CNT=1754, TIME=0x11b969, PA_LFR_ACQUISITION_TIME=0x73a12</p>
</blockquote>
<p>(Pour la plage, 17:31:28-17:31:51, le LFR est en mode BURST)<br />F(TM_LFR_SCIENCE_BURST_CWF_F2): nom=256.0Hz, res=256.002340593/s<br />T(TM_LFR_SCIENCE_BURST_CWF_F2): nom=10.5s, mean=10.499904s<br />T(.../PA_LFR_ACQUISITION_TIME): mean=-12.7769012451s</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_0003</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 #53 (Closed): TM_LFR_PARAMETER_DUMP incohérent avec l'ICD.https://hephaistos.lpp.polytechnique.fr/redmine/issues/532014-02-18T15:11:00ZGerald Saule
<p>Les données brutes sont:<br />14:56:20.66118, 1L, 2L, 0L, 0L, 12L, 201L, 192L, 1L, 0L, 27L, 16L, 3L, 25L, 0L, 128L, 0L, 1L, 20L, 117L, 60L, 10L, 0L, 16L, 8L, 0L, 1L, 44L, 14L, 16L, 4L, 20L, 0L, 0L, 1L, 5L, 1L, 1L, 1L</p>
<p>L'outil d'analyse des TM y associe:<br />14:56:20.66118, TM_LFR_PARAMETER_DUMP/!\Length (byte) - Exp=36, Res=34, /!\(lfr_tm_packet_detail)</p>
<p>A priori, les champs (bytes) SY_LFR_S2_BP_P1 et SPARE (positions 34-35) sont omis.</p>
<p>Contexte:</p>
<p>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 />LFR FSW: 1.0.0.1 (variante sur carte finale)</p>
<p>Brique Star-Dundee S/N 46120065.</p>
<p>TEST CASE = SVS_0001</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 #52 (Closed): Taille des TM_LFR_HK incohérente avec l'ICD.https://hephaistos.lpp.polytechnique.fr/redmine/issues/522014-02-18T14:43:24ZGerald Saule
<p>Les données brutes sont:<br />14:56:18.384098, 1L, 2L, 0L, 0L, 12L, 196L, 192L, 147L, 0L, 119L, 16L, 3L, 25L, 0L, 128L, 0L, 1L, 17L, 221L, 163L, 1L, 13L, 0L, 1L, 0L, 0L, 1L, 0L, 0L, 15L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 146L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L, 0L</p>
<p>L'outil d'analyse des TM y associe:<br />14:56:18.384098, TM_LFR_HK/!\Length (byte) - Exp=124, Res=126</p>
<p>A priori, les champs (words) HK_LFR_DPU_SPW_PKT_RCV_CNT, HK_LFR_DPU_SPW_PKT_SENT_CNT (respectivement positions 80 et 82) sont correctement traités; les octets surnuméraires seraient sont en position>83.</p>
<p><ins>Contexte</ins>:</p>
<p>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 />LFR FSW: 1.0.0.1 (variante sur carte finale)</p>
<p>Brique Star-Dundee S/N 46120065.</p>
<p>TEST CASE = SVS_0001</p>
<p>RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev0<br />RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev1</p> DECOM LFR - Bug #34 (Closed): Problème fine time des formats CUC.https://hephaistos.lpp.polytechnique.fr/redmine/issues/342013-12-20T10:10:04Zbruno katra
<p>Validation de la lecture des temps à la demande de Thomas.</p>
<p>Test :</p>
<p><strong>Lecture du temps d'un échantillon "à la main" avec éditeur Hexa // valeur écrite par le prog de DECOM.</strong><br />Résultat : <br />coarse time : OK<br />fine time : facteur 2 entre les 2 résultats.</p> VHDLib - Bug #25 (Closed): LFR EM Bistream - 0.0.8 - Validationhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/252013-12-10T16:53:54ZJean-Christophe Pellion
<p>WaveFormPicker :<br />Correction de la communication SharedFIFO - LPP_DMA<br />- ajout de registres de tete a la shared FIFO<br />- modification de la generation du read</p>
<p>Revision : r277<br />Bitstream : <a href="https://hephaistos.lpp.polytechnique.fr/redmine/attachments/download/100/LFR-em-WaveFormPicker-0-0-8.pdb" class="external">LFR-em-WaveFormPicker-0-0-8.pdb</a></p> VHDLib - Bug #6 (Closed): écriture des données snapshot f0 f1 f2 erronéehttps://hephaistos.lpp.polytechnique.fr/redmine/issues/62013-11-14T10:55:41Zpaul leroy
<p>Il apparaît des sauts dans l'écriture des données snapshot, cf screenshot joint.</p> VHDLib - Bug #5 (Closed): IRQ from WaveFormPickerhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/52013-11-14T10:16:30ZJean-Christophe Pellion
<p>When the new status register is updated (a bit set to '1'), a continuous interrupt is generated.<br />=> Only one pulse should be generate</p>