Bug #3908
closed
Taille des paquets KCOEFF_DUMP en FSW >=3.3
0%
Description
Les nouveaux paquets KCOEFF_DUMP ne contiennent plus les même valeurs qu'avant ce qui est normal dans la nouvelle implémentation : le 1er paquet contient un stream de 676 flottants soit 2704 octets.
Avant en 3.2.0.24 : le paquet contenait 3900 octets (30x(uint16+32xfloats))
Or on voit dans le binaire du dump 3.3.0.1 attaché que la TM KCOEFF_DUMP fait toujours 3900 octets, seuls les 2704 premiers sont remplis, le reste est à 0 avec des octets de bourrages inutiles. On peut voir le début du stream des flottants à l'offset 768228.
Pour des raisons d'autoconsistance de l'ICD, lié aussi aux modifs que l'on demandera à Plasson : le paquet ne devrait contenir que les 2704 floats.
Files
Related issues
Updated by bruno katra about 3 years ago
- Related to Feature #3905: La TM_KCOEFF_DUMP n'a plus la structure dédcrite dans l'ICD added
Updated by bruno katra about 3 years ago
- Status changed from New to In Progress
- Priority changed from Normal to Urgent
Problème pour le 2eme paquet KCOEFF : il est tronqué à la taille de l'ICD avec un block_number =6.
Ceci est bloquant pour l'instant car je ne peux pas vérifier que les matrices uploadés sont bien appliquées.
Vu avec Alexis : la mise à jour des 2 DEFINE à 676 et 338 devrait résoudre le problème.
Updated by Alexis Jeandet about 3 years ago
Ce build intègre le correctif pour set correctement le BLK_NR (nombre de float)
https://hephaistos.lpp.polytechnique.fr/teamcity/buildConfiguration/LfrFlightSoftware_BuildLpp/72131
Updated by bruno katra about 3 years ago
- Assignee changed from Alexis Jeandet to bruno katra
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 versions?
Updated by Alexis Jeandet about 3 years ago
nope, en effet, je comptais release avec le correctif des changements de mode.
Updated by bruno katra about 3 years ago
- Assignee changed from bruno katra to Alexis Jeandet
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 acquitée avec SUCESS.
Voici la trace des paquets après l'envoi de 4 TC KCOEFF_DUMP, on y voit bien les acquittements mais pas les DUMP :
2021 12 1 12:27:59:118 TM_LFR_HK time = 0x 293a26ce 1db
2021 12 1 12:28:00:118 TM_LFR_HK time = 0x 293a26cf 1db
2021 12 1 12:28:01:118 TM_LFR_HK time = 0x 293a26d0 1f8
2021 12 1 12:28:02:130 TM_LFR_HK time = 0x 293a26d1 1da
2021 12 1 12:28:02:255 TM_LFR_TC_EXE_SUCCESS time = 0x 293a26d1 2507
2021 12 1 12:28:03:118 TM_LFR_HK time = 0x 293a26d2 1da
2021 12 1 12:28:03:712 TM_LFR_TC_EXE_SUCCESS time = 0x 293a26d2 99e7
2021 12 1 12:28:04:118 TM_LFR_HK time = 0x 293a26d3 1f7
2021 12 1 12:28:05:118 TM_LFR_HK time = 0x 293a26d4 1d9
2021 12 1 12:28:05:155 TM_LFR_TC_EXE_SUCCESS time = 0x 293a26d4 b6a
2021 12 1 12:28:06:118 TM_LFR_HK time = 0x 293a26d5 1d9
2021 12 1 12:28:06:656 TM_LFR_TC_EXE_SUCCESS time = 0x 293a26d5 8b98
2021 12 1 12:28:07:118 TM_LFR_HK time = 0x 293a26d6 1f6
2021 12 1 12:28:08:118 TM_LFR_HK time = 0x 293a26d7 1d8
2021 12 1 12:28:09:118 TM_LFR_HK time = 0x 293a26d8 1d7
Voici la trace des paquets avec la précédente 3.3.0.1, on y voit les 2 KCOEFF DUMP envoyés à chaque fois avec l'acquittement après :
2021 12 1 12:30:20:140 TM_LFR_HK time = 0x 293a275b 9d3
2021 12 1 12:30:21:140 TM_LFR_HK time = 0x 293a275c 9d2
2021 12 1 12:30:22:141 TM_LFR_HK time = 0x 293a275d 9f0
2021 12 1 12:30:22:649 TM_LFR_KCOEFFICIENTS_DUMP time = 0x 293a275d 8b05
2021 12 1 12:30:22:653 TM_LFR_KCOEFFICIENTS_DUMP time = 0x 293a275d 8b18
2021 12 1 12:30:22:653 TM_LFR_TC_EXE_SUCCESS time = 0x 293a275d 8b1e
2021 12 1 12:30:23:141 TM_LFR_HK time = 0x 293a275e 9d2
2021 12 1 12:30:24:85 TM_LFR_KCOEFFICIENTS_DUMP time = 0x 293a275e faaf
2021 12 1 12:30:24:90 TM_LFR_KCOEFFICIENTS_DUMP time = 0x 293a275e fac2
2021 12 1 12:30:24:91 TM_LFR_TC_EXE_SUCCESS time = 0x 293a275e fac8
2021 12 1 12:30:24:141 TM_LFR_HK time = 0x 293a275f 9d1
2021 12 1 12:30:25:141 TM_LFR_HK time = 0x 293a2760 9ef
2021 12 1 12:30:25:660 TM_LFR_KCOEFFICIENTS_DUMP time = 0x 293a2760 8dde
2021 12 1 12:30:25:664 TM_LFR_KCOEFFICIENTS_DUMP time = 0x 293a2760 8df1
2021 12 1 12:30:25:664 TM_LFR_TC_EXE_SUCCESS time = 0x 293a2760 8df7
2021 12 1 12:30:26:140 TM_LFR_HK time = 0x 293a2761 9d1
2021 12 1 12:30:27:39 TM_LFR_KCOEFFICIENTS_DUMP time = 0x 293a2761 eef5
2021 12 1 12:30:27:43 TM_LFR_KCOEFFICIENTS_DUMP time = 0x 293a2761 ef08
2021 12 1 12:30:27:43 TM_LFR_TC_EXE_SUCCESS time = 0x 293a2761 ef0e
2021 12 1 12:30:27:140 TM_LFR_HK time = 0x 293a2762 9d0
2021 12 1 12:30:28:141 TM_LFR_HK time = 0x 293a2763 9ee
Updated by bruno katra about 3 years ago
- Assignee changed from Alexis Jeandet to bruno katra
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.
Updated by bruno katra about 3 years ago
- Status changed from In Progress to Closed
La taille des KCOEFF dump est maintenant correcte :
1er : 676 floats soit 2704 octets
2eme : 338 floats sot 1352 octets.
MAIS :
le champ BLOCK_NUMBER est faux. J'ouvre un autre redmine spécifique.