LPP » INSTRU » Solar Orbiter LFR » LFR-FSW

fsw > = 2.0.1.1

J'ai ajouté une fonction de resynchronisation des snapshots. Je vais détailler le fonctionnement dans le software design report.

En résumé:
Lorsqu'un snapshot à f0 est généré, disons le snapshot [n], le soft regarde la date du centre et la compare à la seconde entière la plus proche. Si la différence est supérieure à une période à f2 (1/256 = 3.906 ms), le snapshot [n+2] est recalé, le [n+1] n'est pas modifié. La nécessité du recalage est reconsidérée un snapshot sur deux.

fonction implémentée et testée

Nouveau bug observé depuis, dans des versions récentes du soft et du VHDL:
- Bug #476 (VHDL-1.1.88 FSW-3.0.0.8)
- Bug #496 (VHDL-1.1.89 FSW-3.0.0.8)

En fait ce bug est également observé à l'identique (dans sa logique) sur une ancienne version du soft et du VHDL. A savoir:
- sous VHDL-1.1.68 et FSW-2.0.3, un enregistrement de 11 snapshots tout les 300 s (datant du 7 avril 2015) montre
- le 2èmes SWF_F1 & SWF_F0 en retard de ~0.22s par rapport à 300s (ensuite quasi nominal avec des écarts de ~12 ms tous les 2 snapshots);
- le 3ème SWF_F2 en retard de ~0.22s (ensuite idem quasi nominal avec des écarts de ~12 ms tous les 2 snapshots);
- tous les SWF_F0 centrés sur les SWF_F1 de manière identique (à 2^-16 s près);
- ce qui implique que les 2ème SWF_F1 & SWF_F0 sont décentrées par rapport au 2ème SWF_F2: ils sont en retard d ~0.22s
- que tous les autres SWF sont centrés de la même manière que le 1er snapshot, à des écarts près de l'ordre de 12 ms tout les 2 snapshots.

Fichiers joints: tests_time_VHDL-1.1.68_FSW-2.0.2.3_2015_04_07 + les fichiers ascii des SWF

Jean-Christophe a une idée sur l'origine de cela: si j'ai bien compris, l'actualisation des décompteurs des SWF se ferait dans la même logique que celle qui actualise la seconde de LFR avec celle du S/C, ce qui implique une prise en compte effective tout les deux snapshots au mieux et si l'on démarre avec des mauvais paramètres cela met un certain temps à s'autocorriger ...

J'ai fait une modification dans la version 3.0.0.13 au niveau de la fonction de synchronisation des snapshots. La correction est calculée à chaque génération d'un snapshot, c'est plus efficace.

Ceci dit, j'explique quand même mal des décalages de centaines de ms. Une explication pour un décalage si important dans les mesures que vous avez effectuées serait un démarrage du mode avec un enter_mode_time = 0 qui lance le mode immédiatement, sans référence à une seconde entière.
Ca m'a fait reconsidérer le comportement à la réception d'un enter_mode_time = 0. Pour que ce soit plus sain pour la synchro des snapshots, il faudrait qu'en cas de réception d'un enter_mode_time = 0 je lance le mode à la date 'coarse_time local LFR + 1'. Qu'en pensez-vous?

Explication de la resynchro:
A chaque production d'un snapshot à f0, le centre de la série temporelle est mesuré et le temps avant le prochain snapshot est modifié. Tout cela se fait avec un retard puisque à la réception d'un snapshot n, le compteur permettant de démarrer l'aacquisition du snapshot n+1 a déjà été lancé. Donc la correction calculée sur le snapshot n ne sera appliquée qu'au snapshot n+2.

Pour les dernières avancée sur ce point voir: #614

Nombreuses modifications/améliorations faites par Paul entre 3.0.0.13 et 3.0.0.22 (tracés dans #612 #616 #618 #624 #630).
A partir de 3.0.0.22 ; le jitter est stable même après plusieurs heures de tests : entre -11ms et +3 ms pour F0 par exemple avec ne synchro TIMEGEN. (voir graphes #630)
Une RFW 230 a été émise concernant la nc avec les 1ms demandé par SSS-CP-EQS-350.
Le jitter actuel permet néanmoins un recouvrement complet des SWF de TDS, ce qui est l'exigence scientifique voulue par SSS-CP-EQS-350.

JIRA 627 :

After several improvements on swf resync algorithm, the centering precision of swf has a jitter which is stable and characterized (depending on sampling frequency). 3 figures are attached in this issue showing the jitter for SWF_F0, SWF_F1 and SWF_F2 during 15 hours when LFR is synchronized with an external sources which are approx :
F0 : -11ms/+3ms
F1 : -11.5ms/+3ms
F2 : -14ms/+1ms

Even if more than 1ms required, those range are still scientifically acceptable as they cover TDS SWF range.
All of this has been written in RFW 230.

Pas d'objection à la RFW reçu.