To obtain a colored version with good contrast of the grayscale image of scattering of light by dust particles on the surface of test mass, got using GigE camera. The original and colored images are attached here.

Aim: To find telescopic lens solution to image test mass onto the sensor of GigE camera.

I wrote a python code to find an appropriate combination of lenses to focus the optic onto the camera keeping in mind practical constraints like distance of GigE camera from the optic ~ 1m and distance between the lenses need to be in accordance with the Thorlab lens tubes available. We have to image both the enire optic of size 3" and beam spot of 1" using this combination of lens. The image size that efficiently utilizes the entire sensor array is 1/4". Therefore the magnification required for imaging the entire optic is 1/12 and that for the beam spot is 1/4.

I checked the website of Thorlabs to get the available focal lengths of 2" lenses (instead of 1" lenses to collect sufficient power). I have tried several combination of lenses and the ones I found close enough to what is required have been listed below along with thier colorbar plots.

a) 150mm-150mm (Attachment 2 & 3)

With this combination, object distance varies like 50cm for 1" beam spot to 105cm for 3" spot. Therefore, it posses a difficulty that there is a difference of ~48cm in the distances between the optic and camera in the two cases: imaging the entire optic and the beam spot.

b) 125mm-150mm (Attachment 4 & 5)

With this combination, object distance varies like 45cm for 1" beam spot to 95cm for 3" spot. There is a difference of ~43cm in the distances between the optic and camera in the two cases: imaging the entire optic and the beam spot.

c) 125mm-125mm (Attachment 6 & 7)

The object distance varies like 45cm for 1" beam spot to 90cm for 3" spot. There is a difference of ~39cm in the distances between the optic and camera in the two cases: imaging the entire optic and the beam spot.

Sensitivity check was also done for these combination of lenses. An error of 1cm in object distance and 5mm in the distance between the lenses gives an error in magnification <2%.

The schematic of the telescopic lens system has been given in Attachment 8.

Set up gwsumm on optimus and generated summary pages from both L1 and C1 data. Still a few manual steps need to be taken during generation, not fully automated due to some network/username issues. nds2 now working from optimus after restarting nds2 server.

Found 1 out of 2 bluebird microphones in the 40m.

Found 60 EM172 microphones. Previous elog with details: 7777.

There has been an ongoing memory error in optimus with the following messages:

controls@optimus|~ >
Message from syslogd@optimus at Jun 30 14:57:48 ...
 kernel:[1292439.705127] [Hardware Error]: Corrected error, no action required.

Message from syslogd@optimus at Jun 30 14:57:48 ...
 kernel:[1292439.705174] [Hardware Error]: CPU:24 (10:4:2) MC4_STATUS[Over|CE|MiscV|-|AddrV|CECC]: 0xdc04410032080a13

Message from syslogd@optimus at Jun 30 14:57:48 ...
 kernel:[1292439.705237] [Hardware Error]: MC4_ADDR: 0x0000001ad2bd06d0

Message from syslogd@optimus at Jun 30 14:57:48 ...
 kernel:[1292439.705264] [Hardware Error]: MC4 Error (node 6): DRAM ECC error detected on the NB.

Message from syslogd@optimus at Jun 30 14:57:48 ...
 kernel:[1292439.705323] [Hardware Error]: cache level: L3/GEN, mem/io: MEM, mem-tx: RD, part-proc: RES (no timeout)

Optimus is a Sun Fire X4600 M2 Split-Plane server. Based on this message, the issue seems to be in memory controller (MC) 6, chip set row (csrow) 7, channel 0. I got this same result again after installing edac-utils and running edac-util -v, which gave me:

mc6: csrow7: mc#6csrow#7channel#0: 287 Corrected Errors 

