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

Naomi Jarvis nsj at cmu.edu
Wed Jul 17 19:54:43 EDT 2013 

Hi Gerard,

Thankyou, that was very helpful for our discussion this morning https://halldweb1.jlab.org/wiki/index.php/July_17,_2013_Tracking_CDC/FDC

For the CDC, if the leading edge algorithm fails then I was planning to make it return the initial threshold crossing time minus a constant (TBD, something like 40ns), and flag this in the quality factor, so that the error on the hit time can be increased in the tracking.   

Including the firmware version is a great idea, David thought the best place for it would be the block header.

Best regards,

Naomi.



On Jul 17, 2013, at 9:29 AM, Gerard Visser wrote:

> hi Naomi & all,
> 	Won't some percentage of raw sample data also be stored? If so, that can be 
> used to monitor the pedestals, as well as monitor the algorithm performance for 
> instance comparing to more sophisticated offline algorithms.
> 	I think the proposed 14 bits for time and 17 for amplitude is good. I don't 
> think you'll ever get 17 significant bits of amplitude measurement, but its 
> closer to reality than 19 bits, and 14 bits for time seems fine, 1.24us/2^14 = 
> 75 ps and that is probably approaching the real timing capability of the board 
> (depending on pulse shape variability).
> 	For the amplitude if computed simply as an integral, yes just scaling down 
> (need not be by a power of 2 but could be) and keeping integer part of the 
> result should be fine. Both the amplitude and time output can be scaled by 
> arbitrary fixed-point multiplication (that will be trivial compared to the rest 
> of the endeavor :) ).
> 	I think more "quality" bits is a good idea, suspect you will run into 
> limitations of whatever the format defines and wish for more. However, 
> "pedestal" bits can also be taken over to indicate "quality", especially if the 
> basic pedestal monitoring is provided by another mechanism.
> 	By the way, I think pedestal monitoring _needs_ to use full resolution of the 
> ADC, not dropping LSB's. But it probably does not need to cover the full range, 
> e.g., map 12 bits to 9 bits by (x>511?511:x) or something like that.
> 	Question: Will the algorithm decide on the fly to output a particular pulse raw 
> if it is not able to digest it properly? Or does it just output a "junk flag" 
> and that pulse is lost? There may be some proportion of pulses that could be 
> recovered offline but that the online algorithm can't handle, for instance due 
> to too close pileup.
> 	Another question: Will the board data header have some kind of format version 
> tag in it, so that you can change this data format later and maintain software 
> compatibility with old and new data? If there is room for this, I think it would 
> be a good idea. 4-5 bits should suffice. Obviously not part of the hit record, 
> it would only be sent once per board.
> 	Sincerely,
> 
> 		Gerard
> 
> 
> On 7/16/2013 11:07 PM, Naomi Jarvis wrote:
>> Hello,
>> 
>> For the CDC:
>> 
>> With B field and some deformation in some of the straws we need to allow for max
>> drift time of 1240ns.
>> 
>> Pulse is not needed.  Understood that the FDC does need it though.
>> 
>> Time.
>> If we output time as integer number of 0.1ns this will fit into 13 bits.
>>  Clearly we need to have the time measurement from the flash better than the
>> drift chamber's time resolution; I think we already have this with 1ns (12
>> bits), but if there is room for 13 bits, great.
>> 
>> Integral.
>> Ok with 17 bits.  Also ok with 16.
>> Integer resolution for the integral is OTT but we do need the range.  I would
>> prefer to trade in some precision and divide the integral by 4 (or more) before
>> storing, that would be 17 bits (or less).   For saturated events see the 3rd row
>> of https://halldweb1.jlab.org/wiki/index.php/CDC_odd_events Most of the channels
>> are saturated but there are a few which look ok. From looking at this I would
>> put 3500 as the limit for a reasonable sustained maximum.  With max drift
>> 1.24ns, 155 samples x (3500-pedestalof50)=534750 which needs 19 bits at integer
>> precision, or 17 if divided by 4.  Minimum integral would be a peak only just
>> over threshold ~80 high, ~6 samples wide =  240 ish.
>> 
>> Pedestal
>> I did not explain this well.   My reasons for recording pedestal are to keep an
>> eye on pedestal drifts (alarm points) and indicate if the present hit is sitting
>> on the tail of another.  We do not need full precision for this and I think it
>> will be ok to monitor pedestal divided by 4.  If we also set an upper recording
>> limit eg 500 (range 0-4095) then when divided/4 this will fit into 7 bits.  I
>> would use the upper limit because if a pedestal that high would probably be the
>> tail of an earlier hit.
>> 
>> QF - time
>> 1 bit to indicate when my algorithm has run on past the original threshold time
>> and a less accurate time is being returned
>> 1 extra bit to flag when the leading edge gradient is low (indicates noise,
>> useful for small amplitude signals).
>> 
>> QF - integral
>> The preamp saturates at ~0.5V but the behaviour of the flash is more
>> complicated because it is also a shaper.
>> Anyway, OK with counting up to 15 samples.
>> 
>> QF - extra?
>> It might be a good idea to keep some spare room in the QFs in case we find that
>> we need something extra when the algorithms have been coded onto the flash.
>> 
>> 
>> Best,
>> 
>> Naomi.
>> 
>> 
>> 
>> On Jul 16, 2013, at 9:42 PM, David Lawrence wrote:
>> 
>>> 
>>> 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
>>> <gfhaahhe.jpg>
>>> 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
>>> 
>>> _______________________________________________
>>> 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
>> 
> _______________________________________________
> 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/20130717/5ce266e4/attachment-0001.html

More information about the Halld-tracking-hw mailing list