40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 161 of 335  Not logged in ELOG logo
ID Date Author Type Category Subject
  8782   Fri Jun 28 11:33:32 2013 SteveUpdate 40MARS wireless network problem


I'm not sure what's going on today but we're seeing ~80% packet loss on the 40MARS wireless network.  This is obviously causing big problems for all of our wirelessly connected machines.  The wired network seems to be fine.

I've tried power cycling the wireless router but it didn't seem to help.  Not sure what's going on, or how it got this way.  Investigating...

 Mike and Christian brought over a Mac laptop for surf Alex. 

They power cycled the wireless router of 40Marsh and labtops are working.  Seeing 75-80% signals on all 3 Dell lab top sisters at both end of the lab

  8781   Fri Jun 28 02:23:00 2013 JenneUpdateLSCNeed to measure sensing matrix at REFL165

[Lisa, Rana, Jenne]

Lisa asked to see a model of the PRMI sensing matrix with REFL165 included, in the hopes that it wouldn't be as degenerate as REFL33.


The conclusion, immediately after looking at this, is that I should make sure the REFL beam is nicely aligned onto the REFL165 PD (Koji did some tests, swapping out the REFL165 resonant PD with a broadband PD, and I don't remember if he aligned beam back onto the REFL165 PD).  Then, I need to measure the PRMI sensing matrix, including REFL165.  Hopefully, it is similar to the model, and we can use it as our 3f diode for locking.

  8780   Fri Jun 28 02:12:41 2013 JenneUpdateLSCPRCL locking again - ASC work

Rana had the epiphany that I didn't have any antiwhitening for my POP QPD.  Ooops. 

We looked at the schematic for the Pentek Generic board (pdf), and saw that it has a Zero @ 15Hz, and Poles @ 150Hz and 1500Hz, times 2 stages.  We determined from the TF that I posted that probably both stages are engaged, so I made an antiwhitening filter consisting of the inverse (so, 2 poles at 15Hz, 2 zeros at 150Hz and 2 zeros at 1500Hz).  [Rana points out that for this low frequency system we may not want to include the 1500Hz compensation, since it is probably just enhancing ADC noise].  The ASC system worked really well, really easily, after that.

Another note though, the AA stage of the Pentek Generic boards have 4 poles at 800Hz, which are not compensated.

Rana also added a 60Hz comb to the filter bank with the AntiWhitening, since the QPD has an unfortunately large amount of 60Hz noise.  Also, the 60Hz lowpass in the ASC loop was engaged for both pitch and yaw.

Rana, Lisa and Manasa also found that the ASC system was *more* stable with the PRM oplev ON. 

So, the ASC locking situation is:

PRM oplev loops on.

AS-POP_QPD_[PIT/YAW] filter banks with FM1, FM6 on.

ASC-PRCL_[PIT/YAW] filter banks with FM1, FM5, FM6 and FM9 on.



(No triggering yet).

The ASC Up and Down scripts (which are called from the buttons on the ASC screen) have all of these gain settings, although they assume for now that all the filters are already on.

Here's a screenshot of the power spectra showing the angular motion suppression. The PDF is attached so you can zoom in and see some details.  The dashed lines are the "PRMI locked, ASC off" case, and the solid lines are the "PRMI locked, ASC on" case.  You can see that according to the QPD, we do an excellent job suppressing both the pitch and yaw motion (although better for yaw), but there isn't a huge effect on POPDC or POP110I.  While we could probably do better if we had a 2 QPD system with the QPDs at differet gouy phases, this seems to be good enough that we can keep the PRMI locked ~indefinitely. 


I would like to compile the ASC model, so that I can implement triggering.  For tonight, we did not have the ASC engaged during our PRMI+Xarm tests (see Manasa's elog), but I think it'll make things a little easier if we can get the ASC going automatically.

  8779   Fri Jun 28 02:12:21 2013 manasaUpdateLSCPRMI + X arm ALS

X arm stabilized using ALS while PRMI stayed locked

[Rana, Lisa, Jenne, Manasa]

Attachment 1

Time series : ALS enabled at t = 0 and disabled at t = 95s


What we did:
1. Jenne will elog about ASC (POP QPD) updates.
2. Found the beat note between Xarm green and PSL green.
3. Stabilized arm fluctuation by enabling ALS servo.
4. Scanned the arm for carrier resonance by ramping on the offset and set the offset such that we had IR resonating (TRX fluctuated between 0.1 and 0.8 counts).
5. Disabled the ALS servo and locked PRMI using AS55 for MICH and REFL33 for PRCL.
6. Enabled ALS.

Enabling ALS to detune the arm out of resonance kept PRMI locked  (currently for a span of few tens of seconds). However we could not see PRMI locked as stably compared to when the arms are misaligned. Everytime the offset was set IR to resonate, the PRMI was kicked out of lock.

Also there is some leakage at the arm transmission when PRMI was locked. The leakage was visible at ETMX transmission as flashes in different higher order modes indicating the not-so sufficient ALS stability. The leakage sets an offset at TRX measuring 0.01-0.05 counts.

To do list:
The ALS_OFFSETTER1 has to be calibrated in FSR. We were giving random offsets to do the offset scan.

Installed a filter before ETMXT camera to remove the refl green. (Note to myself: The filter needs to go on a better mount/adapter).

  8778   Thu Jun 27 23:18:46 2013 jamieUpdateComputer Scripts / ProgramsWARNING: Matlab upgraded


I moved the old matlab directory from /cvs/cds/caltech/apps/linux64/matlab_o to /cvs/cds/caltech/apps/linux64/matlab_oo

and moved the previously current matlab dir from /cvs/cds/caltech/apps/linux64/matlab to /cvs/cds/caltech/apps/linux64/matlab_o.

And have installed the new Matlab 2013a into /cvs/cds/caltech/apps/linux64/matlab.

Since I'm not sure how well the new Matlab/Simulink plays with the CDS RCG, I've left the old one and we can easily revert by renaming directories.

Be careful with this.  If Matlab starts re-saving models in a new file format that is unreadable by the RCG, then we won't be able to rebuild models until we do an svn revert.  Or the bigger danger, that the RCG *thinks* it reads the file and generates code that does something unexpected.

Of course this all may be an attempt to drive home the point that we need an RCG test suite.

  8777   Thu Jun 27 23:01:39 2013 gautamUpdateGeneralITMx Oplev-servo gains adjusted


 With rana's input, I changed the ITMx oplev servo gains given the beam path had been changed. The pitch gain was changed from 36 to 30, while the yaw gain was changed from -25 to -40. Transfer function plots attached. The UGF is ~8Hz for pitch and ~7Hz for yaw.

I had to change the envelope amplitudes in the templates for both pitch and yaw to improve the coherence. Above 3Hz, I multiplied the template presets by 10, and below 3Hz, I multiplied these by 25.





  8776   Thu Jun 27 22:52:38 2013 Rana, Gabriele, FrancescoSummaryComputer Scripts / ProgramsLIGO-DV installed

I installed ligoDV in the /ligo/apps/ligoDV/

Now, by pointing the tool at the local NDS2 server (megatron:31200) you can access the recent local data (raw, trends, etc.)

by running /ligo/apps/ligoDV/ligodv from the command line.

  8775   Thu Jun 27 22:05:25 2013 ranaUpdateGeneralPianosa fixed

The keyboard on Pianosa workstation has been flaky for the last several days at least. Today, it was having troubles mounting the linux1 file system and was hanging on boot.

People in the control room emailed Jamie and then grew afraid of the computer. Annalisa suggested that we put garlic on it since was clearly possessed.

Typing 'dmesg' at the command prompt, I found that there were thousands of messages like these:

[ 3148.181956] usb 2-1.2: new high speed USB device number 68 using ehci_hcd
[ 3149.773883] usb 2-1.2: USB disconnect, device number 68
[ 3150.228900] usb 2-1.2: new high speed USB device number 69 using ehci_hcd
[ 3152.076544] usb 2-1.2: USB disconnect, device number 69
[ 3152.787391] usb 2-1.2: new high speed USB device number 70 using ehci_hcd
[ 3154.123331] usb 2-1.2: USB disconnect, device number 70
[ 3154.578459] usb 2-1.2: new high speed USB device number 71 using ehci_hcd

So I replaced the existing Dell keyboard with an older Dell keyboard and the bad messages have stopped. No garlic was used.

  8774   Thu Jun 27 21:59:42 2013 ranaUpdateComputer Scripts / ProgramsMatlab upgraded

I moved the old matlab directory from /cvs/cds/caltech/apps/linux64/matlab_o to /cvs/cds/caltech/apps/linux64/matlab_oo

and moved the previously current matlab dir from /cvs/cds/caltech/apps/linux64/matlab to /cvs/cds/caltech/apps/linux64/matlab_o.

And have installed the new Matlab 2013a into /cvs/cds/caltech/apps/linux64/matlab.

Since I'm not sure how well the new Matlab/Simulink plays with the CDS RCG, I've left the old one and we can easily revert by renaming directories.

  8773   Thu Jun 27 21:45:48 2013 ranaUpdatePEMBLRMS are going crazy

Its an increase in the microseismic peak. Don't know what its due to though.

  8772   Thu Jun 27 19:17:03 2013 manasaUpdateLSCXarm ALS out-of-loop noise

Measured frequency noise is ~10Hz/rtHz @100Hz. 

Measure the out-of-loop noise of Xarm ALS:

1. The X-arm was locked for IR using PDH error signal.

2. 'CLEAR HISTORY' of the phase tracker filters.

3. Measured the power spectrum of the phase tracker output. I have used the newly created calibrated channel "PHASE_OUT_DQ. So the phase tracker output now reads in Hz.


The measurement was done with beat note frequency at ~40MHz. The flat noise level of 10Hz/rtHz from 20-100Hz (in plot 2) is not good. We should investigate as to what sets this noise level. The spike at 60Hz is because the 60Hz frequency comb filter was not enabled.

I plan to the following to get a clearer outlook
1. Connecting the beat box to an RF source and measure the noise levels for a range of frequency inputs to the beatbox.
2. Measure the noise at C1:ALS-BEATX_FINE_I_IN1 (before the antiwhitening filters) and check whether the new whitening filters has done anything good with respect to minimizing the DAQ noise.


  8771   Thu Jun 27 18:24:25 2013 CharlesUpdateISSCTN Servo Prototype Characterization - Done Correctly

As I showed in [elog 8759], measuring the transfer function of my prototype servo was difficult due to physical limitations of either some portion of the construction or even the SR785 itself. To get around this, I tried using lower input excitation amplitudes, but ran into problems with noise.

Finding a TF consistent with theoretical predictions made by LISO was easy enough when I simply measured the TF of each of the two filter stages individually and then multiplied them to obtain the TF for the full servo. I still noticed some amount of gain limitation for 100 mV and 10 mV inputs, although I only had to lower the input to 5 mV to avoid this and thus did not see significant amounts of noise as I did with a 1 mV input. The individual transfer functions for each stage are shown below. Note that the SR785 has an upper cutoff frequency of 100 kHz so I could analyze the TF beyond this frequency. Additionally, the limited Gain Bandwidth Product of OP27 op-amps (used in the prototype) causes the magnitude and phase to drop off for f > 10^5 Hz approximately. The actual servo will use AD829 op-amps which have a much larger GBWP.


The measured TFs above are very close to ideal and agree quite well with theoretical predictions. Based on the [circuit schematics],

  • Stage 1 should have Gain ~ 10^3 until the pole at f ~ 10 Hz  
  • Stage 2 should exhibit a DC pole, a zero at f ~ 10^3 Hz and then unity gain for f > 10^3 Hz

Indeed, this is exactly what we can see from the above two TFs. We can also multiply the magnitudes and add the phases (full_phase = phase1 + phase2 - 180) to find the TF for the full servo and compare that to the ideal TF produced by LISO,


And we find exceptionally consistent transfer functions, which speaks to the functionality of my prototype 

As such, I'll proceed with designing this servo in Altium (most of which will be learning how to use the software)

Note that all TFs were taken using the netgpibdata python module. Measurement parameters were entered remotely using the TFSR785.py function (via control room computers) and following the examples on the 40m Wiki.

  8770   Thu Jun 27 18:11:53 2013 gautamUpdateGeneralITMx Oplev-POX looks beam okay


 Jenne just aligned the X arm and I got a chance to check the status of the POX beam coming out of the chamber. Turned the Oplev servo off so that the red beam could be blocked, turned all the lights off, and had a look at the beam in the vicinity of the mirror steering the Oplev-out beam to the QPD with an IR view-card. The beam is right now about half a centimeter from the pitch knob of the said mirror, so its not getting clipped at the moment. But perhaps the offending mirror can be repositioned slightly, along with the Oplev QPD such that more clearance is given to the POX beam. I will work this out with Steve tomorrow morning. 

  8769   Thu Jun 27 17:49:17 2013 manasaUpdateGreen Lockingc1als model edited


 Could be that this is OK, but it doesn't yet make sense to me. Can you please explain in words how this manages to apply the calibration rather than just add an extra gain to the phase tracking loop?

The calibration is applied by adding an extra gain. But, I missed the point that I should be doing this outside the phase-tracking loop....my BAD .

So I modified the model such that the calibration is done without disturbing the phase tracking loop.

Right now, epics input 'PHASE_OUT_CALIB' accepts the calibration and we get the calibrated phase tracker output converted from deg to Hz at 'PHASE_OUT_HZ'.  I have also made it a DAQ channel to be used with dataviewer and dtt.

medm screens have been modified to accommodate these additions to the phase tracker screen. I used Yuta's phase tracker calibration data in elog to set PHASE_OUT_CALIB in the medm screens.



  8768   Thu Jun 27 17:41:08 2013 AnnalisaUpdateGreen LockingETMY -beat note found!


 Y arm beat note found!


  • Arm lock on IR to align the mirrors
  • Green Laser locked on the arm
  • Green Transmission on the PSL and PSL green beam aligned into the BeatPD: they have been aligned both in the near field (looking at the beam on the camera) and in the far field (removing the DC PD and looking at the two beams on the wall)
  • Checked the PSL temperature and, following the plot of the beat note measurement between "Alberto" laser and PSL reported in elog 8396, I got an idea of the range of temperature where the beat note could be found (I used the values of the second curve)
  • Scanned the Y-green laser temperature using the slow servo on the ALS command window


  • PSL temperature = 31.58°C
  • PSL slow servo temperature offset = 0
  • "Alberto" laser temperature = 40.35 °C (ADJ = 0)
  • Thermal output offset on the ALS screen = -11140
  • Beat note frequency = 22 MHz
  • Beat note amplitude = -31.7 dBm

The green transmission on the PSL reads about 500 cts, and the transmitted power is about 50 uW.

(the second peak on the screen in the picture is the 29 MHz of the MC)

  8767   Thu Jun 27 17:09:41 2013 JenneUpdateLSCPRCL locking again - POP PIT work

Last night before dinner, I copied over the ASC yaw servo filters to the ASC pitch filter bank.  Using ASC gain of +0.001, I was getting the ~250Hz oscillations that Rana and I had seen with yaw. 

Rana pointed out to me that my measured TF of the yaw loop doesn't look right up in the several hundred Hz region:


As you can see on the right side, which is all of the PRCL ASC yaw filter banks, multiplied by a simulated pendulum filter, the magnitude should just keep decreasing.  However, on the measured plot on the left, you can see that I have a little gain hump.  I'm not sure what this is from yet.

  8766   Thu Jun 27 17:04:49 2013 JenneUpdatesafetyNitrogen bottle too hot - overpressured

All of us in the control room / desk area heard a sudden whoosh of air a few minutes ago.  It kind of sounded like a pressure washer or something.  We determined that the northmost nitrogen bottle outside the front door was letting out all its gas. 

It's a gazillion degrees outside (okay, only 91F, according to a google of "Caltech Weather"), and those bottles are in direct sun all day.

We are leaving the bottle as-is, since it seems like its has finished, and nothing else is happening.

  8765   Thu Jun 27 15:58:27 2013 SteveUpdatePEMPSL enclosure particle counts


 Particle counts were measured inside the PSL enclosure at 40VAC variac setting.

Directly under HEPAs, on the east half of the optical table : 0.3 micron    20  particles / cu ft,       0.5 micron     0  p / cu ft,      0.7 micron        0 p / cu /ft

Away from the HEPAs, on the west edge of the op table:     0.3 micron   960  particles / cu ft,      0.5 micron    50 p / cu ft,       0.7 micron      20 p / cu ft

We may want to increase the RPM a little bit.


Checked our counters against recently calibrated Met One GT-526:

#1 is right on, #2 measured 25% less (it will go for calibration)


Flow bench at the south end :   zero particle for all 3 sizes


IOO chamber particle logging  measures  0.5 and 1 micron.  Chamber opening limit is set to 10,000 particles max of 0.5 micron

At 10,000 p of 0.5 micron means ~100,000 - 180,000 p of 0.3 micron

We may have to lower the limit.

  8764   Thu Jun 27 15:50:03 2013 JenneUpdatePEMBLRMS are going crazy

The BLRMS are totally crazy today!  I'm not sure what the story is, since it's been this way all day (so it's not an earthquake, because things eventually settle down after EQs).  It doesn't seem like anything is up with the seismometer, since the regular raw seismic time series and spectrum don't look particularly different from normal.  I'm not sure what's going on, but it's only in the mid-frequency BLRMS (30mHz to 1Hz).

Here are some 2 day plots:





  8763   Thu Jun 27 10:45:41 2013 SteveUpdateGeneral40MARS wireless network problems



I'm not sure what's going on today but we're seeing ~80% packet loss on the 40MARS wireless network.  This is obviously causing big problems for all of our wirelessly connected machines.  The wired network seems to be fine.

I've tried power cycling the wireless router but it didn't seem to help.  Not sure what's going on, or how it got this way.  Investigating...

 I'm still seeing some problems with this - some laptops are losing and not recovering any connection. What's to be done next? New router?

 We had the same problem yesterday. However the Vacuum Dedicated laptop worked with fewer disconnects. Christian is coming over this after noon to look at this issue.

This happened a few weeks ago and it recovered misteriously. Jamie did not understand it.

  8762   Thu Jun 27 05:44:51 2013 ranaUpdate 40MARS wireless network problems


I'm not sure what's going on today but we're seeing ~80% packet loss on the 40MARS wireless network.  This is obviously causing big problems for all of our wirelessly connected machines.  The wired network seems to be fine.

I've tried power cycling the wireless router but it didn't seem to help.  Not sure what's going on, or how it got this way.  Investigating...

 I'm still seeing some problems with this - some laptops are losing and not recovering any connection. What's to be done next? New router?

  8761   Thu Jun 27 02:44:33 2013 ranaUpdateGreen Lockingc1als model edited

 Could be that this is OK, but it doesn't yet make sense to me. Can you please explain in words how this manages to apply the calibration rather than just add an extra gain to the phase tracking loop?

  8760   Wed Jun 26 23:32:15 2013 ManasaUpdateGreen Lockingc1als model edited

I have modified the ALS model to now include PHASE_OUT calibration for both X and Y. MEDM screen has not been edited to include these yet.


  8759   Wed Jun 26 21:52:55 2013 CharlesUpdateISSCTN Servo Prototype Characterization

Following the circuit design in elog 8748, I constructed a prototype for the servo portion of the ISS (not including the differential amp) to be used in the CTN experiment. The device was built on a breadboard and its transfer function was measured with the Swept Sine measurement group of an SR785. For various excitation amplitudes, the transfer function (TF) was not consistent.


Recall the ideal transfer function for this particular servo and consider the following comparisons.

  • The unity gain frequency is consistent, and the measured TFs all exhibit some amount of 1/f behavior up to this point, but there is no zero around f~10^3 and individual low-frequency poles/zeros are not visible.
  • For each of the inputs, there is a feature that is not exhibited in the ideal TF. We see a large drop in gain a little past 10^3 Hz for a 100mV input, just past 10^2 Hz for a 10 mV input and around 10^1 Hz for a 1 mV input.
  • The ideal TF also goes as 1/f for f < 10 Hz, so I believe the low-frequency behavior of each of the above transfer functions is simply a physical limitation of the breadboard or the SR785, although I don't think this is caused by the circuit elements themselves. I used OP27 op-amps in the prototype as opposed to AD829 op-amps which are must faster and end up amplifying noise. To ensure that these op-amps were not the source of the gain limitation, I also tried using AD829 op-amps. The resulting transfer functions are shown below.
  • Both the frequency at which we see the anomalous feature and the maximum gain increase nearly proportional to the increasing input excitation amplitude.

This gain limitation is problematic for characterizing prototypes as my particular servo has very large gain at low frequencies. 


At the risk of looking too deeply into the above data,

  • It appears there is a slight change in slope around f ~ 10^3 Hz which would be consistent with the ideal TF.
  • For f > 10^3 Hz, one can easily see the TF goes as 1/f. The slope for f < 10^3 Hz is not as clear, although it obviously does not show 1/f^2 behavior as we would expect from the ideal TF.
  • We see the same gain limitation around G ~ 55 as we did with OP27 op-amps.

Unfortunately, the noise was too large for lower excitation amplitudes to be used to any effect. I'll try this again tomorrow, just as a sanity check, but otherwise I will proceed with learning Altium and drawing up schematics for this servo.


  8758   Wed Jun 26 19:02:38 2013 gautamUpdateGeneralITMx Oplev (not quite?) Fixed



Steve and I tried to fix the Oplev situation detailed in elog 8684, today afternoon. We have come up with a fix which needs to be adjusted, possibly completely overhauled depending on whether the mirror steering the return beam to the QPD is blocking the POX beam coming out. 


  • ITMx Oplev servo was first turned off.
  • It turns out we were hitting the wrong pair of Oplev steering mirrors inside the chamber. The incident beam was hitting a mirror meant for IR light (see sketch below) and not the intended first steering mirror. We pretty much redid the entire alignment (we used a pair of irises initially to set up a reference path) so as to hit the right pair of mirrors inside the chamber. At the end of today's efforts, the beam is reasonably well centered on both the intended mirrors, and there is not as much scattered light. 

Situation in the chamber: the black line is meant to indicate what was happening, the red is indicative of the present path.



  • The Oplev laser was installed in 2011 (October 13,2011 to be precise), and the quality of the beam coming out of the laser was pretty bad (the cross section was badly distorted even before it hit any optics). Steve thought this laser had reached the end of its lifetime, so we replaced the laser with a new one. Output power of this new laser has yet to be measured. The power-supply for the laser was also dodgy so we switched that out as well, and installed a new power supply. New laser and power supply are working satisfactorily. The old power supply will be checked with another laser tomorrow to gauge its status.
  • The cross-section of the beam from the new Oplev laser was deemed satisfactorily circular and we centred it on the first of the two lenses in the beam-path. We are getting 2.81 mW of power from the new laser.
  • In order to hit the right pair of Oplev steering mirrors while avoiding the clipping the beam on the tip-tilt/PR2 suspension, we had to sort of widen the angle of the beam going in, and so both steering mirrors, as well as the second lens in the beampath were shifted around. I have attached before and after pictures of the layout on the table. We adjusted things till the beam is reasonably well centred on both steering mirrors inside the chamber.
  • Because of the changed beam-path, the return Oplev beampath also changed, and so we had to move the steering mirror directing the return beam to the QPD as well. In its new position, it may be clipping the POX beam.
  • The beam is not getting clipped anywhere on the table now. It is also well centered on the two lenses in its path.
  • We placed two irises marking the new path so that we have a reference if the alignment needs to be changed again.
  • Turned ITMx Oplev servo back on.

Other stuff:

  1. The higher--power new laser means that the QPD sum is now ~6000counts (up from ~3500). The power in the return beam is 143.5 uW, which is ~5% of the power of the input beam.
  2. We centred the spot on the QPD, though when we excited ITM in yaw, the spot doesn't quite move horizontally, rather, it moves somewhat diagonally
  3. I turned the lights off, blocked the beam and measured the zero-current counts for the various QPD quadrants. These were all less than 1.5, and I reset these values on the ITMx Oplev screen according to my measurements.
  4. While viewing the spot of the Oplev beam on the ITMx face, we noticed that there were two spots, one less bright than the other. Steve suspects that this is because of multiple reflections from the chamber window.
  5. The status of the POX beam has to be verified (i.e is it getting clipped by the steering mirror for the return beam?)
  6. There was a Thorlabs PD on the table which had a green power LED. Jenne had asked me to cover this LED up, which I did with bits of tape.

Plan of action:

  • The spot size at the QPD is right now about 3mm. We may want to improve this by moving the first of the two lenses in the beam-path (there is not a whole lot of room to maneuvering the second lens.
  • Jenne just aligned and locked the X-arm, and doesn't think that the POX beam is being blocked, but I will verify this sometime tomorrow.








  8757   Wed Jun 26 15:11:08 2013 John ZweizigUpdateSUSNDS2 Status


I've restarted the NDS2 process on Megatron so that we can use it for getting past data and eventually from outside the 40m.

1) from /home/controls/nds2 (which is not a good place for programs to run) I ran nds2-megatron/start-nds2

2) this is just a script that runs the binary from /usr/bin/ and then leaves a log file in ~/nds2/log/

3) I tested with DTT that I could access megatron:31200 and get data that way.

There is a script in usr/bin called nds2_nightly which seems to be the thing we should run by cron to get the channel list to get updated, but I' m not sure. Let's see if we can get an ELOG entry about how this works.

Then we want Jamie to allow some kind of tunneling so that the 40m data can be accessed from outside, etc.

 I have done the following:

  * installed the nds2-client in /ligo/apps/nds2-client

  * moved the nds2 configuration directories to /ligo/apps/nds2/nds2-megatron

  * set up a cron job to update the channel list every morning at 5 am. The cron line is:

     15 5 * * * /usr/bin/nds2_nightly /ligo/apps/nds2/channel-tracker /ligo/apps/nds2/nds2-megatron

    cron will send an email each time the channel list changes, at which point you will have to restart the server with:

     cd /ligo/apps/nds2/nds2-megatron
     pkill nds2

  * restarted nds2 with updated channel lists.

  8756   Wed Jun 26 13:37:13 2013 JenneUpdateIOOMC very misaligned - put back

Not sure why it was so poorly aligned, since the misalignment "event" happened while we were all away at lunch, but I steered the MC optics until their SUSYAW and SUSPIT values were about the same as they were before they got misaligned.  MC autolocker took over, and things are back to normal.

  8755   Wed Jun 26 11:45:06 2013 gautamUpdateGeneralPID tuning-Doubling Oven at Y end



Having established the serial link between the Doubling oven at the Y-end and the Raspberry pi, I wanted to use this interface to collect time-series from the oven after applying a step function in an effort to measure the transfer function of the oven. The idea was that knowing the transfer function of the oven, I could use some simple PID tuning rules like the Ziegler-Nichols rule or put everything in SIMULINK and find the optimal PID gains. However, I am unable to extract the oven transfer function from the time series data collected.


Last night, between 920pm and 940pm I applied a step function to the doubling oven by changing the setpoint of the controller from 35.7 Celsius to 39 Celsius (having checked elog 3203 to get an idea of a 'safe' step to apply). I then used the Pi to collect time series data for 6 minutes, then returned the set-point back to 35.7 Celsius, and took another time-series to make sure things were back to normal. Having gotten the time series data, I attempted to fit it using some exponentials which I derived as follows:



I couldn't think of a way to get the laplace transform of the time-series data collected, so I approximated the oven transfer function as a system with a one simple pole i.e. G(s)=K/(1+Ts), where K and T are parameters that characterise the oven transfer function. I then plugged in the above expression for Y(s) into Mathematica (knowing X(s)=constant/s, and H(s) = 250 + 60/s +25s from the PID gains) and did an inverse laplace transform to find a y(t) with two unknown parameters K and T to which I could fit the time-series data.


The time-series data collected via the Pi after applying the step was this:


 The inverse laplace transform from mathematica yielded the following (formidable!) function (time, the independent variable, is x, and the fitting parameters are a=K and b=T where K and T are as described earlier):


(39*(exp(x*(1/(2*(25*a - b)) - (125*a)/(25*a - b) - sqrt(1 - 500*a+ 56500*a^2 + 240*a*b)/(2*(25*a - b)))) - exp(x*(1/(2*(25*a - b)) - (125*a)/(25*a - b) + sqrt(1 - 500*a + 56500*a^2 + 240*a*b)/(2*(25*a - b)))))*a)/sqrt(1 - 500*a + 56500*a^2 + 240*a*b)

My best attempts to fit this using MATLAB's cftool have given me useless fits:


I tried changing the start-points for the fitting parameters but I didn't get any better fits.

To Do:

  1. Explore other fitting options.
  2. Try and find a way to Laplace transform the time-series data so I can do the fitting in the s-domain.
  3. I have some tweaking to do as far as the python scripts on the pi are concerned.
  4. I have to get the current temperature readings onto one of the unused Y-arm EPICS channels, and log that data ~ once every 10 seconds.

Misc Remarks:

  1. The time-series data has a 'stepped' appearance because of the resolution of the temperature sensor: it is 0.1 Celsius.
  2. The sampling rate of the data-acquisition is limited; right now, I wait for 0.15 seconds after sending the command word to the controller before reading the data. When I set the wait-period any lower than this, I get errors. This has to be investigated more as I feel I should be able to get better sampling with the advertised baudrate of 115200, but in any case, it looks like it is sufficient for our purposes.


  8754   Wed Jun 26 11:32:11 2013 ManasaUpdateGreen Lockingc1als model edited

I have added more DAQ channels to the c1als model. Installed and restarted the model on c1ioo. Frame builder restarted.

DAQ channels added:

  8753   Wed Jun 26 04:38:02 2013 JenneUpdateLSCPRCL locking again - ASC success

With Rana's help/supervision/suggestions, I have closed the loop on the PRMI ASC servo with the new QPD.  I think I've had it locked for ~30+ minutes now.  It was locked for ~45 minutes, but then the MC momentarily lost lock.  I immediately recovered the PRMI+ASC (after small PRM yaw tweaking, since the ASC isn't triggered yet, so the MC lockloss caused a big yaw step function to go to the PRM, which displayed a bit of hysteresis.).

My biggest problem was that I didn't really understand Koji's servo filter choices, so I wasn't using the right ones / doing good things.  In particular, I need to compensate for the oplev servo filters.  The oplev servo shape is something like ^, so the 1/(1+G) shape is something like =v= (ignoring the lower horizontal lines there).  For tonight, we just turned off the PRM oplevs, but clearly this isn't a permanent solution.  (Although, after Rana went in and roughly centered the PRM oplev, we noticed that turning the oplev on and off doesn't make a huge difference for the PRM....we should investigate why not.  Also, we turned off the FM2 3.2Hz resonant gains in the PRM oplevs, since the Q of those filters is too high, much higher than our actual stacks). 

Rana and I also locked the PRM-ITMY half cavity, and used that beam to realign the beam onto the POP QPD, POP110 PD, and the camera. 

The POP QPD pitch and yaw signals with the half cavity have some noise, that looks like 60Hz crap.  Since this goes away (rather, is much less noticeable) with the regular sideband-locked PRMI, we suspect this is a problem with perhaps the normalization, with the sum very low, and having some noise on it.

Once we had our ASC filters set up (not the 10Hz boost yet though, I think), if I increased the gain from -0.02 to -0.03, we start to get some gain peaking.  With a gain of -0.04, the peak is very noticeable around 250Hz.  We aren't sure where this is coming from, since it shouldn't be coming from the ASC loop.  The UGF of that loop is much lower (I measured it, to check, and the UGF is ~5Hz). Anyhow, this is still a mystery, although the gain of -0.02 holds the cavity pretty well.

I measured the power spectra of the POP QPD pit, yaw, sum, as well as POPDC and POP110I, with the ASC loop on and off (dashed lines are with the loop on.  You can see that the yaw motion as seen on the QPD was reduced by almost 2 orders of magnitude below 1Hz.  It also looks like we can win some more by turning on the equivalent pitch ASC servo (this is also something we see when looking at the dataviewer traces).

I also tried to measure the PRMI sensing matrix, but I get some weird results, even after I double the drive actuation.  I need to be checking whether or not my drive is actually coherent with the error signals that I'm seeing, because right now I'm not sure that I believe things. I'm going to leave that on the to-do list for tomorrow night though.

Next up:

* Engage POP QPD -> pitch loop, copying yaw loop.

* enable ASC triggering

* model PRMI sensing matrix and error signals, bringing one arm into resonance

* Lock the PRMI, and bring the Xarm into IR resonance using the ALS system.


Here are some numbers and plots from the night:

Right now, I'm locking the LSC with:

MICH LSC with AS55Q, FMs 4 and 5 on, FM 3 is triggered, gain = -40.0, normalized by sqrt(POP110I)*0.1

PRCL LSC with REFL33I, FMs 4 and 5 on, FM 9 is triggered, gain = +2.5, normalized by sqrt(POP110I)*10

(FM3 of MICH and FM9 of PRCL are the same, just in different spots).

The ASC (only POP yaw -> PRM yaw right now) has:

FMs 1,2,5,6 on (1 = integrator [0:0.1], 2 = 3.2 res gain, 5 = [1000,1000:1 and gain of 0.01], 6 = 10Hz boost).  Gain = -0.020,  Limit=5000.

Turn off the input, turn on the output and the gain, clear the histories (to clear out the integrator in FM1), then turn on the input.

PRM oplev is OFF. (need to put in a filter to compensate for it in the ASC servo, but for tonight, we just turned it off.)

We measured the spectra of the POP QPD signals with the ASC loop on and off:


I also measured the ASC loop (with the PRM oplev still off):




(sorry about the separate plots - I can't make DTT give me more than 2 plots on a page at a time right now, so I'm giving up, and just making 3 separate pages)

Weird sensing matrix, unsure if I'm really getting good coherence:


  8752   Wed Jun 26 01:30:31 2013 ranaSummaryPEMVariation in 10-30 Hz seismic RMS

For quite a while (no one knows how long), we've seen fluctuations in the 10-30 Hz seismic motion. This shows up as the purple trace on the seismic BLRMS on the wall projector.

The second plot shows that this is not only a periodic increase in the usual 29.5 Hz HVAC peak, but also an anomolous 32.2 Hz peak. Probably some malfunctioning machinery - maybe in the 40m or maybe on the roof.

  8751   Wed Jun 26 00:15:51 2013 AnnalisaUpdateGreen LockingETMY - green locking and beat note setup

[Koji, Annalisa]

Alignment improving

  • The alignment of the green beam injected into the Yarm has been improved, and when the green laser is locked on the cavity in 00 mode we moved from 500 cnts to almost  650 cnts in transmission on the PSL table. Now we have about 70 uW transmitted.
  • Since the beam size on the GRTY PD was too big, I put a lens to focus it better.

Beat note setup

  • The Ybeat RFmon was connected back to the power splitter that Yuta put and Manasa temporarily removed (as described in elog 8666), so that now we are using again the SUM port to monitor the beat signal.


  • Align better the beams on the BeatPD, in order to get a stronger beat note
  • Calibrate the ALS screen to tune remotely the laser temperature
  • Find the beat note!



  8750   Tue Jun 25 23:57:30 2013 ranaUpdateSUSNDS2 Status

I've restarted the NDS2 process on Megatron so that we can use it for getting past data and eventually from outside the 40m.

1) from /home/controls/nds2 (which is not a good place for programs to run) I ran nds2-megatron/start-nds2

2) this is just a script that runs the binary from /usr/bin/ and then leaves a log file in ~/nds2/log/

3) I tested with DTT that I could access megatron:31200 and get data that way.

There is a script in usr/bin called nds2_nightly which seems to be the thing we should run by cron to get the channel list to get updated, but I' m not sure. Let's see if we can get an ELOG entry about how this works.

Then we want Jamie to allow some kind of tunneling so that the 40m data can be accessed from outside, etc.

  8749   Tue Jun 25 23:49:04 2013 AnnalisaUpdateSUSETMY Oplev

I had some problem with the Oplev Servo today. I was working at the mode matching fine tuning and I left the Oplev servo enabled while aligning.

When I opened the Yend table lids, the Oplev beam started moving on the QPD and the Oplev servo didn't help in stopping the mirror movement, but it increased it.

So, the mirror was oscillating at a frequency of a few Hz

Koji suggested that maybe the shaking is due to the air conditioning moving the beam, so the servo tries to feed back the signal to the mirror, even if the mirror doesn't actually move.

I also measured the transfer function for the Oplev, but it didn't show any strange behavior.

  8748   Tue Jun 25 22:57:01 2013 CharlesUpdateISSProposed ISS for CTN Experiment

Following Tara's noise budget, I have developed the following ISS, whose transfer function was computed with LISO and is also displayed below. The transfer function was computed from the output of the differential amplifier circuit (i.e. it does not include the portion of the schematic in the dashed box). The differential amplifier is included for completeness. Essentially, the resistor values of this portion (and even the voltage reference if need be) can be modified to handle various signals from PDs in different experiments. Some filtering may also be applied to the signal from the voltage reference. In previous designs for the ISS, a ~30 mHz low-pass filter applied to the output of the voltage reference has also been proposed.



LISO was also used to compute the input-referred noise of this circuit. Using the response function of Tara's PD the noise spectrum was converted from [V / sqrt(Hz)] to [W / sqrt(Hz)] and then subsequently converted to a frequency noise spectrum, specifically [W / sqrt(Hz)] to [Hz / sqrt(Hz)], using the following transfer function which couples RIN to frequency noise in the CTN experiment. In these particular units, we can make a direct comparison between the inherent noise contribution from the servo itself and other more significant noise contributions shown earlier in Tara's noise budget. Indeed, the servo contributes significantly less noise.


This servo has been prototyped on a breadboard and will soon be characterized with the SR785. Additionally, schematics will be drawn up in Altium and eventually put on PCB.

Additional servos for other experiments can be designed once various requirements for noise suppression are explicitly formalized.

  8747   Tue Jun 25 22:50:12 2013 ranaUpdateSUSSUS Screens generation problems?


From the ALS overview screen, opening up the ETMX and ETMY screens gives these white fields. The PV info indicates that the blank fields were made with some macro variable substitution that didn't work well.

Why are these different from the SUS screens I get from the sitemap?

  8746   Tue Jun 25 19:18:07 2013 gautamConfigurationendtable upgradeplan of action for PZT installation

  This entry is meant to be a sort of inventory check and a tentative plan-of-action for the installation of the PZT mounted mirrors and associated electronics on the Y-endtable. 

Hardware details:

  •  PZT mounts are cleaned and ready to be put on the end-tables.
  • The PZTs being used are PI S-330.20L Piezo Tip/Tilt Platforms. Each endtable requires two of these. The input channels have male single-lemo connectors. There are 3 channels on each tip/tilt platform, for tilt, yaw and a bias voltage.
  • The driver boards being used are D980323 Rev C. Each board is capable of driving 2 piezo tip/tilt platforms. I am not too sure of this but I think that the SMA female connector on these boards is meant to be connected with the bias voltage from our Kepco high-voltage power supplies. The outputs on these boards are fitted with SMB female connectors, while the piezo tip/tilt platforms have male single-lemo connectors. We will have to source cables with the appropriate connectors to run between the end-table and rack 1Y4 (see below). The input to these boards from the DAC will have to be made with a custom ribbon connector as per the pin out configuration given in the circuit drawing.
  • High-voltage power supply: KEPCO BHK 300-130 MG. This will supply the required 100V DC bias voltage to the piezo tip/tilts via the driver board. Since each board is capable of driving two piezos, we will only need one unit per end-table. The question is where to put these (photo attached). It doesn't look like it can be accommodated in 1Y4 (again photo attached) and the power cable the unit came with is only about 8ft long. If we put these under the end-tables, then we will need an additional long (~10m) cable to run from these to the driver boards at 1Y4 carrying 100 V. 
  •  We will need long (~10m by my rough measurement at the X and Y ends) cables to run from rack 1Y4 to the endtable to drive the piezos. These will have to be high-voltage tolerant (at least to 100V DC) and should have SMB male connectors at one end and female single-lemo connectors at the other. I have emailed 3 firms (CD International Technologies Inc., Stonewall Cables, and Fairview Microwave) detailing our requirements and asking for a quote and estimated time for delivery. We will need 6 of these, plus another cable with an SMA connector on one end and the other end open to connect the 100V DC bias voltage from the high voltage power supply to the driver boards (the power supply comes with a custom jack to which we can solder open leads). We will also possibly need ~3m long lemo-to-?(I need to check what the input connector for the data acquisition channels) cables for the monitoring channels, I am not sure if these are available, I will check with Steve tomorrow.

Other details:

  • I have attached a wiring diagram with the interconnects between various devices at various places and the type of connectors required etc. The error signal will the the transmitted green light from the cavity, and there is already a DQ channel logging this information, so nothing additional wiring is required to this end.
  • Jamie had detailed channel availability in elog 8580. I had a look at rack 1Y4, and there were free DAC channels available, but I am not sure as to which of the ones listed in the elog it corresponds to. In any case, Jamie did mention that there are sufficient channels available at the end-stations for this purposes, but all of these are fast channels. What needs to be decided is if we are going ahead and using the fast channels, or if we need to find slow DAC channels. 
  • I spoke to Koji about gluing the mirrors to the PZTs, and he says we can use superglue, and also to be sure to clean both the mirror and the tip/tilt surfaces before gluing. In any case, all the other hardware issues need to be sorted out first before thinking about gluing the mirrors.

High-Voltage Power Supply



Situation at rack 1Y4



 Wiring diagram


  8745   Tue Jun 25 12:42:16 2013 gautamUpdateGeneralSerial-interface with Doubling Oven at Y end


I have been working on setting up a serial-link with the temperature controller of the PPKPT crystal doubling oven at the Y-end for some time now. The idea was to remotely tune the PID gains of the controller and get temperature data. The device used to serially interface with the temperature controller is a Raspberry Pi model B, which is connected to the temperature controller by means of a USB to serial adaptor with a PL2303 chip. I installed the interface this morning, and have managed get talking with the doubling oven. I am now able to collect time-series data by ssh-ing to the Raspberry Pi from the control room. I will use this data to manually tune the PID gains for now, though automatic tuning via some script is the long-term goal.



The temperature controller for the doubling oven is a Thorlabs TC200, and supports serial communication via the RS232 protocol by means of a female DB9 connector located on its rear panel. I have hooked up the Raspberry Pi to this port by means of a USB-Serial adaptor that was in one of the cabinets in the 40m control room. After checking the Martian Host Table, I assigned the Raspberry Pi the static IP so that I could ssh into it from the control room and test the serial-link. This morning, I first hooked up the Raspberry pi to an ethernet cable running from rack 1Y4 to make sure I could ssh into it from the control room. Having established this, I moved the raspberry pi and its power supply to under the Y-endtable, where it currently resides on top of the temperature controller. I then took down the current settings on the temperature controller so that I have something to revert to if things go wrong: these are

Set-Point:                           35.7 Celcius

Actual Temperature:          35.8

P-gain:                                 250

I-gain:                                 60

D-gain:                                25

TUNE:                                  ON

I then connected the Pi to the temperature controller using the serial-USB cable, and plugged the ethernet cable in. Rebooted the Pi and ssh-ed into it from the control room. I first checked the functionality of the serial-link by using terminal's "screen" feature, but the output to my queries was getting clipped on the command line for some reason (i.e. the entire output string wasn't printed on the terminal window, only the last few characters were). Turns out this is some issue with screen, as when I tried writing the replies to my queries to a text file, things worked fine. 