and said that all other DIMMs were working fine with 0 errors. Each MC has 4 csrows numbered 4-7. I shut off optimus and checked inside and found that it consists of 8 CPU slots lined up horizontally, each with 4 DIMMs stacked vertically and 4 empty DIMM slots beneath. I'm thinking that each of the 8 CPU slots has its own memory controller (0-7) and that the csrow corresponds to the position in the vertical stack, with csrow 7 being the topmost DIMM in the stack. This would mean that MC 6, csrow 7 would be the 7th memory controller, topmost DIMM. The channel would then correspond to which one of the DIMMs in the pair is faulty although if the DIMM was replaced, both channels 0 and 1 would be switched out. Here are some sources that I used:

http://docs.oracle.com/cd/E19121-01/sf.x4600/819-4342-18/html/z40007f01291423.html#i1287456

https://siliconmechanics.zendesk.com/hc/en-us/articles/208891966-Identify-Bad-DIMM-from-EDAC

http://martinstumpf.com/how-to-diagnose-memory-errors-on-amd-x86_64-using-edac/

I'll find the exact part needed to replace soon.

After hardware errors prevented me from using optimus, I switched my generation of summary pages back to the clusters. A day's worth of data is still too much to process using one computer, but I have successfully made summary pages for a timescales of a couple of hours on this site: https://ldas-jobs.ligo.caltech.edu/~praful.vasireddy/

Currently, I'm working on learning the current plot-generation code so that it can eventually be modified to include an interactive component (e.g., hovering over a point on a timeseries would display the GPS time). Also, the 40m summary pages have been down for the past 3 weeks but should be up and working soon as the clusters are now alive.

I've added a new tab for VMon under the SUS parent tab. I'm still working out the scale and units, but let me know if you think this is a useful addition. Here's a link to my summary page that has this tab: https://ldas-jobs.ligo.caltech.edu/~praful.vasireddy/1151193617-1151193917/sus/vmon/

I'll have another tab with VMon BLRMS up soon.

Also, the main summary pages should be back online soon after Max fixed a bug. I'll try to add the SUS/VMon tab to the main pages as well.

The main C1 summary pages are back online now thanks to Max and Duncan, with a gap in pages from June 8th to July 4th. Also, I've added my new VMon and Sensors tabs to the SUS parent tab on the main pages. These new tabs are now up and running on the July 7th summary page.

Here's a link to the main nodus pages with the new tabs: https://nodus.ligo.caltech.edu:30889/detcharsummary/day/20160707/sus/vmon/

And another to my ldas page with the tabs implemented: https://ldas-jobs.ligo.caltech.edu/~praful.vasireddy/1150848017-1150848317/sus/vmon/

Let me know if you have any suggestions or see anything wrong with these additions, I'm still working on getting the scales to be right for all graphs.

Optimus' memory errors are back so I found the exact DIMM model needed to replace: http://www.ebay.com/itm/Lot-of-10-Samsung-4GB-2Rx4-PC2-5300P-555-12-L0-M393T5160QZA-CE6-ECC-Memory-/201604698112?hash=item2ef0939000:g:EgEAAOSwqBJXWFZh I'm not sure what website would be the best for buying new DIMMs but this is the part we need: Samsung 4GB 2Rx4 PC2-5300P-555-12-L0 M393T5160QZA-CE6.

