Don't forget to run burtrestore for the target.

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.

I forgot how we could turn on the PRM oplev servo and the PRM ASC servo at the same time without conflict.
It seems that this new oplev servo covers 0.04 to 8Hz. It's pretty broadband. Do we inject the ASC signal to the oplev error?

This morning I came in the 40m then found
1) c1auxex was throwing out the same errors as recently seen.
2) c1iscex processes had errors which persisted even after the mx stream reset.

1) c1auxex - fixed

Tried telnet c1auxex => rejected by the host

Went down to the south end. Power cycled the target. Came back to the control room.
=> Confirmed the epics read/write is back.
Burtrestored the epics vars for the target to the snapshot on 31th Oct at 5:07.

2) c1iscex - still not fixed

ssh c1iscex
rtcds restart all => c1x01 is still in red. 
Followed the procedure on the elog entry 9007. => Still the same error.

At least c1x01 is stalled. Here is the status.

Sync Source is TDS.
C1:DAQ-DC0_C1X01_STATUS is 0x2bad.
C1:DAQ-DC0_C1X01_CRC_SUM stays 0.
The screen shot is attached.

dmesg related to c1x01

controls@c1iscex ~ 0$ dmesg |grep c1x01
[   32.152010] c1x01: startup time is 1069440223
[   32.152012] c1x01: cpu clock 3000325
[   32.152014] c1x01: Epics shmem set at 0xffffc9001489c000
[   32.152208] c1x01: IPC at 0xffffc90018947000
[   32.152209] c1x01: Allocated daq shmem; set at 0xffffc9000480c000
[   32.152210] c1x01: configured to use 4 cards
[   32.152211] c1x01: Initializing PCI Modules
[   32.152226] c1x01: ADC card on bus b; device 4 prim b
[   32.152227] c1x01: adc card on bus b; device 4 prim b
[   32.154801] c1x01: pci0 = 0xdc300400
[   32.154837] c1x01: pci2 = 0xdc300000
[   32.154842] c1x01: ADC I/O address=0xdc300000  0xffffc90003f62000
[   32.154845] c1x01: BCR = 0x84060
[   32.154858] c1x01: RAG = 0x117d8
[   32.154861] c1x01: BCR = 0x84260
[   32.583220] c1x01: SSC = 0x16
[   32.583223] c1x01: IDBC = 0x1f
[   32.583236] c1x01: DAC card on bus 14; device 4 prim 14
[   32.583237] c1x01: dac card on bus 14; device 4
[   32.584527] c1x01: pci0 = 0xdc400400
[   32.584546] c1x01: dac pci2 = 0xdc400000
[   32.584551] c1x01: DAC I/O address=0xdc400000  0xffffc90003f6a000
[   32.584555] c1x01: DAC BCR = 0x810
[   32.584678] c1x01: DAC BCR after init = 0x30080
[   32.584681] c1x01: DAC CSR = 0xffff
[   32.584687] c1x01: DAC BOR = 0x3415
[   32.584693] c1x01: set_8111_prefetch: subsys=0x8114; vendor=0x10e3
[   32.584722] c1x01: Contec 1616 DIO card on bus 23; device 0
[   32.593429] c1x01: contec 1616 dio pci2 = 0x4001
[   32.593430] c1x01: contec 1616 diospace = 0x4000
[   32.593434] c1x01: contec dio pci2 card number= 0x0
[   32.593439] c1x01: Contec BO card on bus 18; device 0
[   32.593447] c1x01: contec dio pci2 = 0x3001
[   32.593448] c1x01: contec32L diospace = 0x3000
[   32.593451] c1x01: contec dio pci2 card number= 0x0
[   32.593456] c1x01: 5565 RFM card on bus 7; device 4
[   32.597218] Modules linked in: c1x01(+) open_mx mbuf
[   32.599939]  [<ffffffffa002e430>] mapRfm+0x71/0x392 [c1x01]
[   32.600199]  [<ffffffffa002ec91>] mapPciModules+0x540/0x8cf [c1x01]
[   32.600458]  [<ffffffffa002f2c1>] init_module+0x2a1/0x9d6 [c1x01]
[   32.600717]  [<ffffffffa002f020>] ? init_module+0x0/0x9d6 [c1x01]
[   32.616194] c1x01: RFM address is 0xd8000000
[   32.616196] c1x01: CSR address is 0xdc000000
[   32.616206] c1x01: Board id = 0x65
[   32.616209] c1x01: DMA address is 0xdc000400
[   32.616213] c1x01: 5565DMA at 0xffffc90003f72400
[   32.616215] c1x01: 5565 INTCR = 0xf010100
[   32.616217] c1x01: 5565 INTCR = 0xf000000
[   32.616218] c1x01: 5565 MODE = 0x43
[   32.616220] c1x01: 5565 DESC = 0x0
[   32.616232] c1x01: 5 PCI cards found
[   32.616233] c1x01: ***************************************************************************
[   32.616234] c1x01: 1 ADC cards found
[   32.616235] c1x01:     ADC 0 is a GSC_16AI64SSA module
[   32.616236] c1x01:         Channels = 64
[   32.616236] c1x01:         Firmware Rev = 34
[   32.616238] c1x01: ***************************************************************************
[   32.616239] c1x01: 1 DAC cards found
[   32.616239] c1x01:     DAC 0 is a GSC_16AO16 module
[   32.616240] c1x01:         Channels = 16
[   32.616241] c1x01:         Filters = None
[   32.616242] c1x01:         Output Type = Differential
[   32.616242] c1x01:         Firmware Rev = 6
[   32.616244] c1x01: MASTER DAC SLOT 0 1
[   32.616244] c1x01: ***************************************************************************
[   32.616246] c1x01: 0 DIO cards found
[   32.616246] c1x01: ***************************************************************************
[   32.616248] c1x01: 0 IIRO-8 Isolated DIO cards found
[   32.616248] c1x01: ***************************************************************************
[   32.616250] c1x01: 0 IIRO-16 Isolated DIO cards found
[   32.616250] c1x01: ***************************************************************************
[   32.616252] c1x01: 1 Contec 32ch PCIe DO cards found
[   32.616252] c1x01: 1 Contec PCIe DIO1616 cards found
[   32.616253] c1x01: 0 Contec PCIe DIO6464 cards found
[   32.616254] c1x01: 2 DO cards found
[   32.616255] c1x01: TDS controller 0 is at 0
[   32.616256] c1x01: Total of 4 I/O modules found and mapped
[   32.616257] c1x01: ***************************************************************************
[   32.616259] c1x01: 1 RFM cards found
[   32.616260] c1x01:     RFM 0 is a VMIC_5565 module with Node ID 41
[   32.616261] c1x01: address is 0x18d80000
[   32.616261] c1x01: ***************************************************************************
[   32.616262] c1x01: Initializing space for daqLib buffers
[   32.616263] c1x01: Initializing Network
[   32.616264] c1x01: Found 1 frameBuilders on network
[   32.616265] c1x01: Epics burt restore is 0
[   33.616012] c1x01: Epics burt restore is 0
[   34.617018] c1x01: Epics burt restore is 0
[   35.618017] c1x01: Epics burt restore is 0
[   36.619011] c1x01: Epics burt restore is 0
[   37.621007] c1x01: Epics burt restore is 0
[   38.622008] c1x01: Epics burt restore is 0
[   39.733257] c1x01: Sync source = 4
[   39.733257] c1x01: Waiting for EPICS BURT Restore = 1
[   39.793001] c1x01: Waiting for EPICS BURT 0
[   39.793001] c1x01: BURT Restore Complete
[   39.793001] c1x01: Found a BQF filter 0
[   39.793001] c1x01: Found a BQF filter 1
[   39.793001] c1x01: Initialized servo control parameters.
[   39.794002] c1x01: DAQ Ex Min/Max = 1 3
[   39.794002] c1x01: DAQ XEx Min/Max = 3 53
[   39.794002] c1x01: DAQ Tp Min/Max = 10001 10007
[   39.794002] c1x01: DAQ XTp Min/Max = 10007 10507
[   39.794002] c1x01: DIRECT MEMORY MODE of size 64
[   39.794002] c1x01: daqLib DCU_ID = 19
[   39.794002] c1x01: Calling feCode() to initialize
[   39.794002] c1x01: entering the loop
[   39.794002] c1x01: ADC setup complete
[   39.794002] c1x01: DAC setup complete
[   39.794002] c1x01: writing BIO 0
[   39.814002] c1x01: writing DAC 0
[   39.814002] c1x01: Triggered the ADC
[   40.874003] c1x01: timeout 0 1000000
[   40.874003] c1x01: exiting from fe_code()

