Star-fst-l mailing list

["Visser, Gerard" <gvisser AT indiana.edu>]

Hi Ziyue.

Roughly speaking the fixed deadtime will have to be increased by a factor of three, if it is really optimized right now. For the record Tonko says that the fixed deadtime setting right now is 300 (RHIC strobe tics). I am trying to find my notes or recalculate the required deadtime change for going from 3 timebin to 9 timebin APV readout, I'll reply on that soon.

The higher data volume of 9-timebin will also impose a hard ceiling on the rate. This was discussed a long time ago on FST mailing list; likewise I'm going to have to do some digging to find the number and will reply when I can.

Flemming (I think it was) asked for a brief summary of what the apparent problem that we want to check on with this 9 timebin running to be sent to starops (or triggerboard?). I agree that is a very good idea. It would really be beneficial to have some statement about any real problem observed in the data, beyond merely an observation that the 'max timebin' plots seem unstable. It would also be good to have some statement about if this is definitely different than last year, or definitely different than IST.

I think that 9-timebin running, which is the FST way of "pre/post" running, should give a confirmation that the timing is really properly set, and it should give more insights into any instability in the timing if there is an instability during the time period that we run 9-tb. Since there will be a cost to such running we will have to be careful to run only as long as really needed.

I can't think of any mechanism which would cause the timing of APV sampling to drift. A particular broken FEE or broken ARM module perhaps, but the observation is more widespread than that, if I understand right. I still mainly suspect that the 3-timebin 'max timebin' plot is influenced by something else than a drift of the sampling time - background or some difference between triggers or the pulse shapes are just not constant enough or something. None of which (I think) would really directly be a problem for FST data quality. Of course I may be completely wrong here. It would be excellent to have some kind of tracking result from current FST data to try to judge if it is working correctly or not, but I appreciate that is a huge ask.

      Gerard

---

From: Star-fst-l <star-fst-l-bounces AT lists.bnl.gov> on behalf of Ziyue Zhang <zzhan70 AT uic.edu>
Sent: Tuesday, June 20, 2023 10:44 AM
To: Star-fst L <star-fst-l AT lists.bnl.gov>
Subject: [Star-fst-l] FST with 9 Time Bins Diagnostic

 

Hello all,

We discussed the FST timing drift issue in this morning's (June 20) meeting and proposed to switch to 9 time-bin temporarily for diagnostic purposes. In the daily ops meeting, it was brought up that this will influence the deadtime of many triggers, and therefore it does not come for free. 

Gerard, I only have a general idea on the trigger dead time topic. Do you have any comments on this?

Therefore we should estimate how long this diagnostic is going to take and discuss what exactly we need to look at, then we can switch to 9 time-bin and do the diagnostic as efficiently as possible.

Best,

Ziyue