Displaying reports 63401-63420 of 77237.Go to page Start 3167 3168 3169 3170 3171 3172 3173 3174 3175 End
Reports until 10:14, Tuesday 30 September 2014
H1 CDS
james.batch@LIGO.ORG - posted 10:14, Tuesday 30 September 2014 (14226)
New software installed for Ubuntu control room workstations
WP 4869

The user environment has been changed to set up the awgstream environment properly.

The CERN ROOT package has been replaced with a version that supports python.

The gds software (diaggui, foton, etc) has been updated to gds-2.16.12.2, which has a number of bug fixes and a few enhancements:

* python scripting capability for awg and foton have been added.
* Cut/paste added to the Calibration dialog box in diaggui (and foton).
* Long channel names are no longer ignored in the Calibration dialog box.
* Fix bug preventing diaggui from reliably making continuous measurements.
* Unsigned 32 bit integer data support for diaggui time series.
* Foton legacy write option has been removed.
* Fix foton bugs for file path option, add "-o " option for non-gui file processing.
* Fix foton bug which caused crashes when invoked from diaggui.
H1 CDS (PEM)
david.barker@LIGO.ORG - posted 10:07, Tuesday 30 September 2014 (14225)
Power cycle of h1iscey to fix bad PEM ADC channels

Sudarshan, Jim and Dave

We power cycled h1iscey as part of the investigation to fix some dodgy ADC channels, we were not successful.

sequence:

take h1iscey out of dolphin, stop models, power down CPU, power down IOChassis, power down PEM AA chassis.

power up AA, power up IOChassis, power up CPU.

H1 PSL (PSL)
gabriele.vajente@LIGO.ORG - posted 09:53, Tuesday 30 September 2014 (14224)
Fine tuning of ISS pointing sensitivity

Sudarshan, Gabriele

To try to reduce as much as possible the beam pointing sensitivity of the ISS photodiodes, we wrote a python script that reads the PD signals and demodulate them with the excitation sent to IM3. In this way we could send a 12 Hz, 1000 cts sinusoid in yaw and a 17 Hz, 1000 counts sinusoid in pitch, and look at time domain traces of the demodulated signals, as shown in the first attached plot. We moved a bit the picomotors, and we could improve quite a lot the situation. As shown in the second plot, right now we almost can't see the sinusoids in the PD signals, since they're below the noise background. Here are therefore upper limtis on the dP/P/dx:

Photodiode Pitch [1/m] Yaw [1/m]
PD5 18 105
PD6 18 64
PD7 20 107
PD8 21 79

The optimal position we found is not exactly with the QPD centered (both x and y are around 0.3). Maybe we could improve this, but for the moment we guess the situation is good enough.

Images attached to this report
H1 PSL (PSL)
corey.gray@LIGO.ORG - posted 08:30, Tuesday 30 September 2014 (14220)
PSL Diode Chiller Topped Off

Per the weekly Tues Maintenance task, the chiller was topped off to the MAX level mark (needed ~250ml to do this).  The stopper for the Chiller isn't ideal (seems a bit big and sheds a bit to make it seat in the inlet).  Last time the chiller was filled was on 9/15/14.

H1 PSL
gabriele.vajente@LIGO.ORG - posted 08:22, Tuesday 30 September 2014 (14206)
Beam pointing sensitivity of ISS photodiodes

I measured the beam pointing sensitivity of all the eight ISS second loop diodes. The naming is the one corresponding to the new slow channel acquisition, we'll check tomorrow the correspondence to the PD1-8 signals. For some diodes, in pitch, I was not able to see any significant modulation

Channel dP/P/x [1/m] PITCH dP/P/x [1/m] YAW
CH24 - PD1 - 560
CH25 - PD2 140 910
CH26 - PD3 170 340
CH27 - PD4 - 150
CH28 - PD5 - 370
CH29 - PD6 220 1610
CH30 - PD7 780 520
CH31 - PD8 270 540

For those not familiar with the meaning of these numbers, the typical values measured for the ISS array before installation were between 1 and 30, depending on the array and on the diode. So the numbers I got are in general quite large.

This beam position on the PD is maybe not the best one, since we are not at the maximum power for all the diodes simultaneously. For each diode, it is possibile to find a beam position that gives maximum power. This also corresponds to undetectable coupling of beam motion to dP/P (at least at this level of excitation). However, the good position is different for each diode, and the non optimal one can have a significant loss of power and large coupling of beam motion to dP/P. The table above is representative of what we normally get.

