I have measured the transfer function of temperature fluctuations inside the enclosure to that of the temperature fluctuations outside. The transfer function has been estimated by using 'tfestimate' which is library function in Matlab and which estimates the transfer function based on Welch's method. The attached plots shows the transfer function of the temperature inside the enclosure to that of outside temperature.

fig1.pdf

fig2.pdf

In order to determine a relation between temperature inside the enclosure to that of the outside temperature, I have calculated the mean squared coherence.  I have used Matlab's 'mscohere' library function which uses Welch's method to calculate the coherence. Attached plot shows the coherence between the temperature across the enclosure.

fig3.pdf

Also, I have attached the matlab script which I used for generating these plots.

script21jul2016.m

I have made the changes as suggested by Gautam.

Please find the new attached plots and the new script.

Guralp 1  is on the south side of IOO chamber

I scanned the temperature of the crystal oven on Friday night in order that we can find the optimal temperature of the crystal for SHG.

The optimal temperature for this crystal was found to be 36.2 deg.

The crystal is on the PSL table. The incident beam on the crystal is 27.0mW with the Newport power-meter configured for 1064nm.
The outgoing beam had 26.5mW.

The outgoing beam was filtered by Y1-45S to eliminate 1064nm. According to Mott's measurements, Y1-45S has 0.5% transmission for 1064nm, while 90% transmission for 532nm. This means I still had ~100uW after the Y1-45S. This is somewhat consistent with the offset seen in the power-meter reading.

First, I scanned the temperature from 28deg to 40deg with 1deg interval.The temperature was scaned by changing the set point on the temperature controller TC-200.The measurements were done with the temperature were running. So, the crystal may have been thermally non-equilibrium.

Later, I cut the heater output so that the temperature could be falling down slowly for the finer scan. The measurement was done from 38deg to 34deg with interval of 0.1deg with the temperature running.

I clearly see the brightness of the green increase at around 36 deg. The data also shows the peak centered at 36.2deg. We also find two lobes at 30deg and 42deg. I am not sure how significant they are.

I wanted to mention here that I have a printed circuit board design (LIGO-D1800304) for using AD590 as temperature sensors. I believe printed boards and all required components are stored on the wire shelf in the WB EE shop on a box labeled with this DCC number. This circuit is also meant to be read by Acromag, maybe it can come of some use to you. You can check out the use in CTN lab in WB near the south-east end of the table.

I propose we set up a temperature sensor network as described in attachment 1.

Here there are two types of units:

• BASE-GATEWAY
  • Holds the processor to talk to the network through Modbus TCP/IP protocol.
  • This unit itself has a temperature sensor in it. It is powered by a power adaptor or PoE from the switch.
  • Each base unit can have at max 2 extended temperature probes ENV-TEMP.
• ENV-TEMP
  • This is just a temperature probe with no other capabilities.
  • It is powered via PoE from the BASE-GATEWAY unit.

Proposal is

