INSTRU: Issueshttps://hephaistos.lpp.polytechnique.fr/redmine/https://hephaistos.lpp.polytechnique.fr/redmine/redmine/favicon.ico?15080976012023-10-27T15:43:18ZRedmine
Redmine JUICE-SCM/Ground Segment - Support #4207 (Resolved): New tries concerning the differences between...https://hephaistos.lpp.polytechnique.fr/redmine/issues/42072023-10-27T15:43:18ZTheo StassenJUICE-SCM/Ground Segment - Support #4197 (Resolved): Research with laurent about the difference o...https://hephaistos.lpp.polytechnique.fr/redmine/issues/41972023-10-17T14:50:01ZTheo StassenJUICE-SCM/Ground Segment - Support #4084 (Resolved): Investigate why results are in general bette...https://hephaistos.lpp.polytechnique.fr/redmine/issues/40842023-05-05T16:37:46ZTheo Stassen
<p>Solution finally found -> there is an error in idl code, y and z are interverted in kernel creation. -> see wiki<br />Now the results are really good everywhere</p> JUICE-SCM/Ground Segment - Support #4082 (Resolved): Find why the computed spectrum is very diffe...https://hephaistos.lpp.polytechnique.fr/redmine/issues/40822023-04-27T16:20:15ZTheo StassenJUICE-SCM/Ground Segment - Support #4075 (Resolved): Obtain good result in the comparison of Refe...https://hephaistos.lpp.polytechnique.fr/redmine/issues/40752023-04-26T14:24:43ZTheo Stassen
<p>The comparison was at beginning not really good next to the waveforms holes.<br />Solved, it was a problem of block ans holes separation.</p> LFR-FSW - Support #1091 (Feedback): Lost some BP packets in BURST modehttps://hephaistos.lpp.polytechnique.fr/redmine/issues/10912017-04-27T09:51:05ZVeronique bouzid
<p>1 test "CAS NOMINAL" <br />on entre en burst mode<br />17:34:51.300563, TC_LFR_ENTER_MODE (CP_LFR_MODE=2)<br />17:34:52.481738, TM_LFR_SCIENCE_BURST_BP1_F0, TIME=0x27b7f503ffff<br />17:34:52.537164, TM_LFR_SCIENCE_BURST_BP1_F1, TIME=0x27b7f504000a</p>
<p>17:34:53.482246, TM_LFR_SCIENCE_BURST_BP1_F0, TIME=0x27b7f5050000<br />17:34:53.537797, TM_LFR_SCIENCE_BURST_BP1_F1, TIME=0x27b7f505000a</p>
<p>17:34:54.482316, TM_LFR_SCIENCE_BURST_BP1_F0, TIME=0x27b7f5060000<br />17:34:54.537483, TM_LFR_SCIENCE_BURST_BP1_F1, TIME=0x27b7f506000a</p>
<p>17:34:55.481104, TM_LFR_SCIENCE_BURST_BP1_F0, TIME=0x27b7f5070000<br />17:34:55.534692, TM_LFR_SCIENCE_BURST_BP1_F1, TIME=0x27b7f507000b</p>
<p>17:34:56.486681, TM_LFR_SCIENCE_BURST_BP1_F0, TIME=0x44a32a03c608<br />17:34:56.489927, TM_LFR_SCIENCE_BURST_BP2_F0, TIME=0x44a32a03c608</p>
<p>17:34:56.527804, TC_LFR_ENTER_MODE (CP_LFR_MODE=3)<br />17:34:56.548004, TM_LFR_SCIENCE_BURST_BP1_F1, TIME=0x44a32a03c612<br />17:34:56.587099, TM_LFR_SCIENCE_BURST_BP2_F1, TIME=0x44a32a03c612<br />17:34:56.587799, TM_LFR_TC_EXE_SUCCESS, TIME=0x44a32a04efa2</p>
<p>17:34:56.920005, TM_LFR_SCIENCE_SBM1_BP1_F0, TIME=0x44a32a050001</p>
<p>Ce cas est nominal. On recoit bien tous les produits BURST meme apres le passage en SBM1.<br />5 BURST_BP1_F0<br />5 BURST_BP1_F1<br />1 BURST_BP2_F0<br />1 BURST_BP2_F1</p>
<p>-Le meme test rejoué " ERREUR" <br />16:27:43.862845, TC_LFR_ENTER_MODE (CP_LFR_MODE=2)<br />16:27:43.871156, TM_LFR_TC_EXE_SUCCESS, TIME=0x318b8203e9a3</p>
<p>16:27:45.049608, TM_LFR_SCIENCE_BURST_BP1_F0, TIME=0x318b82040001<br />16:27:45.105166, TM_LFR_SCIENCE_BURST_BP1_F1, TIME=0x318b8204000b</p>
<p>16:27:46.050847, TM_LFR_SCIENCE_BURST_BP1_F0, TIME=0x318b82050001<br />16:27:46.106364, TM_LFR_SCIENCE_BURST_BP1_F1, TIME=0x318b8205000b</p>
<p>16:27:47.049695, TM_LFR_SCIENCE_BURST_BP1_F0, TIME=0x318b82060001<br />16:27:47.104954, TM_LFR_SCIENCE_BURST_BP1_F1, TIME=0x318b8206000c</p>
<p>16:27:48.049311, TM_LFR_SCIENCE_BURST_BP1_F0, TIME=0x318b82070001<br />16:27:48.103473, TM_LFR_SCIENCE_BURST_BP1_F1, TIME=0x318b8207000c</p>
<p>16:27:49.055988, TM_LFR_SCIENCE_BURST_BP1_F0, TIME=0x3d633003c8cd<br />16:27:49.058668, TM_LFR_SCIENCE_BURST_BP2_F0, TIME=0x3d633003c8cd</p>
<p>16:27:49.084134, TC_LFR_ENTER_MODE (CP_LFR_MODE=3)<br />16:27:49.094502, TM_LFR_TC_EXE_SUCCESS, TIME=0x3d633004ebbe<br />16:27:49.476704, TM_LFR_SCIENCE_SBM1_BP1_F0, TIME=0x3d6330050000</p>
<p>--> la il nous manque BURST_BP1_F1 et un BURST_BP2_F1 un on a seulement recu<br />5 BURST_BP1_F0<br />4 BURST_BP1_F1<br />1 BURST_BP2_F0</p>
<p>Ma piste s oriente vers le changement de mode qui resette les buffers alors parfois les produits burst sont deja dabns la file d attente pour envoi et parfois<br />non</p>
<p>--> Peux-tu expliquer ?</p>
<p>J ai rencontré plusieurs ce petit dysfonctionnement souvent sur le burst mais egalement sur les NORMAL_BP NORMAL_ASM et sur les BP en SBM2.</p>
<p>Je ne classe pas cette issue en BUG car je pense que c'est le comportement de LFR et qu il faut juste documenter ce point.</p>
<p>Contexte du test<br />----------------<br />FSW 3.2.0.15<br />VHDL 3.1.91<br />SocExplorerEngine.getSocExplorer: Version = 0.7.0, Branch = default, Changeset = c459540a6dbdcbb4e17f204685fce02c070ba971+<br />EQM sans Timegen<br />StarDundee</p> LFR-FSW - Support #1090 (Feedback): Back to time managementhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/10902017-04-27T07:43:37ZVeronique bouzid
<p>Premier cas de test<br />- LFR a booté, <br />Le soft remonte bien que le timecode est missing et la derniere erreur tracée est coherente avec cela<br />HK_LFR_UPDATE_TIME_TC_CNT=0, HK_LFR_LE_CNT=1, HK_LFR_ME_CNT=0, HK_LFR_HE_CNT=0, HK_LFR_LAST_ER_RID: LE_LFR_TIMEC = 42129, HK_LFR_LAST_ER_CODE: MISSING = 21, HK_LFR_LAST_ER_TIME=0x8000000209dd, HK_LFR_DPU_SPW_TICK_OUT_CNT=0, HK_LFR_DPU_SPW_LAST_TIMC=0, , HK_LFR_TIMECODE_ERRONEOUS=0, HK_LFR_TIMECODE_MISSING=1, HK_LFR_TIMECODE_INVALID=0, HK_LFR_TIME_TIMECODE_IT=0, HK_LFR_TIME_NOT_SYNCHRO=0, HK_LFR_TIME_TIMECODE_CTR=0,</p>
<p>- Envoi d'une TC_LFR_UPDATE_TIME avec 300ms apres une timecode invalid ( je mets 5)<br />TC_LFR_UPDATE_TIME, CCSDS_VERSION, CP_RPW_TIME=0x38f223010000</p>
<p>sur la TM_LFR_HK<br />HK_LFR_UPDATE_TIME_TC_CNT=1, HK_LFR_LE_CNT=1, HK_LFR_ME_CNT=0, HK_LFR_HE_CNT=0, HK_LFR_LAST_ER_RID: LE_LFR_TIMEC = 42129, HK_LFR_LAST_ER_CODE: MISSING = 21, HK_LFR_LAST_ER_TIME=0x8000000209dd, HK_LFR_DPU_SPW_TICK_OUT_CNT=0, HK_LFR_DPU_SPW_LAST_TIMC=0, HK_LFR_TIMECODE_ERRONEOUS=0, HK_LFR_TIMECODE_MISSING=1, HK_LFR_TIMECODE_INVALID=0, HK_LFR_TIME_TIMECODE_IT=0, HK_LFR_TIME_NOT_SYNCHRO=0, HK_LFR_TIME_TIMECODE_CTR=0,</p>
<p>--> Le soft ne remonte aucune erreur et donc la derniere erreur tracée est toujours missing.</p>
<p>--> Peux-tu expliquer CELA</p>
<p>Contexte du test<br />---------------------<br />FSW 3.2.0.15<br />VHDL 3.1.91<br />SocExplorerEngine.getSocExplorer: Version = 0.7.0, Branch = default, Changeset = c459540a6dbdcbb4e17f204685fce02c070ba971+<br />EQM sans Timegen<br />StarDundee</p> Solar Orbiter LFR - Support #872 (New): Comportement lorsque l'on ne masque que 2 bins // Reactio...https://hephaistos.lpp.polytechnique.fr/redmine/issues/8722016-12-30T15:32:03Zbruno katra
<p>Il s'agit juste d'une remarque et d'une question :<br />On a déjà vu qu'un pic à une fréquence donnée possède 2 lobes (un de chaque côté) qui bavent sur les fréquences autour.<br />Or, lorsque une RW a une frequence propre de LFR le FSW génère un masque avec 3 bins masqués donc en effet on ne voit rien dans les BP2 (même les lobes sont masqués).<br />Cependant, en cas de fréquence entre 2 frequences propres, on ne masque que 2 bins : ne s'attend t'on pas à voir un résidu de lobes dans les BP2 ?</p> SciQLOP - Support #718 (New): QCdf should standardize extracted Time https://hephaistos.lpp.polytechnique.fr/redmine/issues/7182016-06-29T07:48:27ZAnonymous
<p>A good improvement of Qcdf would be to provide time extracted in UTC format for all products.</p> SciQLOP - Support #688 (Resolved): No way to add a colorbar into an axis object in qtchartshttps://hephaistos.lpp.polytechnique.fr/redmine/issues/6882016-05-10T14:22:33ZAnonymous
<p>The only way to interact with the axis in order to add a colorbar is to add a QGraphicsItem into the m_arrow QAbstractAxis' member. This m_arrow is a QGraphicsItemGroup.<br />Even when I add my custom QGraphicsRectItem containing my gradient into this m_arrow, it is never displayed in the axis layout.</p> LFR-FSW - Support #494 (Feedback): Gestion timecode https://hephaistos.lpp.polytechnique.fr/redmine/issues/4942015-09-11T10:33:03ZVeronique bouzid
<p>J'ai travaillé sur la gestion manuelle de l'envoi de timecode.<br />Pour cela on utilise la fonction SpwPlugin0.StarDundeeSendOneTimecode. Parfois, il faut envoyer 2 timecodes de suite pour que la commande<br />TC_LFR_UPDATE_TIME soit prise en compte, parfois un seul suffit. L'effet de bord est que si les 2 timecodes sont pris en compte, le temps interne de LFR est positionné au temps contenu<br />dans la TC_LFR_UPDATE_TIME + 1s. Donc cela n'etait pas concluant.<br />En effet, la TC_LFR_UPDATE_TIME se traduit par l'ecriture du temps dans le registre COARSE TIME LOAD et l'arrivée du timecode va ecrire ce registre dans le registre COARSE TIME. La reception du 2eme<br />timecode lui, incrementera de 1 ce temps.</p>
<p>--> Conclusion ce n'est pas ce que l'on veut.</p>
<p>En fait je me suis rendue compte que si je resette la carte LFR, je relance le test avec le couple TC_LFR_UPDATE_TIME + 1 timecode = 1, cela<br />fonctionne systématiquement.</p>
<p>Ma conclusion est donc que la remise à zero du timecode géré par le spw n'est effectuée que sur le reset et que meme si je ferme socexplorer<br />je conserve la valeur du dernier timecode que j ai envoyé.</p>
<p>Pour valider cette conclusion, j'ai lu la doc grlib.pdf de Gaisler et j'ai été aidé par Alexis.</p>
<p>J'ai donc écrit un petit script qui lit le registre nommé Time register (0x800000514) dans l'onglet GRSPW et qui contient sur 8 bits <br />- Time control flags (TCTRL) = 2 bits = b7 et b6<br />- Time counter (TIMECNT) = 6 bits = b5 à b0<br />Attention, cela correspond à la valeur du dernier timecode valide et non le nbre de timecode valides. Ce registre n'est accessible qu'en lecture et il est à l'adresse<br />0x800000514</p>
<p>Pour le lire, j ai utilisé la fonction SpwPlugin0.Read <br />et ma théorie s'est vérifiée, quand on sort de socexplorer , il y a conservation de ce registre.</p>
<p>Conclusion, avant d'envoyer un time code,<br />1- il faut lire la valeur contenue dans 0x800000514<br />2- incrementer cette valeur et l envoyer avec SpwPlugin0.StarDundeeSendOneTimecode</p>
<p>Voici donc la séquence à mettre<br />Lecture du timer counter<br />loc_time = SpwPlugin0.Read(0x80000514, 1)<br />timec = loc_time<sup><a href="#fn0">0</a></sup> & 0xff<br />print hex(timec)</p>
<p>timecode=int(timec)+2<br />print timecode<br />SpwPlugin0.StarDundeeSendOneTimecode (timecode)</p>
<p>Remarque<br />--------<br />Comme on ne s interesse pas aux 2 bits de controles, <strong>le masque devrait etre 3f au lieu de ff.</strong><br />En effet les timecodes sont modulo 64.<br />Je l'ai egalement vérifié si j'ecris SpwPlugin0.StarDundeeSendOneTimecode (255) et que je lis le registre, j obtiens en binaire 00111111 soit 3f<br />soit 63.</p>
<p>Autre test, j ai envoyé la sequence suivante<br />py > SpwPlugin0.StarDundeeSendOneTimecode (6)<br />py > SpwPlugin0.StarDundeeSendOneTimecode (254)<br />py > SpwPlugin0.StarDundeeSendOneTimecode (255)</p>
<p>--> le registre ne s'est mis à jour que lors de l'envoi de 255 , car 6 n'etait pas valide, 254 pas valide<br />mais 255 oui car increment de 1/ à la valeur précédente.</p>
<p>Voila ma conclusion. <br />Par contre, on voit bien que 254 a été conservé puisque 255 a été validé, mais je ne sais pas ou ???</p> LFR-FSW - Support #486 (Feedback): SSS-CP-FS-340 : Design or Testhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/4862015-08-18T06:46:10ZVeronique bouzid
<p>Hello,<br />Je m'interroge sur ce requirement<br />SSS-CP-FS-340<br />The RPW Flight Software shall maintain a local time with:<br />− a resolution of at least SY_RPW_TIME_RESOLUTION = 1 ms and a relative accuracy of<br /> SY_RPW_TIME_ACCURACY = 500 μs for the DAS and the three analyzers.<br />− a resolution of at least SY_DPU_DBS_TIME_RESOLUTION = 10 ms and a relative<br /> accuracy of SY_DPU_DBS_TIME_ACCURACY = 1 ms for the DBS.</p>
<p>Il est associé dans la SRS à REQ-LFR-SRS-5300_Ed2.<br />Dans notre fichier SSS-SRS-SVS-compliance_matrix_LFR_V2-1.2.xlsx , il apparait comme un test SVS-0020. Le script associé <br />est time_resolution.py (ce qui ne correspond pas à ce qui est ecrit dans le fichier ). Le nom est internal_time_consistent.py,<br />qui est un script de dépouillement.</p>
<p>Ma question est la suivante, <br />Je ne vois pas comment vérifier ce requirement et pour moi, c'est un test de Design.</p>
<p>J ai assigné ce point à Paul et mis Bruno en observateur ainsi que moi.</p>