Difference: OVChannelMapping (2 vs. 3)

Revision 32011-03-02 - MattToups

Line: 1 to 1
 
META TOPICPARENT name="MattToups"

OV Channel Mapping Conventions

Changed:
<
<		There are 4 different numbering conventions used to indicate the 64 "channels" in an OV "module":
>
>		There are 5 different numbering conventions used to indicate the 64 "channels" in an OV "module":
 
  • Pixel #: Hamamatsu labeling physically written on the M64s (1-64).
  • Maroc2 Channel #: Convention used in the Maroc2 and FPGA firmware (0-63). Maroc2# = (64 - Pixel#)
Changed:
<
<
  • UC Strip #: Convention used at the UC to number a strip within a module.
>
>
    • This is the "channel number" referenced in Emily's email verifying the MC channel mapping (channelstripMapping.txt -- see attached).
    • This is the "channel number" (offset by 1) referenced in Mark's original email giving the channel mapping (see attached)
  • UC Strip #: Convention used at the UC to identify a number a strip within a module.
    • This is the "strip number" referenced in Mark's original email giving the channel mapping (see attached)
    • This is the "UC strip number" referenced in Emily's email verifying the MC channel mapping (channelstripMapping.txt -- see attached).
    • This is the "strip number" referenced in Arthur's updated channel map he sent around (but didn't update on Doc DB, see attatched).
 
  • MC Strip #: Convention used in the MC ($DOGS_PATH/DCDB/data/Geometry) to number a strip within a module.
Changed:
<
<		There are 2 different numbering conventions used to indicate the 44 (68) "modules" in the OV far (near) detector
  • UC Module #: Convention used by UC to identify a module within the OV far detector hall.
>
>
    • This is referenced in Emily's email (channelstripMapping.txt -- see attached).
  • Fiber #: Only used internally by UC.
    • This is referenced in Mark's original email
It has been verified that the edge strip firmware, which treats Maroc2 channels 0 and 63 differently, maps onto the actual edge strips.

There are 3 different numbering conventions used to indicate the 44 (68) "modules" in the OV far (near) detector

  • UC Module Position #: Convention used by UC to identify a module within the OV far detector hall.
 
  • MC Module #: Convention used in the MC to identify a module at the far/near detector.
Added:
>
>		It has been verified by Arthur (before the commits by Matt W.) that the MC module #, Trigbox #, and Trig box channel # matched Camillo's spreadsheet which was used to code the OV firware for the 3 trigger boxes. We must program the address of each pmt board and trigger box according to this spreadsheet for our scheme to be self-consistent.
 There is another numbering conventiono closely related to, but not exactly the same as, the number of modules
  • pmtboard_u #: Convention used in the data to identify each module AND trigger box in the OV far/near detector.
Added:
>
>		There are also numberings related to the extrusion of each strip and the construction of each module, but the mapping between these and the module position # will be maintained by UC via a log book.
 

Data Format

The OV data is stored in a TClonesArray of OVHitInfo objects, each of which contains:

Line: 136 to 149
 
    • Strip = (100*module#) + (local strip)
    • module = (100*det#) + detector-specific module
    • The number of channels is between dCH_OFFSET_OV and 2*dCH_OFFSET_OV
Added:
>
>
    • fStrip2Pixel converts UC strip # to Maroc2 Channel according to Mark's email
 
  • This is wrong because
    • There are more PMTs (boards) than (physical) modules and therefore
    • There are more channels than strips
    • The offset that should be used is DC::OV_CHANNEL_INDEX and for this offset the number of OV channels is not between DC::OV_CHANNEL_INDEX and 2*DC::OV_CHANNEL_INDEX.
Added:
>
>
    • fStrip2Pixel should convert MC strip # to Hammamatsu Pixel #
    • fStrip2Maroc2 should convert MC strip # to Maroc2 Channel #
 

  • Implications

    • The ChWithinOV and StripWithinOV functions should be separated
    • DCGeo should be able to access and apply the mapping between module # and pmtboard_u.
    • Information about about the detector should be added to the data stream.
    • dCH_OFFSET_OV or DC::OV_CHANNEL_INDEX?
    • Changed:
    <
    <
    • Verify that "pixel" in the DB refers to MAROC2 CHANNEL
    >
    >
    • Disentangle the usage of fStrip2Pixel from fStrip2Maroc2, which must be implemented.
     
    • How should DCCalib access OV data? At the OVHit level?
    • A call to Geo::GetME()->GetOVMTrigChan() should be added to the section of DCRElectoOV where OVHitInfo objects for edge strips packets are created.
    -- MattToups - 23 Feb 2011
    Added:
    >
    >
    META FILEATTACHMENT attachment="MarkEmail.txt" attr="" comment="" date="1299085181" name="MarkEmail.txt" path="MarkEmail.txt" size="813" user="MattToups" version="1"
    META FILEATTACHMENT attachment="channelStripMapping.txt" attr="" comment="" date="1299085181" name="channelStripMapping.txt" path="channelStripMapping.txt" size="1771" user="MattToups" version="1"
    META FILEATTACHMENT attachment="channel_maps.pdf" attr="" comment="" date="1299085181" name="channel_maps.pdf" path="channel_maps.pdf" size="5762" user="MattToups" version="1"
    View topic | History: r5 < r4 < r3 < r2 | More topic actions...
     
    This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2023 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
    Ideas, requests, problems regarding TWiki? Send feedback