OV Channel Mapping Proposal

1) Resolve Strip # Geometry Inconsistencies:

UC Strip # and OV firmware assumed layout (Looking from PMT end down the length of the module)

         + 33 + 34 + 35 + 36 + 37 + ...

       + 1 + 2 + 3 + 4 + 5 + ...
   
          MC Strip # and MC layout (Looking from PMT end down the length of the module)

       0 + 1 + 2 + 3 + 4 + ...

       + 32 + 33 + 34 + 35 + 36 + ...

Implications: Affects the edge strip firmware, which assumes the first layout above.

Status: Needs to be fixed and propagated to MC, if necessary. UC should take the lead on this.

2) Eliminate MC strip # and instead use UC Strip #

Solves: Issue that fStrip2Pixel tacitly assumes UC Strip number as input

Implications: Modify GetMuLikeNeighbor, Edge Strip condition. Any other problems? RecoOV?

Status: Not yet implemented, add or replace column in ascii table?

3) Enforce equivalency of pmtboard_u numbering scheme and MC module # scheme

Solves: Inconsistency with data

Implications: pmtboard_u and MC table must be always in sync, manual or mysql

Status: Work already done by Arthur, should be double-checked?

4) Encode detector in pmtboard_u on mySQL

Solves: Inconsistency with MC

Implications: RoSS, RecoOV, CalibApply look OK, but should be tested by Arthur & Emily.

Status: Tested with OV DAQ, can be fully implemented in a matter of minutes.

5) Eliminate dCH_OFFSET_OV in favor of DC::OV_CHANNEL_INDEX

Solves: Inconsistency with data, max OV channel out of range of ushort int

Implications: Far detector OV channel range: 14,100 – 18,763

Near detector OV channel range: 24,100 – 31,363

Status: Completed

6) Separate Physical Quantities from Electronic quantities

Solves: Inconsistency between # of pmt boards and # of modules

Implications: GetPMTBoardPMT _OV, GetChannel _OV, PMTBoardWithinOV added. ChWithinOV, StripWithinOV modified.

dTRIGBOX_OUTVETOFD_MAX, dTRIGBOX_OUTVETOND_MAX added.

Status: Completed

7) Verify xtalk code works on Maroc2 channel number (and not Hamamatsu pixel #)

Solves: Inconsistency between channel/pixel #

Implications: None. I think the code does work in Maroc2 pixel number (it's symmetric)

Status: Crosscheck by Matt Strait?

-- MattToups - 17 Mar 2011