The servos are almost certainly not optimal - but we have the IFO sort of working, so before we make any changes, let's make a strong case for it. Once the loop TFs and noises (e.g. the sensing noise reinjection you maybe saw) are fully characterized and a new loop is shown to perform better, then we can make the changes, but until then, let's continue using the "nominal" configuration and keep all the WFS loops on . I turned everything back on.

BTW, MC2_ASCPIT_IN1 isn't the correct channel to measure the sensing noise re-injection, you need some other sensor, e.g. is the MC transmission (de)stabilized. 0-20 Hz is where I expect the WFS is actually measuring above the sensing noise.

Summary:

I spent an hour today evening checking out the remote waveplate operation. Basic remote operation was established 👍 . To run a test on the main beam (or any beam for that matter), we need to lay out some long cabling, and install the controller in a rack. I will work with Jordan in the coming days to do these things. Apart from the hardware, some EPICS channel will need to be added to the c1ioo.db file and a python script will need to be set up as a service to allow remote operation.

Part numbers:

• The controller is a NewFocus ESP300.
• The waveplate stage is a PR50CC. The waveplate itself that is mounted has a 1" diameter (clear aperture is more like 21mm), which I think is ~twice the size of the waveplates we have in the lab, good thing Livingston shipped us the waveplate itself too. It is labelled QWPO-1064-10-2, so should be a half wave plate as we want, but I didn't explicitly check with a linearly polarized beam today. Before any serious high power tests, we can first contact clean the waveplate to avoid any burning of dirt. The damage threshold is rated as 1 MW/cm^2, and I estimate that we will be well below this threshold for any power levels (<30W) we are planning to put through this waveplate. For a 100um radius beam with 30W, the peak intensity is ~0.2 MW/cm^2. This is 20% of the rated damage threshold, so may be better to enforce that the beam be >200um going through this waveplate.
• The dimensions of the mount look compatible with the space we have on the PSL table (though of course once the amplifier comes into the picture, we will have to change the layout. Maybe it's better to keep everything downstream of the PMC fixed - then we just re-position the seed beam (i.e. NPRO) and amplifier, and then mode-match the output of the amplifier to the PMC.

Electrical tests:

1. First, I connected a power cord to the ESP300 and powered it on - the front display lit up and displayed a bunch of diagnostics, and said something to the effect of "No stage connected".
2. Next, I connected the rotary mount to "Axis #1": Male DB25 on the stage to female DB25 on the rear of the ESP300. The stage was recognized.
3. Used the buttons on the front panel to rotate the waveplate, and confirmed visually that rotation was happening 👍 . I didn't calibrate the actual degrees of rotation against the readback on the front panel, but 45 degrees on the panel looked like 45 degrees rotation of the physical stage so seems fine.

RS232 tests:

• This unit only has a 9-pin Dsub connector to interface remotely to it, via RS232 protocol. c1psl Supermicro host was designated the computer with which I would attempt remote control.
• To test, I decided to use a serial-USB adapter. Since this is only a single unit, no need to get an RS232-ethernet interface like the one used in the vacuum rack, but if there are strong opinions otherwise we can adopt some other wiring/control philosophy.
• No drivers needed to be installed, the host recognized the adapter immediately. I then shifted the waveplate and controller assembly to inside the VEA - they are sitting on a cart behind 1X2. Once the controller was connected to the USB-serial adapter cable, it was registered at /dev/ttyUSB0 immediately. I had to chown this port to the controls user for accessing it using python serial. 
• Initially, I was pleasantly surprised when I found not one but TWO projects on PyPi that already claimed to do what I want! Sadly, neither NewportESP1.1 nor PyMeasure0.9.0 actually worked - the former is for python2 (and the string typesetting has changed for PySerial compatible with python3), while the latter seems to be optimized for Labview interfacing and didn't play so nice with the serial-USB adapter. I didn't want to spend >10mins on this and I know enough python serial to do the interfacing myself, so I pushed ahead. Good thing we have several pySerial experts in the group now, if any of you want to figure out how we can make either of these two utilities actually work for us - there is also this repo which claims to work for python 3 but I didn't try it because it isn't a managed package.
• The command list is rather intimidating, it runs for some 100 (!) pages. Nevertheless, I used some basic commands to readback the serial number of the controller, and also succeeded in moving the stage around  by issuing the "PR" command appropriately 👍. BTW, I forgot that I didn't test the motor enable/disable which is an essential channel I think.
• I think we actually only need a very minimal set of commands, so we don't need to read all 100 pages of instructions:
  • motor enable/disable
  • absolute and relative rotations
  • readback of the current position
  • readback of the moving status
  • a stop command
  • an interlock
• Note that as a part of this work, in addition to chowning /dev/ttyUSB0, I installed the two aforementioned python packages on c1psl. I saw no reason to manually restart the modbus and latch services running on it, and I don't believe this work would have impacted the correct functioning of either of those two services, but be aware that I was poking around on c1psl. I was also reminded that the system python on this machine is 2.7 - basically, only the latch service that takes care of the gains for the IMC servo board are dependent on python (and my proposed waveplate control script will be too), but we should really upgrade the default python to 3.7/3.8.

Next steps:

Satisfied that the unit works basically as expected, I decided to stop for today. My thinking was that we can have the ESP300 installed in 1X1 or 1X2 (depending on where space is more readily available). I will upload have uploaded a cartoon here so people can comment if they like/dislike my plan. 

• We need to use a long-ish cable to run from 1X1/1X2, where the controller will be housed, to the PSL enclosure. Livingston did ship one such long cable (still on Rana's table), but I didn't check if the length is sufficient / the functionality of this long cable. 
• We need to set up some EPICS channels for the rotation stage angle, motor ENABLE/DISABLE, a "move stage" button, motion status, and maybe a channel to control the rotation speed? 
• We need a python script that is reading from / writing to these EPICS channel in a while loop. Should be straightforward to setup something to run like the latch.py service that has worked decently reliably for ~a year now. afaik, there isn't a good way to run this synchronously, and the delay in sending/completing the execution of some of the serial commands might be ~1 second, but for the purpose of slowly ramping up the power, this shouldn't be a problem.
• One question I do have is, what is the strategy to protect the IFO from the high power when the lock is lost? Surely we are not gonna rely on this waveplate for any fast actuation? With the current input power of 1W, the MCREFL photodiode sees ~100mW when the IMC loses lock. So if the final input power is 35W, do we wanna change the T=10% beamsplitter in the MCREFL path to keep this ratio?

Once everything is installed, we can run some tests to see if the rotary motion disturbs the PSL in any meaningful way. I will upload some photos to the picasa later. Photos here.

I spent some time today setting up a workable user interface to control the waveplate.

1. Created some EPICS database records at /cvs/cds/caltech/target/ESP300.db. These are all soft channels. This required a couple of restarts of the modbus service on c1psl - as far as I can tell, everything has come back up without problems.
2. Hacked newportESP to make it work, mainly some string encoding BS in the python2-->python3 paradigm shift.
3. Made a python script at /cvs/cds/caltech/target/ESP300.py that is based on similar services I've set up for the CM servo and IMC servo boards. I have not yet set this up to run as a service on c1psl, but that is pretty trivial.
4. Made a minimal MEDM screen, see Attachment #1. It is saved at  /opt/rtcds/caltech/c1/medm/c1psl/C1PSL_POW_CTRL.adl and can be accessed from the "PSL" tab on sitemap. We can eventually "calibrate" the angular position to power units.
5. Confirmed that I can move the waveplate using this MEDM screen.

So this system is ready to be installed once Jordan and I find some time to lay out cabling + install the ESP300 controller in a rack.

At the moment, there is no high power and there is minimal risk of damaging anything, but someone should double check my logic to make sure that we aren't gonna burn the precious IFO optics. We should also probably hook up a hardware interlock to this controller.

I went through some aLIGO documentation and believe that they are using a custom made potentiometer based angle sensor rather than the integrated Newport (or similar) sensor+motor. My reading of the situation was that there were several problems to do with hysterisis, the "find home" routine etc. I guess for our purposes, none of these are real problems, as long as we are careful not to randomly rotate the waveplate through a full 180 degrees and go through the full fringe in the process. Need to think of a clever way to guard against careless / accidental MEDM button presses / slider drags.

Unrelated to this work: I haven't been in the lab for ~a week so I took the opportunity today to go through the various configs (POX/POY/PRMI resonant carrier etc). I didn't make a noise budget for each config but at least they can be locked 👍 . I also re-aligned the badly misaligned PMC and offloaded the somewhat large DC WFS offsets (~100 cts, which I estimate to be ~150 nNm of torque, corresponding to ~50 urad of misalignment) to the IMC suspensions' slow bias voltages. 

[jordan, gautam]

We did the following this afternoon.

1. Disconnected the cable from the unused (and possibly not working) RefCav heater power supply, and removed said PS from 1X1. There was insufficient space to install the ESP300 controller elsewhere. I have stored the power supply along the east arm under the beamtube, approximately directly opposite the RFPD cabinet.
2. Installed the ESP 300 - conveniently, the HP DCPS was already sitting on some rails and so we didn't need to add any.
3. Ran a long D25-D25 cable from the ESP300 to the NE corner area of the PSL enclosure. The ends of the cable are labelled as "ESP end" and "Waveplate end". The HEPA was turned on for the duration we had the enclosure open, and I have now turned it off.
4. Connected the waveplate to this cable. Also re-connected the ESP300 to the c1psl supermicro host via the USB-RS232 adapter cable.

The IMC stayed locked throughout our work, and judging by the CDS overview screen, we don't seem to have done any lasting damage, but I will run more tests. Note that the waveplate isn't yet installed in the beam path - I may do this later today evening depending on lab activity, but for now, it is just sitting on the lower shelf inside the PSL enclosure. I will post some photos later.

Update: The waveplate was installed. I gave it a couple of rounds of cleaning by first contact, and visually, it looked good to me. More photos uploaded. I also made some minor improvements to the MEDM screen, and setup the communication script with the ESP300 to run as a systemd service on c1psl. Let's see how stable things are... I think the philosophy at the sites is to calibrate the waveplate rotation angle in terms of power units, but i'm not sure how the unit we have performs in terms of backlash error. We can do a trial by requesting ~100 "random" angles, monitoring the power in s- and p-polatizations, and then quanitfying the error between requested and realized angles, but I haven't done this yet. I also haven't added these channels to the set recorded to frames / to the burt snapshot - do we want to record these channels long term?

MC was unlocked and struggling to recover this morning due to misguided WFS offsets. In order to recover from this kind of issue, we

1. Cleared the bogus WFS offsets
2. Used the MC alignment sliders to change MC1 YAW from -0.9860 to -0.8750 until we saw the lowest order mode transmission on the video monitor.
3. With MC Trans sum at around ~ 500 counts, we lowered the C1:IOO-WFS_TRIGGER_THRESH_ON from 5000 to 500, and the C1:IOO-WFS_TRIGGER_MON from 3.0 to 0.0 seconds and let the WFS integrators work out some nonzero angular control offsets.
4. Then, the MC Trans sum increased to about 2000 counts but started oscillating slowly, so we restored the delayed loop trigger from 0.0 to 3.0 seconds and saw the MC Trans sum reach its nominal value of ~ 14000 counts over a few minutes.

The MC is now restored and the plan is to let it run for a few hours so the offsets converge; then run the WFS relief script.

We found that megatron is unable to properly run scripts/MC/WFS/mcwfsoff and scripts/MC/WFS/mcwfson scripts. It fails cdsutils commands due to a library conflict. This meant that WFS loops were not turned off when IMC would get unlocked and they would keep integrating noise into offsets. The mcwfsoff script is also supposed to clear up WFS loop offsets, but that wasn't happening either. The mcwfson script was also not bringing back WFS loops on.

Gautam fixed these scripts temprorarily for running on megatron by using ezcawrite and ezcaswitch commands instead of cdsutils commands. Now these scripts are running normally. This could be the reason for wildly fluctuating WFS offsets that we have seen in teh past few months.

gautam: the problem here is that megatron is running Ubuntu18 - I'm not sure if there is any dedicated CDS group packaging for Ubuntu, and so we're using some shared install of the cdsutils (hosted on the shared chiara NFS drive), which is complaining about missing linked lib files. Depending on people's mood, it may be worth biting the bullet and make Megatron run Debian10, for which the CDS group maintains packages.

Came this morning and saw that the IMC is unlocked.

Went into MC Lock screen and see that the watchdog is down and the PSL shutter is closed. I tried to open the shutter but nothing happened - no REFL signal or beam on the MC REFL camera .

Thinking this has something to do with the watchdog I upped the watchdog:

ezcawrite C1:SUS-MC2_LATCH_OFF 1

The watchdog on the MEDM screen became green but the shutter still seemed unresponsive. I went to the PSL table and made sure that the shutter is working. I opened the AS table and saw there no MC REFL beam anywhere.

Thinking that MC1 must be completely misaligned I opened the MC align screen to find that indeed all the alignment values has been zeroed! (attachment).

I burt restore c1iooepics from Mar 4th 00:19. Didn't help.

I try to burt restore c1susepics from Mar 1st 13:19. Still zero.

I try to burt restore c1susaux from Mar 1st 00:19 -> seems like alignment values have been restored.

I open the shutter. Beam is flying! MC Watchdogs tripped! I close the shutter. OK, I need to wait until the MCs are dampped enough. MC2 and MC3 have relaxed so I enable their watchdogs. MC1 is still swinging a bit. I turn on damping for MC1 as well.

MC locked immediately but the REFL is still high like 1.2. Is it normal?

I turn on the WFSs and the REFL went down to 0.3 nice. I run the MC WFS relief script.

Hmm, the bias values were reset at 2022-03-03-20:01UTC which is 2022-03-03-12:01 PST with no apparent disruption of the data acquisition (= no resetting of the RTS). Not sure how this could happen.

Came this morning, opened the PSL and there was not even a beam on the MC REFL.

Looking at the big monitor it seems like the WFS signals went through the roof during the "auto-alignment" night session.

I restored the MC alignment from before the misalignment happen and wait for the SUS to damp. Once the RMS values went below 200 I enabled the watchdog and the coil outputs.

I opened the PSL shutter and the IMC locked immediately. I turned on the WFS servo and the MC REFL DC went down to 0.3. I run the WFS relief script.

The IMC alignment was restored and the IMC is nicely locking.

Once the vacuum level recovered P<1e-4 torr, the PSL shutter was able to be opened.

The IMC was still flashing, so the lock to TEM00 was possible.

Once it was locked, the MC2 alignment was tweaked and the autolocker and the WFS kicked in to help the locking/alignment.

The transmission is ~13k and seems reasonable considering the low PMC transmission of the PMC (0.672)

[Yuta, JC]

It seems that early this morning MC got very misaligned. Yuta was able to align the Mode Cleaner again by individually adjusting the MC1 MC2, and MC3. Once transmission reach ~12000, we went ahead and turned on WFS. Oddly enough, the transmission began plummeting and MC fell out of lock. After this, Yuta reset the WFS offsets and realigned the WFS QPDs. We then locked MC and turned on WFS once again, but the same issue happened. After fiddeling around with this, we found the if we set C1:IOO-MC2_TRANS_PIT_OUTPUT and C1:IOO-WFS1_YAW_OUTPUT equal to 0, WFS does not cause this issue. Is there a proper to reset WFS, aside from only zeroing the offsets?

This issue is very weird and still unresolved. Without WFS loops, we'll have to realign IMC often and we might loose IMC alignment completely during weekends or long weekends.

I tried following things today but nothign worked:

• Blocked WFS PDs and reset DC offsets (sitemap>C1IOO>C1IOO_WFS_MASTER>! Actions>Correct WFS DC Offsets).
• Switched off MC chamber lights.
  I felt that they might be on, but later I feel that wasn't the case. Anyways, this didn't help.
• Algined IMC manually using cavAlign tool with MC2-MC3 and then tweaking MC1 and MC3 a little bit. Reach 13.6k in C1:IOO-MC_TRANS_SUM. Then I unlocked IMC with autolocker off, centered beam on WFSs (they were pretty off even though we have been centering them this week), and then reset RF offsets (sitemap>C1IOO>C1IOO_WFS_MASTER>! Actions>Correct WFS DC Offsets). This did not help either.
• The fact that IMC started misbehaving since Thursday onwards was bugging me that maybe the FE models did not come online properly, that maybe some RTS link is broken in IOO model which is causing the feedback loop to not work. So I went ahead and restarted all models, that didn't help either.
  • Now we have a restartAllModels.sh script which restarts all cds system and restores state to just before restarting. It also makes sure that watchdogs are engaged safely particularly for new suspesnions where alignment offsets are ramped.

We need to investigate this as first priority. Maybe some cable is loose, some PD power supply not working etc. Until we fix this, people should align IMC to > 12000 transmission counts whenever they have a spare 5 min. We need to work in place of WFS for sometime.

I could run the WFS servo (6dofs) for more than 15min by flipping the sign for the MC2 Pit and WFS1 Yaw. (See attachments)

This may mean that the sign of the loops / the input matrix / the output matrix, as well as the sensors and actuators, have the problem.
Isn't it the time to measure the sensing/actuation matrices? Maybe Tomislav already has the data?

I have reverted the changes as you may need more careful investigation.

[Anchal, Yuta]

We found that MC1 local damping loop signs were revereted to the state before our standardization on June 7th (40m/16898), but the WFS output matrix was not reverted.
This caused the sign flip in the feedback to MC1, which caused the IMC WFS issue.
This probably happened when we were restarting the models after RTS modeling (40m/16935). We might have used wrong snap files for burt-restoring.

We went back to the snapshot taken at 09:19 June 21, 2022 and now the IMC WFS is working,

I found the IMC was largely misaligned and was not locking. The WFS feedback signals were saturated and MC2 was still largely misaligned in yaw after resetting the saturation.
It seemed that the MC WFS started to put the large offset at 6:30AM~7:00AM (local).
MC2 was aligned and the lock was recovered then the MC WFS seems working for ~10min now.

MC WFS Demod board needs some attention.

Tomislav has been measuring a very high noise level in the MC WFS demod output (which he promised to elog today!). I thought this was a bogus measurement, but when he, and Paco and I tried to measure the MC WFS sensing matrix, we noticed that there is no response in any WFS, although there are beams on the WFS heads. There is a large response in MC2 TRANS QPD, so we know that there is real motion.

I suspect that the demod board needs to be reset somehow. Maybe the PLL is unlocked or some cable is wonky. Hopefully not both demod boards are fried.

Please leave the WFS loops off until demod board has been assessed.

This is just my intuition but the IMC servo seems not so optimized. I can increase the servo gain by 6~10dB easily. And I couldn't see that the PC drive went mad (red) as I increase the gain (=UGF).
The IMC needs careful OLTF measurements as well as the high freq spectrum observation.

It seems that I have worked on the IMC servo tuning in 2014 July/Aug. Checking these elogs would be helpful.

It looks like Tomislav's measurements of the WFS demod board noise were actually of the cable that goes from the whitening to the ADC. So the huge low frequency excess that he saw is not due to wind, but just the inverse whitening of the digital system?

In any case, today, I looked at the connections from the Whitening to the ADC. It goes through an interface chassis to go from ribbon to SCSI. The D-Sub connectors there have the common problem in many of the LIGO D-sub connectors: namely that the strain relief nuts are too tall and so the D connector doesn't seat firmly - its always about to fall out. JC, can you please take a look at this and order a set of low profile nuts so that we can rework this chassis? Its the one between the WFS whitening and the SCSI cables which go to the ADCs.

After pushing them in, I confirmed that the WFS are working, by moving all 6 DoF of the MC mirrors via bias slider, and looking at the step responses (attached). As you can see, all sensors see all mirrors, even if they are noisy.

Next up: get a breakout for the demod output connector and measure the noise there.

For today, I aligned the IMC by hand, then centred the WFS beams by unlocking the IMC and aligning the bright beam. I noticed that the WFS1 beam was being dumped randomly, so I angled the WFS1 by ~3 deg and dumped the specular reflection on a razor blade dump. To handle the sign change in the MC1 actuation (?), I changed the sign in the MC1 ASC filter banks. MCWFS loops still nto closing, but they respond to mirror alignment.

I wasn't sure how the IMC servo was optimized recently. We used to have the FSS over all gain (C1:PSL-FSS_MGAIN) of +6dB a few years back. It is not 0dB. So I decided to do a couple of measurements.

1) Default setting:

C1:IOO-MC_REFL_GAIN +4
C1:IOO-MC_BOOST2 +3
C1:IOO-MC_VCO_GAIN +13
C1:PSL-FSS_MGAIN +0
C1:PSL-FSS_FASTGAIN +19

2) Looked at the power spectrum at TEST1A output (error signal)
TEST1A is the signal right after the input gain stage (C1:IOO-MC_REFL_GAIN). Prior to the measurement, I've confirmed that the UGF is ~100Hz even at +0dB (see next section). It was not too bad even with the current default. Just wanted to check if we can increase the gain a bit more.
The input gain was fixed at +4dB and the FSS overall gain C1:PSL-FSS_MGAIN was swept from +0 to +6.
At +5dB and +6dB, the servo bump was very much visible (Attachment 1).
I decided to set the default to be +4dB (Attachment 3).

