Present: David Abbott, Fernando Barbosa, Peter Bosted, Chris Cuevas, Ed Jastrzembski, James Proffitt,  Xiaochao Zheng

Note: The meeting lasted 2 hours but the minutes below is really short, because the note keeper is really a layman of DAQ and FADC and was not able to record all discussions in details.  Here I try to cover only what matters to the users (people in the physics division):

Everyone had a printout of  DAQ Algorithm Design (dated 08/03/2005)

Comments on the design:
(FB): Fragmentation of the Shower counter should take into account that one FADC module has 16 channels. If one fragment has >16 channels, will require cross-board talk at the first processing level, which should be avoided.
(XC): Will fragment the Shower counter into 8 sections, each contains 15 channels. Smaller fragmentation means less efficiency since an overlap is require between each two fragments;

(FB): Can the S-trigger be formed using external electronics? Using FADC to do this is not very economic; A dedicated electronic unit can provide ~ a few ns of triggering speed;
(DA): Not really, it only needs 2 boards and we should not introduce extra deadtime;
(CC): One board (10bit, 16 channels) costs about $3.5K.

(JP): About the gain correction, can do so using realtime data. However that will require feeding the data backwards and is time-consuming. Should only do it from time to time;

(FB, JP etc.): Looks like data from each FADC board will be processed on-board first (FPGA), and then fed to a "collector" unit for global processing. Not sure how to design this "collector" yet, may use VME back-plane switch boards (VXS?);
(JP): For the first prototype, can design a board first, and see how it performs;
(XC): We would also like to see the design of the "collector" for the first prototype . If the prototype means only a board with some FPGA unit, then it will be similar to what we have done already using the 100MHz Struck FADC (except the FPGA part). From the Struck we already learned how to collect data, how the pulse shape looks like, and how to analyze it.
(FB): That's true;
(JP, CC): We need to sit down and study what the "collector" needs to do, not sure whether it will be ready for the 1st prototype;

(DA): Timing alignment between blocks should be considered in the design (part of the calibration);
(DA): Pulse pileup will be a problem. Even if we use the algorithm described in the writeup, it is not clear what to do if one channel has pileup, and others do not. In this case we don't know which pulse to keep and which to throw away;
(XC): Will think more on this. (My  thoughts:) E-e pileups can be corrected using high-threshold analysis; pi-pi pileups will not trigger cherenkov and should not cause a big problem. What needs to be improved are separation of Pi-e or e-pi pileups, how to keep the e and throw away the pion;  Maybe we can add all channels of one fragment together first and then try to separate the pileup;

(CC?): Should keep the FADC DAQ system for one HRS below one crate (<=16 boards), should not be a problem as seen from the writeup;

Readouts:
(All): Not likely to readout all samples, but should readout as much as possible.
(CC): Currently the limit on readout speed is 40-50MBytes/sec. Each ADC sample is 10 bit;
(XC): Will work on the document to give several different options to choose from.

Plan:
(All DAQ people): The design here is very similar to Hall-D. However we probablly don't need to wait for Hall D's requirement, though it means we may do one design that covers everything.  The Hall-D final requirement may come out when the accelerator is being upgraded, 7 years from now?
(XC): And we would like to see the first prototype in one year, and the experiment to run in 2007.

XC will work on the "DAQ algorithm" and give an updated version in a week; (Note: an updated version 8/25/2005 can be found here)
CC will give a document on the FADC design (not sure final, but at least we will have something) in one month.