The Phase tracker outputs (= ALS X/Y error signals) are now conveyed to the LSC model.

Their entry points at the LSC model are C1:LSC-ALSX_IN1 and C1:LSC-ALSY_IN1.
They are connected to the signal matrix (28th and 29th signals) via signal conditioning filters (C1:LSC-ALSX and C1:LSC-ALSY).

The main LSC screen has not been updated. The conventional ALS servos are still remains as they were.

This renovation required the recompilation of c1als, c1rfm, and c1lsc. Two PCIe-RFM bridge paths were added resulting in
increase of the c1rfm timing budget from 38 to 44.

It seems that the front fan unit was running at the full speed. The fan itself seems still OK.

I talked with Jamie and make a power cycling (i.e. shutdown gracefully, unplug the power supply cables (x4), plug them in again, and pushed the power button)

The warning signal went off and the fan is quiet. FOR NOW.

Now, daqd and ndsd is down.

FB cannot mount /opt/rtcds and /cvs/cds during its boot.

After mounting these manually, I tried to run /opt/rtcds/caltech/c1/target/fb/start_daqd.inittab and /opt/rtcds/caltech/c1/target/fb/start_nds.inittab
but they don't keep running.

I'll be back to this issue tomorrow with Jamie's help.

Now FB is fixed: daqd and nds are running

When I rebooted FB, I noticed that any of the nfs file systems were not mounted.
I started tracking down the issues from here.

I googled the common issues of the nfs mounting during the boot sequence.
- It is good to give "_netdev" option to fstab to mount the system after the network connection is established.

- "auto" option specifies that the file system is mounted when mount -a is run

Resulting /etc/fstab is this:

But this didn't help mounting the nfs file systems at boot yet. I dug into google again and found a command "/sbin/rc-update".
"/sbin/rc-update show" shows what services are activated at boot. It did not include "nfsmount". So the following command
was executed

> sudo /sbin/rc-update add nfsmount boot

> /sbin/rc-update show

After rebooting, I confirmed that the nfs file systems are correctly mounted
and daqd and nds are automatically started.

This means that FB had never been configured to run correctly at boot. Shame on you!

c1scy had frequent time-over. This caused the glitches of the OSEM damping servos.

Today Eric Q was annoyed by the glitches while he worked on the green PDH inspection at the Y-end.

In order to mitigate this issue, low priority RFM channels are moved from c1scy to c1tst.
The moved channels (see Attachment 1) are supposed to be less susceptible to the additional delay.

This modification required the following models to be modified, recompiled, reinstalled, and restarted
in the listed order: c1als, c1sus, c1rfn, c1tst, c1scy

Now the models are are running. CDS status is all green.
The time consumption of c1scy is now ~30us (porevious ~60us) (see Attachment 2)

I am looking at the cavity lock of TEM00 and I have witnessed no glitch any more.
In fact, the OSEM signals have no glitch. (see Attachment 3)

We still have c1mcs having regularly time-over. Can I remove the WFS->OAF connections temporarily?

I worked on the CDS related stuffs for LSC yesterday and today.

1. Slow machines:

I checked the database files for c1iscaux and c1iscaux2 (slow machines). They are mainly
used for the control of LSC whitening filters. The channel names were totally random as we
reconfigured the RF PDs while the channel names had been unchanged.

- Now the database was modified so that the PD name and the channels are related.
- saverestore.req and autoBurt.req were also changed accordingly.

- PD interface channels are completely random. Don't use them.
- I found the whitening of DCPDs are not effective.

- We need to clean up /cvs/cds/caltech/target directory. The autoBurt requests in the old targets
are making unnecessary burt files.

2. LSC screens

- The channel names on the LSC OVERVIEW screen was modified. (Attachment 1)
- A new LSC Whitening screen was made. (Attachment 2)

3. LSC screen generator

To touch the main LSC screen is very tough. The screen was split in to several sub screens
and combined with a command.

/opt/rtcds/caltech/c1/medm/c1lsc/master/generateLSCscreen/generateLSCscreen.py

This command combines the multiple adl files into a single file with x&y offsets.
This way, you can work with the each section of the screen.
Also, moving the blocks are just easy.

4. LSC Code Bug?

During the screen making, I found that a couple of the whitening switches are not
working properly. e.g. When AS165 (either I or Q) FM1 is activated throught the whitening trigger,
the MSB bit (bit15) of the binary I/O (C1:LSC-BIO_0_0) does not .

SImilarly ASDC FM1 does not toggle bit15 of C1:LSC-BIO_0_1.

The other channels seems OK.

At first, I thought this is a bug of "Bit2Word" block. But an individual test of the block showed that
the block is not guilty. So why is only Bit15 malfunctioning???

In order to unify the theme for MEDM screens, I'll have to make many combinations of rectangles, polygons, and invisible related-screen buttons.
Everytime I change the size of the block, I have to modify the size of this combination. It is impossile for me.

