Activity
From 04/11/2021 to 03/12/2021
03/12/2021
-
04:16 PM Feature #3905: La TM_KCOEFF_DUMP n'a plus la structure dédcrite dans l'ICD
- Il faut maintenant prévenir le LESIA
-
- Testé ok en 3.3.0.4
-
- Testé ok en 3.3.0.4
-
- Testé ok en 3.3.0.4
02/12/2021
-
01:33 PM Bug #3911: KCOEFF_DUMP : champ PA_LFR_KCOEFF_BLK_NR faux
- Devrait être corrigé ici https://github.com/LaboratoryOfPlasmaPhysics/LFR_Flight_Software/commit/8a9fbaf9ba5bfb80ca20...
-
- Discuté avec Alexis : le BLOCK_NUMBER pourrait contenir le nombre de floats/26 (26= nombre de floats pour 1matrice B ...
-
- Dans 3.3.0.2 : les paquets KCOEFF_DUMP font la bonne taille attendue
MAIS le champs PA_LFR_KCOEFF_BLK_NR qui devrai... -
- Lié à #3912
-
- J'ai ajouté le binaire et l'ascii décommuté
-
- Testé en 3.3.0.2 au démarrage de LFR avec les matrices par défaut :
le 2eme paquet est rempli de floats à 0.
J'ai... -
- Pb #3911 : le champs blk_number est un octet, on ne peut pas stocker 676 et 338.
Discuté avec Alexis : le BLOCK_NU... -
- Réassignée à Bruno pour tests
-
- En effet, désolé pour la typo, ça devrait être corrigé ici:
https://github.com/LaboratoryOfPlasmaPhysics/LFR_Flight_... -
- Informations supplémentaires :
test fait en 3.3.0.2 avec les valeurs par défaut des matrices au boot de LFR (avant e... -
- Si on se réfère au code du FSW : calibration_matrices.c où sont initialisés les matrices par défaut :
la première v... -
- La taille des KCOEFF dump est maintenant correcte :
1er : 676 floats soit 2704 octets
2eme : 338 floats sot 1352 ...
01/12/2021
-
- Alexis a livré une 3.3.0.2, il y avait bien un bug qui n'envoyait plus les KCOEFF_DUMP. Testé en 3.3.0.2 OK.
-
- Dans cette version 3.3.0.1b : les KCOEFF_DUMP ne sont plus envoyés du tout par LFR, mais la commande est quand même a...
29/11/2021
-
- nope, en effet, je comptais release avec le correctif des changements de mode.
-
- Ok merci je me réassigne l'issue. Je vais tester.
Mais du coup c'est toujours une 3.3.0.1 ? Pas de changement de ver... -
- Ce build intègre le correctif pour set correctement le BLK_NR (nombre de float)
https://hephaistos.lpp.polytechnique... -
- Problème pour le 2eme paquet KCOEFF : il est tronqué à la taille de l'ICD avec un block_number =6.
Ceci est bloquan... -
- Test fait avec matrices unitaires pour retrouver le comportement de FSW 3.2.0.24.
Il y a toujours un truc qui ne va... -
- Matrices unitaires chargées avec FSW 3.3.0.1.
A première vue je ne retrouve pas le comportement ni les amplitudes de... -
- ll faudrait changer les 2 DEFINE du code du FSW qui contiennent le champ BLOCK_NUMBER : Les DEFINE sont actuellement ...
26/11/2021
-
- Les nouveaux paquets KCOEFF_DUMP ne contiennent plus les même valeurs qu'avant ce qui est normal dans la nouvelle imp...
24/11/2021
-
- L'ICD précise qu'un KCOEFF_DUMP contient :
n blocs de [KCOEFF_FREQ + 32xKCOEFF] où KCOEFF_FREQ est un UINT16 et KC...
18/11/2021
-
11:07 AM Task #3897: Faire un test avec les matrices de chgt de repère/calibration mises à 1 et 0 pour reproduire le comportement du FSW <=3.2.0.24
- Le tableau en question et le notebook qui l'a produit
-
- Afin de valider la non régression au niveau des signaux (amplitude et forme).
Thomas a envoyé le tableau 32x36 -
- Test fait sur EM1 avec FSW 3.3.0.1:
*On injecte un signal uniquement sur E1 :*
+Résultat attendu :+ avec les nouv...
10/11/2021
-
- FSW 3.3.0.1 sur EM1
Quand on demande à passer dans un mode où l'on est déjà le FSW doit générer une TM_LFR_TC_EXE_...
Also available in: Atom