3) Took OLTF at 0dB and 4dB for the FSS overall gain.

Now the comparison of the opel loop transfer functions (OLTF) for C1:PSL-FSS_MGAIN at 0dB and 4dB. The OLTF were taken by injectiong the network analyzer signal into EXCA and measure the ratio between TEST1A and TEST1B (A/B).

C1:PSL-FSS_MGAIN +0 -> UGF 100kHz / Phase Margin ~50deg
C1:PSL-FSS_MGAIN +4 -> UGF 200kHz / Phase Margin 25~30deg

The phase margin was a bit less but it was acceptable.

4) IMC FSR

Took the opportunity to check the FSR of the IMC. Connected a cable to the RF MON of the IMC REFL demod board. Looked at the peak at 40.56MHz (29.5MHz + 11.066MHz). The peak was not so clear at 11.066195MHz (see 40m ELOG 15845). The peak was anyway minimized and the new modulation frequency was set to be 11.066081MHz (new FSR). The change is 10ppm level and it is within the range of the temp drift.

I wanted to check what's wrong with the WFS.

I played with MC2 misalignment to check the error signals.
MC2 pitch and yaw misalignment optically produce a vertical translation and horizontal rotation of the cavity axis at the waist, respectively. So it is thought to be a more separated excitation of the cavity axis.
Then I noticed that WFS2 error signals in general has high (~100%) pitch-yaw coupling. So it was suspicious.

