Can't we somehow hook up this camera to the MUX with the movie mode?
I think both the MUX and the sensoray are compatible with the color video signal.
Only the old CRT is B/W.

 The auxey machine is back, in that I can interact with the IFO_ALIGN sliders, and they actually make the optic move, but I still can't read and write to and from the EPICs channels:

controls@rossa:/opt/rtcds/caltech/c1/medm/MISC/ifoalign/burt 0$ cdsutils read C1:SUS-ETMY_PIT_COMM
CA.Client.Exception...............................................
    Warning: "Virtual circuit disconnect"
    Context: "c1auxey.martian:5064"
    Source File: ../cac.cpp line 1214
    Current Time: Mon Nov 18 2013 21:13:52.044973819
..................................................................
Could not connect to channel (timeout=2s): C1:SUS-ETMY_PIT_COMM
controls@rossa:/opt/rtcds/caltech/c1/medm/MISC/ifoalign/burt 1$ cdsutils read C1:SUS-ETMY_YAW_COMM
CA.Client.Exception...............................................
    Warning: "Virtual circuit disconnect"
    Context: "c1auxey.martian:5064"
    Source File: ../cac.cpp line 1214
    Current Time: Mon Nov 18 2013 21:14:07.040168660
..................................................................
Could not connect to channel (timeout=2s): C1:SUS-ETMY_YAW_COMM
controls@rossa:/opt/rtcds/caltech/c1/medm/MISC/ifoalign/burt 1$

This is also causing trouble for the BURT save and BURT restore scripts, that are called from the IFO_ALIGN screen.  If I look at the log that is written from an attempted 'save' of the slider values, I see:

**** READ BURT LOGFILE

--- Start processing files
file >/opt/rtcds/caltech/c1/medm/MISC/ifoalign/burt/ETMY.req<
preprocessing ... done
pv >C1:SUS-ETMY_PIT_COMM< nreq=-1
pv >C1:SUS-ETMY_YAW_COMM< nreq=-1
--- End processing files

--- Start searches
C1:SUS-ETMY_PIT_COMM ... ca_search_and_connect() ... OK
C1:SUS-ETMY_YAW_COMM ... ca_search_and_connect() ... OK
--- End searches
Waiting for 2 outstanding search(es) ...
Waiting for 2 outstanding search(es) ...
did not find 2

--- Start reads
C1:SUS-ETMY_PIT_COMM ... not connected so no ca_array_get_callback()
C1:SUS-ETMY_YAW_COMM ... not connected so no ca_array_get_callback()
--- End reads

--- Start wait for pending reads

-- End wait for pending reads 0 outstanding read(s)

**** END BURT LOGFILE

The burt save file has no values in it.  Even if I copy over the ETMX save file and put in the correct channel names and values, a burt restore is unsuccessful. 

So, I can do locking tonight by restoring and misaligning by hand, but this sucks, and needs to be fixed. Other optics (at least PRM, SRM, ETMX) seem to be working just fine.  It's just ETMY that has a problem.

I have created a new filter for the PRM oplev damping loops.  The biggest change is an increase in the gain between 0.4 - 7 Hz.

Here is a plot of the old, and my new modelled open loop gain:

When I look at my step and impulse response time series, the notches for the bounce and roll were causing some ringing, so for now they are turned off, both in the model and in the real time system.  Also, the "OLG orig" trace has a 4th order elliptic lowpass at 75 Hz, but the real system had a 4th order elliptic low pass at 35 Hz.  When we use 35 Hz in the model, we get lots of ringing.  So, we have moved both model and real system to 55 Hz 4th order elliptic low passes.  Also, also, we haven't been using the 3.3 Hz resonant gain, so I removed that from the modelled loop.

I have put the "boost" for the .4-7 Hz emphasis into FM 7 of the PRM oplev filters.  I also removed several old filters that are never used.  So, for now, the PRM oplevs should have engaged:  FM 1, 7, 9. Pitch gain is +5, yaw gain is -9.  We can consider re-implementing the bounce-roll notches, and the stack resgain if it looks like those are getting rung up, and causing trouble.

Here is a set of spectra, showing the improvement.  It's unclear why yaw is worse than pitch below 4Hz, and why pitch is so much worse than yaw between 4-15 Hz, however for each of pitch and yaw, the before (reference pink and cyan traces) is higher than the improved (dark red, dark blue traces) between a few tenths of a Hz up to 3ish Hz.  And, we're not causing more noise elsewhere.  We do want to monitor to make sure we're not ringing up the bounce and roll modes, but for now they seem fine.

Nice camera work Steve! I will use these for publicity photos.

Now we need to get one of the video cameras hooked into the MUX so that we can see the flashing and do some image subtraction.

It crossed my mind that, from these pictures, it could be glow from the oplev scattered light that is causing the problem.  However, that seems not possible, since the power fluctuations that we see depend on the presence of the IR light - if it were the oplev light, then when I close the PSL shutter, I should see the same amount of kick, which I don't.  Also, the amount of fluctuation increases with increased stored power in the cavities.  Also, also, Steve reminds me that some of the MC mirrors see similar kicks in their OSEM signals, but they don't have oplevs.

