<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Hello,</div><div><br></div><div>For the CDC:</div><div><br></div><div>With B field and some deformation in some of the straws we need to allow for max drift time of 1240ns.</div><div><br></div><div>Pulse is not needed. Understood that the FDC does need it though.</div><div><br></div><div>Time. </div><div>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.</div><div><br></div><div>Integral.</div><div>Ok with 17 bits. Also ok with 16.</div><div>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 <a href="https://halldweb1.jlab.org/wiki/index.php/CDC_odd_events">https://halldweb1.jlab.org/wiki/index.php/CDC_odd_events</a> 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. </div><div><br></div><div>Pedestal</div><div>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. </div><div><br></div><div>QF - time</div><div><div>1 bit to indicate when my algorithm has run on past the original threshold time and a less accurate time is being returned</div><div>1 extra bit to flag when the leading edge gradient is low (indicates noise, useful for small amplitude signals).</div></div><div><br></div><div>QF - integral</div><div>The preamp saturates at ~0.5V but the behaviour of the flash is more complicated because it is also a shaper. </div><div>Anyway, OK with counting up to 15 samples. </div><div><br></div><div>QF - extra?</div><div>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.</div><div><br></div><div><br></div><div>Best,</div><div><br></div><div>Naomi.
</div>
<div><br></div><div><br></div><br><div><div>On Jul 16, 2013, at 9:42 PM, David Lawrence wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000">
<br>
Hi All,<br>
<br>
Based on Gerard's comments and a discussion with Elton, I have
updated the bit assignments.<br>
Given the larger number of bits in the time field, it made sense to
move it to the second word<br>
so that it is not split between the first and second words. Other
significant changes from the<br>
previous iteration:<br>
<br>
1.) pulse time increased to 14 bits<br>
<br>
2.) pulse integral reduced from 19 to 17 bits. Since it is a 12bit
ADC, this still gives enough<br>
range to record a pulse with (17-12 = 5bits =) 32 samples in
saturation. This should more<br>
than exceed any reasonable sized signal.<br>
<br>
3.) pedestal increased from 8 bits to 9 bits<br>
<br>
4.) Q.F. reduced from 6 bits to 4 bits. This will still allow up to
15 samples to be in saturation<br>
corresponding to the signal being over 1V for more than 120 ns.
Again, a signal this large<br>
probably has something wrong with it and should be discarded anyway.<br>
<br>
We can discuss this at the Wed. tracking meeting if there is time.<br>
<br>
Regards,<br>
-David<br>
<span><gfhaahhe.jpg></span><br>
<div class="moz-cite-prefix">On 7/16/13 1:42 PM, Curtis A. Meyer
wrote:<br>
</div>
<blockquote cite="mid:AB556DF9-8DEE-4A87-B887-7A5BB8C342B2@cmu.edu" type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
At least for the CDC, the most important measurement is the time,
so I do not want to
<div>compromise there. As for the pulse integral, the real issue
is dynamic range. What is the</div>
<div>smallest meaningful amplitude that we want to measure, and
what is the largest sensible</div>
<div>amplitude that we could measure.</div>
<div><br>
</div>
<div>curtis<br>
<div apple-content-edited="true">
<span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; ">
<div style="word-wrap: break-word; -webkit-nbsp-mode:
space; -webkit-line-break: after-white-space; ">
<div>-------</div>
<div>Prof. Curtis A. Meyer<span class="Apple-tab-span" style="white-space: pre; "> </span> <span class="Apple-converted-space"> </span>Department of
Physics</div>
<div>Phone: (412) 268-2745<span class="Apple-tab-span" style="white-space: pre; "> </span> <span class="Apple-converted-space"> </span>Carnegie
Mellon University</div>
<div>Fax: (412) 681-0648<span class="Apple-tab-span" style="white-space: pre; "> </span>
Pittsburgh, PA 15213</div>
<div><a moz-do-not-send="true" href="mailto:curtis.meyer@cmu.edu">curtis.meyer@cmu.edu</a>
<a moz-do-not-send="true" href="http://www.curtismeyer.com/">http://www.curtismeyer.com/</a></div>
<div><br>
</div>
<div><br>
</div>
</div>
</span><br class="Apple-interchange-newline">
</span><br class="Apple-interchange-newline">
</div>
<br>
<div>
<div>On Jul 16, 2013, at 12:22 PM, Gerard Visser <<a moz-do-not-send="true" href="mailto:gvisser@indiana.edu">gvisser@indiana.edu</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">hi all,<br>
<span class="Apple-tab-span" style="white-space:pre"> </span>Although
I'm now not directly involved in the effort to define &
design the <br>
ADC125 algorithms and data format, I would like to comment
here that in my <br>
opinion there are too many bits devoted to pulse amplitude
(19) and too few <br>
devoted to time (11). You will never get an amplitude
measurement with 19 <br>
significant bits, I think. I would suggest flip a few more
bits over to time, <br>
for instance make it 16 bits amplitude and 14 bits time. In
particular, it <br>
should be possible to have time resolution down to 1/2 ns or
1/4ns, at least it <br>
is less of a stretch to believe in the significance of those
digits than in the <br>
significance of an amplitude measurement to 2 ppm (19 bits).<br>
<span class="Apple-tab-span" style="white-space:pre"> </span>Sincerely,<br>
<br>
<span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>Gerard<br>
<br>
On 7/16/2013 12:05 PM, David Lawrence wrote:<br>
<blockquote type="cite"><br>
Hi Naomi,<br>
<br>
Thanks for the feedback. I have some comments on your
suggestions below:<br>
<br>
On 7/15/13 4:27 PM, Naomi Jarvis wrote:<br>
<blockquote type="cite">Hello,<br>
<br>
I prefer option 1, the coupled words with pedestal, as
it packs more info into<br>
the same space.<br>
<br>
First word<br>
<br>
Do we need the 2bits for 'pulse'? From looking through
the spec it seems that<br>
this is to label up to 4 pulses for which time data is
to be sent. For the<br>
CDC this would always be 1, just 1 pulse, so could we
dispense with it?<br>
<br>
</blockquote>
I think there should be enough room in the 64 bits to keep
the 2 bits for this.<br>
I would hate to give this up unless we really have to.
Since we'll be using<br>
these for the FDC cathodes which will have a much higher
rate, it could be very<br>
useful.<br>
<br>
<blockquote type="cite">We would like to increase the bits
available for time data from 10 to 11 bits,<br>
as an integer # of ns, that gives us 0-2047 ns. This
allows some headroom for<br>
slower drift times.<br>
<br>
</blockquote>
This seems reasonable to me. If we move the 3 bits for the
Q.F. down to the<br>
second word as you suggested, we can use one of those.<br>
<br>
<blockquote type="cite"><br>
Second word<br>
<br>
Pedestal. I would indeed like to include this but it is
not necessary to have<br>
full range 0-4095 available in integer steps. We will
set the pedestals to<br>
something low, ~55-60. How about outputting pedestal/8
to cover the subrange<br>
pedestal=0-504 as pedestal/8=0-63 in 6 bits. ?<br>
<br>
</blockquote>
I'm not sure if I fully understand your notation of
pedestal/8, but I think your<br>
main point is that we can just limit the range of the
pedestals to be within<br>
that defined by 6 bits. Either by adjusting voltage
offsets or applying an<br>
offset parameter to the FPGA. Just to be clear though, the
6bits of pedestal<br>
would have the same resolution as the integral right?
(i.e. changing the<br>
pedestal by 1 is equivalent to changing the pulse integral
by 1)<br>
<br>
<blockquote type="cite">Integral. OK.<br>
</blockquote>
<br>
Actually, I'm thinking we could reduce this by a couple of
bits. With a 12bit<br>
ADC, storing 19 bits for the integral means we could have
up to 7bits=128<br>
samples in saturation without overflowing. This would
correspond to a pulse that<br>
is over 1V high for more than 1 microsecond. That seems
unlikely to provide<br>
anything useful (correct me if I'm wrong here.) We could
move 2 bits from this<br>
to the Q.F. allowing use to keep 8 bits for the pedestal.<br>
<blockquote type="cite"><br>
Integral quality factor.<br>
I would like to include a count of the number of
overflowed samples<br>
contributing to the integral, this could count up to 63
samples (504ns) in the<br>
6 bits freed up from the pedestal.<br>
</blockquote>
<br>
OK<br>
<br>
<br>
Here is a revised diagram which incorporates your
suggestions and then my<br>
modifications to those. Let me know what you think.<br>
<br>
<br>
Regards,<br>
-Dave<br>
<br>
<br>
<br>
_______________________________________________<br>
Halld-tracking-hw mailing list<br>
<a moz-do-not-send="true" href="mailto:Halld-tracking-hw@jlab.org">Halld-tracking-hw@jlab.org</a><br>
<a class="moz-txt-link-freetext" href="https://mailman.jlab.org/mailman/listinfo/halld-tracking-hw">https://mailman.jlab.org/mailman/listinfo/halld-tracking-hw</a><br>
<br>
</blockquote>
_______________________________________________<br>
Halld-tracking-hw mailing list<br>
<a moz-do-not-send="true" href="mailto:Halld-tracking-hw@jlab.org">Halld-tracking-hw@jlab.org</a><br>
<a class="moz-txt-link-freetext" href="https://mailman.jlab.org/mailman/listinfo/halld-tracking-hw">https://mailman.jlab.org/mailman/listinfo/halld-tracking-hw</a><br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Halld-tracking-hw mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Halld-tracking-hw@jlab.org">Halld-tracking-hw@jlab.org</a>
<a class="moz-txt-link-freetext" href="https://mailman.jlab.org/mailman/listinfo/halld-tracking-hw">https://mailman.jlab.org/mailman/listinfo/halld-tracking-hw</a></pre>
</blockquote>
<br>
</div>
_______________________________________________<br>Halld-tracking-hw mailing list<br><a href="mailto:Halld-tracking-hw@jlab.org">Halld-tracking-hw@jlab.org</a><br>https://mailman.jlab.org/mailman/listinfo/halld-tracking-hw</blockquote></div><br></body></html>