LPP » INSTRU » Solar Orbiter LFR » LFR-FSW

Paul, une question bête. Cela marche t-il aussi pour les transitions suivantes:
SBM1 => SBM2 ?
SBM2 => SBM1 ?

Normalement oui.

Installation de la version 3.0.0.13 sur pc-faust9.

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

Le script /home/validation/SCRIPT/just_hk_survey.py a été joué.

1- La version est correctement affichée dans les TM_LFR_HK.

2- Apres la sequence de boot, les champs
HK_LFR_TIME_NOT_SYNCHRO est positionné à 1
HK_LFR_LE_CNT est incrémenté et vaut 1
--> cela me semble correct

3- le champ SY_LFR_WATCHDOG_ENABLED est toujours à DISABLED.
--> comme indiqué par Paul, on doit determiner son fonctionnement

Les fichiers de test sont dans le répertoire /home/validation/data/3.0.0.13/TESTS6UNITAIRES/just_hk

C'est pas forcément sain qu'une désynchro soit repérée juste après le boot puisque c'est normal de commencer désynchronisé.

Je propose d'attendre une transition synchronisé vers désynchronisé avant de commencer à compter les désynchros.

J'ai trouvé le bug. Finalement, je suis revenu à une solution ou je resynchronise en utilisant 1 snapshot sur 2:
1) je reçois le snapshot 2k, je mesure le temps de centre, je calcule une correction (le snapshot 2k+1 est déjà en cours d'acquisition)
2) la correction est utilisée pour le snapshot 2k+2
3) à la réception du snapshot 2k+2, je calcule une nouvelle correction
Ca fonctionne sur ma machine, ça peut corriger des dérives inférieure à 0.5 secondes sur deux périodes (2*300 secondes dans les conditions nominales)

Correction dans fsw >= 3.0.0.14

A noter, quelquechose que je viens de vérifier et que j'avais oublié:
avec VHDL 0.1.68 sur ma MINI-LFR, en l'absence de timcodes, il n'y a pas de dérive, on tombe sur des intervalles exacts (ce qui est le comportement attendu sur les vieilles version du VHDL).
avec VHDL 0.1.89 sur MINI-LFR (et donc sur les versions récentes du VHDL), même sans synchro ni timecode il y a une dérive, on ne tombe plus parfaitement sur des temps justes parce que le coarse_time et le fine_time sont basés sur l'oscillateur à 50 MHz et non plus sur l'oscillateur à 49.152 MHz (utilisé pour générer 16, 256, 4096 et 24576 Hz), donc finis les cas où tout tombait juste.

Ce dernier point est à clarifier avec Alexis peut-être.