[Halld-tagger] F1TDC unlocking

[Richard Jones]

Sean,

The reason that shifts of this size are not seen in the data is that the
values read out by the DAQ are differences between the clock on each input
channel and the trigger clock. Each chip records a trigger time that
applies to all of its inputs, in addition to the individual times for each
channel, and only the difference is reported. The only thing that is
relevant, then, is the clock RATE because the same clock is measuring both
trigger and channel stops. The internal oscillator inside each F1 chip
counts at a rate that can swing quite a bit depending on exact voltage,
temperature, and the chip characteristics. However, the F1 has inside it a
phase-locked feedback circuit that watches a 32-ns global clock that is
distributed to all of the crates and adjusts an internal voltage on its
internal oscillator to keep its clock phase-locked to the reference. If
that lock lets go then the natural variation in the internal clock takes
over and you might see differences up to 1ns over a time difference of
several hundred ns channel-to-channel between the trigger and stop times
for events that occur at the same time. What my algorithm does is to
compare the internal chip clock for each chip to the accelerator RF and
does a phase-locked loop to that oscillator in software. So I always know
what the difference is between the free-running (hardware) clock on any
given chip is and my phase-locked stable copy of it in software. Of course,
my software phase-locked loop can also lose its lock if enough time goes by
without any hits in a given chip. Normally within a run the breaks would
not be so large that my algorithm would come unlocked, but even if it did
it would immediately regain its lock after 2-3 events have gone by and so
not much effect would be seen from this. Does that make sense?

-Richard Jones

On Thu, Mar 16, 2017 at 2:50 PM, Sean Dobbs <s-dobbs at northwestern.edu>
wrote:

> Richard,
>
> Thanks a lot for this information, I'll need some time to properly digest
> it, but your procedure looks very promising.  It sounds like we could
> implement this algorithm in sim-recon with a minimum of CCDB overhead and
> not too many unintended consequences.
>
> I am trying to understand how, if the F1TDC clocks are only synced at the
> beginning of a run, how drifts of several microseconds in oscillator phase
> over a run would affect the time values that are read out, since we don't
> see shifts in the data of that order of magnitude.
>
>
> Cheers,
> Sean
>
> On Wed, Mar 15, 2017 at 5:06 PM Richard Jones <richard.t.jones at uconn.edu>
> wrote:
>
> Sean,
>
> Have a look at https://logbooks.jlab.org/entry/3402982
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__logbooks.jlab.org_entry_3402982&d=DwMFaQ&c=yHlS04HhBraes5BQ9ueu5zKhE7rtNXt_d012z2PA6ws&r=y4ZD58I4nPR6tZqjerSGt-WlWVAhqa3FHDMXqQ_5aUc&m=09MvkOczQccGClGUIt1BklAlceyXdeDxgPnQrcmNCLw&s=YfnC3Cv0pyApqlOSRKzZsPo9rFonYhkNpIMh3koabwE&e=>.
> In that exercise, I was trying to use the tdc hit spectra in the TAGM to
> compute a high-resolution Fourier transform of the beam time structure, and
> look for harmonics associated with other halls than hall d. In the process,
> I needed to establish a "standard clock" whose phase is locked to the
> accelerator clock and delivers a ps-resolution time for every hit from a
> single clock running continuously over a period of days starting at some
> instance, say for instance, 12:00 noon on Tuesday. By late in the week,
> this clock has seen 1e17 ps go by, so I was looking for a precision of a
> part in 1e17, which is a challenge to try to do. I do not pretend that the
> machine clock has absolute accuracy of a part in 1e17, but using that clock
> to define the scale of time, to measure events in the hall to that kind of
> precision. In order to achieve this, I had to continuously update the
> free-running oscillator in the F1TDC of every card I was monitoring and
> keep track of its phase wrt the master clock. The details are in that
> logbook entry, but basically it presents an algorithm for using the rf
> measurements in the PS events (or any other continuous stream of events) to
> continuously track the drifts in the internal F1TDC oscillator. As you can
> see, even when it is locked, it drifts by several microseconds over a
> period of a run, as shown in the plots in that logbook entry.
>
> The job I was trying to do is more challenging in some ways, but the
> problem we have when the F1TDC chip comes out of lock is solved by the same
> procedure I think, provided that the fluctuations in the unlocked clock are
> not too large, where "large" means greater than 32 ns of drift from one
> event to the next. As long as the drift is only a few ns between events,
> this procedure will take care of it. What you will get out is an average
> rate of this clock since the last event, which at reasonably high trigger
> rate compared to the drift time can be continuously averaged to give a high
> resolution updated estimate for the instantaneous clock period of the
> unlocked F1TDC oscillators.
>
> Comments on this would be welcome.
>
> -Richard J.
>
> On Wed, Mar 15, 2017 at 4:04 PM, Sean Dobbs <s-dobbs at northwestern.edu>
> wrote:
>
> Hi Richard,
>
> You mentioned at the analysis meeting today that you had a mitigation for
> the F1TDC unlocking problem, would you mind explaining more about it?  I
> haven't fully understood the ramifications of what is happening with the
> chips when this happens.
>
> Thanks,
> Sean
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jlab.org/pipermail/halld-tagger/attachments/20170316/967c6650/attachment.html>