• to put 2 ENV-TEMP sensors (#1 and #2) along the Y-arm at the end and midway. These are powered and read through a BASE-GATEWAY (#A) at the vertex. The BASE-GATEWAY (#A) will serve as temperature sensor for the vertex.
• We put one ENV-TEMP(#3) at the X-end powered and read through by another BASE-GATEWAY (#B) at the midpoint of X-arm.
• Both BASE-GATEWAY are connected by ethernet cables to the network switch. That's it.

These sensors can be configured over network by going to their assigned IP addresses. I'm not sure at the moment how to configure the dB files to get them to write on slow EPICS channels.

We will have an unused port on the BASE-GATEWAY (#B) which can be used to run another temperature sensor, maybe at an important rack, PSL table or somewhere else.

In future, if more sensors are required, there are expansion (network switch like) options for BASE-GATEWAY or daisy-chain options for the probes.

Edit Fri Jun 18 16:28:13 2021 :

See this [wiki page](https://wiki-40m.ligo.caltech.edu/Physical_Environment_Monitoring/Thermometers) for updated plan and final quote.

We can now view the minute trend of the temperature sensors under the PEM tab of the summary pages. See attachment 1 for an example of today's temperature readings. 

[jordan, gautam]

the long DB25 cable to connect the Acromag chassis to the temperature sensor interface box arrived. We laid it out today. This cable does the following:

1. Supply the box with +/- 24 V DC from the chassis. The pin arrangement here is rather unfortunate (the +/-24 V DC and GND pins are in close proximity), so if you're not careful, you'll create a short as you plug this cable in (as we found out today). So the best practise is to power down the crate before connecting/disconnecting this cable. Jordan will label this accordingly tomorrow.
2. Pipe the "TAMB" and "TCAV" signals, corresponding to temperature sensors mounted to the PSL table-top and reference cavity exterior respectively, to the Acromags. We found during some initial testing that the "TAMB" signal was reaching the DB25 connector on the Acromag chassis, but wasn't going to any ADC channel - this was rectified.

Both signals now show up in the EPICS channels, but are noisy - I suspect this is because the return pin of the Acromag is not shorted to ground (this is a problem I've seen on the bench before). We will rectify this tomorrow as well.

We took this opportunity to remvoe the bench supply and temporary Acromag crate (formerly known as c1psl2) from under the PSL table. While trying to find some space to store the bench supply, we came across a damaged Oscilloscope in the second "Electronics" cabinet along the Y-arm, see Attachment #1. 

After this work, I found that the IMC autolocker was reliably failing to run the mcup script at the stage where the FSS gains are ramped up to their final values. I was, however, able to smoothly transition to the low-noise locked state if I was manipulating the EPICS sliders by hand. So I added an extra 2 seconds of sleep time between the increasing of the VCO gain to the final value and the ramping of the FSS gains in the mcup script (where previously there was none). Now the autolocker performs reliably.

Below are some plots from dataviewer of temperature-step data taken over the past 32 hours. (They show minute trends). I am looking at the thermal coupling from the can surrounding the reference cavity on the PSL table to the cavity itself, and trying to measure the cavity temperature response via the control signal sent to heat the NPRO laser, which is locked to the cavity.

• Top left: out-of-loop temperature sensor on can surrounding ref cav (RCTEMP)
• Top right: control signal sent to slow drive of laser (laser heater), which is supposed to follow the cavity temperature (TMP_OUTPUT)
• Bottom left: in-loop can temperature sensors (MINCOMEAS)
• Bottom right: room temperature reading (RMTEMP)

I stepped the temperature set point from 35 to 36 deg. C for the can at 12:30am last night. Then I waited to see the cavity temperature change and the slow actuator (laser heater: TMP_OUTPUT) follow that change.

I was a bit worried about the oscillations that were occuring in the TMP_OUTPUT signal even long after this temperature step was made, but I figured that they were simply room-temperature changes propagating into the cavity, since they seemed to have a similar pattern to the room-temperature variations, and since it is clear that the out-of-loop temperature sensor on the can (RCTEMP) experiences variations, even when the in-loop sensors are recording no variation.

At 8:46pm tonight I stepped the temperature down 2 degrees to 34 deg. C. The step had a clear effect on TMP_OUTPUT. The voltage to the heater dropped and eventually railed at its lowest output. I'm worried that the loop is unstable, although I haven't ruled out other possibilities, such as that a 2 deg. C temperature step is too large for the loop. I will investigate further in the morning.

 The lock was lost when I came in around noon today to check on it. The slow actuator was still railing.

1) I got lock back for a few minutes, by varying the laser temperature set point manually. TMP_OUTPUT was still reading -30000 cts (minimum allowed) and the transmission was not as high as it had been.

2) I toggled the second filter button off. The TMP_OUTPUT started rising up to ~2000 cts. I then toggled the second filter back on, and TMP_OUTPUT jumped the positive maximum number of counts allowed.

3) I lost the lock again. I turned off the digital output to the slow actuator.

4) I have so far failed at getting the lock back. My main problem is that when the BNC cable to the slow port is plugged in, even when I'm not sending anything to that port, it makes it so that changing the temperature set point manually has almost no effect on the transmission (it looks as though changing the setpoint is not actually changing the temperature, because the monitor shows the same higher order mode even when with +-degree temperature setpoint changes).

 Same thing for the Innolight Mephisto.

Not unexpected values with dn/dT around 11E-6 K^-1 and coefficient of thermal expansion = 8E-6 K^-1 and a laser resonator length of order 10cm.

Please put those numbers onto wiki somewhere at the green page or laser characterization page.

The beams from the Innolight and Lightwave NPROs were both incident on a 1GHZ New Focus PD. Mott and I swept the temperature of the Lightwave and tracked the change in frequency of the beatnote between the two. The Innolight temperature was set to 39.61C although the actual temperature was reported to be 39.62C.

Freq. vs temperature is plotted below in the attached PDF. The slope is 2.8GHz/K.

The data is in the attached MATLAB file.

<p>I removed the rsync backup from nodus' crontab temporarily so as to not have multiple backup jobs running.&nbsp; The job I started from yesterday was still running.&nbsp; Hopefully the backup will finish by Monday.</p>
<p>The line I removed was:</p>
<p>0 5 * * * /opt/rtcds/caltech/c1/scripts/backup/rsync.backup</p>
<table align="left" width="786" cellspacing="1" cellpadding="1" border="2">
    <tbody>
        <tr>
            <td><span style="font-size: larger;">MC damp</span></td>
            <td><span style="font-size: larger;">dataviewer</span></td>
            <td><span style="font-size: larger;">diaggui</span></td>
            <td><span style="font-size: larger;">AWG</span></td>
            <td><span style="font-size: larger;">c1lsc</span></td>
            <td><span style="font-size: larger;">c1ioo</span></td>
            <td><span style="font-size: larger;">c1sus</span></td>
            <td><span style="font-size: larger;">c1iscex</span></td>
            <td><span style="font-size: larger;">c1iscex</span></td>
            <td><span style="font-size: larger;">RFM</span></td>
            <td><span style="">The Dolphins</span></td>
            <td><span style="font-size: larger;">Sim.Plant</span></td>
            <td><span style="font-size: larger;">Frame builder</span></td>
            <td><span style="font-size: larger;">TDS</span></td>
            <td><span style="font-size: larger;">Cabling</span></td>
        </tr>
        <tr>
            <td bgcolor="blue"><span style="font-size: larger;">&nbsp;</span></td>
            <td bgcolor="green"><span style="font-size: larger;">&nbsp;</span></td>
            <td bgcolor="blue"><span style="font-size: larger;">&nbsp;</span></td>
            <td bgcolor="yellow"><span style="font-size: larger;">&nbsp;</span></td>
            <td bgcolor="orange"><span style="font-size: larger;">&nbsp;</span></td>
            <td bgcolor="yellow"><span style="font-size: larger;">&nbsp;</span></td>
            <td bgcolor="blue"><span style="font-size: larger;">&nbsp;</span></td>
            <td bgcolor="yellow"><span style="font-size: larger;">&nbsp;</span></td>
            <td bgcolor="yellow"><span style="font-size: larger;">&nbsp;</span></td>
            <td bgcolor="blue"><span style="font-size: larger;">&nbsp;</span></td>
            <td bgcolor="blue"><span style="font-size: larger;">&nbsp;</span></td>
            <td bgcolor="red"><span style="font-size: larger;">&nbsp;</span></td>
            <td bgcolor="blue"><span style="font-size: larger;">&nbsp;</span></td>
            <td bgcolor="orange"><span style="font-size: larger;">&nbsp;</span></td>
            <td bgcolor="orange"><span style="font-size: larger;">&nbsp;</span></td>
        </tr>
    </tbody>
</table>

The backup appears to have finished on nodus, and I've put the rsync job back in the crontab.

Apparently updating to the latest revision of the RCG has some issues with diaggui and awgtpman.  Alex had to do some recompiling up at Hanford which apparently took him some time.  He'll be coming by tomorrow to try to bring those codes to the front end machines.

As a temporary fix, until Alex gets here tomorrow, we're reverting to the 2005 revision in the svn of the cds code.  I'm placing it in the location it is supposed to go in the new advLIGO scheme, which is /opt/rtcds/caltech/c1/core/, which is where Keith had it at LLO.  Once we get the new codes working, we will do an svn update on that location and migrate our work to that install location, at which point I'll remove the old /cvs/cds/caltech/cds/advLigoRTS/ location.

I made a voltage divider using a 20.47kohm and 1.07kohm (both values measured with a DMM). The whole thing is packaged inside a Pomona box I found lying around on the Electronics bench. I have hooked it up to the ALSY_I channel and will leave it so overnight. The INMON of this channel isn't DQed, but for this test, the 16Hz EPICS data will suffice. I've locked the EX laser to the arm, enabled slow temperature servo to allow overnight lock (hopefully) and disabled LSC mode (as locking the arm to the MC tends to break the green lock)

To convert the INMON counts to RF power, I will use (based on my earlier calibration of this monitor channel, see DCC document for the demod chassis).

1AM update: Attachment #1 shows that the RF amplitude has been relatively stable (less than 10% of nominal value variation) over the course of the last hour or so. Even though there is some low frequency drift over timescales of ~20mins, no evidence of the wild ~20dB amplitude changes I saw last week. The signs are encouraging...

overnight update: See Attachment #2 - looking at the past 11 hours of second trend data during which the arm stayed locked, there actually seems to have been more significant variation in the beatnote amplitude. Swings of up to 6dBm are seen on a ~20min timescale, while there is also some longer term drift over 12 hours by a couple of dBm. There is probably a systematic error in the Y-axis, as I measured the RF power at the input of the power splitter at the LSC rack to be ~3dBm, so I expect something closer to 0dBm to be the LO input power which is what I am monitoring. So further debugging is required - I think I'll start by aligning the X fiber coupled beam to one of the fiber's special axes.

Problem:

Each RFM read in the c1mcs model is adding ~7 microseconds to the cycle time.  Adding too many pushes it over the 62 microsecond limit.

RFM writes do not have this problem.

Temporary Solution:

The fastest fix was to create a new front end model, called c1rfm, which does nothing but read in the MC1, MC2, MC3 PIT and YAW signals from the c1ioo machine, and then passes them along to the c1mcs model via shared memory, which is fast.

This means the data being sent is 2 cycles slow, one to go over the RFM, and one to go over shared memory.  It is running at 16384 cycles/second, so it shouldn't have much impact at the frequencies we use those channels for.

MC_L is still being sent directly to the c1mcs front end code via RFM.

Current Status:

The c1mcs model is running at  30-33 microseconds for CPU time.

The c1rfm model is running at 45-47 microseconds for CPU time.

All 7 channels, MC_L, MC1_PIT, MC1_YAW, MC2_PIT, MC2_YAW, MC3_PIT, MC3_YAW are responding.

The c1rfm model was added to the /diskless/root/etc/rtsystab file on the fb machine so that it automatically starts on the reboot of c1sus.

The USR and CPU time channels for c1rfm were added to the MCS_SLOW.ini file in /opt/rtcds/caltech/c1/chans/daq/ so that the framebuilder records them, namely:

[C1:FEC-38_USR_TIME]
[C1:FEC-38_CPU_METER]

The framebuilder was restarted to take these new channels into account.

Future:

Finish implementing and debugging the "round robin" RFM reader so as to not require a seperate model to be doing RFM reads in parallel.

Look into improving read speed by either merging timestamps and data into a single  or reading time stamp once every tenth or hundreth cycle, although this at best provides a factor of 2 improvement.

Check to see if RFM card being on the IO chassis or directly in the computer chassis makes a difference.

Get Alex and Rolf to improve RFM read speed.

Fiber coupling 1064 nm light at the end of X arm

This is 'work in progress'.  The attempt is to bring a few milliwatts of the 1064 nm light from the NPRO at the end of the South(X) Arm to the PSL table through an single mode optical fiber.  This would enable us to tune the two NPRO's to be less than 15 MHz apart by looking at their beat frequency before doubling.  Because we have a 1GHz bandwidth PD at 1064 nm, while the photodiode for green has a BW of about 30MHz.

A PBS (P-type) cube has been introduced into the beam of the X arm NPRO  (between the lamda/2 plate and the input lens of the doubling crystal).  By rotating the face of the PBS slightly away from normal incidence, I have diverted away 1.5mW of the 1064 light for coupling into the fiber. The beam has shifted slightly because of this and the green beam from the south arm has to be realigned to reach the PSL table.

A single mode fiber (Thorlabs SM980-5.8-125),  which was already laid half way, has been extended all the way to the PSL table. It runs along the  South arm in the cable tray. 

A pair of mirrors have been arranged in a zig-zag to steer the beam into a fiber coupler.  There was some hope that this coupler had been aligned at some point in the past and that attaching a fiber might result in some transmission.  But this is not the case and fiber coupler needs to be readjusted.

In order to see the light transmitted through the fiber, a camera has been set up on the PSL table.  Its output has been routed into the 'Ref Cavity reflected' video signal.  A video cable running from the ETMX to the Video-MUX used to be connected to the input channel 9 of the Video MUX.  This has now been shifted to output channel 25 of the MUX and disconnected from the camera at the ETMX.   The 'Ref Cav Refl.' video signal has been routed to the output channel 25.  The camera looking at the fiber output can now be seen on a local monitor at the end of the X arm and on the video monitor in the control room.

With the fiber disconnected, the 1064 nm beam was steered into the fiber coupler and its transmission maximised by observing  with an IR viewer.  The fiber was then connected and then the transmission at the PSL table was sought.  There was no transmission seen after a searching around this region for a few mins.

The plan is to purchase a Visual fault locator which would enable us to quickly get a rough alignment of the fiber coupler. A local vendor is listed as a distributor for this product from JDSU.  Contact info:

DuVac Electronics (EDGE)
Tel: 626-796-3291
Email: jack@duvac.com
1759 E Colorado Blvd
Pasadena, CA 91106

In order to identify the output adapter of the BNC patch panel used for about 20 PEM channels, I had to disconnect its power and remove the back panel.  Channels coming into that panel (seismometers and so forth) was out from 1:36 to 1:56 pm.

I did a quick check of some of the channels and it looks like its working again after putting it all back together.

[Jon, Jordan, Koji]

Today Jordan reconfigured the vac system to allow pumping of the main volume resume, with Jon and Koji remotely advising. All clear to resume normal IFO activities. However, the vac system is operating in a temporary configuration that will have to be reverted as we locate replacement components. Details below.

Procedure

Since serial readback of the TP2 controller seems to be failing, we reconfigured the system with TP3 now backing for TP1. TP2 was valved off (at V4) and shut down until we can replace its controller.

TP3 has its own problems, however. It was valved off in January after its temperature readback began glitching and spuriously triggering the interlocks [ELOG 15140]. However the problem appears to be limited only one readback (rotation speed, current, voltage are fine) and there is enough redundancy in the pump-dependent interlock conditions to safely connect it to the main volume.

We also discovered that sometime since January, the TP3 dry pump has failed. The foreline pressure had risen to 165 torr. Since the TP2 and TP3 dry pumps are not interchangeable (Agilent vs. Varian), we instead valved in the auxiliary dry pump and disconnected the failed dry pump using a KF blank. This is a temporary arrangement until the permanent dry pump can be repaired. Jordan removed it to replace the tip seals and will test it in the bake lab before reinstalling.

With this configuration in place, we proceeded to pump down the main volume without issue (attachment 1). We monitored the pumpdown for about 45 min., until the pressure had reached ~1E-5 torr and TP3 had been transitioned to standby (low-speed) mode.

Summary of topology changes:

• TP2 valved off and shut down until controller can be replaced
• TP3 temporarily backing for TP1
• Auxiliary dry pump temporarily backing for TP3
• TP3 dry pump has been removed for repairs

Started working on this. First created a git repo for tracking https://git.ligo.org/40m/susaux.git

I have looked through the folder to see what needs doing and I think I know what needs to be done for the final case by just following the same pattern for the other optics, which I am listing below

- Create database file for the BHD optics, say C1_SUS-AUX_LO1.db by copying another optic database file say C1_SUS-AUX_SRM. Then replace the optic name.

- Insert a new line "C1:SUS-LO1_LATCH_OFF" in the file autoBurt_watchdogs.req

- Populate the file autoBurt.req with the appropriate channels for LO1

- Populate the file C1SUSaux_post.sh with the corresponding commands for LO1

- Add the line dbLoadDatabase("/cvs/cds/caltech/target/c1susaux/C1_SUS-AUX_LO1.db") to the file C1SUSaux.cmd

For the temporary watchdog, we comment everything I have just talked about, and do only what come next.

My question is the following:

I understand that we need to use the OUT16 slow channel as a temporary watchdog since we don't currently have access to the slow channels bcos the Acromag units have not been installed. My guess from Koji's instructions is that we need to update the channels in the last two fields "INPA" and "INPB" below

record(calc,"C1:SUS-LO1_UL_CALC")
{
        field(DESC,"ANDs Enable with Watchdog")
        field(SCAN,"1 second")
        field(PHAS,"1")
        field(PREC,"2")
        field(HOPR,"40")
        field(LOPR,"-40")
        field(CALC,"A&B")
        field(INPA,"C1:SUS-LO1_UL_COMM  PP  NMS")
        field(INPB,"C1:SUS-LO1_LATCH_OFF  PP  MS")
}

Suppose we replace the channel for INPA with C1:SUS-LO1_ULCOIL_OUT16, what about INPB. Is this even the right thing to do as I am just guessing here?

I don't remember the syntax of the db file, but here this calc channel computes A&B. And A&B corresponds to INPA and INPB.

        field(CALC,"A&B")
        field(INPA,"C1:SUS-LO1_UL_COMM  PP  NMS")
        field(INPB,"C1:SUS-LO1_LATCH_OFF  PP  MS")

What is this LATCH doing?

After some work on the reference database file, we now have a template for temporary watchdog implementation for LO1 located here "/cvs/cds/caltech/target/c1susaux/C1_SUS-AUX_LO1.db".

Basically, what I have done is swap the EPICS asyn analog input readout for the COIL and OSEM to accessible medm channels, then write out watchdog enable/disable to coil filter SW2 switch. Everything else in the file remains the same. I am worried about some of the conversions but the only way to know more is to see the output on the medm screen.

To test, I restarted c1su2 but this did not make the LO1 database available, so I am guessing that we also need to restart the c1sus, which can be done tomorrow.

As the new db is made for c1susaux, 1) it needs to be configured to be read by c1susaux 2) it requires restarting c1susaux 3) it needs to be recorded by FB 4) and restartinbg FB.
(^-Maybe not super exact procedure but conceptually like this)

