Star-fst-l mailing list

["Landgraf, Jeffery M." <jml AT bnl.gov>]

I think FST just saturates at 1450hz.   If you try to shove more data through (fcsDY at 20khz) then the deadtime goes up but nothing else changes.  (well, fscDY starves out all other triggers.)

-Jeff

---

From: Visser, Gerard <gvisser AT indiana.edu>
Sent: Monday, December 20, 2021 10:01 PM
To: Xu Sun <sunxuhit AT gmail.com>; Ogawa, Akio <akio AT bnl.gov>
Cc: Landgraf, Jeffery M. <jml AT bnl.gov>; Ljubicic,Ante <tonko AT bnl.gov>; Aschenauer, Elke <elke AT bnl.gov>; Star-fst L <star-fst-l AT lists.bnl.gov>
Subject: Re: [Star-fst-l] FST deadtime and raw events in the data stream

 

No - trigger was 87% dead in 22354057.

There is an FCS trigger problem. I don't know the recipe to fix, but certainly a reboot FCS MIGHT help. Do we have other crew instructions for FCST trigger problems? 

     Gerard

---

From: Xu Sun <sunxuhit AT gmail.com>
Sent: Monday, December 20, 2021 9:57 PM
To: Visser, Gerard <gvisser AT indiana.edu>
Cc: jml AT bnl.gov <jml AT bnl.gov>; Tonko Ljubicic <tonko AT bnl.gov>; Aschenauer Elke-Caroline <elke AT bnl.gov>; Star-fst L <star-fst-l AT lists.bnl.gov>
Subject: Re: [Star-fst-l] FST deadtime and raw events in the data stream

 

When excluding FST, everything else seems running fine without any noticeable deadtime.

Best,

Xu

On Mon, Dec 20, 2021 at 9:54 PM Visser, Gerard <gvisser AT indiana.edu> wrote:

What has had deadtime when you excluded FST? I think something must have, under this condition???

    GV

---

From: Xu Sun <sunxuhit AT gmail.com>
Sent: Monday, December 20, 2021 9:50 PM
To: Visser, Gerard <gvisser AT indiana.edu>
Cc: jml AT bnl.gov <jml AT bnl.gov>; Tonko Ljubicic <tonko AT bnl.gov>; Aschenauer Elke-Caroline <elke AT bnl.gov>; Star-fst L <star-fst-l AT lists.bnl.gov>
Subject: Re: [Star-fst-l] FST deadtime and raw events in the data stream

 

Hi Gerard,

Just to make it more clear, when including FST, the rate is about 1.5kHz and FST is 96% dead.

If exclude FST, the rates for the rest will be 4.5kHz.

FST could have 1.5kHz rates with 20% dead this morning and I don't think we changed anything about FST today.

Best,

Xu

On Mon, Dec 20, 2021 at 9:48 PM Visser, Gerard <gvisser AT indiana.edu> wrote:

I see. Well 4.5kHz would be pretty challenging anyway although of course it would be better if we had reduced the timebins before, I am sorry.

I don't know how to best proceed, but I'm adding Jeff in reply here, can you or other experts offer any advice? Maybe the FST can be taken out of one trigger (fcsDY?) if it is not yet a physics trigger anyway, just to get through the night more productively for all? Crew should not make any change on my suggestion alone, to be clear. I am not sure what will be best.

     Gerard

---

From: Xu Sun <sunxuhit AT gmail.com>
Sent: Monday, December 20, 2021 9:29 PM
To: Visser, Gerard <gvisser AT indiana.edu>
Cc: Tonko Ljubicic <tonko AT bnl.gov>; Aschenauer Elke-Caroline <elke AT bnl.gov>; Star-fst L <star-fst-l AT lists.bnl.gov>
Subject: Re: [Star-fst-l] FST deadtime and raw events in the data stream

 

Hi Gerard and Tonko,

It seems like the trigger rate for tonight's run is about 4.5kHz and FST is 100% dead if included.

We didn't find a time this afternoon to reduce the time bin.

What should we do now?

Best,

Xu

On Sun, Dec 19, 2021 at 2:12 PM Xu Sun <sunxuhit AT gmail.com> wrote:

Hi Gerard,

Thanks for the suggestion. 

It might be better to discuss this topic in tomorrow's FST meeting as Flemming suggested.

Could you please join the discussion tomorrow?

Best,

Xu

On Sun, Dec 19, 2021 at 2:02 PM Visser, Gerard <gvisser AT indiana.edu> wrote:

hi Xu,

So if we use just a single timbin then I think we should seriously consider running 3 tb instead of 4 tb. One consideration is that the APV chips always read 3*N timebins, so the fixed deadtime can be much lower for 3 timebins than for 4. In 4 timebin modes the APV sends data for 6 and we ignore the last 2.

On a separate note, I think it might be worth checking the performance difference between selecting for each hit the max timebin -- I think this is what you are doing?? -- versus using a fixed timebin always which you have selected as being the right one for that APV group to get the maximum of the pulse. There's probably a difference, e.g. in effect of pileup hits at the least. But anyway, you certainly don't want to select max over a wide range that is only going to bring in more pileup and noise, so to study which way is better you don't need many timebins stored.

     Gerard

---

From: Xu Sun <sunxuhit AT gmail.com>
Sent: Sunday, December 19, 2021 1:53 PM
To: Visser, Gerard <gvisser AT indiana.edu>
Cc: Tonko Ljubicic <tonko AT bnl.gov>; Aschenauer Elke-Caroline <elke AT bnl.gov>; Star-fst L <star-fst-l AT lists.bnl.gov>
Subject: Re: [Star-fst-l] FST deadtime and raw events in the data stream

 

Hi Gerard,

> What do you think about 4 timebins?

