The new HEPA speed controllers are attached at the middle of the HEPA unit (not at the edge of the unit)... (Attachment 1)
You still need a step./stool to touch the knob and need a ladder for a more precise setting.

We still don't know the optimal speed of the nominal IFO operation. For now, the HEPAs are running at the max speed (Attachment 2).
Once we know the optimal setting, we mark the knobs so that we can see them only with the step.

When adjusting the blower speed, give the blower at least 30 seconds to speed up or slow down to the set speed.  The flywheel effect of the big motor armature and blower mass requires time to follow the control current.  Note the taller Flanders HEPA filters.  These and the new intake filters should keep the PSL air clean for a long time!

I was a bit surprised by these numbers suggesting the PMC transmission is only 50-60%. I went to the table today and confirmed that it is more like 85% (1.3 W in, 1.1 W transmitted, both numbers from with the FieldMate power meter), as I claimed in 2019. Even being conservative with the power meter errors, I think we can be confident T_PMC will be >80% (modulo any thermal effects with higher power degrading the MM). There isn't any reliable record of what the specs of the PMC mirrors are, but assuming the IO couplers have T=4000ppm and the end mirror has T=500ppm as per Alan's plot, this is consistent with a loss of something like 300ppm loss per mirror - seems very high given the small beam spots, but maybe these mirrors just aren't as high quality as the test masses?

It's kind of unfortunate that we will lose ~20% of the amplifier output through the first filter, but I don't see an easy way to clean these mirrors. It's also not clear to me if there is anything to be gained by attempting a cleaning - isn't the inside of the cavity supposed to be completely isolated from the outside? Maybe some epoxy vaporization events degraded the loss?

Koji mentioned that the mode of the laser is different for lower diode currents. So that might be the reason why we got less transmission at the low input power but more afterward.

According to the aLIGO 70W amplifier interlock concept the flow rate of the chiller should be between 5 and 40 l/min. The chillers I found in the TCS lab both have around 15 l/min flow rate so we should be fine in that regard.

Assuming that the power consumption of the diode box is ~800W and that the optical output power of the diode is ~ 300W of optical power, the chillers need to be able to remove the remaining power. At room temperature, they both have enough cooling capacity according to their specs.

As for the idea to put the chiller and diode box in the drill room: There are not a lot of options here. The only viable place is the SW corner (attachment 1). I was told this place is used sometimes for liquid nitrogen dewar. Alternatively, if possible, we can move the fire extinguishers to the SW corner and use the NW corner. In that way, we don't have to clear all the junk from the SW corner, as long as the extinguishers are still accessible.

I made a sketch (attachment 2) showing a possible setup for a diode box + chiller rack. The fiber and network cable can go through the hole in the wall that already exists for the N2. It will have to get bigger though (attachment 3). The rack would also need to host some Acromag unit to convert the communication channel of the chiller/flow meter to Ethernet. The Acromag on 1X7 has no spare channels.

The only power socket in the room, to which the drill is connected, is circuit #36 which is connected to panel L in the lab. The breaker's ampacity seems to be 20A if I'm reading the number on the breaker correctly.

I will upload some plots later - but in summary, I set the HEPA speed to ~40%. I used (i)IMC transmission RIN, (ii) Arm cavity transmission RIN and (iii) ALS beat noise as 3 diagnostics, to see how noise in various frequency bands for these signals change as a function of the HEPA speed. The MC2T RIN shows elevated noise between 1-10Hz at even the lowest speed I tried, ~20% of the max on each blower. The elevated noise extended to ~50-70 Hz for HEPA speeds >40% of the maximum, and the arm cavity RIN and ALS signals also start to become noisy for speeds >60% of the maximum. So I think 40% is a fine speed to run at - for squeezing measurement we may have to turn off the HEPA for 10mins but for the usual single arm / PRMI / DRMI locking, this should be just fine. For the elevated ALS noise - I'm not sure if the coupling is happening over the top of the enclosure where the fiber bringing light from EX comes close to the HEPA filters, or if it is happening inside the PSL enclosure itself, near the beat mouth - but anyways, at the 40% speed, I don't see any effect on the ALS noise.

I checked with a particle counter at the SW corner of the PSL table (which is the furthest away we can be on the table from the HEPA blowers) after leaving the blowers on for ~30mins and it registered 0 for both 0.3um and 0.5um sized particles (if the blowers are off, the respective numbers are 43 and 9 but I forgot what the units were, and I believe they have to be multiplied by 10). 

I have not yet marked the speed control units yet in case there is some other HEPA science that needs to be done before deciding what is the correct setting. But I think I can get the PRFPMI lock without much issue with this lower speed, which is what I will try later today evening.

I believe that there is an internal setting for the minimum flow, so the flow is not linear ("0%" is not zero), but we should mark this flow speed once you find this is sufficiently low for the locking too.

The PSL was too hot, so I turned on the south HEPA on the PSL. The north one was on and the south one was off (or so slow as to be inaudible and no vibration, unlike the north one). Lets watch the trend over the weekend and see if the temperature comes down and if the PMC / WFS variations get less. Fri May 14 17:46:26 2021

