40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 48 of 341  Not logged in ELOG logo
ID Date Author Typeup Category Subject
  3830   Sat Oct 30 14:35:43 2010 KojiSummaryCDSCDS time delay measurement

Unsatisfactory.

Neglecting the digital anti-imaging filter makes the discrepancy. You must take into account your digital filter twice.

I attached the slides I made during my visit for March LVC '09. P.5 would be useful.

Quote:

Result:
  [time delay of the CDS]  (left, middle)
    The time delay gets larger with frequency. The time delay seems to be -175 usec at DC.
    However, the gain seems a little different from my expectation(feCoeff4x). So, there are maybe other filters I don't know.
    I neglected TF of upsampling this time.

 

  3831   Sun Oct 31 00:19:35 2010 ranaSummaryComputer Scripts / ProgramsHP3563A netGPIB function

I've wheeled the old HP audio frequency signal analyzer into the control room to debug the GPIB/python interface. The wireless setup was getting more than 80% packet loss in the office area.

I also noticed that we have multiple and competing copies of the netgpib package installed. Kiwamu is going to merge them soon. Pleae only use the official location:

scripts/general/netgpibdata/

which is also the SVN working copy. Committ all changes periodicallty so that we can share the updated versions between sites.

  3838   Mon Nov 1 15:47:15 2010 yutaSummaryCDSCDS time delay measurement

Background:
  I measured CDS time delay last week, but because of my lack of understanding the system, it was incorrect.
  IOP has an anti-aliasing filter before downsampling from 64kHz(65536Hz) to 16kHz(16384Hz) and also has an anti-imaging filter before upsampling from 16kHz to 64kHz.
  So, I should have take feCoeff4x into account twice.
downupsampling.png

Result:
  TF agreed well with 2-time feCoeff4x and CDS time delay was -123.5 usec.
CDSdelay2.png


Plan:
 - make AWG(, diaggui TF measurement, tdssine) work
 - check input/output filter switching (using tdssine & tdsdmd)
 - measure openloop TF of MC suspension damping
 - divide it with my expectation and see if there are any filters I don't know

Quote:

Unsatisfactory.

Neglecting the digital anti-imaging filter makes the discrepancy. You must take into account your digital filter twice.

I attached the slides I made during my visit for March LVC '09. P.5 would be useful.

 

  3839   Mon Nov 1 16:43:24 2010 KojiSummaryCDSCDS time delay measurement

Um, Beautiful.

Actually, 123.5usec is almost exactly twice of 1/16384Hz.
Because of the loop, we have 1/16384Hz delay. I wonder where we do have the delay.

In order to understand the behaviour of the system can I ask you to test the following things?

1) What are the delay without IOPs with fsampl of 16k, 32k, 64k?

2) What are the delay with IOP with fsampl of 32k, 64k?

Quote:

Result:
  TF agreed well with 2-time feCoeff4x and CDS time delay was -123.5 usec.
CDSdelay2.png

 

  3841   Mon Nov 1 19:32:08 2010 yutaSummaryCDSfb crashed? during c1ioo and c1mcs connection at ASC

Frame builder died again!!

Background:
  We want to do angle to length measurement to optimize the beam position and increase visibility of MC locking.
  In order to do A2L measurement, we need excitation point, but AWG is currently not working.
  The better way is to use LOCKIN stuff like we had for OMC and put it to C1IOO WFS.
  A software oscillator in LOCKIN shakes the suspension, and demodulate the length signal.
  We can choose whatever DOF to shake, whatever signal to demodulate. It would be useful not just for A2L.

What I did:

  I started to put C1IOO WFS signal into C1SUS MC suspension RT model, but after compiling new c1mcs, fb crashed.
  Looks like daqd and mx_streams are running, but DAQ is not working(red).
  I don't know how to restart in a new way!

  3849   Wed Nov 3 02:23:11 2010 yutaSummaryCDSchecking whitening filter board

