sPHENIX EMCal discussion

[John Haggerty <haggerty AT bnl.gov>]

Martin,

That sounds good, and perhaps it is time to tackle this, since there's 
some time before the next run and I think there may be more use for this 
in the future when we will need to test tracking detectors as well.

Short summary: I think we should look into borrowing one of the 
controllers and do development at BNL so we are not in the position of 
trying to get the readout working on the first day of the run.  Read on 
for more discussion.

In more detail, the issues that I see as needing to be tested in a 
controlled way have to do with the late trigger sent to the HBD (which 
is set so that the trigger at the clockmaster comes 1 microsec after the 
analog signal rises at the front panel, the trigger is formed with 
significant cable delays and transmitted back to the digitizer with yet 
more cable delay.  Also, I suspect, but have never verified, that the 
clockmaster may ignore some triggers--that doesn't matter in the case of 
the HBD electronics, because there is only one "accept" resulting from 
any trigger, so no event can be skipped that gets promoted to "accept." 
(This doesn't happen in PHENIX, because the GTM prevents it, but we 
don't have exactly the same logic without the GTM, although it could be 
emulated with enough care.)

We depend on all FEM's getting the same trigger and reporting data for 
every accept, and we just match event numbers, as you know, but without 
testing that under all trigger conditions that we read the same number 
of events, we have no way to guard against event misalignment which can 
accumulate during the course of a run.  I think that's what we need to 
test and debug on the bench with pulser triggers before we use it in 
anger, and we need to test it with various kinds of bursty triggers.

Also, buffers of data from the HBD and buffers from the wirechambers 
need to be split up into events and packed into events, although we 
could just write multiple streams (files) and either build prdf events 
later or even go crazy and just write multiple prdf's which 
reconstruction takes care of sundering (I guess that must be the 
opposite of asunder, right?).  I suppose Fun4All can synchronize 
multiple input prdf's (although I'm not aware anyone has done that) if 
we are sure we have event numbers that match. *But we have to build in 
online checks that assure us that the same number of triggers is seen by 
the FADC's as the wirechambers.*  And this check is complicated by 
events which may be left in the jseb or jseb ii memory at the end of a run.

Last, I think you would want to package up the events in a prdf format 
so these data are available into the future.

By the way, I'm not sure anyone saw how I had the detector timed in to 
the trigger (S1*S2*S3) before we turned on the beam--the way I did it 
was to replace S1 with a pulser, reduce the coincidence to 1, and use 
the same pulser and about the same delay to pulse the LED's in the 
EMCAL.  That way, I could see the trigger and the analog signal on a 
scope while I was in the enclosure.  The reason I mention this is that 
one may be able to get the wirechamber readout timed in with a similar 
procedure.

Getting that all straight does not sound like something we want to be 
doing as we start the run, but when we do have beam, I think we would 
then need to beat the wirechamber readout against the hodoscope and 
verify our extrapolation of the hits into the hodoscope.  I think these 
wirechambers have 1 mm wire spacing, so we could do a pretty good test 
if we put the (5 mm finger) hodoscope up against the last wirechamber, 
and that would also confirm that there is no funny business in the 
readout order of the wires.

When we get there, we'll want to have a tracking program that can find 
multiple tracks in some set of chambers that we read and survey.  One of 
my consultants recommended that we could do better than the droopy tape 
measure with one of these:

> http://www.fluke.com/fluke/m3en/products/Laser-Distance-Meters.htm

which might save us from a full survey, since I think we mainly need the 
z (along the beamline) positions since we can dead reckon the data in x 
and y.

I'm still not entirely convinced it's worth it for the calorimeter test 
(i.e., we don't want to map the non-uniformity that wrecks the 
resolution, we want to fix it), but it would certainly give us another 
tool to study the calorimeters with, and I think the real use of this is 
in the beam tests of the tracking detectors that I'll discuss on another 
list one of these days.

But again, bottom line, I think we need to test this at BNL where we can 
do so with our own electronics and digitizer and have some breathing 
space for code development.

On 9/1/16 8:54 AM, Martin Purschke wrote:
> Dear Emcal (and HCal) aficionados,
>
> a while ago we had a discussion how to go about getting better pointing
> power for the beam position on the detectors. This spring we had been
> reading the wire chambers for a general beam spot position, but had been
> unable to read them event by event together with our DAQ because our
> busy-vetoed trigger was way too late.
>
> I have been back and forth with Sten, the engineer who makes the
> firmware for the wirechamber controllers. He will make changes to the
> controller firmware to be able to stack more events and accommodate
> twice the current maximum delay. I had measured a delay of about 1.2
> microseconds between the trigger that Ewa sends to the chambers, and our
> trigger signal. We looked at the current setup parameters, and found
> that we'd be ok with about 980 ns but not 1200.
>
> The change that Sten will implement for us will get us well into the
> range we need. That does not pre-empt other choices we had been kicking
> around, but at least it is a viable option to get a 4-point beam vector
> event by event.
>
> Best,
>         Martin


--
John Haggerty
email: haggerty AT bnl.gov
cell: 631 741 3358