Today (RUN13791), we went ahead and increased the WFD byte limit to 60K.
This change increased the effective memory depth of the WFDs to ~150usec
(until now we're reading 40K, i.e., ~100usec).
Over the last couple of days we've tested this camac list change with
real and LED data; it doesn't seem to be giving us any problem. Standard
WFD software we've used to look at data handled the data increase with
no problem.
IF YOU HAVE ANY WFD BUFFER MATCHING ALGORITHM/WFD ANALYSIS GOING, THIS IS
THE MOMENT TO TEST HOW IT HANDLES THIS WFD READOUT CHANGE.
It is conceivable that more ID=2 will now be created and a slight overall
increase in the amount of data written on disk might be noticed.
As you may recall a similar change took place also last summer (17JUL96,
RUN12514) when we doubled the WFD readout byte limit from 20K to 40K in
an effort to recover some of the WFD data lost on high charge events.
After this byte limit increase no significant effect was observed in the
data volume at that time.
The fix to the present WFD problem (overshoot/undershoot) is yet to come;
in the tests we've performed we found out that the 60K give us more freedom
in choosing "safer" capacitor values for the fanouts/WFDs and moving the
"fast" WFD stop to higher charge values. So, we anticipate that the final
fix will most likely have the 60K byte limit as part of it, unless something
fundamentally wrong is observed in the present data with the 60K readout.
Until the final fix, the 60K will buy us quite a lot of total charge
(due to the non linearity of the PMTs at big charges) in our sensitivity plot.
--Erik