I went to the rack and found that WFS2 SEG4 RF input (labeled "8") was not completely inserted. (Attachment 1)
It seemed that the LEMO connector or the receptacle didn't latch properly anymore and could be easily pulled.
I gave some elbow grease to fix this but in vain. I ended up to use LEMO-BNC adapters which somehow offered a robust connection.

Desipite the insightful discovery, this was not the intrinsic solution to the issue. I checked the past signal history, but I don't think this loose connection caused the missing signal.

Next, I needed to go a bit deeper. The WFS sensors are supposed to be adjusted to I phase where the PDH signal maximally shows up. And all the segments are supposed to have the same sign in terms of the PDH signal.

I've unlocked the IMC and turned on MC2 tickling. This swept the cavity over the resonances.
WFS1 SEG1I~3I showed about the same waveform, but SEG4 Q shows the PDH signal rather than SEG 4 I.
Then tried the same test for WFS2. The SEG4 I signal has the sign-flipped PDH signal compared to WFS2 SEG1I-SEG3I.

I quickly adjusted the demod phase of WFS1 SEG4 and WFS2 SEG4 to correct them,

WFS1 SEG4 103.9-> -20
WFS1 SEG4 -58  -> 120

This in fact made the pitch and yaw separated but flipped (Pitch signal shows up in WFS1Y and yaw signal shows up in WFS1P. Same for WFS2)