So, I don't believe that the oplev light is causing the problem, but I wanted to write down why I don't think that's it. 

Investigations into OSEM and oplev loops to get rid of the kicks are continuing.

PRM is aligned. IFO is not locked. It is just flashing, including arms. Olympus SP570UZ camera used without IR blocker. Note: PRM side OSEM does not show IR effect.

I will take more pictures with IOO IR blocked and HeNe oplev blocked  tomorrow morning.

PSL NPRO shut down again today for reasons unknown. I was working near the IOO rack and noticed there was no light at both the refl and trans PMC cameras. Jenne and I checked the PSL and found the 'OFF' red switch on the laser driver lit up. Switching ON the green button brought the laser back. PMC and MC autolocked after this.

 I went and keyed the crate again, and this time the computer came back.  I burt restored to Nov 10th.  ETMY is damping again.

 This is what I remember doing all the time when Rob was around, but with all the new computers, I forgot whether or not this was allowed for the slow computers.

Anyhow, I went down there and keyed the crate, but auxey isn't coming back.  I'll give it a few more minutes and check again, but then I might go and power cycle it again.  If that doesn't work, we may have a much bigger problem.

 Don't forget to run burtrestore for the target.

Please just try rebooting the vxworks machine.  I think there is a key on the card or create that will reset the device.  These machines are "embeded" so they're designed to be hard reset, so don't worry, just restart the damn thing and see if that fixes the problem.

 I have disconnected the cable from the SR560 to LSC -ch8 for 15minutes this morning. It is moved from the floor to the top of the chambers as preparation for 40m tour. The SR560 seems to be overloading.

The  ISS servo is off according to the MEDM screen. Why MC-T plot showing zero?  The MC was happy yesterday.

This is what was done (as I recollect) when we said "inspected":Tenet into the computer, ping them and look at the status. Since c1auxey is not responding, here is how c1auxex responds.

controls@rossa:/cvs/cds/caltech/target 0$ telnet c1auxex
Trying 192.168.113.59...
Connected to c1auxex.martian.
Escape character is '^]'.

c1auxex > h
  1  i
  2  -help
  3  --help
  4  h
  5  2
  6  h
  7  -help
  8  i
  9  h
value = 0 = 0x0
c1auxex > i

  NAME        ENTRY       TID    PRI   STATUS      PC       SP     ERRNO  DELAY
---------- ------------ -------- --- ---------- -------- -------- ------- -----
tExcTask   _excTask       fde244   0 PEND          87094   fde1ac   3006b     0
tLogTask   _logTask       fdb944   0 PEND          87094   fdb8a8       0     0
tShell     _shell         ddad00   1 READY         6d974   dda9c8  3d0001     0
tRlogind   _rlogind       fbc11c   2 PEND          2b604   fbbdf4       0     0
tTelnetd   _telnetd       fba278   2 PEND          2b604   fba1a8       0     0
tTelnetOutT_telnetOutTa   db7578   2 READY         2b604   db72e0       0     0
tTelnetInTa_telnetInTas   db6060   2 READY         2b5dc   db5d68       0     0
callback   _callbackTas   f7941c  40 PEND          2b604   f793d4       0     0
scanEvent  ee7ca8         ecacb4  41 PEND          2b604   ecac6c       0     0
tNetTask   _netTask       fd75b8  50 READY         6be6c   fd7550       0     0
scanPeriod ee78f8         ecd554  53 READY         6d192   ecd508       0     0
scanPeriod ee78f8         f23e48  54 DELAY         6d192   f23dfc       0     6
tFtpdTask  _ftpdTask      fb7848  55 PEND          2b604   fb778c       0     0
scanPeriod ee78f8         f266e8  55 READY         6d192   f2669c       0     0
scanPeriod ee78f8         f38678  56 READY         6d192   f3862c       0     0
callback   _callbackTas   f7bcbc  57 PEND          2b604   f7bc74       0     0
scanPeriod ee78f8         f906d8  57 DELAY         6d192   f9068c       0    59
scanPeriod ee78f8         f995ac  58 DELAY         6d192   f99560       0   238
scanPeriod ee78f8         f9c908  59 DELAY         6d192   f9c8bc       0   538
callback   _callbackTas   fa4c1c  65 PEND          2b604   fa4bd4       0     0
scanOnce   ee7764         f9f96c  65 PEND          2b604   f9f92c       0     0
epicsPrint f0501c         e88fa0  70 PEND          2b604   e88f64   c0002     0
ts_Casync  ee5bae         f76b7c  70 DELAY         6d192   f76880  3d0004   178
tPortmapd  _portmapd      fb8d60 100 PEND          2b604   fb8c2c      16     0
EgRam      ea00e4         fa14ac 100 PEND          2b604   fa1458       0     0
CA client  _camsgtask     d85878 180 PEND          2b604   d85774  3d0004     0
CA client  _camsgtask     df91e8 180 PEND          2b604   df90e4       0     0
CA client  _camsgtask     d98bf4 180 PEND          2b604   d98af0       0     0
CA client  _camsgtask     e03cd0 180 PEND          2b604   e03bcc       0     0
CA client  _camsgtask     ddf2b8 180 PEND          2b604   ddf1b4       0     0
CA client  _camsgtask     faaec8 180 PEND          2b604   faadc4       0     0
CA client  _camsgtask     d79f3c 180 PEND          2b604   d79e38       0     0
CA TCP     _req_server    f305dc 181 PEND          2b604   f30540       0     0
CA repeaterf109e2         f215a8 181 PEND          2b604   f21474       0     0
CA event   _event_task    d7fe58 181 PEND          2b604   d7fe10       0     0
CA event   _event_task    d6ce5c 181 PEND          2b604   d6ce14       0     0
CA event   _event_task    dab7e0 181 PEND          2b604   dab798       0     0
CA event   _event_task    d76efc 181 PEND          2b604   d76eb4       0     0
CA event   _event_task    d9bddc 181 PEND          2b604   d9bd94       0     0
CA event   _event_task    d9a864 181 PEND          2b604   d9a81c       0     0
CA event   _event_task    da8d8c 181 PEND          2b604   da8d44       0     0
CA UDP     _cast_server   f2f064 182 READY        efcabe   f2efe4       0     0
CA online  _rsrv_online   f2d84c 183 DELAY         6d192   f2d7bc       0   265
EV save_res_event_task    de88dc 189 PEND          2b604   de8894   3006b     0
save_restor_save_restor   df61cc 190 PEND          2b604   df5c44  3d0002     0
RD save_res_cac_recv_ta   fb47d8 191 READY         2b604   fb46a4  3d0004     0
logRestart f05d42         e861c0 200 PEND+T        2b604   e86174      33  1714
taskwd     ef4d46         e85030 200 DELAY         6d192   e84f7c       0   224
value = 0 = 0x0
c1auxex >
telnet> quit
Connection closed.
controls@rossa:/cvs/cds/caltech/target 0$