So, I made a script to replace a certain type of rectangles with a combination of the objects with the same (or related) size.

The script is here (so far)

/opt/rtcds/caltech/c1/medm/c1lsc/master/generateLSCscreen/rect_replace.py

Usage:

cat C1LSC_OVERVIEW_ADC.adl | ./rect_replace.py > tmp.adl

Description:

The script takes stdin and spits the result to stdout. It parses a given ADL file. When a "rectangle" object
with Channel A with a string "REPLACE_XXXX", it replaces it with the objects predefined as "XXXX".

So far, there is only "TYPE1" for the predefinition. It actually takes another argument to specify the
path of the related screen to open when the block is clicked. The path should be filled in "Channel B"
slot of the original rectangle. (See Attachment 1)

The "TYPE1" style has the function calls as indicated below. place_rect is to place a rectangle object. You can
specify the filling method and color. place_rel_disp is to place an invisible button with the link to the specified
path by strOpt. place_polygon places a polygon. The cordinate array for the polygon is described with
the relative positions from the specified position.

        place_rect(rect_x-4,         rect_y-4,        rect_w+7, rect_h+7, "outline",  0) # outline white box
        place_rel_disp(rect_x, rect_y, rect_w, rect_h, strOpt, 0, 14)                    # invisible button
        place_rect(rect_x,           rect_y,          rect_w,   rect_h,   "fill",     3) # main gray box
        place_rect(rect_x+3,         rect_y,          rect_w-6, 3,        "fill",     0) # top white rim
        place_rect(rect_x,           rect_y,          3,        rect_h-3, "fill",     0) # left white rim
        place_rect(rect_x+rect_w-3 , rect_y,          3,        rect_h,   "fill",    10) # right gray rim
        place_rect(rect_x,           rect_y+rect_h-3, rect_w-3, 3,        "fill",    10) # bottom gray rim
        place_polygon(rect_x+rect_w-3,rect_y,3,3, "fill",  0, [[0,0],[2,0],[0,2],[0,0]]) # top-right white triangle
        place_polygon(rect_x,rect_y+rect_h-3,3,3, "fill",  0, [[0,0],[2,0],[0,2],[0,0]]) # bottom-left white triangle


Yesterday evening I inspected at IMC servo as a preparation of the CM servo recommissioning.

More details to come.

What a such long pain we suffered.

After more than three years from Kiwamu's discovery, the PDH box 50kHz oscillation issue was finally solved.

This "weird peak at 50kHz" was caused by the oscillation of the voltage regulator (ON's MC7912).
As it imposed common noise almost everywhere, it screwed up transfer function measurements
like EricQ saw recently.

The negative voltage regulator (79XX) tends to get unstable than the positive counter parts (78XX).

The oscillation was removed by adding 22uF electrolytic capacitor between the output pin (pin3) and the ground pin (pin1) of MC7912.
This is indeed more than 20 times of the specification you can find in the data sheet.

In order to accomplish CARM control with the PSL laser frequency, we use two actuators.

One is the longitudinal direction of one of the MC mirrors. The londitudinal motion of the MC induces
the laser frequency control via the MC servo. As we move the mirror, the range is sort of big,
but the BW is limited by the mechanical response.

The other is the additive offset path. We inject a signal to the additional input port of the MC.
The MC servo supresses this injection by giving the same amount but oppsite sign offset to
the error signal (before the addtion of the inputs). The bandwidth of this AO path is limited
by the bandwidth of the MC servo. Basically the BW of the AO path is about 1/10 of that of the MC servo.

In order to confirm the capability of the AO path as a frequency actuator, 1) OLTF of the MC servo
2) TF of the AO input to the servo error was measured.

Attachment 1 shows the openloop TF of the MC servo. The UGF seems just little bit higher than
100kHz. The OLTF is empirically modelled by LISO as seen in the figure.

Attachment 2 shows the TF from the additive input (In2) to the error monitor (MC Servo module Q error mon).
The gain setting of the MC servo box was: In1 +18dB, In2 0dB. The measured TF has arbitorary gain 
due to the gain setting, the measuemrent data was multiplied by 4 to mach the DC value to the unity.
This is to compare the measurement with the prediction from the OLTF.

The AO path TF is expected to show the character of -G/(1+G) where G is the OLTF. In my case,
G = 0.75*OLTF showed the best maching. There might have been some misalignment of the MC
upon the AO path measurement as I found after the measurement.

From the plot , we can see that the response is flat up to 20kHz. Above that it rapidly raises.
This should be dealt with the CM servo filter as the bump may hit the unity gain. Since we have to use
strong roll off to avoid the bump, this will eat the phase margin at low frequency.

In the case that we don't like this bump:
This bump is caused by low phase mergin of the OLTF at 30~40kHz. If the total gain
is increased, the bump is reduced. Or, we can decrease the PZT loop gain in order to
reduce the dip at the crossover ferquency between the PZT and PC loops. In both cases,
the PC path suffers more actuation. We may need to think about the HV actuation option
for the PC (Apex PA85).

Well, let's see how the CM servo can handle this.
The key point here is that we have enough data to start the design of the CM servo.

OK, the next question will be "why the loop bandwidth is so miserable?"
In other words, what is preventing us to have the bandwidth of 20~30kHz?
Your breaking down will give us the answer.

According to the measurement by Eric, the X-arm green PDH UGF is too low. We still have some room to increase the gain.

The out of loop stability of the ALS for each arm should be measured everyday.
Otherwise we can't tell whether the arm is prepared for advanced locking activities or not.

We expect to see the arm stablity of ~50pm_rms for the Y arm and ~150pm_rms for the X arm.

rect_replace.py script was updated.
This sounds crazy but it was actually quite easy as I could use a free font data.

/opt/rtcds/caltech/c1/medm/c1lsc/master/generateLSCscreen/rect_replace.py

Usage:

cat C1LSC_OVERVIEW_ADC.adl | ./rect_replace.py > tmp.adl

Description:

The script takes stdin and spits the result to stdout. It parses a given ADL file. When a "rectangle" object
with Channel A with a string "REPLACE_XXXX", it replaces it with the objects predefined as "XXXX".

Now new type "CHAR" (i.e. REPLACE_CHAR) was added. This replaces the string in Channel B slot
into 5x7 dot matrix representation of the string with the specified color. The dot size is derived from the
height of the original rectangular object.

Looks good.

Once the control cable (bakplane cable) is identified, we can install the module to the LSC analog rack.

We should be able to test the CM servo with either POX or POY and only one correspoding arm without modifying the servo TF.
Just for this test, we don't need to use MCL.

Now the module is inserted at the 2nd crate from the top of 1Y2 (LSC analog rack). It is next to the DCPD whitening module.

I found the backplane cable for the Common Mode servo module.
I traced a cable form XY220 at the right most module on the crate where iscaux2 is living.
This cable was connected to the upper backplane connector.

