LFR-FSW: Issueshttps://hephaistos.lpp.polytechnique.fr/redmine/https://hephaistos.lpp.polytechnique.fr/redmine/redmine/favicon.ico?15080976012023-06-14T15:32:11ZRedmine
Redmine Task #4115 (In Progress): Mise à jour DP R3.3 suite à émission des RIDS par le CNEShttps://hephaistos.lpp.polytechnique.fr/redmine/issues/41152023-06-14T15:32:11Zbruno katra
<p>Mail Dixon du 13/06/2023</p>
<p>Bonjour,</p>
<p>Vous trouverez en PJ mes FEPS.</p>
<p>Il y a pas mal de remarques (dont des coquilles).<br />On peut prévoir un point ensemble pour les parcourir et bien identifier les problèmes "réels".</p>
<p>Bonne journée,</p>
<p>Charles.</p>
<p>(fichier excel attaché)</p>
<hr />
<p>Fichiers mis à jour pour relivraison :</p>
<p>- SCF (00037) (pas de chgt de version) --> DP mis à jour<br />- SPAMR (00036) (pas de chgt de version) --> DP mis à jour<br />- SPC 00276 (pas de chgt de version) --> DP mis à jour<br />- SGSE CDL (00205) (pas de chgt de version) --> DP mis à jour<br />- spec LFR (00003) (pas de chgt de version) --> DP mis à jour<br />- SRS (pas de chgt de version) --> DP mis à jour<br />- SPC-277 (pas de chgt de version) --> DP mis à jour<br />- SDD (00039) (pas de chgt de version) --> DP mis à jour<br />- NTT-271 (pas de chgt de version) --> DP mis à jour<br />- SUM-123 (pas de chgt de version) --> DP mis à jour<br />- RPT-199 (pas de chgt de version) --> DP mis à jour<br />- RPT-168 (pas de chgt de version) --> DP mis à jour<br />- RPT- 95 (pas de chgt de version) --> DP mis à jour<br />- NTT124 (pas de chgt de version) --> DP mis à jour<br />- SVS-00066 (pas de chgt de version) --> DP mis à jour<br />- CPS (00191) --> DP mis à jour<br />- document de Thomas RPW-MEB-LFR-SPC-00275 --> DP mis à jour</p> Task #3991 (In Progress): Mise en place d'un protocole de test pour la validation de la correctio...https://hephaistos.lpp.polytechnique.fr/redmine/issues/39912022-10-21T11:47:10Zbruno katra
<p>Le bug est détaillé là : <a class="issue tracker-1 status-3 priority-2 priority-default" title="Bug: Moyennage des SM erroné pour F0 et F1 dans FSW <=3.2.0.24 (Resolved)" href="https://hephaistos.lpp.polytechnique.fr/redmine/issues/3821">#3821</a></p>
<p>VALIDATION : j'ai créé points à points des signaux personnalisés qui sont ensuite générés par les ANALOG DISCOVERY. En utilisant les scripts pour la validation de PAS : ces signaux sont triggés de façon à être synchrones avec l'acquisition des ASM. Je génére ainsi des +/- courtes impulsions à une fréquence définie que je peux faire coïncider temporellement avec une ou plusieurs des 8 SM calculés à bord.</p>
<p>En comparant ensuite 3.2.0.24 VS 3.3.0.x : on peut caractériser si toutes les SM sont bien prises en compte ou bien seulement la première comme avant.</p> Task #3985 (Feedback): Test du chargement forcé des KCOEFF par défaut : écrasement des KCOEFF à bordhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/39852022-10-12T15:44:31Zbruno katra
<p>Demande de Thomas (mails du 11/10/2022) :</p>
<p>Hello Bruno,</p>
<p>As-tu le fichier des kcoeff correspondant au kcoef par defaut ? On pourrait déjà commencer par vérifier que cela marche, comme avec les valeurs par défaut (cohérence entre les SWF et les ASM). Non ?</p>
<p>Thomas</p>
<p>Voici ce que j'enverrais à Diane. C'est dans le même format que le fichier que je t'avais fourni pour le cas des kcoeff unitaires. Par rapport à ce que j'avais déjà produit au moment de la définition des kcoeff par défaut pour Alexis (fichiers datant du 2021-09-08), j'ai juste rajouté 3 décimales supplémentaires.</p>
<p>Thomas</p> Bug #3936 (In Progress): Comparaison/validation FSW 3.2.0.24 vs 3.3.0.7 avec matrices unitaires.https://hephaistos.lpp.polytechnique.fr/redmine/issues/39362022-03-15T14:56:30Zbruno katra
<p>En relation avec <a class="issue tracker-4 status-2 priority-2 priority-default" title="Task: Matrices de passage par défaut pour les ASM : à valider (In Progress)" href="https://hephaistos.lpp.polytechnique.fr/redmine/issues/3877">#3877</a> il est pertinent de vérifier la cohérence entre 3.2.0.24 vs (3.3.0.7 avec matrices unitaires). Les comportements attendus doivent être similaires entre les 2 (à la différence près de la correction de la moyenne des ASM qui ne doit pas trop se voir dans le cadre de signaux constants).</p>
<p>J'ai rejoué les runs PREL-08 ( <a class="issue tracker-4 status-2 priority-2 priority-default" title="Task: Matrices de passage par défaut pour les ASM : à valider (In Progress)" href="https://hephaistos.lpp.polytechnique.fr/redmine/issues/3877">#3877</a> ) mais en 3.2.0.24, les datadumps sont ici :<br /><a class="external" href="https://ao.lpp.polytechnique.fr/index.php/apps/files/?dir=/LFR/3.2.0.24/PREL-09&fileid=2507041">https://ao.lpp.polytechnique.fr/index.php/apps/files/?dir=/LFR/3.2.0.24/PREL-09&fileid=2507041</a></p> Task #3897 (In Progress): Faire un test avec les matrices de chgt de repère/calibration mises à ...https://hephaistos.lpp.polytechnique.fr/redmine/issues/38972021-11-18T08:32:29Zbruno katra
<p>Afin de valider la non régression au niveau des signaux (amplitude et forme).<br />Thomas a envoyé le tableau 32x36</p> Task #3877 (In Progress): Matrices de passage par défaut pour les ASM : à valider https://hephaistos.lpp.polytechnique.fr/redmine/issues/38772021-09-17T09:52:23Zbruno katra
<p>Oui c'est exactement ça, dans le dernier où avant dernier commit tu trouveras les matrices par défaut générées avec les valeurs de Thomas.</p>
<p>Envoyé depuis mon smartphone Xperia de Sony</p>
<p>---- Bruno KATRA a écrit ----</p>
<p>Salut Alexis et Thomas.</p>
<p>J'ai pensé à un truc : qu'en est-il des KCOEFF par défaut au démarrage</p>
<p>de LFR?</p>
<p>De mémoire, avec l'ancienne implé : tous les coeff étaient à 1.0 au</p>
<p>démarrage.</p>
<p>Mais maintenant que les KCOEFF ne sont plus des KCOEFF mais les</p>
<p>paramètres permettant de calculer les matrices de passage pour les ASM,</p>
<p>je suppose qu'il existe des matrices par défaut au démarrage de LFR et</p>
<p>que donc les KCOEFF par défaut ne sont pas des 1.0 mais bien des valeurs</p>
<p>différentes?</p>
<p>Merci</p>
<p>-------------------------------------------------------------<br />Mapping Discospace :</p>
<p>Analog Discovery 1 : E1/E2<br />Analog Discovery 2 : B1/B2<br />Analog Discovery 3 : B3<br />-------------------------------------------------------------</p> Bug #3851 (Feedback): bruit périodique à F1 vu sur les BPs et ASM mais pas sur les SWFhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/38512021-05-25T09:11:43Zthomas chust
<p>Un truc bizarre/paradoxal depuis le début de la mission: on observe sur les produits spectraux à F1 (BP2, BP1 et ASM) un bruit large bande qui module régulièrement en intensité sur une période de ~3h. Parfois cette modulation est accentuée soudainement une ou deux fois puis retour à la "normale". Alors que sur les produits SWF il n'y a rien à voir (semble-t-il) ?</p>
<p>1) Exemples des 18 et 19 mai 2020 (on voit l'accentuation le 18 mai associée à une hausse du bruit global visible sur les SWF mais sans modulation)</p>
<p>2) Exemple du 7 février 2021 (ASM toutes les 52 s et SWF toutes les 30 s)</p>
<p>Il faudrait que j'intègre sur les fréquences les SWF pour obtenir la même résolution en fréquences que les BP pour être sûr que cette modulation n'est pas cachée dans les SWF. Mais j'y crois pas ... Du coup il y a peut-être quelque chose à voir du coté du FSW dans sa façon de faire les moyennes ?</p> Bug #3821 (Resolved): Moyennage des SM erroné pour F0 et F1 dans FSW <=3.2.0.24https://hephaistos.lpp.polytechnique.fr/redmine/issues/38212021-03-29T09:26:52Zbruno katra
<p>Pour F0 et F1, on moyenne 8 SM pour faire une ASM. La boucle est fausse : Seul la première SM est comptabilisée et moyennée (*8/8).</p>
<p><a class="external" href="https://github.com/LaboratoryOfPlasmaPhysics/LFR_Flight_Software/blame/729417ab5a3e7e5854a6665a3662e2b8ebc7756e/header/processing/fsw_processing.h#L206">https://github.com/LaboratoryOfPlasmaPhysics/LFR_Flight_Software/blame/729417ab5a3e7e5854a6665a3662e2b8ebc7756e/header/processing/fsw_processing.h#L206</a></p>
<p>Message de Alexis :<br /><pre>
"Ce qui me choque dans la ligne en question, c'est qu'on a une boucle
sur k et qu'on somme N fois la même composante de la même matrice selon
que incomingSMIsValid[k] == MATRIX_IS_NOT_POLLUTED.
Je trouve ça étrange."
</pre></p>