INSTRU: Issueshttps://hephaistos.lpp.polytechnique.fr/redmine/https://hephaistos.lpp.polytechnique.fr/redmine/redmine/favicon.ico?15080976012023-03-09T13:24:21ZRedmine
Redmine LFR-FSW - Task #4048 (Closed): Datapack FSW 3.3 : mises à jour SVerRhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/40482023-03-09T13:24:21Zbruno katra
<p>Cet issue rassemble les mises à jour/ajouts à prévoir dans le SVerR :</p> LFR-FSW - Task #4047 (Closed): Datapack FSW 3.3 : mises à jour SValRhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/40472023-03-09T13:23:09Zbruno katra
<p>Cet issue rassemble les mises à jour/ajouts à prévoir dans le SValR :</p> LFR-FSW - Task #4036 (Closed): Datapack FSW 3.3 : mises à jour CPShttps://hephaistos.lpp.polytechnique.fr/redmine/issues/40362023-02-22T10:43:43Zbruno katra
<p>Cet issue rassemble les mises à jour/ajouts à prévoir dans le CPS:</p>
<p>- Formules BP page 15 et plus</p> LFR-FSW - Task #4026 (Closed): Analyse GCOVhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/40262023-02-13T10:10:15ZVeronique bouzid
<p><strong>Début de la couverture de Test en 3.3.0.16</strong></p>
<p>Une quinzaine de tests ont été joués. Avant de pousser plus loin, il faudrait traiter ses tests et évaluer la couverture atteinte.</p>
<p>Sur pc-solar3, dans le répertoire /opt/VALIDATION_R3.3/GCOV/3.3.0.16, voici les fichiers à traiter:</p>
<p>gcov_out_2023-02-13 09:10:52.635355.txt<br />gcov_out_2023-02-13 09:12:32.358845.txt<br />gcov_out_2023-02-13 09:15:53.533775.txt<br />gcov_out_2023-02-13 09:17:58.219268.txt<br />gcov_out_2023-02-13 09:23:23.893858.txt<br />gcov_out_2023-02-13 09:33:27.972367.txt<br />gcov_out_2023-02-13 09:37:47.458757.txt<br />gcov_out_2023-02-13 09:39:33.827127.txt<br />gcov_out_2023-02-13 09:41:52.977440.txt<br />gcov_out_2023-02-13 10:23:51.069120.txt (SVS-0002 à SVS-0010 + SVS-0059)</p> LFR-FSW - Task #4017 (Closed): Datapack FSW 3.3 : mises à jour SPEC LFRhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/40172023-01-25T13:26:08Zbruno katra
<p>Cet issue rassemble les mises à jour/ajouts à prévoir dans la spec LFR :</p>
<p>- Décrire (schéma?) : le dataflow de l'application des différents masques et traitements : RW filter, PAS, FBINS MASKS, 'KCOEFF'<br />- Mise à jour du §2.4.3 sur les ASM : expliquer comment sont calibrées les ASM directement à bord à partir de FSW 3.3<br />- Mise à jour des formules BP §2.4.4 <br />- Décrire le nouveau comportement du calcul des ASM avec la calibration à bord<br />- Décrire le nouveau mécanisme de mise à jour des KCOEFF et déclenchement de l'interpolation</p> LFR-FSW - Task #4016 (Closed): Datapack FSW 3.3 : SRShttps://hephaistos.lpp.polytechnique.fr/redmine/issues/40162023-01-25T08:22:38Zbruno katra
<p>Cet issue rassemble les mises à jour/ajouts à prévoir dans le SRS :</p>
<p>- <del>Dans le cas des diverses fonctions de filtrages (RW, FBINS, KCOEFF, PAS) : il faudra expliquer dans les req à quel moment du dataflow elles sont appliquées et/ou ref. au SDD</del></p>
<p>- <del>page 16, note mise à jour en dessous tableau changement de mode : mettre la bonne référence à RD02 ou RD 03 pour explication mécanisme interpolation KCOEFF</del></p>
<p>- <del>Le fait que la 36eme TC est acquittée APRES que l'interpolation soit faite</del><br /> fait dans req-5583 + spec LFR<br />- <del>expliquer en intro le changement de sens des KCOEFF qui sont maintenant des matrices de cal</del> fait dans req-5583 + ref à spec LFR<br /><del><br /><a class="issue tracker-4 status-5 priority-1 priority-lowest closed" title="Task: Datapack FSW 3.3 : expliquer initialisation des matrices au boot de LFR (Closed)" href="https://hephaistos.lpp.polytechnique.fr/redmine/issues/3915">#3915</a> à mettre dans un req ou note</del> fait dans SRS req sous forme de note</p> LFR-FSW - Task #4014 (Closed): Datapack FSW 3.3 : NCR corrigées à reporter https://hephaistos.lpp.polytechnique.fr/redmine/issues/40142023-01-19T14:58:35Zbruno katra
<p>Il y a un document avec les NCR en cours ou corrigées dans cette version, je ne sais plus lequel mais il faudra y reporter :<br />- Bug ASM<br />- numéro de paquet 1/2 - 2/2 dans le KCOEFF_DUMP corrigé (bug signalé par Xavier en 2021)</p> LFR-FSW - Task #4008 (Closed): Mettre à jour CalibrationMatrices_TC_TM.html (document qui décrit ...https://hephaistos.lpp.polytechnique.fr/redmine/issues/40082022-12-28T12:12:53Zbruno katra
<p>Il faut mettre à jour ce document (en pj) pour la partie TM_LFR_KCOEFF_DUMP car suites aux réunions avec le LESIA il a été décidé de garder la structure des paquets KCOEFF_DUMP comme en 3.2.0.24 : le dump contient 26 ou 13 blocs du type :<br /><strong>1 x UINT16 (KCOEFF FREQ INDEX)</strong> + 32 x FLOAT32 (valeurs KCOEFF du KCOEFF FREQ INDEX correspondant).<br />Actuellement le documents décrit un stream de floats (§ TM DUMP KCOEF format à la fin du document).</p>
<p>D'ailleurs question : il aurait été plus lisible de mettre le numéro de BIN directement dans le UINT16 (16, 24, 32, ... pour F0 et 5,13,21,... pour F0 par exemple) au lieu d'un index qui commence à 0, non?</p> LFR-FSW - Task #3987 (Closed): Tests avec KCOEFF distordushttps://hephaistos.lpp.polytechnique.fr/redmine/issues/39872022-10-14T07:58:07Zbruno katra
<p>Salut Bruno,</p>
<p>Voici un nouveau jeu de kcoeff pour un test2 (quand tu auras le temps ). Par rapport au test1 (kcoeff "defaut"), j'ai distordu tous les kcoeff de façon arbitraire, pour produire des différences assez visibles.</p>
<p>a+</p>
<p>Thomas</p> LFR-FSW - Task #3944 (Closed): Modif de la TC_LOAD_KCOEFF : ICD + LFR FSWhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/39442022-03-31T08:44:51Zbruno katra
<p>Suite à la teleconf du 29/03/22, proposition au LESIA :</p>
<p>Salut à tous!</p>
<p>Comme discuté durant la teleconf, j'ai préparé un draft avec les nouveaux labels pour la TM_KCOEFF_DUMP.</p>
<p>Du coup, on avait aussi dit qu'on mettait les labels à jour pour la TC correspondante tant qu'à faire pour être symétrique avec ceux de la TM.</p>
<p>Pour rappel : dans l'implémentation actuelle le tableau complet de KCOEFF c'est 36 groupes de 32 floats. Thomas envoie un tableau 36 lignes x 32 colonnes à Diane qui construit les 36 TC afférentes.</p>
<p>Pour la nouvelle implémentation, afin de ne pas toucher à la TC, Thomas et Alexis utilisent pour la TC certains des floats à des fins différentes en fonction du paramètre KCOEFF frequency. C'est un arrangement un peu complexe mais qui permettait de conserver toute la partie TC identique.</p>
<p>Pas évident donc d'harmoniser les labels de ces champs qui sont soit utilisés soit SPARE.</p>
<p>Par contre, la teleconf de mardi nous a apporté un nouvel éclairage côté contrainte IDB qui est de mettre des champs en SPARE afin de conserver la structure et ne pas modifier l'IDB (ce que l'on va faire pour la TM).</p>
<p>En faisant cela pour la TC actuelle, on pourrait réarranger le placement de nos floats afin de le simplifier sans toucher à l'IDB.</p>
<p>Cela implique :</p>
<p>- Côté LPP : une modif du FSW de LFR (qui va simplifier le traitement de la TC)</p>
<p>- Côté LESIA : Diane devrait générer 39 TC au lieu de 36 TC (Thomas lui enverrait un tableau 39x32 au lieu de 36x32)</p>
<p>Hormis la contrainte opérationnelle, pouvez-vous aussi nous confirmer que cela est possible côté DPU? Les TC à exécuter sont-elles stockées à bord ? Y aurait-il la place pour 3 TC de plus?</p>
<p>Si c'est bon pour vous on part là dessus sinon on laissera nos labels génériques tout moches.</p>
<p>Merci d'avance de votre aide</p>
<p>Bruno</p> LFR-FSW - Task #3922 (Closed): Datapack FSW 3.3 : mises à jour SUMhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/39222022-01-18T23:35:36Zbruno katra
<p>Cet issue rassemble les mises à jour/ajouts à prévoir dans le SUM :</p>
<p>- TM_INCONSISTENT : le champs qui contient la valeur fausse ne fait que 1 octet alors que certains paramètres qui devrait y aller en font 2 + si plusieurs paramètres faux, le champs ne contient que le dernier (voir explications/tests Véro dans <a class="issue tracker-1 status-5 priority-2 priority-default closed" title="Bug: Ordre de vérification des parametres de TC_LFR_LOAD_NORMAL_PAR (Closed)" href="https://hephaistos.lpp.polytechnique.fr/redmine/issues/482">#482</a> )<br />==> <strong>prévenir Plasson pour suivi</strong></p>
<p>- <del>Le fait que la 36eme TC est acquittée APRES que l'interpolation soit faite</del></p>
<p>- <del>§5.4b : à mettre à jour</del></p>
<p>- <del>Ajouter ref aux résultats de la calibration SCM à la fin</del> FAIT</p> LFR-FSW - Task #3921 (Closed): Datapack FSW 3.3 : mises à jour SDDhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/39212022-01-18T23:30:39Zbruno katra
<p>Cet issue rassemble les mises à jour/ajouts à prévoir dans le SDD :</p>
<p>- <del>Task DUMB : en FSW>= 3.3.0.5 elle est désactivée pour les releases de vol = désactivée automatiquement par les directives de compilation quand les printf sont désactivés. En effet, Alexis s'est rendu compte que cette tâche n'est appelée que pour forwarder des printf, donc inutile en vol.</del> voir note # 4</p>
<p>BKA : REQ-LFR-SRS-5703_Ed1 à mettre à jour</p> LFR-FSW - Task #3915 (Closed): Datapack FSW 3.3 : expliquer initialisation des matrices au boot d...https://hephaistos.lpp.polytechnique.fr/redmine/issues/39152021-12-08T12:33:42Zbruno katra
<p>Le comportement de l'init des matrices au boot devra être détaillé dans SDD et/ou spec LFR :</p>
<p>- Les matrices par défaut ne sont pas calculées dynamiquement au boot de LFR pour ne pas charger le CPU, elles ont été précalculée statiquement et sont dans un tableau d'init dans le fichier calibration_matrices.c<br />- voir <a class="issue tracker-3 status-9 priority-2 priority-default closed" title="Support: Question sur la dernière matrice des KCOEFF... (Stalled)" href="https://hephaistos.lpp.polytechnique.fr/redmine/issues/3914">#3914</a> : les dernières matrices de chaque composante et freq sont des matrices nulles car elles ne servent qu'à faire l'interpolation, or comme ici tout est précalculé pas besoin.</p> LFR-FSW - Task #3876 (Closed): Datapack FSW 3.3 : TC_LFR_KCOEFF acceptée uniquement en mode STDBYhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/38762021-09-17T09:49:04Zbruno katra
<p>Hello,</p>
<p>Je propose de retourner une TM_LFR_TC_NOT_EXECUTABLE si je reçois une<br />TC LOAD K COEF et que je suis pas en mode standby. Ce n'était pas le<br />cas avant et ça aurait dû l'être.</p>
<p>A plus,<br />Alexis.</p>
<p>Documents impactés :<br />- spec LFR (pas sûr)<br />- SRS (tableau)<br />- SVS et tests associés à modifier <br />- User manual : tableau des commandes</p> LFR-FSW - Task #3875 (Closed): Datapack FSW 3.3 : comportement du FSW lors de la reception d'1 TC...https://hephaistos.lpp.polytechnique.fr/redmine/issues/38752021-09-17T09:46:44Zbruno katra
<p>Il faudra documenter ce comportement : le calcul d'interpolation des matrices de passages des ASM est déclenché lors de la réception des KCOEFF de la 36eme fréquence, elle doit donc être envoyée en dernier. Aussi il faut considérer qu'une opération de mise à jour des KCOEFF n'a de sens maintenant que si les 36 commandes sont envoyées, pas de mise à jour partiel des kcoeff.</p>
<p>Documents impactés :<br />- Spec LFR<br />- SRS<br />- SVS : il faut mettre à jour les tests pour valider ce comportement<br />- User manual : très important, il faudra y décrire le mode d'emploi et la façon de mettre à jour les KCOEFF + avertir le LESIA d'y prêter attention pour leurs tests.</p>