LPP » INSTRU » Solar Orbiter LFR » LFR-FSW

Bingo ! Comment as-tu fait Paul? Cela tombe d'équerre (à 2-3 fine times près) du début jusqu'à la fin du fichier, excepté parfois des écart de ~1/256 (255 à 257 fine times). Pour le reste c'est nominal comme pour la 3.0.0.13 (#590) et la 3.0.014 qui a suivi.

Un bug/feature sur les ASM déjà relevé pour la transition SBM1 => SBM2 est décrit là: #600

-------- Message transféré --------
Sujet : Test 3.0.0.15
Date : Thu, 28 Jan 2016 15:29:14 +0100
De : Véronique Bouzid <veronique.bouzid@lpp.polytechnique.fr>
Pour : Thomas Chust <thomas.chust@lpp.polytechnique.fr>
Copie à : Bruno Katra <bruno.katra@lpp.polytechnique.fr>

voici le test à depouiller:
derniere version de Paul.

30mn de SBM1 + 30 mn de SBM2

ftp://ftp.lpp.polytechnique.fr/bouzid/keep/LFR/3.0.0.15/

Merci pour ton travail.
Véronique

• ce que j'ai en fait mesurée explicitement est la variation de la durée entre 2 snapshots par rapport à la première durée.
• cette première durée est inférieure de ~120 µs (~8 fine times) par rapport à 22 s pile (cela s'explique a priori par la dérive relative des oscillateurs 49MHz et 50MHz)
• dès la 2ème durée (entre le 2ème et 3ème snapshot) il y a un décalage de - 256 fine times (- 1 période F2) qui est parasite car ne correspond à aucun rattrapage
• ensuite, de snapshot en snapshot, il y a continuement des décalages minimes de -1 à - 3 fine times qui s'additionnent avec la dérive des oscillateurs (~8 fine times comme noté plus haut)
• ce qui explique que tous les ~30 snapshots il y a un "brusque" rattrapage de +256 (254 à 256) fine times
• ce qui donne au final la figure suivante: à partir du 3ème snapshot, la position des snapshots par rapport au temps idéaux donnés par les multiples de 22 s, oscillent entre environ -4ms et -8ms

Paul est ce que cela est conforme à tes prévisions ?

(de mon coté je vais modifier mon programme d'analyse pour calculer explicitement ce que je viens de synthétiser ...)

Comme promis voici en pièces jointes: fichier de sortie de mon programme en partie plus explicite + figures associées

Paul, cela donne à penser que tu démarres le premier SWF un échantillon (période F2) trop tard, d'où le décalage global. Peux-tu faire mieux ?

Effectivement, en creusant et en comparant à des choses que j'ai déjà eues, j'ai trouvé un décalage d'une T2. Je fait la correction pour la réivions 3.0.0.16. Les écarts avec la seconde de synchro devrait osciller en 0 et -4ms par exemple. La correction est assez douce.

J'ai modifié également, la façon dont les matrices spectrales redémarrent. Maintenant, après une transition NORM/SBM, SBM/NORM, SBM/SBM, les matrices repartent de façon plus attendue (réception des ASM_F0 puis des ASM_F1 puis des ASM_F2), idem pour les BP normalement.
Donc lorsqu'une transition est demandée, les matrices sont redémarrées (trou dans les les données) et les BP de même.

paul leroy wrote:

Effectivement, en creusant et en comparant à des choses que j'ai déjà eues, j'ai trouvé un décalage d'une T2. Je fait la correction pour la réivions 3.0.0.16. Les écarts avec la seconde de synchro devrait osciller en 0 et -4ms par exemple. La correction est assez douce.

Super, mais cela ne devrait-il pas osciller plutôt entre +2ms et -2ms ?

J'ai modifié également, la façon dont les matrices spectrales redémarrent. Maintenant, après une transition NORM/SBM, SBM/NORM, SBM/SBM, les matrices repartent de façon plus attendue (réception des ASM_F0 puis des ASM_F1 puis des ASM_F2), idem pour les BP normalement.
Donc lorsqu'une transition est demandée, les matrices sont redémarrées (trou dans les les données) et les BP de même.

Cool. On gardera donc bien une acquisition quasi simultanée des ASM_F0, ASM_F1 et ASM_F2 (toutes les 4 s par ex.) comme s'est actuellement observé au démarrage (NM ou SBM). Es-tu d'accord?

Oui, on gardera une acquisition simultanée ASM_F0, ASM_F1, ASM_F2, comme au démarrage.

J'ai un peu amélioré la resynchro pour la 3.0.0.16 et on s'approche des +2ms/-2ms. On en rest un peu eloigné du fait des décalages entre la mesure et la correction. Je propose de rester sur cette configuration. J'ai fait pas mal de test pour optimiser le tout et c'est ce que j'ai obtenu de plus précis et de plus robuste.

Version intermédiaire. Bugs corrigés dans les versions > à livrer au LESIA