At present, I have a python script which can read and set parameters (set-point temperature, actual temperature, PID gains)on the controller as well as log time-series data (temperature from the temperature sensor as a function of time )to a text file on the Pi. As of now, I have only checked the read functions and the time-series logger, and both are working (some minor changes required in the time-series function, I need to get rid of the characters the unit spits out, and only save the numbers in my text-file). 

For the time-being, I plan to apply a step to the controller and use the time-series data to manually tune the PID parameters using MATLAB. I am working on a bunch of shell scripts to automate the entire procedure.

  8744   Tue Jun 25 11:39:13 2013 KojiUpdateLSCArm Cavity scan with X-ALS after ALS servo upgrade

My understanding is that that number is an in-loop evaluation of the loop so far (as the first step of the loop evaluation).
This is not what we can directly compare with the number in the paper.

Basically the entry 8741 is telling us that the new filter suppresses the error signal better than before.
That's clearly shown in the attachment 2.



RMS is now less than 1 kHz or ~50 pm. (in your face, Kiwamu!)

 Isn't this still a factor of 2 away from the limit in the paper?


  8743   Tue Jun 25 10:23:20 2013 SteveUpdatesafetysurf safety training

 Alex Cole and Craig Cahillane received 40m specific,  basic safety training last week.


  8742   Tue Jun 25 10:18:34 2013 Mystery ManUpdateLSCArm Cavity scan with X-ALS after ALS servo upgrade


