40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 240 of 344  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  5228   Sun Aug 14 04:12:37 2011 JennyUpdatePSLTemperature steps and slow actuator railing

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.

Picture_6.png

Picture_7.png

  • 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.

  5230   Sun Aug 14 15:37:39 2011 JennyUpdatePSLTemperature steps and slow actuator railing

Quote:

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.

Picture_6.png

Picture_7.png

  • 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).

  2794   Mon Apr 12 20:48:51 2010 Aidan, MottSummaryGreen LockingTemperature sweep of the Innolight: df/dT ~ 3.3GHz/K

Quote:

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.

 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.

  2797   Tue Apr 13 12:39:51 2010 Aidan, MottSummaryGreen LockingTemperature sweep of the Innolight: df/dT ~ 3.3GHz/K

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

Quote:

Quote:

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.

 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.

 

  2793   Mon Apr 12 19:50:30 2010 AidanSummaryGreen LockingTemperature sweep of the Lightwave: df/dT = 2.8GHz/K

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.

  4250   Fri Feb 4 13:45:25 2011 josephbUpdateComputersTemporarily removed cronjob for rsync.backup
<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>
  4252   Fri Feb 4 18:58:19 2011 ranaUpdateComputersTemporarily removed cronjob for rsync.backup

Quote:

I removed the rsync backup from nodus' crontab temporarily so as to not have multiple backup jobs running.  The job I started from yesterday was still running.  Hopefully the backup will finish by Monday.

The line I removed was:

0 5 * * * /opt/rtcds/caltech/c1/scripts/backup/rsync.backup

Actually, this is not true. Joe actually killed the currently running backup and set it to start tomorrow morning at 6AM. Its taking forever since its not an incremental backup but a new one due to the change in the setup.

  4256   Mon Feb 7 10:37:28 2011 josephbUpdateComputersTemporarily removed cronjob for rsync.backup

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

Quote:

I removed the rsync backup from nodus' crontab temporarily so as to not have multiple backup jobs running.  The job I started from yesterday was still running.  Hopefully the backup will finish by Monday.

The line I removed was:

0 5 * * * /opt/rtcds/caltech/c1/scripts/backup/rsync.backup

  3498   Tue Aug 31 16:42:26 2010 josephbUpdateCDSTemporarily reverting to CDS revision 2005

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.

  13645   Wed Feb 21 00:04:27 2018 gautamUpdateElectronicsTemporary RF power monitor setup

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).

\mathrm{P_{RF}} (\mathrm{dBm}) = \frac{19.13 \times \frac{cts}{1638.4} - 10.23}{0.12}


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.

  3853   Wed Nov 3 15:13:55 2010 josephbUpdateCDSTemporary RFM slow read work around

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.

  3843   Tue Nov 2 00:17:01 2010 SureshConfigurationLockingTemporary changes to the Video Mux

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

 

  3153   Thu Jul 1 14:03:40 2010 josephbUpdatePEMTemporary disconnect of some PEM channels for ~20 minutes

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.

  15402   Tue Jun 16 13:35:03 2020 JonUpdateVACTemporary vac fix / IFO usable again

