[Halld-tracking-hw] Tracking minutes posted
Fernando J Barbosa
barbosa at jlab.org
Wed Jul 24 09:49:12 EDT 2013
Hi David,
The offsets are programmable via VME.
Best regards,
Fernando
On 7/24/2013 9:37 AM, David Lawrence wrote:
>
> 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
>
>
>
> _______________________________________________
> 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/d63d9044/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: barbosa.vcf
Type: text/x-vcard
Size: 265 bytes
Desc: not available
Url : https://mailman.jlab.org/pipermail/halld-tracking-hw/attachments/20130724/d63d9044/attachment-0001.vcf
More information about the Halld-tracking-hw
mailing list