Unfortunately this does not work. These WFSs are not the detectors which we can move freely.
In order to move the WFS detectors, we need the precise design of the Gouy phase for each WFS heads.
Without the design, we can't move the detectors.

This is a proposal to move WFSs such way that their reflected beam can be trapped.

Later ps: Nic will take care of the Gouy phase telescopes.

ETMY sus damping restored

 This problem is now worse - the sliders on IFO_ALIGN for ETMY are white.  I can't telnet to the machine either, although auxex works okay.  Rather, it looks like maybe I'm getting to auxey, but then I'm immediately booted.  I can ping both c1auxex and c1auxey with no problem.
 

Heeeeelllp please.  Is this just a "shut off, then turn back on" problem?  I'm wary of hard rebooting things, with all the warnings and threats in the elog lately.  I've sent an email to Jamie to ping him.

There are some vague instructions in the wiki, but they begin at doing the burt restores, not actually restarting the computers: wiki  Back in July, elog 8858 was written, from which the wiki instructions seem to be based.  But in the elog it says "...went to the /cvs/cds/caltech/target/ area and started to (one by one) inspect all of the targets to see if they were alive.", but I don't know what "inspected" means in this case.  I probably should, since I've been here for something like a millennia, but I don't.

 Sorry to say but MC1, MC2, MC3 and PRM face OSEMS are having the same problem of leaking IR into the sensors

The PMC was not locked for 11 minutes on this plot.

 The 785 analyzer in the 40 had a wonky hard to read screen. I was hoping that a new white CRT would fix all the problems. 

I installed a white CRT, which didn't fix the wonkyness, but I adjusted the CRT position, brightness, focus settings to make the screen somewhat more readable.

BEFORE:

AFTER:

If we want to send the thing in for service to fix the wonkyness, we should probably hold on to the old CRT because they will probably replace the whole screen assembly and we'll lose our white screen.

 IR off for 11 minutes. The PRM  face sensors are effected. The PRM side and the rest of the SUS OSEMS are not effected.

Some more words about the ISS -> OSEM measurement:

The calibration of the OSEMs have been done so that these channels are each in units of microns. The SIDE channel has the lower noise floor because Valera increased the analog gain by 5x some time ago and compensated with lower digital gain.

The peak heights in the plot are:

UL   0.85

LL   0.78

UR   0.61

LR   0.45

S    0.27

So that tells us that the coupling is not uniform, but mostly coming in from the left side (which side is the the SIDE OSEM on?).

Jenne and I discussed what to do to mitigate this in the loops. Before we vent to fix the scattering (by putting some covers around the OSEMs perhaps), we want to try to tailor the OSEM damping loops to reduce their strength and increase the strength of the OL loops at the frequencies where we saw the bulk of the instability last time.

Jenne is optimizing OL loops now, and I'm working on OSEM tweaking. My aim is to lower the overall loop gains by ~3-5x and compensate that by putting in some low Q, resonant gain at the pendulum modes as we did for eLIGO. We did it here at the 40m several years ago, but had some troubles due to some resulting instability in the MC WFS loops.

In parallel, Steve is brainstorming some OSEM shields and I am asking around LIGO for some AC OSEM Satellite modules.

In the process of figuring out what we can do to fix our PRM motion problem, I am looking at the PRM oplev. 