[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
  16571   Tue Jan 11 10:58:58 2022 TegaUpdateSUSTemporary watchdog

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?

 

  16573   Tue Jan 11 13:43:14 2022 KojiUpdateSUSTemporary watchdog

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?

 

  16600   Wed Jan 19 21:39:22 2022 TegaUpdateSUSTemporary watchdog

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.

  16601   Thu Jan 20 00:26:50 2022 KojiUpdateSUSTemporary watchdog

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

 

  16606   Thu Jan 20 17:21:21 2022 TegaUpdateSUSTemporary watchdog

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.

Quote:

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.

 

  3139   Tue Jun 29 20:47:19 2010 JenneUpdatePEMTerminator put on Guralp Box

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

  2232   Wed Nov 11 00:55:47 2009 JenneUpdateAdaptive FilteringTerms put on some ADC inputs

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.

  10886   Mon Jan 12 18:11:25 2015 ericqUpdateASCTest Mass -> Transmon QPD TFs measured

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...

  2228   Tue Nov 10 17:49:20 2009 AlbertoMetaphysicsComputersTest Point Number Mapping

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...

  2231   Tue Nov 10 21:46:31 2009 ranaSummaryComputersTest Point Number Mapping

Quote:

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.

  13265   Tue Aug 29 01:52:22 2017 gautamUpdateSUSTest mass actuator calibration

[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.

  15542   Wed Aug 26 16:12:25 2020 gautamUpdateElectronicsTest mass coil current requirements

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).

  14798   Mon Jul 22 13:32:55 2019 KruthiUpdateSUSTest mass pitch adjustment test

[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. 

 

ETMX

ITMX

ETMY

ITMY

 

Beam 1

Beam 2

Beam 1

Beam 1

Beam 2

Beam 1

Beam 2

Standing start time (gps)

1247620911

1247621055

1247621984

1247622394

1247622585

1247622180

1247622814

Standing end time (gps)

1247620974

1247621118

1247622058

1247622459

1247622647

1247622250

1247622880

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

  3906   Fri Nov 12 10:49:34 2010 josephb, valeraUpdateCDSTest of ADC noise

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.

  3910   Fri Nov 12 19:24:56 2010 KojiUpdateCDSTest of ADC noise

[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...

Quote:

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.

 

  3915   Sun Nov 14 11:56:59 2010 valeraUpdateCDSTest of ADC noise

 

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.

  1204   Wed Dec 24 12:46:54 2008 YoichiUpdateComputersTest points are back
Rob told me how to restart the test point manager.
It runs on fb40m and actually there is an instruction on how to do that in the Wiki.
http://lhocds.ligo-wa.caltech.edu:8000/40m/Computer_Restart_Procedures#fb40m

I couldn't find the page because when I put a keyword in the search box on the upper right
corner of the Wiki page and hit "enter", it only searches for titles. To do a full text
search, you have to click on the "Text" button.

Anyway, now the test points are back.
  8797   Wed Jul 3 14:33:46 2013 KojiSummaryLSCTest result for the REFL165 photodetector

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.

  10212   Wed Jul 16 01:46:41 2014 NichinUpdateElectronicsTest run of PDFR system

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.

  10214   Wed Jul 16 02:22:10 2014 KojiUpdateElectronicsTest run of PDFR system

Log-log ... 

  4163   Mon Jan 17 15:31:50 2011 josephbUpdateCamerasTest the Basler acA640-100gm camera

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.

  16541   Tue Jan 4 18:26:59 2022 AnchalUpdateBHDTested 2" PR2 candidates transmission

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.

  Polarization Incident Power [mW] Transmitted Power [mW] Transmission [ppm]
V2-2239 & V2-2242 s-pol 940 0.015 16.0
V2-2239 & V2-2242 p-pol 935 0.015 16.0
V6-704 & V6-705 p-pol 925 21 22703

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.

  16543   Wed Jan 5 17:46:04 2022 AnchalUpdateBHDTested 2" PR2 candidates transmission

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.

 

Polarization Incident Power [mW] Transmitted Power [mW] Transmission [ppm]
Existing PR2 p-pol 910 0.004 4.4
V2-1698 & V2-1700 p-pol 910 595 653846

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

 

  16566   Mon Jan 10 18:20:45 2022 AnchalUpdateBHDTested 2" PR2 candidates transmission

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

  Polarization Incident Power [mW] Transmitted Power [mW] Transmission [ppm]
V6-704 V6-706 p-pol 850 17.1 20118
Yellow cylindrical box p-pol 850 <1 ( could not even see it to measure it with a more sensitive power meter) <1000

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.

 

  15930   Wed Mar 17 11:57:54 2021 Paco, AnchalUpdateSUSTested New Input Matrix for MC1

[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)
  1892   Wed Aug 12 13:35:03 2009 josephb, AlexConfigurationComputersTested old Framebuilder 1.5 TB raid array on Linux1

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.

  16042   Fri Apr 16 11:36:36 2021 Anchal, PacoUpdateSUSTested proposed filters for POS colum in MC2 output matrix

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.
  16043   Fri Apr 16 15:47:58 2021 ranaUpdateSUSTested proposed filters for POS colum in MC2 output matrix

Looks mostly right, but you used the OSEM sensors as readbacks. We are diagonalizing using the cavity sensors. Using the diagonalized input matrix is also good since that will reduce the cross-coupling due to the damping loops.

Its sort of a subtle issue:

  1. The sensors are are diagonalized into the eigenmode basis, not the Cartesian basis of the mirror motion.
  2. What the cavity cares about is the Cartesian motion.
  3. Q1: in the model, how much Cartesian pitch motion is there at the POS eigenfrequency in the free-swinging case?
  4. Q2: should we somehow diag the input matrix into the Cartesian basis?
  5. Q3: if so, How?
  6. Q4: and why?
  16049   Mon Apr 19 12:18:19 2021 Anchal, PacoUpdateSUSTested proposed filters for POS colum in MC2 output matrix

The filters were somewhat successful, how much we can see in attachment 1. The tip about difference between eigenmode basis and cartesian basis was the main thing that helped us take data properly. We still used OSEM data but rotated the output from POS, PIT, YAW to x, theta, phi (cartesian basis where x is also measured as angle projected by suspension length).


Eigenmode basis and Cartesian basis:

  • It is important to understand the difference between these two and what channels/sensors read what.
  • Eigenmode basis as the name suggests is the natural basis for the suspended pendulum.
    • It signifies the motion along three independent and orthogonal modes of motion: POS (longitudinal pendulum oscillation), PIT, and YAW.
    • The position of optic can be written in eigenmode basis as three numbers:
      • POS: Angle made by the center of mass of optic with verticle line from suspension point.
      • PIT: Angle made by the optic face with the suspension wires (this is important to note).
      • YAW: Angle made by optic surface with the nominal plane of suspension wires. (the yaw angle basically).
  • Cartesian basis is the lab reference frame.
    • Here we define three variables that can also represent an optic positioned and orientation:
      • x: Angle made by the center of mass of optic with verticle line from suspension point. (Same as POS)
      • \large \theta: Angle made by the optic surface with absolute verticle (z-axis) in lab frame.
      • \large \phi: Twist of the optic around the z-axis. Same as YAW angle above.
  • We want to apply the feedback gains and filters in eigenmode basis because they are a set of known independent modes. (RXA: NOOO!!!!!! read me elog entry on this topic)
  • Hence, the output from input matrix of suspensions comes out at POS, PIT and YAW in the eigenmode basis.
  • However, the sensors of optic positional, and orientation such at MC_F, wave front sensors and optical levers measure it in lab frame and thus in cartesian basis.
  • Essentially, the \large \theta measured by these sensors is different from the PIT calculated using the OSEM sensor data and is related by:
    • \large \theta = PIT - POS, where PIT and POS both are in radians as defined above.
  • When we optimized the cross-coupling in output matrix at high frequencies using the MC_F and WFS data, we actually optimized it In cartesian basis.
  • The three feedback filters from POS, PIT and YAW which carry data in the eigenmode basis need to be rotated into the cartesian basis in the output matrix before application to the coils.
  • The so-called F2A and A2L filters are essentially doing this rotation.
  • Above the resonant frequencies, the PIT and \large \theta become identical. Hence we want our filters to go to unity

The two filter sets:

  • The filters are named Eg2Ctv1 and Eg2Ctv2 on the POS column of MC2 output matrix.
  • This is to signify that these filters convert the POS, PIT, and YAW basis data (eigenmode basis data) into the cartesian basis (x, theta, phi) in which the output matrix is already optimized at higher frequencies.
  • v1 filter used an ideal output matrix during the calculation of filter as described in 16042 (script at scripts/SUS/OutMatCalc/coilBalanceDC.py).
  • Attachment 2 shows these filter transfer functions.
  • v2 filter use the output matrix optimized to reduce cross-coupling amount cartesian basis modes (MC_F, WFS_PIT and WFS_YAW) in 16009.
  • Attachment 3 shows these filter transfer funcitons.
  • Because of this, the v2 filter is different among right and left coils as well. We do see in Attachment 1 that this version of filter helps in reducing POS->YAW coupling too.

Test procedure:

  • We uploaded both the diagonalized input matrix and the diagonalized output matrix as calculated earlier.
  • We measured channels C1:SUS-MC2_SUSPOS_IN1_DQ, C1:SUS-MC2_SUSPIT_IN1_DQ, and C1:SUS-MC2_SUSYAW_IN1_DQ throughout this test.
  • These channels give output in an eigenmode basis (POS, PIT, and YAW) and the rows of the input matrix have some arbitrary normalization.
  • We normalize these channels to have same input matrix normalization as would be for ideal matrix (2 in each row).
  • Then, assuming the UL_SENS, UR_SENS, LR_SENS, and LL_SENS channels that come at input of the input matrix are calibrated in units of um, we calculate the cartesian angles x, theta, phi. for this calculation, we used the distance between coils as 49.4 mm (got it from Koji) and length of suspension as 0.2489 m and offset of suspension points from COM, b = 0.9 mm.
  • Now that we have true measures of angles in cartesian basis, we can use them to understand the effect on cross coupling from the filters we used.
  • PSL shutter is closed and autolocker is disabled. During all data measurements, we switched of suspension damping loops. This would ensure that our low frequency excitation survives for measurement at the measurement channels.
  • We first took reference data with no excitation and no filters for getting a baseline on each channel (dotted curves in Attachment 1).
  • We then send excitation of 0.03 Hz with 500 counts amplitude at C1:SUS-MC2_LSC_EXC and switched on LSC output.
  • One set of data is taken with no filters active (dashed curve in attachment 1).
  • Then two sets of data are taken with the two filters. Each data set was of 500s in length.
  • Welch function is used to take the PSD of data with bin widht of  0.01Hz and 9 averages.

Results:

  • Filter v1 was the most successful in reducing \large x \rightarrow \theta coupling by factor of 17.5.
    • The reduction in \large x \rightarrow \phi coupling was less. By a factor of 1.4.
  • Filter v2 was worse but still did a reduction of \large x \rightarrow \theta coupling by factor of 7.8.
    • The reduction in \large x \rightarrow \phi coupling was better. By a factor of 3.3.

Next, filters in PIT columns too

  • We do have filters calculated for PIT as well.
  • Now that we know how to test these properly, we can test them tomorrow fairly quickly.
  • For the YAW column though, the filters would probably just undo the output matrix optimization as they are derived from ideal transfer function models and ideally there is no coupling between YAW and other DOFs. So maybe, we should skip putting these on.
  17030   Mon Jul 25 09:05:50 2022 PacoSummaryGeneralTesting 950nm laser found in trash pile

[Paco, Yehonathan]

==== Late elog from Friday ====

Koji provided us with a QFLD-950-3S (QPHOTONICS) salvaged from Aidan's junk pile (LD is alive according to him). We tested the Jenne laser setup with this just to decide if we should order another one, and it worked.

The laser driver anode and cathode pins (8/9, 4/5 respectively) on the rear DB9 port from the  ILX Lightwave LDX-3412 driver were connected to the corresponding anode and cathode pins in the laser package (5, and 9; note the numbers are reversed between driver and laser). Then, interlock pins 1 and 2 in the driver were shorted to enable operation. This is all illustrated in Attachments #1-2.

After setting a limit of 27.6 mA current in the driver, we slowly increased the actual current to ~ 19 mA until we could see light on a beam card. We can go ahead and get a 1060 nm replacement.

  17064   Fri Aug 5 17:03:31 2022 YehonathanSummaryGeneralTesting 950nm laser found in trash pile

I set out to test the actuation bandwidth of the 950nm laser. I hooked the laser to the output of the bias tee of PD testing setup. I connected the fiber coming out of the laser to the fiber port of 1611 REF PD.

The current source was connected to the DB9 input of the PD testing setup. I turned on the current source and set the current to 20mA. I measured with a fluke ~ 2V at the REF PD DC port.

I connected the AC port of the bias tee to the RF source of the network analyzer and the AC port of the REF PD to the B port of the network analyzer. Attachment 2 shows the setup.

I took a swept sine measurement (attachment) from 100kHz to 500MHz.

It seems like the bandwidth is ~ 1MHz which is weird considering the spec sheet says that the pulse rise time is 0.5ns. To make sure we are not limited by the bandwidth of the cables I looped the source and the input of the network analyzer using the cables used for the previous measurement and observed that the bandwidth is a few 100s of MHz.

  17162   Wed Sep 28 19:15:56 2022 KojiUpdateGeneralTesting 950nm laser found in trash pile

I don't know what was wrong with the past setup but the 950nm laser (QPHOTONICS QFLD-950-3S) just worked fine up to ~300MHz with basically the same setup.

A 20dB coupler picks up a small amount of the driving signal from the source signal of the network analyzer. This was fed to CHR. The fiber-coupled NewFocus PD RF output was connected to CHA.
The calibration of the response was done with the thru response (connect the source signal to the CHA via all the long cables).

Attachment 1 shows the response CHA/CHR. The output is somewhat flat up to 20MHz and goes down towards 100MHz, but still active up to 500MHz as long as the normalization with the New Focus PD works.
The structure around 200MHz~300MHz changes with how the wires of the clips are arranged. I have twisted and coiled them as shown and the notch disappeared. For the permanent setup we should keep the lines as short as possible and take care of the stray capacitance and the inductance.

Attachment 2 shows the setup at the network analyzer side. Nothing special.

Attachment 3 shows the setup at the laser side. The DB9 connector on the Jenne's laser has the negative output of the LD driver connected to the coax core and the positive output connected to the shield of the coax. Therefore the coax core (red clip) has to be connected to Pin 9 and the coax shield (black clip) to PIn 5.

  7747   Mon Nov 26 19:27:59 2012 RijuHowTo Testing AG4395A+GPIB

Riju, Jenne

We have checked the transfer function of a bandpass filter using AG4395A network analyzer and retrieved the data through GPIB. The RF out signal of AG4395A had been divided by splitter with two outputs of the splitter going to through R and the filter which was connected to the A channel of the network analyzer. The GPIB data came in complex data format, from which the absolute value and phase had to be retrieved. 

 

The plot for the TF is as following

  7756   Tue Nov 27 19:06:16 2012 RijuUpdate Testing AG4395A+GPIB

 I ve tested another bandpass filter today with similar set-up. This time I took the data with corrected reference level. To set this reference-level the filter was disconnected and the cable was connected "thru" according to the instructions provided in the manual of AG4395A at http://cp.literature.agilent.com/litweb/pdf/04395-90040.pdf, page 3-10. The transfer functions are as follows 

  7817   Wed Dec 12 17:26:47 2012 RijuUpdate Testing AG4395A+GPIB

I repeated my experiment to get noise level. To get that I disconnected the bandpass filter SBP-10.7  from channel A of network analyzer AG4395A and terminated both the open ends (open end of filter and open end of channel A) with 50ohm terminator.

Reference level had been corrected, signal and noise data had been collected separately w.r.t that level.

Command for GPIB:   ./netgpibdata.py -i 192.168.113.105 -d AG4395A -a 10 -f filename

The result is as follows

 

  13009   Tue May 23 18:09:18 2017 KaustubhConfigurationGeneralTesting ET-3010 PD

In continuation with the previous(ET-3040 PD) test.

The ET-3010 PD requires to be fiber coupled for optimal use. I will try to test this model without the fiber couple tomorrow and see whether it works or not.

ELOG V3.1.3-