These modifications were reverted upon my leaving.

Now things are much more subtle now. And I need to do a more careful quantitative analysis of the demodulation phases / input matrix / output matrix.

Note: It seems that I had worked on IMCWFS on Dec 21, 2016

Continued to work on the WFS repair

Demod phase adjustment:

- Use the PDH signal to adjust the demodulation phase to have uniform signals between the segments.

- Excited laser frequency at 1234Hz by injecting 10mVpp into IMC Servo Board IN2. The input was enabled on the MC Servo screen and given the input gain of 0dB.

- Looked at the ~real time spectrum in WFS1/2 SEG1/2/3/4 I&Q after the phase rotators. Changed the demod phases 1) to have ~0deg transfer function between C1:IOO-MC_F to C1:IOO-WFSi_Ij 2) to minimize the freq signal in Q phases.
(See Attachment 1)

- Resulting change of the demod phases:

WFS1 SEG1  52.0 -> 38.0deg
WFS1 SEG2  54.0 -> 53.0deg
WFS1 SEG3  16.6 -> 33.2deg
WFS1 SEG4 103.9 ->-37.1deg

WFS2 SEG1  17.0 -> 57.8deg
WFS2 SEG2  26.6 -> 51.5deg
WFS2 SEG3  24.5 -> 44.0deg
WFS2 SEG4 -58.0 ->103.7deg

SEG4 of both WFSs had significant phase rotation. A quick check of the power spectrum indicates that the Q signals have significantly (<x1/10) lower signals (Attachment 2/3/4). So that's good.

Transfer function measurement

Now the ASCPIT/ASCYAW of the MC1/2/3 suspension were excited and the transfer functions to WFS1/2 SEG1/2/3/4 and MC Trans P/Y were measured. The analysis will come later.

Again here the Q signals have significantly lower sensitivity to the mirror motion. So it is consistent with the above observation of the spectra.

However, the quick check of the transfer functions indicated that the conventional input matrices result in the flipped dependence of the combined error signals in pitch and yaw.
This might indicate that some of the cables were not inserted into the demod board properly although the cables at the demod boards show no indication of anomaly. (See the photos in ELOG 17048)
It might be the case that the cable had been inserted with a special unusual arrangement.

In any case, this can be fixed at the input matrix. Native change of the input matrix made WFS1PIT/WFS1YAW/WFS2PIT/WFS2YAW/MC2Trans YAW servos running (after some adjustment of the servo signs).
The MC2TRANS PIT servo didn't seem to settle and run away no matter which sign is used.

It's probably better to look at the sensing matrix and figure out the proper input/output matrix carefully. So at this moment, no WFSs are working.

Note that I left the new demod phases in the system

During the transfer function measurement some filters were turned off to make the shaking smoother:

IMC ASC filters were turned off to make the FResp flat:
- MC1 ASCP/Y FM1/FM5 OFF
- MC2 ASCP/Y FM1/FM5/FM6 OFF
- MC3 ASCP/Y FM1/FM5 OFF

60Hz comb OSEM Input filters were also turned off to make the transfer functions simpler:
- MC1 INPUT FM2 OFF (60Hz comb)
- MC2 INPUT FM2 OFF (60Hz comb)
- MC3 INPUT FM2 OFF (60Hz comb)

cf. Past IMCWFS commissioning http://nodus.ligo.caltech.edu:8080/40m/12684

OK... It seems that all the 6 dof of the IMC WFS servo loops were closed with some condition...

- Measured the transfer functions from ASCPIT/YAW_EXC of each suspensions to WFS segs.
- FInd the proper input matrix for PIT and YAW for WFS1 and WFS2
- Closed loops one by one => This was not so successful because the loop shape was quite conditional.
- Closed WFS1/WFS2 loops one by one only with FM4 (0.8Hz Zero / (100Hz pole)^2). Adjust the gains to have the UGF at a few Hz.

