[Halld-tracking-hw] F125ADC what do we want / need

Tue Jul 16 21:42:54 EDT 2013

Hi All,

   Based on Gerard's comments and a discussion with Elton, I have 
updated the bit assignments.
Given the larger number of bits in the time field, it made sense to move 
it to the second word
so that it is not split between the first and second words. Other 
significant changes from the
previous iteration:

1.) pulse time increased to 14 bits

2.) pulse integral reduced from 19 to 17 bits. Since it is a 12bit ADC, 
this still gives enough
range to record a pulse with (17-12 = 5bits =) 32 samples in saturation. 
This should more
than exceed any reasonable sized signal.

3.) pedestal increased from 8 bits to 9 bits

4.) Q.F. reduced from 6 bits to 4 bits. This will still allow up to 15 
samples to be in saturation
corresponding to the signal being over 1V for more than 120 ns. Again, a 
signal this large
probably has something wrong with it and should be discarded anyway.

We can discuss this at the Wed. tracking meeting if there is time.

Regards,
-David

On 7/16/13 1:42 PM, Curtis A. Meyer wrote:
> At least for the CDC, the most important measurement is the time, so I 
> do not want to
> compromise there. As for the pulse integral, the real issue is dynamic 
> range. What is the
> smallest meaningful amplitude that we want to measure, and what is the 
> largest sensible
> amplitude that we could measure.
>
> curtis
> -------
> Prof. Curtis A. MeyerDepartment of Physics
> Phone: (412) 268-2745Carnegie Mellon University
> Fax:      (412) 681-0648Pittsburgh, PA 15213
> curtis.meyer at cmu.edu <mailto:curtis.meyer at cmu.edu> 
> http://www.curtismeyer.com/
>
>
>
>
>
> On Jul 16, 2013, at 12:22 PM, Gerard Visser <gvisser at indiana.edu 
> <mailto:gvisser at indiana.edu>> wrote:
>
>> hi all,
>> Although I'm now not directly involved in the effort to define & 
>> design the
>> ADC125 algorithms and data format, I would like to comment here that 
>> in my
>> opinion there are too many bits devoted to pulse amplitude (19) and 
>> too few
>> devoted to time (11). You will never get an amplitude measurement 
>> with 19
>> significant bits, I think. I would suggest flip a few more bits over 
>> to time,
>> for instance make it 16 bits amplitude and 14 bits time. In 
>> particular, it
>> should be possible to have time resolution down to 1/2 ns or 1/4ns, 
>> at least it
>> is less of a stretch to believe in the significance of those digits 
>> than in the
>> significance of an amplitude measurement to 2 ppm (19 bits).
>> Sincerely,
>>
>> Gerard
>>
>> On 7/16/2013 12:05 PM, David Lawrence wrote:
>>>
>>> Hi Naomi,
>>>
>>>   Thanks for the feedback. I have some comments on your suggestions 
>>> below:
>>>
>>> On 7/15/13 4:27 PM, Naomi Jarvis wrote:
>>>> Hello,
>>>>
>>>> I prefer option 1, the coupled words with pedestal, as it packs 
>>>> more info into
>>>> the same space.
>>>>
>>>> First word
>>>>
>>>> Do we need the 2bits for 'pulse'?  From looking through the spec it 
>>>> seems that
>>>> this is to label up to 4 pulses for which time data is to be sent. 
>>>>  For the
>>>> CDC this would always be 1, just 1 pulse, so could we dispense with it?
>>>>
>>> I think there should be enough room in the 64 bits to keep the 2 
>>> bits for this.
>>> I would hate to give this up unless we really have to. Since we'll 
>>> be using
>>> these for the FDC cathodes which will have a much higher rate, it 
>>> could be very
>>> useful.
>>>
>>>> We would like to increase the bits available for time data from 10 
>>>> to 11 bits,
>>>> as an integer # of ns, that gives us 0-2047 ns.  This allows some 
>>>> headroom for
>>>> slower drift times.
>>>>
>>> This seems reasonable to me. If we move the 3 bits for the Q.F. down 
>>> to the
>>> second word as you suggested, we can use one of those.
>>>
>>>>
>>>> Second word
>>>>
>>>> Pedestal.  I would indeed like to include this but it is not 
>>>> necessary to have
>>>> full range 0-4095 available in integer steps.  We will set the 
>>>> pedestals to
>>>> something low, ~55-60.   How about outputting pedestal/8 to cover 
>>>> the subrange
>>>> pedestal=0-504 as pedestal/8=0-63 in 6 bits.  ?
>>>>
>>> I'm not sure if I fully understand your notation of pedestal/8, but 
>>> I think your
>>> main point is that we can just limit the range of the pedestals to 
>>> be within
>>> that defined by 6 bits. Either by adjusting voltage offsets or 
>>> applying an
>>> offset parameter to the FPGA. Just to be clear though, the 6bits of 
>>> pedestal
>>> would have the same resolution as the integral right? (i.e. changing the
>>> pedestal by 1 is equivalent to changing the pulse integral by 1)
>>>
>>>> Integral.  OK.
>>>
>>> Actually, I'm thinking we could reduce this by a couple of bits. 
>>> With a 12bit
>>> ADC, storing 19 bits for the integral means we could have up to 
>>> 7bits=128
>>> samples in saturation without overflowing. This would correspond to 
>>> a pulse that
>>> is over 1V high for more than 1 microsecond. That seems unlikely to 
>>> provide
>>> anything useful (correct me if I'm wrong here.) We could move 2 bits 
>>> from this
>>> to the Q.F. allowing use to keep 8 bits for the pedestal.
>>>>
>>>> Integral quality factor.
>>>> I would like to include a count of the number of overflowed samples
>>>> contributing to the integral, this could count up to 63 samples 
>>>> (504ns) in the
>>>> 6 bits freed up from the pedestal.
>>>
>>> OK
>>>
>>>
>>> Here is a revised diagram which incorporates your suggestions and 
>>> then my
>>> modifications to those. Let me know what you think.
>>>
>>>
>>> Regards,
>>> -Dave
>>>
>>>
>>>
>>> _______________________________________________
>>> Halld-tracking-hw mailing list
>>> Halld-tracking-hw at jlab.org <mailto:Halld-tracking-hw at jlab.org>
>>> https://mailman.jlab.org/mailman/listinfo/halld-tracking-hw
>>>
>> _______________________________________________
>> Halld-tracking-hw mailing list
>> Halld-tracking-hw at jlab.org <mailto:Halld-tracking-hw at jlab.org>
>> https://mailman.jlab.org/mailman/listinfo/halld-tracking-hw
>
>
>
> _______________________________________________
> Halld-tracking-hw mailing list
> Halld-tracking-hw at jlab.org
> https://mailman.jlab.org/mailman/listinfo/halld-tracking-hw

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mailman.jlab.org/pipermail/halld-tracking-hw/attachments/20130716/e506077e/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gfhaahhe.jpg
Type: image/jpeg
Size: 54915 bytes
Desc: not available
Url : https://mailman.jlab.org/pipermail/halld-tracking-hw/attachments/20130716/e506077e/attachment-0001.jpg 