INSTRU: Issueshttps://hephaistos.lpp.polytechnique.fr/redmine/https://hephaistos.lpp.polytechnique.fr/redmine/redmine/favicon.ico?15080976012023-02-01T08:14:05ZRedmine
Redmine LFR-FSW - Bug #4022 (Closed): Validation BP des modes SBM1 et SBM2https://hephaistos.lpp.polytechnique.fr/redmine/issues/40222023-02-01T08:14:05Zbruno katra
<p>Salut Bruno,</p>
<p>Je viens de de comparer les BP2 à F0 en SBM1 avec les ASM à F0 en NM, du moins les termes diagonaux (les AUTO). J'ai des résultats du même ordre (écart de plusieurs dizaines de %) donc pas aberrant. En fait je réalise que pour ce teste et être plus précis (comparer des signaux forts et non des niveaux de bruit), il faudrait avoir injecter dans la gamme de fréquence F0 et non F1. As-tu encore le temps de refaire ce test SBM1 en balayant les fréquence F0 ?</p>
<p>Et en fait même problème pour le test SBM2: il faudrait balayer les fréquences F1 et F0 ...</p>
<p>Désolé pour ce contre temps</p>
<p>Thomas</p> LFR-FSW - Bug #4021 (Closed): FSW 3.3.0.14 : Valeurs moyennage potentiel s/c dans HK dupliquées e...https://hephaistos.lpp.polytechnique.fr/redmine/issues/40212023-01-30T15:34:47Zbruno katra
<p>Dans FSW 3.3.0.14 : le moyennage dans les HK de E1 et E2 est identique alors que des signaux différents sont appliqués. En fait peu importe ce que l'on met comme signal sur E1 ses valeurs sont identiques à celle de E2. Si on change le signal sur E2, E1 change aussi pour être =E2.</p>
<p>Dans la capture en PJ (HKmeaning3.3.0.14) on injecte des signaux différents sur E1 et sur E2 et on voit que la réponse est la même dans les HK.</p> LFR-FSW - Bug #4020 (Closed): FSW 3.3.0.13 crashe avec certaines combinaisons de paramètres pour ...https://hephaistos.lpp.polytechnique.fr/redmine/issues/40202023-01-28T17:14:53Zbruno katra
<p>J'ai testé 29 combinaisons de paramètres pour PAS_FILTER plusieurs fois pour essayer de déterminer un critère de reproductibilité.</p>
<p>Les paramètres PAS par défaut sont pour rappel :<br />sy_lfr_pas_filter_modulus = 4<br />sy_lfr_pas_filter_tbad = 1<br />sy_lfr_pas_filter_offset = 0<br />sy_lfr_pas_filter_shift = 0.5</p>
<p><ins>Pour certaines combinaisons :</ins> * le FSW crashe (plus de HK) dès que des ASM doivent être produites pour être envoyées*</p>
<p><ins>Voici les résultats :</ins></p>
<ul>
<li>PARAMETRES PAS PAR DEFAUT : OK, pas de carsh</li>
<li>TOUTES LES COMBINAISONS AVEC sy_lfr_pas_filter_modulus = sy_lfr_pas_filter_tbad = 4 : NOK, crashe systématiquement dès que les ASM doivent être envoyées (testé avec ASM à 4/8/12/16s)</li>
<li>COMBINAISONS AVEC sy_lfr_pas_filter_modulus = 8 et sy_lfr_pas_filter_tbad = 4 : POK, crashe des fois mais pas tout le temps, en fonction des paramètres précédemment entrés j'ai l'impression, reproductibilité aléatoire mais toujours quand les ASM doivent être envoyées (testé avec ASM à 4/8/16s)</li>
<li>TOUTES LES AUTRES COMBINAISONS testées : OK, pas de crash</li>
</ul>
<ul>
<li>Les crashs ne se produisent que si le filtrage est activé (sy_lfr_pas_filter_enabled = 1 ) = si on envoie les combinaisons qui font crasher mais sans activer le filtrage : pas de crash</li>
</ul>
<ul>
<li>Test refait en 3.2.0.24 : pas de crash</li>
</ul> LFR-FSW - Bug #4018 (Closed): FSW 3.3.0.13 instrumenté pour mesure du SCRUBBING : le compteur res...https://hephaistos.lpp.polytechnique.fr/redmine/issues/40182023-01-27T11:14:28Zbruno katra
<p>On utilise dans cette version spécifique du FSW la valeur HK de la version FPGA pour compter les cycles de scrubbing.</p>
<p>En FSW 3.3.0.13 : on voit bien la valeur à 0 au début comme attendu mais elle ne s'incrémente jamais, testé en STANDBY et NORMAL. Pour comparaison en 3.2.0.24 on s'oncrémentait de 1 toutes les 3s environ en STDBY.</p> LFR-FSW - Bug #4015 (Closed): HK_LFR_ME_CNT ne s'incremente pas lors du passage à zero du compteu...https://hephaistos.lpp.polytechnique.fr/redmine/issues/40152023-01-24T11:00:35ZVeronique bouzid
<p>Le test SVS-0026 doit vérifier le requirement suivant<br />All the counters (error counter, packet counter, etc) managed by LFR FSW shall restart at 0 when tehy reached their maximun value.</p>
<p>Le script qui teste le compteur HK_LFR_DPU_SPW_RX_TOO_BIG envoie 257 Tc générant une erreur. Le compteur valide bien le requirement et on voit parfaitement le passage à zero.</p>
<p>Un autre compteur nommé HK_LFR_ME_CNT comptabilise les erreurs de type medium. HK_LFR_DPU_SPW_RX_TOO_BIG fait partie de ce type d erreur et donc on s'attend à la fin du test à obtenir<br />HK_LFR_ME_CNT=257. Ce n est pas le cas il manque 1.</p>
<p>Ici un extrait des valeurs de ces 2 compteurs (fichir verif_count.txt)<br />11:47:45.222921 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=0 HK_LFR_DPU_SPW_RX_TOO_BIG=0<br />11:47:46.242728 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=1 HK_LFR_DPU_SPW_RX_TOO_BIG=1<br />11:47:47.222395 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=1 HK_LFR_DPU_SPW_RX_TOO_BIG=1<br />11:47:48.223832 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=1 HK_LFR_DPU_SPW_RX_TOO_BIG=1<br />11:47:49.222892 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=1 HK_LFR_DPU_SPW_RX_TOO_BIG=1<br />11:47:50.223058 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=2 HK_LFR_DPU_SPW_RX_TOO_BIG=2<br />----</p>
<p>12:04:48.226406 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=255 HK_LFR_DPU_SPW_RX_TOO_BIG=255<br />12:04:49.225973 HK_LFR_LE_CNT=1 <strong>HK_LFR_ME_CNT=255 HK_LFR_DPU_SPW_RX_TOO_BIG=0</strong><br />12:04:50.225914 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=255 HK_LFR_DPU_SPW_RX_TOO_BIG=0<br />12:04:51.226438 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=255 HK_LFR_DPU_SPW_RX_TOO_BIG=0<br />12:04:52.225955 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=255 HK_LFR_DPU_SPW_RX_TOO_BIG=0<br />12:04:53.225879 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=256 HK_LFR_DPU_SPW_RX_TOO_BIG=1<br />12:04:54.22646 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=256 HK_LFR_DPU_SPW_RX_TOO_BIG=1<br />12:04:55.225976 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=256 HK_LFR_DPU_SPW_RX_TOO_BIG=1<br />12:04:56.225969 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=256 HK_LFR_DPU_SPW_RX_TOO_BIG=1<br />12:04:57.22624 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=256 HK_LFR_DPU_SPW_RX_TOO_BIG=1<br />12:04:58.226003 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=256 HK_LFR_DPU_SPW_RX_TOO_BIG=1<br />12:04:59.226005 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=256 HK_LFR_DPU_SPW_RX_TOO_BIG=1<br />12:05:00.226468 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=256 HK_LFR_DPU_SPW_RX_TOO_BIG=1<br />12:05:01.226032 HK_LFR_LE_CNT=1 <strong>HK_LFR_ME_CNT=256 HK_LFR_DPU_SPW_RX_TOO_BIG=1</strong></p>
<p>On voit la parfaite égalité des 2 compteurs excepté après le wrap de HK_LFR_DPU_SPW_RX_TOO_BIG.<br />Le script joué se nomme /opt/VALIDATION_R3.3/lfrverif/LFR_SVS/SVS-0026/check_rx_too_big_cnt_wrap.py et les fichiers de test sont dans<br />/home/validation/data/R3.3/3.3.0.11/1.1.91/SVS-0026/TESTS/check_rx_too_big_cnt_wrap</p>
<p>Contexte du test<br />---------------------<br />FSW 3.3.0.11<br />VHDL 1.1.91<br />EM1 sans Timegen<br />SocExplorerEngine.getSocExplorer: Version = 0.7.0, Branch = default, Changeset = c459540a6dbdcbb4e17f204685fce02c070ba971+<br />StarDundee</p>
<p><strong>ATTENTION<br />Il se peut que ce bug soit applicable également à la gestion du compteur d'erreur HK_LFR_LE_CNT.</strong></p> LFR-FSW - Bug #4013 (Closed): LFR en mode compilé pour les CPU_STATS crashe en SBM1https://hephaistos.lpp.polytechnique.fr/redmine/issues/40132023-01-19T10:39:16Zbruno katra
<p>Quand on execute FSW 3.3.0.12 compilé avec les CPU_STATS :<br />- passage en NORMAL puis STDBY : OK, sortie série avec STATS CPU<br />- passage en SBM1 : NOK, seulement les BP/ASM @F1 et @F0 sont produits, pas de produits F2 et le soft crash au bout de quelques secondes</p>
<p>Même tests refaits en 3.2.0.24 : OK</p> LFR-FSW - Bug #4012 (Closed): TM_LFR_KCOEFFICIENTS_DUMP erroné suite à l'envoi d'une TC_LFR_LOAD_...https://hephaistos.lpp.polytechnique.fr/redmine/issues/40122023-01-19T10:26:55ZVeronique bouzid
<p>Dans le test /opt/VALIDATION_R3.3/lfrverif/LFR_SVS/SVS-0086/load_kcoeff_with_dump_v3-3.py</p>
<p>l'envoi d'un TC_LFR_LOAD_KCOEFFICIENTS avec KCOEFF_FREQ = 0, KCOEFF_1 = 1065353216 à KCOEFF_32 = 1065353216<br /> ne doit pas modifier les KCOEFF contenus dans la TM_LFR_KCOEFFICIENTS_DUMP.</p>
<p>Extrait</p>
<p><strong>TM_LFR_KCOEFFICIENTS_DUMP</strong> , CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: FUNCTIONAL_NON_CYCLIC = 6, (PACKET_ID=0xcc6), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=2, (PACKET_SEQUENCE_CONTROL=0xc002), PACKET_LENGTH=3393, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: EQ_CONFIGURATION = 181, SERVICE_SUBTYPE: KCOEFFICIENTS_DUMP = 96, DESTINATION_ID: MISSION_TIMELINE = 110, TIME=0x8000000d233f, PA_LFR_HK_SID: LFR_KCOEFF_SID = 11, PA_LFR_KCOEFF_PKT_CNT=2, PA_LFR_KCOEFF_PKT_NR=1, PA_LFR_KCOEFF_BLK_NR=26, <strong>SY_LFR_KCOEFF_FREQUENCY=0, SY_LFR_KCOEFF_1=1065353216, SY_LFR_KCOEFF_2=1065353216, SY_LFR_KCOEFF_3=1065353216, SY_LFR_KCOEFF_4=1065353216, SY_LFR_KCOEFF_5=1065353216, SY_LFR_KCOEFF_6=1065353216, SY_LFR_KCOEFF_7=1065353216, SY_LFR_KCOEFF_8=1065353216, SY_LFR_KCOEFF_9=1065353216, SY_LFR_KCOEFF_10=1065353216, SY_LFR_KCOEFF_11=1065353216, SY_LFR_KCOEFF_12=1065353216, SY_LFR_KCOEFF_13=1065353216, SY_LFR_KCOEFF_14=1065353216, SY_LFR_KCOEFF_15=1065353216, SY_LFR_KCOEFF_16=1065353216, SY_LFR_KCOEFF_17=1065353216, SY_LFR_KCOEFF_18=1065353216, SY_LFR_KCOEFF_19=1065353216, SY_LFR_KCOEFF_20=1065353216, SY_LFR_KCOEFF_21=1065353216, SY_LFR_KCOEFF_22=1065353216, SY_LFR_KCOEFF_23=1065353216, SY_LFR_KCOEFF_24=1065353216, SY_LFR_KCOEFF_25=1065353216, SY_LFR_KCOEFF_26=1065353216, SY_LFR_KCOEFF_27=0, SY_LFR_KCOEFF_28=0, SY_LFR_KCOEFF_29=0, SY_LFR_KCOEFF_30=0, SY_LFR_KCOEFF_31=0, SY_LFR_KCOEFF_32=0</strong></p>
<p>On voit bien que seuls les KCOEFF allant de 1 à 26 ont récupéré la valeur modifiée par la TC_LFR_LOAD_KCOEFFICIENTS_alors que les KCOEFF de 27 à 32 sont bien restés à zéro (valeurs par défaut mises au boot).</p>
<p><ins>Ici les valeurs de référence récupérées au boot</ins></p>
<p><strong>TM_LFR_KCOEFFICIENTS_DUMP</strong> , CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: FUNCTIONAL_NON_CYCLIC = 6, (PACKET_ID=0xcc6), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=0, (PACKET_SEQUENCE_CONTROL=0xc000), PACKET_LENGTH=3393, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: EQ_CONFIGURATION = 181, SERVICE_SUBTYPE: KCOEFFICIENTS_DUMP = 96, DESTINATION_ID: MISSION_TIMELINE = 110, PA_LFR_HK_SID: LFR_KCOEFF_SID = 11, PA_LFR_KCOEFF_PKT_CNT=2, PA_LFR_KCOEFF_PKT_NR=1, PA_LFR_KCOEFF_BLK_NR=26, <strong>SY_LFR_KCOEFF_FREQUENCY=0, SY_LFR_KCOEFF_1=1050859893, SY_LFR_KCOEFF_2=1051774863, SY_LFR_KCOEFF_3=3199048410, SY_LFR_KCOEFF_4=3199675526, SY_LFR_KCOEFF_5=1048105208, SY_LFR_KCOEFF_6=1049731468, SY_LFR_KCOEFF_7=3199884855, SY_LFR_KCOEFF_8=3201093691, SY_LFR_KCOEFF_9=1002946415, SY_LFR_KCOEFF_10=993270132, SY_LFR_KCOEFF_11=1052396741, SY_LFR_KCOEFF_12=1051678457, SY_LFR_KCOEFF_13=3193633745, SY_LFR_KCOEFF_14=3195990147, SY_LFR_KCOEFF_15=3202344225, SY_LFR_KCOEFF_16=3204016481, SY_LFR_KCOEFF_17=3191761623, SY_LFR_KCOEFF_18=3194781000, SY_LFR_KCOEFF_19=0, SY_LFR_KCOEFF_20=2147483648, SY_LFR_KCOEFF_21=3164388996, SY_LFR_KCOEFF_22=3169957665, SY_LFR_KCOEFF_23=3164388996, SY_LFR_KCOEFF_24=3169957665, SY_LFR_KCOEFF_25=3156000388, SY_LFR_KCOEFF_26=3161569057, SY_LFR_KCOEFF_27=0, SY_LFR_KCOEFF_28=0, SY_LFR_KCOEFF_29=0, SY_LFR_KCOEFF_30=0, SY_LFR_KCOEFF_31=0, SY_LFR_KCOEFF_32=0</strong></p>
<p><strong>QUESTION<br />----------------<br />Est ce un bug ou bien le comportement attendu?</strong></p>
<p>Contexte du test<br />----------------------<br />FSW 3.3.0.11 et 3.3.0.12<br />VHDL 1.1.91<br />EM2 sans Timegen<br />SocExplorerEngine.getSocExplorer: Version = 0.7.0, Branch = 0.6, Changeset = c459540a6dbd+<br />StarDundee</p> LFR-FSW - Bug #4007 (Closed): Le FSW crashe pendant l'envoi massif de TC_LFR_LOAD_KCOEFFhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/40072022-12-27T14:39:57Zbruno katra
<p>FSW 3.3.0.11<br />TEST SVS-0022</p>
<p>Hello</p>
<p>Je viens de relancer une troisième fois le test. Cette fois aucun plantage. Ce test est un test de charge (envoi de cdes) et le mode choisi est le SBM1.</p>
<p>J'avais fait 2 captures d'écran du LFR GSE que je documenterai dans le Redmine. Les 1000 cdes TC_LFR_LOAD_KCOEFF avaient été rejetées car le mode LFR actif etait SBM1 et non standby. Le soft a bien remonté 1000 erreurs (hk_lfr_rej_tc_cnt = 1000) , ce qui est cohérent.</p>
<p>Le plantage a eu lieu pendant l'envoi des 1000 cdes TC_LFR_DUMP_KCOEFFICIENTS, le premier indique la 268eme TC et le deuxieme indique 266eme TC.</p>
<p>Je referai un test à la rentrée.</p>
<p>@AlexisJ tu peux mettre ton cerveau au repos.</p>
<p>Bonne soirée.</p>
<p>Véronique<br />Le 21/12/2022 à 13:27, Alexis Jeandet a écrit :</p>
<blockquote>
<p>Ok, c'est presque normal, au moins je sais où regarder en parallèle si jamais je vois quelque chose de flagrant. Sinon est-ce que ça pourrait être côté gse?</p>
<p>Le 21 décembre 2022 12:59:13 GMT+01:00, "Véronique Bouzid" <<a class="email" href="mailto:veronique.bouzid@lpp.polytechnique.fr">veronique.bouzid@lpp.polytechnique.fr</a>> a écrit :</p>
<p>Hello,</p>
<p>Oui c est au niveau de l'envoi des 1000 load_kcoeff dans tous les modes mais cela ne veut pas forcement dire que c est elle.</p>
<p>J'ai fait un test unitaire qui envoie les 1000Tc en standby et cela fonctionne.</p>
<p>Le script du SVS-0022 est plus complexe et je prèfere circonscrire le pb avant de vous inonder de mails.</p>
<p>A+</p>
<p>Véronique</p>
<p>Le 21/12/2022 à 12:52, Alexis Jeandet a écrit :</p>
<p>Hello,</p>
<p>Tu sais sur quelle TC il plante? Est-ce la même à chaque fois?</p>
<p>Alexis.<br />On Wed, 2022-12-21 at 12:46 +0100, Véronique Bouzid wrote:</p>
<p>Hello</p>
<p>Pour info, je viens de planter le soft de vol sur le test de la SVS-<br />0022.</p>
<p>le plantage est reproductible, je l'ai rejoué 2 fois. C</p>
<p>Il faut donc que je trouve le pourquoi. Je renseignerai le REdmine<br />quand j'aurai un peu plus d'infos.</p>
<p>Bon Noel à tous.</p>
<p>Véronique</p>
</blockquote> LFR-FSW - Bug #3948 (Closed): FSW <= 3.3.0.7 : fluctuation de l'amplitude des ASM avec signal sta...https://hephaistos.lpp.polytechnique.fr/redmine/issues/39482022-04-04T08:23:14Zbruno katra
<p>Avec 3.3.0.7 matrices par défaut : on injecte la même fréquence sur B1, B2, B3, E1 et E2 : <br />l'amplitude ASM des termes diagonaux change à chaque ASM, on la voit osciller sur le GSE, voir vidéos et commentaires dans <a class="issue tracker-1 status-2 priority-2 priority-default" title="Bug: Comparaison/validation FSW 3.2.0.24 vs 3.3.0.7 avec matrices unitaires. (In Progress)" href="https://hephaistos.lpp.polytechnique.fr/redmine/issues/3936">#3936</a>.</p> DECOM LFR - Bug #3947 (Closed): Problème de format dans output ASCII des ASM dans DECOM <=0r124https://hephaistos.lpp.polytechnique.fr/redmine/issues/39472022-04-01T14:34:58Zbruno katra
<p>Avec des valeurs très élevées les floats se touchent rendant les valeurs illisibles :</p>
<p>Exemple:</p>
<ol>
<li>SOURCE DATA BEGIN - Offset in the file (byte pos): 20300 #####</li>
<li>PA_LFR_PKT_CNT_ASM: 3 #####</li>
<li>PA_LFR_PKT_NR_ASM: 1 #####</li>
<li>Number of blocks/samples to read : 32</li>
<li>Acquisition Time (first sample): </li>
<li>Sync bit : 0</li>
<li>Raw Integer (unit of 2^-16 seconds) : 46014206509194</li>
<li>Seconds : 702121071.0021057128906250<br /> 84374110208.0000000000176146710528.0000000000 76289605632.0000000000-190448828416.0000000000168695201792.0000000000 38721120.0000000000 -11585246.0000000000 32918624.0000000000 -20688280.0000000000436719157248.0000000000-245066317824.0000000000524383813632.0000000000 70362424.0000000000 -59197352.0000000000 50017824.0000000000 -72955144.0000000000767165726720.0000000000 -110564408.0000000000 -51267808.0000000000 -115667424.0000000000 -19119120.0000000000 19360.7246093750 17947.7539062500</li>
</ol> LFR-FSW - Bug #3941 (Closed): Calcul des BP2 erroné pour F2 [3.3.0.7 avec matrices unitaires]https://hephaistos.lpp.polytechnique.fr/redmine/issues/39412022-03-28T16:40:45Zthomas chust
<p>A F2 le calcul des ASM semble correct sur toute la bande de fréquence ( <a class="issue tracker-1 status-2 priority-2 priority-default" title="Bug: Comparaison/validation FSW 3.2.0.24 vs 3.3.0.7 avec matrices unitaires. (In Progress)" href="https://hephaistos.lpp.polytechnique.fr/redmine/issues/3936">#3936</a> ). Voir par exemple les résultat des CTC-902 ou CTC-912. En utilisant les ASM des ces tests j'ai reconstruit des BP2. Normalement à quelques imprécisions près on devrait retrouver les BP2 calculés à bord. Mais ce n'est pas ce que j'observe: aucune correpondance, tout semble faux. Pour vérifier que je ne me suis pas planté complétement, j'ai refait le même type de calcul/comparaison mais avec le run du 14 mars qui utilise la 3.2.0.24 (F2-64Hz-2Vpp_on_E1E2B1B2B3): là pas de pb je retrouve bien ce qu'il faut.</p>
<p>A suivre ...</p> LFR-FSW - Bug #3930 (Closed): Les valeurs des KCOEFF après une sequence de LOAD_KCOEFF ne sont pa...https://hephaistos.lpp.polytechnique.fr/redmine/issues/39302022-02-11T18:23:38Zbruno katra
<p>Test fait en 3.3.0.5 et 3.3.0.4 : les matrices et les tableaux sont énormes, pour plus de visibilité je ne copie/colle pas toutes les valeurs dans l'issue.<br />Je réduis le test uniquement aux valeurs du BIN16 de F0.</p>
<p>J'ai uploadé les kcoeffs de Thomas pour faire des matrices unitaires, pour (sy_lfr_kcoeff_frequency = 0) qui contient le 'F0 calibration matrix bin 16' cela donnes les valeurs suivantes :</p>
<p>[ <strong>1.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,1.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,1.0,0.0</strong> ,1.0,0.0,0.0,0.0,0.0,0.0,1.0,0.0,1.0,0.0,0.0,0.0,0.0,0.0]<br />Les valeurs en gras sont les 18 floats de la matrice B pour BIN16 à F0 (9 nombres complexes) que l'on s'attend à retrouver en mémoire et dans le KCOEFF_DUMP</p>
<p>L'upload des KCOEFF se passe bien (tous les acquittements OK) MAIS voici ce que contient la mémoire pour la matrice B pour le BIN16 F0 :</p>
<p>1.0, 1.0, 0.875, 0.765625, 0.669921875, 0.586181640625, 0.512908935546875, 0.4487953186035156, 0.39269590377807617, 0.46860891580581665, 0.41003280878067017, 0.39529386162757874, 0.39178162813186646, 0.3037853538990021, 0.21817202866077423, 0.21827389299869537, 0.2288564145565033, 0.15853223204612732</p>
<p>Ceci est confirmé par le KCOEFF_DUMP :</p>
<p>1.0000000000000000 1.0000000000000000 0.8750000000000000 0.7656250000000000 0.6699218750000000 0.5861816406250000 0.51290893554687<br />50 0.4487953186035156 0.3926959037780762 0.4686089158058167 0.4100328087806702 0.3952938616275787 0.3917816281318665 0.3037853538<br />990021 0.2181720286607742 0.2182738929986954 0.2288564145565033 0.1585322320461273</p> LFR-FSW - Bug #3916 (Closed): Les valeurs reportées dans le KCOEFF_DUMP ne sont pas comme attendues.https://hephaistos.lpp.polytechnique.fr/redmine/issues/39162021-12-08T14:04:26Zbruno katra
<p>FSW 3.3.0.4 : boot LFR puis DUMP_KCOEFF immediatement. On doit récupérer dans la TM KCOEFF_DUMP les valeurs par défaut des matrices.</p>
<p>Si on prend l'exemple de MAG à F0 : le premier (BIN16) est correct.<br />Mais le 2eme qui devrait être le BIN 24 n'est pas correct :</p>
<p>- le fichier calibration_matrices.c indique comme BIN 24 :<br /> <strong>0.08846061297961542f 0.46413810919321624f -0.10038471453508746f -0.4843699075328815f<br /> 0.03327358102637455f 0.3772868178797596f -0.09786024818940642f -0.5364344929284444f<br /> 0.004235217228007431f 0.004583954729805597f</strong> 0.12025744717251019f 0.47833933495166725f<br /> -0.050588274112707214f -0.3293622659031427f -0.11632660132661053f -0.6506716440667137f<br /> -0.01683527047976743f -0.30264228744682875f</p>
<p>- la TM KCOEFF_DUMP contient :</p>
<pre><code>0.0000000000000000 -0.0000000000000000 -0.0191338136792183 -0.0295062679797411 <br /> -0.0191338136792183 -0.0295062679797411 -0.0095669068396091 -0.0147531339898705 <br /><strong>0.0884606093168259 0.4641381204128265 -0.1003847122192383 -0.4843699038028717 <br />0.0332735814154148 0.3772868216037750 -0.0978602468967438 -0.5364344716072083 <br />0.0042352173477411 0.0045839548110962</strong></code></pre>
<p>On remarque cependant des valeurs communes avec juste un offset d'index (en gras).</p>
<p>Je propose de vérifier de mon côté d'abord : que la decom est correcte et que les valeurs en mémoire sont correctes</p> LFR-FSW - Bug #3898 (Closed): E1 et E2 semblent intervertis dans FSW 3.3.0.1https://hephaistos.lpp.polytechnique.fr/redmine/issues/38982021-11-18T08:44:46Zbruno katra
<p>Test fait sur EM1 avec FSW 3.3.0.1:</p>
<p><strong>On injecte un signal uniquement sur E1 :</strong><br /><ins>Résultat attendu :</ins> avec les nouvelles matrices de calibration/chgt de repère on devrait observé du signal sur les ASM E1 ET E2<br /><ins>Résultat observé :</ins> on ne voit du signale que sur E2, rien sur E1</p>
<p><strong>On injecte un signal uniquement sur E2 :</strong><br /><ins>Résultat attendu :</ins> avec les nouvelles matrices de calibration/chgt de repère on devrait observé du signal sur les ASM E1 uniquement<br /><ins>Résultat observé :</ins> on voit du signal sur E2 ET E1</p>
<p>On dirait que les canaux E1 et E2 sont intervertis dans le traitement du FSW.</p>
<p>On a fait le test avec 3.2.0.24 et on voit bien E1 et E2 réagir comme attendu.</p>
<p>A confirmer avec des matrices unitaires.</p> LFR-FSW - Bug #3822 (Closed): TM_LFR_KCOEFFICIENTS_DUMP : le champs PA_LFR_KCOEFF_PKT_NR est tou...https://hephaistos.lpp.polytechnique.fr/redmine/issues/38222021-03-29T09:31:32Zbruno katra
<p>Le lundi 29 mars 2021 à 10:25 +0200, Bruno KATRA a écrit :</p>
<blockquote>
<p>Xavier a peut-être trouvé un petit bug dans les entêtes des paquets<br />KCOEFF_DUMP de LFR :</p>
<p>Les dumps KCOEFF étant trop grand, le FSW les fractionnent en 2<br />paquets :</p>
<p>- 1er paquet de 30 KCOEFF</p>
<p>- 2ème paquet de 6 KCOEFF</p>
<p>Il y a dans les entêtes un champs PA_LFR_KCOEFF_PKT_NR qui indique si<br />c'est le paquet 1 ou le paquet 2.</p>
<p>Or apparemment il est toujours à 1.</p>
</blockquote>
<p>Bug identifié dans le code par Alexis, capture écran en PJ dans l'issue</p>