Eventually (as in, tomorrow), I'd like to be able to simulate some optic motion as a result of an impulse, and see what the oplev loops do to that motion.  (For starters, I'll take the impulse response of the OSEM loop as my time series that the oplev loop sees).

One thing that I have done is look at the oplev model that Rana put together, which is now in the noisebudget svn: /ligo/svncommon/NbSVN/aligonoisebudget/trunk/OpLev/C1

This script plots the open loop gain of the modeled oplev:

This should be compared to the pitch and yaw measured transfer functions:

In the YAW plot, there are 2 transfer functions.  The first time around, the UGF was ~2.5Hz, which is too low, so I increased the gain in the C1:SUS-PRM_OLYAW filter bank from -3 to -9. 

The shapes of the measured and modeled transfer functions look reasonably similar, but I haven't done a plot overlay.  I suspect that the reason I don't see the same height peak as in the model is just that I'm not taking a huge number of points.  However, if the other parts of the TF line up, I'll assume that that's okay.

I want to make sure that the modeled transfer function matches the measured ones, so that I know I can trust the model.  Then, I'll figure out how to use the time series data with the simulated loop.  Ideally, I'd like to see that the oplev loop can fully squish the motion from the OSEM kicks.  Once I get something that looks good (by hand-tweaking the filter shape), I'll give it a try in the actual system.  We should, as soon as I get the optimal stuff working, redo this in a more optimal way.  Both now, and after I get an optimal design, I'll look at the actual step and impulse responses of the loop, to make sure there aren't any hidden instabilities.

Other thoughts for the night:

Rana suggests increasing the gain in some of the oplev QPD heads (including PRM), so that we're getting more than a few hundred counts of power on each quadrant.  Since our ADCs go to 32,000 counts, a few hundred is very small, and keeping us close to our noise limits.

Also, just an observation, but when I watch the REFL camera along with POP and AS, it's clear that the PRM is getting kicked, and I don't have the ETMs aligned right now, so this is just PRMI flashes.  There is also a lot of glow in the BS chamber during flashes (as seen on the PRM face video camera).

Back in 2009, Jenne replaced the PMC board mixer with a Level 13 one. Today I noticed that the LO level on the PMC screen was showing a LO level of ~5-10 dBm and fluctuating a lot. I think that it is related to the well known failure of the Mini-Circuits ERA-5SM amplifier which is on the D000419-A schematic (PMC Frequency Reference Card). The Hanford one was dying for 12 years and we found it in late 2008. If we don't have any in the blue bin, we should ask Steve to order 10 of them.

The attached trend shows 2000 days of hour trend of the PMC LODET channel. The big break in 2009 is when Jenne changed the mixer and then attenuated the input by 3 dB. The slow decay since then is the dying amplifier I guess.

Since the LOCALC channel was not in the trend, I added it to the C0EDCU file tonight and restarted the FB DAQD process. Its now in the dataviewer list.

I went out and took out the 3 dB attenuator between the LO card and the PMC Mixer. The LO monitor now reads 14.9 dBm (??!!). The SRA-3MH mixer data sheet claims that the mixer works fine with an LO between 10 and 16 dBm, so I'll leave it as is. After we get the ERA-5, lets fix the LODET monitor by upping its gain and recalibrating the channel.

 A small followup measurement. Here are spectra of the MC trans diode with and without the ISS on. The DC value of the diode (in counts) changed from 17264.2 (no ISS) to 17504.3 (with ISS), but I didn't account for this change in the plot.

There is a small inkling of benefit between 100Hz and 1kHz. Above about 100Hz, the RIN is suppressed to about the noise level of this measurement. Below 100Hz there is no change, which probably means that power fluctuations are introduced downstream of the AOM, which argues for an outer-loop ISS down the road.

Atm #2 is in units of RIN.

AOM driving from DAC:

I found that the DAC channels for TT3 and TT4 are connected up in the simulink model, but we aren't using them, since we don't actually have those tip tilts installed.  So, we hooked up the TT4 LR DAC output, which is channel 8 on the 2nd set of SMA outputs.  We put our AOM excitations into TT4_LR_EXC.

[Gabriele, Jenne]

Nic and Evan put the ISS together (elog 9376), and we used an injection into the error point (?) to modulate the laser power before the PMC (The AOM had a bias offset, but there is no loop).  This gives us some RIN, that we can try to correlate with the PRM OSEM sensors. 

We injected several lines, around 100, 200, 500 and 800 Hz.  For 100, 200 and 800 Hz lines, we see a ratio between POPDC and the OSEM sensors of 1e-4, but at 500 Hz, the ratio was more like 1e-3. We're not sure why this ratio difference exists, but it does.  These ratios were true for the 4 face OSEMs.  The side OSEM saw a slightly smaller signal.  

For these measurements, the PRMI was sideband locked, and we were driving the AOM with an amplitude of 10,000 counts (I don't know what the calibration is between counts and actual drive, which is why we're looking at the POPDC to sensor *ratio*).  

To get a more precise number, we may want to consider locking the PRMI on carrier, so we have more power in the cavity, and so more signal in the OSEMs.  