The NPRO has been off since ~1AM this morning it looks like. Is this intentional? Can I turn it back on (or at least try to)? The interlock signal we are recording doesn't report getting tripped but I think this has been the case in the past too.

After getting the go ahead from Koji, I turned the NPRO back on, following the usual procedure of diode current ramping. PMC and IMC locked. Let's see if this was a one-off or something chronic.

Looks like the fan lowered the temperature as expected. Need to get a few more days of data to see if its stabilized, or if that's just a fluke.

The vertical line at 00:00 UTC May 18 is about when I turned the fans up/on.

Fluke. Temp fluctuations are as usual, but the overall temperature is still lower. We ought to put some temperature sensors at the X & Y ends to see what's happening there too.

PMC has been unlocked since ~ 2:30 AM. Seems like the PZT got saturated. I moved the DC output adjuster and the PMC locked immidiatly although with a low transmission of 0.62V (>0.7V is the usual case) and high REFL.

IMC locked immidiately but IFO seems to be completely misaligned. The beams on the AS monitor are moving quite alot syncronously. BS watchdog tripped. I enabled the coil outputs. Waiting for the RMS motion to relax...

Its not relaxing. RMS motion is still high. I disabled the coils again and reenabled them. This seems to have worked. Arms were locked quite easily but the ETMs oplevs were way off and the ASS couldn't get the TRX and TRY more than 0.7. I align the ETMs to center the oplev. I realign everything else and lock the arms. Maximium TR is still < 0.8.

{Yehonathan, Anchal}

I went to get a sandwich around 10:20 AM and when I came back BS was moving like crazy. We shutdown the watchdog.

We look at the spectra of the OSEMs (attachment 1). Clearly, the UR sensing is bad.

We took the BS sattelite box out. Anchal opened the box and nothing seemed wrong visually. We returned the box and connected it to the fake OSEM box. The sensor spectra seemed normal.

We connected the box to the vacuum chamber and the spectra is still normal (attachment 2).

We turn on the coils and the motion got damped very quickly (RMS <0.5mV).

Either the problem was solved by disconnecting and connecting the cables or it will come back to haunt us.

[Paco, Yuta]

We have increased the output power from the PSL table to 951 mW (it was 96.7 mW).
IMC was recovered including WFS, and both arms are flashing nicely in IR.
We tweaked the alignment of GRX and GRY injection to align them with IR, but it was hard.
Right now IR beams are not centered on TMs. We should center them first.

What we did:
Power increase and IMC recovery
 - Replaced a beam splitter which splits the beam into IMC REFL RF PD path and WFS path from R=98% to R=10% one. Reflection goes to RF PD.
 - Put a R=98% beam splitter back into WFS path.
 - We also tried to put a window in front of IMC REFL camera to recover the arrangement in 40m wiki, but the beam reflected from the window was too weak for us to align. So, we decided not to place a window in front of the camera.
 - Attached photos are the IMC REFL path before and after the work.
 - Measured the PSL output power as Koji did in elog 40m/16672. It was measured to be 96.7+/- 0.5 mW.
 - Rotated the HWP using the Universal Motion Controller (it was not possible for us to do it from the MEDM screen). The position was changed from 73.99 deg to 36.99 deg. Output power was measured to be 951 +/- 1 mW
 - IMC locked without any other changes.
 - Changed C1:IOO-WFS_TRIGGER_THRESH_ON to 5000 (was 500). IMC WFS also worked.
 - After running MC WFS relief script, WFS DC offsets and RF offsets are adjusted following the steps in elog 40m/16835. Below are the results.

C1:IOO-WFS1_SEG1_DC.AOFF => -0.0008882080010759334
C1:IOO-WFS1_SEG2_DC.AOFF => -0.0006527877490346629
C1:IOO-WFS1_SEG3_DC.AOFF => -0.0005847311617496113
C1:IOO-WFS1_SEG4_DC.AOFF => -0.0010395992663688955
C1:IOO-WFS2_SEG1_DC.AOFF => -0.0025944841559976334
C1:IOO-WFS2_SEG2_DC.AOFF => -0.003191715502180159
C1:IOO-WFS2_SEG3_DC.AOFF => -0.0036688060499727726
C1:IOO-WFS2_SEG4_DC.AOFF => -0.004011172490815322

IOO-WFS1_I1         :  +1977.7 ->    +2250 (Significant change)
IOO-WFS1_I2         :  +3785.8 ->  +3973.2
IOO-WFS1_I3         :  +2014.2 ->  +2277.7 (Significant change)
IOO-WFS1_I4         :  -208.83 ->  +430.96 (Significant change)
IOO-WFS1_Q1         :  +2379.5 ->  +1517.4 (Significant change)
IOO-WFS1_Q2         :  +2260.4 ->  +2172.6
IOO-WFS1_Q3         :  +588.86 ->  +978.98 (Significant change)
IOO-WFS1_Q4         :  +1654.8 ->  +195.38 (Significant change)
IOO-WFS2_I1         :  -1619.9 ->  -534.25 (Significant change)
IOO-WFS2_I2         :  +1610.4 ->  +1619.8
IOO-WFS2_I3         :  +1919.6 ->  +2179.8 (Significant change)
IOO-WFS2_I4         :    +1557 ->  +1426.6
IOO-WFS2_Q1         :   -62.58 ->  +345.56 (Significant change)
IOO-WFS2_Q2         :  +777.01 ->  +805.41
IOO-WFS2_Q3         :  -6183.6 ->  -5365.8 (Significant change)
IOO-WFS2_Q4         :  +4457.2 ->  +4397.

