INSTRU: Issueshttps://hephaistos.lpp.polytechnique.fr/redmine/https://hephaistos.lpp.polytechnique.fr/redmine/redmine/favicon.ico?15080976012017-10-11T09:09:58ZRedmine
Redmine LFR-FSW - Bug #2134 (Stalled): Emission d'une raie à 96Hz par LFRhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/21342017-10-11T09:09:58ZAlexis Jeandet
<p>Pendant les tests EMC, il a été mesuré une raie à 96Hz émise par LFR.<br />Après quelques investigations, ça s'explique par le fait que la consomation du FPGA entre le moment ou le CPU est en POWERDOWN et le moment ou il travaille est assez différente. De plus 96Hz correspond à la fréquence des interruptions pour les ASM à F0.<br />Une première tentative de mitigation en ajoutant une tache qui consomme du CPU en background a permis de baisser les niveaux d'émission mais c'est pas encore suffisant.<br />Il faut essayer de monter encore un peu la conso dans cette tache idle en utilisant la FPU par exemple.</p>
<ul>
<li><a href="https://hephaistos.lpp.polytechnique.fr/rhodecode/HG_REPOSITORIES/LPP/INSTRUMENTATION/USERS/JEANDET/LFR_FSW/changeset/fc82b08705ba9931880e4e57a76b1bb1ffa1e28e" class="external">Commit actuel</a></li>
<li><a href="https://hephaistos.lpp.polytechnique.fr/rhodecode/HG_REPOSITORIES/LPP/INSTRUMENTATION/USERS/JEANDET/SOLO_LFR_Notebooks/files/ea8683773e3816b28b499a7520bdfde53353a82a/LFR_CPU_POWERDOWN_EFFECT/LFR_CPU_POWERDOWN_EFFECT.ipynb" class="external">Analyse de l'effet du powerdown</a></li>
</ul> LFR-FSW - Bug #1029 (Stalled): La tâche AVGV semble s'arrêter lorsque l'on repasse en STDBY sur l...https://hephaistos.lpp.polytechnique.fr/redmine/issues/10292017-03-27T14:15:21Zbruno katra
<p>La courbe ci-dessous montre les moyennes dans les HK avec un signal de 0.1Hz sur V et 5Hz sur E1 -3/3V en STANDBY puis passage en NORMAL pendant 10s et repassage en STANDBY (on voit d'ailleurs le bug <a class="issue tracker-1 status-5 priority-2 priority-default closed" title="Bug: HK_LFR_SC_V_F3 , HK_LFR_SC_E1_F3, HK_LFR_SC_E2_F3 have amazing values when a TC_LFR_ENTER_MODE is... (Closed)" href="https://hephaistos.lpp.polytechnique.fr/redmine/issues/955">#955</a> de Véro).</p>
<p><img src="https://hephaistos.lpp.polytechnique.fr/redmine/attachments/download/2192/FLOWCHART01.png" alt="" /></p>
<p>Ceci est confirmé en regardant les valeurs dans les HK :<br />[LFR@pc-solar1 3.2.0.9]$ more hk<br /> V E1 E2<br /> 431 434 379 > STDBY<br /> 432 433 380>.....<br /> 430 433 380<br /> 430 433 380<br /> 432 434 379<br /> 431 434 379<br /> 430 435 380<br /> 431 434 380<br /> 431 434 380<br /> 430 434 380<br /> 432 433 379<br /> 431 436 380<br /> 431 434 380 <br /> 8279 1271 381 > NORMAL<br /> 22638 418 377<br /> 27125 409 376<br /> 21361 411 377<br /> 7575 411 377<br /> -8947 410 378<br /> -21935 410 378<br /> -26425 410 378<br /> -20669 410 377<br /> -6895 410 377<br /> 9642 410 378<br /> 22631 410 377> STDBY<br /> 540 415 338 <br /> 433 435 377<br /> 430 434 379<br /> 432 434 379<br /> 430 435 379</p>
<p>SSS-CP-EQS-526 ne stipule pas que la moyenne n'est faite qu'en mode SCIENCE. Nous avions compris que le moyennage est tout le temps actif (y compris en BURST et STANDBY où il n'y a pas de produits F3)</p> LFR-FSW - Bug #97 (Rejected): TM_LFR_HK: sauts de HK_LFR_DPU_SPW_PKT_SENT_CNThttps://hephaistos.lpp.polytechnique.fr/redmine/issues/972014-03-19T12:04:35ZGerald Saule
<p>Il s'agit de tester la robustesse du FSW LFR lors de déconnection fugitive entre carte et brique.<br />Les traces obtenues sont:</p>
<blockquote>
<p>18:38:27.989082, TM_LFR_HK, HK_LFR_DPU_SPW_PKT_SENT_CNT=1728, HK_LFR_MODE: STANDBY = 0</p>
<p>DECONNECTION/RECONNECTION</p>
<p>18:38:30.59011, TM_LFR_HK, HK_LFR_DPU_SPW_PKT_SENT_CNT=*4003*; exp=1729 , HK_LFR_MODE: STANDBY = 0</p>
</blockquote>
<p>Le pb porte sur le saut inaproprié de la valeur de HK_LFR_DPU_SPW_PKT_SENT_CNT.<br />Notons que la déconnexion se traduit ici par une absence de TM pendant 2.6s, ce qui laisse présentir que le FSW a identifié une perte du lien confirmée pendant SY_LFR_DPU_CONNECT_TIMEOUT (=1000ms); une mise en oeuvre des SSS-CP-EQS-153/154/155 étant prévisible.</p>
<p>Ce test montre aussi d'autres irrégulariés de HK_LFR_DPU_SPW_PKT_SENT_CNT: davantage compréhensibles, elles sont tracées par l'issue "TM_LFR_HK: HK_LFR_DPU_SPW_PKT_SENT_CNT périmé".</p>
<p><ins>Contexte:</ins></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.15<br />Soft: 1.0.0.1 (variante sur carte finale)<br />Brique Star-Dundee S/N 46120065.</p>
<p>TEST CASE = SVS_0061</p>
<p>RPW-SYS-IDB-00067-LES_Issue1_Rev8<br />RPW-SYS-MEB-LFR-ICD-00097 Issue2_Rev0<br />RPW-SYS-SSS-00013-LES + Annex_Release_Definition Issue2_rev1</p> VHDLib - Bug #96 (Rejected): DMA latency to access External memoryhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/962014-03-18T09:18:41ZJean-Christophe Pellion
<p>1- Verify than there is too waitstate access during a Memory Burst Access<br />2- Try others configurations to limit this latency ...</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> 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>