Task #597
closed3.0.0.15
0%
Description
principale modification sur la resynchro des snapshots
test effectué avec 22s de période
Files
Updated by Veronique bouzid over 8 years ago
Installation du 3.0.0.15 sur pc-faust9 dans /opt/LFR/LFR-FSW/3.0.0.15
Les scripts de lancement ont été mis à jour.
Voici donc le nouvel environnement de test
FSW 3.0.0.15
VHDL 1.1.89
EM sans Timegen
SocExplorerEngine.getSocExplorer: Version = 0.6.2, Branch = default, Changeset = 819d0376d481
StarDundee
Updated by thomas chust over 8 years ago
- File tests_time_swf_VHDL-1.1.89_FSW-3.0.0.15_2016_01_28 tests_time_swf_VHDL-1.1.89_FSW-3.0.0.15_2016_01_28 added
- File tests_time_cwf_VHDL-1.1.89_FSW-3.0.0.15_2016_01_28 tests_time_cwf_VHDL-1.1.89_FSW-3.0.0.15_2016_01_28 added
- File README README added
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
Updated by thomas chust over 8 years ago
- Assignee set to paul leroy
- Priority changed from Normal to High
- 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 ...)
Updated by thomas chust over 8 years ago
- File plot_delta_SWF_F2.png plot_delta_SWF_F2.png added
- File plot_delta_SWF_F1.png plot_delta_SWF_F1.png added
- File plot_delta_SWF_F0.png plot_delta_SWF_F0.png added
- File tests_time_swf_VHDL-1.1.89_FSW-3.0.0.15_2016_01_28_bis tests_time_swf_VHDL-1.1.89_FSW-3.0.0.15_2016_01_28_bis added
- Priority changed from High to Urgent
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 ?
Updated by paul leroy over 8 years ago
- Assignee changed from paul leroy to thomas chust
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.
Updated by thomas chust over 8 years ago
- Assignee changed from thomas chust to paul leroy
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?
Updated by paul leroy over 8 years ago
- Assignee changed from paul leroy to thomas chust
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.
Updated by bruno katra over 8 years ago
- Status changed from New to Closed
Version intermédiaire. Bugs corrigés dans les versions > à livrer au LESIA