These ratios look, by eye, similar to the ratios we see from the time back on 30 Oct when we were doing the PRMI+2arms test, and the arms were resonating about 50 units.  So, that is nice to see some consistency.

This time series is from 1067163395 + 27 seconds, from 30 Oct 2013 when we did the PRMI+2arms.

Ideas to go forward:

We should think about chopping the OSEM LEDs, and demodulating the PD sensors. 

We should also take a look in the chamber with a camera from the viewport on the north side of the BS chamber, to see if we see any flashes in the chamber that could be going into the OSEMs, to see where we should maybe put aluminum foil shields.

The first picture shows that there is indeed a DAC next to the ADC in the LSC IO chassis. The second picture shows how there are two cables, each one carrying 8 channels of DAC. The third one shows how these come out of the coil drivers to handle the Tip/Tilt mirrors which point the beam from the IMC into the PRC. It should be the case that the second Dewhitening filter board can give us access to the next 8 channels for use in driving an audio signal into the control room or an ISS excitation.

We have implemented an SR560-based ISS loop using the AOM on the PSL table. This is a continuation of the work in 40m:9328.

We dumped the diffracted beam from the AOM onto a stack of razor blades. This beam is not terribly well separated from the main beam, so the razor blades are at a very severe angle. Any alternatives would have involved either moving the AOM or attempting to dump the diffracted beam somewhere on the PMC refl path. We trimmed the RF power potentiometer on the driver so that with 0.5 V dc applied to the AM input, about 10% of the power is diverted from the main beam.

We ran the PMC trans PD into an AC-coupled SR560. To shape the loop, we set SR560 to have a single-pole low- pass at 300 Hz and an overall gain of 5×10⁴. We take the 600 Ω output and send it into a 50 Ω feed-through terminator; this attenuates the voltage by a factor of 10 or so and thereby ensures that the AOM driver is not overdriven.

The AOM driver's AM input accepts 0 to 1 V, so we add an offset to bias the control signal. The output of the 50 Ω feedthrough is sent into the 'A' input of a second SR560 (DC coupled, A − B setting, gain 1, no filtering). Using a DS345 function generator, a 500 mV offset is put into the 'B' input (the function generator reads −0.250 V because it expects 50 Ω input). The 50 Ω output of this SR560 is sent into the AOM driver's AM input.

A measurement of suppressed and unsuppressed RIN is attached. We have achieved a loop with a bandwidth of a few kilohertz and with an in-loop noise suppression factor of 50 from 100 Hz to 1 kHz. This measurement was done using the PMC trans PD, so this spectrum may underestimate the true RIN.

The restore scripts from the IFO config screen half-failed, with this error:

retrying (1/5)...
retrying (2/5)...
CA.Client.Exception...............................................
    Warning: "Virtual circuit disconnect"
    Context: "c1auxey.martian:5064"
    Source File: ../cac.cpp line 1214
    Current Time: Wed Nov 13 2013 17:24:00.389261330
..................................................................

Jamie, do you know what this might be?  When requested, ETMY was not misaligned or restored, but we got these errors.  So, somehow we're not talking properly to EY, but other things seem fine (the models are running okay, the suspension is damped, etc, etc.)

Interesting results. When you compute the effect of ETM motion, you maybe should also consider that moving around the arm cavity axis changes the matching of the input beam with the cavity, and thus the coupling between PRC and arms. But I believe this effect is of the same order of the one you computed, so maybe there is only one or two factors of two to add. This do not change significantly the conclusion.

Instead, the numbers you're giving for PRM motion are interesting. Since I almost never believe computations before I see that an experiment agrees with them, I suggest that you try to prove experimentally your statement. The simplest way is to use a scatter plot as I suggested the past week: you plot the carrier arm power vs PRM optical lever signals in a scatter plot. If there is no correlation between the two motions, you should see a round fuzzy ball in the plot. Otherwise, you will se some non trivial shape. Here is an example: https://tds.ego-gw.it/itf/osl_virgo/index.php?callRep=18918

New limit switch installed and tested. The crane is back in full operational mode. Two spare limit switches on hand.

 I think that our problem of seeing significant arm power fluctuations while we bring the arms into resonance during PRMI+arms tests is coming from PRM motion. I've done 3 calculations, so I will describe below why I think the first two are not the culprit, and then why I think the PRM motion is our dominant problem.

===============================================================

ALS length fluctuations

Arm length fluctuations seem not to be a huge problem for us right now, in terms of what is causing our arm power fluctuations.

What I have done is to calculate the derivative of the power in the arm cavity, using the power buildup that optickle gives me. The interferometer configuration I'm using is PRFPMI, and I'm doing a CARM sweep. Then, I look at the power in one arm cavity. The derivative gives me Watts buildup per meter CARM motion, at various CARM offsets. Then, I multiply the derivative by 60 nm, which is my memory of the latest good rms motion of the ALS system here at the 40m. I finally divide by the carrier buildup in the arm at each offset, to give me an approximation of the RIN at any CARM offset.

I don't know exactly what the calibration is for our ALS offset counts, but since we are not seeing maximum arm cavity buildup yet, we aren't very close to zero CARM offset. 