Summary:
  Last night, I found that some of the input channels have wrong hardware filter switching(see elog #3842).
  So, to check the whitening board(D000210), I swapped the one with ok switching and bad switching.
  During the checking, I somehow broke the board.
  I fixed it, and now the status is the same as last night (or, at least look like the same).

What I did:
  1. Switching for SRM_LRSEN looked bad and every input channel for MC3 looked OK.
     So, I unplugged the whitening board for SRM (1X5-1-5B) and plugged it into MC3's place(1X5-1-8B).

  2. Ran WDWchecker.py for MC3. The switching seemed OK for every input channel, which means the whitening board was not the wrong one.

  3. Swapped back the whitening board as it was.

  4. Found MC3_ULSEN_OUT and MC3_LLSEN_OUT was keep showing negative value(they should be positive).

  5. Check the board and found that one of LT1125 for UL/LL was wrong (broken virtual ground).

  6. Replaced LT1125 and put the board back to 1X5-1-8B.

  7. Checked the board with WDWchecker.py and dataviewer 5-hour minute trend.
      The input signal came back to normal value(Attachment #1), MC3 damping working, input filter switching seems working

before LT1125 replacement after LT1125 replacement
C1:SUS-MC3_ULSEN_IN1: -2.4 dB [!]
C1:SUS-MC3_URSEN_IN1: 16.9 dB
C1:SUS-MC3_LRSEN_IN1: 15.4 dB
C1:SUS-MC3_LLSEN_IN1: -1.1 dB [!]
C1:SUS-MC3_SDSEN_IN1: 18.4 dB
C1:SUS-MC3_ULSEN_IN1: 18.2 dB
C1:SUS-MC3_URSEN_IN1: 17.6 dB
C1:SUS-MC3_LRSEN_IN1: 16.6 dB
C1:SUS-MC3_LLSEN_IN1: 17.1 dB
C1:SUS-MC3_SDSEN_IN1: 16.2 dB


Result:
  The whitening board seems OK.
  The wrong one is either wiring or RT model. Or, the checking script.

  3850   Wed Nov 3 02:37:39 2010 yutaSummaryGreen Lockingcoarse locked green beat frequency

(Kiwamu, Yuta)

We succeeded in coarse locking the green beat frequency, using a frequency counter and feeding back the signal to the X-end laser temperature.

Setup:
  beat note -> RF PD -> SHP-25 -> SLP-100 -> ZFL-1000LN -> ZFL-1000LN -> ZFL-500LN -> ZFRSC-42 -> SBP-70 -> ZFRSC-42 -> SR620 -> c1psl(C1:PSL-126MOPA_126MON)
  c1auxey(C1:LSC-EX_GREENLASER_TEMP) -> X-end laser temp

  The frequency counter SR620 converts the beat frequency to voltage.
  We added some filters (SHP-25, SLP-100, SBP-70). Otherwise, SR620 doesn't count the frequency correctly.

What we did:

  1. Getting green beat note again
     Set PSL laser temp to 31.81 °C and X-end laser temp to 37.89 °C.
     Set PPKTP crystal temp to 37.6 °C, which maximizes output green beam power.

  2. ADC channel and DAC channel
     Disconnected one channel going into VME-3123 (at 1X1) and used c1psl's C1:PSL-126MOPA_126MON as ADC channel for the output from SR-620
     Made a new DAC channel on c1auxey named C1:LSC-EX_GREENLASER_TEMP, and disconnected one channel from VME-4116 (at 1X9) to use it as DAC channel for X-end laser temperature control.

  3. Coarse lock by ezcaservo
     Ran;
        ezcaservo C1:PSL-126MOPA_126MON -s 150 -g -0.0001 C1:LSC-EX_GREENLASER_TEMP
     "-s" option is a set value. The command locks C1:PSL-126MOPA_126MON to 150 (in counts), using 0Hz pole integrator.

Result:
  The beat frequency locked on to ~77MHz. The frequency fluctuation of the beat note during the servo is ~3MHz with ~10sec timescale.
  VCO has  ~+/-5MHz range, so this coarse locking meets the requirement.

  Here's a plot of the error signal and feed back signal;
  Screenshot_LowFreqLock.png

  3851   Wed Nov 3 03:00:47 2010 KojiSummaryGreen Lockingcoarse locked green beat frequency

Wow! Great guys!!

Can I expect to see the spectra of the frequency counter output with and without the servo?

RA: I think the SBP-70 is a bad idea. It limits the capture range. So does the SHP-25. You should instead just use a DC-block; the SR620 should work from 1-200 MHz with no problems.

Also, we have to figure out a better solution for the DAC at the ends: we cannot steal the QPD gain slider in the long run and the 4116 DAC at the ends has all 8 channels used up. Should we get the purple box for testing or should we try to use the fast DAC in the EX IO chassis as the actuator?

  3852   Wed Nov 3 09:32:00 2010 ranaSummaryCDSEurocard board swapping

When swapping Eurocard boards, it is safest to first turn down the power supplies and then do the swapping.

Otherwise, it is sometimes the case that people plug in the board slowly and/or asymmetrically. This can cause the opamp to see one of the power supply rails without the other (e.g. +15 but not -15).

This can destroy some opamps. The true danger is that there may be damage to the board which you do not notice for several months, thereby leaving a timebomb for the next person.

Don't be an electronics terrorist!

  3855   Wed Nov 3 17:01:01 2010 josephbSummaryCDSComparison of RFM read times

Problem:

RFM reads are slow.  Rolf has said it should take 2-3 microseconds per read. 

c1sus is taking about 7 microseconds per read, twice as slow as Rolf's claim.

Hypothesis:

The RFM card is in the IO chassis, and is sharing the PCIe bus with 4 ADC cards, 3 DAC cards, 4 BO cards, and a BIO card.  Its possible this crowded bus is causing the reads to take even longer.

Test Results:

Compare read times between the c1sus computer, which has its RFM card in the IO chassis, to c1ioo, which has its RFM card in the computer.

c1ioo:

No RFM reads: 8 microseconds

3 RFM reads: 20 microseconds (~4 per read)

6 RFM reads: 32 microseconds (~4 per read)

c1sus:

No RFM read: 25 microseconds (bigger model)

1 RFM read: 33 microseconds (~8 per read)

3 RFM read: 45 microseconds (~7 per read)

6 RFM read: Over 62 microseconds, doesn't run.

Conclusion:

It looks like moving the RFM card may help by about a factor of 2 in read speed, although its still not quite what Alex and Rolf claim it should be.

The c1mcs and c1ioo models have been reverted to their normal operations.

 

  3869   Fri Nov 5 15:20:18 2010 josephb, alexSummaryCDS40m computer slow down solved

Problem:

The 40m computers were responding sluggishly yesterday, to the point of being unusable.

Cause:

The mx_stream code running on c1iscex (the X end suspension control computer) went crazy for some reason.  It was constantly writing to a log file in /cvs/cds/rtcds/caltech/c1/target/fb/192.168.113.80.log.  In the past 24 hours this file had grown to approximately 1 Tb in size. The computer had been turned back on yesterday after having reconnected its IO chassis, which had been moved around last week for testing purposes - specifically plugging the c1ioo IO chassis in to it to confirm it had timing problems.

Current Status:

The mx_stream code was killed on c1iscex and the 1 Tb file removed.

Computers are now more usable.

We still need to investigate exactly what caused the code to start writing to the log file non-stop.

Update Edit:

Alex believes this was due to a missing entry in the /diskless/root/etc/hosts file on the fb machine.  It didn't list the IP and hostname for the c1iscex machine.  I have now added it.  c1iscex had been added to the /etc/dhcp/dhcpd.conf file on fb, which is why it was able to boot at all in the first place.  With the addition of the automatic start up of mx_streams in the past week by Alex, the code started, but without the correct ip address in the hosts file, it was getting confused about where it was running and constantly writing errors.

Future:

When adding a new FE machine, add its IP address and its hostname to the /diskless/root/etc/hosts file on the fb machine.

  3872   Fri Nov 5 21:49:12 2010 ranaSummaryCDS40m computer slow down solved

Quote:

Problem:

The 40m computers were responding sluggishly yesterday, to the point of being unusable.

Cause:

The mx_stream code running on c1iscex (the X end suspension control computer) went crazy for some reason.  It was constantly writing to a log file in /cvs/cds/rtcds/caltech/c1/target/fb/192.168.113.80.log.  In the past 24 hours this file had grown to approximatel

The moral of the story is, PUT THINGS IN THE ELOG. This wild process is one of those things where people say 'this won't effect anything', but in fact it wastes several hours of time.

  3875   Sat Nov 6 01:54:15 2010 FrankSummaryComputersvirus definition file update on laptop for dinocam

i took some pictures with the dinocam this afternoon. I used the laptop computer next to it using wireless lan connection to the caltech network to send the pictures to me.

The installed anti virus software was bitching about the old database and wanted to update that. As the installed virus definition database was from mid last year i agreed and started downloading the update. As the file was huge (~100MB) it wasn't finished when i left. computer is still running and probably waiting for instructions.

Will come back on the weekend to finalize the new virus definition file database installation.

  3876   Sat Nov 6 07:26:54 2010 yutaSummaryIOOreduced common mode displacement of the beam through MC1 to MC3

(Koji, Suresh, Yuta)

Summary:

  We need MC to be locked and aligned well to align other in-vac optics.
  By using a new python script A2L.py(see elog #3863), we are measuring A2L coupling and centering the beam.
  Tonight's goal was to reduce common mode displacement of the beam through MC1 to MC3, and we succeeded.

Strategy of beam centering:

  We first ignore the beam position at MC2 and focus on MC1,MC3. If MC1,MC3 alignments are given, MC2 alignment is determined.

  For MC1 and MC3, we first reduce the common mode displacement using the last steering mirror at PSL table.
  The last steering mirror makes translation of the incident beam because it is far (~m) from the MC.
  So,
    1. Rotate the steering mirror nob a little
    2. Lock MC so that MC beam axis will be the same as the incident beam axis
    3. A2L measurement
    4. To 1-3 over until the beam crosses MC1 center to MC3 center axis
        The amount of vertical/horizontal displacements of the beam spot at MC1 and MC3 should be the same.
        From our convention, for vertical, MC1 and MC3 should have opposite sign. For horizontal, same sign. (see picture below)

Result:
A2LMCalign.png
 
  From the A2L measurement, now the beam spot is lower right at MC1 and upper right at MC3.
 

  The directions of the beam spot motion agree with the steering mirror tilts.
  Also, the amount of the motion seems reasonable.
    1 tooth rotation of the steering mirror nob makes ~1e-3 inch push which equals to ~0.5mrad rotation.
    The steering mirror to MC is like ~2m and 0.5mrad mirror tilt makes ~2mm displacement at the MC optics.
    2mm displacement is ~15% at the mirror (see Koji's elog #2863;note that coil-coil distance is 1/sqrt(2) of the mirror diameter).
    The measured vertical spot motion is ~15%/1tooth. Horizontal is sqrt(2) times bigger because of the angle of the MC1, MC3 and they are about that much, too.

Plan:
 - Use IM1 to make beam tilt and finally center the beam
 - Improve the script so that it features weighting in fitting
 - Write a script that balances actuation efficiency of the 4 coils.
     We are currently assuming that 4 coils are well balanced.
     In order to do the balancing, we need to balance OSEMs too.

  3877   Sat Nov 6 16:13:14 2010 ranaSummaryCDS40m computer slow down solved

As part of the effort to debug what was happening with the slow computers, I disabled the auto MEDM snapshots process that Yoichi/Kakeru setup some long time ago:

https://nodus.ligo.caltech.edu:30889/medm/screenshot.html

We have to re-activate it now that the MEDM screen locations have been changed. To do this, we have to modify the crontab on nodus and also the scripts that the cron is calling. I would prefer to run this cron on some linux machine since nodus starts to crawl whenever we run ImageMagick stuff.

Also, we should remember to start moving the old target/ directories into the new area. All of the slow VME controls are still not in opt/rtcds/.

  3883   Tue Nov 9 05:40:12 2010 yutaSummaryIOOMC aligning going on

(Suresh, Yuta)

Background:
  Last week, we reduced the common mode displacement of the beam through MC1 to MC3. 
  Next work is to tilt the beam and center it.

What we did:
  1. Changed the offset going into 1201 Low Noise Amplifier(1201 is for adding +5V offset so that the feedback signal will be in the range of 0-10V)
  2. Using the last steering mirror(SM@PSL) and IM1, tilted the beam
  3. As the beam height changed alot(~0.5cm higher at IM1), MC1 reflection could not reach MCREFL PD. So, we tilted the mirror just after MC1, too.

Result:
MCalignNov9.png

Plan:

  - continue to tilt IM1 in small increments in order to reduce PIT/YAW to length coupling
      If large increments, it takes so much time re-aligning MC to get flashing!

By the way:

    The signal we kept saying "MCL" was not the error signal itself. It was a feed back signal(output of the mode cleaner servo board). The cable labeled "MC REFL" is the error signal. Compare MEDM screen C1IOO_MC_SERVO.adl and the mode cleaner servo board at 1X2. You will be enlightened.

Quote (from elog #3857):

4. Disconnected the cable labeled "MC OUT1" at 1X2 (which is MCL signal to ADC) and put MC2_ULCOIL output directly using long BNC cable.

 

  3884   Wed Nov 10 02:51:35 2010 yutaSummaryIOOlimitation of current MC aligning

(Suresh, Yuta)

Summary:
  We need MC to be locked and aligned well to align other in-vac optics.
  We continued to align the incident beam so that the beam passes the actuation nodes of MC1 and MC3.
  From the previous measurement, we found that beam height at IM1 has to be increased by ~3cm.
  Today, we increased it by ~1cm and achieved about 1/3 of the required correction.
  But we cannot proceed doing this because the beam is hitting IM1 at the edge already.

What is the goal of this alignment?:
  If the beam doesn't hit MC optics in the center, we see angle to length coupling, which is not good for the whole interferometer.
 
  Also, if the beam is tilted so much, transmitted beam though MC3 cannot go into FI at right after MC3.
  Say, FI has an aparture of 3mm and MC3-FT distance is 300mm. The beam tilt should be smaller than 3/300 rad. MC1-MC3 distance is 200mm, so the displacement at each mirror should be smaller than ~1mm.
  1mm is about 7% (see Koji's elog #2863) TO_COIL gain imbalance in A2L measurement.
 
  We are currently assuming that each coils are identical. If they have 5% variance, it is meaningless to try to reduce the beam displacement less than ~5%.

  So, we set the goal to 7%.

What we did:

  1. Leveled the MC table.

  2. Measured the table height using DISTO D3 laser gauge.
    PSL table 0.83m (+-0.01m)
    OMC table 0.82m
    MC table  0.81m

  3. Using the last steering mirror(SM@PSL) and IM1, tilted the beam vertically

Result:

MCalignNov9.png

  At t=0 (this morning), the beam tilt was ~40%/(MC1-MC3 distance). Now, it is ~30%/(MC1-MC3 distance).
  30%/(MC1-MC3 distance) is ~5/200 rad.

Plan:

 We have to somehow come up with the next story. Too much vertical tilt. What is wrong? Table leveling seems OK.
 - measure in-vac beam height
 - maybe OSEMs are badly aligned. we have to check that.

  3885   Wed Nov 10 11:46:19 2010 KojiSummaryIOOlimitation of current MC aligning

It didn't make sense in several points.

1. Is the Faraday aperture really 3mm? The beam has the gaussian radius of ~1.5mm. How can it be possible to go through the 3mm aperture?

2. Why the MC3-FT distance is the matter? We have the steering mirror after MC3. So we can hit the center of the Faraday.
But if we have VERTICAL TILT of the beam, we can not hit the center of the Faraday entrance and exit at the same time.
That would yield the requirement.

3. If each coil has 5% variance in the response, variance of the nodal point (measured in % of the coil imbalance) by those four coils will be somewhat better than 5%, isn't it?

  3886   Wed Nov 10 12:21:18 2010 yutaSummaryIOOlimitation of current MC aligning

1. We didn't measure the aperture size last night. We have to check that.

2. We have to measure the length of FI. Or find a document on this FI.

3. Yes, 5%/sqrt(4). But I didn't think the factor of 2 is important for this kind of estimation.

  3887   Wed Nov 10 14:28:33 2010 KojiSummaryIOOlimitation of current MC aligning

1. Look at the Faraday.

2. Look at the wiki. There is the optical layout in PNG and PDF.

3. 5% (0.8mm) and 2.5%(0.4mm) sounds a big difference for the difficulty, but if you say so, it is not so different.

Actualy, if you can get to the 5% level, it is easy to get to the 1-2% level as I did last time.
The problem is we are at the 15-20% level and can not improve it.

  3891   Thu Nov 11 04:32:53 2010 yutaSummaryCDSfound poor contact of DAC cable, previous A2L results were wrong

(Koji, Jenne, Yuta)

We found one of DAC cables had a poor contact.
That probably caused our too much "tilt" of the beam into MC.

Story:
  From the previous A2L measurement and MC aligning, we found that the beam is somehow vertically "tilted" so much.
  We started to check the table leveling and the beam height and they looked reasonable.
  So, we proceeded to check coil balancings using optical levers.
  During the setup of optical levers, I noticed that VMon for MC1_ULCOIL was always showing -0.004 even if I put excitation to coils.
  It was because one of the DAC cables(labeled CAB_1Y4_88) had a poor contact.
  If I push it really hard, it is ok. But maybe we'd better replace the cable.

What caused a poor connection?:
  I don't know.
  A month ago, we checked that they are connected, but things change.

How to prevent it:
  I made a python script that automatically checks if 4 coils are connected or not using C1:IOO_LOCKIN oscillator.
  It is /cvs/cds/caltech/users/yuta/scripts/coilchecker.py.
  It turns off all 3 coils except for the one looking at, and see the difference between oscillation is on and off.
  The difference can be seen by demodulating SUSPOS signal by oscillating frequency.
  If I intentionally unplug CAB_1Y4_88, the result output for MC1 will be;

==RESULTS== (GPS:973512733)
MC1_ULCOIL      0.923853382664 [!]
MC1_URCOIL      38.9361304794
MC1_LRCOIL      55.4927575177
MC1_LLCOIL      45.3428533919


Plan:
 - Make sure the cable connection and do A2L and MC alignment again
 - Even if the cables are ok, it is better to do coil balancings. See the next elog.

  3892   Thu Nov 11 05:56:04 2010 yutaSummaryIOOsetting up temporary oplev for coil balancing of MCs

(Suresh, Yuta)

Background:
  Previous A2L measurement is based on the assumption that actuator efficiencies are identical for all 4 coils.
  We thought that the unbelievable "tilt" may be caused by imbalance of the coils.

Method:
  1. Setup an optical lever.
  2. Dither the optic by one coil and demodulate oplev outputs(OL_PIT or OL_YAW) in that frequency.
  3. Compare the demodulated amplitude. Ideally, the amplitude is proportional to the coil actuation efficiency.

What we did:
[MC2]
  MC2 is the least important, but the easiest.
  1. Placed a red laser pointer at MC2 trans table. During the installation, I moved the mirror just before QPD.
  2. Made a python script that measures coil actuation efficiency using the above method. I set the driving frequency to 20Hz.
  It is /cvs/cds/caltech/users/yuta/scripts/actuatorefficiency.py.
  The measurement result is as follows. Errors are estimated from the repeated measurement. (Attachment #1)

MC2_ULCOIL 1
MC2_URCOIL 0.953 ± 0.005
MC2_LRCOIL 1.011 ± 0.001
MC2_LLCOIL 0.939 ± 0.006


[MC1]
  For MC1, we can use the main laser and WFS1 QPD as an oplev.
  But we only have slow channels for QPD DC outputs(C1:IOO_WFS1_SEG#_DC).
  So, we intentionally induce RF AM by EOM(see Kiwamu's elog #3888) and use demodulated RF outputs of the WFS1 QPD(C1:IOO_WFS1_I/Q#) to see the displacement.
  1. Replaced HR mirror in the MCREFL path at AP table to BS so that we can use WFS1.(see Koji's elog #3878)
    The one we had before was labeled 10% pick-off, but it was actually an 1% pick-off.
  2. Checked LO going into WFS1 demodulator board(D980233 at 1X2).
    power: 6.4dBm, freq: 29.485MHz
  3. Turned on the hi-voltage(+100V) power supply going into the demodulator boards.
  4. Noticed that no signal is coming into c1ioo fast channels.
    It was because they were not connected to fast ADC board. We have to make a cable and put it in.

[MC3]
  Is there any place to place an oplev?

Plan:
 - prepare c1ioo channels and connections
 - I think we'd better start A2L again than do oplev and coil balancing.

  3895   Thu Nov 11 11:51:30 2010 KojiSummaryCDSfound poor contact of DAC cable, previous A2L results were wrong

The cause is apparent! The connectors on the cables are wrong!
Currently only 50% of the pin length goes into the connector!

Quote:

(Koji, Jenne, Yuta)

We found one of DAC cables had a poor contact.
That probably caused our too much "tilt" of the beam into MC.

  It was because one of the DAC cables(labeled CAB_1Y4_88) had a poor contact.
  If I push it really hard, it is ok. But maybe we'd better replace the cable.

What caused a poor connection?:
  I don't know.
  A month ago, we checked that they are connected, but things change.

 

  3901   Thu Nov 11 23:35:23 2010 KojiSummaryCDSfound poor contact of DAC cable, previous A2L results were wrong

[Koji / Yuta]

There were the guys who used the PENTEK 40pin connectors into the IDC 40pin connectors.
Those connectors are not compatible at all.

==> We replaced the connectors on the cables from DAC to IDC adapters to the dewhitening board for the vertex SUSs.

In addition, I found one of the Binary OUT IDC50pin connector has no clamp.

==> We put the IDC50pin clamp on it.

bad-boys.png

PENTEK connectors were inserted. The latches are not working!

IMG_3698.jpg

the vertical pitch is different between PENTEK and IDC!
IMG_3705.jpg

Wow! Where is the clamp???

IMG_3706.jpg

Quote:

The cause is apparent! The connectors on the cables are wrong!
Currently only 50% of the pin length goes into the connector!

Quote:

(Koji, Jenne, Yuta)

We found one of DAC cables had a poor contact.
That probably caused our too much "tilt" of the beam into MC.

  It was because one of the DAC cables(labeled CAB_1Y4_88) had a poor contact.
  If I push it really hard, it is ok. But maybe we'd better replace the cable.

What caused a poor connection?:
  I don't know.
  A month ago, we checked that they are connected, but things change.

 

 

  3924   Mon Nov 15 15:02:00 2010 KojiSummaryPSLpower measurements around the PMC

[Valera Yuta Kiwamu Koji]

Kiwamu burtrestored c1psl. We measured the power levels around the PMC.

With 2.1A current at the NPRO:

Pincident = 1.56W
Ptrans_main = 1.27W
Ptrans_green_path = .104W

==> Efficiency =88%

----

We limited  the MC incident power to ~50mW. This corresponds to the PMC trans of 0.65V.
(The PMC trans is 1.88V at the full power with the actual power of 132mW)

  3941   Wed Nov 17 20:44:59 2010 yutaSummaryCDSno QPD channels on c1sus machine today

(Joe, Suresh, Yuta)

Currently, only 2 ADC cards work on c1sus machine.
No QPD inputs(e.g. MC2 trans), and no RFM.


Summary:
  We wanted to have PEM(physical environment montor) channels, so we moved a ADC card in c1sus machine.
  It ended up with destroying one of the 3 ADCs.

What we did:
  1. Moved ADC card at PCIe expansion board slot 0 to other empty slot.
     What we call PCI slot 0 was "DO NOT USE" in LIGO-T10005230-v1, so we moved it.

  2. Connected that ADC card to PEM channel box at 1X7 via SCSI cable.

  3. ADC card order is changed, so we checked ADC number assinging and re-labeled the cable.

  4. Found RFM is not working(c1sus and c1ioo not talking) and fb is in a weird state(Status: 0x4000 in GDS screens)

  5. Swapped the cabling so that ADC card 0 will be connected to timing interface card at slot1, but didn't help.
     More than that, we suffered ADC timeout.

  6. Tried ADC card swapping, slot position changing, taking out some of the ADC cards, etc.
     We found that ADC timeout doesn't happen with 2 ADC cards.
     But if we connect one of the ADC card to the timing interface card at slot 8, c1sus ADC timeouts with 2 ADC cards, too.
     So, I think that timing interface card is bad.

  7. Stopped rebooting c1sus again and again. We decided to investigate the problem tomorrow.
     We only need ADC card 0 and 1 for MC damping.(see this wiki page)
       ADC card 0: all UL/UR/LR/LL SENs
       ADC card 1: all SD SENs     
       ADC card 2: all QPDs

Result:
  We can damp optics and lock MC.
  We can't do A2L because RFM is not working.
  We can't see MC2 trans because we currently don't have ADC card 2.

  3948   Thu Nov 18 16:32:21 2010 yutaSummaryCDScurrent damping status for all optics c1sus handles

Summary:
   I set Q-values for each ringdown of PRM, BS, ITMX, ITMY, MC1, MC2, MC3 to ~5 using QAdjuster.py.
   Here are the results;
c1susdampings.png

  Red ringdowns indicate the second try after gain setting.

Note:

  - ITMX and ITMY are referred according to MEDM screens in this entry.
  - ITMX(south) OSEM positions are currently so bad(LL and SD are all the way in/out).
        I have to change IFO_ALIGN slider values to check the damping servo. For SIDE, I couldn't do that. I reverted the slider change after the damping checking.
  - ITMY(west) somehow has opposite coil gain sign.
       Usually for the other optics, UL,UR,LR,LL is 1,-1,1,-1. But for ITMY to damp, they are -1,1,-1,1.
  - PRM damps, but ringdown doesn't look nice. There must be something funny going on.
  - SRM doesn't have OSEMs put in now.

  3950   Thu Nov 18 17:42:20 2010 Joonho LeeSummaryElectronicsCCD cables.

I finished the direct measurement of cable impedances.

Moreover, I wrote the cable replacement plan.

The reason I am checking the cables is for replacing the cables with impedance of 50 or 52 ohm by those with impedance of 75 ohm.

After I figures out which cable has not proper impedance, I will make new cables and substitute them in order to match the impedance, which would lead to better VIDEO signal.

Moreover, as Koji suggested, the VIDEO system will be upgraded for better interface.

 

I measured the cable impedance by checking the reflection ratio at the point connected to the terminator with 50 ohm or 75 ohm.

The orange colored cables are measured to be 75ohm so we do not need to replace them.

Combining the list of cable types and the list of desired length,

I need to make total 37 cables and to remove 10 cables from the current connection.

Detailed plan is attached below.

I currently ordered additional cables and BNC plugs.

 

From now on, I will keep making CCD cables for VIDEO upgrade.

Then, with your helps, we will replace the CCD cables.

 

In my opinion, I will finish VIDEO upgrade by this year.

  3961   Sat Nov 20 03:37:11 2010 yutaSummaryCDSCDS time delay measurement - the ripple

(Koji, Joe, Yuta)

Motivation:
  We wanted to know more about CDS.

Setup:
  Same as in elog #3829.

What we did:

  1. Made test RT models c1tst and c1nio for c1iscex.
     c1tst has only 2 filter module(minimum limit of a model), 2 inputs, 2 outputs and it runs with IOP c1x01.
     c1nio is the same as c1tst except it runs(or, should run) without IOP.

  2. Measured the time delay of ADC through DAC using different machine, different sampling rate by measuring transfer functions.

  3. c1nio(without IOP) didn't seem to be running correctly and we couldn't measure the TF.
     "1 PPS" error appeared in GDS screen(C1:FEC-39_TIME_ERR).
     It looks like c1nio is receiving the signal as we could see in the MEDM screen, but the signal doesn't come out from the DAC.

TF we expected:
  All the filters and gains are set to 1.

  We have DA's TF when putting 64K signal out to analog world.
    D(f)=exp(-i*pi*f*Ts)*sin(pi*f*Ts)/(pi*f*Ts)  (Ts: sample time)

  We have AA filter and AI filter when downsampling and upsampling.
    A(f)=G*(1+b11/z+b12/z/z)/(1+a11/z+a12/z/z)*(1+b21/z+b22/z/z)/(1+a21/z+a22/z/z)       z=exp(i*2*pi*f*Ts)
  Coefficients can be found in /cvs/cds/rtcds/caltech/c1/core/advLigoRTS/src/fe/controller.c.

/* Coeffs for the 2x downsampling (32K system) filter */
static double feCoeff2x[9] =
        {0.053628649721183,
        -1.25687596603711,    0.57946661417301,    0.00000415782507,    1.00000000000000,
        -0.79382359542546,    0.88797791037820,    1.29081406322442,    1.00000000000000};
/* Coeffs for the 4x downsampling (16K system) filter */
static double feCoeff4x[9] =
    {0.014805052402446, 
    -1.71662585474518,    0.78495484219691,   -1.41346289716898,   0.99893884152400,
    -1.68385964238855,    0.93734519457266,    0.00000127375260,   0.99819981588176};


  For 64K system, we expect H=1.

  We also have a delay.
    S(f)=exp(-i*2*pi*f*dt)   (dt: delay time)

  So, total TF we expect is;
    H(f)=a*A(f)^2*D(f)*S(f)
  a is a constant depending on the range of ADC and DAC(I think). Currently, a=1/4.

  We may need to think about TF when upsampling.(D(f) is TF of upsampling 64K to analog)

Result:

  Example plot is attached.
  For other plots and the raw data, see /cvs/cds/caltech/users/yuta/scripts/CDSdelay2/ directory.
  As you can see, TFs are slightly different from what we expect.
  They show ripple we don't understand at near cut off frequency.

  If we ignore the ripple, here is the result of delay time at each condition;

data file    host    FE    IOP        rate    sample time    delay        delay/Ts
c1rms16K.dat    c1sus      c1rms    adcSlave    16K    61.0usec    110.4usec    1.8
c1scx16K.dat    c1iscex    c1scx    adcSlave    16K    61.0usec     85.5usec    1.4
c1tst16K.dat    c1iscex    c1tst    adcSlave    16K    61.0usec     84.3usec    1.4
c1tst32K.dat    c1iscex    c1tst    adcSlave    32K    30.5usec     53.7usec    1.8
c1tst64K.dat    c1iscex    c1tst    adcSlave    64K    15.3usec     38.4usec    2.5

  The delay time shown above does not include the delay of DA. To include, add 7.6usec(Ts/2).

  - delay time is different for different machine
  - number of filters (c1scx has full of filters for ETMX suspension, c1tst has only 2) doen't seem to effect much to delay time
  - higher the sampling rate, larger the (delay time)/(sample time) ratio

Plan:

 - figure out how to run a model without IOP
 - where do the ripples come from?
 - why we didn't see significant ripple at previous measurement on c1sus?

  3963   Mon Nov 22 13:16:52 2010 josephbSummaryCDSCDS Plan for the week

CDS Objectives for the Week:

Monday/Tuesday:

1) Investigate ETMX SD sensor problems

2) Fully check out the ETMX suspension and get that to a "green" state.

3) Look into cleaning up target directories (merge old target directory into the current target directory) and update all the slow machines for the new code location.

4) Clean up GDS apps directory (create link to opt/apps on all front end machines).

5) Get Rana his SENSOR, PERROR, etc channels.

Tuesday/Wednesday:

3) Install LSC IO chassis and necessary cabling/fibers.

4) Get LSC computer talking to its remote IO chassis

Wednesday:

5) If time, connect and start debugging Dolphin connection between LSC and SUS machines

 

  3976   Tue Nov 23 11:32:03 2010 JoonhoSummaryElectronicsRF distribution unit.

The last time(Friday) I made an arrangement for RF distribution unit.

I am making RF distribution unit for RF upgrade which is designed by Alberto.

 

To reduce a noise from loose connection,

I tried to make the number of hard connect as much as possible while reducing the number of connection via wire.

This is why I put splitters right next to the front pannel so that the connection between pannel plugs and splitters could be made of hard joints.

I attached the arrangement that I made on the last Friday.

 

Next time, I will drill the teflon(the supporting plate) for assembly.

Any suggestion would be really appreciated.

  3982   Tue Nov 23 23:13:40 2010 kiwamuSummaryCDSplan: we will install C1LSC

 [Joe, Suresh, Kiwamu]

 We will fully install and run the new C1LSC front end machine tomorrow.

And finally it is going to take care of the IOO PZT mirrors as well as LSC codes. 

 


 (background stroy)

 During the in-vac work today, we tried to energize and adjust the PZT mirrors to their midpoints.

However it turned out that C1ASC, which controls the voltage applying on the PZT mirrors, were not running.

We tried rebooting C1ASC by keying the crate but it didn't come back.

 The error message we got in telnet  was :

   memory init failure !!

 

 We discussed how to control the PZT mirrors from point of view of both short term and long term operation.

We decided to quit using C1ASC and use new C1LSC instead.

A good thing of this action is that, this work will bring the CDS closer to the final configuration. 

 

(things to do)

 - move C1LSC to the proper rack (1X4).

 - pull out the stuff associated with C1ASC from the 1Y3 rack.

 - install an IO chasis to the 1Y3 rack.

- string a fiber from C1LSC to the IO chasis.

- timing cable (?)

- configure C1LSC for Gentoo

- run a simple model to check the health

- build a model for controlling the PZT mirrors

  3996   Tue Nov 30 12:33:27 2010 kiwamuSummaryIOOcabling of in-vac PZT mirrors

  4010   Fri Dec 3 15:56:50 2010 Joonho, Jenne.SummaryElectronicsRF distribution unit plan

The last time(Moonday) Jenne and I worked on the RF distribution unit's structure.

We are making RF distribution unit for RF upgrade which is designed by Alberto.

 

Rana, Koji, Jenne suggested a better design for RF Distribution unit.

So Jenne and I gathered information of parts and decided what parts will be used with specific numbers.

Specific circuit is shown in the attached picture.

 

Any suggestion would be really appreciated.

  4011   Sun Dec 5 22:28:39 2010 ranaSummaryall down cond.power outage

Looks like there was a power outage. The control room workstations were all off (except for op440m). Rosalba and the projector's computer came back, but rossa and allegra are not lighting up their monitors.

linux1 and nodus and fb all appear to be on and answering their pings.

I'm going to leave it like this for the morning crew. If it

  4012   Mon Dec 6 11:53:20 2010 josephb, kiwamuSummaryall down cond.power outage

The monitors for allegra and rossa's seemed to be in a weird state after the power outage.  I turned allegra and rossa on, but didn't see anything.  However, I was after awhile able to ssh in.  Power cycling the monitors did apparently got them talking with the computers again and displaying.

I had to power cycle the c1sus and c1iscex machines (they probably booted faster than linux1 and the fb machines, and thus didn't see their root and /cvs/cds directories).  All the front ends seem to be working normally and we have damped optics.

The slow crates look to be working, such as c1psl, c1iool0, c1auxex and so forth.

Kiwamu turned the main laser back on.

Quote:

Looks like there was a power outage.

 

  4013   Mon Dec 6 11:57:21 2010 KojiSummaryall down cond.power outage

I checked the vacuum system and judged there is no apparent issue.

The chambers and annulus had been vented before the power failure.
So the matters are only on the TMPs.

TP1 showed the "Low Input Voltage" failure. I reset the error and the turbine was lift up and left not rotating.
TP2 and TP3 seem rotating at 50KRPM and the each lines show low pressur (~1e-7)
although I did not find the actual TP2/TP3 themselves.

Quote:

Looks like there was a power outage. The control room workstations were all off (except for op440m). Rosalba and the projector's computer came back, but rossa and allegra are not lighting up their monitors.

linux1 and nodus and fb all appear to be on and answering their pings.

I'm going to leave it like this for the morning crew. If it

 

  4049   Mon Dec 13 22:21:41 2010 kiwamuSummarySUSfunny output matrix of ETMX: solved !

I found that a few connections in the simulink model of c1scx was incorrect, so I fixed them correctly.

It had been a mystery why we had to put a funny matrix on ETMX (see this entry).

But now we don't have to do such a voodoo magic because the problem was solved.

Now the damping of ETMX is happily running with an ordinary output matrix.


 --(details)

 I looked at the wiring diagram of the ETMX suspension (it's on Ben's web page) and confirmed that the coils are arranged in order of UL, LL, UR, LR.

But then I realized that in our simulink model they had been arranged in order of UL, UR, LL, LR.

So UR and LL had been swapped incorrectly !

So I just disconnected and plugged them into the right outputs in the simulink model.

   I rebooted c1iscex in order to reactivate c1scx front end code.

After rebooting it, I changed the output matrix to the usual one, then everything looked okay.

(actually it's been okay because of the combination of the wrong connections and the funny matrix).

  4056   Wed Dec 15 12:46:18 2010 KojiSummaryIOOFinishing up the vac work

What else?

v: Edit on Dec 15 10PM
v: Edit on Dec 16 10PM

JD:  We should check OSEMs for all optics *after* table leveling.  Some of them (esp. BS and ITMX) are currently close to their limits right now.

KA: Check green alignment.

Take photos of the tables.

Fix the leveling weights



Location    Optics            Action
--------------------------------------------------------------
@ITMX -     v POX             alignment
            v POP1/POP2       alignment
            v Table Leveling

@ITMY -     POY               mirror replacement (45deg->0deg) / alignment
            v SR2-TT          alignment
            v SRM Tower       alignment / EQ-stop release
            v SRM             alignment
            v SRM OSEM
            vvSRM OPLEV (X2)  install (VIS)/ alignment
            v ITMY OPLEV (X2)   install (VIS)/ alignment
            v OM1/OM2         install (DLC 45deg)/ alignment       
            v Table Leveling

@BSC -      v OM3             install (DLC 45deg/ alignment)
            v OM4(PZT)          neutralize, adjustment
            IPPOS steering    alignment
            v BS OPLEV        alignment
           
v PRM OPLEV(x2)     alignment
            Beam dumps
            Table Leveling

@IMC -      v REFL              mirror replacement (45deg->0deg)

@ETMX -     Al foil removal
            Table Leveling

@ETMY -     ETMY damping
            OSEM
            OPLEV
            Al foil removal
            Table Leveling

@OMC -      v OM5(PZT)        neutralize, adjustment

@ITM/ETM -  Mirror Wiping

  4084   Tue Dec 21 16:34:42 2010 kiwamuSummaryVACAll the test masses have been wiped

 [Jenne and Kiwamu]

 We wiped all the test masses with isopropyl alcohol.

They became apparently much cleaner.

(how to)

 At first we prepared the following stuff:

  * syringe

  * isopropyl alcohol 

  * lens papers

  * cleaned scissors

  Then we cut the lens papers into the half by the scissors such that the long side can remain.

This is because that the SOSs have relatively narrow spaces at their optic surfaces for putting a piece of paper. 

   We did vertical and horizontal wiping using the lens paper and appropriate amount of isopropyl alcohol.

Each wiping (vertical and horizontal) requires two or three times trials to appropriately remove dusts.

Amount of isopropyl:

   * vertical 15 [ul]

   * horizontal 10 [ul]

In addition to this, we also used the ionizer gun for blowing big dusts and fiber away from the surface.

 

 

(surface inspection)

   Before wiping them, all the test masses had small dusts uniformly distributed on the HR surfaces.

Especially ETMX was quite dirty, many small spots (dusts) were found when we shined the surface with the fiber illuminator.

ETMY was not so bad, only a couple of small dusts were at around the center.  ITMX/Y had several dusts, they were not as dirty as ETMX, but not cleaner than ETMY.

   After we wiped them,  we confirmed no obvious dusts were around the centers of the optics. They looked pretty good !

 

 

  4098   Wed Dec 29 18:53:11 2010 ranaSummaryelogfound hung - restarted

This was the error today:

GET /40m/ HTTP/1.1
Host: nodus.ligo.caltech.edu:8080
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://www.ligo.caltech.edu/~ajw/40m_upgrade.html
Cookie: elmode=threaded; __utma=65601905.411937803.1291369887.1291369887.1291369887.1; __utmz=65601905.1291369887.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); SITESERVER=ID=4981c5fd42ae53c9c9e0980f2072be4f

  4102   Mon Jan 3 10:32:27 2011 kiwamuSummaryelogfound hung - restarted

Found exactly the same error messages at the end of the log file.

Quote: #4098

This was the error today:

GET /40m/ HTTP/1.1
Host: nodus.ligo.caltech.edu:8080
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://www.ligo.caltech.edu/~ajw/40m_upgrade.html
Cookie: elmode=threaded; __utma=65601905.411937803.1291369887.1291369887.1291369887.1; __utmz=65601905.1291369887.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); SITESERVER=ID=4981c5fd42ae53c9c9e0980f2072be4f

 

  4109   Wed Jan 5 00:23:30 2011 ranaSummaryDAQFrameBuilder fails in a new way

Since Leo was trying to demo his LIGO Data Listener code, he noticed that there was and NDS2 issue. The NDS2 guy (JZ) noticed that the FrameBuilder had an issue.

We investigated. At 4PM on Dec 31, the GPS timestamp of the frame file names started to be recorded wrong. In fact, it started to give it a file name matching the correct time from 1 year in the past.

So that's our version of the Y2011 bug. Here's the 'ls' of /frames/full:

drwxr-xr-x 2 controls controls 252K Dec 26 03:59 9773
drwxr-xr-x 2 controls controls 260K Dec 27 07:46 9774
drwxr-xr-x 2 controls controls 256K Dec 28 11:33 9775
drwxr-xr-x 2 controls controls 252K Dec 29 15:19 9776
drwxr-xr-x 2 controls controls 244K Dec 30 19:06 9777
drwxr-xr-x 2 controls controls 188K Dec 31 16:00 9778
drwxr-xr-x 2 controls controls 148K Jan  1 08:53 9463
drwxr-xr-x 2 controls controls 260K Jan  2 12:39 9464
drwxr-xr-x 2 controls controls 252K Jan  3 16:26 9465
drwxr-xr-x 2 controls controls 248K Jan  4 20:13 9466
drwxr-xr-x 2 controls controls  36K Jan  5 00:22 9467
controls@fb /frames/full $

The culprit is the directory who's name starts out as 9463 whereas it should be 9779.

 

  4112   Wed Jan 5 16:00:11 2011 rana, alexSummaryDAQFrameBuilder fails in a new way

Email from Alex:

Turned out to be the lack of current year information in the IRIG-B signal
received by the Symmetricom GPS card in the frame builder machine caused
this. I have added a constant in daqdrc to bring the seconds forward:

controls@fb /opt/rtcds/caltech/c1/target/
fb $ grep symm daqdrc
#set symm_gps_offset=-1;
set symm_gps_offset=31536001;

Hopefully we will be upgrading to the newer timing system at the 40M this
year, so this will not happen again next year.


 

Doing an 'ls -lrt' in /frames/full/ now shows that the names are correct:

drwxr-xr-x 2 controls controls 249856 Dec 30 19:06 9777
drwxr-xr-x 2 controls controls 192512 Dec 31 16:00 9778
drwxr-xr-x 2 controls controls 151552 Jan  1 08:53 9463
drwxr-xr-x 2 controls controls 266240 Jan  2 12:39 9464
drwxr-xr-x 2 controls controls 258048 Jan  3 16:26 9465
drwxr-xr-x 2 controls controls 253952 Jan  4 20:13 9466
drwxr-xr-x 2 controls controls 151552 Jan  5 13:54 9467
drwxr-xr-x 2 controls controls  12288 Jan  5 15:57 9783

  4113   Wed Jan 5 16:11:17 2011 kiwamuSummaryIOOtemporary PZT connection

PZTconnection.png

This is a connection diagram for the input PZTs (i.e. PZT1 and PZT2).

As drawn in the diagram, the signals don't go through the anti-imaging filter D000186 in the current configuration.

  4115   Wed Jan 5 22:14:41 2011 ranaSummaryDAQFrameBuilder fails in a new way

Just a proof that the DAQ is working - ran DTT on nodus from 3 hours ago.

  4132   Tue Jan 11 11:19:13 2011 josephbSummaryCDSStoring FE harddrives down Y arm

Lacking a better place, I've chosen the cabinet down the Y arm which had ethernet cables and various VME cards as a location to store some spare CDS computer equipment, such as harddrives.  I've added (or will add in 5 minutes) a label "FE COMPUTER HARD DRIVES" to this cabinet.

  4139   Tue Jan 11 21:08:19 2011 JoonhoSummaryCamerasCCD cables upgrade plan.

Today I have made the CCD Cable Upgrade Plan for improvement of sysmtem.

I have ~60 VIDEO cables to be worked for upgrades so I would like to ask all of your favor in helping me of replacing cables.

 

1. Background

Currently, VIDEO system is not working as we desire.

About 20 cables are of impedance of 50 or 52 ohm which is not matched with the whole VIDEO system.

Moreover, some cameras and monitors are out of connection.

 

2. What I have worked so far.

I have checked impedance of all cables so I figured out which cables can be used or should be replaced.

I measured cables' pathes along the side tray so that we can share which cable is installed along which path.

I have made almost of cables necessary for VIDEO system upgrades but no label is attached so far.

 

3. Upgrade plan (More details are shown in attached file)

 

0 : Cable for output ch#2 and input ch#16 is not available for now
1 : First, we need to work on the existing cables. 
1A : Check the label on the both ends and replace to the new label if necessary
1B : We need to move the existing cable's channel only for those currently connected to In #26 (from #26 to #25)
2 : Second, we need to implement new cables into the system
2A : Make two cable's label and attach those on the both ends
2B : Disconnect existing cables at the channel assigned for new cables and remove the cables from the tray also
2C : Move 4 quads into the cabinet containing VIDEO MUX
2D : Implement the new cable into the system along the path described and connect the cables to the assgined channel and camera or monitor

 

 

4. This is a kind of  a first draft of the plan.

Any comment for the better plan is always welcome.

Moreover, replacing all the cables indicated in the files is of great amount of work.

I would like to ask all of your favors in helping me to replace the cables (from 1. to 2D. steps above).

 

  4180   Thu Jan 20 22:17:12 2011 ranaSummaryLSCFPMI Displacement Noise

I found this old plot in an old elog entry of Osamu's (original link).

It gives us the differential displacement noise of the arms. This was made several months after we discovered how the STACIS made the low frequency noise bad, so I believe it is useful to use this to estimate the displacement noise of the arm cavity today. There are no significant seismic changes. The change of the suspension and the damping electronics may produce some changes around 1 Hz, but these will be dwarfed by the non-stationarity of the seismic noise.

  4213   Thu Jan 27 17:12:02 2011 Aidan, JoeSummaryGreen LockingDigital Frequency to Amplitude converter

Joe and I built a very simple digital frequency to amplitude converter using the RCG. The input from an ADC channel goes through a filter bank (INPUT), is rectified and then split in two. One path is delayed by one DAQ cycle (1/16384 s) and then the two paths are multiplied together. Then the output from the mixer goes through a second filter bank (LP) where we can strip off twice the beat frequency. The DC output from the LP filter bank should be proportional to the input frequency.

Input Channel: C1:GFD-INPUT_xxx

Output Channel: C1:GFD-LP_xxx

Joe compiled the code and we tested it by injecting a swept sine [100, 500]Hz in the input filter bank. We confirmed that output of the LP filter bank changed linearly as a function of the input frequency.

The next thing we need to do is add a DAC output. Once that's in place we should inject the output from a 4kHz VCO into the ADC. Then we can measure the transfer function of the loop with an SR785 (driving the VCO input and looking at the output of the DAC) and play around with the LP filter to make sure the loop is fast enough.

The model is to be found here:

/opt/rtcds/caltech/c1/core/advLigoRTS/src/epics/simLink/c1gfd.mdl

The attached figures show the model file in Simulink and a realtime dataviewer session with injecting a swept sine (from 500Hz to 100Hz) into the INPUT EXC channel. We've had some frame builder issues so the excitation was not showing on the green trace and, for some reason, the names of the channels are back to front in dataviewer (WTF?), - the lower red trace in dataviewer is actually displaying C1:GFD-LP_OUT_DAQ, but it says it is displaying C1:GFD-INPUT_OUT_DAQ - which is very screwy.

However, the basic principle (frequency to amplitude) seems to work.

ELOG V3.1.3-