- Found that the separation between WFS1P and WFS2P was not good. This caused instability of these loops when the gains were matched. I ended up lowering the gain of WFS1P by a factor of 10. This made the loop OK to work. FM3 (Integrator below 0.8Hz) worked fine.

- FM9 Rolloff filters (RLP12) makes the loops unstable.

- The MC2 spot loops (MC2_TRANS_PIT/YAW) are supposed to be slow loops. From the time series behavior it looks they are working.

MEDM Snapshots (Attchaments 1~4)

Sensing matrix measurement

MCx_ASCyyy_EXC was shaken with the amplitude of 3000 cnt. Measure the transfer functions to each segment of the WFS I&Q demod outputs.

- Pitch excitations consistently indicated WFS1 SEG2&3 / SEG1&4, and WFS2 SEG 1&2 / SEG 3&4 are the pairs.
- Yaw excitations consistently indicated WFS1 SEG1&2 / SEG3&4, and WFS2 SEG 1&4 / SEG 2&3 are the pairs.

---> WFS1P matrix {1,-1,-1,1}, WFS1Y matrix {1,1,-1,-1}, WFS2P matrix {1,1,-1,-1}, WFS2Y matrix {-1,1,1,-1}

Now look at the servo input. The following lists show the important numbers for the actuation to sensor matrices. The numbers were the measured transfer function between 7~10Hz and the unit is 1/f^2 [cnt/cnt].

CHA:, C1:SUS-MC1_ASCPIT_EXC, CHB:, C1:IOO-WFS1_I_PIT_OUT, -77.4602 +/- 18.4495
CHA:, C1:SUS-MC1_ASCPIT_EXC, CHB:, C1:IOO-WFS2_I_PIT_OUT, -22.6042 +/- 5.289
CHA:, C1:SUS-MC1_ASCPIT_EXC, CHB:, C1:IOO-MC_TRANS_PIT_OUT, -0.0007949 +/- 0.00019046
CHA:, C1:SUS-MC1_ASCYAW_EXC, CHB:, C1:IOO-WFS1_I_YAW_OUT, -60.5557 +/- 14.1008
CHA:, C1:SUS-MC1_ASCYAW_EXC, CHB:, C1:IOO-WFS2_I_YAW_OUT, -206.3526 +/- 47.1332
CHA:, C1:SUS-MC1_ASCYAW_EXC, CHB:, C1:IOO-MC_TRANS_YAW_OUT, 0.00027094 +/- 6.6131e-05

CHA:, C1:SUS-MC2_ASCPIT_EXC, CHB:, C1:IOO-WFS1_I_PIT_OUT, 57.8636 +/- 35.3874
CHA:, C1:SUS-MC2_ASCPIT_EXC, CHB:, C1:IOO-WFS2_I_PIT_OUT, -185.079 +/- 104.679
CHA:, C1:SUS-MC2_ASCPIT_EXC, CHB:, C1:IOO-MC_TRANS_PIT_OUT, 0.00089367 +/- 0.00052603
CHA:, C1:SUS-MC2_ASCYAW_EXC, CHB:, C1:IOO-WFS1_I_YAW_OUT, -349.7898 +/- 202.967
CHA:, C1:SUS-MC2_ASCYAW_EXC, CHB:, C1:IOO-WFS2_I_YAW_OUT, -193.7146 +/- 111.2871
CHA:, C1:SUS-MC2_ASCYAW_EXC, CHB:, C1:IOO-MC_TRANS_YAW_OUT, 0.003911 +/- 0.0023028

CHA:, C1:SUS-MC3_ASCPIT_EXC, CHB:, C1:IOO-WFS1_I_PIT_OUT, 65.5405 +/- 14.305
CHA:, C1:SUS-MC3_ASCPIT_EXC, CHB:, C1:IOO-WFS2_I_PIT_OUT, 78.8535 +/- 17.1719
CHA:, C1:SUS-MC3_ASCPIT_EXC, CHB:, C1:IOO-MC_TRANS_PIT_OUT, -0.00087661 +/- 0.00020837
CHA:, C1:SUS-MC3_ASCYAW_EXC, CHB:, C1:IOO-WFS1_I_YAW_OUT, -130.7286 +/- 29.6898
CHA:, C1:SUS-MC3_ASCYAW_EXC, CHB:, C1:IOO-WFS2_I_YAW_OUT, 129.0654 +/- 28.6328
CHA:, C1:SUS-MC3_ASCYAW_EXC, CHB:, C1:IOO-MC_TRANS_YAW_OUT, -0.00024944 +/- 5.9112e-05

Put these numbers in the matrix calculation and take the inverse for pitch and yaw separately.

We obtained

WFS1P    WFS2P    MCTP    
-4.017   -4.783   -7.306e5   MC1P
 3.611   -5.252   -2.025e5   MC2P
 7.323   -1.017   -6.847e5   MC3P

WFS1Y    WFS2Y    MCTY    
-3.457   -4.532   -5.336e5   MC1Y
-0.1249   0.3826   2.635e5   MC2Y
-5.714    1.076   -4.578e5   MC3Y

Basically we can put these numbers into the output matrix. The last column corresponds to the spot position servo and we want to make this slow.
So used x1e-5 values (i.e. removed e5) instead of these huge numbers.

WFS/MCTRANS_QPD Power Spectra

Attachment 1: HEPA ON

WFS1/2 PIT/YAW Spectra are stabilized below 1Hz (0.1Hz for WFS1P)

MC2 TRANS PIT is largely contaminated by the other WFS loops.
MC2 TRANS YAW is slightly contaminated but not much compared to the one for pitch.

Attachment 2: HEPA OFF

Again, WFS1/2 PIT/YAW Spectra are stabilized below 1Hz (0.1Hz for WFS1P)

MC2 TRANS PIT is still contaminated but better.
MC2 TRANS YAW is not contaminated.

Observation

WFS1/2 signals are largely disturbed when PSL HEPA is ON. Probably the amount of HEPA air flow was not optimized.
Above 1Hz, invacuum suspension are quieter than the beam incident on the IMC.

The dirty WFS signals are fedback to the mirrors. Due the large motion of the beam and also the imperfection of the actuator matrix cause the MC2 spot rather moves than stabilized.

This means that the WFS loops should leave the mirrors untouched above 1Hz i.e. The loop bandwidths should be low (~<0.1Hz). (Yes I know)
However, the simple gain reduction (x10) does make the servos unstable. So more adjustment is necessary. (<-Not for today)

Upon leaving the lab:

- HEPA is ON at the original speed (i.e. same speed at 5PM today)

- WFS servo is ON, partly because we want to see how stable it is. It is not handled with the autolocker right now.
So there is a possibility that the WFS servo goes wild and make the IMC totally misaligned (and does not come back)
In such a case, go to the WFS servo screen and push "CH" (clear history) of each servo filters.

The IMC lock survived overnight and the WFS servo loops kept it aligned. The IMC was unlocked in the morning.
The left 6 plots are the WFS servo outputs and the right most two plot show the transmission and reflection of the IMC.

If the WFS is making the lock unstable under high seismic conditions, please turn the loops off.

After the CDS upgrade team called for a day (their work TBD), I took over the locked IMC to check how it looked like.

