[Halld-tracking-hw] Tracking minutes posted
Naomi Jarvis
nsj at cmu.edu
Wed Jul 24 09:50:24 EDT 2013
It's done in software - the flashes read in the offsets from a file upon initialization. If the signal drops below the readout window what you then see is zero.
Naomi.
On Jul 24, 2013, at 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
>>>>>>>> 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
>>
>>
>>
>> _______________________________________________
>> 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/b041167c/attachment-0001.html
More information about the Halld-tracking-hw
mailing list