J. Kissel

I was warned that -- though all the GND STS channels are mapped from the instrument to the frames correctly now (see LHO aLOG 14072) -- what actually gets fed into the sensor correction filter banks is a total mess in the corner station. I've scoured the front-end simulink models, toggled some switches at the racks in the EE bay, and stomped on the ground near the STSs themselves trying to map it out, and all I can say is WOW do I agree. I'll work with the SEI and CDS groups to clean up.

Here're the facts, as they stand now, in order of my discovery:
(1) In reality, we want the following seismometer-location-to-channel map for all 17 digital instances of the signals in the corner (6 HAM HPIs, 5 HAM ISIs, 3 BSC HPIs, 3 BSC HPIs):
       Just +X of HAM2    => STS A
       In the Beer Garden => STS B
       Just +Y of HAM5    => STS C
as determined by D1002704, revised due to Integration Issue 45, and DCN E1400111.
(2) I've confirmed that the above mapping is correct for ITMY (the "master" front-end model responsible for storing these STSs and "GND" channels in the frames) by performing my finest hill-billy hoe-down near the respective STS, and watching the ISI-GND channels on a CDS laptop. 
(3) Because of the STS-2 analog distribution chassis, and that the SEI BSC wiring diagram (D0901301), and SEI HAM wiring diagrams (D1101584, D1101576, and D1000298) were written before the ABC convention was established and not addressed in E1400111, there're 17-choose-3 = 680 possible combinations, and I'm pretty sure we used all of them.

Front end models:
(4) ALL HAM-ISIs use the library part, ${userapps}/release/isi/common/models/isihammaster.mdl. There is another library, isiham236master.mdl, that looks deceiving in the same directory, but it's unused according to the tar balls of source code for what's actually running on the IFO. This should be removed from the repo.
(5a) The HAM-ISIs  are reasonably consistent, in that, 
       ADC_0 or ADC_2 Channels 24-26 => STS A XYZ
       ADC_0 or ADC_2 Channels 28-30 => STS B XYZ
       ADC_1 or ADC_3 Channels 24-26 => STS C XYZ
where it's ADC_0/1 on the "first" HAM-ISI in the I/O chassis, and ADC_2/3 on the "second" HAM-ISI (HAM2, HAM4, and HAM6 are the "firsts," HAM3 and HAM5 are the "seconds."). 
(5b) EXCEPT HAM2, who has ADC_0 channels 24-26 mapped into BOTH STS A and STS B. 
(6) Because of an RCG "feature" even though different ADC *card* numbers are used between the seconds and firsts, the block name is always ADC 0 or ADC 1. 
(7) The HAM-HPIs all use the same library part, ${userapps}/release/hpi/common/models.
(8a) HPIs HAM2-5 have GND STSs hooked up, also, reasonably consistent in that they all use
       ADC_0 or ADC_2 Channels 24-26 => STS A XYZ
all piped into STS A, with STS B and STSC terminated. Again, the "firsts" use ADC0, and the "seconds" use ADC 2. 
(8b) EXCEPT HAMs 1 & 6 have all STS inputs terminated.
(9) The BSC ISIs and the BSC-HEPIs are consistent, but consistently bonkers.
       BSC1 ITMY ADC_3   23-25 => STS A
                         26-28 => STS B
                         29-31 => STS C
       BSC2 BS   ADC_3   29-31 => STS A
                         23-25 => STS B
                         26-28 => STS C
       BSC3 ITMX ADC_3   26-28 => STS A
                         29-31 => STS B
                         23-25 => STS C
That's right -- the channels have been cyclically rotated between BSC chambers.

Electronics Chain:
To test out which STS chassis maps to which GNDSTSINF (for ISIs) or STSINF (for HPIs), just in case the STS distribution chassis had been used to rectify the front-end badness, I toggled the period switch on the front of each of the three chassis, in consecutive order, and followed which channels showed the characteristic flip to (more) AC coupled signal (1 [sec] period) and then drove off into tilt land after switching back to the low-frequency mode (120 [sec] period). Since I didn't want to disconnect any cables, and couldn't simultaneously look at all the channels needed with the tiny laptop while zydeco dancing, all I could determine which which *rack* affected which GNDSTSINf or STSINF channel.
(10) BSC 1 (ITMY) ISI and HPI on-board sensors are read out in rack SEI-C4, BSC2 (BS) ISI and HPI are read out in rack SEI-C5, and BSC3 (ITMX) ISI and HPI are read out by rack SEI-C6. As such, I'll refer to the STS chassis that I switch as C4, C5, and C6, after the rack in which they're mounted, since I was unable to determine which was HAM2 (STS A), Beer Garden (STS B), or HAM5 (STS C).
(11) For the BSC-ISIs, the matrix of channels affected by the switching is as follows:
          ITMY     BS      ITMX
     C4     A       A       A
     C5     B       B       B
     C6 (bonkers)   C       C
This indicates that, even though the ADC to model mapping is some crazy, cyclic thing, the cables from the STS distribution chassis have been arranged such that what goes into the ADC is "normal." The ITMY STS C channel doesn't make any sense to me. It didn't respond to any of the period-switch toggles, but still showed live tilt-full signals. Need to debug that one.
(12) For the BSC-HPIs, it's different:
          ITMY     BS      ITMX  
     C4    A        B       C
     C5    B        C       A
     C6    C        A       B
This indicates, that the cabling matches the crazy-bonkers front-end mapping.
(13) For the HAM-ISIs, it's different:
           HAM2     HAM3     HAM4     HAM5     HAM6
     C4    A&B       A      (dead)   (dead)      A
     C5 (no change)  B      (dead)   (dead)      B
     C6     C        C      (dead)   (dead) (no change)
HAM2 is weird, but is consistent with the model layout described in (5b). HAMs 4 and 5 are receiving only ADC noise -- maybe this means the channels aren't hooked up? I didn't check.
(14) And finally, the HAM-HEPIs, they're the worst off:
           HAM1     HAM2     HAM3      HAM4      HAM5     HAM6
     C4   (n/c)      A        B       (dead)    (dead)    (n/c)
     C5   (n/c)     (n/c)    (n/c)    (n/c)      (n/c)    (n/c)
     C6   (n/c)     (n/c)    (n/c)    (n/c)      (n/c)    (n/c)
where "n/c" is not connected in the front-end model as described in (7a). Still no help as to why HAM4 and HAM5 are reading out ADC noise.
And that's the anti-climactic end of the list. We've got some work to do!

Step-one will be to update the SEI wiring diagrams to clearly define how each STS gets into each front-end via an ADC channel list. Next, change the top-level front end models to match the convention in the drawings. Third, change the cabling at the racks around so we get the expected behavior. At the moment, although it's don't in an icky way, the BSC-ISIs are our best case.