INSTRU: Issueshttps://hephaistos.lpp.polytechnique.fr/redmine/https://hephaistos.lpp.polytechnique.fr/redmine/redmine/favicon.ico?15080976012017-07-07T14:13:58ZRedmine
Redmine Solar Orbiter LFR - Bug #1746 (New): Requête de modification pour prochaine release FSW : augment...https://hephaistos.lpp.polytechnique.fr/redmine/issues/17462017-07-07T14:13:58Zbruno katra
<p><a class="external" href="https://jira-lesia.obspm.fr/browse/RPWSWR-637">https://jira-lesia.obspm.fr/browse/RPWSWR-637</a></p> DECOM LFR - Bug #958 (New): Intégrer les différentes FT T° selon modèle cartehttps://hephaistos.lpp.polytechnique.fr/redmine/issues/9582017-03-06T09:17:19Zbruno katraVHDLib - Bug #850 (New): [IMPORTANT] amélioration de l'opération de shaping dans le VHDL LFRhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/8502016-12-02T12:09:15ZJean-Christophe Pellion
<p>ajouter un écrêtage au signaux</p> LFR-FSW - Bug #518 (Feedback): synchronisation F3-F2-F1-F0https://hephaistos.lpp.polytechnique.fr/redmine/issues/5182015-09-29T19:43:57Zthomas chust
<p>D'autres observations sont nécessaires pour confirmer la stabilité du décalage temporel décrit ci-dessous. Il faut confirmer aussi qu'un décalage entre F1 et F0 obéit à une logique semblale: avance de F1 sur F0 de ~T1/2. <br />Jean-Christophe pense qu'il s'agit d'une erreur dans le VHDL de comptage des registres temporels. S'il s'agit bien de cela, les décalages devraient être fixes. A priori il pourrait y avoir une différence entre ce qui a été observé ici sur le l'EM (VHDL 1.1.89 FSW 3.0.0.8) et ce que l'on observera sur le RTAX (VHDL 3.1.89) car sur l'EM il n'y en fait pas de filtre après les CIC ...</p>
<p>Le 29/09/2015 10:43, Thomas Chust a écrit :</p>
<blockquote>
<p>Salut Paul,</p>
<p>Les mesures à f3 n'ont rien donné car nous n'avons enregistré qu'un seul buffer. Et donc le temps indiqué (zéro) n'est pas utilisable ...Par contre la comparaison entre f2 et f1-f0 montre une avance de f2 sur f1-f0 d'environ T2/2 (au lieu d'un retard d'~T2 observé avec VHDL 1.1.83 FSW 3.0.0.8). Ci-joint trois plots (2015_09_25 ...) montrent ce décalage, dans la cas d'un sinus et dans le cas d'une rampe à 1Hz et dans le cas d'un sinus à 24Hz.</p>
<p>J'ai refais des mesures hier que je suis en train d’analyser et qui jusqu'à présent confirme cela. Cela semble donc être stable et reproductible (VHDL 1.1.89 FSW 3.0.0.8). Pour f3 je trouve un décalage qui suit la même logique: c'est en avance de ~T3/2. Voir les deux plots joints (2015_09_28 ...).</p>
<p>Par contre je m'interroge sur le fait que le premier échantillon f3 (cwf mode normal_long) puisse être daté plus de 100s avant le premier échantillon f2 (swf mode normal toute les 16s) ?</p>
<p>a+<br />Thomas</p>
<p>Le 29/09/2015 08:48, paul leroy a écrit :</p>
<blockquote>
<p>Qu'ont donné les mesures qu'on a faites vendredi?</p>
<p>J'ai réfléchi à un truc pour les mitigations SWA/PAS. Une matrice occupe 12800 octets en mémoire (25*128*4). C'est pas impossible qu'on puisse stocker 2 secondes entières de matrices à f0, f1 et f2, et enlever du calcul les matrices qui seraient identifiées comme polluées sur la base des informations transmises par SWA/PAS.</p>
<p>Le 09/26/2015 09:39 AM, Thomas Chust a écrit :</p>
<blockquote>
<p>Salut Jean-Christophe,<br />L'objet de mes questions hier à propos de la synchro entre f0, f1, f2 et f3 était ce message d'Emmanuel G. et ses observations. Sur le moment j'ai peut-être répondu un peu trop rapidement ...<br />A lundi<br />Thomas</p>
</blockquote></blockquote></blockquote>
<blockquote><blockquote><blockquote>
<p>-------- Message transféré --------<br />Sujet : Re: Synchronisation F1-F2<br />Date : Tue, 22 Sep 2015 17:35:17 +0200<br />De : Thomas Chust <<a class="email" href="mailto:thomas.chust@lpp.polytechnique.fr">thomas.chust@lpp.polytechnique.fr</a>><br />Pour : Guilhem Emmanuel (ALTRAN TECHNOLOGIES) <<a class="email" href="mailto:emmanuel.guilhem@cnes.fr">emmanuel.guilhem@cnes.fr</a>><br />Copie à : nicolas briand <<a class="email" href="mailto:nicolas.briand@lpp.polytechnique.fr">nicolas.briand@lpp.polytechnique.fr</a>>, Vincent Leray <<a class="email" href="mailto:vincent.leray@nexeya.com">vincent.leray@nexeya.com</a>>, Alexis Jeandet <<a class="email" href="mailto:alexis.jeandet@lpp.polytechnique.fr">alexis.jeandet@lpp.polytechnique.fr</a>>, <a class="email" href="mailto:moustapha.dekkali@obspm.fr">moustapha.dekkali@obspm.fr</a> <<a class="email" href="mailto:moustapha.dekkali@obspm.fr">moustapha.dekkali@obspm.fr</a>>, Pontet Bernard <<a class="email" href="mailto:Bernard.Pontet@cnes.fr">Bernard.Pontet@cnes.fr</a>>, Sanisidro Julien <<a class="email" href="mailto:Julien.Sanisidro@cnes.fr">Julien.Sanisidro@cnes.fr</a>>, Bruno Katra LPP <<a class="email" href="mailto:bruno.katra@lpp.polytechnique.fr">bruno.katra@lpp.polytechnique.fr</a>></p>
<p>Salut Emmanuel,</p>
<p>Merci pour cette jolie observation mais a priori cela n'est pas anormal. Les filtrages numériques introduisent des déphasage en fonction de la fréquence. Ces derniers ne sont a priori pas identiques selon les fréquences de décimation f0, f1 et f2. Plus courte est la fréquence de coupure, plus grand est le retard de phase. Le signal f2 est donc celui qui serait le plus déphasé (en retard) sur les autres (f1 ou f0).</p>
<p>L'objet de la détermination des fonctions de transfert à f0, f1, f2 et f3 de LFR seul, en amplitude et phase, a justement pour objet la possibilité de "détordre" ces données. On doit justement prochainement avancer avec Bruno pour passer à la calibration de la réponse en fréquence de la phase ...</p>
<p>A bientôt<br />Thomas</p>
<p>Le 22/09/2015 15:13, Guilhem Emmanuel (ALTRAN TECHNOLOGIES) a écrit :</p>
<blockquote>
<p>Bonjour Thomas,</p>
<p>Je t’envoie un résultat de test en pièce jointe. Il s’agit de la synchro entre F1 et F2, nous le vérifions lorsque nous testons la synchro entre TDS et LFR. Sur ces fichiers, vous pourrez constater qu’il y a un gros phase shift entre la mesure F2 et la mesure F1, ce décalage dépend de la fréquence. La configuration de LFR était E1=V12_DC, donc il n’est pas sensé y avoir de filtrage, ce qui pourrait induire un phase shift.</p>
<p>Les mesures de synchro entre F0 et F1 sont bonnes comme tu peux le voir en pièce jointe.</p>
<p>Qu’en penses-tu? Est-ce calibrable ? le phase shift atteint quand même presque 90° aux basses fréquences.</p>
<p>Merci pour ton retour,</p>
<p>Emmanuel Guilhem (ALTRAN)<br />RPW<br />Téléphone : (+ 00 33) 5 61 28 76 04<br />E-mail : <a class="email" href="mailto:emmanuel.guilhem@cnes.fr">emmanuel.guilhem@cnes.fr</a></p>
</blockquote></blockquote></blockquote></blockquote> SocExplorer - Bug #504 (New): setInstanceName doesn't changes python context instance name and al...https://hephaistos.lpp.polytechnique.fr/redmine/issues/5042015-09-21T13:27:42ZAlexis Jeandet
<p>The best solution would be to remove this method from python context since it's internal stuff.</p> SocExplorer - Bug #503 (New): closeMe() method doesn't remove plugin from python context.https://hephaistos.lpp.polytechnique.fr/redmine/issues/5032015-09-21T13:25:19ZAlexis JeandetSocExplorer - Bug #498 (New): Timecode + timegen en mode router non fonctionnelshttps://hephaistos.lpp.polytechnique.fr/redmine/issues/4982015-09-18T11:35:50ZVeronique bouzid
<p>Timecode:<br />Revoir la fonction SendOneTimecode</p>
<p>Timegen:<br />la procedure manuelle d'utilisation de Timegen fonctionne.<br />Investiger pourquoi en automatique le mode router ne fonctionne pas.</p> Solar Orbiter LFR - Bug #471 (New): Bistream 1.1.85 issueshttps://hephaistos.lpp.polytechnique.fr/redmine/issues/4712015-07-17T09:49:53ZAlexis JeandetSolar Orbiter LFR - Bug #470 (Resolved): Bistream 1.1.85 snapshots non généréshttps://hephaistos.lpp.polytechnique.fr/redmine/issues/4702015-07-16T15:31:27ZAlexis Jeandet
<p>Les snapshots ne sont plus générés si la période de génération est changée.<br />Le comportement est observé avec les softs de vol 3.0.0, 3.0.3 et 3.0.8.<br />Avec le bistream 1.1.83c, ce comportement n'est pas observé, les snapshots sont générés de manière nominale.</p>
<p>D'autre part sur le bitstream 1.1.85, le coarstime ne semble pas s'incrémenter correctement, à chaque transition il passe rapidement par de mauvaises valeurs avant de se stabiliser sur la bonne.<br />Par exemple pour passer de 0x005 à 0x006 il va passer par 0x001 0x004 pendant quelques fractions de secondes avant de se stabiliser à 0x006.</p> LFR-FSW - Bug #383 (Feedback): petite irrégularité de temps pour les CWF à F1 ?https://hephaistos.lpp.polytechnique.fr/redmine/issues/3832015-04-13T08:54:29Zthomas chust
<p>Point similaire au point <a class="issue tracker-1 status-3 priority-2 priority-default" title="Bug: petite irrégularité de temps pour les CWF à F2 ? (Resolved)" href="https://hephaistos.lpp.polytechnique.fr/redmine/issues/382">#382</a> mais avec les CWF à F1:</p>
<p>Le cas considéré ici est un ctc-5: balayage en fréquence où on enregistre 104 fichiers CWF à F1 comprenants chacun 320 paquets de 336 échantillons. Voir les fichiers joints.</p>
<p>Avec la configuation FSW = 2.0.2.3 et VHDL = 1.1.68 on observe:<br />- les temps des paquets de 336 échantillons sont bien séparés de 5376 2^-16 s [336 / 4096 / 2^-16] à 2^-16 s près,<br />- SAUF de temps à autre entre des paquets p et p+1 où l'on observe la valeur de 5474 et où l'entier p a la caractéristique d'être un multiple de 8.</p>
<p><strong>Conclusion: la datation des premiers paquets de chaque buffer (2688=8*336) est de temps à autre légèrement erronée, de l'ordre de 2 fine times (~ 30 micro secondes) ?</strong></p> LFR-FSW - Bug #382 (Resolved): petite irrégularité de temps pour les CWF à F2 ?https://hephaistos.lpp.polytechnique.fr/redmine/issues/3822015-04-10T22:39:06Zthomas chust
<p>Des tests ont été fait avec pas mal de fichiers durant les procédures automatiques de calibration/étalonnage.<br />Le cas considéré ici est un ctc-6: balayage en fréquence où on enregistre 96 fichiers CWF à F2 comprenants chacun 24 paquets de 336 échantillons. Voir les fichiers joints.</p>
<p>Avec la configuation FSW = 2.0.2.3 et VHDL = 1.1.68 on observe:<br />- les temps des paquets de 336 échantillons sont bien séparés de 86016 2^-16 s [336 / 256/ 2^-16] à 2^-16 s près<br />- SAUF entre le 8ème et 9ème paquet où on observe des valeurs allant de 86003 à 86006 fine times,<br />- et SAUF entre le 16ème et le 17ème paquet où on observe la même irrégularité.</p>
<p>Si j'ai bien compris, 8 paquets correspond à un buffer plein (2688=8*336), et <strong>il semblerait que la datation du premier paquet de chaque buffer est légèrement erroné, de l'ordre de 10 fine times (~ 150 micro secondes) ?</strong></p> Solar Orbiter LFR - Bug #301 (New): Réception des harnais de tests STAEhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/3012014-12-19T12:23:43ZVincent Leray
<p>STAE a livré ce matin les harnais (LFR 701H à LFR 704H, LFRSPWH), ainsi que la boite éclatée 21points et les cavaliers.<br />La boite éclatée est OK.<br />Les deux harnais LFR703H ont été retournés car mauvais genre de connecteur coté 9 points.<br />Les deux harnais LFR704H montrent une inversion sur le 1V5 (mesure donne <del>2,12V, double contrôle Paul/Vincent) -</del>> Surtout à ne pas utiliser (câbles identifiés et scellés). STAE est alerté.</p>
<p>Les autres harnais doivent être contrôlés.</p> LFR-FSW - Bug #250 (Feedback): temps des ASM pas bien définihttps://hephaistos.lpp.polytechnique.fr/redmine/issues/2502014-10-16T14:53:07Zthomas chust
<p>Observation de 52 ASM_F0 enregistrée toute les 4 s montre des temps pas identiques entre les paires de paquets (44+44=88) + une période de 4 secondes peu précise (imprécision ~0.1 s) :</p>
<p>time2 - time = -0.020156860 0.011550903 0.011184692 -0.0041961670 -0.0047454834 -0.0044250488 -0.019683838<br /> 0.011184692 -0.0041961670 0.011550903 -0.0041961670 0.011154175 0.011154175 0.011566162 0.011108398<br /> -0.0045318604 -0.019699097 -0.019683838 -0.020126343 -0.0042114258 -0.020156860 -0.019699097 -0.020126343<br /> -0.020095825 -0.020065308 0.011352539 0.011550903 -0.026458740 -0.020065308 -0.019699097 -0.0041961670<br /> -0.0041961670 -0.0041961670 0.011566162 0.011138916 0.011077881 -0.0045318604 -0.020156860 0.011550903<br /> -0.0041961670 0.011093140 0.011550903 0.011123657 0.011169434 0.011184692 -0.0041961670 -0.020004272<br /> -0.019790649 0.011550903 -0.019699097 -0.0041961670 -0.0041656494</p>
<p>time = 0.0000000 4.0883179 8.1497498 12.199188 16.277664 20.342529 24.385040<br /> 28.462250 32.511978 36.588318 40.638199 44.712173 48.774673 52.838242 56.899628<br /> 60.966888 65.009949 69.072952 73.134003 77.214767 81.281235 85.322617 89.384018<br /> 93.446564 97.509140 101.60860 105.68166 109.78070 113.75912 117.82260 121.90385<br /> 125.96486 130.02734 134.11949 138.18091 142.23433 146.30894 150.35422 154.43175<br /> 158.48064 162.54700 166.61948 170.68089 174.74348 178.80600 182.85767 186.91600<br /> 190.97850 195.08821 199.10388 203.18507 207.24611</p>
<p>Config de l'observation:</p>
<p>EM1 <br />FSW : 2.0.1.0 <br />VHDL : 1.1.26 <br />SGSE : 2.0.0.0 <br />SocExplorer : 0.2.2</p>
<p>MODE = SBM1 <br />NM: NW=2048, SWF_P=16, ASM_P=4, BP_P0=4, BP_P1=20, LONG_F3=1 <br />SBM1: BP_P0=1, BP_P1=5 <br />BW=1, R0=1, R1=1, SP0=0, SP1=0 <br />=> fichier 2014_9_29-15_14_12_packet_record</p> Solar Orbiter LFR - Bug #240 (Resolved): Liste de problèmes observés sur le LFR FGSEhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/2402014-09-18T07:57:45ZVincent Leray
<p>Lors de l'utilisation du FGSE LFR au CNES quelques dysfontionnements ou incompréhensions dans l'utilisation sont remontés:</p>
<p>Extrait mail CNES (Cf PJ):<br />Le foreign LFR plante 9 fois sur 10 lors du lancement<br />Les courbes LFR ASM ou SWF s’affichent en superposées lors de leur sélection.<br />Nous n’arrivons pas à faire fonctionner la fonction FFT, mode d’emploi ?</p>
<p>A cela 2 Ncs ont été ouvertes:<br />NC 93 concernant l'enregistrement des ASM à F1 et F2 sur le FGSE<br />NC 102 concernant les labels des colonnes des ASMs lors d'un export.</p>
<p>Existe t il des mises à jours du FGSE prévues pour corriger ces points?</p> SocExplorer - Bug #107 (New): SocExplorerPlot python module doesn't work on Windowshttps://hephaistos.lpp.polytechnique.fr/redmine/issues/1072014-03-30T15:42:52ZAlexis Jeandet
<p>The SocExplorerPlot module crashes SocExplorer when you try to instantiate it.</p>