LPP » INSTRU » Solar Orbiter LFR » LFR-FSW

1. SWF: idem que pour #614 (logique de synchro semble maitrisée et amplitude des oscillations "forte" car dérive, ~T2, plus forte que dans le cas du test à 22s) ; dans l'immédiat je n'arrive pas à comprendre l'évolution des dérives/resynchro observée au vu de l'algo ; à suivre ...
2. ASM: il y a un problème à la transition SBM1 vers SBM2, donc 7h après les 10 min de NM; les 7ièmes ASM_F1 et ASM_F2 disparaissent (pas de ASM au temps attendu, les suivants sont 3600s après) alors que le 7ème ASM_F0 est bien là mais avec 1s de retard
3. ASM: les premiers ASM arrivent 1h10 après le passage en NM lorsqu'il y a eu une transition en SBM1 10 mn après le début du NM. On dirait que le passage en SBM1 a remis à 0 le timer pour la génération des ASM toutes les 3600s. Cela veut dire que le NORMAL DATAFLOW a été impacté par le chgt de mode donc non conformité avec l'exigence SSS-CP-EQS-326 (Upon reception of a TC_xxx_ENTER_MODE(SBM1) / TC_xxx_ENTER_MODE(SBM2) /
   TC_xxx_ENTER_MODE(NORMAL), the equipment flight software shall not re-initialize the
   NORMAL data flow if this one was already active.)
4. CWF3: il y a un problème avec le premier buffer ou le deuxième; en effet le deuxième buffer est daté 168.99776s après le premier, donc ~1s de trop !? Paul, est-ce que cela peut avoir un lien avec la façon dont maintenant on démarre LFR avec une date donnée (+1s par défault si on indique 0)? Sinon ensuite la continuité temporelle est nominale (les sauts de temps entre chaque buffer peuvent s'expliquer par la dérive ...)
5. CWF2: OK (continuité temporelle est nominale)
6. CWF1: pas fait car fichier trop lourd ; je vais modifier mon code pour ne prendre que les headers; à suivre donc ...

2.
Il faudrait consulter un log des paquets pour se faire une idée, notamment voir l'arrivée de la TC de changement de mode. Tu es peut-être sur un cas limite où la transition a été demandée entre le moment où on a émis les ASM_F0 et le moment où les autres, ASM_F1 et ASM_F2, devaient suivre?

Oui c'est possible mais un changement SBM1 vers SBM2 n'est pas censé perturber le NORMAL DATAFLOW.
paul: ça ne perturbe pas les snapshots, j'avais demandé à Thomas si on pouvait accepter une perturbation sur les ASM et BP

3.
Pour les ASM, il me semble que je t'avais parlé de ça lors de ma venue. Je ne retrouve plus le dessin que j'avais fait pour expliquer la chose.
Les tâches concernant les ASMs (AVFx et PRCx) sont redémarrées à la demande de transition NORM <=> SBMx. Ca a peu d'influence sur l'arrivée des BPs, qui sont fournis souvent, mais beaucoup sur les ASM malheureusement. Et ça, je n'y toucherai que si c'est fondamental. A la limite, on pourrait émettre une matrice spectrale sans attendre 3600s, genre juste après avoir démarré, pour ne pas attendre trop longtemps.
==> Ok, je ne savais pas mais Véro a l'air au courant. Cela fait que nous sommes POK sur ce requirement et qu'il faudra le renseigner dans SRS, SUM + une RFD pour William. Cela concerne t'il aussi les transitions SBM1<=>SBM2 (cf . point 2 ci dessus ) ?

paul: oui, c'est pareil pour SBM1 <=> SBM2

Ok c'est noté pour point 2 et 3, ce sera renseigné dans la datapack.

Pour le point 4, aurais-tu une théorie?

Pour le point 4, tel Eric et Ramzy à la grande époque "nous n'avons pas d'autre explication".

Paul,
2.
OK pour que cela soit lié à un cas limite de transition qui tombe mal. Pour autant cela n'explique pas que le 7ième SWF_F0 soit daté de 1s en retard. Cela est peut-être l'indication d'un bug à venir ... Il n'y a pas urgence mais pour la R3+ et en rapport avec le 3. cela reviendra peut-être à l'ordre du jour.
3.
Dans l'immédiat ce n'est pas fondamental. Pour la R3+ il y aura l'occasion de reconsidérer la question car il s'agira de maitriser avec encore plus de détails le timing du calcul des ASM (virer les FFT sous-jacente qui sont poluées ...).

6.
CWF1: OK (continuité temporelle est nominale)