cf.
https://wiki-40m.ligo.caltech.edu/How_To/Add_or_rename_a_daq_channel

Temp software watchdog now operational for LO1 and the remaining optics!

Koji helped me understand how to write to switches and we tried for a while to only turnoff the output switch of the filters instead of the writing a zero that resets everything in the filter.

Eventually, I was able to move this effort foward by realising that I can pass the control trigger along multiple records using the forwarding option 'FLNK'. When I added this field to the trigger block, record(dfanout,"C1:SUS-LO1_PUSH_ALL"), and subsequent calculation blocks, record(calcout,"C1:SUS-LO1_COILSWa") to record(calcout,"C1:SUS-LO1_COILSWd"), everything started working right.

A little D-sub terminator was put on the Gur1 input to the Guralp box, to check again the noise level of the box.

Mostly a note to self:  I have put terminators on the ADC inputs which are usually the PEM-SEIS-GUR2_(XYZ) channels.  Since these 3 signals are currently going into the ASS ADC, these PEM ADC inputs are open, and have predefined channel names.  I'll collect the data and put it as the ADC noise level in my nifty plot which will show the noise limits of all things which affect Wiener Filtering.

We want to have some angular control of the arms during lock acquistion. 

In single arm lock, Diego and I shook the TMs and measured how the QPDs responded. (I would've liked to do a swept sine in DTT, but the user envelope function still isnt' working!)