I believe the reason to use 9 time bin is to tune the latency, and that has been done.

So we should be fine to switch to 4 timebins.

> Is there a fit to the peak of the pulse, or a sum over an interval, or we just use a single timebin, or what?

We use the time bin with the maximum ADC for the hit reconstruction.

Best,

Xu

On Sun, Dec 19, 2021 at 1:32 PM Visser, Gerard <gvisser AT indiana.edu> wrote:

hi Xu,

    What do you think about 4 timebins? Are you guys planning to study different ways of using the 9 timebin data, e.g. comparing tracking resolution somehow using / not using data from more than the middle 4 timebins? By the way, how do we use the data now in the baseline plan? Is there a fit to the peak of the pulse, or a sum over an interval, or we just use a single timebin, or what?

   If there's no real study planned with the extra 5 timebins pre/post of the middle 4, then we should change to 4 tb and change latency of course to get those middle 4. Or maybe even go to 3 tb?

    Gerard

---

From: Xu Sun <sunxuhit AT gmail.com>
Sent: Sunday, December 19, 2021 1:26 PM
To: Tonko Ljubicic <tonko AT bnl.gov>
Cc: Visser, Gerard <gvisser AT indiana.edu>; Aschenauer Elke-Caroline <elke AT bnl.gov>; Star-fst L <star-fst-l AT lists.bnl.gov>
Subject: Re: [Star-fst-l] FST deadtime and raw events in the data stream

 

Hi Tonko,

As discussed in today's meeting, I am done with the ADC timing adjustment and we should be good to set the ratio to 1:100.

Best,

Xu

On Sun, Dec 19, 2021 at 4:14 AM Tonko Ljubicic <tonko AT bnl.gov> wrote:

Hello,

I had a few private emails with Xu so we left it at 1:5 for yesterday
but right now we are again dominated by FSTs data volume
(deadtime 35% at 1300 Hz) so I will cut it down to 1:20
and then to 1:100 e.g. tomorrow.

IMHO, we should set the steps still needed before we switch to
4 timebin readout.

           -- Tonko



On Fri, Dec 17, 2021 at 9:12 PM Xu Sun <sunxuhit AT gmail.com> wrote:
>
> Hi Tonko, All,
>
> We should have enough non-zs data, switching back to 1 to 100 should be fine for us.
>
> Best,
>
> Xu
>
> On Fri, Dec 17, 2021 at 9:29 AM Visser, Gerard <gvisser AT indiana.edu> wrote:
>>
>> I see no reason to have so much non-ZS. If a test run needs more e.g. to check the ADC timing, it can be changed for one run and then put back. But this even is probably not necessary.
>>
>>       Gerard
>>
>> ________________________________
>> From: Star-fst-l <star-fst-l-bounces AT lists.bnl.gov> on behalf of Aschenauer Elke-Caroline <elke AT bnl.gov>
>> Sent: Friday, December 17, 2021 9:25 AM
>> To: Tonko Ljubicic <tonko AT bnl.gov>
>> Cc: Star-fst L <star-fst-l AT lists.bnl.gov>
>> Subject: Re: [Star-fst-l] FST deadtime and raw events in the data stream
>>
>> As we are planning to get up in lumi, we need to change this, so the FST group should think what they need and why
>>
>> Cheers elke
>>
>> On Dec 17, 2021, at 09:15, Tonko Ljubicic <tonko AT bnl.gov> wrote:
>>
>> Hello,
>>
>> from the runs last night you can notice that FST
>> runs at 1.2 kHz with ~40% deadtime.
>>
>> This is currently all due to the large number of non-zero-suppressed,
>> raw, events, currently 1 in 5.
>>
>> If we plan to at least approximate the TPC (and we plan more
>> eventually) right now I propose we drop this enhanced
>> raw data percentage to 1 in 20 or even to the usual 1 in ~100.
>> I can't imagine why you would need so many of them but
>> it's not my call.
>>
>> Let me know what you think,
>>
>>       -- Tonko
>> _______________________________________________
>> Star-fst-l mailing list
>> Star-fst-l AT lists.bnl.gov
>> https://lists.bnl.gov/mailman/listinfo/star-fst-l
>>
>>
>> Note: Please do not feel obligated to respond to this message outside of your work hours.
>>
>>  ( `,_' )+=-+=-+=-+=-+=-+=-+=-+=-+=-+=-+=-+=-+=-+=-+=-+=-+=-+=-
>>   )    `\                                                      +
>>  /    '. |        Elke-Caroline Aschenauer  (she/her/hers)      =
>>  |       `,                                                      -
>>   \,_  `-/        Brookhaven National Lab                         +
>>   ,&&&&&V         Physics Dept.,            25 Corona Road         =
>>  ,&&&&&&&&:       Bldg. 510 /2-195          Rocky Point, NY,        -
>> ,&&&&&&&&&&;      20 Pennsylvania Avenue                 11778       +
>> |  |&&&&&&&;\     Upton, NY 11973                                     =
>> |  |       :_) _  Tel.:  001-631-344-4769   Tel.:   +1-631-569-4290    -
>> |  |       ;--' |                           Cell-USA:  +1-757-2565224   +
>> '--'   `-.--.   |                           Cell-Europe: +49152220025211 =
>>    \_    |  |—‘                                                           -
>>      `-._\__/     Mail: elke AT bnl.gov        elke.caroline AT me.com           +
>>             +=-+=-+=-+=-+=-+=-+=-+=-+=-+=-+=-+=-+=-+=-+=-+=-+=-+=-+=-+=-+=-+=
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Star-fst-l mailing list
>> Star-fst-l AT lists.bnl.gov
>> https://lists.bnl.gov/mailman/listinfo/star-fst-l