Here is the procedure in details

  1. Move the beam using the picomotors to center the QPD. Dither IM3 with an amplitude of 100 counts at 1 Hz in both pitch and yaw (H1:SUS-IM3_M1_OPTICALIGN_P_EXC and H1:SUS-IM3_M1_OPTICALIGN_Y_EXC), and measure the normalized signal on the QPD. I got 0.14 peak to peak in pitch and 0.22 peak to peak in yaw. The beam size on the QPD should be 250 um. The normalized signal should be given by sqrt(8/pi) * deltaX / w where deltaX is the beam motion on the QPD and w is the beam size. Therefore, 100 cts at 1 Hz of IM3 correspond to 22 um in pitch and 35 um in yaw of beam motion on the QPD. I assume that the motion on the photodiode is the same. 
  2. With the dither on, I measured the mean value of each of the photodiode and the peak to peak oscillation at the dither frequency, separately in pitch and yaw. I had to move pitch of 300 counts (70 um beam motion on the diodes) and yaw of 100 counts (35 um of beam motion on the diodes). Larger amplitudes were giving weird signals.
  3. From the photodiode signals I computed the dP/P and then the dP/P/x reported above
H1 SEI
hugh.radkins@LIGO.ORG - posted 08:15, Tuesday 30 September 2014 (14219)
Early AM Spectra for HAM6 on Lvl3 Controller

Comparable to other Level3s.

Images attached to this report
H1 PSL (PSL)
peter.king@LIGO.ORG - posted 08:14, Tuesday 30 September 2014 (14218)
PSL Weeklies
Weekly report of various things.

There are daily spikes in the H1 chiller and diode room relative humidity.  The spikes also occur in the chiller room temperature but not in the diode room,
or at least the ones in the diode room are not as large.
Images attached to this report
H1 PSL (PSL)
peter.king@LIGO.ORG - posted 08:07, Tuesday 30 September 2014 (14216)
PSL Diagnostic Breadboard Scan
Relative power noise looks nominal.  Better than the reference measurement below 10 Hz and a factor of a few worse between 10 Hz and 4 kHz.  The ISS was locked at the time with a diffracted power of ~9%, REFSIGNAL -2.03 V, and output DC of 10.01 V on PDA, 10.19 V on PDB.  Gain slider on 10 dB.

Frequency noise is better than the reference measurement above ~500 Hz, worse below.  Otherwise the same as per previous weeks.

Beam pointing looks nominal.  All better than the reference measurement.

Mode scan looks nominal.  Higher order mode count slightly higher than last week, 55 cf. 56.  Higher order mode power slightly higher too, 4.7% cf. 4.6%.  Nothing to worry about.

ISS relative power noise looks good.  The out of loop measurement (PDB) is flat from 3 Hz to ~100 Hz, at ~1.3E-8.  Rising to ~2E-8 at 1 kHz.
Non-image files attached to this report
H1 CDS (DAQ)
david.barker@LIGO.ORG - posted 07:18, Tuesday 30 September 2014 (14217)
CDS model and DAQ restart report, Monday 29th September 2014

no restarts reported

H1 ISC
sheila.dwyer@LIGO.ORG - posted 22:17, Monday 29 September 2014 (14214)
ALS COMM and DIFF work today

Kiwamu, Jenne, Alexa, Sheila, Daniel,

Today we locked ALS COMM.  We chaanged the locking sequence compared to our old sequence.  One difference is that we have moved the notches in MC2 to M2, so we can have a higher crossover between the slow and fast actuators (CARM gain is 240 now, instead of 80).  We also got rid of a z5 p20 filter we had in the CARM filter module.  The rest is the same as it was in late May.  This seems to be locking fairly robustly.  The ugf is 1 kHz, with a phase of -80 deg.  A measurement of the cross over is attached.

We also aligned the DIFF beatnote, 800mVpp.  We have locked this at low gain a few times.  We need to feedback to the top mass of the ETMs to keep the DIFF PLL within the VCO range, but we have had trouble engaging the tidal feed back.

Images attached to this report
H1 SEI
fabrice.matichard@LIGO.ORG - posted 19:13, Monday 29 September 2014 (14210)
LLO blend filters loaded on ITMY