From this plot, I conclude that we have to be quite close to zero offset for arm length fluctuations to explain the large arm power fluctuations we have been seeing.

=======================================================================

AS port contrast defect from ETM motion

For this calculation, I considered how much AS port contrast defect we might expect to see given some ETM motion. From that, I considered what the effect would be on the power recycling buildup. 

Rather than doing the integrals out, I ended up doing a numerical analysis. I created 2 Gaussian beams, subtracted the fields, then calculated the total power left. I did this for several separations of the beams to get a plot of contrast defect vs. separation. My simulated Gaussian beams have a FWHM of 1 unit, so the x-axis of the plot below is in units of spot motion normalized by spot size. 

Unfortunately, my normalization isn't perfect, so 2 perfectly constructively interfering beams have a total power of 0.3, so my y-axis should all be divided by 0.3. 

The actual beam separation that we might expect at the AS port from some ETM motion (of order 1e-6 radians) causing some beam axis shift is of the order 1e-5 meters, while the beam spot size is of the order 1e-3 meters. So, in normalized units, that's about 1e-2. I probably should change the x-axis to log as well, but you can see that the contrast defect for that size beam separation is very small. To make a significant difference in the power recycling cavity gain, the contrast defect, which is the Michelson transmission, should be close to the transmission of the PRM. Since that's not true, I conclude that ETM angular motion leading to PRC losses is not an issue. 

I still haven't calculated the effect of ITM motion, nor have I calculated either test mass' angular effect directly on arm cavity power loss, so those are yet to be done, although I suspect that they aren't our problem either. 

========================================================================

PRM motion

I think that the PRM moving around, thus causing a loss in recycling gain, is our major problem. 

First, how do I conclude that, then some thoughts on why the PRM is moving at all. 

=========

theta = 12e-6 radians (ref: oplev plot from elog 9338 last week)

L = 6.781 meters

g = 0.94

a = theta * L /(1-g) = 0.0014 meters axis displacement

w0 = 3e-3 meters = spot size at ITM

a^2/w0^2 = 0.204 ==>> 20% power loss into higher order modes due to PRM motion.

That means 20% less power circulating, hitting the ITMs, so less power going into the arm cavities, so less power buildup. This isn't 50%, but it is fairly substantial, using angular fluctuation numbers that we saw during our PRMI+arms test last week. If you look at the oplev plot from that test, you will notice that when the arm power is high (as is POP), the PRM moves significantly more than when the carrier buildup in the cavities was low. The rms motion is not 12 urad, but the peak-to-peak motion can occasionally be that large. 

So, why is that? Rana and I had a look, and it is clear that there is a difference in PRM motion when the IFO is aligned and flashing, versus aligned, but PSL shutter is closed. Written the cavities flash, the PRM gets a kick. Our current theory is that some scattered light in the PRC or the BS chamber is getting into the PRM's OSEMs, causing a spike in their error signal, and this causes the damping loops to push on the optic. 

We should think a little more on why the PRM is moving so much more that any other optic while the power is building up, and if there is anything we can do about the situation without venting. If we have to, we should consider putting aluminum foil beam blocks to protect the PRM's OSEMs. 

Since I saw that the trend was good, I aligned the MC refl path to the existing IMC alignment:

1. removed a broken IRIS that was clipping the reflected beam (and its mount)
2. moved the first 1" diameter steering mirror on the high power path after the 2" diameter R=10% steering mirror. It was not centered.
3. Moved the lens just upstream of the LSC RFPD away from the PD by ~5 mm. The beam going towards the WFS was too close to this mount and I could see some glow.
4. Centered the beam on all optics in the WFS path and then the WFS DC.
5. Centered beam on LSC RFPD.

The reflected spots from the PD are not hitting the dump correctly. WE need to machine a shorter post to lower the dump by ~1 cm to catch the beams.

 I installed 'nfs-client' on zita (the StripTool terminal). It now has mounted all the shared disks, but still can't do StripTool since its a 32-bit machine and our StripTool is 64.

 I have the X end transmission QPD, as well as the whitening board, out on the electronics bench.  Since the Thorlabs high-gain TRX PD also goes through this whitening board, we have no transmission signal for the Xarm at this time. The whitening board was in the left-most slot, of the top crate in the Xend rack.  The only cables that exist for it (like the Yend), are the ribbon from the QPD, the 4-pin lemo from the Thorlabs PD, and the ribbon going to the ADC.

I have taken photos, and want to make sure that I know what is going on on the circuits, before I put them back in. 

The QPD:

The whitening board:

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

Seems to now be working. I made several fixes to the scripts to get it working again:

1. changed TCSH scripts to BASH. Used /usr/bin/env to find bash.
2. fixed stdout and stderr redirection so that we could see all error messages.
3. made the PERL scripts executable. most of the PERL errors are not being logged yet.
4. fixed paths for the MEDM screens to point to the right directories.
5. the screen cap only works on screens which pop open on the left monitor, so I edited the screens so that they open up there by default.
6. moved the CRON jobs from mafalda over to megatron. Mafalda no longer is running any crons.
7. op540m used to run the 3 projector StripTool displays and have its screen dumped for this web page. Now zita is doing it, but I don't know how to make zita dump her screen.