For now, we can close simple loops with QPD sensor and ITM actuator, but, as Rana pointed out to Diego and me today, this will drive some amount of the angular cavity degree of freedom that the QPD doesn't sense. So, ideally, we want to come up with the right combination of ITM and ETM motion that lies entirely within the DoF that the QPD senses.

I created a rudimentary loop for Yarm yaw, was able to get ~20Hz for the upper UGF, a few mHz for the lower, but it was starting to leak into the length error signal. Further tweaking will be neccesary...

I found this interesting entry by Rana in the old (deprecated) elog : here

I wonder if Rolf has ever written the mentioned GUI that explained the rationale behind the test point number mapping.

I'm just trying to add the StochMon calibrated channels to the frames. Now I remember why I kept forgetting of doing it...

 As far as I know, the EPICS channels have nothing to do with test points.

[ericq, gautam]

Tonight, we decided to double-check the POX counts-to-meters conversion.

It is unclear when this was last done, and since I modified the coil driver electronics for the ITMs and BS recently, I figured it would be useful to get this calibration done. The primary motivation was to see if we could resolve the discrepancy between the current ALS noise (using POX as a sensor) compared to the Izumi et. al. plot.

Because we are planning to change the coil driver electronics further soon anyways, we decided to do the calibration at a single frequency for tonight. For future reference, the extension of this method to calibrate the actuator over a wider range of frequencies is here. The procedure followed, and the relevant numbers from tonight, are as follows.

