[Halld-tracking-hw] Tracking minutes posted

[David Lawrence]

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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mailman.jlab.org/pipermail/halld-tracking-hw/attachments/20130723/a1fcb2d3/attachment.html