Conversion TI UT
Des tables de conversion TI ⇒ UTC semblent exister.
2017/03/21 Passage valeurs physiques
Un memo se trouve dans le répertoire jaxa/mk_romtbl/MEAmemo.docx
2017/03/20 Geometrie
Certaines définitions se trouvent dans le fichier :
jaxa/Applications/INC/app_MPPE-MEA.hLa description des secteurs et des azimuths se trouve dans le fichier :
423 int app02_MEA_setTable1(unsigned char uc_sens)
424 {
425 int i, j, k;
426
427 struct _s_MEA_ProcParam *pP;
428 double f_az0, f_pl, f_az, f_pl1, f_az1;
429 short s_cosx, s_sinx;
430
431 if (uc_sens == Gd_N_MEA1) { pP = &Gst_MEA1_proc; f_az0 = d_Lcl_MEA1_PHI0; }
432 else { pP = &Gst_MEA2_proc; f_az0 = d_Lcl_MEA2_PHI0; }
433
434 //Polar
435 for (i = 0; i < 16; ++i) {
436 f_pl = (-78.75 + i*22.5)*MATH_PI/180.; //Centor of Polar angle
437 pP->s_csp0[i] = (short)(app_math_cos(f_pl)*d_Lcl_MEA_TBL_RD1);
438 pP->s_snp0[i] = (short)(app_math_sin(f_pl)*d_Lcl_MEA_TBL_RD1);
439 for (k = 0; k < 5; ++k) {
440 f_pl1 = f_pl + d_Lcl_MEA_MAX_RAD*pP->c_csp[i + 16*k]/d_Lcl_MEA_TBL_RAD; //Real Polar angle
441 s_cosx = (short)(app_math_cos(f_pl1)*d_Lcl_MEA_TBL_RD1);
442 s_sinx = (short)(app_math_sin(f_pl1)*d_Lcl_MEA_TBL_RD1);
443 pP->c_csp[i + 16*k] = (char)(s_cosx - pP->s_csp0[i]);
444 pP->c_snp[i + 16*k] = (char)(s_sinx - pP->s_snp0[i]);
445
446 }
447 }
448
449 //Azimuth
450 //<8d>Ä
z
u
451 for (k = 1; k < 5; ++k) memcpy(&pP->c_csa[256*k], &pP->c_csa[16*k], 16);
452 //
ZN^
[
û<8c>ü
É
W<8a>J
453 for (j = 15; j >= 0; --j) {
454 f_az = f_az0 + MATH_PI/8*j; //Centor of Azimuth
455 pP->s_csa0[j] = (short)(app_math_cos(f_az)*d_Lcl_MEA_TBL_RD1);
456 pP->s_sna0[j] = (short)(app_math_sin(f_az)*d_Lcl_MEA_TBL_RD1);
457 for (i = 0; i < 16; ++i) {
458 for (k = 0; k < 5; ++k) {
459 f_az1 = f_az + d_Lcl_MEA_MAX_RAD*pP->c_csa[i+k*256]/d_Lcl_MEA_TBL_RAD; //Real azimuth
460 s_cosx = (short)(app_math_cos(f_az1)*d_Lcl_MEA_TBL_RD1);
461 s_sinx = (short)(app_math_sin(f_az1)*d_Lcl_MEA_TBL_RD1);
462 //if (i >= 8) f_az1 += MATH_PI; //plrª
ê<8e>ü³¹éÌű±Å<8d>l
¶·é KvÍÈ¢B
463 pP->c_sna[i+16*j+k*256] = (char)(s_sinx - pP->s_sna0[j]);
464 pP->c_csa[i+16*j+k*256] = (char)(s_cosx - pP->s_csa0[j]);
465
466 }
467 }
468 }
469 return 0;
470 }2016/11/30 Point avec Nicolas ANDRE
Consommation
-
Septembre : 4 jours
-
Octobre : 8 jours
-
Novembre : 9 jours
A priori continuer à ce rythme pour essayer d’avancer le plus possible avant de rencontrer les Japonais à l’ESTEC en janvier 2017.
Il va essayer de trouver un financement pour une rallonge éventuelle.
Avancement
Les discussions lors du dernier SWT ont permis d’avancer sur les points suivants :
-
geom-factor : valeur (0,1,2,4,8) présente dans le header HDR (FPGA)
-
energy-table : index présent dans la structure INF présente dans la télémesure
Valeurs des tables dans le rapport de calibration de Andrei ou dans les documents de Mathieu
-
identification des produits : apparemment il y a des produits de bourrage (dataID = 7)
-
meilleure compréhension des Housekeeping (numérotation / commandes interface soft/FPGA)
Nous avons commemcé à produire des CDF pour les données 3DL et VM :
-
il reste à compléter les métadonnées (Nicolas)
-
décider les regroupements de produits (3D notamment)
-
définir mieux les niveaux L1 et L2
Actions
Questions en suspens
-
Problème champ B dans les PAD’s
Nicolas se propose de leur demander de l’ajouter.
-
Passage en valeurs physiques (Moments, 3D)
-
Mode engineering et mode H0 : sera t-il utilisé en mode croisière ou exceptionnellement sur demande ?
Voir avec Petiot et Aoustin
-
geom-factor et tables energies :
Vérifier que l’ISAS a implémenté les dernières valeurs
PAD’s
-
Continuer à traiter les produits pour voir le contenu des PAD’s
-
Regarder les données présentes dans les Housekeeping : il y a apparemment le numéro du secteur
Moments
J’ai trouvé un algorithme de transformation des valeurs USHORTtoDBL()
Demander s’il y a une documentation ou une norme pour ce format
Compression
Régler avec YOKOTA les doutes sur la compression des données :
-
Isoler les lignes de codes du soft de bord et de leurs softs de traitement liées à la compression.
-
Sortir les listings de nos logs
-
Lui demander de vérifier
Description métadonnées LPP
Clore l’action à la charge de l’IRAP concernant la description des métadonnées du LPP.
Relancer Katra pour savoir si notre réponse leur convient.
Si oui, rédiger une doc pour SAITO et proposer de clore l’action.
2016/11/21 Matthieu PETIOT
Discussion de jour avec M. Petiot pour avoir des précisions sur le format de l’entête HDR.
Il nous a fait parvenir divers documents : documents/PETIOT
Timing
- TI0
-
envoyé par Jaxa, multiple de 1.95 ms
- TI1
-
offset pour démarrer l’acquisition plus tard si nécessaire (0 par défaut)
- TC
-
offset (~100 micro-s) précédent TI0 qui marque le début de l’acquisition
time-tag = TI0 - TC + TI1Geom factor
0 |
GF1 |
HT sphre 1 = HT sphere 2 |
1 |
GF2 |
0,8 |
2 |
GF3 |
0,53 |
4 |
GF4 |
0,37 |
8 |
GF5 |
0,28 |
|
Vérifier les valeurs dans le rapport de calibration de Fédorov |
Energy mode
0 |
16 energies x 16 sweep |
1024 (dont 512 FF) x 16 |
1 |
16 energies x 32 sweep |
1024 (dont 512 FF) x 32 |
2 |
32 energies x 16 sweep |
1024 (dont 512 FF) x 16 |
3 |
32 energies x 32 sweep |
1024 (dont 512 FF) x 32 |
4 |
64 energies x 16 sweep |
1024 (dont 512 FF) x 16 |
|
La taille des paquets envoyés par le FPGA est fixe (1024 + header) Pour les produits 16 energies, il envoie 512 bytes + 512 FF. Pour les produits 32 energies, 1024 valeurs Pour les produits 64 energies, 2 paquets de 1024 |
Spin period
A aller rechercher dans les User HK.
Elle est recalculée à chaque spin (voir formule avec Mathieu)
