LPP » INSTRU » Solar Orbiter LFR » LFR-FSW

2 tests ont été joués et se trouvent sur pc-instru/weekly erased /Thomas/run-2016-02-03.3.0.0.18-1.1.89
- premier test contient 1h de NORMAL MODE avec les SWF = 22s (2016-02-03_17_15_51*)
- deuxieme test contient 30mn de SBM1 suivi de 30mn de SBM2 2016-02-03_18_15_56*)

Voici donc le nouvel environnement de test
FSW 3.0.0.18
VHDL 1.1.89
EM sans Timegen
SocExplorerEngine.getSocExplorer: Version = 0.6.2, Branch = default, Changeset = 819d0376d481
StarDundee

analyse faite:
- test1: 1h NM OK (même plutôt très joli!)
- test2: 30min SBM1 + 30min SBM2 KO (pas joli du tout ! ) => dérive continue ...
Voir les fichiers joints

Voici un exemple des données que j'ai obtenues, avec les timecodes mais sans timegen:
Jeu de données considéré: 2016_02_04_11_59_59

1) démarrage en SBM1, 22s de période pour les snapshots
2) passage en SBM2 juste après le snasphot 20
3) passage en SBM1 juste après le 29

J'ai essayé sans timecodes, résultats corrects:
Jeu de données 2016_02_04_13_48_07
1) SBM1 démarré à la date 0x33
2) SBM2 commuté juste après le snapshot 23

Je n'ai pas encore bien compris la manip (timecode ou pas, avec ou sans timegen ...) mais voilà mes résultats (voir les fichiers). Cela semble correct, il n'y a que le démarrage qui est légèrement moins bon q'avant: on commence avec un écart supérieur à l'amplitude des oscillations.

Le premier décalage ne m'inquiète pas plus que ça.

Serait-il possible que le test où il y a une dérive continue n'ait pas été joué avec 3.0.0.18? Je ne vois pas d'autre explication possible à ce comportement bizarre.

D'après Véro cela est absolument impossible. Il s'agit bien du même FSW 3.0.0.18 mais la différence avec avant est l'usage d'un STANDBY de plus:
- STANBY puis enter mode NM
- RE-STANBY puis SBM1 + SBM2
Véro est partie refaire une manip avec exclusivement le SBM1+SBM2
Suite au prochain épisode ...

Les erreurs, ça peut arriver. Vous rechargez le soft à chaque début de test ou c'est forcément la même version du logiciel qui tourne? Si vous avez les HK, c'est possible d'y jeter un oeil?

les fichiers sont binaires et la decom de Bruno ne les decommute pas.
Je oeux tenter un editeur hexa pour voir.

les fichiers de test 30mn SBM1 + 30mn SBM2 sont disponibles sur pc-instru et dans run-2016-02-04-3.0.0.18.1.1.89/sans-timecode

2016_02_04_15_31_17*

Bon dépouillement.

Voilà le dépouillement. C'est nominal et plutôt très bien! Donc on a eu un problème avec le passge par STANDBY ...

Juste le nom de fichier qui était incorrect (le contenu était bon)

Bon, à suivre, et à vérifier lors des prochains tests.

Peut etre le fait de generer 2 fichiers au lieu d'un est une piste (utilisation de soc.lfrControlPlugin.Set_logPackets et soc.lfrControlPlugin.Set_storePacketsRaw.

ce point n'est plus prioritaire car en 3.0.0.19, les resultats sont bons puisque j'ai adapté le script pour generer
toutes les données dans le meme fichier, ( soc.lfrControlPlugin.Set_logPackets (1) et soc.lfrControlPlugin.Set_storePacketsRaw (1) au début du test
et on ferme les logs à la fin du script (soc.lfrControlPlugin.Set_logPackets (0) et soc.lfrControlPlugin.Set_storePacketsRaw (0) .