Fine time means greater accuracy than the system clock of 25 ns YES Here are some reasons we need to match identified kaons in CEDAR with measured particles in GTK there will be often more than one ID: 635950
Download Presentation The PPT/PDF document "Do we need fine time in NA62?" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
Do we need fine time in NA62?
Fine time means greater accuracy than the system clock of 25 ns.
YES
Here are some reasons
we need to match identified
kaons
in CEDAR with measured particles in GTK
there will be often more than one
kaon
in our system within a 25 ns time slot and we should be able to match the observed pion with one of those two
kaons
identified by CEDAR and measured by GTK, so we need fine time also in other detectors
From the NA62TD:
The guiding principles for the construction of the NA62 detectors are, therefore: accurate kinematic reconstruction,
precise particle timing
, efficiency of the vetoes and excellent particle identification. Slide2
We need fine time in NA62
How shall we handle it?
From NA62 TD:
A
common time scale is defined by a 32-bit timestamp word, with 25 ns LSB and covering the full duration of the interval between two consecutive SPS spills, plus an 8-bit fine time word, with
100ps
LSB. While the timestamp will be defined in each system by the phase-coherent distributed clock, each sub-system will locally generate by multiplication a properly locked reference for the fine time.
Note: 32bit of 25 ns ticks is roughly 107 seconds, enough to label 25 ns time slots within one spill.
Note:
rx
chip by itself does not have 32 bit BC counter, the 32 bits should be provided by firmwareSlide3
We
need to match identified
kaons
in CEDAR with measured particles in GTK Problem in GTK: there is 750MHz of particles, that is on average 1 particle per 1 ns (very crude!)So time stamping should be much better than 1 ns in both CEDAR and GTK to match the reading of the two.Conclusion we need 100 ps time stamping in CEDAR and GTKAnd we need to learn how to synchronize those fine time stamps.
CEDAR GTK matchingSlide4
Stability
is a key word. So investigation of stability of all the procedures mentioned above is essential to adopt it as a working scheme.
What concerns the BC clock we assume that every subdetector sends info after SOB and after EOB, and comparing those two we check that BC offsets are stable during one spill.
What concerns the fine time, we are not aware of any similar procedure. If we manage somehow to find correct synchronizing offsets between various nodes (for example by some offline statistical analysis), we should also check for stability somehow, maybe for each spill, maybe for each run. Slide5
TDCB and fine time
Fine time stamp is assigned by the TDCB for each event, but there seems to be no way to read the TDCB "fine time counter" by some outer command independent of the event. This makes synchronization difficult. One can always use sparse beam and obtain fine time stamps for the same particle in every node.
One can perhaps do some off-line statistical analysis also for the dense beam. But there will be certain asymmetry in the level of care for the BC clock synchronization stability and the fine time synchronization stability.
So before ordering a massive production of TDCB's we perhaps should give a second thought whether we really do not need access to its internal "fine time clock" form outside.