Bug #518
open
synchronisation F3-F2-F1-F0
0%
Description
D'autres observations sont nécessaires pour confirmer la stabilité du décalage temporel décrit ci-dessous. Il faut confirmer aussi qu'un décalage entre F1 et F0 obéit à une logique semblale: avance de F1 sur F0 de ~T1/2.
Jean-Christophe pense qu'il s'agit d'une erreur dans le VHDL de comptage des registres temporels. S'il s'agit bien de cela, les décalages devraient être fixes. A priori il pourrait y avoir une différence entre ce qui a été observé ici sur le l'EM (VHDL 1.1.89 FSW 3.0.0.8) et ce que l'on observera sur le RTAX (VHDL 3.1.89) car sur l'EM il n'y en fait pas de filtre après les CIC ...
Le 29/09/2015 10:43, Thomas Chust a écrit :
Salut Paul,
Les mesures à f3 n'ont rien donné car nous n'avons enregistré qu'un seul buffer. Et donc le temps indiqué (zéro) n'est pas utilisable ...Par contre la comparaison entre f2 et f1-f0 montre une avance de f2 sur f1-f0 d'environ T2/2 (au lieu d'un retard d'~T2 observé avec VHDL 1.1.83 FSW 3.0.0.8). Ci-joint trois plots (2015_09_25 ...) montrent ce décalage, dans la cas d'un sinus et dans le cas d'une rampe à 1Hz et dans le cas d'un sinus à 24Hz.
J'ai refais des mesures hier que je suis en train d’analyser et qui jusqu'à présent confirme cela. Cela semble donc être stable et reproductible (VHDL 1.1.89 FSW 3.0.0.8). Pour f3 je trouve un décalage qui suit la même logique: c'est en avance de ~T3/2. Voir les deux plots joints (2015_09_28 ...).
Par contre je m'interroge sur le fait que le premier échantillon f3 (cwf mode normal_long) puisse être daté plus de 100s avant le premier échantillon f2 (swf mode normal toute les 16s) ?
a+
ThomasLe 29/09/2015 08:48, paul leroy a écrit :
Qu'ont donné les mesures qu'on a faites vendredi?
J'ai réfléchi à un truc pour les mitigations SWA/PAS. Une matrice occupe 12800 octets en mémoire (25*128*4). C'est pas impossible qu'on puisse stocker 2 secondes entières de matrices à f0, f1 et f2, et enlever du calcul les matrices qui seraient identifiées comme polluées sur la base des informations transmises par SWA/PAS.
Le 09/26/2015 09:39 AM, Thomas Chust a écrit :
Salut Jean-Christophe,
L'objet de mes questions hier à propos de la synchro entre f0, f1, f2 et f3 était ce message d'Emmanuel G. et ses observations. Sur le moment j'ai peut-être répondu un peu trop rapidement ...
A lundi
Thomas
-------- Message transféré --------
Sujet : Re: Synchronisation F1-F2
Date : Tue, 22 Sep 2015 17:35:17 +0200
De : Thomas Chust <thomas.chust@lpp.polytechnique.fr>
Pour : Guilhem Emmanuel (ALTRAN TECHNOLOGIES) <emmanuel.guilhem@cnes.fr>
Copie à : nicolas briand <nicolas.briand@lpp.polytechnique.fr>, Vincent Leray <vincent.leray@nexeya.com>, Alexis Jeandet <alexis.jeandet@lpp.polytechnique.fr>, moustapha.dekkali@obspm.fr <moustapha.dekkali@obspm.fr>, Pontet Bernard <Bernard.Pontet@cnes.fr>, Sanisidro Julien <Julien.Sanisidro@cnes.fr>, Bruno Katra LPP <bruno.katra@lpp.polytechnique.fr>Salut Emmanuel,
Merci pour cette jolie observation mais a priori cela n'est pas anormal. Les filtrages numériques introduisent des déphasage en fonction de la fréquence. Ces derniers ne sont a priori pas identiques selon les fréquences de décimation f0, f1 et f2. Plus courte est la fréquence de coupure, plus grand est le retard de phase. Le signal f2 est donc celui qui serait le plus déphasé (en retard) sur les autres (f1 ou f0).
L'objet de la détermination des fonctions de transfert à f0, f1, f2 et f3 de LFR seul, en amplitude et phase, a justement pour objet la possibilité de "détordre" ces données. On doit justement prochainement avancer avec Bruno pour passer à la calibration de la réponse en fréquence de la phase ...
A bientôt
ThomasLe 22/09/2015 15:13, Guilhem Emmanuel (ALTRAN TECHNOLOGIES) a écrit :
Bonjour Thomas,
Je t’envoie un résultat de test en pièce jointe. Il s’agit de la synchro entre F1 et F2, nous le vérifions lorsque nous testons la synchro entre TDS et LFR. Sur ces fichiers, vous pourrez constater qu’il y a un gros phase shift entre la mesure F2 et la mesure F1, ce décalage dépend de la fréquence. La configuration de LFR était E1=V12_DC, donc il n’est pas sensé y avoir de filtrage, ce qui pourrait induire un phase shift.
Les mesures de synchro entre F0 et F1 sont bonnes comme tu peux le voir en pièce jointe.
Qu’en penses-tu? Est-ce calibrable ? le phase shift atteint quand même presque 90° aux basses fréquences.
Merci pour ton retour,
Emmanuel Guilhem (ALTRAN)
RPW
Téléphone : (+ 00 33) 5 61 28 76 04
E-mail : emmanuel.guilhem@cnes.fr
Files
Updated by thomas chust about 9 years ago
Par contre je m'interroge sur le fait que le premier échantillon f3 (cwf mode normal_long) puisse être daté plus de 100s avant le premier échantillon f2 (swf mode normal toute les 16s) ?
Cela est en fait parfaitement normal: les données cwf_f3 étant datées seulement toutes les 168 s (correspondant à un buffer plein) il n'y a généralement pas coïncidence avec le début de l'enregistrement des données swf_f2 à 16 s ...
Updated by thomas chust about 9 years ago
- File 2015_09_28_15_15_24_SWF_E2_snap1_100Hz_zoom.png 2015_09_28_15_15_24_SWF_E2_snap1_100Hz_zoom.png added
D'autres observations sont nécessaires pour confirmer la stabilité du décalage temporel décrit ci-dessous. Il faut confirmer aussi qu'un décalage entre F1 et F0 obéit à une logique semblale: avance de F1 sur F0 de ~T1/2.
D'autres observations faites sur l'EM (VHDL 1.1.89 FSW 3.0.0.8) confirme l'avance observée de F2 sur F0-F1 (de l'ordre de T2/2) ainsi que celle de F3 sur F2 (de l'ordre de T3/2). Par contre ce qui est observé entre F1 et F0 suit une autre logique: F1 est en retard sur F0 de l'ordre de T1/2 (un exemple est montré dans le fichier joint)
Updated by paul leroy about 9 years ago
- Assignee changed from paul leroy to thomas chust
Thomas, il faudrait mettre Jean-Christophe sur le coup.
Au niveau du logiciel de vol, je peux configurer le démarrage des acquisitions, mais la date d'acquisition (acquisition_time) est donné par la partie VHDL. C'est à dire que'on pourrait avoir des snaphsots non centrés par la faute du logiciel de vol, qui aurait mal configuré les démarrages, mais les données devraient quand même être correctement datées. Je ne pense pas que ça vienne du logiciel.
Updated by thomas chust about 9 years ago
Thomas, il faudrait mettre Jean-Christophe sur le coup.
Au niveau du logiciel de vol, je peux configurer le démarrage des acquisitions, mais la date d'acquisition (acquisition_time) est donné par la partie VHDL. C'est à dire que'on pourrait avoir des snaphsots non centrés par la faute du logiciel de vol, qui aurait mal configuré les démarrages, mais les données devraient quand même être correctement datées. Je ne pense pas que ça vienne du logiciel.
Oui cela est déjà fait (cf la description) et Jean-Christophe est d'accord pour dire qu'il y a a posteriori une erreur dans son comptage des temps sous VHDL. A l'heure actuelle (livraison du pFM) l'important est de vérifier que cette erreur produit toujours le même effet, ce qui semble bien être le cas jusqu'à présent.
Updated by thomas chust about 9 years ago
- File 2015_10_02_12_10_09_SWF_B2_snap1_12Hz.png 2015_10_02_12_10_09_SWF_B2_snap1_12Hz.png added
- File 2015_10_02_13_10_23_SWF_B3_snap1_100Hz_zoom.png 2015_10_02_13_10_23_SWF_B3_snap1_100Hz_zoom.png added
Jean-Christophe pense qu'il s'agit d'une erreur dans le VHDL de comptage des registres temporels. S'il s'agit bien de cela, les décalages devraient être fixes. A priori il pourrait y avoir une différence entre ce qui a été observé ici sur le l'EM (VHDL 1.1.89 FSW 3.0.0.8) et ce que l'on observera sur le RTAX (VHDL 3.1.89) car sur l'EM il n'y en fait pas de filtre après les CIC ...
Justement les dernières mesures faites avec l'EQM2 (VHDL 3.1.89 FSW 3.0.0.8) montrent des résultats tout à fait semblables à ceux obtenus sur l'EQM1 (VHDL 1.1.83 FSW 3.0.0.8): retard de f2 sur f1-f0 de l'ordre de T2 ainsi qu'un retard de f1 sur f0 de l'ordre de T1/2 (voir les fichiers joint).
CONCLUSION : entre le VHDL 83 et 89 il y a un stabilité dans la façon de dater les données et la différence observée entre le 1.1.89 et le 3.1.89 serait exclusivement due à l'absence des filtres IRR après les filtres CIC dans le 1.1.89 (oublie de J-C pour raison de place ...). Or ces filtres CIC ne concernent que les données f3 et f2, ce qui est cohérent avec une datation identique des données f1-f0 dans tous les cas de figure. Ce dernier point sera à confirmer avec la comparaison des données f3-f2 sous VHDL 3.1.89 ...
Updated by thomas chust about 9 years ago
- File 2015_10_06_16_47_41_SWF_B3_snap21_1Hz_bis.png 2015_10_06_16_47_41_SWF_B3_snap21_1Hz_bis.png added
- File 2015_10_06_16_47_41_SWF_B3_snap21_1Hz_zoom.png 2015_10_06_16_47_41_SWF_B3_snap21_1Hz_zoom.png added
- File 2015_10_06_16_47_41_SWF_B3_snap21_1Hz.png 2015_10_06_16_47_41_SWF_B3_snap21_1Hz.png added
- Status changed from New to Feedback
Il y a confirmation : la comparaison des données f3 et f2 sur l'EQM2 (VHDL 3.1.89 FSW 3.0.0.10) montre un clair retard de f3 sur f2 de l'ordre de T3. Voir les fichiers joints.
CONCLUSION / SYNTHESE : sur le PFM (VHDL 3.1.89) on s'attendra à avoir les décalages temporels fixes suivant:
- retard de ~T1/2 de f1 sur f0
- retard de ~T2 de f2 sur f1-f0
- retard de ~T3 de f3 sur f2-f1-f0