IFO Alignment
 - Aligned both arms using IR. Both arm flashes at the following, which is consistent with the power increase.
 C1:SUS-ETMX_TRX_OUT_DQ ~1.1
 C1:SUS-ETMY_TRY_OUT_DQ ~0.6
 - With this, we tried to tweak GRX and GRY injection. The following is after the work. We could increase GTRX to 0.204 when the Xarm is aligned to green. This suggests that GRX injection is not aligned nicely yet. But the beams are also not centered on TMs. We should center them first.
 C1:ALS-TRX_OUT_DQ ~0.13
 C1:ALS-TRY_OUT_DQ ~0.07
 - GTRX and GTRY cameras are adjusted to have nicer images. In GRX path, the second and last lens before the PD and CCD was pulled ~ 1 cm behind its original position and both beams realigned. Then, on GRY path, the beam was re-centered on the first and only lens, the whole assembly pushed forward by ~ 2 cm and the beams re-centered.

Next:
 - Center the IR beam on TMs (first by our eyeballs; better to use A2L after arm locking is recovered and coils are balanced)
 - Tweak GRX and GRY injection (restore GRY PZTs?)
 - Install ETMXT camera (if it is easy)
 - Lock Xarm and Yarm (C1:LSC-TRX/Y_OUT needs to be fixed for triggering. Can we use other PDs for triggering?)
 - MICH locking (REFL and AS PDs might need to be re-aligned; they are not receiving much light)
 - RTS model for BHD needs to be updated

The commissioners complained about the PMC alignment. The PMC input beam was aligned. It made the transmission improved from 0.72 to 0.74.

FYI: Which steering mirrors do we use for the PMC beam alignment?
The mounts are indicated with the red arrows in Attachment 2.
You have to move these two in common and differential for each pitch and yaw.
The first steering (the right one in the picture) has the beam going through the immediate back of the mount.
So touching the yaw knob of this mount needs some care so that you don't block the PMC refl beam.

[Paco, Tomislav, Yuta]

Somehow, when we were trying to measure WFS open loop transfer functions, PMC unlocked many times for the past two hours and PMC transmission got low.
PMC iput beam was aligned again, and IMC WFS DC offsets and RF offsets were adjusted.
PMC transmission is now C1:PSL-PMC_PMCTRANSPD~0.75, and IMC transmission is C1:IOO-MC_TRANS_SUM~1.4e4.
Actually, IMC transmission once reached 1.5e4 at 06-16-2022 20:01 UTC with PMC transmission of 0.75 (see Attached). There might be a better alignment.

For the PSL HEPA, we wanted it to remain at full speed during the vent, when anyone is working on the PSL, or when there is a lot of dust due to outside conditions or cleaning in the lab.

For NORMAL conditions, the policy is to turn it to 30% for some flow, but low noise.

I think we ought to lock one of the arms on IR PDH and change the HEPA flow settings and plot the arm error signal, and transmitted power for each flow speed to see what's important. Record the times of each setting so that we can make a specgram later

MCAutolocker/FSSSlow are not properly documented and not properly working.
Tidy up the script and documentation, or bring it back to megatron

I was aware that the FSSSlow was misbehaving since the shutdown upon the July power outage.
- FSS Slow servo did nothing even though the apparent settings in C1:PSL_SLOW screen looked fine and heart beat blinking
- Wanted to restart FSSSlow at megatron. Despite the login message showing how to do it, the system service does not exist anymore, because it was moved somewhere.
- Searched 40m wiki but found no info how to kill and restart it
- Found an elog. It was moved to docker on optimus ELOG 16480 . The restart procedure can only be found here. Please fix all the documentation inconsistency >> Anchal

According to this elog, the following commands need to be run for starting up MCAutolocker and FSSSlow on optimus:

cd /opt/rtcds/caltech/c1/Git/40m/scripts/MC
sudo docker-compose up -d

- Problem continues. Now FSSSlow is running but only when the IMC is locked. It does not stop even when the IMC lock is lost. How can we debug docker thing?
- This is minor but the MCAutolocker log (/opt/rtcds/caltech/c1/scripts/MC/logs/AutoLocker.log) is no longer updated even though MCAutolocker is running. Was it moved somewhere?

The FSSSlow script was not properly documented and it was not working, so I had to use one that I knew worked from CTN. This scripts lives in

/opt/rtcds/caltech/c1/Git/40m/scripts/PSL/FSS/PIDLocker.py

and uses a configuration file

/opt/rtcds/caltech/c1/Git/40m/scripts/PSL/FSS/PIDConfigFSS.yml

The script runs all the time inside docker container which keeps it running. The heart-beat blinker shows if the script is active or not, but it only starts working when C1:IOO-MC_LOCK is 1 and C1:PSL-FSS_SLOWLOOP is 1. The second channel is a button on C1PSL_SLOW screen to engage autolocker. It has to be turned on for FSS to work.

