Project

General

Profile

Actions
Copy link

Bug #382

open

petite irrégularité de temps pour les CWF à F2 ?

Added by thomas chust over 9 years ago. Updated over 9 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
thomas chust
Category:
-
Target version:
-
Start date:
10/04/2015
Due date:
% Done:

0%

Estimated time:
revision:
r0

Description

Des tests ont été fait avec pas mal de fichiers durant les procédures automatiques de calibration/étalonnage.
Le cas considéré ici est un ctc-6: balayage en fréquence où on enregistre 96 fichiers CWF à F2 comprenants chacun 24 paquets de 336 échantillons. Voir les fichiers joints.

Avec la configuation FSW = 2.0.2.3 et VHDL = 1.1.68 on observe:
- les temps des paquets de 336 échantillons sont bien séparés de 86016 2^-16 s [336 / 256/ 2^-16] à 2^-16 s près
- SAUF entre le 8ème et 9ème paquet où on observe des valeurs allant de 86003 à 86006 fine times,
- et SAUF entre le 16ème et le 17ème paquet où on observe la même irrégularité.

Si j'ai bien compris, 8 paquets correspond à un buffer plein (2688=8*336), et il semblerait que la datation du premier paquet de chaque buffer est légèrement erroné, de l'ordre de 10 fine times (~ 150 micro secondes) ?

Files

Download all files
calibration_cwf_2015_03_24_ctc-006_noecho000.txt (549 KB) calibration_cwf_2015_03_24_ctc-006_noecho000.txt thomas chust, 11/04/2015 12:34 AM
ctc006_2015_03_24-14_27_33.pdf (127 KB) ctc006_2015_03_24-14_27_33.pdf thomas chust, 11/04/2015 12:34 AM
Actions
Copy link
 #1

Updated by paul leroy over 9 years ago

  • Status changed from New to Feedback
  • Assignee changed from paul leroy to thomas chust

Une salve de 8 paquets, correspondant à 2688 points, est stockée dans LFR sous forme d'un buffer de données et d'une information de temps. Cette unique information de temps est utilisée pour calculer les acquisition_time des 8 paquets de la salve, ce qui explique qu'entre les 8 paquets de la salve, le delta soit parfait mais qu'entre le premier paquet d'une salve et le premier paquet de la salve suivante, il puisse y avoir un décalage (quand on utilise le timegen, sinon, tout est censé être identique).

Le décalage est supérieur comparé à l'erreur relevée sur les CWF_F1 (10 fine_time au lieu de 2) parce qu'il s'écoule plus de temps entre les deux buffers (10.5 secondes au lieu de 656.25 ms).

Actions
Copy link
 #2

Updated by thomas chust over 9 years ago

  • Assignee changed from thomas chust to paul leroy

Ok. Mais même remarque que pour les données CWF_F1 (#383). Pourquoi un rattrapage de 150 micro seconde d'un coup? 150e-6 / 10.5 ~ 1.4e-5 > 1e-6 => dérive supérieure à 1 pour 1 million ?

Actions
Copy link
 #3

Updated by paul leroy over 9 years ago

  • Status changed from Feedback to Resolved
  • Assignee changed from paul leroy to thomas chust

Se référer à #441, qui reprend les constatations liées aux dérives de synchronisation.

Actions
Copy link

Also available in: Atom PDF