Procedure:

1. Set dark offsets on all DCPDs and LSC PDs.
2. Look at the free swinging Michelson signal on ASDC.
   • For tonights test, ASDC was derived from the AS55 photodiode.
   • The AS110 photodiode actually has more light on it, but we think that the ADC that the DCPD board is interfaced to is running on 0-2V rather than 0-10V, as the signal seemed to saturate around 2000 counts. It is unclear whether the actual photodiode is saturating, to be investigated.
   • So we decided to use ASDC from AS55 photodiode with 15dB whitening gain.
   • There is also some issue with the whitening filter (not whitening gain) on ASDC - engaging the whitening shifts the DC offset. This has to be investigated while we get stuck into the LSC electronics.
3. Look at the peak-to-peak swing of ASDC. Use algebraic expression for reflected power from Michelson interferometer to calibrate the ASDC slope at Michelson half-fringe. For the test tonight, ASDC_max = 1026 counts, ASDC_min = 2 counts.
4. Lock the Michelson at half-fringe, with ASDC as the error signal.
   • Zero out the MICH elements in the RFPD input matrix.
   • Set the matrix element from ASDC to MICH in the DCPD LSC input matrix to 1.
   • The servo gain used was +0.005 on the MICH_A servo path.
   • A low-frequency boost was turned on.
