[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Flash ADC Timing
Hello everyone,
As you may be aware from Elke's email and the phone conference last
week, our resources are very limited at Jlab. As a result, Jlab will not
be able to provide (cannot afford) DAQ systems. There are two options
for those people at collaborating institutions: schedule tests at Jlab
or purchase their own systems. Jlab can provide the required specifications.
Regards,
Fernando
Fernando J. Barbosa wrote:
> Hi Beni and Paul,
>
> I am CCing Elliott just in case he is not receiving these emails
> but I will talk to him regarding the issue of ordering and setting up
> small systems for R&D. He also has information on current and future
> plans from the DAQ group at Jlab with regards to CODA and software
> drivers for the various modules.
>
> The F1TDC is VME64x compliant and can be installed on VXS crates. I
> agree it is a good idea to order VXS crates in view of future tests of
> the energy sum trigger.
>
> Is one system sufficient for tests at IU? If multiples, how many?
> Most likely Gerard will also need one or access to one.
>
> Best regards,
> Fernando
>
>
>
>
>
>
> We would also need a VME64X crate, and a single board computer with
> CODA software installed on it. An F1 TDC would also be useful, along
> with any necessary back mounted interface cards, and a trigger
> supervisor. We would want to test the energy sum trigger as soon as
> it is available; this needs a VXS crate. Will the F1 operate in a VXS
> crate?
>
> Elliott was looking into getting together a test setup for IU maybe
> two years ago, but nothing ever came of it.
>
> Paul
>
>
> On Nov 19, 2007, at 9:22 AM, Fernando J. Barbosa wrote:
>
>> We currently have 4 10-bit fADC-250 under tests/debugging and I don't
>> expect these will be released until early 2008. We have been
>> discussing the possibility of an engineering run, 5-10 boards, in the
>> fADC group for use by users and for testing the trigger system.
>> Please be aware that it make take up to 8 weeks before we get any new
>> boards (ordering components, PCB fabrication, assembly, test).
>
>
> beni zihlmann wrote:
>> Hi All,
>> some time ago Elliot sent around a mail asking what is needed in
>> terms of electronics on DAQ
>> at the Universities. I answered to that question that here at IU we
>> have no VME based equipment
>> at all. In particular this means NO crate, NO front end cpu (ROC), NO
>> other VME based modules.
>> This means we need a Crate, a ROC and maybe another module I do not
>> know we need to get
>> CODA running in addition to the fADC. We have computers that can be
>> used as back ends
>> to install CODA on and if the communication is done via ethernet then
>> all we need on top of that is
>> a hub and some cables that we have here at IU.
>>
>> cheers,
>> Beni
>>
>> Fernando J. Barbosa wrote:
>>> Hi Elke,
>>>
>>> That's a good idea to start thinking about requests for any sort
>>> of electronics people will need over the next few months, especially
>>> in light of CD-3.
>>>
>>> We currently have 4 10-bit fADC-250 under tests/debugging and I
>>> don't expect these will be released until early 2008. We have been
>>> discussing the possibility of an engineering run, 5-10 boards, in
>>> the fADC group for use by users and for testing the trigger system.
>>> Please be aware that it make take up to 8 weeks before we get any
>>> new boards (ordering components, PCB fabrication, assembly, test).
>>>
>>> I will be away on Wednesday, 11/21/07 for the Thanksgiving holiday.
>>>
>>> Best regards,
>>> Fernando
>>>
>>>
>>>
>>> Elke-Caroline Aschenauer wrote:
>>>> 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 -
>>>>
>>>> +=-+=-+=-+=-+=-+=-+=-+=-+=-+=-+=-+=-+=-+=-+=-+=-+=-+=-+=-+=-+
>>>>
>>>>
>>
begin:vcard
fn:Fernando J. Barbosa
n:Barbosa;Fernando J.
org:Jefferson Lab
adr:Suite #10, 12B3;;12000 Jefferson Ave.;Newport News;VA;23606;USA
tel;work:757-269-7433
version:2.1
end:vcard