[Halld-tracking-hw] Tracking minutes posted
Beni Zihlmann
zihlmann at jlab.org
Wed Jul 24 09:50:14 EDT 2013
Hi David,
the software library from Bryan Moffit provides two functions
to set the offsets:
int fa125SetOffset(int id, int chan, int dacData);
int fa125SetOffsetFromFile(int id, char *filename);
As you can see the first functions allows you to set the pedestal for a
channel
while the second function reads from a file and sets the offsets for all
channels
in the module.
Setting the offsets part of the initialization at the beginning of a
run. this could be
part of the "prestart" state transition or "download". I guess we have
to make up
our mind at what stage that should be done. -> DAQ discussion.
Also we probably want the time interval over which to calculate the ADC
integral
to be a parameter that can be set at start-up because we need different
intervals
for FDC and CDC. The same is true for the range over which to search for
signals.
Similar configuration issue exist for the F250 and the T1.
cheers,
Beni
>
> 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/6ca95b55/attachment-0001.html
More information about the Halld-tracking-hw
mailing list