Since the pointing has gone bad again, I went to the PSL to investigate. Found some bad things and removed them:

1) There was a stopped down iris AGAIN in the main beam path, after the newly installed mirror mount. I opened it. Stop closing irises in the beam path.

2) The beam dump for the IOO QPD reflection was just some black aluminum. That is not a real dump. I removed it. We need two razor blade dumps for this.

3) There was an ND filter wheel (???) after one of the PMC steering mirrors. This is not good noise / optics practice. I removed it and dumped the beam in a real dump. No elog about this ?!#?

The attached trend shows the last 20 days. The big step ~2 weeks ago is when Steve replaced the steering mirror mount with the steel one. I don't understand the drift that comes after that.

Today I also spent ~1 hour repairing the Aldabella laptop. Whoever moved it from the PSL area to the SP table seems to have corrupted the disk by improper shutdown. Please stop shutting the lid and disconnecting it from the AC power unless you want to be fixing it. Its now running in some recovery mode. Lets leave it where it is next to the PSL and MC1.

I steered the MC suspensions back to where they were on the trends before the PSL mirror mount swap and then aligned the PSL beam into it by touching the last 2 steel mounts. Once the alignment was good without WFS, I centered the beams on the IOO QPDs. If it behaves good overnight, I will center the unlocked beams on the MC WFS.

Please stay off the PSL for a couple days if you can so that we can watch the drift. This means no opening the doors, turning on the lights, or heavy work around there.

 Seems partially broken again. Not updating for most of the FE. I've commented out the cron lines for this as well as the mostly broken MEDM Snapshots job. I'm in the process of adding them to the megatron cron (since that machine is at least running 64 bit Ubuntu 12, instead of 32-bit CentOS)

General Remarks on the BBPD

- To form the LC network: Use fixed SMD inductors from Coilcraft. SMD tunable capacitors are found in the shelf right next to Steve's desk.
  If the tuning is too coarse, combine an appropriate fixed ceramic SMC C and the tunable C (in parallel, of course)

- L1/C1a/C1b pads are specifically designed for an additional notch

- Another notch at the diode stage can be formed between the middle PD pin (just left of the marking "C3b") to the large GND pad (between C1a/C1b to C3a).
  You have to scratch off the green resin with a small flat screw driver (or anything similar)

- A notch at the amplifier stage can be formed between the output of MAR-6SM ("+" marking)  and one of the GND pads (left side of the "U1" marking)

- The original design of the PD is broadband. So additional notches on the diode stage provides notches and resonances.
  Check if the resonances do not hit the signal frequencies.

- One would think the PD can have resonant feature to reduce the coupling of the undesired signals.
  In some sense it is possible but it will be different from the usual resonant tank circuit in the following two points.

  * Just adding a parallel L between the cathode and ground does not work. As this DC current should be directed to the DC path,
    L&C combo should be added. In fact this actually give a notch-resonance pair. This C should be big enough so that you can ignore it
    at the target resonant frequency. Supply complimentary small C if necessary to keep low impedance of the Cs at the target frequency.
    (i.e. Check SRF - self-resonant frequency of the big C)

  * Since the input impedance of MAR-6SM is 50Ohm, the top of the resonant curve will be cut at 50Ohm. So the resultant shape looks
    like a bandpass rather than a resonance.

