Activity
From 19/11/2021 to 18/12/2021
13/12/2021
-
02:32 PM Bug #3916: Les valeurs reportées dans le KCOEFF_DUMP ne sont pas comme attendues.
- Vu avec Alexis : le pb vient de la specif qu'il avait fourni où l'ordre des matices est faux. Pas de pb au niveau du ...
-
- J'ai effectué un dump mémoire de LFR : le bin 24 est correct à première vue en mémoire (bonne valeur au bon indice).
...
08/12/2021
-
- DECOM vérifiée : OK
Je suis allé lire le binaire directement et on a bien les valeurs 0.0000000000000000 et -0.0000... -
- 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éfau...
-
- Le comportement de l'init des matrices au boot devra être détaillé dans SDD et/ou spec LFR :
- Les matrices par dé... -
- Ok merci je trace dans une issue dédiée pour que cela soit reportée dans la spec LFR et/ou le SDD quand ils seront mi...
-
01:22 PM Support #3914: Question sur la dernière matrice des KCOEFF...
- Oui, car initialement j'avais demandé à Thomas de mettre à 0 toutes les matrices non utilisées dans les calculs. L'av...
-
- Dans calibration_matrices.c, lors de l'init des matrices KCOEFF par défaut :
Est-il normal que la dernière matrice...
03/12/2021
-
- 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
-
- 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...
Also available in: Atom