[Halld-pid] trigger electronics

[Alexander Ostrovidov]

Beni,

Well, the fact is that this setup does work, and it's a simple scheme. 
Let me clarify. Basically, I use TI as a latch that flips its state.
The second coincidence, together with TI, plays the role of a door
which a trigger closes behind itself  to prevent consequent triggers 
from passing through it until DAQ opens this door again for the
next trigger. This is  how it works.
 
A 50ns pulse from the main coincidence (TL*TR*BL*BR)
creates a trigger. It goes as an input to the second coincidence. 
The other input to the second coincidence is A LEVEL from TI. 
I suspect that's where all the confusion is: it's not a pulse but 
a level at the second input to the second coincidence unit.
When this level is set to "1", the trigger simply passes through this
coincidence becoming the earliest possible ADC gate and TDC trig 
as two of its outputs. The third output of this coincidence goes into 
TI as a trigger. It flips the state of TI turning  its level "1" output
into level "0".  This change of TI level goes back to the second
coincidence, reaching it about 50ns later (tuned with a delay unit 
there), i.e., at about the same time as the initial 50ns trigger pulse 
from the main coincidence ends as the other input to this unit. 
>From now on, the second coincidence blocks (due to level "0" at 
one of its inputs) any further gates/triggers from passing through it. 
The door is closed. So, I can have one and only one ADC gate/TDC 
trig and they are coming from the same source. I.e., no worries  
about ADC and TDC events going out of sync with each other 
due to multiple triggers or one of the two signals missing somehow
because they come from different electronic units.

When DAQ sees a change in TI state, it knows that an event has 
happened. It reads ADC and TDC event, clearing their output buffers.
Then it resets TI back to level "1". The door at the second coincidence
is now open again. The next  (TL*TR*BL*BR) trigger can  go through 
it now, and the cycle repeats. I think such scheme is more simple than
counting gates and throwing events.

Sasha

On Wednesday, March 30, 2011, Beni Zihlmann wrote:
> Hi Sasha,
> I see your problem. Actually I have the same issue with the cosmic test
> stand of the FDC. What I do is that my ADCs have a counter how many gate
> the ADC has seen at the time it is read out by the ROC. Whenever this
> number is more than 1 I throw the event away.
> However you should still do two things.
>   1)   you can not have this second coincidence. In particular I do not
> understand
>         the purpose of the second coincidence and the delay at all.
>         take the output of the first 4-fold coincidence (TL*TR*BL*BR) go
> directly
>         into the ADC as gate and with a second output to the TI trigger
> input.
>   2)  Then use the TI trigger accept (output) and send it to the F1TDC
> trigger input.
>         But do not make a coincidence with the original 4-fold trigger
> coincidence at
>         all. From the sketch I do not even see how this ever should have
> worked.
> 
> cheers,
> Beni
> 
> > Hi Beni,
> > 
> > Indeed, your setup looks more logical. Actually, this is a setup
> > I  was thinking of using initially. However, the reason I went
> > with my current scheme is very simple - it provides the fastest
> > ADC gate possible. Even in this case, I have to delay 6 PMT
> > signals by 130ns to be at proper time. This is about 100' of cable
> > on top of another 50' from detector to the first splitter for a total
> > of 150 feet. I guess this is already longer than we'll ever need for
> > the real detector in the hall and with flash ADC.
> > 
> > What you are suggesting will add extra delay to the ADC gate
> > due to delays in the extra path elements between the main
> > coincidence and the second one (the one you replaced with fanout):
> > 1) delay in NIM-ECL; 2) delay in TI; 3) delay in ECL-NIM; 4) all extra
> > cables in between. We are talking about something like extra 40-60ns,
> > or 30-45 feet of extra cable length. Actually, exactly 50' because
> > that the length of the cables we have, and I don't want to start
> > cutting them without good reason.
> > 
> > I have such NIM-ECL to TI to ECL-NIM path anyway. However, it is
> > not used to propagate (and delay) the front of the trigger/gate.
> > Rather, it is used to block consequent triggers after the first one
> > by flipping TI latched level until it is reset by DAQ. That's a
> > purpose of the second coincidence, and 50ns delay for this purpose is
> > even desirable.
> > 
> >   Basically, instead of routing trigger signal on a long way through
> >   TI
> > 
> > logic,  I bring TI logic right to the trigger signal at the second
> > coincidence. And save 50' of extra cable length for each channel
> > this way.
> > 
> > Sasha
> > 
> > On Monday, March 28, 2011, Beni Zihlmann wrote:
> >> Hi Sasha,
> >> I attached a pdf file with some red maker to indicate some issues I
> >> have with
> >> your trigger electronics.
> >> If I understand correctly then the red circle indicates the main
> >> trigger coincidence,
> >> namely a coincidence between top left/right and bottom left/right
> >> trigger paddles.
> >> This trigger signal should directly go to the TI input as trigger.
> >> The output of the TI
> >> is then the accepted trigger and should be used in the fanout to
> >> multiplex and
> >> be used for the ADC gate and the TDC trigger. The signal
> >> output of the trigger coincidence (red circle) should go directly
> >> into the TI and not
> >> making a coincidence between the trigger and the TI trigger accept.
> >> That does not
> >> make any sense. I indicated with red crosses (x) which lines should
> >> be removed
> >> and where the trigger (red line) should go.
> >> 
> >> I hope it is clear what I try to say.
> >> 
> >> cheers,
> >> Beni
> > 
> > _______________________________________________
> > Halld-pid mailing list
> > Halld-pid at jlab.org
> > https://mailman.jlab.org/mailman/listinfo/halld-pid
> 
> _______________________________________________
> Halld-pid mailing list
> Halld-pid at jlab.org
> https://mailman.jlab.org/mailman/listinfo/halld-pid