RMS is now less than 1 kHz or ~50 pm. (in your face, Kiwamu!)

 Isn't this still a factor of 2 away from the limit in the paper?

  8741   Tue Jun 25 00:28:52 2013 rana, manasaUpdateLSCArm Cavity scan with X-ALS after ALS servo upgrade

[Rana, Manasa]

ALS noise suppressed to 1KHz/rtHz. 1kHz RMS.

Plot 1: Scan of X arm by changing offset into Phase Tracker -> Xarm loop. Filter bank ramp time set to 120 s + using a 30 mHz low pass filter. IR beam is aligned to x arm, but not well.

Plot 2: ALS error signal with loop open (BLUE), closed with old filters (PURPLE), and with new, better boost (RED).

Plot 3: Bode plot of new boost (FM10), v. old, sad boost (1:50 pole:zero). RMS is now less than 1 kHz or ~50 pm. (in your face, Kiwamu!)

Changes made to the ALS servo:


ALS-TRX has been calibrated to read from 0-1 instead of counts in 1000 s. Calibration factor = 1/4500 = 0.00022


Old antiwhitening filter has been removed. Added LPF at 1000Hz to remove glitches at high frequencies.


No changes made.


FIlter FM5 modified. 1000:1 changed to 3000:1

5. Offset for ALS scan were given through C1ALS_OFFSETTER1 with LPF50m enabled.