docker instructions:

The following message is displayed on login in optimus:

For checking log files of autolocker script, on optimus do:

For checking log files of FSS PID loop, on optimus do:

In the above commands, add < | tail -15> to just see the most recent 15 lines in the log file. change 15 to whatever number of lines you want to see from the end.

At any time, if you want to know how docker is running stuff, check out the /opt/rtcds/caltech/c1/Git/40m/scriptsdocker-compose.yml file for self-explanatory script usage.

I'll add some documentation on the wiki soon. That is indeed required and should have been done already.

Debugging scripts:

All scripts could be debugged by running them on rossa by directly using python command. You can stop the docker container on optimus using:

and then run the file on rossa to check it's behavior. After debugging and fixing any issues, please commit the file to gitlab repo and go back to optimus and restart the docker container:

I'll add this procedure to a wiki page as well.

Reverting back to systemd on megatron

The setup on megatron was not removed at all. All service files exist in same place and old scripts can be started in the old manner by doing following on megatron:

For FSSSlow:

For MC autolocker:

For diabling these services again, do:

Note that one should stop docker containers on optimus before starting these systemd services to avoid conflicting scripts running together.

I have added above instructions on megatron motd. So on loging into megatron, these updated instructions would come.

If someone wants to fix the old scripts and use systemd for managing those scripts, please do so but I won't be able to help in debugging those old scripts. The shell scripts are very complicated and beyond my knowledge and python scripts are lacking documentation.

I'm happy to help debug or extend the functionality of the new scripts that live in the git directory.

> it only starts working when C1:IOO-MC_LOCK is 1 and C1:PSL-FSS_SLOWLOOP is 1.

- OK. Your new MCAutolocker does not reflect the lock status to C1:IOO-MC_LOCK. This causes FSS Slow to go crazy when the IMC is not locked. Can you fix that?

- So C1PSL_SLOW.adl screen, which spawns by the "SLOW Servo" button on the FSS screen, has no effect on the FSS SLOW servo anymore. It is obsolete. At least the screen (or the link to the screen) should be removed. (Work on it once you are back.)

- Also, please make a wiki page and copy the description on the previous page.

Added C1:IOO-MC_LOCK to ALConfigMC.yml which solved the isse with FSS Slow. We should tune the FSS Slow Servo PID coefficients for a better performance.

the C1PSL_SLOW.adl screen is not obsolete. It can be used to change the PID coefficients, engage/disengage the PID loop, monitor the PID script blinker, and monitor FAST actuator value C1:PSL-FSS_FAST. the functionality of this screen has not changed from before.

I've also added a wiki page for scripts documentation.

can't we just go back to the old python script that was working for many years, and tested? I imagine that as soon as someone besides you tries to debug the docker setup, this is what will happen.

I measured the sideband frequencies for PMC and IMC lock (to use it for Mariner PMC and IMC design).

PMC: 35.498912(2) MHz
IMC: 29.485038(2) MHz

Details:
 - Mini-Circuits UFC-6000 was used. The spec sheet says the frequency accuracy in 1-40 MHz is +/- 2 Hz.
 - "29.5 MHz OUT" port of 40m Frequency Generation Unit (LIGO-T1000461) was connected to UFC-6000 to measure IMC sideband frequency.
 - "LO TO SERVO" port of Crystal Frequency Ref (LIGO-D980353) was connected to UFC-6000 to measure PMC sideband frequency.
 - It seems like IMC sideband frequency changed from 29.485 MHz to 29.491 MHz back in 2011 (40m/4621). We are back to 29.485 MHz. I'm not sure what happened after this.

[Yuta, JC, Radhika]

PMC input beam was aligned again, bringing transmission from 0.70 to ~0.75. To avoid blocking the PMC refl beam, I found success handling the yaw knob of the first steering mirror from below.

[JC, Paco]

I attempted to align PMC Beam from a transmission of 0.72. I failed to do so on my own, but Paco arrived and helped me out. Transmission has gone from from 0.72 to ~0.73.

[Paco, Anchal, JC]

C1:PSL-PMC_PMCTRANSPD ~ 0.715 this morning, this was increased to ~0.730. There also seems to be an earthquake going on and the MC is flashing.

C1:PSL-PMC_PMCTRANSPD was increased from 0.72 to 0.731

[JC, Paco, Yuta]

It seems like PMC transmission (C1:PSL-PMC_PMCTRANSPD) dropped to ~0.68 from ~0.74 on Dec 27.
We tried to tweak PZT offset for PMC loop and input alignment to PMC, but PMC transmission didn't increased.
PSL laser temperature was also sweeped in the range 30.3 - 31.6 degC, but didn't help. The PSL temperature was reverted to original 30.61(1) degC.
Power measured at PSL output now is 893 mW (measured at our standard place shown in 40m/16672), which used to be 951 mW in June 2022 (40m/16886).
Power measured at PMC input (see attached photo) now is 1.18 W.

Next:
 - What was the previous PMC input power we had?
 - Sweep PSL laser temperature for larger range

