Star-fst-l mailing list

[Tonko Ljubicic <tonko AT bnl.gov>]

Note another complication:

You _must_ take a pedestal run after you switched to 9 timebins
and then again once you switch back to 3.


On Tue, Jun 20, 2023 at 5:13 PM Visser, Gerard <gvisser AT indiana.edu> wrote:
>
> 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
>
>
>
> _______________________________________________
> Star-fst-l mailing list
> Star-fst-l AT lists.bnl.gov
> https://lists.bnl.gov/mailman/listinfo/star-fst-l