5. Use the sensing matrix infrastructure to drive a line in the optic of interest.
   • Tonight, we looked at ITMX and ITMY.
   • The line was driven at 311.1Hz, and the amplitude was 300 counts.
   • Download 60secs of ASDC data, demodulate at the driven frequency to find the peak height in counts, and using the slope of ASDC (in cts/m) at the Michelson half-fringe, calculate the actuator gain in m/cts.
   • ITMY: 2.55e-9 / f^2 m/count
   • ITMX: 2.65e-9 / f^2 m/count
   • These numbers kind of make sense - the previous numbers were ~5nm/f^2 /ct, but I removed an analog gain of x3 in this path. Presumably there has been some change in the N/A conversion factor - perhaps because of a change in the interaction between the optics' face magnets and the static magnetic field in the OSEMs?
6. Lock the arms with POX/POY, and drive the newly calibrated ITMs.
   • So we know how many meters we are driving the ITMs by.
   • Looking at POX/POY, we can calibrate these into meters/count.
   • Both POX and POY were whitened.
   • POX whitening gain = +30dB, POY whitening gain = +18dB.
   • ITMX and ITMY were driven at 311.1Hz, with amplitude = 2counts.
   • Download 60 secs of data, demodulate at the drive frequency to find the peak height, and use the known ITM actuator gains to calibrate POX and POY.
   • POX: 7.34e-13 m / count (approx. 5 times less than the number in the Foton filter bank in the C1:CAL-CINV model).
   • POY: 1.325e-13 m / count
   • We did not optimize the demod phases for POX/POY tonight. 

Once these calibrations were updated, we decided to control the arms with ALS, and look at the POX spectrum. Y-arm ALS wasn't so stellar tonight, especially at low frequencies. I can see the GTRY spot moving on the CCD monitor, so something is wonky. To be investigated. But the X arm ALS noise looked pretty good.

Seems like updating the calibration did the job; see the attached comparison plot.

Attachment #1 is a summary of the current to each coil on the suspensions. The situation is actually a little worse than I remembered - several coils are currently drawing in excess of 10mA. However, most of this is due to a YAW correction, which can be fixed somewhat more easily than a PIT correction. So I think the circuit with a gain of 31 for an input range of +/-10 V, which gives us the ability to drive ~12mA per coil through a 25kohm series resistor, will still provide sufficient actuation range. As far as the HV supplies go, we will want something that can do +/- 350 V. Then the current to the coils will at most be ~50 mA per optic. The feedback path will require roughly the same current. The quiescent draw of each PA95 is ~10mA. So per SOS suspension, we will need ~150mA.

If it turns out that we need to get more current through the 25kohm series resistance, we may have to raise the voltage gain of the circuit. Reducing the series resistance isn't a good option as the whole point of the circuit is to be limited by the Johnson noise of the series resistance. Looking at these numbers, the only suspension on which we would be able to plug in a HV coil driver as is (without a vent to correct for YAW misalignment) is ITMY.

Update 2 Sep 2020 2100: I confirmed today that the number reported in the EPICS channel, and the voltage across the series resistor, do indeed match up. The test was done on the MC3 coil driver as it was exposed and I didn't need to disable any suspensions. I used a Fluke DMM to measure the voltage across the resistor. So there is no sneaky factor of 2 as far as the Acromag DACs are concerned (unlike the General Standards DAC).

[Kruthi, Milind]

On Friday, Milind and I performed the pitch adjustment test Rana had asked us to do. Only 1 blue beam in case of ITMX and two in case of ETMY, ETMX and ITMY were accessible. Milind (of mass 72 kg as of 10 May 2019) stood on each of the accessible blue beams of the test mass chambers for one minute and I recorded the corresponding gps time. Before moving to the next beam, we spared more than a minute for relaxation after the standing end time. Following are the recorded gps times. 

PS: For each blue beam relaxation time ~ 1 min after the standing end time

Test:

Look at the effects of the ADC voltage range on the ADC noise floor.

ADC input was terminated with 50 ohms.  We then looked at the channel with DTT. This was at +/- 10 V range.  We used C1:SUS-PRM_SDSEN_IN1 as the test channel.

The map.c file (in /opt/rtcds/caltech/c1/core/advLigoRTS/src/fe/ ) then had two lines added at line 766.

//JCB temporary 2.5V test, remove me
  adcPtr[devNum]->BCR &= 0x84240;

This hard coded the 2.5 V range (we default to the 10 V range at the moment).

We then rebuilt the c1x02 model and reran the test.

Finally, we reverted the code change to map.c and rebuilt c1x02.

Results:
I've attached the DTT output of the two tests.

It appears the ADC is limited by 1.6 uV/rtHz.  Hence the increase in noise in counts by a factor of 4 when we drop to +/- 2.5 V from +/- 10 V.

[Koji Yuta]

We found one of the ADC cables were left unconnected. This left the MC suspensions uncontrollable through the whole afternoon.
Please keep the status updated and don't forget to revert the configuration...

We missed a factor of 2 in the ADC calibration: the differential 16 bit ADC with +/-10 V input has 20 V per 32768 counts (1 bit is for the sign). I confirmed this calibration by directly measuring ADC counts per V.

So the ADC input voltage noise with +/-10V range around 100 Hz is 6.5e-3 cts/rtHz x 20V/32768cts =  4.0 uV/rtHz. Bummer. 

The ADC quantization noise limit is 1/sqrt(12 fs/2)=1.6e-3 cts/rtHz. Where the ADC internal sampling frequency is fs=64 kHz. If this would be the limiting digitization noise source then the equivalent ADC input voltage noise would be 1 uV/rtHz with +/-10 V range.

P.1 Circuit diagram

Added components are indicated by red symbols.

- The diode on the board is HAMAMATSU S3399. It is a Si PIN diode with φ3.0 mm.

