[Halld-tracking-hw] Tracking minutes posted
David Lawrence
davidl at jlab.org
Wed Jul 24 09:37:41 EDT 2013
Hi Beni,
How do we adjust where the pedestals are? I can imagine a software
offset in the FPGA, but that won't fix
a negative DC offset. Do the modules have the capability of setting this
via VME? (My experience with old
modules was using a small screwdriver, but that can work here!)
Regards,
-David
On 7/24/13 9:14 AM, Beni Zihlmann wrote:
> Hi Naomi, everybody,
>
> I finally looked through all the back and forth on this issue and more
> or less understand
> the last iteration of the data format. So here my 0.5 cent blabla:
>
> 0) As you point out the pedestal position/width changes if a cable is
> connected to the ADC or not and
> also where the cable is coming from (pream source) because all
> this matters to the overall ground
> and capacitive coupling that is seen by the ADC channel.
> that is why we need to monitor the pedestal at all times and needs
> to be in the data.
>
> 1) 12 Bits for the pedestal is overkill. As you write below we want to
> have the pedestal as reasonably
> low as possible to maximise the dynamic range of the ADC. An
> offset of 0x8000 puts that pedestal
> roughly in the middle of the full range of the ADC but there is
> quite a large variation from channel
> to channel. In the FDCs I observe base lines easily vary between
> 2500 and 5000 or even more.
> (note these numbers are with the traditional factor 4 ! ;-) )
> The offsets should be set such (for each individual channel) that
> it is sufficiently high above zero to
> accommodate the noise. This means it has to depend on the width
> of the pedestal (noise), lets say
> for the sake of argument an offset above zero is 4 sigma of the
> pedestal. I can not remember what
> the answer was to the question "what happens to the ADC when the
> input signal undershoots the
> low edge of the dynamic range?"
> Note that the pedestal is normalized to one sample.
> From this considerations the pedestals in the proposed data
> format can easily be expressed with 8 bits.
>
> 2) we do not need special pedestal runs, what we need is special runs
> reading out all samples with the offsets
> all set at 0x8000 or some other most preferred offset. From that
> data one can easily calculate the pedestals
> and width and from that new best offsets. These new offsets can
> then be loaded and the procedure repeated
> to verify/optimize the settings if so desired.
> -> which of course brings up another point of book-keeping these
> pedestals, width and offsets and what is
> currently loaded in the ADCs.
>
>
> 3) I think it is a very bad idea to have different data formats for
> the FDC and CDC. We have to come up with
> a common solution. The threat of a potential mix-up in the future
> overweights any benefit I see.
>
> 4) The next very important step is now to understand what algorithms
> we want to implement to determine
> pedestal, integral and time. I guess this is the harder part. We
> have to specify what we want and find
> out what we can get ;-) (We can't always get what we want but we
> can try).
> -> I propose for the next tracking meeting to have a discussion
> of what we want. We should try to start
> with the basics (simple approach with expansion in mind) and
> then go from there to see how far we
> can push the system.
>
>
> cheers,
> Beni
>
>
>
>
>
>
>> Hello,
>>
>> OK.
>>
>> Yes using all 12 bits would indicate a huge problem, pedestal should
>> really be in a much smaller range such as between 40 and 80, could be
>> higher if on the tail end of a previous event. If it moves (and
>> stays) outside that range you need to know where it is in order to
>> correct the offset on the flash. I am finding that the pedestals
>> change when I switch electronics or read out a different set of
>> straws. Also the pedestal rises (and gain falls) if the preamp LV
>> supply drops, which is a good indicator of a bad cable at the HVB
>> end. So we would need full range readout at least for setting the
>> pedestals following maintenance and for periodic monitoring; this
>> could be done using a dedicated pedestal data format rather than in
>> the pulse data format.
>>
>> Naomi.
>>
>>
>>
>>
>> On Jul 23, 2013, at 11:08 AM, David Lawrence wrote:
>>
>>> Hi All,
>>>
>>> To answer your last question first: Yes, the crate number (rocid)
>>> is included in an EVIO header that is put on by the ROC before the
>>> data is sent over the network. The ROC may send more than one
>>> "Physics Event Bank" for a block of events (e.g. multiple DMAs are
>>> used), but the number will generally appear just once or twice for
>>> all hits in all events in the block.
>>>
>>> As for the pedestal, wouldn't this indicate a problem if the
>>> pedestal itself was a large enough number as to require 12 bits? I
>>> thought from earlier discussions we were going to try and adjust the
>>> pedestal so that it was never larger than say, a 9 -bit number could
>>> hold (0-511). This would leave 6 bits for the Q.F. Not that I'm
>>> completely opposed to dropping the slot from the hit data, but I do
>>> like how it is currently being used to help check the data integrity
>>> in a stream-like fashion which helps supplement the other checks
>>> being done with larger data chunks.
>>>
>>> Regards,
>>> -David
>>>
>>> On 7/23/13 10:43 AM, Naomi Jarvis wrote:
>>>> Hi Gerard,
>>>>
>>>> David put together a draft document for the current spec -
>>>> http://argus.phys.uregina.ca/cgi-bin/private/DocDB/ShowDocument?docid=2274
>>>>
>>>> There the slot does come before the channel, and we have one large
>>>> 15-bit chunk designated as quality factor which would include the
>>>> pedestal.
>>>> I hadn't realized that the slot would also be in the block header.
>>>>
>>>> Could we take some of the 5 bits marked slot and move them into the
>>>> QF section? The extra space (QF would then be 20 bits) would allow
>>>> for full precision pedestal in 12 bits, plus another 8 for quality
>>>> indicators. Also, we have 3 bits in the block header to designate
>>>> data format, or rather, how to interpret the QF part. I would
>>>> hope that we would not go through more than 8 iterations of this
>>>> but it could happen, and 1 or 2 bits of the QF section could be
>>>> kept aside for this. If we have full precision pedestal in the
>>>> event readout then I don't think we would need separate pedestal runs.
>>>>
>>>> (Is there another header designating the crate which is tagged on
>>>> separately?)
>>>>
>>>> Best,
>>>>
>>>> Naomi.
>>>>
>>>>
>>>>
>>>>
>>>> On Jul 23, 2013, at 9:58 AM, Gerard Visser wrote:
>>>>
>>>>> hi Dave,
>>>>> I think it might be better to provide a more generic and
>>>>> all-encompassing
>>>>> redundancy in the data, such as by inserting a CRC word every N
>>>>> hits or at end
>>>>> of block or something like that. Just a fixed pattern on a few
>>>>> bits is a pretty
>>>>> minimalist sort of redundancy, e.g. would not detect if an even
>>>>> number of
>>>>> longwords was dropped, for instance.
>>>>> I also suspect that more bits might be good for quality/status of
>>>>> the hit,
>>>>> although I don't have a specific proposal. At the moment I see it
>>>>> is proposed
>>>>> (1c) to have 13 bits for "pedestal"&quality (these are all quality
>>>>> bits IMHO).
>>>>> This may eventually prove not to be enough, then the 5 slot bits
>>>>> could be added
>>>>> into this purpose.
>>>>> Regardless of the slot bits, I think you are certainly right to
>>>>> put some
>>>>> redundancy in the data that can be used for integrity check, so
>>>>> IMHO you should
>>>>> add some CRC words explicitly for that purpose.
>>>>> Sincerely,
>>>>>
>>>>> Gerard
>>>>>
>>>>> p.s. Minor point: If you do keep slot field, how about putting it
>>>>> to the left of
>>>>> channel field, so that the whole thing can be interpreted as a 12 bit
>>>>> superchannel number? Of course the bit arrangement doesn't matter
>>>>> except to
>>>>> improve human readability of the code and data.
>>>>>
>>>>>
>>>>> On 7/23/2013 1:14 AM, David Lawrence wrote:
>>>>>>
>>>>>> Hi Gerard,
>>>>>>
>>>>>> That's correct, "slot" is the slot in the VME crate. You're
>>>>>> right, it
>>>>>> could be sacrificed from the hit record if needed. Right now, it
>>>>>> appears
>>>>>> in the both the block header and hit record and is currently used
>>>>>> by the
>>>>>> parsing software to provide a small integrity check on the data. If
>>>>>> there is something else more worthy of those bits, we can consider
>>>>>> dropping it from the hit record.
>>>>>>
>>>>>> Regards,
>>>>>> -Dave
>>>>>>
>>>>>> On 7/23/13 12:47 AM, Gerard Visser wrote:
>>>>>>> hi Naomi, Dave,
>>>>>>> What is 'slot' by the way? (5/62 hit payload bits used for
>>>>>>> this.) I guess it is
>>>>>>> the ADC module number? But why put this in the hit record? It
>>>>>>> can just as well
>>>>>>> be in the block or event header from the module, it will be
>>>>>>> constant for all hit
>>>>>>> records from the module...
>>>>>>>
>>>>>>> - Gerard
>>>>>>>
>>>>>>>
>>>>>>> On 7/22/2013 7:58 PM, Naomi Jarvis wrote:
>>>>>>>> Minutes are online at
>>>>>>>> https://halldweb1.jlab.org/wiki/index.php/July_17,_2013_Tracking_CDC/FDC
>>>>>>>>
>>>>>>>> Also I think I forgot to email the same for the previous
>>>>>>>> meeting, sorry, those are at
>>>>>>>> https://halldweb1.jlab.org/wiki/index.php/July_3,_2013_Tracking_CDC/FDC
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>
>>>>>>>> Naomi.
>>>>>>> _______________________________________________
>>>>>>> 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 <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/20130724/cf754ff1/attachment-0001.html
More information about the Halld-tracking-hw
mailing list