[Jim, Fabrice]

 

To help comparing and finding the best of the blend configurations used at each sites, we loaded the LLO blend configuration on ITMY.  Unlike for previous transfers of filters from site to site, we did not export the filters from LLO foton files into different continuous or digital forms before to re-convert them, simplify and re-install them into LHO foton file. We directly copied and pasted the second order sections from one foton file to another. [We used the filter file logged in the repository Keith has set up (very useful!): https://daqsvn.ligo-la.caltech.edu/websvn/]. A few blend filters take two banks,  we left it that way.

We performed measurements with the initial configurations (called "before" in the figures) and with the LLO filters configuration (called "after" in the figures). The blend configurations are summarized at the end of the report.

- The first two figures show the ISI motion for each configuration. Using the LLO config (after), the X and Y motion is lower at the suspension resonances at the cost of more motion at higher frequencies (good compromise). The rotational motions appear higher at most frequencies.

- The next two figures show the suspension point motion for each configuration. In the initial configuration, the suspension point motion is dominated by ISI longitudinal motion at almost all frequencies. With the LLO blend, the RZ motion takes over around 1 Hz.

- The last two figures show the optical lever motion for each configuration. In this example the Pitch RMS motion went from 5.8 nRad (before) to 4.1 nRad (after).  The Yaw RMS motion went from 6.6 nRad to 4.2 nRad. [These numbers seem very small (calibration issue?) but the relative comparison is probably fair.] 

We leave it on for tonight for making a comparison over a longer stretch of time.

---------------

Blend configuration used for the "before"  and 'after" measurements.

DOF:            Before  /  After

Stage 1 X : Tbetter  / 45mHz

Stage 1 Y: Tbetter / 45mHz

Stage 1 RZ: TCrappy / Off

Stage 1 Z: T750mHz / 90mHz

Stage 1 RX: Tbetter  / [250a & 250b for CPS and T240, 250 for L4C]

Stage 1 RY: Tbetter  / [250a & 250b for CPS and T240, 250 for L4C]

Stage 2 X : T750mHz  / 250 mHz

Stage 2 Y: T750mHz  / 250 mHz

Stage 2 RZ: T750mHz / Off

Stage 2 Z: T750mHz / Off

Stage 2 RX: T750mHz / Off

Stage 2 RY: T750mHz / Off

Images attached to this report
H1 ISC
keita.kawabe@LIGO.ORG - posted 19:11, Monday 29 September 2014 (14212)
Green WFS today

After finding good whitening setting, the arm was aligned, I walked the beam on WFSB to find a good offset.

Demod phase was set after finding a good position on WFSB (PIT offset = -0.15, YAW=0). For WFSA I never set any offset.

See the first attachment for the demod phase.

See the second for the spectra after an offset of -0.15 was set for the WFSB PIT centering servo to balance the demod signal peak generated by an excitation to the PDH board EXC A.

Images attached to this report
H1 PSL
gabriele.vajente@LIGO.ORG - posted 18:55, Monday 29 September 2014 - last comment - 07:11, Tuesday 30 September 2014(14211)
Improved ISS centering on photodiodes

Sudarshan, Gabriele

We significantly improved the beam centering on the ISS array: now we have good powers on all diodes, centered QPD and lower coupling of beam motion to dP/P

The procedure

  1. We wrote a python script that uses the picomotor 1 to maintain the beam centered on the QPD. 
  2. We moved picomotor 8, mainly in the LEFT direction. After each motion, we ran the script to recenter the beam on the QPD. We then checked that we were improving the power levels.

After a lot of steps in the LEFT direction and few in the UP direction (for picomotor 8), we could get the beam centered on the QPD and good power levels on all diodes. Actually, we believe we are quite close to the maximum power for each diode.

The results

The following table compares the power levels (in counts) before our adjustment and at the end.

Photodiode Power before [cts.] Power after [cts.]
CH24 - PD1 460 470
CH25 - PD2 500 507
CH26 - PD3 510 505
CH27 - PD4 560 563
CH28 - PD5 535 554
CH29 - PD6 460 520
CH30 - PD7 550 612
CH31 - PD8 530 564

Then, we measured again the coupling of beam motion to dP/P, and we got much improved numbers:

Photodiode dP/P/dx PITCH [1/m] dP/P/dx YAW [1/m]
CH24 - PD1 < 30 < 90
CH25 - PD2 130 430
CH26 - PD3 < 30 < 60
CH27 - PD4 40 180
CH28 - PD5 310 90
CH29 - PD6 60 100
CH30 - PD7 < 45 < 50
CH31 - PD8 < 50 < 50

At this level it is difficult to find a better position looking only at the power levels. We might have to optmize the centering looking directly at the beam motion coupling.

Comments related to this report
peter.king@LIGO.ORG - 07:11, Tuesday 30 September 2014 (14215)
CH24 - CH 27 = PD1 - PD4 upper row, left to right
CH28 - CH 31 = PD5 - PD8 lower row, left to right
H1 ISC
keita.kawabe@LIGO.ORG - posted 18:36, Monday 29 September 2014 - last comment - 15:44, Wednesday 01 October 2014(14209)
EY WFS RF whitening nonsense (again)

Summary:

Some whitening settings for EY green WFSA  I3, Q3 and WFSB Q2 channel don't work. It's probably the whitening chassis itself as the whitening request and the readback agree with each other.

For now I'm leaving both of the chassis in place as there are some usable settings, but note that these guys have a history of many troubles due to chassis and crappy cablings (1215912138, 12127).

Details 1:

For WFSA I3 and WFSB Q2, the measured whitening gain doesn't match the request and the readback (attached).

You can see that in both cases one of four stages (+3dB, +6dB, +12dB and +24dB) is failing. It's the 12dB gain stage for WFSA I3 and the 6dB stage for WFSB Q2.

These were measured injecting 20mVpp signal at 100Hz using a function generator and a breakout board.

Details 2:

For WFSA Q3, the third whitening filter doesn't turn on.

For now:

I set the gain to +27dB and turned all filters off.

Images attached to this report
Comments related to this report
keita.kawabe@LIGO.ORG - 08:36, Wednesday 01 October 2014 (14241)
It still might be the cable, so we'll check the cable using bio tester.
keita.kawabe@LIGO.ORG - 15:44, Wednesday 01 October 2014 (14255)

Update: It was crappy connector shell.

https://alog.ligo-wa.caltech.edu/aLOG/index.php?callRep=14243

H1 AOS (TCS)
alastair.heptonstall@LIGO.ORG - posted 17:12, Monday 29 September 2014 - last comment - 19:28, Monday 29 September 2014(14207)
TCS CO2 X-arm laser, short test

Alastair & Greg

Greg is running the TCS x-arm laser for a couple of hours (from 16:41 onwards) so we can start to get some data on stability at LHO.  The beam to the CP is blocked so there is no output, and the laser is being run with the table closed.

Comments related to this report
greg.grabeel@LIGO.ORG - 19:28, Monday 29 September 2014 (14213)TCS
Shut the laser off at 7:20pm. Rotation stage is non-functional right now, most likely due to the cable dressing that was done at the end of last week. Will try and restart the ethercat chassis during maintenance tomorrow.
H1 SUS
betsy.weaver@LIGO.ORG - posted 14:54, Monday 29 September 2014 - last comment - 09:15, Tuesday 30 September 2014(14202)
3IFO QUAD 06 Phase 1B testing

Now with added "damped" plots.  Note, the damping loops on the electronics test stand are hodge podge and so damping was poor for some regions of many loops.  As well, like I mentioned in earlier logs, the coherence of this in-air QUAD is poor at lower frequencies.  I spent some time trying to work out better excitation filtering/boosting but to no avail.  Damping works on both M0 and R0 chains of Q6.

Non-image files attached to this report
Comments related to this report
stuart.aston@LIGO.ORG - 09:15, Tuesday 30 September 2014 (14221)
Attached below is a comparison of undamped and damped Phase 1b QUAD06 TFs, which are also compared to QUADs of similar construction.

Summary:

As already noted above, damping loops are in no way optimised on this test-stand, however, damping on all DOFs on both chains of QUAD06 can be observed. The most egregious damping behaviour occurs on the R DOF of the reaction chain. It should be noted that, since the undamped TF for this DOF appears clear, this indicates that issue is most likely filter configuration related when attempting to engage damping loops. Thus alleviating any concerns.

All data, plots and scripts have been committed to the sus svn.
Non-image files attached to this comment
H1 ISC
alexan.staley@LIGO.ORG - posted 14:03, Monday 29 September 2014 - last comment - 17:14, Monday 29 September 2014(14201)
Green X-arm locking

This morning I adjusted the x-arm alignment to obtain green locking. First I misaligned ETMX, and adjusted TMSX using the ITMX baffle PDs. See table below for configuration:

 

Old Average (alog 13741)

Target PD1 Target PD4 new Average
TMSX (P,Y) (-23.8, -320.1) (-58.1, -292.7) (9.6, -354.9) (-24.25, -323.8)

NOTE: he baffle PDs read 2.4V at 0dB gain.

Then, using the ETMX camera I centered the beam on ETMX by adjusting the ITMX alignment. I found ITMX (P,Y) = (74.7, -8.2). Finally, I maximized the flashes by aligning ETMX. H1:ALS-X-TR_A_LF_OUT reached about 0.85 cnts. With this alignment we were able to lock the green beam to the arm. The alignments are saved to the guardian. 

Comments related to this report
alexan.staley@LIGO.ORG - 17:14, Monday 29 September 2014 (14208)

The dither alignment in yaw helped bring the counts up to about 1. The pitch dither made things worse.

H1 SEI (DetChar, PEM)
jeffrey.kissel@LIGO.ORG - posted 22:46, Monday 22 September 2014 - last comment - 09:46, Tuesday 30 September 2014(14086)
H1 GND STS Kerfuffle
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.
Comments related to this report
jeffrey.kissel@LIGO.ORG - 09:46, Tuesday 30 September 2014 (14223)CDS, DetChar
B. Abbott, J. Kissel

Sorry for the belated post on this: I got a reply from B. Abbott on this, that is detailed enough that it should be put here for future reference.

-------- Ben's reply ---------
Looking at D0901301,, page 11 some things can be seen:  
In answer to item (12), i.e.:
      ITMY     BS      ITMX  
     C4    A        B       C
     C5    B        C       A
     C6    C        A       B
This is actually necessary, and had been planned as such. Each of the corner-station STS2s (HAM2, ITMY, and HAM5) are actually read out by the BSC chamber racks, i.e. the ITMX, BS, and ITMY chamber racks. These are the analog "home" where the STS is read out. Because the "Home" BSC chamber for each STS wants to bring in both the XYZ channels, and the UVW channels, the XYZ channels must come in to the local AA chassis on channels 23, 24 and 25, respectively (starting at channel 00, of course).  That leaves the next STS-2 in the sequence to go into Ch26-28, and the next one to go into 29-31.  This may not be optimal for ease of model-making, but it is necessitated by the desire for all six signals (which necessitates a 15-pin DSub cable).

Looking at D1101576, Page 3, we see the HAM 2 (HAM3) mapping is: STS A on ADC0 (ADC2) Chs 24-27, STS B on ADC1 (ADC3) Chs 24-27, and STS C on ADC0 (ADC2) Chs 28-31.

In D1000298, page 4, we see the analogous wiring to HAMs 2&3: the HAM 4 (HAM5) mapping is: STS A on ADC0 (ADC2) Chs 24-27, STS B on ADC1 (ADC3) Chs 24-27, and STS C on ADC0 (ADC2) Chs 28-31.

Suggestions:
(a) I like the way that HAMs 1&6 are hooked up, and suggest that we move all of the cables to match that mapping, with STS A coming in on ADC0 (or ADC2) Chs 24-27, STS B on ADC1 (or ADC3) Chs 24-27 and STS C on ADC1 (or ADC3) Chs 28-31.  

(b) I don't see any way to change the BSC mapping in the corner by moving cables, unless we fundamentally change the kind of cable (make a 15-9 pin converter) and don't care about the UVW channels.

(c) I don't think there's much of any way to help out with the HEPI channels in hardware.  I think this is solely a simulink model thing.

---------- End Ben's reply

My thoughts on (a) and (c): I still have to do some research and talk with LLO on this. After conversing with Ryan DeRosa, he says "we have a functional system here!", so I want to make sure we don't re-invent the wheel and start another new convention before we write stuff down and change anything here at LHO.

Regarding (b), fair enough. I had just forgotten about the need. But we at least need to make sure its consistent everywhere!
Displaying reports 63401-63420 of 77237.Go to page Start 3167 3168 3169 3170 3171 3172 3173 3174 3175 End