A new MEDM tab has been added to the summary pages (https://nodus.ligo.caltech.edu:30889/detcharsummary/day/20160708/medm/), although some of the screens are not updated when /cvs/cds/projects/statScreen/cronjob.sh is run. In /cvs/cds/projects/statScreen/log.txt, the following error is given for those files: import: unable to read X window image `0x20011f': Resource temporarily unavailable @ error/xwindow.c/XImportImage/5027. If anyone has seen this error before or knows how to fix it, please let me know.

In the meantime, I'll be working on creating an archive of MEDM screens for every hour to be displayed on the summary pages.

Thanks! Yes, only the screens that are not updated when the script is executed show this error. I'll try to keep debugging over the weekend.

The MEDM screen capture tab is now working and up on the summary pages: https://nodus.ligo.caltech.edu:30889/detcharsummary/day/20160725/medm/

Please let me know if you have any suggestions or notice any issues.

I recreated Den's microphone amplifier circuit on a solderless breadboard to test it and make sure it does what it's supposed to. So far it seems like everything is working- I'll do some testing tomorrow to see what the amplified output is like for some test noises. Here's the circuit diagram that Den made (his elog as well https://nodus.ligo.caltech.edu:8081/40m/6651):

I'm not sure why he set up the circuit the way he did- he has pin 7 grounded and pin 4 going to +12V while in the datasheet for the opamp (http://cds.linear.com/docs/en/datasheet/1677fa.pdf), pin 7 goes to positive voltage and pin 4 goes to negative voltage. There's some other strange things about the circuit that I don't really understand, such as the motivation for using no negative voltage source, but for now I'm going to stick with Den's design and then make some modifications after I have things working and a better understanding of the problem.

Here's my current plan:

-Make sure Den's amplifier works, test it out and make changes if necessary

-Make multiple amplifier circuits on soldering breadboard

-Either make a new amplifier box or reuse Den's old box depending on how many changes I make to the original circuit

-Solder EM172s to BNC connectors, set them up around the floor suspended

-Get the amplifier box hooked up, set up some data channels for the acoustic noise

-Add new acoustic noise tab to the summary pages

Den also mentioned that he wanted me to measure the coupling of acoustic noise to DARM.

I set up a test inverting amplifier circuit using the LT1677 opamp:

The input signal was a sine wave from the function generator with peak to peak amplitude of 20 mV and a frequency of 500 Hz and I received an output with an amplitude of about 670 mV and the same 500 Hz frequency, agreeing with the expected gain of -332k/10k = -33.2:

So now I know that the LT1677 works as expected with a negative supply voltage. My issue with Den's original circuit is that I was getting some clipping on the input to pin 2, which didn't seem to be due to any of the capacitors- I switched them all out. I set up a modified version of Den's circuit using a negative voltage input to see if I could fix this clipping issue:

I might reduce the input voltages to +5V and -5V- I couldn't get my inverting amp circuit to work with +12V and -12V. I'll start testing this new circuit next week and start setting up some amplifier boxes.

I could not get Den's circuit to work for some reason with microphone input, so I decided to try to use another circuit I found online. I made some modifications to this circuit and made a schematic:

Using this circuit, I have been able to amplify microphone input and adjust my passband. Currently, this circuit has a high-pass at about 7 Hz and a low-pass at about 23 kHz. I tested the microphone using Audacity, an audio testing program. I produced various sine waves at different frequencies using this program and confirmed that my passband was working as intended. I also used a function generator to ensure that the gain fell off at the cutoff frequencies. Finally, I measured the frequency response of my amplifier circuit:

ampTest_03-08-2016_180448.pdf

A text file with the parameters of my frequency response and the raw data is attached as well.

These results are encouraging but I wanted to get some feedback on this new circuit before continuing. This circuit seems to do everything that Den's circuit did but in this case I have a better understanding of the functions of the circuit elements and it is slightly simpler.

The Guralp cable has been pulled and put in the corner to the left of the water cooler:

Ben came by today before the cable had been pulled but he said he'll be back tomorrow.

I took the spectrum of an EM172 connected to my amplifier inside and outside a large box filled with foam layers:

I also made a diagram with my plan for the microphone amplifier boxes. This is a bottom view:

The dimensions I got from this box: http://www.digikey.com/product-detail/en/bud-industries/CU-4472/377-1476-ND/696705

This seemed like the size I was looking for and it has a mounting flange that could make suspending it easier. Let me know if you have any suggestions.

I'll be doing a Huddle test next week to get a better idea of the noise floor and well as starting construction of the circuits to go inside the boxes and the boxes themselves.
 

The Guralp cable has been reconnected and powered after having the connector changed out.
 

I set up 3 of my circuits in the interferometer near MC2 to do a huddle test. I have the signals from my microphones going into C1:PEM-MIC_1_IN1, C1:PEM-MIC_2_IN1, and C1:PEM-MIC_3_IN1. These are channels C17-C19. Here are some pictures of my setup:

I'll likely be collecting data from this for a couple of hours. Please don't touch it for now- it should be gone soon. There are some wires running along the floor near MC2 as well.

The summary pages have been updated with the new naming seismometer channel naming conventions. Here's a link to them working on my own page: https://ldas-jobs.ligo.caltech.edu/~praful.vasireddy/1154908817-1154909717/pem/seismic/
 

Let me know if the actual pages aren't working when they come back online or if there's something that needs to be changed.

The results of my first huddle test were not so good- one of the signals did not match the other two very well- so I changed the setup so that the mics would be better oriented to receive the same signal. Pictures of the new setup are attached.

I also noticed some problems with one of my microphones so I soldered a new mic to bnc and switched it out. Just judging from Dataviewer, the signals seem to be more similar now. I'll be taking data for another few hours to confirm.

I used the Wiener filtering method described by Ignacio and Jessica (https://dcc.ligo.org/DocDB/0119/T1500195/002/SURF_Final.pdf and https://dcc.ligo.org/public/0119/T1500194/001/Final_Report.pdf) and got the following results:

mic1_wiener.pdf

mic2_wiener.pdf

mic3_wiener.pdf

The channel readout has a gain of 0.0005 and the ADC is 16-bit and operates are 20V. The channel also reads the data out in Pa. I therefore had to multiply the timeseries by 1/0.0005=2000 to get it in units of counts and then by (20 Volts)/(2^16 counts) to get back to the original signal in volts. The PSDs were generated after doing this calibration. I also squared, integrated, and square rooted the PSDs to get an RMS voltage for each microphone as a sanity check:

Mic 1: 0.00036 V

Mic 2: 0.00023 V

Mic 3: 0.00028 V

These values seem reasonable given that the timeseries look like this:

timeseries_elog.pdf

I didn't have a separate training set and data set, so I think that's why the graphs came out looking too good. The units on the graphs are also incorrect, I was interpreting PSD as ASD. I haven't been able to get my Wiener filtering code working well- I get unreasonable subtractions like the noise being larger than the unfiltered signal, so Eric showed me this frequency-dependent calculation described here: https://dcc.ligo.org/LIGO-P990002

This seems to be working well so far:

freq1.pdf

freq2.pdf

freq3.pdf

Here's all the plots on one figure:

frequency_dependent.pdf

Let me know if this looks believable.

For the past week, I've been trying to make a soldered amplifier circuit to use in a prototype box, However, I've been running into this same issue. The circuit, pictured below, works fine on a solderless breadboard.

simple_amp.png

When I amplify a sine wave, I get a clean looking result at the output on the solderless breadboard:

However, on my soldered circuit, if I turn up the negative voltage supply from the power supply past about -12.5V (the target is -15V), I get a strange signal that Gautam suggested looks like some kind of discharging.

At -12.3 V (soldered breadboard):

At -15.0 V (soldered breadboard):

The signal is much noisier. Zooming in on this second signal, this pattern appears:

This pattern is also showing up even when there is no input from the function generator and the circuit is just given a voltage supply of +/- 15V:

I have tried switching out both the positive and negative voltage regulators, the opamp, and remaking and resoldering the entire circuit but I'm still getting the same signal, which is absent from the solderless circuit. This output was produced with a function generator, so I have also ruled out the microphone as a source of this extra noise. The voltage dependence of this problem made me think it was the voltage regulator, but I've switched out the voltage regulator multiple times and it's still showing up. I'm not sure why this signal appears only as the negative voltage supply is increased- there is no problem with increasing the positive input voltage. Please let me know if you have any ideas as to what component or issue could be causing this.

The temperature is decreasing slowly but is still above 24 C.

temp_plot.png

I remade another soldered circuit, adding extra 100uF electrolytic bypass capacitors at the input and output of the voltage regulator and ensuring that every grounded component now has its own path to ground rather than going through other elements. This circuit now seems to be working just like the solderless circuit. Attached is the transfer function of the soldered circuit, which matches with the result from the solderless circuit.

soldered_transfer_function.png

solderless_transfer_function.png

Here are both on the same figure- they are about overlapping but are slightly different if you zoom in enough.

both_transfer.png

I have also attached a new version of the circuit schematic to reflect the changes and to make the physical layout more clear.

simple_ampv2.pdf

My next step for these last few days this summer will be designing a PCB using Altium. I've emailed Varun about how to use Altium on the iMac but he hasn't responded. If anyone else knows how to use the software, please let me know.

I added an EM172 to my soldered circuit and it seems to be working so far. I have taken a spectra using the EM172 in ambient noise in the control room as well as in white noise from Audacity. My computer's speakers are not very good so the white noise results aren't great but this was mainly to confirm that the microphone is actually working.

white_v_ambient.pdf

Do these look good for the ceramic capacitors? We're running low.

http://www.mouser.com/ProductDetail/Vishay-BC-Components/K104K15X7RF53L2/?qs=sGAEpiMZZMuMW9TJLBQkXmrXPxxCV7CRo6C15yUYAos%3d

Gautam helped me drill holes in a metal box and I set up my circuit inside. Everything seems to be working so far. Tomorrow I'll be suspending the box near the PSL and setting up a data channel. Attached are some pictures of the box- sorry some of the angles turned out weird.

My box has been suspended in the PSL using surgical tubing, and it has been connected to C1:PEM-MIC_1 (C17) with a BNC. I made a braided power cable as well but it turned out to be slightly too short... Once this is fixed, everything should be ready and we can see if it's working correctly. I also set up a new tab on the summary pages for this channel:

https://ldas-jobs.ligo.caltech.edu/~praful.vasireddy/1154941217-1154942117/pem/acoustic/

This data is back from when I had my solderless breadboard running near MC2. I'll add this tab to the real pages once the box is working (which could be a while since I'm gone for a month). Let me know if you see any issues with either the tab or the box/cables.

I'll add a picture of the installation when I get back to campus and finish hooking up the power cable. I haven't added this channel to the actual pages yet because there's not any data right now- the box is still unpowered because my braided power cable wasn't long enough. I just changed the format of the spectrum to ASD and added spectrograms. Here's how the tab looks now: https://ldas-jobs.ligo.caltech.edu/~praful.vasireddy/1155014117-1155015017/pem/acoustic/

Let me know if there's anything else to change.

I made an Altium schematic for the microphone amplifier circuit for fabrication.

mic_schematicv2.pdf

Q doesn't like elogging, but he sent me this nice detailed email, so I'm copying it into the log:

I’ve locked the power recycled Y arm numerous times today, to try and find a usable AO recipe for the full locking.

 The MC had been unlocked for the last 4 hours and was crying out to me so I gave it some attention. Its happier now.

From the trend (AtM #1), I saw that the MC2 suspension has moved by ~10 microradians. Since the MC cavity divergence angle is lambda/(pi*w0) ~ 200 microradians, this isn't so much, but enough to cause it to lock on bad modes sometimes. Attackmint too shows that there's not much in monotonic drift over the last 40 nights.

I moved back MC2 to its old alignment with these commands:

ezcaservo -r C1:SUS-MC2_SUSPIT_INMON -s -1017 -g 0.0009 C1:SUS-MC2_PIT_COMM -t 300

ezcaservo -r C1:SUS-MC2_SUSYAW_INMON -s 490 -g 0.0009 C1:SUS-MC2_YAW_COMM -t 332

Then I went out to the table and aligned the beam into MC using the last two steering mirrors good enough so that the WFS coming on doesn't make the visibility any better. In this nominal state, I unlocked the MC and then aligned the reflected beam onto the center of the LSC PD as well as the WFS. The beam on the first WFS is a little small - next time someone wants to improve our Gouy phase telescope, we might try to make it bigger there. On the LSC PD, the beam was off-center by a few hundred microns.

 At some point tonight we lost our CA connection to c1auxex (which is actually the computer at the X End and controls the ETMX, but has a Y sticker). We could telnet to it, but its puny RAM must have been overloaded with too many EPICS connections that bypassed the CArepeater. I went around and booted some machines and it seems to be back and allowing damping now. Along the way I keyed off the crate to c1auxex a couple of times.

When trying to close the rack door I saw that Charlie/Steve had illegally connected the power cable for the illuminator through the door so that it couldn't close, so I disconnected it so that they can run it properly and feel better about themselves.

Disclaimer: Steve had nothing to do with this connection. I rerouted the cable the correct way. 10-28-2013

** what does this coherence tell us about the noise in the arms ?

8 day minute trend of some of the IMC alignment signals.

That step ~2 days ago in the WFS2 yaw control signal shows that I didn't do such a good job on yaw.

Nic is going to come over some time and give us a new Gouy telescope that let's us have bigger beams on the WFS. At LLO, Hartmut demonstrated recently how bigger beams can reduce offsets somehow...mechanism TBD.

Also, we must angle the WFS and figure out how to dump the reflections at the same time that we rework the table for the telescope.

Steve, can you please put 2 mounted  razor dumps near the WFS for this purpose??    

            Tuesday: Razor dumps are waiting for you.

 I couldn't find any dumps near the WFS. Koji looked. I looked twice. Maybe they are spooky and absorbing all of the light?

The MC alignment was bad and the WFS were making it drift. Koji aligned the beam into the PMC. I then restored the MC suspensions to where they were 8 days ago (back when the transmission and reflection were good). With the WFS OFF, this gave us a MC trans ~ 16000. With WFS ON it goes to 17500 which is about as good as its been over the last 80 days.

I centered the beam on the WFS with the MC unlocked and also centered the beam on the whole WFS path (it was near clipping between WFS 1 & 2). Also for some reason that beamsplitter which steers the beam onto WFS1 is a R=33% (!? why is this not a R=50% ??).

Steve, please swap this out to a BS1-1064-50-1025-45S if we have one sitting around. If not, we want to add this to the CVI purchase list, but not buy until we get a bigger list together.

I also centered this newly aligned beam into the IMC onto the PSL QPDs. We should now use these as a pointing reference for the beam into the IMC.

While doing this I noticed that the beam was almost clipping on the Uniblitz shutter used to block the PSL beam. That shutter is mounted too short and was also not centered horizontally. I removed it for now so that Steve can find a more adjustable mount for it and put it back into play. The beam going into the IMC is BIG, so you have to very careful when centering the shutter. Might be that we cannot leave it at 45 deg and still get a big enough aperture.

Note #3 for Steve: please also replace the mount for last steering mirror into the IMC with a Polanski or a Superman, that black Ultima is no good. Also the dogs must be steel - no aluminum dogs for our sensitive places.

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

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

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

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

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

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

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

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

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

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

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

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

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

 The trend shows a big jolt to the MC1/3 pointing this morning at 8:30.

Was anyone working anywhere near there today? There is no elog.

If not, we will have to put a 'no janitor' sign on all of the 40m doors permanently to prevent mops misaligning our interferometer.

 Demod boards should be at 90 deg, not 82.7 or 12 or yellow or ****. We should re-inject the RF and then set the D Phase in the filter module to make the signals orthogonal. 165 is a challenging one to get right, but its worth it since the signals are close to degenerate already.

[Radhika, Paco, Anchal]

I placed a lens in the B-beam path to focus the beam spot onto the RFPD [Attachment 1]. To align the beam spot onto the RFPD, Anchal misaligned both ETMs and ITMY so that the AS and LO beams would not interfere, and the PD output would remain at some DC level (not fringing). The RFPD response was then maximized by scanning over pitch and yaw of the final mirror in the beam path (attached to the RFPD).

Later Anchal noticed that there was no RFPD output (C1:LSC-BH55_I_ERR, C1:LSC-BH55_Q_ERR). I took out the RFPD and opened it up, and the RF OUT SMA to PCB connection wire was broken [Attachment 2]. I re-soldered the wire and closed up the box [Attachment 3]. After placing the RFPD back, we noticed spikes in C1:LSC-BH55_I_ERR and C1:LSC-BH55_Q_ERR channels on ndscope. We suspect there is still a loose connection, so I will revisit the RFPD circuit on Monday. 

[Anchal, Radhika]

We proceeded with the TODO items from [17166].

We tried to update the YARM ASS output matrix to appropriately feed back the ETM and ITM T error signals (input beam pointing) to actuate on PR2 and PR3. Using the existing matrix (used for actuating on TT1 and TT2) led to diverging error signals and big drops in transmission. We iteratively tried flipping signs on the matrix elements, but exhausting all combinations of parity was not efficent, since angular sign conventions could be arbitrary across optics. 

We decided to go ahead with Yuta's suggestion of dithering on PR2 and PR3 for input beam pointing, instead of ETMY and ITMY. This would simplify the output matrix greatly since dithering and actuation would now be applied to the same optics. Anchal made the necessary model changes. We tried a diagonal identity submatrix (for input pointing) to map each error signal to the corresponding DOF. With the length (L) control loops disengaged, this configuration decreased all T error signals and increased YARM transmision. We then re-engaged the L loops: the final result is that YARM transmission reached just below 1 [Attachment 1].

[Yuta, Anchal, Radhika]

Yesterday we attempted to lock MICH and BHD using the BH55_Q_ERR signal. We adjusted the demodulation phase to send the bulk of the error signal to the Q quadrature. With the LO beam misaligned, we first locked MICH with AS55_Q_ERR. We tried handing over the feedback signal to BH55_Q_ERR, which in theory should have been equivalent to AS55_Q_ERR. But this would not reduce the error and would instead break the MICH lock. Qualitatively the BH55_Q signal looked noisier than AS55_Q.

We used the Moku:Lab to send a 55 MHz signal into the demod board, replacing the BH55 RF input [Attachment 1]. The frequency was chosen to be 10 Hz  away from the demodulation frequency (5x Marconi source frequency). However, a 10Hz peak was not visible from the spectra - instead, we observed a 60 Hz peak. Tweaking the frequency offset a few times, we realized that there must be a ~50Hz offset between the Moku:Lab and the Marconi.

We generated an X-Y plot of BH55_Q vs. AS55_DC with the MICH fringe: this did not follow a circle or ellipse, but seemed to incoherently jump around. Meanwhile the X-Y plot BH55_I vs. AS55_DC looked like a coherent ellipse. This indicated that something might have been wrong with the demod board producing the I and Q quadrature signals.

We fed the BH55 RF signal into an unused demod board (previously AS165) [Attachment 2] and updated the channel routing accordingly. This step recovered elliptical I and Q signals with Moku input signal, and their relative gain was adjusted to produce a circle X-Y plot [Attachment 3]. C1:LSC-BH55_Q_GAIN was adjusted to 155.05/102.90=1.5068, and measured diff C1:LSC-BH55_PHASE_D was adjusted to 94.42 deg.

Now BH55_Q_ERR was able to be used to lock the MICH DOF. However, BH55 still appears to be noisy in both I and Q quadratures, causing the loop to feedback a lot of noise.

Next steps:

- Amplify the BH55 RF signal before demodulation to increase the SNR. In order to power an RF amplifier, we need to use a breakout board to divert some power from the DB15 cable currently powering BH55.

[Anchal, Radhika]

We selected a 102K (1 nF) ceramic capacitor and a 100 uF electrolytic capacitor for the RF amplifier power pins. I soldered the connections and reinstalled the amplifier [Attachments 1, 2].