Project

General

Profile

Actions

Task #597

closed

3.0.0.15

Added by paul leroy about 8 years ago. Updated about 8 years ago.

Status:
Closed
Priority:
Urgent
Assignee:
Category:
-
Target version:
-
Start date:
28/01/2016
Due date:
% Done:

0%

Estimated time:
revision:

Description

principale modification sur la resynchro des snapshots
test effectué avec 22s de période


Files

README (16.5 KB) README paul leroy, 28/01/2016 11:04 AM
fsw (4.05 MB) fsw paul leroy, 28/01/2016 11:04 AM
tests_time_cwf_VHDL-1.1.89_FSW-3.0.0.15_2016_01_28 (56.5 KB) tests_time_cwf_VHDL-1.1.89_FSW-3.0.0.15_2016_01_28 thomas chust, 28/01/2016 10:37 PM
tests_time_swf_VHDL-1.1.89_FSW-3.0.0.15_2016_01_28 (220 KB) tests_time_swf_VHDL-1.1.89_FSW-3.0.0.15_2016_01_28 thomas chust, 28/01/2016 10:37 PM
README (73 Bytes) README thomas chust, 28/01/2016 10:38 PM
plot_delta_SWF_F2.png (187 KB) plot_delta_SWF_F2.png thomas chust, 01/02/2016 08:33 AM
plot_delta_SWF_F1.png (184 KB) plot_delta_SWF_F1.png thomas chust, 01/02/2016 08:33 AM
plot_delta_SWF_F0.png (187 KB) plot_delta_SWF_F0.png thomas chust, 01/02/2016 08:33 AM
tests_time_swf_VHDL-1.1.89_FSW-3.0.0.15_2016_01_28_bis (115 KB) tests_time_swf_VHDL-1.1.89_FSW-3.0.0.15_2016_01_28_bis thomas chust, 01/02/2016 08:39 AM
Actions #1

Updated by Veronique bouzid about 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

Actions #2

Updated by thomas chust about 8 years ago

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 <>
Pour : Thomas Chust <>
Copie à : Bruno Katra <>

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

Actions #3

Updated by thomas chust about 8 years ago

  • Assignee set to paul leroy
  • Priority changed from Normal to High
Un petit bémol après quelques réflexions avec Bruno:
  • 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 ...)

Actions #4

Updated by thomas chust about 8 years ago

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 ?

Actions #5

Updated by paul leroy about 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.

Actions #6

Updated by thomas chust about 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?

Actions #7

Updated by paul leroy about 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.

Actions #8

Updated by bruno katra about 8 years ago

  • Status changed from New to Closed

Version intermédiaire. Bugs corrigés dans les versions > à livrer au LESIA

Actions

Also available in: Atom PDF