The lock was robust but the IMC REFL spot and the WFS DC/MC2 QPD were moving too much.
I wondered if there were something wrong with the damping. I thought MC3 damping seemed weak, but this was torelable level.LR
During the ring down check of MC2, I saw that the OSEM signals were glitchy. In the end I found it was LR sensor which was glitchy and fluctuating.

I went into the lab and pushed the connectors on the euro card modules and the side connectors as well as the cables on the MC2 sat amp.
I came back to the control room and found the MC2 LR OSEMs had the jump and it seems more stable now.

I leave the IMC locked & WFS running. This sus situation is not great at all and before we go too far, we'll work on the transition to the new electronics (but not today or next week).

By the way the unit of the signals on the dataviewer didn't make sense. Something seemed wrong with them.

The IMC and the IMC WFS kept running for ~2days. 👍

I wanted to look at the trand of the IMC REFL DC, but the dataviewer showed that the recorded values are zero. And this slow channel is missing in the channel list.

I checked the PSL PMC signals (slow) as an example, and many channels are missing in the channel list.

So something is not right with some part of the CDS.

Note that I also reported that the WFS plot in the above refered previous elog has the value like 1e39

Thanks for pointing out that EPICS data collection (slow channels) was not working. I started the service that collects these channels (standalone_edc, running on c1sus), and pointed it to the channel list in /opt/rtcds/caltech/c1/chans/daq/C0EDCU.ini, so this should be working now.

[Tega, Anchal]

c1mcs and c1ioo models have been updated to add new acquisition of data.

IOO:WFS channels

We found from https://ldvw.ligo.caltech.edu/ldvw/view that following channels with "WFS" in them are acquired at the sites:

• :IOO-WFS1_IP
• :IOO-WFS1_IY
• :IOO-WFS2_IP
• :IOO-WFS2_IY

These are most probably error signals of WFS1 and WFS2. At 40m, we have following channel names instead:

• C1:IOO-WFS1_I_PIT_OUT
• C1:IOO-WFS1_I_YAW_OUT
• C1:IOO-WFS2_I_PIT_OUT
• C1:IOO-WFS2_I_YAW_OUT

And similar for Q outputs as well. We also have chosen quadrature signals (signals after sensing matrix) at:

• C1:IOO-WFS1_PIT_OUT
• C1:IOO-WFS1_YAW_OUT
• C1:IOO-WFS2_PIT_OUT
• C1:IOO-WFS2_YAW_OUT

We added following testpoints and are acquiruing them at 1024 Hz:

• C1:IOO-WFS1_IP  (same as C1:IOO-WFS1_I_PIT_OUT)
• C1:IOO-WFS1_IY  (same as C1:IOO-WFS1_I_YAW_OUT)
• C1:IOO-WFS2_IP  (same as C1:IOO-WFS2_I_PIT_OUT)
• C1:IOO-WFS2_IY  (same as C1:IOO-WFS2_I_YAW_OUT)

IOO-MC_TRANS

For the transmission QPD at MC2, we found following acquired channels at the site:

• :IOO-MC_TRANS_DC
• :IOO-MC_TRANS_P
• :IOO-MC_TRANS_Y

We created testpoints in c1mcs.mdl to add these channel names and acquire them. Following channels are now available at 1024 Hz:

• C1:IOO-MC_TRANS_DC
• C1:IOO-MC_TRANS_P
• C1:IOO-MC_TRANS_Y

We started acquiring following channels for the 6 error signals at 1024 Hz:

• C1:IOO-WFS1_PIT_IN1
• C1:IOO-WFS1_YAW_IN1
• C1:IOO-WFS2_PIT_IN1
• C1:IOO-WFS2_YAW_IN1
• C1:IOO-MC2_TRANS_PIT_IN1
• C1:IOO-MC2_TRANS_YAW_IN1

We started acquiring following 6 control signals at 1024 Hz as well:

• C1:IOO-MC1_PIT_OUT
• C1:IOO-MC1_YAW_OUT
• C1:IOO-MC2_PIT_OUT
• C1:IOO-MC2_YAW_OUT
• C1:IOO-MC3_PIT_OUT
• C1:IOO-MC3_YAW_OUT

RXA: useful to know that you have to append "_DQ" to all of the channel names above if you want to find them with nds2-client.

Other changes:

In order to get C1:IOO-MC_TRANS_[DC/P/Y], we had to get rid of same named EPICS output channels in the model. These were been acquired at 16 Hz before this way. We then updated medm screens and autolocker config file. For slow outputs of these channels, we are using C1:IOO-MC_TRANS_[PIT/YAW/SUMFILT]_OUTPUT now. We had to restart daqd service for changes to take effect. This can be done by sshing into fb1 and running:

Now there is a convinient button present in FE overview status medm screen to restart DAQD service by a simple click.

in looking closer at the IMC WFS performance I notice 2 issues:

1. the watchdog thresholds are set to 200 mV, but this only made sense back when the OSEM calibration was 2 V/mm. Because of the increased analog gain(?) the RMS value of the watchdog sensors is now ~35 mV for MC1, so it will trip its watchdog and unlock the IMC with a 10x smaller seismic impulse than before. I recommend changing the watchdog thresholds appropriately changing the OSEM sensor signals to something so that its the same for all SUS.
2. For the MC SUS, the F2P or F2A decoupling filters are not on. SO the POS damping loop is injecting a lot of pitch noise into the mirrors. We could perhaps lower the ~1 Hz angular motion by commissioning those filters for the MC optics. Does anyone know why we have several filters in those filter banks? I think we could contain it all in 1, although its fine to make a few different ones with different Q's for testing the performance.

Turned HEPA OFF / Lab Lights OFF / WFS Input Gain switched off for the IMC WFS signal tests.
The IMC is still well aligned.

Clean data from the following time:
2022/10/26 5:24:00 UTC (10/25 22:24 PDT)
GPS 1350797056

Turned HEPA ON this morning at 10:28 local (pacific time) or gpstime = 1350802758. WFS ON right after that. IMC was locked and nominally aligned at this time.

• looking at some IMC WFS swept sines, it seems like there is poor margin around 1 Hz
• increasing the overall gain (input) by 2x makes the whole system shake a lot at ~1Hz
• increasing the input gain from 1 to 4 makes the lock break due to oscillations
• I have turned the input slider to 0.5 just now, but it will revert to 1 after the next lock loss for tonights testing
• we can use the observations from now for an hour or so to see if 0.5 is better for the 1 Hz behavior (lets look at the summary pages)

Made a comparison plot between the WFS1 PIT loop and the model. There is good agreement.

• I have had trouble increasing the UGF to > 1 Hz. Usually some instability ~1 Hz.
• Took a swept sine TF of WFS1 P, with the all 6 angular loops closed. The UGFs are all <0.1 Hz or so, so I think it doesn''t affect the loop shapes around 1 Hz.
• The model was not agreeing with the measurement. In addition to the pendulum TF and the WFS1 PIT filters, I had to add the Bounce/Roll mode bandstop filters, and the 28 Hz elliptic low pass which is the post DAC low pass (aka dewhitening filters).
• I expect that some of the wiggles around 1 Hz are due to modeling the pendulum as a viscous damped pendulum, rather than the OSEM damping loop.