The filter modules of the servo were:






Check PZT out range for ALS. Figure out what the deal is with ALS SLOW servos.

Add DQ channels for ALS.

Automatic ALS up script (enable and disable phase tracker included).



  8740   Tue Jun 25 00:13:00 2013 JenneUpdateCDSProto-ASC implemented in ASS model

I have finished my work on the LSC and ASS models for now. The triggering is all implemented, and should be ready to go.  There are no screens yet.

I have *not* compiled either the LSC or the ASS, since Rana and Manasa still have the IFO.

  8739   Mon Jun 24 16:41:40 2013 JenneUpdateCDSProto-ASC implemented in ASS model

I am working on making the Proto-ASC less "proto".  I have put IPC senders in the LSC model to send the cavity trigger signals over to the ASS model, for ASC use.  I'm partially done working on the ASC end of things to implement triggering.

LSC should be compile-able right now, ASS is definitely not.  But, I expect that no one should need to compile either before I get back in a few hours.  If you do - call me and we'll figure out a plan.

  8738   Mon Jun 24 16:06:17 2013 ManasaSummaryGreen LockingALS model

 I am working on the basic ALS servo model. The simulink model for the same is attached. The loop is not yet complete (I'm still debugging it) ; but this is just an update of where I am right now.

Attached is the simulink and matlab file. 






  8737   Mon Jun 24 11:51:23 2013 JenneUpdateLSCNew modeled sensing matrix


 This is nice - how about figuring out how to plot the measurement and model on the same plot? I guess we need to figure out how to go from counts to Watts.

I haven't done a units conversion for the measured vs. modelled plot,  but at least we can compare the separation between the different degree of freedom signals.  Figuring out why the REFL11 measurement and models are so different is still high on my to-do list.  But at least the measurements that were taken last month are consistent with one another. EDIT:  The separation angles match up pretty well between the 2 sets of measurements, but the overall rotation isn't really consistent.  I do not believe that the phase rotation values that we're using online changed between the measurements, so the I&Q lines should be the same for both seets of measurements....however, I did not write down the phase rotation values at the time of the first measurement, so there's a chance that they were different.  Also, something that I need to monitor is the coherence of my measurement, to make sure I'm really driving and measuring something.


2 measurements, with overall rotation arbitrarily rotated to make MICH lines match up:


Same 2 measurements, without the arbitrary overall rotation:


Measurement vs. Model, with the *modelled* phase arbitrarily rotated:


  8736   Fri Jun 21 16:30:04 2013 SteveUpdateGeneralCapacitor Inventory

The 3 Panasonic Ceramic Kits Books, 1206 NPO, SMT are well stocked. The 4 th one needs to be refilled at some values.

I labeled them on the cover for fast access. See Atm1


The Metalized Polyester Film Book with through holes mount are in good shape also. Atm2


The AVX Ceramic 1206,  Garrett cab, range: 1pF - 22 microF 50V...... 67 values

Note here: that the value of dielectric, capacitance / voltage will vary

NPO: 1 pF - 1 nF /  50V .......37 values

X7R : 1 nF -  0.082 microF /  50V,  0.1 microF /  100V.......27 values

Y5V:  4.7 microF / 6.3 V,  10 microF / 10V,  22 microF / 6.3V.........3 values 


  8735   Thu Jun 20 20:46:16 2013 gautamUpdateIOOWFS debugging-QPD debugging


 I wanted to make sure that the QPD map on the C1IOO_MC_TRANS_QPD.adl screen corresponded to the actual physical quadrants on the photodiode at the MC2 table. We turned MC_WFS_OUT  OFF before fiddling around with a red laser pointer to try and map the quadrants.

I initially verified the correspondence between the various quadrants and the text-fields displaying the outputs using PV_Info. I found that there was good agreement in this respect. So for instance, field adjacent to the quadrant marked "1" on the C1IOO_MC_TRANS_QPD.adl screen had the following input channel: IOO_MC_TRANS_SEG1_INMON. The filter banks were empty and there was just an overall gain on -1 on all four channels. The channels leading to the filter-banks were the 'right' ones: quadrant 1 for the top bank, then quadrants 2,3 and 4 down.

Next, a red laser pointer was used to map the quadrants. Here, there was some disagreement between the physical quadrants and the map on the C1IOO_MC_TRANS_QPD.adl screen, which is summarised in the attached image-the whole thing is sort of rotated 180degrees about the centre. 

The interpretation of the figure is as follows:

quadrant 1 on screen QPD=bottom right quadrant on QPD

quadrant 2 on screen QPD=top right quadrant on QPD

quadrant 3 on screen QPD=top leftt quadrant on QPD

quadrant 4 on screen QPD=bottom left quadrant on QPD

MC_WFS_OUT was turned back ON.






  8734   Thu Jun 20 17:47:44 2013 AnnalisaConfigurationSUSETMY oplev servo

[Jenne, Annalisa]

The ETMY Oplev servo didn't work properly, when it was activated the ETMY moved too much.

We measured the oplev TF for Pitch and Yaw and it turned out that the gain was too low by a factor 3, so we increased the gain from -.250 to -.750 on both.

We also locked the Y arm and we could see that the mirror's oscillations are actually suppressed.


  8733   Thu Jun 20 15:15:39 2013 ranaUpdateIOOWFS debugging

Tried a bunch of stuff, but eventually just turned off the TRANS_QPD loops and loops are stable. Needs more debugging.

  1. Modified the on/off scripts so that the Integrators are no longer toggled. No reason to turn them off since we are clearing the filter bank histories.
  2. With QPD feedback OFF, I have lowered the overall gain by 15x so that its just drift control.
  3. Deleted unused / bad filters from the main filter banks.
  4. Gautam is going to debug the QPD with a red laser pointer and then elog.
  5. Jamie is checking out the MC Coil dewhitening logic to see if that's in a funny state.
ELOG V3.1.3-