LPP » INSTRU » Solar Orbiter LFR » LFR-FSW

Ok alors je pense que je ne suis pas conforme dans la façon dont je decommute.

thomas chust wrote:

Dans le fichier .h la variable nbitsig n'ai utilisé que pour les puissances spectrales PE et PB. Pour SX et VPHI le SIGNIFICAND est codé sur 8 bits comme indiqué dans l'ICD R3.
Mais effectivement mes commentaires (copiés collés ...) sont ambigüe ...

significand = frexpf(e_cross_b_re, &exponent); // 0.5 <= significand < 1
// ReaSX = significand * 2^exponent
if (exponent < expmin) { // value should be >= 0.5 * 2^expmin
exponent = expmin;
significand = 0.5; // min value that can be recorded
}
if (exponent > expmax) { // value should be < 0.5 * 2^(expmax+1)
exponent = expmax;
significand = 1.0; // max value that can be recorded
}
if (significand 0) { // in that case exponent 0 too
exponent = expmin;
significand = 0.5; // min value that can be recorded
}

lfr_bp1[i*NB_BYTES_BP1+8] = (uint8_t) ((significand*2-1)*255 + 0.5); // Shift and cast into a 8-bit uint8_t with rounding
// where all bits are used (0, ..., 255)
tmp_uint8 = (uint8_t) (exponent-expmin); // Shift and cast into a 8-bit uint8_t where
// just the first nbitexp bits are used (0, ..., 2^nbitexp-1)
#ifdef DEBUG_TCH
printf("|ReaSX| : %16.8e\n",e_cross_b_re);
printf("significand : %16.8e\n",significand);
printf("exponent : %d\n" ,exponent);
printf("tmp_uint8 for ReaSX exponent : %d\n",tmp_uint8);
#endif
lfr_bp1[i*NB_BYTES_BP1+7] = lfr_bp1[i*NB_BYTES_BP1+7] | tmp_uint8; // Record these nbitexp bits in the nbitexp first bits
// (from the right to the left) of lfr_bp1[i*NB_BYTES_BP1+7]

la r78 ne semble pas améliorer les choses. Et je ne trouve pas de bugg de mon coté (mon fichier .c qui calcul SX et VPHI, ou la façon dont je fais la vérification en idl) ? A suivre ...

Salut Paul,
Je te réponds point par point:

Le 30/06/2015 11:26, Paul LEROY a écrit :

Questions:
=> ça marche de façon nominale pour la R2? L'intégralité du paquet décommuté est correct pour tous les paramètres?

Oui jusqu'à présent les BP1 en R2 étaient correctes

=> en R3, les seuls paramètres que vous ne voyez pas correctement sont SX et VPHI? Tous les autres sont corrects, pour toutes les bins? Les BP2 sont corrects?

Oui seuls les SX et les VPHI sont incorrects. Les autres données BP1 sont correctes ainsi que tous les BP2.

=> Thomas, as-tu bien pris en compte le fait que la représentation MSB/LSB n'est pas la même sur LFR et sur ton PC (pour un float, les 4 octets sont inversés)

Oui. Et a priori cela n'intervient pas vraiment dans l'écriture en mémoire de SX et VPHI

?
Thomas

Question: avez-vous fait tourner le calcul de Thomas sur les données matrices spectrales réelles, lorsque celles-ci sont livrées avec les BP1.

Si oui, il serait intéressant de comparer les valeur en hexa lues dans les BP1 reçu et les valeurs en hexa attendues (celle du calcul de référence de Thomas affectuées sur les matrices spectrales reçues).

Oui je lis les données ASM associées (toutes les 4 secondes aussi) et calcule sous idl ce que le programme C est sensé faire.
Et c'est bien là le problème. On observe pas ce qu'il faudrait ...

Ca serait possible de faire le calcul avec le programme en c?
Ceci pour vérifier deux choses: ça marche avec des float (en supposant que linux ne fasse pas le calcul en douce en double), et aussi pour regarder les valeurs en hexa qu'on est censé voir dans les BP, et comparer avec ce qui est reçu.

OK. En hexa, serais-tu capable de dire si les deux bytes sont faux ou si un des deux est correct?

A minima lfr_bp1[i*NB_BYTES_BP1+7] et lfr_bp1[i*NB_BYTES_BP1+9] sont mal retranscrits.
Concernant les octets stockant les valeurs significand lfr_bp1[i*NB_BYTES_BP1+8] lfr_bp1[i*NB_BYTES_BP1+10], valeurs comprises entre 0.5 et 1 je ne sais pas si elles sont fausses. Le contraire me surprendait mais ...

paul leroy wrote:

J'ai lancé le calcul directement sur LFR en utilisant les valeurs de la matrice que vous avez utilisé pour les tests. On trouve des différences dans les résultats pour les octets 7 et 9 du jeu de 11 bytes, j'ai l'impression que les valeurs 8 et 10 sont conformes.
Thomas, il fauudrait que tu passes chez moi pour regarder directement. Je joins la capture enregistrée pendant le test.

Commentaire Bruno : cela semble cohérent avec les erreurs observées car selon Thomas, ces erreurs sont relatives à l'exposant du flottant qui est justement dans les octets 7 et 9.

Merci Paul c'est un test concluant! Je crois avoir compris.
A priori c'est de ma faute: je n'ai pas pris garde de préaffecter une valeur nulle aux octects 7 et 9 alors que je les modifie via des opération logiques (et ou), ce qui n'était pas le cas pour le programme R2. Cela explique l'aspect aléatoire des résultats.

Je fais bientôt une modif et un push ...