Switching of the module is tested. All the switches and gain control are doing their job.

It was found that the offset and slow readback are not responding.
I checked the schematic of the CM servo module (D040180).
It seems that there is another cable for the offset and read back voltages.

I found another backplane cable for the CM servo module. It is plugged to the module now.

I can see that C1:LSC-CM_SLOW_MON is responding to C1:LSC-CM_REFL_OFFSET.
But C1:LSC-CM_SUM_MON and C1:LSC-CM_FAST_MON are not replated to the given offset.
I probably need to check the cross connects.

I worked on the mitigation of c1mcs time-over issue this afternoon.

The timing for the c1mcs is successfully reduced from >60us to 45us.

The previous models are svned in redoubt as follows:

MCS rev. 6696
RFM rev. 6697
IOO rev. 6698

What I changed was:

- Remove connection from ALS (on c1ioo) to MCS (on c1sus). This should be all done in LSC. (# of RFM IPC in MCS -1)

- MC2 trans QPD filters are moved from IOO to MCS to reduce the RFM channels in MCS.
  Previously the signals for the 4 segments are sent. Now the processed siganls (pit/yaw/sum) are sent. (# of RFM IPC in IOO -1, MCS -1)

- WFS MC3 feedback channels are moved from MCS to RFM to distribute the RFM channels (# of RFM IPC in MCS -2, in RFM +2)

model    prev. timing[us] current timing[us]  diff in time[us]  diff in ch#
c1mcs         >60                45                -15              -4
c1rfm         47                 53                + 6              +2       
c1ioo         47                 36                -11              -1

Revisions of the new models:
MCS rev. 6702
RFM rev. 6701
IOO rev. 6700

Now netgpibdata is working again.

Usage:

cd /cvs/cds/rtcds/caltech/c1/scripts/general/netgpibdata   
./netgpibdata -i 192.168.113.108 -d AG4395A -a 10 -f meas01
./netgpibdata -i 192.168.113.105 -d SR785 -a 6 -f meas01   

Jenne witnessed and certified that they were working fine.
Now no one can say "it does not work"!

These weeks I was annoyed by the fact that netgpibdata was messed up by dummies.
A terrible situation was found:

1. Someone pushed the factory reset of one of the wifi bridges (LINKSYS WET54G).
2. Someone gave wrong IPs to the bridges (192.168.1.* instead of 192.168.113.*)
3. Someone left a default IP to the bridges. This means the routers had the same IPs.

-------

I gave the IPs to the bridges. According lines of /etc/hosts in linux1 were updated.

192.168.113.230 WET54G1
192.168.113.231 WET54G2

All of the network settings are taped on the bridge now.
The reset switch of each bridge was covered by a tape so that dummies can't randomly push the button.

The command was tested with each device.

A while ago, I noticed that the most significant bits of the LSC whitening DOs are not toggling.
I track this issue down and found what is happening. I need experts' help.

To illuminate the issue, terminators are connected to Bit15 of the Bit2Word blocks in the LSC model (attached screen shots).

The corresponding source file is found in c1lsc.c at the following location.
The last channels of the Bit2Word are connected to lsc_cm_slow (the filter module).
This is the source of the issue. This wrong assignment of the connections
can't be changed by connecting Go-From tags to the chennels.

/opt/rtcds/caltech/c1/rtbuild/src/fe/c1lsc/c1lsc.c

3881// Bit2Word:  LSC_cdsBit2Word1                                                                                                              
3882{
3883double ins[16] = {
3884        lsc_as110_logicaloperator4,
3885        lsc_as110_logicaloperator1,
3886        lsc_refl11_logicaloperator4,
3887        lsc_refl11_logicaloperator1,
3888        lsc_pox11_logicaloperator4,
3889        lsc_pox11_logicaloperator1,
3890        lsc_poy11_logicaloperator4,
3891        lsc_poy11_logicaloperator1,
3892        lsc_refl33_logicaloperator4,
3893        lsc_refl33_logicaloperator1,
3894        lsc_pop22_logicaloperator4,
3895        lsc_pop22_logicaloperator1,
3896        lsc_pop110_logicaloperator4,
3897        lsc_pop110_logicaloperator1,
3898        lsc_as165_logicaloperator4,
3899        lsc_cm_slow
3900};
3901lsc_cdsbit2word1 = 0;
3902for (ii = 0; ii < 16; ii++)
3903{
3904if (ins[ii]) {
3905lsc_cdsbit2word1 += powers_of_2[ii];
3906}
3907}
3908}

3946// Bit2Word:  LSC_cdsBit2Word2                                                                                                              
3947{                                                                                                                                           
3948double ins[16] = {                                                                                                                          
3949        lsc_as55_logicaloperator4,                                                                                                          
3950        lsc_as55_logicaloperator1,                                                                                                          
3951        lsc_refl55_logicaloperator4,                                                                                                        
3952        lsc_refl55_logicaloperator1,                                                                                                        
3953        lsc_pop55_logicaloperator4,                                                                                                         
3954        lsc_pop55_logicaloperator1,                                                                                                         
3955        lsc_refl165_logicaloperator4,                                                                                                       
3956        lsc_refl165_logicaloperator1,                                                                                                       
3957        lsc_logicaloperator_cm_ctrl,                                                                                                        
3958        ground,                                                                                                                             
3959        ground,                                                                                                                             
3960        lsc_logicaloperator_popdc,                                                                                                          
3961        lsc_logicaloperator_poydc,                                                                                                          
3962        lsc_logicaloperator_poxdc,                                                                                                          
3963        lsc_logicaloperator_refldc,                                                                                                         
3964        lsc_cm_slow                                                                                                                         
3965};                                                                                                                                          
3966lsc_cdsbit2word2 = 0;                                                                                                                       
3967for (ii = 0; ii < 16; ii++)                                                                                                                 
3968{                                                                                                                                           
3969if (ins[ii]) {                                                                                                                              
3970lsc_cdsbit2word2 += powers_of_2[ii];
3971}
3972}
3973}

up/down scripts are to be made

(Offset Edit on Dec 20 10:38PM)

Configuration:
POY11QMon -> CM Servo In1 -> CM Servo -->Out1 -> ADC -> CM Slow FM -> LSC MC Servo FM -> ETMY(x1.0) -> DAC -> ETMY
                                       |
                                       -->Servo Out -> SR560 (DC, 1st order 30kHz LPF) -> MC In2

Lock acquisition path 1


Initial condition:

CM Slow FM:

• Gain 2.6

CM Servo setting:

• In1 Gain 31dB, SW:OFF, Offset -1.880, Boost Off, Super Boost Off, AO +8dB

MC Servo setting:

• In2 10dB, SW:OFF

Acquisition:

• Engage LSC
• LSC MC servo gain +0.1, FM7/FM10 (Trigger FM2 with 3sec delay)
• Turn on MC

Transition:

• Enable AO path (CM servo In1 SW:ON, MC servo In2 SW:ON)
• LSC MC gain +0.1 -> +0.2
• AO path gain 8dB->14dB
• LSC MC gain +0.2 -> +0.35
• AO path gain 14dB->18dB
• CM servo offset -1.88 -2.7 -> 0.8 0.0 (gradually)
• Enable CM servo Boost

Lock acquisition path 2

Initial condition:

CM Slow FM:

• Gain 2.6

CM Servo setting:

• In1 Gain 31dB, SW:OFF, Offset -1.880, Boost Off, Super Boost Off, AO +20dB

MC Servo setting:

• In2 10dB, SW:OFF

Acquisition:

• Engage LSC
• LSC Yarm G=+0.25 FM4/5 (Trigger FM3/6/7/8)

Transition:

• Enable MC servo In2 (SW:ON)
• Set LSC MC gain +0.2 FM7/10
• Enable LSC MC (On)
• Enable CM servo In1 (SW:ON)
• Disable LSC Yarm (OFF)
• Change CM servo offset -1.88 -> +0.700 -2.70 -> 0.0
• Enable CM servo Boost
• Turn on LSC CM FM2 (optional)

Transition to ETMY LSC to MCL

• After all of the transition: LSC output matrix ETMY (+1.00)
• LSC output matrix MC2 (-1.00)
• LSC output matrix ETMY (0.00)

This too huge offset difference with/without "BOOST" switch should be checked.

The bug is still there but the incorrect bits are now overridden.

I checked the offset situation in the CM servo boost circuit. 

- The offset voltage on the CM servo screen is a raw DAC output. This number is diluted by the voltage divider before the amplifier.
  So, the actual offset of the boost circuit was much smaller. (~20mV)

- There is a offset trimmer on the board. This was adjusted so that the boost does not generate an output offset.

- So the default offset is 0V.

- When the arm was locked with (digital) POY11, the CM servo offset is necessary to be -2.7 (now).
  This means that analog POY11Q and digital POY11 has different offset for the best resonance transmission.
  That is believable if POY11I is contributing to the digital POY11 signal.

I'm leaving the 40m now. IFO is aligned. Everything look good.

- The main volume P1=5e-4, CC1=1.4e-5 is still pumped by TP1 and TP2

- RGA P4<0e-4, CC4 2.1e-7, is pumped by TP3

- The annuluses are isolated.

- RP1/2/3 are off.

The previous LSC whitening filters for the DCPDs were in an unknown state (although the transfer functions were actually measured and fit a while ago)
They had no DC gain control and some of the channels had modifications.

To make the setup clear, the filter module was replaced with the spare module without any modification.

The channels are now respoding to the whitening gain switches. So far there is no screen for the new  whitening gains yet.

Also I found that POX11 DC cable has not been connected. Now it is connected.

Dec 22 between 6AM and 7AM, physical or logical failure has occure on the 4th disk in the RAID array on linux1.
This caused the RAID disk fell into the readonly mode. All of the hosts dependent on linux1 via NFS were affected by the incident.

Today the system has been recovered. The failed filesystem was restored by copying all of the files (1.3TB total) on the RAID to a 2TB SATA disk.
The depending hosts were restarted and we recovered elog/wiki access as well as the interferometer control system.

Recovery process

o Recover the access to linux1

- Connect an LCD display on the host. The keyboard is already connected and on the machine.
- One can login to linux1 from one of the virtual consoles, which can be switched by Alt+1/2/3 ...etc
- The device file of the RAID is /dev/sda1
- The boot didn't go straightforward as mounting of the disks accoding to /dev/fstab doesn't go well.
- The 40m root password was used to login with the filesystem recovery mode.
- Use the following command to make the editing of /etc/fstab available

# mount -o rw, remount /

- In order to make the normal reboot successfull, the line for the RAID in /etc/fstab needed to be commented out.

o Connect the external disk on linux1

- Brought a spare 2TB SATA disk from rossa.
- Connect the disk via an USB-SATA enclosure (dev/sdd1)
- Mount the 2TB disk on /tmpdisk
- Run the following command for the duplication

# rsync -aHuv --progress /home/ /tmpdisk/ >/rsync_KA_20131229_0230.log

- Because of the slow SCSI I/F, the copy rate was limited to ~6MB/s. The copy started on 27th and finished 31st.

o Restart linux1

- It was found that linux1 couldn't boot if the USB drive is connected.
- The machine has two SATA ports. These two are used for another RAID array that is not actually used. (/oldhome)
- linux1 was pulled out from the shelf in order to remove the two SATA disks.
- The 2TB disk was installed on the SATA port0.
- Restart linux1 but didn't start as the new disk is recognized as the boot disk.
- The BIOS setting was changed so that the 80GB PATA disk is recognized as the boot disk.
- The boot process fell into the filesystem recovery mode again. /etc/fstab was modified as follows.

- Another reboot make the operating system launched as usual.

o What's happen to the RAID?

- Hot removal of the disk #4.
- Hot plug of the disk #4.
- Disk #4 started to get rebuilt -> ~3hours rebuilding done
- This made the system marked as "clean". Now the raid (/dev/sdb1) can be mounted as usual.

o Nodus

- Root password of nodus is not known.
- Connect an LCD monitor and a Sun keyboard on nodus.
- Type Stop-A. This leads the nodus transition to the monitor mode.
- Type sync.
- This leads the system rebooted.

IFO restart after the recovery of linux1

Machine recovery in the following order
- Start fb
- Start the following machines: mafalda, megatron, op340m
- Start c1ioo, c1lsc, c1sus, c1iscex, c1iscey

CDS recovery / burtrestore

- Confirm all of the RT systems are running in "green". If not, restart corresponding model.
- c1iscaux, ciscaux2 didn't have response (white boxes). Went to the LCS digital rack and power cycled these targets
- burtrestore: The snapshots at Dec 19 05:07 were used. For c1iscaux and c1iscaux2 the snapshots at Dec 22 05:07 were used.

fast machines
c1alsepics.snap
c1assepics.snap
c1asxepics.snap
c1calepics.snap
c1iooepics.snap
c1lscepics.snap
c1lspepics.snap
c1mcsepics.snap
c1oafepics.snap
c1pemepics.snap
c1rfmepics.snap
c1scxepics.snap
c1scyepics.snap
c1spxepics.snap
c1supepics.snap
c1susepics.snap
c1tstepics.snap

slow machines
c1auxex.snap
c1auxey.snap
c1aux.snap
c1iool0.snap
c1iscaux2.snap
c1iscaux.snap
c1psl.snap
c1susaux.snap

IFO recovery

- Reload watchdogs => restore sus damping
- MC misaligned but TEM00 was locked
- Gave a small touch on MC2 yaw => IMC almost aligned
- Autolocker wasn't running => Manually launched rather than wait for an hour for cron to launch it
- PMC was largely misaligned. => Aligned on the PSL table (PSLTRANS 0.640->0.753)
- MC WFS ON
- IFO X/Y arm locked and aligned with ASS.
- PRMI mode: manually aligned PRM. The PRMIsb momentally locked.

We probably need to restart the machine, but I didn't want to touch c1vac1 and c1vac2. 

Since this configuration change, the daily backup was speeded up by factor of more than two.
It was really limited by the bandwidth of the RAID array.

/cvs/cds/rtcds/caltech/c1/scripts/backup/rsync.backup.cumlog:

...
rsync.backup start: 2013-12-20-05:00:00, end: 2013-12-20-07:04:28, errcode 0
...
rsync.backup start: 2014-01-05-05:00:00, end: 2014-01-05-05:55:04, errcode 0

(The daily backup starts from 5:00)

In order to activate the slow actuator servo for the MC locking,
the threshold level for this servo (C1:PSL-FSS_LOCKEDLEVEL) was changed from 10000 to 700.

Now the servo started to move the PZT fast out to be controlled to 5V.

[Steve Koji]

We pushed the reset button of c1vac1 and c1vac2 and the vacuum screen is back.

First, we pushed the reset button of c1vac1 and pushed the one on c1vac2.
This did not bring c1vac2 up. We pushed the reset of c1vac2 again and now everything of the vacuum screen is back.

[Koji EricQ]

The both arms have been locked with IR and aligned by ASS.

The IFO was left with ITMX/Y, ETMX/Y, BS, and PRM aligned, and the PSL shutter closed.

YARM
SIGNAL PATH: POY11I(+45dB)->YARM(G=+1.0)->ETMY
NORM: TRYx10
TRIG: TRY 0.01up/0.005down
FM TRIG: FM2/3/6/7/8/9 0.01up/0.05down, 0.5 sec delay

XARM
SIGNAL PATH: POX11I(+45dB)->XARM(G=+4.0)->ETMX
NORM: TRXx10
TRIG: TRX 0.01up/0.005down
FM TRIG: FM2/3/6/7/8/9 0.01up/0.05down, 0.5 sec delay

For decent locks, it was necessary that the offset of the error signals are trimmed at the input filters
even after running LSCoffset.py script.

Once the cavities were aligned for the IR, we could see the green beams are also flashing.
The Y arm was actually locked with the green with a TEM00 mode

[Rich, Jay, Koji]

We blasted the aLIGO RF PD with a 1W IR beam. We did not find any obvious damage.
Rich and Jay brought the PD back to Downs to find any deterioration of the performance with careful tests.

The power modulation setup is at the rejection side of the PBS in front of the laser source.
I checked the beams are nicely damped.
As they may come back here tomorrow, a power supply and a scope is still at the MC side of the PSL enclosure.

The X arm was also aligned for the IR by hand and ASS. Also the X end green PZT was aligned to make the TEM00 mode reasonably locked.

What I did:

- Looked at the ITMXF camera. It seemed that the green beam was hitting the mirror.

- Went to the end. Looked at the X end green REFL. Tuned coarse alignment of the ETMX so that the beam was (retro-)reflected to the Faraday and the REFL PD.

- Looked at the ETMX face from the view port. Tried to locate the spot from the ITMX by shaking the ITMX alignment with 0.1 and then 0.01 increments.

- After some struggle with the ETMX and ITMX alignment, resonant fringes were found on the ETMY face while I still looked at the ETMX.

- Once the ITMX/ETMX were aligned, the BS needed to be aligned. But of course there was no IR fringe.

- Returned to the original alignment of the ITMX to find the ITMX spot on the AS camera.
Then gradually moved the ITMX to the aligned value for the green while tracking the michelson alignment with the BS.
This made the AS spots at the upper left edge of the AS video image.

- This was enough to find the IR spikes at TRX. Then the ETMX was touched to maximize the transmission.

- Lock the cavity. Use the ASS to optimize the alignement.

- Once the arm mirrors were aligned, the Xend PZT was also adjusted to have TEM00 for the green beam.

Now I leave the IFO with ITMX/Y, ETMX/Y and BS aligned. As I wrote above, the AS spot is very high at the AS camera.
We need to revisit the AS steering (SR TTs?) to ensure the AS beam unclipped.

Manasa, Steve: Please revisit the Xend oven temperature again.

I found that the X end SLOW control was left on for ~15days. The output of the filter had grown to ~2e7.

This yielded the laser temperature pulled with the maximum output of the DAC.

This was the cause of the power reduction of the X end SHG; phase matching condition was changes as the wavelength of the IR was changed.

Once the SLOW output was reset, the green REFL was reduced from 4000cnt to 1800cnt.

• Adjusted the PMC alignment
• Adjusted the IMC length offsets for the MC servo and the FSS servo
• Adjusted the MC alignment. Ran /opt/rtcds/caltech/c1/scripts/MC/WFS/WFS_FilterBank_offsets
 
• The Yarm servo was oscillating. Reduced the servo gain from 0.2 to 0.08.
 
• AS Camera & AS port alignment was adjusted. Now the spot is at the center of the AS camera.
• Cleaned up the ASC offsets on the suspensions (i.e. C1:SUS-***_(PIT|YAW)_OFFSET) by replacing them by the BIAS adjustment.
• Saved the alignment values
• Locked the PRMI with SB with REFL55I for PRCL and AS55Q for MICH
• Aligned the PRM, then checked the alignment of the REFL PDs
• The best POP110I was 500cnt.
• Found REFL165 output was disconnected. It is now restored.
   
• Used the LSC lockins to figure out the demod phases and the signal amplitudes (relative)

PRCL: 100cnt -> PRM 567.01Hz

Signal in demod Q ch were minimized

REFL11I -19.2deg demod I, Lockin I out (C1:CAL-SENSMAT_PRCL_REFL11_I_I_OUTPUT) 12.6 cnt
REFL33I +130.4deg 1.70cnt
REFL55I +17.0deg 2.30cnt
REFL165I -160.5deg 27.8cnt

MICH: 1000cnt -> ITMX(-1) & (ITMY +1.015 => Minimized the signal in REFL11I to obtain pure MICH)

REFL11I   +0.0     REFL11Q   +0.119
REFL33I   +0.023 REFL33Q   -0.012
REFL55I   +0.023 REFL55Q   -0.113
REFL165I +0.68   REFL165Q +0.038

It seems that REFL165 has almost completely degenerated PRCL and MICH.

• Try to replace ITMX/Y with BS (+0.16) / PRM (-0.084)

 ITMX(-1)/ITMY(+1.015) actuation was cancelled by BS (+0.16). This introduces PRCL in REFL11I. This was cancelled by PRM (-0.084)

REFL11I   +0.0     REFL11Q   +0.13
REFL33I   -0.012  REFL33Q   0.025
REFL55I   +0.041 REFL55Q   -0.45
REFL165I +0.69   REFL165Q +/-0.02

Again, It seems that REFL165 has almost completely degenerated PRCL and MICH.

Locking info:

PRCL:
[Signal source] REFL11I (-19.2deg) x 0.16, OR REFL33I (+130.4deg) x 2.0, OR REFL55I (+17.0deg) x1.0, OR REFL165I (-160.5deg) x0.05
[Trigger] POP110I(-81deg) 100/10, FM trigger 35/2, delay 0.5sec FM2/3/6/9
[Servo] FM4/5 always on. G=-0.02, Limitter ON
[Output] PRM x+1.00

MICH:
[Signal source] AS55Q (-5.5deg) x 1, OR REFL11Q x 0.25, OR REFL55Q x-0.06
[Trigger] POP110I 100/10, FM trigger 35/2, delay 5sec FM2/3/9
[Servo] FM4/5 always on. G=-10, Limitter ON
[Output] ITMX -1.0 / ITMY +1.0 (or +1.015), OR PRM -0.084 / BS +0.16

Nice restoration. We eventually want to make transition of the servo part from ALS to LSC model for the further handing off to the other signals.
Please proceed to it.

We usually want to remove PRCL from the Q quadrature for each PD.
Therefore, you are not supposed to see any PRCL in Q assuming the tuning of the demod phases are perfect.
Of curse we are not perfect but close to this regime. Namely, the PRCL in Qs are JUNK.

In the condition where MICH is supressed by the servo, it is difficult to make all of the Qs line up because of the above PRCL junk.
But you shook MICH at a certain freq and the signal in each Q signal was calibrated such that the peak has the same height.
So the calibration should give you a correct sensing matrix.

If you tune the demod phases precisely and use less integrations for MICH, you might be able to see the residual MICH lines up on the Q plot.

Jenne and I noticed high pitch sound from our acoustic interferometer noise diagnostic system.
The frequency of this narrow band noise was 1256Hz, which is enough close to twice of the PRM violin mode freq.
After putting notch filter at 1256+/-25Hz at the violin filters, the noise is gone. Just in case I copied the same filters to all of the test masses.

Later, I found that the 4th violin modes are excited. Additional notch filters were added to "vio3" filter bank to mitigate the oscillation.

As I didn't have the green laser PZT feedback for the laser temp control, I went to the yend to check out what's the situation.

I found horrible and disgusting "remnants".

WHAT ARE THESE BSs AT THE Y END?

- The table enclosure was left open

- A (hacky) DB25 cable with clips was blocking the corridor and I was about to trip with the cable.

- This DB25 cable went to the table without going through the air tight feedthrough that is designed for this purpose.

- An SR560 (presumably for the openloop TF measurement) was left inserted in the loop with entangled cables connected to the servo box.

- Of course the laser PZT out mon was left unplugged.

Even after cleaning these cables (a bit), the end setups (including the X end too) are too amature.
Everything is so hacky. We should not allow ourselves to construct this level of setup everytime
we work on any system. This just adds more and more mysteries and eventually we can't handle
the complexity.

I wanted to try common/differential ALS Friday evening. I tried ALS using the LSC servo but this was not successfull.
The usual ALS servo in the ALS model works without problem. So this might be coming from the shape of the servo filter.
The ALS one has 1:1000 filter but the LSC one has 10:3000. Or is there any problem in the signal transfer between
ALS and LSC???

- MC:
Slow offset -0.302V

- IR:
TRX=1.18 / TRY=1.14, XARM Servo gain = 0.25 / YARM Servo gain = 0.10

- Green Xarm:
GTRX without PSL green 0.562 / with PSL green 0.652 -> improved upto 0.78 by ASX and tweaking of PZTs
Beat note found at SLOW OFFSET +15525
Set the beat note as +SLOW OFFSET gives +BEAT FREQ

- Green Yarm:
GTRY without PSL green 0.717 / with PSL green 1.340
Beat note found at SLOW OFFSET -10415
Set the beat note as +SLOW OFFSET gives -BEAT FREQ

- BEAT X -10dBm on the RF analyzer@42.5MHz / Phase tracker Qout = 2300 => Phase tracking loop gain 80 (Theoretical UGF = 2300/180*Pi*80 = 3.2kHz)
- BEAT Y -22dBm on the RF analyzer@69.0MHz / Phase tracker Qout = 400 => Phase tracking loop gain 300 (Theoretical UGF = 2.1kHz)

Transfer function between ALSX/Y and POX/Y11I @560Hz excitation of ETMX
POX11I/ALSX = 54.7dB (~0deg)
POY11I/ALSY = 64.5dB (~180deg)

POX11I calibration:

ALSX[cnt]*19230[Hz/cnt] = POX11I[cnt]/10^(54.7/20)*19230[Hz/cnt]
= 35.4 [Hz/cnt] POX11I [cnt] (Hz in green frequency)

35.4 [Hz/cnt]/(2.99792458e8/532e-9 [Hz]) * 37.8 [m] = 2.37e-12 [m/cnt] => 4.2e11 [cnt/m] (c.f. Ayaka's number in ELOG #7738 6.7e11 cnt/m)

POY11I calibration:

ALSY[cnt]*19230[Hz/cnt] = POY11I[cnt]/10^(64.5/20)*19230[Hz/cnt]
= 11.5 [Hz/cnt] POX11I [cnt] (Hz in green frequency)

11.5 [Hz/cnt]/(2.99792458e8/532e-9 [Hz]) * 37.8 [m] = 7.71e-13 [m/cnt] => 1.3e12 [cnt/m] (c.f. Ayaka's number in ELOG #7738 9.5e11 cnt/m)

Hmm. Wierd. Can you look at the TFs between ETMX-EXC and the error signals so that we can identify which one has these structures.

Great. I indeed disabled all of the triggers and the normalization during my trial but in vain.
So I'm curious this is actually because of the filter shape or not.

We need to correctly setup crontab or rc.local for the frontend machines.

I wanted to check how the refl signals looked like.
I decided to measure the demod phase where PRCL and MICH appear, one by one.

The method I used is to actuate PRCL or MICH at a fixed frequency and rotate the demod phase such that
the signal at the actuating frequency disappears.

For the PRCL actuation, PRM was actuated by the lock-in oscillator with the amplitude of 100cnt.
For MICH, the ITMX and ITMY was actuate at the amplitude of 1000cnt and 1015cnt respectively.

The script I used was something like this

ezcaread C1:LSC-REFL11_PHASE_R
ezcaservo -r C1:CAL-SENSMAT_CARM_REFL11_Q_I_OUTPUT C1:LSC-REFL11_PHASE_R -g 100 -t 60
ezcaread C1:LSC-REFL11_PHASE_R

"11" should be changed according to the PD you want to test.
"Q" should be changed to "I" depending on form which quadrature you want to eliminate the signal

The option "-g" specifies the servo gain. This specifies which slope (up or down) of the sinusoidal curve the signal is locked.
Therefore, it is important to flip the signal angle 180degree if a negative gain is used.

Note: Original phase settings before touching them

REFL11  - 19.2
REFL33   135.4
REFL55    48.0
RELF165 -118.5

Here in the measurement PRMI was locked with AS55Q (MICH) and REFL55I (PRCL)


Without no serious reason I injected a peak at 503.1Hz. This peak is not notched out by the servo. There may have been
some residual effect of the feedback loops.

PRCL: By elliminating the peak from the Q quadrature, we optimize the I phase for PRCL.

REFL11,   minimize PRCL in "Q", gain, -1, -19.3659 deg
REFL33,   minimize PRCL in "Q", gain, -1, 132.813 deg
REFL55,   minimize PRCL in "Q", gain, -1, 20.9747 deg
REFL165, minimize PRCL in "Q", gain, -1, -119.004 deg

MICH: By elliminating the peak from the I quadrature, we optimize the Q phase for MICH.
If PRCL and MICH appears at the same phase, the resulting angles shows an identical number.

REFL11,   minimize PRCL in "I", gain, -1, -28.4526 deg
REFL33,   minimize PRCL in "I", gain, -1, 65.9148 deg
REFL55,   minimize PRCL in "I", gain, -1, 12.4051 deg
REFL165, minimize PRCL in "I", gain, -0.1, -143.75 deg

Then, the signal frequency was changed to 675Hz where the notch filters in the servo is active.

PRCL: By elliminating the peak from the Q quadrature, we optimize the I phase for PRCL.

REFL11,   minimize PRCL in "Q", gain, 1, -19.5224 deg
REFL33,   minimize PRCL in "Q", gain, -1, 135.868 deg
REFL55,   minimize PRCL in "Q", gain, 1, 48.5716 deg
REFL165, minimize PRCL in "Q", gain, 1, -122.398 deg

MICH: By elliminating the peak from the I quadrature, we optimize the Q phase for MICH.
If PRCL and MICH appears at the same phase, the resulting angles shows an identical number.

REFL11,   minimize PRCL in "I", gain, -10, -73.7153 deg
REFL33,   minimize PRCL in "I", gain, -10, 135.5 deg
REFL55,   minimize PRCL in "I", gain, 10, -2.55868 deg
REFL165, minimize PRCL in "I", gain, -5, -156.135 deg

This is just a test of the REFL channels for the arms signals. ETMX or ETMY were actuated.

YARM

REFL11, minimize ETMY in "Q", gain 100 => C1:LSC-REFL11_PHASE_R = 145.694
REFL55, minimize ETMY in "Q", gain 100 => C1:LSC-REFL11_PHASE_R = -60.1512

XARM

REFL11, minimize ETMX in "Q", gain 100 => C1:LSC-REFL11_PHASE_R = 142.365
REFL55, minimize ETMX in "Q", gain 100 => C1:LSC-REFL55_PHASE_R = -68.6521

Successful PRMIsb locking with REFL165I/Q

My previous entry suggested that somehow the REFL165 signals show reasonable separation between PRCL and MICH, contrary to our previous observation.
I don't know what is the difference now. But anyway I took this advantage and tried to lock sideband resonant PRMI.

REFL165I was adjusted so that the signal is only sensitive to PRCL. Then REFL165I and Q were mixed so that the resulting signal shows.
(Next time, we should try to optimize the Q phase to eliminate PRCL and just use the I phase for PRCL.

At first, I used AS55Q for lock acquisition and then switched the MICH input matrix to REFL165.
Later I found that I can acquire PRMI just turning on AS55Q without turning off REFL165.

The REFL165 MICH signal had an offset of 15cnt. The lock was more robust and the dark port was darker once the MICH input offset was correctly set.

MICH OFS = 0
Turn on AS55Q only / or AS55Q + REFL156I/Q
Once it is locked and all of the FMs are activated, give -15.0OFS to MICH.
Turn off AS55Q.

Input ports:
AS55       WHTN: 21dB  demod phase -5.5deg
REFL165 WHTN: 45dB demod phase -156.13deg

Input matrix:
AS55Q x1.00 MICH
REFL165I x-0.035 + REFL165Q -0.050 MICH

REL165Q x+0.14

Triggers:
MICH POP110I 100up/10down / FM Trig FM2/3/6/7/9 35up 2down 5sec delay
PRCL POP110I 100up/10down / FM Trig FM2/3/6/9 35up 2down 0.5sec delay

Servo:
MICH OFS -15.0 / Gain -10 / Limitter ON
PRCL OFS 0 / Gain -0.02 / Limitter ON

Output matrix:
MICH ITMX -1.0 / ITMY +1.0
PRCL PRM 1.0

Step by step description of transition from 2arm ALS to Common/Differential LSC for FPMI

- Step 0: Place the frequencies of the arm green beams at the opposite side of the carrier green.

- Step 1: Activate stablization loops for ALSX and ALSY simultaneously.
  (Use LSC filter modules for the control. This still requires correct handling of the servo and filter module triggers)

- Step 2: Activate stablization loops for ALS Common and Differential by actuating ETMX and ETMY

- Step 2 (advanced): Activate stabilization loops for ALS Common by actuating MC2 and ALS Differential by ETMX and ETMY

- Step 3: Transition from ALS Common to 1/SQRT(TRX)+1/SQRT(TRY). Make sure that the calibration of TRX and TRY are matched.
  The current understanding is that the offset for 1/SQRT(TRX)+1/SQRT(TRY) can't be provided at the servo filter. Figure out
  what is the correct way to give the offsets to the TR signals.

- Step 4: Lock Michelson with AS55Q and then POP55Q (PD not available yet) or any other PD, while the arms are kept off-resonant using ALS.

- Step 5: Reduce the TR offsets. Transition to RF CARM signals obtained from POP55I or REFL11I in the digital land.

- Step 5 (advanced): Same as test6 but involve the analog common mode servo too.

- Step 6: Transition from ALS Differential to AS55Q

Independent test: One arm ALS (To be done everyday)

- ALS resonance scan

- Measurement of out-of-loop displacement (or frequency) stability 

- Check openloop transer function

Independent test: Common Mode servo for one arm

- Reproduce Decmber CM servo result of transition from one arm ALS to CM servo
  Insert 1/sqrt(TRY) servo in between?

- How can we realize smooth transition from ALS to POY11?