Next, I will try to do some loopology to increase the phase margin around 1-3 Hz. HEPA in OFF state for now - please turn on in the morning.

I added a less agressive low pass filter to give some more phase margin, and then increased the overall gain by 4x. There is now some suppression around 1 Hz.

In the attached plot:

1. HEPA ON is the grey traces. Nothing surprising there.
2. The dark PURPLE traces are HEPA OFF, old gain/filter settings.
3. Colorful traces: RLP20 instead of RLP12. input gain slider = 4.0

Its clear from this that the WFS2 PIT servo has a very low gain. There's no UGF bump in the spectra.

I also added a 6 Hz : 3 Hz pole:zero pair to give some phase lead. Turning this on reduces some gain bump in pitch, but makes the WFS1 Yaw loop oscillate.

changed some y-scale limits on the WFS summary pages to zoom in better

I've updated c1ioo model with adding WFS sensor to optic angle matrix and output filter module option. The output filter modules are named like EST_MC1_PIT to signify that that these are "estimated" angles of the optic. We can change this naming convention if we don't like it. I've also started DQ on the outputs of these filter moduels at 512 Hz sampling rate.

No medm screens have been made for these changes yet. One can still access them through:

For SENS_TO_OPT_P Matrix

For SENS_TO_OPT_Y Matrix

For filter modules:

I confirmed that MC Length feedback path to MC2 position is present and has been turned off in recent history. Feedback filter module can be seen in sitemap>IOO>Lock MC>MC2_LSC where the bottom fitler module is for feeding back MC Length to MC2. See attached screenshot.

This feedback signal goes and gets added to MC2 suspension longitudnal signal through ALTPOS path which is nominally not shown in any of the suspension screens (including the old ones). Note that this path is different than the LSC path that comes into each suspension screen.

Today, I tried a quick turning ON of this apth without playing around with any of the filters to see if the feedback helps. On first glance, it does not seem to help. Probably the gain values and filter modules need ot be adjusted. See attachment 2.

I'm turning this off again and in future someone should take a look at this loop.

this afternoon I did some swapping around of linear and RL for IMC WFS.

In the end, I left in in the 'both' state:

• The WFS1,2,MC_TRANS PIT loops are all on but with -40, -40, -20 dB of nominal gain
• the RL is on for PIT

this is so that we have good DC control with integrators and good HF performance too.

{JC, Yehonathan}

When JC came this morning the IMC was completely misaligned. After tweaking the MC alignment we realized the MC WFS where comletely off the rail. We cleared their history and returned the suspensions to their original position. MC locked immediately.

However there still issues:

1. When WFS where turned on it (now its at 8.194) would slowly misalign the IMC.

2. PMC would get unlocked very quickly everytime the IMC tweaked due the PMC input offset being at the slider's edge at 10V.

First we dealt with the PMC issue. We brought the offset down and tried locking the PMC. When it didn't work we went to the PMC table and connected a triangular wave to EXT DC in the PMC servo. PMC reflection and tansmission where observed using a scope while triggering on the triangular wave.

We changed the input volatge until we could see transmission peaks during the voltage ramp. We aligned the PMC so that the HOMs are minimized. We were then able to lock the PMC at an offset input voltage of 8.2V. Transmission is at 0.67V REFL is at 0.03V.

WFS Servo fix:

We went to the AS table and centered the WFS. We run correct DC and AC WFS offset scripts. When then we locked the IMC and turned on the WFS servo. This time the WFS didn't rail, at least not for the last 1 hour. We also realigned MC2 transmission QPD.

1. Well, it seems that the PMC error offset issue still remains.

2. The IMC transmon QPD had been aligned for some reference e.g. Max transmission, Center of the MC2 mirror, lowest noise, or else. It's not arbitrary.
    Find the appropriate spot poisiton and then align the QPD for the given spot.

I went down to the IFO hall and checked the PMC situation. The freq mixer fixed on the rack 1X1 had BNC-T, so the raw error was checked while the PMC was swept around the resonance.
The error signal was ~1mVpp while there is ~1mV offset.

There are a few possibilities: modulation, beam, PD, demodulator, or something else.

I checked if the PD was busted, misaligned, unpowered, etc, but there was no clear sign of what was wrong.
The beam was not well steered on the PD but realigning the PD didn't help the size of the error signal.

Modulation... a possibly high-power RF amp is usually delicate so without consulting with the circuit schematic, I did not want to disconnect the output from a proper load.
Instead, I just checked the modulation level monitor on the PMC Phaseshifter screen. C1:PSL-PMC_MODET said 0~-0.004, which didn't mean anything.
By the way, the LO output had ~1Vpp observed with 50ohm termination on an oscilloscope. That looked OK.

But the history of this channel told us that there was some negative number, which we lost ~3.5 days ago. So it's suspicious.

I checked the circuit schematic of the oscillator box D980353. As I said, the LO was OK. So the oscillator would also be OK. Maybe the EOM path has something.
There is a notorious ERA-5SM in the path. So the first thing to check is this chip. Of course, we have many spares in the blue tower.
 

[JC, Yuta]

PMC was unlocked from last night, so we aligned PMC
c1sus2 crashed again during the PMC alignment, so we ran

./opt/rtcds/caltech/c1/Git/40m/scripts/cds/restartAllModels.sh

We burt restored to 2023/Aug/14/16:19 by

./opt/rtcds/caltech/c1/Git/40m/scripts/cds/burtRestoreAndResetSUS.sh /opt/rtcds/caltech/c1/burt/autoburt/snapshots/2023/Aug/14/16:19

Summary

The problem in the PMC Frequency Reference Card (35.5MHz) was fixed.
The last opamp stage of the attenuator control (LT1125) had the negative rail, and the EOM drive level was maximally attenuated.
The chip was replaced, and the card was back in the euro crate. The PMC is locking as before.

Diagnosis

Yesterday, I already found that the modulation level was basically zero and had no response to the level slider. Today, the card was extracted from the rack and tested on the workbench. It required +/-24V supplies for the main power and +10V supply for high-power RF amps (SMA-202). Additionally, a function generator to supply a DC voltage is needed to tune the attenuation level manually. (Attachment 1)

Some notes:
- This circuit was previously fixed in 2015 by Yutaro and me: [ELOG 11763]
- Even before that, Jenne and Rana looked at the board for LO fix in 2014 [ELOG 10160]
- The boards DCC number is D980353 however the 35.5MHz version is D000419 and the 40m version has a dedicated DCC number D1400221

Initial look was horrible because some greasy material was covering some parts on the boards (I had the same thing in 2015 too). It turned out that it is a leaked thermal paste from the heat sink at the bottom side. (Attachment 2)

Firstly, the suspicious ERA-5SM was checked. The attenuator control path was suspiciously dead (-5V) but the function generator was attached to the attenuator control pin, the ERA-5SM in the EOM path received the signal and it was working fine(!). The ERA-5SM received 20mVpp and spit out 270mVpp, observed with a 1/10 probe. The LO path one was also alive, receiving 173mVpp_max and yielding 200mVpp.