- So in total, simulation of the circuit is very important to shape the transimpedance. And, consider the circuit can not be formed as simulated
  because of many practical imperfections like stray Ls and Cs.

 I have done a sweep of CARM, while looking at the fields inside of one arm (I've chosen the Xarm), to see where any resonances might be, that could be causing us trouble in keeping the PRMI locked as we bring the arms into resonance. 

Since Gabriele pointed out to me that we're using the 3x55MHz signal for locking, we should be most concerned about resonances of the higher orders of 55, and not of 11.  So, on this plot, I have up to the 6th order 55 MHz sidebands, which are 332 MHz.  Although the Matlab default color chart has wrapped around, it's clear that the carrier is the carrier, and the +4f2, which is the same blue, is not the giant central peak.  So, it's kind of clear which trace is which, even though the legend colors are degenerate.  Also, the main point that I want to show here is that there is nothing going on near the carrier, with any relevant amplitude.  The nearest things are the plus and minus 55 MHz sidebands themselves, and they're more than 50 nm away from the carrier. 

Recalling from elog 9122, the PRFPMI and DRFPMI linewidths are about 40pm.  50pm away from the resonant point is ~1/10 the power, and 100pm away from the resonant point is ~1/100 the power.  So, 50 nm is a looooong ways away. 

Just for kicks, here is a plot of all the resonances of the 1f and 2f modulation frequencies, up to 30*f1, which is the same 6*f2:

The resonances which are "close" to the carrier are the 9th order 11 MHz sidebands, and they're 280pm from the carrier, so twice as far as we need to be, to get our arm powers to ~1/100 of the maximum, and, they're a factor of ~1e4 smaller than the carrier.

Here is a photo of the board inside the broadband photodiode (one of them) that I took from the Gyro experiment:

This PD is Serial Number S1200271.

We need to have a look at the schematic, figure out what's in here now, and then modify this to be useful (appropriate resonances / notches, as well as amplification) for POP 22/110.

Between the 40m meeting, and chatting with Gabriele, there was lots of talking yesterday about our 40m Lock Acquisition game plan. 

From those talks, here is my current understanding of the plan, in a Ward-style cartoon:

 (This is a 2 page document - description of steps is on 2nd page)

If you look closely, you will notice that there are several places that I have used "?" rather than numbers, to indicate what RFPD signal we should be using.  To fill these in, I need to look at some more simulations, and think more carefully about what signals exist at what ports, and what SNR we have at each of those ports.

Also, while the overall scale of the arm power plot is correct, the power level at each step is totally arbitrary right now, and should just be taken to mean places (in time) where the CARM offset is reduced a little more.

There are several things at this point that we know we need to look into:

* POP 22/110 PD and filtering electronics should be switched to a broadband PD, rather than the Thorlabs PD + Miniciruits filters. (Hardware)

* Whitening for the transmission QPDs needs to be thought about more carefully. (Calculation, then hardware)

* Chose a good SNR REFL DC signal, which may or may not be from the PD we are currently using (I think it's the DC of REFL11, but I'll have to check). (Calculation)

* For DRMI locking, what is the size of the SRCL error signal at AS55, AS165, and the REFL ports?  Do we need to lock with AS port, and then switch over to a REFL 3f port, to make acquisition easier?  (Simulation)

* Similarly, I want to make the equivalent of Figure 3 of T1000294, with our 40m parameters. (Simulation)

* To set the phase of AS110, simulate the demod phase of AS110 in both DRMI and SRMI cases.  If no (significant) change, maybe we can set the phase in the real system by misaligning the PRM, and watching the SRMI flash.  (Simulation)

* Simulate an arm sweep, up to many orders of the sidebands, to see how close to the carrier resonance any sideband resonances might be.  If something like the 4th order sideband resonates, and then beats with a 1st order sideband, is that signal big enough to disturb our 3f locking of the PRMI / DRMI?  We want to be holding the arms off resonance with ALS closer to the carrier than any "important" sideband resonances (where the definition of "important" is still undetermined).  (Simulation)

* Check if we can hand DARM from the DC transmission signals to the final RF signal while we still have a large CARM offset. Is there a point where the CARM offset is too large, and we must be still using the DC signals? (Simulation)

* At what arm power level can we transition from ALS to IR DC transmission signals for the individual arms? (Simulation)

* Still need to finish calculating what could be causing our big arm power fluctuations (Test mass angular motion?  PRM angular motion? ALS noise?) (Calculation)

Replys, and comments are welcome, particularly to help me understand where I may have (likely did) go wrong in drawing my cartoon. 

 New limit switch will be installed tomorrow morning

Konecranes postponed installation Friday morning Nov. 8

Friday 5pm : Konacranes promising to be here 8am Monday, Nov 11

It was rescheduled on Tuesday again for Wednesday, Nov 13

 The qpd sees the power drop as position change.

The laser  monitoring screen shows little changes of the Innolight 2W output. See elog 9292 to compare

So why does the PMC downgrade if the laser output is stationary ?

The PMC-T power is down to 0.75V  The auto locker does maximize power output.

It needs a manual alignment touch up.

This definitely looks like a timing problem on the c1lsc front end computer.  The red lights on the left mean that the timing synchronization is lost at the user model.  I'm perplexed why it looks like the IOP is not seeing the same error, though, since it should originate at the ADC.  The red lights to the right just mean the timing synchronization is lost with the DAQ, which is too be expected given a timing loss at the front end.

We'll have to take a closer look when this happens again.

I switched OFF the +/-5V power supplies on the IOO rack to hook up the ADC power connectors through 250mA fuses to +/-5V. Since these power supplies were powering the MC demod boards, MC remained unlocked during the process. I turned the power supplies back ON and MC relocked itself after this.

We have decided that, rather than replacing the power source for the amplifiers that are on the rack, and leaving the Thorlabs PD as POP22/110, we will remove all of the temporary elements, and put in something more permanent.

So, I have taken the broadband PDs from Zach's Gyro experiment in the ATF.  We will figure out what needs to be done to modify these to notch out unwanted frequencies, and amplify the signal nicely.  We will also create a pair of cables - one for power from the LSC rack, and one for signal back to the LSC rack.  Then we'll swap out the currently installed Thorlabs PD and replace it with a broadband PD.

Something funny is going on with the framebuilder's communication with the LSC machine. 

This is a different failure mode / error than I have seen before.  It's not the type of problem that is solved by restarting the mxstreams (that is indicated by also the 2 blocks on top of one another, that are green on the lsc machine right now, being red), although I did try that, before I looked closer and realized that that wasn't the problem.

ssh-ing to c1lsc, and doing a "rtcds restart all" seems to be fixing the problem.  Both c1oaf and c1cal needed another round of restarting, because they needed their BURT buttons pressed manually.  All of the models on the lsc machine are running fine now, though.

Here's a screenshot of the CDS overview screen, with the error lights: