INSTRU: Issueshttps://hephaistos.lpp.polytechnique.fr/redmine/https://hephaistos.lpp.polytechnique.fr/redmine/redmine/favicon.ico?15080976012017-11-23T10:39:12ZRedmine
Redmine SciQLOP - Bug #2361 (Closed): Retour arrière après un zoom-boxhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/23612017-11-23T10:39:12ZAnonymousSciQLOP - Bug #2255 (Closed): Drag&drop crasheshttps://hephaistos.lpp.polytechnique.fr/redmine/issues/22552017-11-07T19:22:28ZNicolas Aunainicolas.aunai@lpp.polytechnique.frLFR-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> SciQLOP - Bug #741 (Closed): Point labels do not appear on mousehoverhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/7412016-07-13T09:20:37ZAnonymous
<p>Point labels do not appear on mousehover</p> SciQLOP - Bug #739 (Closed): Times with high precision appear stackedhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/7392016-07-11T13:43:15ZAnonymous
<p>Times with high precision appear stacked</p> SciQLOP - Bug #720 (Closed): Linked Plots don't work as intendedhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/7202016-06-29T08:43:27ZAnonymous
<p>When Plots are linked, changes in zoom on X on a plot are properly echoed by the other plot, but not the X scales.<br />We can see a small difference between axes tick labels.</p> SciQLOP - Bug #719 (Closed): The "M" feature in Plots in order to rescale the plot in not working...https://hephaistos.lpp.polytechnique.fr/redmine/issues/7192016-06-29T07:55:05ZAnonymous
<p>The "M" feature in Plots in order to rescale the plot in not working as intended.<br />It unzooms but doesn't scale, and does nothing if the zoom ratio didn't change.</p> SciQLOP - Bug #713 (Closed): Curves of plots are sometimes displayed where they shouldn't behttps://hephaistos.lpp.polytechnique.fr/redmine/issues/7132016-06-27T08:25:11ZAnonymous
<p>Curves of plots are displayed through other elements (margins and Py console) when they leave the scrollarea's displayed area.</p>
<p>Might be a Z-level problem.</p> SciQLOP - Bug #708 (Closed): Plot Minimum Sizehttps://hephaistos.lpp.polytechnique.fr/redmine/issues/7082016-06-20T10:00:16ZAnonymous
<p>I have difficulties to set a minimum size for a plot.</p>
<p>I tried to reimplement sizeHint, minimumSizeHint, and to call setMinimumSize without success.</p> SciQLOP - Bug #672 (Closed): Application does not respond in preference panelhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/6722016-03-11T20:55:00ZNicolas Aunainicolas.aunai@lpp.polytechnique.fr
<a name="Symptoms"></a>
<h1 >Symptoms<a href="#Symptoms" class="wiki-anchor">¶</a></h1>
<p>On my mac:<br />QLOP > Preferences > Space data AMDA Settings <br />If I check the box Use AMDA personnal settings:<br />The box is not checked, the program does not respond I must kill it.</p> SciQLOP - Bug #671 (Closed): code crashed after trying to move plot widgethttps://hephaistos.lpp.polytechnique.fr/redmine/issues/6712016-03-11T20:45:19ZNicolas Aunainicolas.aunai@lpp.polytechnique.fr
<p>I tried to move the plot widget around and the program crashed :</p>
<pre>
2016-03-11 21:36:29.532 QLop[16288:4679835] outHitPart = -1
2016-03-11 21:36:29.533 QLop[16288:4679835] inOptions: {
"is.flipped" = 1;
kCUIPartMaskKey = 768;
kCUIThumbProportionKey = "0.625";
state = normal;
value = 0;
widget = scrollbar;
}
2016-03-11 21:36:29.533 QLop[16288:4679835] inOptions: {
"is.flipped" = 1;
kCUIPartMaskKey = 768;
kCUIThumbProportionKey = "0.625";
state = normal;
value = 0;
widget = scrollbar;
}
2016-03-11 21:36:29.533 QLop[16288:4679835] outHitPart = -1
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
Segmentation fault: 11
</pre> SciQLOP - Bug #669 (Closed): user can remove data from database while it is still plottedhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/6692016-03-11T20:37:58ZNicolas Aunainicolas.aunai@lpp.polytechnique.fr
<a name="Symptom"></a>
<h1 >Symptom<a href="#Symptom" class="wiki-anchor">¶</a></h1>
<p>It is not normal the user can remove data from the database while it is still in use by one of the plots (or later, any other module)</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>