Then, the high-power amps (SMA-202) were checked. This is an old chip which is not commercially available anymore. So I thought I would be reluctant to replace it was broken. But the amps were just fine. With the above condition, the LO and PC paths' outputs were ~9Vpp and 6.1Vpp.

Now I went into the attenuator control part. And it turned out that the last stage (low pass filter part) was broken. By replacing the LT1125, the attenuator control chain recovered the function. (Attachment 3)

Calibration

The attenuator control voltage was applied to the board, then this control voltage was measured together with the RF output powers (LO and PC). (Attachment 4)

LO power is about 16dBm~17dBm and almost independent with the setting (as expected).
PC power changes from -24dBm to +25dBm.

Attachment 5 is the relationship between the PC RF power and the MODEL Voltage measured in analog.

Restore the setting:

The module was returned to the rack. One thing we should take care of is that the external 10V should be disconnected when the output is not terminated with 50Ohm loads. This is to protect SMA-202 from reflection damage.

Once the board was secured and the 10V supply was connected, the MODET voltage was dependent on the slider setting. The PC output RF power was calibrated against the RFADJ setting. (Attachment 6) It is consistent with the above analog measurements.

The RF level (C1:PSL-PMC_RFADJ) was set to 6.0. This imposes the PC output of +14dBm. C1:PSL-PMC_MODET came back to ~-0.34, which is consistent with the number before the trouble.
I also checked the LO power in situ. The direct output was ~17dBm and the 9dB attenuator made the LO level down to 8dBm. The mixer is ZAD-6, which is 7dBm LO level. So it looks fine.

PDH error signal

The amplitude of the PDH error signal was observed at the IF output of the frequency mixer. The cavity was swept around one of the resonances. It showed a clear PDH error shape with the P-P amplitude of ~130mV. (Attachment 7)

By the way, the PMC error offset slider was swept while the cavity was locked. The error signal indicated

The error signal / Offset slider value
-5.23mV / +10V
-6.11mV / 0V
-7.03mV / -10V
It seems that there is a 1/10⁴ reduction factor between the slider value and the actual applied voltage.

[Paco, Murtaza, JC]

Fixed C1SUS2 Crash from this morning

What we did:
  - Attempt to restart only C1SUS2
  - Restart All Machines and Burt Restored to Friday @ 7:19 pm

Summary:

Entering this morning, We were unsure why we were having issues aligning and come to find out that C1SUS2 crashed. Paco attempted to restore by restarted the machine individually and restoring, while this did turn all the machines green on the CDS.MEDM Screen, it did not resolve the issue. So moving forward, please keep in mind that EVEN IF ALL MACHINES SHOW GREEN, OPTICS MAY STILL NOT BE DAMPING. 

Next we continued to restart and reboot the old fashioned way.

I attempted to use the ./restartAllModels.sh script in the "/opt/rtcds/caltech/c1/Git/40m/scripts/cds" directory, but there was an error and the message I got said something along the lines of "Restart medm screen and try again". This was weird and all of the machines were already shutdown. So, to bring them back up, I used the ./startAllModels.sh script. When starting up, i was prompted to provide a burtrestore directory, and I inputted /opt/rtcds/caltech/c1/burt/autoburt/snapshots/2023/Sep/22/20:19.

This worked out and IMC came back to nominal alignment. The primary issue we seem to be coming across now is that C1:IOO-WFS2_PIT_OUTPUT is increasing at a steady rate and this is disrupting our alignment.

Attached are both the circuit diagram and the liso formatted *.fil for the main branch of the ISS, as well as the resulting transfer function when analyzed. Unfortunately, as noted in the file, not all of the elements are possible to analyze in liso, such as any type of op-amp with more than two inputs and one output (AD602 used in this design has 16 pins with two distinct amplifiers contained within).

I have begun prototyping this circuit on a breadboard.

Typically, you can still find a way to model the important parts of the stages that are not as simply added. In the case of the differential input stage, in particular, it is important to include it because it will usually set the input noise level of the circuit. In this case, the noise is the same as the second stage (U5) and it has a gain of 1, so there is essentially no difference (up to factors of sqrt(2) or 2).

You can edit the opamp.lib file and add in custom components. For the input stage, you can just pretend it is a simple non-inverting amplifier with the specified noise characteristics from the datasheet: un = 1.3n, uc = 50 Hz (see below).

For dual op amps, you can usually just model each part separately. For example, the OPA2604 is a dual op amp that is included in the opamp.lib and can be treated as a single one in a model.

After spending a good deal of time learning how to use the SR785, I was able to characterize my prototype circuit. The transfer function from a swept sine measurement looks very similar to the theoretically calculated transfer function (both of which are attached). The frequency response of the circuit was considered over the range 10 Hz - 10 kHz, which contains the eventual working range of the ISS (at least to my knowledge).

Note that OP27 op-amps were used instead of the high-speed AD829 op-amps that will be implemented in the actual design. This was done as a result of the limitations and inherent noise characteristics of the breadboard on which the prototype was built.

Unfortunately, I saved the wrong dataset (i.e. phase of the transfer function, not magnitude) and thus the presented function here is image generated by the SR785.

RXA: One must learn to use the python-GPIB interface to not lose data in the future.

In order to allow other individuals besides myself to consider the proposed design of the ISS, I have created a publicly available CircuitLab drawing, which can be found here: CircuitLab Drawing. For simplicity, I have used ideal op-amps without voltage rails or their associated power supplies. In the actual implementation of the ISS, we will most likely also have trim resistors to ensure a zero offset for each op-amp. We interpret the PD as a voltage source for simplicity and I will use an actual summing amplifier in place of the summing junction used in the diagram.

The diagram linked above is simply a naive copy of a design by Rich Abbott so there are most likely mistakes and/or unnecessary elements, but it is a work in progress. I began discussing, with Jamie, the relative use of the first few filter stages in the servo. As far as my understanding goes, the first 'stage' was part of cascade of op-amps that served to convert a differential input from the PD into a single DC signal referenced to ground. Indeed, the first stage of my diagram (U1) is simply a unity-gain low-pass filter with f~5 MHz. Additionally, the second filter 'stage', U2, is also a unity-gain low-pass filter although it introduces a phase shift of 180 deg as the input to the second stage is on the inverting input of the op-amp. These characteristics were determined using LISO and examining the transfer function.

Noise analysis was also performed for the above circuit. The noise from various elements is examined at the output of the servo (labeled as 'outU6' in my LISO file). In the attached diagram, we see the voltage noise at the output from each op-amp as well as the sum of all the various noises, which includes resistor noise and current noise from the inputs of each op-amp. These are LISO's standard considerations and it is also worthwhile to note that the result is not referred to the circuit input, but as we have the transfer function of the whole servo, referring the noise to the input is trivial.

I have also included the following output for the sake of completeness.

from 1 Hz onwards noise by OP:I+ (U3) dominates.

from 38.6812 Hz onwards noise by R(R24) dominates.

from 115.478 Hz onwards noise by R(R11) dominates.