sPHENIX EMCal discussion

[Martin Purschke <purschke AT bnl.gov>]

John,

I take your word about the inner workings of the clockmaster module and
its ability to slip a trigger.

Let me point out that we have run dual-stream, event-synchronized DAQs
successfully in the past at the FTBF. One of those was the MPC-EX test
beam using the wirechambers, where we did get the event-sync'ed streams
quite nicely. I'd have to check back with Nikki but I recall that we got
the synchronization with >97% success rate. That was the first time that
the wire chambers were read with RCDAQ (*and* the first time they were
read, period - the controllers were just coming off the assembly line
then).

The wirechamber data are written by RCDAQ in PRDF format. Although we
were unable to read the chambers in an event-synchronized way this year,
the main DAQ did automatically start a run with the same run number for
the chamber-reading DAQ, and that worked 100%.

I would be more concerned about an accumulating loss of synchronization
were it not for the built-in heartbeat that the 60s cycle provides.
Let's say you lose synchronization in one spill at event 2000 in. True,
you might want to skip the remainder of events in that spill, but then
you see the 60s gap until the next spill starts, and you re-synchronize
the first event you see after the gap in both systems. In another setup,
Craig's GEMS were read together with the CMS silicon telescope (which
has a much more finicky readout), we applied this technique rather
successfully. The above 97% number is based on dropping the entire spill
if there was a mismatch between per-spill event counts - we didn't have
an independent means of verifying the synchronization as we would have
with the hodoscope.

I still have the MPC-EX and the GEM analysis code that maintains the
per-spill synchronization. It is no problem reading 2 streams in a
pmonitor project and combine the data.

BTW, the MWPC data from this year are in
/sphenix/data/data01/t1044-2016a/fnal/mwpc/

Best,
        Martin

On 9/6/16 23:42, John Haggerty wrote:
> 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
>>
>>
> 
> 


-- 
Martin L. Purschke, Ph.D.        ;   purschke AT bnl.gov
                                 ;   http://www.phenix.bnl.gov/~purschke
                                 ;
Brookhaven National Laboratory   ;   phone: +1-631-344-5244
Physics Department Bldg 510 C    ;   fax:   +1-631-344-3253
Upton, NY 11973-5000             ;   skype: mpurschke
-----------------------------------------------------------------------