- Based on prototype version of aLIGO BBPD D1002969-v8 (although the board says v7, It is v8.)

- The input impedance of the MAR-6SM amplifier (50Ohm) provides the transimpedance.

- The first notch (Lres and Cresa/b) is actually not notch but a LF rejection with DC block.

- The second and third notches are tuned to 11MHz and 55MHz.

- Another notch is implemented between the RF amps. The 33MHz signal is weak so I expected
to have no saturation at the first amplifier.

- As you see from the DC path, the transimpedance of the DC path is 2k V/A. If this is too high,
  we need to replace R9 and R11 at the same time. TP1 is providing +10V such that the total
  reverse bias becomes 25V without bringing a special power supply.

P.2 Transimpedance

The transimpedance is measured with an amplitude modulated diode laser.

The transimpedance is 1k V/A ish. It is already at the edge of the bandwidth.
If we need more transimpedance at 165MHz, we should replace
the PD with FFD-100 (I have one) and apply 100V of reverse bias.

P.3 Current noise spectrum

The measured dark noise voltage spectrum was converted to the equivalent current noise at the diode.

The measured transimpedance is ~1.2kV/A.
The reduction of the transimpedance above 100MHz has been seen as 165MHz is already at the edge of the bandwidth.
If we need more transimpedance at 165MHz, we should replace the diode with FFD-100 (I have one) and apply 100V of reverse bias.

P.4 Shot-noise intercept current

Shot-noise intercept current was measured with a white light from a light bulb.
This measurement suggests the shot-noise intercept current of 1mA, and transimpedance of 1.5kV/A.

A test run was conducted on the PDFR system last afternoon and transimpedance plots were generated for 6 of the PDs. The laser was shut down after the test run.

I have not verified (yet) if the transimpedance values indicated by the plots are correct or not. The values mostly look INCORRECT. But the peaks are exactly where they need to be. *phew!*

Reasons: Incorrect calibration, Light other than from the PDFR system fibers on the PDs

Will have to work on debugging all this.

Log-log ... 

The Basler acA640-100gm is a power over ethernet camera.  It uses a power injector to supply power over an ethernet cable to the camera.  Once I got past some initial IP difficulties, the camera worked fine out of the box.

You need to set some environment variables first, so the code knows where its libraries are located.

setenv PYLON_ROOT /opt/pylon
setenv GENICAM_ROOT_V1_1 /opt/pylon
setenv GENICAM_CACHE /cvs/cds/caltech/users/josephb/xml_cache
setenv LD_LIBRARY_PATH /opt/pylon/lib64:$LD_LIBRARY_PATH

I then run the /opt/pylon/bin/PylonViewerApp

Notes on IP:

Initially, you need to set the computer connecting to the camera to an ip in the 169.254.0.XXX range.  I used 169.254.0.1 on megatron's eth1 ethernet connection.  I also set mtu to 9000.

You can then run the IpConfigurator in /opt/pylon/bin/ to change the camera IP as needed.

I used the rejected light from the PBS after the motorized half-wave plate between PMC and IMC injection path (used for input power control to IMC) to measure the transmission of PR2 candidates. These candidates were picked from QIL (QIL/2696). Unfortunately, I don't think either of these mirrors can be used for PR2.

If I remember correctly, we are looking for a 2" flat mirror with a transmission of the order of 1000 ppm. The current PR2 is supposed to have less than 100 ppm transmission which would not leave enough light for LO path.

