<div dir="ltr">Sean,<div><br></div><div>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?</div><div><br></div><div>-Richard Jones</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 16, 2017 at 2:50 PM, Sean Dobbs <span dir="ltr"><<a href="mailto:s-dobbs@northwestern.edu" target="_blank">s-dobbs@northwestern.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr" class="m_1674854468471325440gmail_msg">Richard,<div class="m_1674854468471325440gmail_msg"><br class="m_1674854468471325440gmail_msg"></div><div class="m_1674854468471325440gmail_msg">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.</div><div class="m_1674854468471325440gmail_msg"><br class="m_1674854468471325440gmail_msg"></div><div class="m_1674854468471325440gmail_msg">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.</div></div><div dir="ltr" class="m_1674854468471325440gmail_msg"><div class="m_1674854468471325440gmail_msg"><br></div><div class="m_1674854468471325440gmail_msg"><br></div><div class="m_1674854468471325440gmail_msg">Cheers,<br>Sean<br class="m_1674854468471325440gmail_msg"><div class="m_1674854468471325440gmail_msg"><br class="m_1674854468471325440gmail_msg"><div class="gmail_quote m_1674854468471325440gmail_msg"><span class=""><div dir="ltr" class="m_1674854468471325440gmail_msg">On Wed, Mar 15, 2017 at 5:06 PM Richard Jones <<a href="mailto:richard.t.jones@uconn.edu" class="m_1674854468471325440gmail_msg" target="_blank">richard.t.jones@uconn.edu</a>> wrote:<br class="m_1674854468471325440gmail_msg"></div></span><blockquote class="gmail_quote m_1674854468471325440gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">



<div class="m_1674854468471325440gmail_msg">
<div dir="ltr" class="m_1674854468471325440gmail_msg">Sean,
<div class="m_1674854468471325440gmail_msg"><br class="m_1674854468471325440gmail_msg">
</div>
<div class="m_1674854468471325440gmail_msg">Have a look at <a href="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=" class="m_1674854468471325440gmail_msg" target="_blank">https://logbooks.jlab.org/<wbr>entry/3402982</a>.
 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.</div>
<div class="m_1674854468471325440gmail_msg"><br class="m_1674854468471325440gmail_msg">
</div>
<div class="m_1674854468471325440gmail_msg">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.</div>
<div class="m_1674854468471325440gmail_msg"><br class="m_1674854468471325440gmail_msg">
</div>
<div class="m_1674854468471325440gmail_msg">Comments on this would be welcome.</div>
<div class="m_1674854468471325440gmail_msg"><br class="m_1674854468471325440gmail_msg">
</div>
<div class="m_1674854468471325440gmail_msg">-Richard J.</div>
</div></div></span><div class="m_1674854468471325440gmail_msg">
<div class="gmail_extra m_1674854468471325440gmail_msg"><br class="m_1674854468471325440gmail_msg">
<div class="gmail_quote m_1674854468471325440gmail_msg"><span class="">On Wed, Mar 15, 2017 at 4:04 PM, Sean Dobbs <span dir="ltr" class="m_1674854468471325440gmail_msg">
<<a href="mailto:s-dobbs@northwestern.edu" class="m_1674854468471325440gmail_msg" target="_blank">s-dobbs@northwestern.edu</a>></span> wrote:<br class="m_1674854468471325440gmail_msg">
</span><div><div class="h5"><blockquote class="gmail_quote m_1674854468471325440gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr" class="m_1674854468471325440gmail_msg">Hi Richard,
<div class="m_1674854468471325440gmail_msg"><br class="m_1674854468471325440gmail_msg">
</div>
<div class="m_1674854468471325440gmail_msg">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.</div>
<div class="m_1674854468471325440gmail_msg"><br class="m_1674854468471325440gmail_msg">
</div>
<div class="m_1674854468471325440gmail_msg">Thanks,<br class="m_1674854468471325440gmail_msg">
Sean</div>
</div>
</blockquote>
</div></div></div>
<br class="m_1674854468471325440gmail_msg">
</div>
</div></blockquote></div></div></div></div></div>
</blockquote></div><br></div>