[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Flash ADC Timing
On Fri, 16 Nov 2007, Matthew Shepherd wrote:
Fernando and Matt,
i think we all agree test are needed we can do what was suggested in the
report. Currently we have 5 250MHz FADCs. I suggest that on Wednesday in
the weekly Hall D meeting we find out how many FADCs pleople might need
for test stands and than see we have to produce more.
bye elke
> Date: Fri, 16 Nov 2007 16:46:11 -0500
> From: Matthew Shepherd <mashephe@indiana.edu>
> To: Fernando J. Barbosa <barbosa@jlab.org>
> Cc: halld-cal@jlab.org
> Subject: Re: Flash ADC Timing
>
>
> Hi Fernando,
>
> I understand the claims in the document are rather optimistic;
> however, the fact of the matter is that we probably just need timing
> resolution roughly on the scale of sampling rate to suppress beam-
> related out of time noise.
>
> If you have a real fADC that is ready for use we're happy to take it
> and get it setup and running here. This would serve many purposes --
> probably most important at this point is that we could use the real
> PMT, light guide, base, and fADC that we plan for the actual
> experiment to readout just one bar and probe the low energy threshold
> of the calorimeter using cosmic rays (and guidance from simulation).
>
> -Matt
>
>
> On Nov 16, 2007, at 3:01 PM, Fernando J. Barbosa wrote:
>
> > Hi Matt,
> >
> > I am familiar with those documents and I recall that at the time
> > we started developing the fADC (~2 years?), I suggested that
> > someone needed to take some real data with Paul's single-channel
> > prototype and try doing the prescribed fittings, etc. To the best
> > of my knowledge, no one in the collaboration has done that.
> >
> > Referring to the document, the algorithm relies on finding the
> > exact pulse peak and getting the two preceding samples to determine
> > the 50% time, for instance. The exact peak was determined from
> > sampling at 2.5 GHz (400 ps intervals) and fitting the data with a
> > 9th degree polynomial. The data was then "degraded" to provide the
> > equivalent of 8 or 10-bit, 250 MHz (4 ns intervals) sampling. Note
> > that the exact peak is critical for the algorithm to provide the
> > quoted resolution, although these details are missing from the
> > document.
> >
> > The real fADC, and sampling at 250 MHz, will not provide a
> > sample of the true pulse peak. I believe that such "fluctuation"
> > will degrade the effective resolution considerably. So, I suggest
> > that this needs to be checked with a real fADC, perform the
> > algorithm on real raw fADC data (offline) and determined the
> > effective resolution that can be achieved by this method. Obtaining
> > 400 ps resolution from 4 ns data points and from 10 ns pulse rise
> > times seems difficult to me. We actually may have to shape (i.e.
> > slow) the pulse to get more samples on the leading edge of the
> > pulse. Once the algorithm is well understood, it will need to be
> > implemented in a relatively simple/compact manner to fit within the
> > resources of the FPGAs or board memory. Eventually, any data that
> > is passed up the chain must be balanced with the backplane bandwidth.
> >
> > Let me suggest you set up a test with the real PMTs/bases/
> > scintillator/fiber/laser and get data with a real fADC, a TDC and
> > CFD. We could lend you one fADC-250 to get the raw data. Let me
> > know what you decide and how I can help.
> >
> > Best regards,
> > Fernando
> >
> >
> >
> >
> > Matthew Shepherd wrote:
> >>
> >> Hi all,
> >>
> >> The study I was referring to has been linked to the FCAL page here:
> >>
> >> http://www.jlab.org/Hall-D/software/wiki/index.php/FCAL
> >>
> >> This work was done about 3 years ago and claims a resolution of
> >> about ~160 ps can be achieved. This is far better than is
> >> actually needed to push down backgrounds. I think Scott had in
> >> mind another application: using the FCAL to determine the event
> >> start time. The algorithm does a transformation of the leading
> >> edge of the pulse to determine the start time and depends on
> >> having the two samples before the peak on the leading edge.
> >>
> >> I believe Paul had planned to implement this in a simple lookup
> >> table which would require about 65K of memory on the chip.
> >> Perhaps that could be optimized even more. It was never
> >> investigated in detail mainly because it seemed like something
> >> relatively easy to implement. All of these buffers will need some
> >> processing -- the drift chambers will also depend on the timing
> >> algorithms that are built into the flash ADCs.
> >>
> >> -Matt
> >>
> >>
> >> <barbosa.vcf>
>
>
( `,_' )+=-+=-+=-+=-+=-+=-+=-+=-+=-+=-+=-+=-+=-+=-+=-+=-+=
) `\ -
/ '. | +
| `, Elke-Caroline Aschenauer =
\,_ `-/ -
,&&&&&V Jefferson Lab +
,&&&&&&&&: HALL-D 12C / F381 121-A Atlantic Avenue =
,&&&&&&&&&&; Mailstop: 12H5 Hampton, VA 23664 -
| |&&&&&&&;\ 12000 Jefferson Ave +
| | :_) _ Newport News, VA 23606 Tel.: 001-757-224-1216 =
| | ;--' | Mail: elke@jlab.org Mobil: 001-757-256-5224 -
'--' `-.--. | +
\_ | |---' Tel.: 001-757-269-5352 =
`-._\__/ Fax.: 001-757-269-6248 -
+=-+=-+=-+=-+=-+=-+=-+=-+=-+=-+=-+=-+=-+=-+=-+=-+=-+=-+=-+=-+