I've kept the transmission testing setup intact on the PSL table, I'll test existing PR2 and another optic (which is 0.5" thick unfortunately) tomorrow.

I tested 2 more optics today, the old PR2 that we took out and another optic I found in QIL. Both these optics are also not good for our purpose.

I'll find thw Y1S optic and test that too. We should start looking for alternate solutions as well.

I tested 2 more optics found by Paco and Yehonathan in QIL.

I would like someone to redo the second test. I'm not sure what was happening but I could not find the transmitted beam at all on my card even with all lights out. This is either too good a coating and not useful for us or I did something wrong while measuring it.

V6-704, V6-706 mirror seemed like a good candidate as the paper with it said it would be a 200 ppm mirror. But I measured a lot more transmission than that. Now that I see that paper more carefully, it is a 45 degree s-pol mirror, probably that's why it had so much transmission for p-pol at near-normal incidence.

[Paco, Anchal]

Paco accidentally clicked on C1:SUS-MC1_UL_TO_COIL_SW_1_1 (MC1 POS to UL Coil Switch) and clicked it back on. We didn't see any loss of lock or anything significant on the large monitor on left.

Testing the new calculated input matrix

• Switched off the PSL shutter (C1:PSL-PSL_ShutterRqst)
• Switched off IMC autolocker (C1:IOO-MC_LOCK_ENABLE)
• Uploaded the same input matrix as the current one to check writing function in scripts/SUS/InMatCalc/testingInMat.py . We have created backup text file for current settings in backupMC1InMat.txt .
• Uploaded the new input matrix in normalized form. To normalize, we first made each row vector unit vector and then multiplied by the norm of current input matrix's row vectors (see scripts/SUS/InMatCalc/normalizeNewInputMat.py)
• Switched ON the PSL shutter (C1:PSL-PSL_ShutterRqst)
• Switched ON IMC autolocker (C1:IOO-MC_LOCK_ENABLE)
• Locked was caught immediately. The wavefront sensor of MC1 shows usual movement, nothing crazy.
• So the new input matrix is digestable by the system, but what's the efficacy of it?

< Two inspection people taking pictures of ceiling and portable AC unit passed. They rang the doorbell but someone else let them in. They walked out the back door.>

Testing how good the input matrix for MC1 is:

• We loaded the input matrix butterfly row in C1:SUS-MC1_LOCKIN_INMATRX_1_4 to 8. This matrix is multiplied by C1:SUS-MC1_UL_SEN_IN and so on channels before the calibration to um and application of toher filters.
• We tried to look around on how to load the same filter banks on the signal chain of LOCKIN1 of MC1 but couldn't, so we just manually added gain value of 0.09 in this chain to simulate the calibration factor at the very least.
• We started the oscillator on LOCKIN 1 on MC1 with amplitude 1 and frequency 6 Hz.
• We added butterfly mode actuation output column (UL:1, UR:-1, LL:-1, LR:1), nothing happened to the lock of probably because of low amplitude we put in.
• Now, we plot the ASD of channels like C1:SUS-MC1_SUSPOS_IN1 (for POS, PIT, YAW, SIDE) to see if we see a corresponding peak there. No we don't. See attachment 1.

Restoring the system:

• Added 0 to the LOCKIN1 column in MC1 output matrix.
• Made LOCK1 oscillator 0 Amplitude, 0 Hz.
• Changed back gain on signal chain of LOCKIN1 on MC1.
• Added 0 to C1:SUS-MC1_LOCKIN_INMATRX_1_4 to 8.
• Switched off the PSL shutter (C1:PSL-PSL_ShutterRqst)
• Switched off IMC autolocker (C1:IOO-MC_LOCK_ENABLE)
• Wrote back the old matrix by scripts/SUS/InMatCalc/testingInMat3.py which used the backup we created.
• Switched ON the PSL shutter (C1:PSL-PSL_ShutterRqst)
• Switched ON IMC autolocker (C1:IOO-MC_LOCK_ENABLE)

Yesterday, Alex attached the old frame builder 1.5 TB raid array to linux1, and tested to make sure it would work on linux1.

This morning he tried to start a copy of the current /cvs/cds structure, however realized at the rate it was going it would take it roughly 5 hours, so he stopped.

Currently, it is planned to perform this copy on this coming Friday morning.

We tried two sets of filters on the output matrix POS column in MC2. Both versions failed. Following are some details.

How test was done:

• PSL shutter was closed and autolocker was switch off.
• Turned off damping on POS, PIT, and YAW using C1:SUS-MC2_SUSPOS_SW2, C1:SUS-MC2_SUSPIT_SW2, and C1:SUS-MC2_SUSYAW_SW2.
• Reference data was taken with no excitation to get relative increase at excitation.
• Channels C1:SUS-MC2_SUSPIT_IN1, C1:SUS-MC2_SUSPOS_IN1, and C1:SUS-MC2_SUSYAW_IN1.
• Frist we sent an excitation through LOCKIN1 at 0.11 Hz and 500 counts amplitude.
• LOCKIN column in MC2 output matrix was kept identical to POS column, so all ones.
• This formed our reference data set when no filters were used. Attachment 1.
• Note that the peak at 0.03 Hz is due to LOCKIN2 that was left switched on due to autolocker.
• Then the calculated filters were loaded using foton. Procedure:
  • Right click on filter bank med. Got to Execute-> Foton.
  • Go to File and uncheck 'Read Only'.
  • Find the filter module name in Module drop down.
  • Select an empty module section in Sections.
  • Write a name for the filter. We used DCcoupF2A and DCcouF2A2 for the two version respectively.
  • Paste the zpk foton format in Command.
  • Check with Bode plot if these are correct filters. Then click on Save. It will take about 30s to become responsive again.
  • GO back to filter bank medm screen and click on 'Load Coefficients'. This should start displaying your new filter module.
  • To switch on the module, click on the button below its name.
• Once fitlers were loaded, we realized we can not use the LOCKIn to excite anymore as it comes as separate excitation.
• So we used awggui to excite C1:SUS-MC2_LSCEXC at 0.11 Hz and 500 counts.
• Then we retook the data and checked if the peaks are visible on PIT and YAW channels and how high they are.

Filer version 1

• This was calculated by starting from ideal output matrix elements as they are currently loaded. All 1's for POS and so on.
• The calculations were done in scripts/SUS/OutMatCalc/coilBalanceDC.py.
• This file uses a state space model of the suspension and calculated the cross-coupling. Then the cross coupling is inverted and applied to the current output matrix elements to get correction DC gains.
• These corrected DC gains are then used to create the filters as described in last post.
• Attachment 2 shows the filter transfer functions and Attachment 3 shows the test results. Failed :(.
• There was practivally no change in cross coupling that we can see.

Filter version 2:

• In this version we used the output matrix optimized at high frequencies earlier (16009).
• While testing this version, we also uploaded this optimised output amtrix at high frequency.
• In this test, we realized the LOCKIN2 was on and switched it off manually. All excitations were done through awggui.
• Attachment 4 shows the filter transfer functions and Attachment 5 shows the test results. Failed :(.
• There was again practivally no change in cross coupling that we can see.

Forgot to upload new MC2 input matrix:

• In hindsight, we should have uploaded our diagonalized suspension input matrix in MC2.
• Without it, there was cross-coupling the in the sensor data to begin with.
• But this can only be part of the reason why all our filters failed miserably.
• Because the output matrix was not diagonalized earlier but it was not so bad. Onyl a fresh test can tell if it was the culprit.