Notes diverses ============== == Conversion TI UT http://www.isas.jaxa.jp/home/solar/ana/TI-UT.html.en[] 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 link:documents/JAXA/MEAmemo.docx[] == __2017/03/20__ Geometrie Certaines définitions se trouvent dans le fichier : jaxa/Applications/INC/app_MPPE-MEA.h La description des secteurs et des azimuths se trouve dans le fichier : .jaxa/Applications/APP02/app02_MPPE-MEA.c ---- 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>Ä<94>z<92>u 451 for (k = 1; k < 5; ++k) memcpy(&pP->c_csa[256*k], &pP->c_csa[16*k], 16); 452 //<83>Z<83>N<83>^<81>[<95>û<8c>ü<82>É<93>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<82>ª<88>ê<8e>ü<82>³<82>¹<82>é<82>Ì<82>Å<82>±<82>±<82>Å<8d>l<97>¶<82>·<82>é <95>K<97>v<82>Í<82>È<82>¢<81>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 + [green]#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 ? + [red]#Voir avec Petiot et Aoustin# * geom-factor et tables energies : + [red]#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() [green]#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 : link: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 .Formule de calcul time-tag = TI0 - TC + TI1 === Geom factor [width = '50%', cols = "15,15,70"] |==== | 0 | GF1 | HT sphre 1 = HT sphere 2 | 1 | GF2 | 0,8 | 2 | GF3 | 0,53 | 4 | GF4 | 0,37 | 8 | GF5 | 0,28 |=== CAUTION: Vérifier les valeurs dans le rapport de calibration de Fédorov === Energy mode [width = '90%', cols = "10,40,50"] |==== | 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 |=== [NOTE] ==== 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)