LPP » INSTRU » Solar Orbiter LFR » LFR-FSW

Le test n'etait pas bon. On a recupéré que des HK.
J'ai gardé les fiichiers 2016_02_12_16_55_23*) (ils se trouvent sur pc-faust9 dans le répertoire /home/validation/data/R3/3.0.0.22/TESTCHARGE/TEST-ECHOUE.

J'ai resetté avec le bouton LFR puis glissé
- le script LFRControlPlugin_startAll+setTime.py
- le script test_mode_SBMx_12h.py

les fichiers de test (2016_02_13_11_48_53_packet_l*) sont sur pc-instru weekly erase / Thomas/run-2016-02-13_3.0.0.22-1.1.89.

Véro, il est bizarre ton fichier. Decommuté il ne donne aucune donnée ?

Cette fois c'est la bonne.
Log de Socexplorer
Entered in NORMAL with defaults during 10mn

Entered in SBM1 with defaults during 6h et 10s

Entered in SBM2 with defaults during 6h et 10s

Entered in NORMAL with defaults during 10mn

Entered in STDBY

Voici la taille des fichiers obtenus
rw-rw-r-. 1 validation validation 40455311 17 févr. 05:46 2016_02_16_17_26_11_packet_log.data
rw-rw-r-. 1 validation validation 1223316598 17 févr. 05:46 2016_02_16_17_26_11_packet_record.data

les données sont copiées sur pc-instru Weeklly erased/Thomas/run-2016-02-16-3.0.0.22-1.1.89.
Les données sont également rangéessur pc-faust9 dans /home/validation/data/R3/3.0.0.22/TESTCHARGE/sbm1+sbm2.

Voir fichiers joints. OK. Commentaires éventuels plus tard. Plouf ...

En effet, le comportement des SWF a l'air plus stable qu'en 3.0.0.20
+ lancement du periodicity.py : analyse montre qu'il n'y a plus le saut 169s.

1. SWF: la modif de Paul semble avoir changer des choses car le type d'oscillation est de nature différente ce qui est surprennant en première analyse car on ne s'attendait pas à actionner des corrections négatives (ce qui a été corrigé dans l'algo); cela renvoie peut-être à mon incompréhension toujours actuelle de ce que fait l'algo pour de vrai; cependant le résultat est correct : les dérives semblent maitrisées; pour ma part à suivre ...
2. ASM: avec une transition décalée de 10 s après l'arrivé des (6ièmes) ASM il n'y a plus le problème observé suite à la transition SBM1 vers SBM2 ; les 7ièmes ASM (et non les 6èmes comme j'ai pu l'écrire par erreur [corrigé depuis dans le texte...]) sont bien là au temps attendu; en fin presque: 1s après (les 7ièmes arrivent 3611s après les 6ièmes).
3. ASM bis: comme avant: 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: le passage en SBM1 a remis à 0 le timer pour la génération des ASM toutes les 3600s. Même remarque pour le passage à SBM2 (10s de plus ...)
4. CWF3: cette fois ci OK (nominale, pas de problème avec le le temps du 2ième buffer; on ne comprends toujours pas ce qui a pu se passer avec la 3.0.0.20; peut-être à suivre ...)
5. CWF2: idem OK (la continuité temporelle est nominale)
6. CWF1: idem OK (continuité temporelle est nominale)

Lors des transitions suivantes, la génération des ASMs est redémarrée (effet collatéral de la nouvelle stratégie de changement de mode):
NORM => SBM1
NORM => SBM2
SBM1 => NORMAL
SBM1 => SBM2
SBM2 => NORMAL
SBM2 => SBM1

Fait pour 3.2.0.24