PMC aligned (Attachment #1).
Over the past month, PMC transmission is actually slowly growing from 0.68 to 0.70 (Attachment #2), since it suddenly dropped from 0.72 on Dec 27 (40m/17390).

PMC hit a drop around mid-day on Saturday and has been going down since. As of now,

C1:PSL-PMC_PMCTRANSPD - 0.664

I will go in and adjust now.

This is super! And now is the time to replace the internal fan!

We removed the PSL controller internal (broken) fans after it tripped due to overheat.

Background

[Mayank, Radhika]

While aligning Xarm I noticed sudden loss of beam. On Radhikas suggestion we cheked the PSL and found out that the PSL controller was in off state (No lights on front and back panel). We restored the situation by unplugging and replugging the power cord. The PSL worked fine for a few minutes (~ 30 ) and then tripped again.This time the front panel  OFF light was on . See attached image (Attachment #1).

Fix

[Paco, Mayank, Koji-remote]

We disconnected the PSL controller and took this opportunity to investigate the controller's internal cooling mechanism. After disassembling the top panel of the chassis, we saw there are two SUNON - KD1205PHB2 fans meant to run at 12 VDC (1.7 W) connected to the bottom pcb inside the controller. After disconnecting them from this board, we tested them with an externally supplied dc voltage and confirmed they no longer worked. We noted the cooling mechanism is based on a long aluminum heat sink to which most ICs are attached, and the fans are meant to provide airflow towards the rear aperture on the chassis. We followed Koji's suggestion and for now, removed the damaged components (detailed pictures of this operation have been posted in a google photos album elsewhere) to allow heat to flow out more easily.  We reassembled the controller chassis and reinstalled it with the external fan providing the necessary airflow to prevent the unit from tripping again due to overheating. Then we turned on PSL and recovered PMC and IMC locks.

Aftermath

We took a C1:IOO-MC_F_DQ trace after this work to confirm our earlier findings; the trace is attached in Attachment #2. The noise bumps are present as expected. This is still not a desirable configuration so next step would be replacing the external fan, or even better, find the appropriate spare of the internal units and berid the external one.

We Changed The Fans on the PSL

To start, the part Koji ordered is 259-1818-ND from DigiKey. This is a Maglev fan from SUNON that should give us less noise. We have 3 spare replacement fans in case these go bad which are stored in the ___ Cabinet along the Y arm (This will be updated once I find a suitable storage spot for the part.)

Starting the replacement process.

Removing the PSL 

    1. Our first step to doing this was to prepare for removing PSL. We began by doing a 60s MC WFS Relief. This will allows us to turn off WFS and close the PSL Shutter next. This is to prevent a large kick once we place the PSL back in its place. 
    2. Went to the PSL and mushed the off button and turned the key. After this, begin by removing the external fan which is shown in elog 17595. After, continue by unplugging the cables from the back beginning with the power cable. Attachment #1 shows the original positions of the cables connected before removing any. Keep in mind, DO NOT TO TOUCH THE KNOBS. If the inputs are changed, this will throw off the beatnotes of the AUX lasers.
        a. There is a black plug at the bottom with a screw hat is hard to reach. Be very patient taking this off because the position of the cable blocks a screqwdriver from untightening the screw. 
        b. A second person should be on the other side of the table to push the module back into arm's reach. Also to make sure the module does not slide back and fall. 
    3. After removing the module, bring into the control room and place onnto the workbench. Make sure all of the red lights are off and the PSL table is closed properly.

Changing the Fan 
    
    
    1. We removed the top cover of the module and opened it all up. Similar to what is shown in elog 17452.
        a. Keep in mind to wear a grounding wristband when working on this.
    2. After removing the old fans and attempting to install the new ones, the holes did not line up correctly (Shown in Attachment #2). To accomodate for this, we used 6-32 screws which gave us just enough slack to fit in all 4 corners.
    3. Ones the fans were bolted down onto the aluminum plate, I soldered the cables to connecting the fan cable to the cables those of the original PSL fans.
    4. Next I used heat shrinks to cover the bare soldered areas and placed the fans into the module. 
    5. We tested the fans by plugging intp the PSL and turning the key. The fans turned on nicely and we proceeded to put it module back together.

Placing the PSL back in its place. 

    1. We place the PSL back into its original spot and began to connect the cables. Make sure the Power cables is put in LAST. 
    2. After the module was put back, we DID NOT put the external fan back into its place. This is to see if the fans which were installed are good enough to maintain the PSL.
    3. Turn the key and press the on Button.

The noise from the external fan is no longer appearing as shown in attachment #3. The PSL has been on for ~2 hrs now and has not turned off. It seems that the fans are doing their jobs well. 

I found that the MC transmission was low (~13000. Usually it's ~13500) in the morning.
This was due to the low transmission of PMC (~0.675. Usually it's ~0.685), so I restored the PMC alignment using the two steering mirrors before the input mirror.
The transmission of MC and PMC was restored to ~13300 and ~0.687.

[Yuta, Hiroki]

Remote switching of PSL shutter is not working.

When we tried to reset the LSC offsets, we found that the remote switching of the PSL shutter was not working.
We closed the shutter manually by using the toggle switch on the front panel of the shutter driver (N.C. -> N.O. (Attachment 1)) for the momment.
 

[JC Koji]
c1vac was hard rebooted. This fixed the PSL shutter issue.

• Checked the Unibritz Shutter Controller for the PSL shutter. It seems that it responds to the NO/NC switch no matter how the REMOTE/LOCAL switch is. (Normal action)
• Checked the BNC input to the shutter controller. There was no trigger/gate or whatever signal from Acromag.
• c1psl reboot did not help
  • Upon this action, a snapshot was taken.
  • Stopped/restarted modbusIOC.services. Did not work.
  • Rebooted c1psl. Didn't work.
• c1psl was shutdown and c1psl acromag chassis was power-cycled. This didn't help. c1psl was burtrestored.
  • Stopped modbusIOC.services. Shutdown c1psl.
  • Power cycled the Acromag chassis.
  • After a while, c1psl was turned on. The epics channels came back.
  • Confirmed modbusIOC.services was running.
  • Burtrestored the snapshot.
• I remembered that the vacuum pressure could make an interlock action on the PSL shutter.
  Found that c1vac values were all whited out. c1vac was not reachable from Martian.
• Went to c1vac and found it was frozen. Pushed hard reset.
• c1vac came back, and it closed the gate valve V1 (main GV for the main vacuum manifold). We opened V1 from the vac control screen.
• Confirmed the PSL shutter is now operational.

After the exploration of c1psl, the IMC locking was not functioning well. It looked like the MC autolocker issue.

Now I remember that the autolocker was running on docker. I followed the instruction on the wiki page. https://wiki-40m.ligo.caltech.edu/Computers_andScripts/AlwaysRunningScripts

Remember: Docker is running on optimus / systemctl is running on megatron!

Then: I noticed that MC autolocker heartbeat was blinking even with the docker stopped (!?). I confirmed that autolocker is not running on systemctl

I had no hope who is toggling the heartbeat, but "ps -def" on megatron showed me that "AutoLockMC_LowPower.csh" is running! I was afraid that it is a remnant from vent!? But, is that possible?

The process was killed and the docker locker is running well now.

For monitoring the statuses of the PSL HEPA fans, we are planning to attach flow speed sensors (D6F-V03A1) on the HEPA fans.
Before installing the flow sensors, I have finished the followings:

• Tested two flow sensors with alligator clip wires (Attachment 1)
  • No flow: ~ 0.5 V
  • Saturation: ~ 2.7 V
     
• Measured the flow speed of PSL HEPA fans with an alligator-clip-wired flow sensor
  • Medium speed: ~ 0.8 V (~ 0.6 m/s )
  • Maximum speed: ~ 1.4 V (~ 1.8 m/s)
    The flow speed [m/s] was estimated from the linear approximation of the nominal value
     
• Wired flow sensors to install them in PSL and to take the output voltage by an Acromag ADC (Attachment 2)
  • Wired sensors worked as in the case of the alligator-clip-wired sensors.

Next:

• Summarize the details of the used parts and the wiring.
• Install the wired flow sensors in PSL. Monitor their outputs from CDS.

[Paco, Hiroki]  

Installed two flow sensors on the PSL HEPA fans 

To monitor the flow speed of the PSL HEPA fans, we installed two flow sensors:

• Attached two flow sensors on the ceiling of PSL table and connected their outputs to the Acromag ADC:
  • Attachment 1: Connected DB37 to the Acromag ADC
  • Attachment 2: Wiring from the Acromag ADC to the PSL table
  • Attachment 3: Attached flow sensors on the ceiling of the PSL table
  • Attachment 4: Wiring diagram
     
• Changed the flow speed of HEPA fans and monitored the signals from the corresponding sensors with StripTool (Attachment 4):
  • ​Sensor 1:
    • Minimum speed: ~ 0.52 V 
    • Medium speed:   ~ 0.78 V 
    • Maximum speed: ~ 0.83 V 
  • ​Sensor 2:
    • Minimum speed: ~ 0.50 V 
    • Medium speed:   ~ 0.72 V 
    • Maximum speed: ~ 0.83 V 

The results above are non-linear. This might be due to the non-linearity of the flow sensors and the non-linearity of the controllers for HEPA fans.
*Regarding the HEPA fan 1, which the sensor 1 is attached on, there was slight flow even when the speed was minimized. This is why the minimum output of sensor 1 was ~ 0.52 V and not 0.50 V.

Next:

• Calibrate the Acromag ADC by injecting signal from a function generator.
• Calibrate the measued voltage to the flow speed (with linear approximation?) and show them on the CDS screen.

[JC, Koji]

In the morning, JC came in and found that c1sus had crashed. JC tried to save the situation by rebooting the host, inevitably, all the CDS machines needed to be rebooted.
But it was successful! Thanks, JC!

The remaining issue was that the PMC was in a strange state.
- The transmission was low (0.45~0.5V vs 0.67~0.68V nominal)
- The input alignment didn't help much
- The refl spot was not well centered on the CCD

We jiggled the setting for a while and found that the PMC error input offset needs to be significantly increased from the nominal value.
In fact, the offset hit the end of the range (+10V), this made the transmission to be ~0.67, but there may be slight room to improve it.
To investigate this, we need to look at the analog error signal, but I don't have enough energy to look into it today.

After the PMC recovery, the IMC was locking already, and the arms were flashing. I took the alignment of both arms.

[Koji, Hiroki] 

Calibrated flow sensor signals from [volt] to [m/s] and displayed them on CDS screen

We added the EPICS calc records to /cvs/cds/caltech/target/c1psl/psl/pem.db (Attachment 1) and made two channels for the calibrated signals of the flow sensors as follows:

C1:PEM-HEPA_FLOW_PSL1_CAL : Calibrated signal of flow sensor 1 [m/s]
C1:PEM-HEPA_FLOW_PSL2_CAL : Calibrated signal of flow sensor 2 [m/s]

At first, we tried to calibrate the output signal by using the 6-order approximation written in the user's manual (P11, D6F-V03A1) but the resulting outputs became 0 and we failed.
The cause of this failure might be due to the large number of the calculation of the 6-order approximation.
Then we used 5-order approximation that was fitted to the 6-order approximation and succeeded in obtaining the calibrated signals.
The used 5-order approximation is as follows:

    v: output voltage from flow sensor [V]
    A=5.11938
    B=-29.7601
    C=68.6169
    D=-78.4301
    E=46.0640
    F=-10.2767  

Attachment 2 shows the time series data of the raw signals and the calibrated signals when the flow speed was changed in minimum - middle - maximum.
Attachment 3 shows the CDS screen displaying the calibrated signals.

 I had a think about the algorithm we might use for the phase camera measurement. MATLAB has an fft function that will allow us to extract the data that we need with a single command.

We record a series of images from a camera and put them into a 3D array or movie, image_arr, where the array parameters are [x-position, y-position, time], i.e. a 2D slice is a single frame from the camera. Then we can do an FFT on that object with the syntax, f3D = fft(image_arr, [ ], 3), which only does the FFT on the temporal components. The resulting object is a 3D array where each 2D slice is an 2D array of amplitude and phase information across the image for a single temporal frequency of the movie.

So if we recorded a movie for 1s where the sample rate is 58Hz, then the 1st frame of f3D is just a DC image of the movie, the 2nd frame are the complex 1Hz components of the movie, etc all the way up to 29Hz. 

Suppose then that we have a image, part of which is being modulated, e.g. a chopper wheel rotating at 20 or 24Hz, or a laser beam profile which contains a 1kHz beat between a sideband and a reference beam. All we have to do is sample at at least twice that modulation frequency, run the command in MATLAB, and then we immediately get an image which contains the phase and magnitude information that we're interested in (in the appropriate 2D slice o the FFT).

As an example, I recorded 58 frames of data from a camera, sampling at 58Hz, which was looking at a spinning chopper wheel. There was a white sheet of paper behind the wheel which was illuminated from behind by a flashlight. The outer ring was chopping at 24Hz and the inner ring was chopping at 20Hz. I stuck all the images into the 3D array in MATLAB, did the transformation and picked out the DC, 20Hz and 24Hz signals. The results are shown in the attached PDFs which are:

1. phase_camera_DC_comp.pdf - a single image from the camera and the DC component (zoomed in) of the FFT
2. phase_camera_F1_comp.pdf - the magnitude and phase information of the 20Hz component of the FFT
3. phase_camera_F2_comp.pdf - the magnitude and phase information of the 24Hz component of the FFT (this PDF contains a typo that says 25Hz).
4. load_raw_data.m - the MATLAB routine that loads the saved data from the camera and does the FFT

You can, and I have, run the MATLAB engine from C directly. This will allow you to transfer the data from the camera to MATLAB directly in memory, rather than via the disk, but it does need proper memory allocation to avoid segmentation faults - that was too frustrating for me in the short term. In this case, the 58 frames were recorded to a file as a contiguous block of data which I then loaded into MATLAB, so it was slower than it might've otherwise been. Also the computer I was running this on was a bit of a clunker so it took a bit of time to do the FFT.

The data rate from the camera was 58fps x (1024 x 1024) pixels per frame x 2 bytes per pixel = 116MB per second. If we were to use this technique in a LIGO phase camera, where we want to measure a modulation which is around 1kHz, then we'd need a sample rate of at least 2kHz, so we're looking at at least a 30x reduction in the resolution. This is okay though - the original phase camera had only ~4000 spatial samples. So we could use, for instance, the Dalsa Falcon VGA300 HG which can give 2000 frames per second when the region of interest is limited to 64 pixels high.

 We've set up a preliminary test bed for the phase camera. It simply uses a HeNe that is split into two beams. One is frequency shifted by an AOM by -40 MHz - df, where df is some acoustic frequency. The second beam is transmitted through a 40MHz EOM to get sidebands. The two beams are recombined and are, currently, incident on a photodetector, but this can be replaced by the phasecamera.

We turned everything on with df = 1kHz and confirmed that a 1kHz signal is visible on the output from the photodetector (PD). The signal looks to be about 1:300 of the DC level from the PD.

1. In terms of the AOM:

How much beam power is incident on the AOM? How much is the deflection efficiency?
i.e. How much is the power lost by the crystal, deflected in the 1st order, and remaining in the oth order?

I am curious because I assume the AOM (which vender?) is designed for 1064nm and the setup uses 632nm.

2. In terms of the EOM:

How much sidebands do you expect to have?

I assume the EOM is designed for 1064nm, the only difference is the coating at the end. Is this right? 

3. Beating

How much beating strength do you expect?

Is your beating level as expected?

How much is the contrast between the PM sideband and the frequency shifted carrier?
This must include the consideration on the presence of the carrier and the other sidebands.

This past week I have completed the following tasks:

1. Built a trigger and power box for the camera GC 750M (06058) and took some test images to see whether the trigger box really works. Result: It is doing fine!

2. Went over the setup that is already sitting on the table. Ref: Aidan's elog entry

3. Attended seminars and talks given by Alan, Jahms, Koji and Rana.

4. Attended the mandatory laser safety training by Peter.

Expected task for this week (could be more):

1. Work out analytical expressions of the power of the carrier and sidebands going to the camera in the setup. (As suggested by Rana and Joe)

2. Work on producing beat signal to the camera using the He-Ne laser setup.

3. Move,if possible, to the Nd:YAG setup.

4. Go over the codes and paper by the past SURFers on the phase camera experiment.

This week I have completed following tasks:

1. Worked out the analytical expressions for the amount of power of the DC and oscillatory part going into the camera.

2. Realigned the He-Ne PhaseCam setup as we had to replace the first steering mirror after the laser with a silvered mirror ( one without a dielectric coating for 1064 nm).

3. Gone through the code written by a previous surfer (Zach Cummings).

4. Read the paper 'Real-time phase-front detector for heterodyne interferometers'- F. Cervantes et. el. where they talk about constructing a phase detector for LISA pathfinder mission. One interesting fact I found was that, they used InGaAs chip for their CCD Cam which has a amazing QE of 80% @ 1064 nm. Unfortunately, the one we are using (Micro MT9V022 CMOS) has only ~5% QE for 1064 nm and 50% for 633 nm. One top of it MT9V022 has a built-in infra-red filter infront of it to make it more insenstive to 1064. In such limitations, we may have to find a work-around for this issue. Any idea?

5. Read about the EOM and AOM and their vibrating (!) way to add on and alter the incident light on them. (Source: Intro to Optical Electronics-Yariv)

One task that we couldn't accomplish even though I planned on doing is:

1. Move,if possible, to the Nd:YAG setup.

Task for this week:

1. Produce breathtaking calibration of the camera at He-Ne setup.

2. Read 'Fringe Analysis'-Y.Surrel and 'Phase Lock Technique'-Gardner.

3. Modify the phasecam code.

4. Produce an alternate triggerbox using diodes instead of Op-Amp as op-amp is suspected to fail at some point driving the camera due to impedance mismatch.

5. Answer Koji's question at Aidan's ELOG .

I have completed the following tasks:

1. Find a simplified calibration of the exposure time for the current He-Ne setup. Basically, I triggered the camera to take 20 snapshots with a 20 Hz driving signal at different exposure time beginning from 100 us (microsecond) upto 4000 us with an increment of 200 us.

    Result: The current power allows the camera to have an exposure time of ~500 us before the DC level begans to saturate.

2. Aidan and I did some alignment and connected the AOM and corrected the driving frequency of its PZT to 40 Mhz(which apparently was disconnected which in turn gets the credit of NO beat signal for me until Tuesday 07/06/2010 5:30 PST) .

    Result: I got the beat signal of 1 Hz and 5 Hz. Image follows (the colormap shows the power in arbitrary units).

3. Finished writing my Progress Report 1 .

Here are some more details about the current phasecam setup. We are using a He-Ne laser setup

A crude snap shot of the setup....

We sent light through SM2 (Steering Mirror 2)  to BS1(Beam-Splitter 1) where the laser light is split into two parts, one going to the AOM and the other to the EOM. The EOM adds 40 MHz sidebands to the incoming carrier light after SM3, and the AOM shifts the frequency of the incident light on it to 40.000 005 MHz. The purpose for doing this juggling is to intentionally create a beat signal off the reference beam from the AOM with the sidebands added at the EOM. Note that, we are driving the AOM at 7dBm and the EOM at 13 dBm with 0 (nil) modulation. The two lights are combined at the BS2 and sent off through SM5 to the camera. The CMOS of the camera contains silicon based Micro MT9V022 chip which has a quantum efficiency of 50% at 633 nm. Thus we expected a fairly good response to this He-Ne setup from the camera. 

Using a trigger circuit, we triggered the camera at 20 Hz by sending a 20Hz sinusoidal signal to it. The trigger circuit converts this to a positive square waves. Then I roughly figured out the optimum exposure time for the camera before the DC levels saturates it by writing a code for taking a series of 25 images at different exposure time. I found that 500µs seems to be a reasonable exposure time. So, using this data, I took 20 consecutive images and sent them through a short Fourier Transform segment using Matlab to see the beat signal. Note that the DC component from these processing of the images have some fringe pattern which is due to the ND 2.5 filter that we were using to reduce the light power incident on the camera. The FT method also gave us the presence of the beat signal at the corresponding bin of the FT (for example: for 5Hz beat signal, I got the DC at bin 1 of the FT and 5Hz component at bin 6 as expected). Then I changed the AOM driving frequency to 40.000 001 MHz in order to see a 1 Hz beat signal. The results for both is in my previous post.