40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 128 of 346 Not logged in
ID Date Author Type Category Subject
11002   Wed Feb 11 16:49:41 2015 ranaUpdateelogELOGD restarted

No elog response from outside and no elogd process on nodus, so I restarted it using 'start-elog.csh'.

11001   Wed Feb 11 04:08:53 2015 JenneUpdateLSCNew Locking Paradigm?

[Rana, Jenne]

While meditating over what to do about the fact that we can't seem to hold PRMI lock while reducing the CARM offset, we have started to nucleate a different idea for locking

We aren't sure if perhaps there is some obvious flaw (other than it may be tricky to implement) that we're not thinking about, so we invite comments.  I'll make a cartoon and post it tomorrow, but the idea goes like this.....

Can we use ALS to hold both CARM and DARM by actuating on the ETMs, and sit at (nominally) zero offset for all degrees of freedom?  PRMI would need to be stably held with 3f signals throughout this process.

1) Once we're close to zero offset, we should see some PDH signal in REFL11.  With appropriate triggering (REFLDC goes low, and REFL11I crosses zero), catch the zero crossing of REFL11I, and feed it back to MC2. We may want to use REFL11 normalized by the sum of the arm transmissions to some power (1, 0.5, or somewhere in between may maximize the linear range even more, according to Kiwamu).  The idea (very similar to the philosophy of CESAR) is that we're using ALS to start the stabilization, so that we can catch the REFL11 zero crossing.

2) Now, the problem with doing the above is that actuating on the mode cleaner length will change the laser frequency.  But, we know how much we are actuating, so we can feed forward the control signal from the REFL11 carm loop to the ALS carm loop.  The goal is to change the laser frequency to lock it to the arms, without affecting the ALS lock.  This is the part where we assume we might be sleepy, and missing out on some obvious reason why this won't work.

3) Once we have CARM doubly locked (ALS pushing on ETMs, REFL11 pushing on MC/laser frequency), we can turn off the ALS system. Once we have the linear REFL11 error signal, we know that we have enough digital gain and bandwidth to hold CARM locked, and we should be able to eek out a slightly higher UGF since there won't be as many digital hops for the error signal to transverse.

4) The next step is to turn on the high bandwidth common mode servo.  If ALS is still on at this point, it will get drowned out by the high gain CM servo, so it will be effectively off.

5) Somewhere in here we need to transition DARM to AS55Q.  Probably that can happen after we've turned on the digital REFL11 path, but it can also probably wait until after the CM board is on.

The potential show-stoppers:

Are we double counting frequency cancellation or something somewhere?  Is it actually possible to change the laser frequency without affecting the ALS system?

Can we hold PRMI lock on 3f even at zero CARM offset?  Anecdotally from a few trials in the last hour or so, it seems like coming in from negative carm offset is more successful - we get to slightly higher arm powers before the PRMI loses lock.  We should check if we think this will work in principle and we're just saturating something somewhere, or if 3f can't hold us to zero carm offset no matter what.

A note on technique:  We should be able to get the transfer function between MC2 actuation and ALS frequency by either a direct measurement, or Wiener filtering.  We need this in order to get the frequency subtraction to work in the correct units.

11000   Wed Feb 11 03:41:12 2015 KojiUpdateLSCPRC error signal RF spectra

As the measurements have been done under feedback control, the lower RF peak height does not necessary mean
the lower optical gain although it may be the case this time.

These non-33MHz signals are embarassingly high!
We also need to check how these non-primary RF signals may cause spourious contributions in the error signals,
including the other PDs.

10999   Wed Feb 11 02:42:05 2015 JenneUpdateLSCPRC error signal RF spectra

Since we're having trouble keeping the PRC locked as we reduce the CARM offset, and we saw that the POP22 power is significantly lower in the 25% MICH offset case than without a MICH offset, Rana suggested having a look at the RF spectra of the REFL33 photodiode, to see what's going on.

The Agilent is hooked up to the RF monitor on the REFL33 demod board.  The REFL33 PD has a notch at 11MHz and another at 55MHz, and a peak at 33MHz.

We took a set of spectra with MICH at 25% offset, and another set with MICH at 15% offset.  Each of these sets has 4 traces, each at a different CARM offset.  Out at high CARM offset, the arm power vs. CARM offset is pretty much independent of MICH offset, so the CARM offsets are roughly the same between the 2 MICH offset plots.

What we see is that for MICH offset of 25%, the REFL33 signal is getting smaller with smaller CARM offset!!  This means, as Rana mentioned earlier this evening, that there's no way we can hold the PRC locked if we reduce the CARM offset any more.

However, for the MICH offset 15% case, the REFL 33 signal is getting bigger, which indicates that we should be able to hold the PRC.  We are still losing PRC lock, but perhaps it's back to mundane things like actuator saturation, etc.

The moral of the story is that the 3f locking seems to not be as good with large MICH offsets.  We need a quick Mist simulation to reproduce the plots below, to make sure this all jives with what we expect from simulation.

For the plots, the blue trace has the true frequency, and each successive trace is offset in frequency by a factor of 1MHz from the last, just so that it's easier to see the individual peak heights.

Here is the plot with MICH at 25% offset:

And here is the plot with MICH at 15% offset:

Note that the analyzer was in "spectrum" mode, so the peak heights are the true rms values.  These spectra are from the monitor point, which is 1/10th the value that is actually used.  So, these peak heights (mVrms level) times 10 is what we're sending into the mixer.  These are pretty reasonable levels, and it's likely that we aren't saturating things in the PD head with these levels.

The peaks at 100MHz, 130MHz and 170MHz that do not change height with CARM offset or MICH offset, we assume are some electronics noise, and not a true optical signal.

Also, a note to Q, the new netgpib scripts didn't write data in a format that was back-compatible with the old netgpib stuff, so Rana reverted a bunch of things in that directory back to the most recent version that was working with his plotting scripts.  sorry.

Attachment 1: REFL33_25.pdf
Attachment 2: REFL33_15.pdf
10998   Wed Feb 11 00:07:54 2015 ranaUpdateLSCLock Loss plot

Here is a lock loss from around 11 PM tonight. Might be due to poor PRC signals.  $\oint {\frac{\partial PRCL}{\partial x}}$

This is with arm powers of ~6-10. You can see that with such a large MICH offset, POP22 signal has gone done to zero. Perhaps this is why the optical gain for PRCL has also dropped by a factor of 30 .

This seems untenable . We must try this whole thing with less MICH offset so that we can have a reasonable PRCL signal.

Attachment 1: 1107673198.png
10997   Tue Feb 10 18:37:17 2015 ericqUpdateASCQPD ASC ready to go

I've remeasured the QPD ASC sensing coefficients, and figured out what I did weird with the actuation coefficients. I've rearranged the controller filters to be able to turn on the boost in a triggered way, and written Up/Down scripts that I've tested numerous times, and Jenne has used as well; they are exposed on the ASC screen.

All four loops (2 arms * pit,yaw), have their gains set for 8Hz UGF, and have 60 degrees of phase margin. The loop shape is the same as the previous ELOG post. Here is the current on/off performance. The PDH signals (not shown, but in attached xml) show no extra noise, and the low frequency RIN goes down a bit, whic is good. The oplevs error signals are a bit noisier, but I suppose that's unavoidable. The Y-arm performs a bit better than the X-arm.

The up/down scripts don't touch the filters' trigger settings at all, just handles switching the input and output and clearing history. FM1 contains the boost which is intended to have a longer trigger delay than the filters themselves.

Attachment 1: Feb10_loops_offOn.png
Attachment 2: Feb10_newLoops_offOn.xml.zip
10996   Tue Feb 10 16:01:21 2015 manasaUpdateGeneralAUX X fiber coupled 72%

Plan C finally worked. We have 1.454mW of AUX X light at the PSL table (2mW incident on the fiber coupler).

Attached is the layout of the telescope.

What I did:

I stuck in Lens 1 (f=200mm) and measured the beam width after the focus of the lens at several points. I fit the data and calculated the beam waist and its position after this lens.

I used the calculated waist and matched it with an appropriate lens and target (fiber coupler) distance. I calculated the maximum coupling efficiency to be 77% for Lens 2 with f=50mm and the fiber coupler placed at 20cm from the waist of Lens1. I was able to obtain 72% coupling after putting the telescope together.

I locked the arms, ran ASS and brought back GTRX to its usual optimum value of ~0.5 counts after closing. We also have the X arm beatnote on the spectrum analyzer.

Notes:

There are still a couple of things to fix. The rejected beam from the beam sampler has to be dumped using a razor blade.

10995   Tue Feb 10 13:48:58 2015 manasaUpdateLSCProbable cause for headaches last night

I found the PSL enclosure open (about a feet wide) on the north side this morning. I am assuming that whoever did the X beatnote alignment last night forgot to close the door to the enclosure before locking attempts

 Quote: Unfortunately, we only had one good CARM offset reduction to powers of about 25, but then my QPD loop blew it. We spent the vast majority of the night dealing with headaches and annoyances.  Things that were a pain: If TRX is showing large excursions after finding resonance, there is no hope. These translate into large impulses while reducing the CARM offset, which the PRMI has no chance of handling. The first time aligning the green beat did not help this. For some reason, the second time did, though the beatnote amplitude wasn't increased noticibly.  NOTICE: We should re-align the X green beatnote every night, after a solid ASS run, before any serious locking work.  Afterwards, phase tracker UGFs (which depend on beatnote amplitude, and thereby frequency) should be frequently checked.  We suffered some amount from ETMX wandering. Not only for realigning between lock attempts, but on one occasion, with CARM held off, GTRX wandered to half its nominal value, leading to a huge effective DARM offset, which made it impossible to lock MICH with any reasonble power in the arms. Other times, simply turning off POX/POY locking, after setting up the beatnotes, was enough to significantly change the alignment.  IMC was mildly tempermental, at its worst refusing to lock for ~20min. One suspicion I have is that when the PMC PZT is nearing its rail, things go bad. The PZT voltage was above 200 when this was happening, after relocking the PMC to ~150, it seems ok. I thing I've also had this problem at PZT voltages of ~50. Something to look out for.  Other stuff: We are excited for the prospect of the FOL system, as chasing the FSS temperature around is no fun.  UGF servo triggering greatly helps the PRMI reacquire if it briefly flashes out, since the multipliers don't run away. This exacerbated the ALS excursion problem.  Using POPDC whitening made it very tough to hold the PRMI. Maybe because we didn't reset the dark offset...?

10994   Tue Feb 10 03:09:02 2015 ericqUpdateLSCSome locking thoughts on PRMI

Unfortunately, we only had one good CARM offset reduction to powers of about 25, but then my QPD loop blew it. We spent the vast majority of the night dealing with headaches and annoyances.

Things that were a pain:

• If TRX is showing large excursions after finding resonance, there is no hope. These translate into large impulses while reducing the CARM offset, which the PRMI has no chance of handling. The first time aligning the green beat did not help this. For some reason, the second time did, though the beatnote amplitude wasn't increased noticibly.
• NOTICE: We should re-align the X green beatnote every night, after a solid ASS run, before any serious locking work.
• Afterwards, phase tracker UGFs (which depend on beatnote amplitude, and thereby frequency) should be frequently checked.
• We suffered some amount from ETMX wandering. Not only for realigning between lock attempts, but on one occasion, with CARM held off, GTRX wandered to half its nominal value, leading to a huge effective DARM offset, which made it impossible to lock MICH with any reasonble power in the arms. Other times, simply turning off POX/POY locking, after setting up the beatnotes, was enough to significantly change the alignment.
• IMC was mildly tempermental, at its worst refusing to lock for ~20min. One suspicion I have is that when the PMC PZT is nearing its rail, things go bad. The PZT voltage was above 200 when this was happening, after relocking the PMC to ~150, it seems ok. I thing I've also had this problem at PZT voltages of ~50. Something to look out for.

Other stuff:

• We are excited for the prospect of the FOL system, as chasing the FSS temperature around is no fun.
• UGF servo triggering greatly helps the PRMI reacquire if it briefly flashes out, since the multipliers don't run away. This exacerbated the ALS excursion problem.
• Using POPDC whitening made it very tough to hold the PRMI. Maybe because we didn't reset the dark offset...?
10993   Tue Feb 10 02:55:29 2015 JenneConfigurationModern ControlQuacky filters

I discovered that somehow my Wiener filters that show up in Foton are not the same as what I have in Matlab-land.

I have plotted each of my 3 filters that I'm working with right now (T-240 X, Y and Z for PRCL Pitch) at several stages in the filter creation process.  Each plot has:

• Blue trace is the Wiener filter that I want, after the vectfit process.
• Green trace is the frequency response of the SOS filters that are created by autoquack (really, quack_to_rule_them_all, which is called by autoquack).  The only thing that happens in matlab after this is formatting the coefficients into a string for writing to foton.
• Red trace is the exported text file from foton.

It's not just a DC gain issue - there's a frequency dependent difference between these filters.  Why??

It's not frequency warping from changing between analog and digital filters.  The sample rate for the OAF model is 2048Hz, so the effect is small down at low frequencies.  Also, the green trace is already discretized, so if it were freq warping, we'd see it in the green as well as red, which clearly we don't.

Has anyone seen this before?  I'm emailing my seismic friends who deal in quack more than I do (BLantz and JKissel, in particular) to see if they have any thoughts.

Also, while I'm asking questions, can autoquack clear filters?  Right now I'm overwriting old filters with zpk([],[],1)'s, which isn't quite the same.  (I need this because the Wiener code needs more than one filter module to fit all of the poles I need, and it decides for itself how many FMs it needs by comparing the length of the poles vector with 20.  If one iteration needs 4 filter modules, but the next iteration only wants 3, I don't want to leave in a bogus 4th filter.

Here are the plots:

(The giant peak at ~35Hz in the Z-axis fiilter is what tipped me off that something funny was going on)

10992   Tue Feb 10 02:40:54 2015 JenneUpdateLSCSome locking thoughts on PRMI

[EricQ, Jenne]

We wanted to make the PRMI lock more stable tonight, which would hopefully allow us to hold lock much longer.  Some success, but nothing out-of-this-world.

We realized late last week that we haven't been using the whitening for the ASDC and POPDC signals, which are combined to make the MICH error signal.  ASDC whitening is on, and seems great.  POPDC whitening (even if turned on after lock is acquired) seems to make the PRMI lock more fussy.  I need to look at this tomorrow, to see if we're saturating anything when the whitening is engaged for POPDC.

One of the annoying things about losing the PRMI lock (when CARM and DARM have kept ALS lock) is that the UGF servos wander off, so you can't just reacquire the lock.  I have added triggering to the UGF servo input, so that if the cavity is unlocked (really, untriggered), the UGF servo input gets a zero, and so isn't integrating up to infinity.  It might need a brief "wait" in there, since any flashes allow signal through, and those can add up over time if it takes a while for the PRMI to relock.  UGF screens reflect this new change.

10991   Mon Feb 9 17:47:17 2015 diegoUpdateLSCCM servo & AO path status

I wrote the script with the recipe we used, using the Yarm and AS55 on the IN2 of the CM board; however, the steps where the offset should be reduced are not completely deterministic, as we saw that the initial offset (and, therefore, the following ones) could change because of different states we were in. In the script I tried to "servo" the offset using C1:LSC-POY11_I_MON as the reference, but in the comments I wrote the actual values we used during our best test; the main points of the recipe are:

• misalign the Xarm and the recycling mirrors;
• setting up CARM_B for POY11 locking and enabling it;
• setting up CARM_A for CM_SLOW;
• setting up the CM_SLOW filter bank, with only FM1 and FM4 enabled;
• setting up the CARM filter bank: FM1 FM2 FM6 triggered, only FM3 and FM5 on; usual CARM gain = 0.006;
• setting up CARM actuating on MC2;
• turn off the violin filter FM6 for MC2;
• setting up the default configuration for the Common Mode Servo and the Mode Cleaner Servo; along with all the initial parameters, here is where the initial offset is set;
• turn on the CARM output and, then, enable LSC mode;
• wait until usual POY11 lock is acquired and, a bit later, transition from CARM_B to CARM_A;
• then, the actual CM_SLOW recipe:
• CM_AO_GAIN = 6 dB;
• SUS-MC2_LSC FM6 on (the 300:80 filter);
• CM_REFL2_GAIN = 18 dB;
• servo CM_REFL_OFFSET;
• CM_AO_GAIN = 9 dB;
• CM_REFL2_GAIN = 21 dB;
• servo CM_REFL_OFFSET;
• CM_REFL2_GAIN = 24 dB;
• servo CM_REFL_OFFSET;
• CM_REFL2_GAIN = 27 dB;
• servo CM_REFL_OFFSET;
• CM_REFL2_GAIN = 31 dB;
• servo CM_REFL_OFFSET;
• CM_AO_GAIN = 6 dB;
• SUS-MC2_LSC FM7 on (the :300 compensating filter);

I tried the procedure and it seems fine, as it did during the tries Q and I made; however, since it touches many things in many places, one should be careful about which state the IFO is into, before trying it.

The script is in scripts/CM/CM_Servo_OneArm_CARM_ON.py and in the SVN.

10990   Mon Feb 9 17:23:17 2015 diegoUpdateComputer Scripts / ProgramsNew laptops

I forgot to elog about these ones, my bad... The new/updated laptops are giada, viviana and paola; paola is already in the lab, while giada and viviana are in the control room waiting for a new home. The Pool of Names Wiki page has already been updated to reflect the changes.

10989   Mon Feb 9 08:40:49 2015 SteveUpdateSUSrecent earthquake 4.9

Baja 4.9 m earth quake tripped suspentions, except ETMX Sus damping recovered. MC is locking.

Attachment 1: M4.9Baja.png
10988   Sun Feb 8 21:54:50 2015 ranaSummaryPSLISS AOM driver check

This is good news. It means that the driver probably won't limit the response of the loop - I expect we'll get 20-30 deg of phase lag @ 100 kHz just because of the acoustic response of the AOM PZT + crystal.

10987   Sat Feb 7 21:30:45 2015 JenneUpdateLSCPRC aligned

I'm leaving the PRC aligned and locked.  Feel free to unlock it, or do whatever with the IFO.

10986   Sat Feb 7 13:34:11 2015 KojiSummaryPSLISS AOM driver check

I wanted to check the status of the ISS. The AOM driver response was measured on Friday night.
The beam path has not been disturbed yet.

- I found the AOM crystal was removed from the beam path. It was left so.

- The AOM crystal has +24V power supply in stead of specified +28V.
I wanted to check the functionality of the AOM driver.

- I've inserted a 20dB directional coupler between the driver and the crystal.
To do so, I first turned off the power supply by removing the corresponding fuse block at the side panel of the 1X1 Rack.
Then ZFDC-20-5-S+ was inserted, the coupled output was connected to a 100MHz oscilloscope with 50Ohm termination.
Then plugged in the fuse block again to energize the driver box.

Note that the oscilloscope bandwidth caused reduction the amplitude by a factor of 0.78. In the result, this has already been compensated.

- First, I checked the applied offset from a signal generator (SG) and the actual voltage at the AOM input. The SG OUT
and the AOM control input are supposed to have an impedance of 50Ohm. However, apparently the voltage seen at the
AOM in was low. It behaved as if the input impedance of the AOM driver is 25Ohm.
In any case, we want to use low output impedance source to drive the AOM driver, but we should keep this in mind.

- The first attachment shows the output RF amplitude as a function of the DC offset. The horizontal axis is the DC voltage AT THE AOM INPUT (not at the SG out).
Above 0.5V offset some non linearity is seen. I wasn't sure if this is related to the lower supply voltage or not. I'd use the nominal DC of 0.5V@AOM.

The output with the input of 1V does not reach the specified output of 2W (33dBm). I didn't touch the RF output adjustment yet. And again the suppy is not +28V but +24V.

- I decided to measure the frequency response at the offset of 0.53V@AOM, this corresponds to the DC offset of 0.8V. 0.3Vpp oscillation was given.
i.e. The SG out seen by a high-Z scope is V_SG(t) = 1.59 + 0.3 Sin(2 pi f t) [V]. The AOM drive voltage V_AOM(t) = 0.53 + 0.099 Sin(2 pi f t).
From the max and min amplitudes observed in the osciiloscope, the response was checked. (Attachment 2)
The plot shows how much is the modulation depth (0~1) when the amplitude of 1Vpk is applied at the AOM input.
The value is ~2 [1/V] at DC. This makes sense as the control amplitude is 0.5, the applied voltage swings from 0V-1V and yields 100% modulation.

At 10MHz the first sign of reduction is seen, then the response starts dropping above 10MHz. The specification says the rise time of the driver is 12nsec.
If the system has a single pole, there is a relationship between the rise time (t_rise) and the cut-off freq (fc) as fc*t_rise = 0.35 (cf Wikipedia "Rise Time").
If we beieve this, the specification of fc is 30MHz. That sounds too high compared to the measurement (fc ~15MHz).
In any case the response is pretty flat up to 3MHz.

Attachment 1: AOM_drive.pdf
Attachment 2: AOM_response.pdf
10985   Fri Feb 6 18:06:18 2015 manasaUpdateGeneralFiber Optic module for FOL

I pulled out the Fiber Optic Module for FOL from the rack inside the PSL table enclosure and modified it. The beat PDs were moved into the box to avoid breaking the fiber pigtail input to the PD.

The box has 3 input FC/APC connectors (PSL and AUX lasers) and 2 output FC/APC connectors (10% of the beatnote for the AUX lasers).

Attachment shows what is inside the box. The box will again go back on the rack inside the PSL enclosure.

Attachment 1: FOLfiberModule.png
10984   Fri Feb 6 15:29:29 2015 ericqUpdateCDSNetwork Shenanigans

Just now we had another EPICS freeze. The network was still up; i.e. I could ssh to chiara and fb, who both seemed to be working fine.

I could ping c1lsc successfully, but ssh just hung. fb's dmesg had some daqd segfault messages, so I telnet'ed to daqd and shut it down. Soon after, EPICS came back, but this is not neccesarily because of the daqd restart...

10983   Fri Feb 6 10:03:23 2015 SteveUpdatePEMdusty days

 Quote: Yesterday morning was dusty. I wonder why? The PRM sus damping was restored this morning.

Yesterday afternoon at 4 the dust count peaked 70,000 counts

Manasa's alergy was bad at the X-end yesterday. What is going on?

There was no wind and CES neighbors did not do anything.

Attachment 1: duststorm.png
10982   Fri Feb 6 03:21:17 2015 diegoUpdateLSCCARM Transition to REFL11 using CM_SLOW Path

[Diego, Jenne]

We kept struggling with the PRMI, although it was a little better than yesterday:

• we retuned the X Green beatnote;
• we managed to reach lower CARM offsets than yesterday night, but we still can't keep lock long enough to perform a smooth transition to CM SLOW/REFL11;
• we tweaked MICH a bit:
• the ELP in FM8 now is always on, because it seems to help;
• we tried using a new FM1 1,1:0,0 instead of FM2 1:0 because we felt we needed a little more gain at low frequencies, but unfortunately this didn't change much MICH's behaviour;
• now, after catching PRMI lock, the MICH limiter is raised to 30k (in the script), as a possible solution for the railing problem; the down/relock scripts take care of resetting it to 10k while not locked/locking;

So, still no exciting news, but PRMI lock seems to be improving a little.

10981   Thu Feb 5 15:21:25 2015 manasaUpdateGeneralX endtable work

[EricG, Manasa]

We were at the X end today trying to couple AUX X light into the fiber.

The proposed plan still did not give a good beampath. The last steering mirror before the fiber coupler was sticking out of the table enclosure. I tried a few other options and the maximum coupling that I could get was ~10%

I am working on plan C now; which would be to use fixed mount mirrors and steer the beam to the space created by Koji near the IR trans path and use a set of lenses instead of a single lens. I will elog more details after some modematching calculations.

We moved one of the clamps for the doubling crystal to make space. Also, the NPRO current was reduced during this work.

I reset things to how they were before I touched the table. I ensured that the green power was still the same (~3mW) after the doubler and that it could lock to the arm in TEM00.

10979   Thu Feb 5 04:35:14 2015 diegoUpdateLSCCARM Transition to REFL11 using CM_SLOW Path

[Diego, Eric]

Tonight was a sad night... We continued to pursue our strategy, but with very poor results:

• before doing anything, we made sure we had a good initial configuration: we renormalized the arm powers, retuned the X arm green beatnote, did extensive ASS alignment;
• since the beginning of the night we faced a very uncooperative PRMI, which caused a huge number of locklosses, often just by itself, without even managing to reduce the MICH offset before reducing the CARM one;
• we had to reduce the PRCL gain to -0.002 in order to acquire PRMI lock, but keeping it such or restoring it to -0.004 once lock was acquired either didn't improve the PRMI stability at all;
• we also tweaked a bit the PRCL and MICH UGF servos (namely, their frequencies to ~80 Hz and ~40 Hz respectively) and that seemed to help earlier during the night, but not much longer;
• we only managed to transition CARM to REFL11 via CM SLOW twice;
• the first time we lost lock almost immediately, probably because of a non-optimal offset between CARM A and B;
• the second time we managed to stay there a little longer, but then some spike in the PRCL loop and/or the MICH loop hitting the rails threw us out of lock (see the lockloss plot);
• both times we transitioned at arm power ~18;
• during the night we used an increased analog ASDC whitening gain, as from Eric's elog here http://nodus.ligo.caltech.edu:8080/40m/10972 ; even with this fix, though, MICH is still often hitting the rails and causing the lock losses;
• the conclusion for tonight is that we need to figure what is going on with the PRMI...

Attachment 1: 4Feb2015_Transition_CARM_REFL11_CM_SLOW_AP_18.png
10978   Wed Feb 4 21:09:43 2015 manasaUpdateGeneralX endtable work scheduled tomorrow

The X end fiber setup will be put together tomorrow morning. Let me know if there are any concerns.

 Quote: It is certain that we have space issues at the X end that has been preventing us from sticking in a lens to couple light into the fiber.  The only way out is to install a platform on the table where we can mount the lens. I have attached the a photo of how things look like at the X end (attachment 1) and also a drawing of the platform that which can hold the lens (attachment 2). Additional support to the raised platform will be added depending on how much space we can clear up on the table by moving the clamping forks of the doubler. Steve and I have been able to gather parts that can be put together into something similar to what is shown in the drawing.  Proposed modifications to the X end table: 1. The side panels of the table enclosure will come out while putting in the new platform. 2. The clamping forks for the doubling crystal will be moved. Let me know of any concerns about the proposed solution.

10977   Wed Feb 4 21:05:24 2015 manasaUpdateGeneralRF amplifier for ALS

The components of the RF amplifier box are in place. The RF amplifier box has been mounted on the IOO rack and the front panel connections have been labeled. Attached is the photo of how things look in the inside for future reference.

Sometime in the next few days the box will be pulled out to replace the panel mount SMA barrels in the front with insulated ones.

Attachment 1: RFampBox.png
10976   Wed Feb 4 19:21:45 2015 JenneUpdatePEMSeismometer Vertex is covered

I opened up the spaghetti pot over the vertex seismometer, and taped the cable to the slab.  The way the cable is coiled, it was touching the underside of the seismometer.  Now the only connection is at the cable connector.  There is a ~few inch bit of cable, then it's taped down.

10975   Wed Feb 4 19:21:37 2015 KojiUpdateASCArm ASS servos now have triggered gain with arm lock status

We had persistent frustration by occasional unlock during ASSing.
Today, I added triggers to the servo gains in order to elliminate this annoyance.

Each ASS servo gain slider is multiplied with the corresponding LSC Trigger EPICS channel (i.e. C1:LSC-iARM_TRIG_MON, where i=X or Y).
This has been done by ezcaread modules in RCG.

The model and screen have been commited to svn.

10974   Wed Feb 4 18:27:55 2015 KojiSummaryASCXarm ASS fix

Please remember that Xarm ASS needs FM6 (Bounce filters) to be ON in order to work properly.

10973   Wed Feb 4 18:16:44 2015 KojiUpdateLSCData transfer rate of c1lsc reduced from ~4MB/s to ~3MB/s

c1lsc had 60 full-rate (16kS/s) channels to record. This yielded the LSC to FB connection to handle 4MB/s (mega-byte) data rate.
This was almost at the data rate limit of the CDS and we had frequent halt of the diagnostic systems (i.e. DTT and/or dataviewer)

Jenne and I reviewed DAQ channel list and decided to remove some channels.  We also reviewed the recording rate of them
and reduced the rate of some channels. c1lsc model was rebuilt, re-installed, and restarted. FB was also restarted. These are running as they were.
The data rate is now reduyced to ~3MB nominal.

The following is the list of the channels removed from the DQ channels:

AS11_I_ERR AS11_Q_ERR AS165_I_ERR AS165_Q_ERR POP55_I_ERR POP55_Q_ERR

The following is the list of the channels with the new recording rate:

TRX_SQRTINV_OUT 2048 TRY_SQRTINV_OUT 2048 DARM_A_ERR 2048 DARM_B_ERR 2048 MICH_A_ERR 2048 MICH_B_ERR 2048 PRCL_A_ERR 2048 PRCL_B_ERR 2048 CARM_A_ERR 2048 CARM_B_ERR 2048

10972   Wed Feb 4 14:30:05 2015 ericqUpdateLSCASDC Whitening Gain

At the lunch meeting, we were thinking about the exess high frequency content of the MICH control signal, which leads to railing against the FM output limiter and lock loss. I propsed that POPDC sensor/ADC noise was the culprit.

In short, I was wrong. Just now, I locked the PRMI with a MICH offset as we normally do, and then froze the POPDC output. The MICH spectrum did not change in any noticible way.

However, increasing the analog ASDC whitening gain showed a direct improvement of the error signal noise floor, and thus a reduction in the control signal spectrum. I.e. we have been suffereing from ASDC ADC noise.

We had previously set the ASDC whitening gain so that half fringe of the PRMI would be well within the ADC range, but since we're actually only ever going to 25%, I feel fine upping this gain. Interestingly, when increasing the whitening gain by 12dB,  the control signal spectrum has fallen by more like 20 dB in the 400Hz-1kHz region, which is great.

The only potential hurdle I can think of is that when we start reducing the MICH offset at zero CARM offset, we may approach ADC saturation in ASDC before we can hand off to RF signals, in which case we would have to dynamically lower the whitening gain, which introduces offsets, which could get hairy. But, since MICH railing has been directly seen to lead to lock-loss, I'd rather solve that problem first.

10971   Wed Feb 4 04:51:14 2015 diegoUpdateLSCCARM Transition to REFL11 using CM_SLOW Path

[Diego, Jenne, Eric]

Tonight we kept on following our current strategy for locking the PRFPMI:

• the first few tries were pretty unsuccessful: the PRMI lock wasn't much stable, and we never managed to reduce CARM offset to zero before losing lock;
• then we did some usual manteinance: we fixed the X arm green beatnote, fixed the phase tracker and given much attention to ASS alignment, since the X arm wasn't doing great;
• the last few locks were consintently better: we managed to get to CARM offset zero "easily", but the arm power was not very high (~8);
• then we tried to transition CARM to REFL11, both with the usual configuration and using CM_SLOW, using REFL11 as input for the Common Mode Board;
• with the usual configuration, we lost lock right after the transition, because of MICH hitting the rail;
• we did a very smooth CARM transition directly to REFL11 on the CM_SLOW path; we managed to take a spectrum with the SR785, but we couldn't take any more measurements before losing lock because of some weird glitch, as we can see from the lockloss plot;
• another thing that helped tonight was changing the ELP of the MICH filter bank: it went from 4th order to 6th order, and from 40 dB suppression to 60 dB suppression;

both of the last two locks, the most stable ones (one transition to usual REFL11 and one transition to "CM_SLOW" REFL11) were acquired actuating on MC2;

EDITs by JCD:  At least one of the times that we lost PRMI lock (although kept CARM and DARM lock on ALS), was due to MICH hitting the rail, even after we increased the limiter to 15,000 counts.

Here is the transfer function between CARM ALS (CARM_IN1) and REFL11 coming through the CM board (CARM_B), just before we transitioned over.  Coherence was taken simultaneously as usual, I just printed it to another sheet.

CARM_3Feb2015_CarmBwasCMslow_CarmAwasLiveALS.pdf

CARM_3Feb2015_CarmBwasCMslow_CarmAwasLiveALS_Coh.pdf

Here is the lockloss plot for the very last lockloss.  This is the time that we were sitting on REFL11 coming through the CM_SLOW path.  A DTT transfer function measurement was in progress (you can see the sine wave in the CARM input and output data), but I think we actually lost lock due to whatever this glitch was near the right side of the plots.  This isn't something that I've seen in our lockloss plots before.  I'm not sure if it's coming from REFL11, or the CM board, or something else.  We know that the CM board gives glitches when we are changing gain settings, but that was not happening at this time.

Q: Here's the SR785 TF of CARM locked through CM board, but still only digital control; nothing exciting. Excitation amplitude was only 1mV, which explains the noisy profile.

Attachment 1: CARM_3Feb2015_CarmBwasCMslow_CarmAwasLiveALS.pdf
Attachment 2: CARM_3Feb2015_CarmBwasCMslow_CarmAwasLiveALS_Coh.pdf
Attachment 3: Glitch_in_CARM_and_PRCL_3Feb2015.png
Attachment 4: slowCM_04-02-2015_042805.png
10970   Tue Feb 3 16:43:48 2015 manasaUpdateGeneralRF amplifier for ALS

I pulled out the RF amplifier box from the IOO rack again and added the new RF amplifiers for FOL.

I replaced one of the decoupling capacitors of the ALS beat note RF amplifier ; the poloproylene capacitor with a ceramic capacitor (0.1uF) .

After putting back the box, I confirmed that we had a beat note. I did not get a chance to measure the ALS noise after putting back the box because the IFO was already occupied.

I will post a detailed elog of the components in the RF amplifier box once I am done with it (hopefully tomorrow)!

10969   Tue Feb 3 16:36:33 2015 ericqUpdateLSCCM servo & AO path status

I have removed REFLDC and the SR560 offsetter from the CM board IN2. Now, analog AS55 I lives there, for our single arm testing. (Analog I has more of the single arm Y PDH signal in it). REFL11 has been reconnected to IN1.

With ITMX super misaligned, Diego and I locked the Y-arm with the AO path on AS55, ultimately at 4kHz bandwidth, but with plenty of gain margin. We didn't allocate the gains too intelligently, and had the CM board input gain slider maxed out, but plenty of headroom in the digital and AO sliders, making it inconvenient to up the UGF even more, to engage the super boosts. However, since this is just a test case to make sure we still can AO lock, I'm not too worried about this.

Since LSC FMs and such had changed around, old recipies didn't neccesarily work 1:1. Diego is writing a script for the current recipe, and will post an elog with the steps.

Gains and signs are able to be tracked by loop TFs, the real sticking point is a stable crossover. We used the 1.6k:80 hardware filter in the CM board to give the AO Path a 1/f shape in the crossover region, and undid it digitally in the CM_SLOW input FM. However, we do use a 300:80 in the MC2 sus FM to make the digital loop like 1/f^2 around the crossover, once a little bit of AO has come in to pull up the digital loop's phase. We used the CARM filter bank to do this, so I think we should be able to use a similar technique to do it in the PRFPMI case, as long as the coupled cavity pole is around ~100Hz.

Attached are a few OLTFs from the progression.

Attachment 1: yarmAO.pdf
10968   Tue Feb 3 15:20:13 2015 Steve, KojiUpdateVACPneumatic pressure is being read again

[Koji, Steve]

Summary

The N2 pressure reading (C1:VAC-N2PRES) is now up-to-date after rebooting c1vac1.
The vaccum system is "Vacuum normal". We now have a space pressure transducer.

Introduction

Our vacuum valves are manipulated with 60~75 PSI of nitrogen. All the valves are configured to be closed in the case of low N2 supply pressure.
In order to avoid this safety shutdown accidentally triggered, we have two N2 cylinders to sustain the vacuum valves. When one cylinder goes to low
the mechanical valve switches over to the other cylinder.

We have the monitor channel for this (combined) cylinder pressure. One shoulbe be able to see periodical pressure variation when the auto cylinder
switch is operating. However, the nirogen pressure reading got stuck at 66 PSI on Dec.16, 2014 (See attached 60-day plot of N2 supply pressure).

What we did

This morning we tracked down the cause of the trouble. We first closed the valves on EPICS and started to vary the N2 pressure.

Our first guess was the pressure transducer (Omega #236PC100GW) that was already 15 yrs old. We even has a sensor spare for replacement.
But it turned out that the direct voltage reading (to be 1mV/PSI) is changing correctly. The second guess was Omega Controller-Monitor
#DPiS32-C24 that is reading the voltage from the tranceducer. The display on this small black unit was changing corresponding to the
pressure change.

So our thought was
1) RS232C of the monitor unit is not working correctly
or
2) c1vac1 is not communicating with the monitor unit.

We wondered what could cause c1vac1 not communicating with the monitor unit, but we were afraid that some function got stuck
during either the nodus upgrade or chiara rebooting (or something else). So we decided to reboot c1vac1

In order to avoid any glitch in the main vacuum pressure, Steve disconnected some of the controller connectors for the closed valves.
We did this treatment before and it was successful.

Then c1vac1 was rebooted just by telnet and type reboot in the terminal.
Once the target is back in action, we noticed that the monitor value started to move.

Steve reverted the cables to the valves and operated the valves to recover "Vacuum Normal" state. Everything is now nicely settled.

10967   Tue Feb 3 04:07:49 2015 JenneUpdateModern ControlMeasured PRM -> POP QPD TFs

Today (after centering the POP QPD), I measured the PRM to POP QPD transfer functions.  I am suspicious that this was part of my problem last week.  Since most of the angular noise is coming from the folding mirrors, but I can't actuate on them, I need to know (rather, the Wiener calculator needs to know) how actuating on the PRM will affect the spot at the POP QPD.

For the plots below, I have cut out any data points that have coherence less than 0.95. I may want to go back and fill in a little bit some of the areas (particularly around 3Hz) that I had trouble getting coherence in.

Using these to prefilter my witness data, I am failing to calculate a Wiener filter.  I have tried the Levinson algorithm, as well as brute-forcing it, but I'm too close to singular for either to work.  I am able to calculate a set of Wiener filters without the prefiltering, or with a dummy very simple prefilter, so it's not inherently in the calculators.  Separately, I can plot my vectfit-ed actuator TFs, and I can convert them to a discrete fiilter with the bilinear transform, and then use sosfilt to filter some white noise data, which comes out with the shape I expect.  So.  It's not inherently the filters either.  More work to do, when it's not 4am.

Here are the measured actuator transfer functions.  They were measured as usual with DTT, but since the measurement kept getting interrupted (MC unlock, or I wanted to add more integrations or more cycles), these are several different DTT files stitched together.  In both cases I am acuating PRM's ASC[pit, yaw] EXC point, and looking at the POP QPD.

Attachment 1: PIT_measured_TF.png
Attachment 2: YAW_measured_TF.png
10966   Tue Feb 3 04:01:55 2015 diegoUpdateLSCCM servo & AO path status

[Diego, Jenne]

Tonight we worked on the CM board and AO path:

• at first we changed the REFL1 input to the CM board from REFL11 to AS55, as written in my previous elog; we tried following Koji's procedures from http://nodus.ligo.caltech.edu:8080/40m/9500 but we didn't get any result: we could lock using the regular digital path but no luck at all for the analog path;
• then we decided to follow the procedure to the letter, using POY11Q as input to the CM board;
• we still couldn't lock following the Path #2, even after adjusting the gains to match the current configuration for the Yarm filter bank;
• we had some more success using Path #1, but we had to lower the REFL1 Gain to ~3-4 (from the original 31) because of the different configuration of the Yarm filter bank, in order to have the same sensing in both of them; we managed to acquire lock a few times, it's not super stable but it can keep lock for a while;
• when we tried to increase the gain of the MC filter bank and the AO Gain, however, we immediately had some gain peaking, and we couldn't go further then 0.15 and 9db respectively. We currently don't have an answer for that.
• anyhow, we took a few measurements with the SR785:

The BLUE plot is at MC Gain = 0.10 and REFL1 Gain = 4dB; the GREEN plot is for MC Gain = 0.10 and REFL1 Gain = 3dB, which seemed a more stable configuration; after this last configuration, we increased the MC Gain to 0.15 and the AO Gain from 8dB to 9dB and took another measurement, the RED plot; this is as far as we got as of now. We also couldn't increase the REFL11 Gain because it made things unstable and more prone to unlock.

So, some little progress on the AO path procedure, but we are very low on our UGF and we have to find a way to increase our gains without breaking the lock and avoiding the gain peaking we have witnessed tonight.

Notes:

• is the REFL1 Gain dB slider supposed to go to negative dBs? During the night we also tried to use negative dBs, but it seemed it wasn't doing anything instead;
• when we plugged POY11Q to the CM board, we noticed that it wasn't connected to anything at the moment; since we phase rotate POY11, we were assuming that we were using that signal somewhere. We are confused by this...
• we remind that REFL11 is no more connected to the CM board input, as POY11 is.
Attachment 1: CARM_03-02-2015_031754.pdf
10965   Mon Feb 2 22:59:49 2015 diegoUpdateLSCCM board input switched to AS55

[Diego, Jenne]

We just changed the input to the CM board from REFL11 to AS55.

10964   Mon Feb 2 16:58:56 2015 manasaUpdateGeneralRF amplifier for ALS

Today I was around the IOO rack.

I shutdown the power to the beat PDs on the PSL table and disconnected the D sub 3w3 connector that was powering the RF amplifier panel on the IOO rack.

I moved the RF amplifier from the panel to a box that can go on the rack. The box will also hold the RF amplifiers that will be used for FOL. I have not completed putting in all the amplifiers. But the RF amplifier for ALS is in place and the box has been installed on the IOO rack for locking tonight. The power supply to the green beat PDs has been switched ON.

I took the out of loop noise measurements for ALS X and Y and the attachment is the screenshot of it (X and Y have rms of ~300Hz and ~400Hz).

I had to touch the Y end steering mirrors for green to get maximum GTRY before making thes measurments.

Attachment 1: ALSXY_outLoop.png
10963   Mon Feb 2 12:24:27 2015 JenneUpdateASCPOP QPD centered

After aligning the PRC, I centered the POP QPD.

10962   Sat Jan 31 01:34:12 2015 JenneUpdateLSCNot able to engage AO path

Nothing earth-shattering today.

A few things of note:

• I checked the coherence (no lock present, just noise) between REFL11_I_IN1 and CM_SLOW_OUT, which are meant to be the same thing when only the REFL1 path is allowed through the CM board.
• However, at first, there was very little coherence - small band, and only about 0.7 or so.
• I went inside and jiggled the cables, and also toggled the whitening switches for REFL11 and the CM_SLOW, and after that I had excellent coherence.
• I didn't take a coherence spectrum in between those activities, but since the cable connections were all solid, I believe that it may have been a sticky slider -esque problem, and the CM whitening wasn't matched between the analog and digital.
• I tried two or three times to engage the AO path, but I always lost lock before I was getting any meaningful gain through.
• I took some TFs remotely with the SR785, but they're totally noise.  I don't even know which sign of the CM board is correct, so no real knkowledge added there, from today.
• The ~400Hz ringing that we have been seeing, we have been blaming on the PRCL loop.  However, just before my last lockloss I saw gain peaking around 400Hz in the CARM input spectrum. I didn't see if it was also there in the PRCL spectrum.  So, either it is coupling from PRCL to CARM, or CARM itself.  But I think we need to see if we can eek out a little more phase at higher frequencies for both of those loops.  I  just looked, and about 16 seconds before the last lockloss, I see the PRCL loop coupling into the CARM loop.
• Since yesterday, we have been lowering the PRCL UGF using the servos to be about 70Hz, to give us more gain margin at the high end of the phase bubble, but we still see this ringing.
• Two or three times my arm power buildup at 0 CARM offset, 25% MICH offset was at 20 or 21.  Then, a few other times I was only getting about 10 (which is what we have been seeing the last few days.)
• I'm running the ASS between each lock, although I'm not running it for a full ~2 minutes or so usually.
• I think that the reason I was able to get to such high arm powers was excellent alignment, so maybe it's worth sitting and waiting for the ASS to have a full 2 or 3 minutes between locks, even if the ASS error signals look zero-ed out.
• This is still a factor of 2 lower than we expect for 25% MICH offset, but the whole factor of 5 isn't explained by some mysterious loss.  At least half of it is alignment.
• The PRCL ASC feedforward still isn't working, but I'd like to try Q's trans qpd ASC soon, with the full lock.  I think the system is ready, but scripts are not, so Q has to be here to run it.

See first plot below for the PRCL->CARM coupling just before lockloss.  The second plot is the corresponding lockloss, where the PRCL loop is starting to see that oscillation again, and it's just barely starting to get into CARM.

10961   Fri Jan 30 11:37:20 2015 manasaFrogsTreasureSP table madness ends

SP table has been a mess because Q and I had let our SURF leave without cleaning up.

I cleaned up the SP table, put things back where they belong and did some sorting. I will put back the optomechanics where they belong sometime later.

For now, check out the SP table next time you are looking for a Y1  or lens or BS.

10960   Fri Jan 30 03:12:15 2015 diegoUpdateLSCCARM on REFL11I

[Jenne, Diego]

Tonight we continued following the plan of last night: perform the transition of CARM to REFL11_I while on MICH offset at -25%:

• we managed to do the transition several times, keeping the UGF servos on for MICH and PRCL but turning off the DARM and CARM ones, because their contribution was rather unimportant and we feared that their excitations could affect negatively the other loops (as loops tend to see each other's excitation lines);
• we had to tweak the MICH and PRCL UGF servos:
• the excitation frequency for MICH was lowered to ~41 Hz, while PRCL's one was lowered to ~50 Hz;
• PRCL's amplitude was lowered to 75 because it was probably too high and it affected the CARM loop, while MICH's one was increased to 300 because during the reduction of the CARM offset it was sinking into the noise; after a few tries we can say they don't need to be tweaked on the fly during the procedure but can be kept fixed from the beginning;
• after the transition to REFL11_I for CARM, we engaged also its UGF servo, still at the highest frequency of the lot (~115 Hz) and with relatively low amplitude (2), to help keeping the loop stable;
• as DARM was still on ALS, we didn't engage its UGF servo during or after the transition, but we just hold its output from the initial part of the locking sequence (after we lowered its frequency to 100 Hz;
• however, at CARM offset 0 our arm power was less that what we had yesterday: we managed to get higher than ~8, but after Koji tweaked the MC alignment we reached ~10; we still don't understand the reason of the big difference with respect to what the simulations show for MICH offset at 25% (arm power ~50);
• after the CARM transition to REFL11_I we felt things were pretty stable, so we tried to reduce the MICH offset to get us in the ~ -10% range, however we never managed to get past ~ -15% before losing lock, at arm power around 20;
• we lost lock several times, but for several different reasons (IMC lost lock a couple of times, PRCL noise increased/showed some ringing, MICH railed) but our main concern is with the PRCL loop:
• we took several measurements of the PRCL loop: the first one seemed pretty good, and it had a bigger phase bubble than usual; however, the subsequent measurements showed some weird shapes we struggle to find a reason for; these measurements were taken at different UGF frequencies, so maybe it is worth looking for some kind of correlation; morever, in the two weird measurements the UGFs are not where they are supposed to be, even if the servo was correctly following the input (or so it seemed); the last measurement was interrupted just before we lost lock because of PRCL itself;
• we noticed a few times during the night that the PRCL loop noise in the 300-500 Hz range increased suddenly and we saw some ringing; at least a couple of times it was PRCL who threw us out of lock; this frequency range is similar to the 'weird' range we found in our measurements, so we definitely need to keep an eye on PRCL on those frequencies;
• in conclusion, the farthest we got tonight was CARM on REFL11_I at 0 offset, DARM at 0 offset still on ALS and MICH at ~ 15% offset, arm power ~20.

Attachment 1: PRCL_29Jan2015_Weird_Shape.pdf
Attachment 2: ArmPowers20_MICHoffsetBeingReduced_0CARMoffset_29Jan2015.pdf
10959   Fri Jan 30 02:57:03 2015 JenneUpdateModern ControlFirst try with PRCL ASC Wiener filtering

[Aside - How do you rotate plots in the new elog?  It's showing them correctly in the attachments list below the entry, but not in the body of the log :( ]

I tried a round of PRCL ASC Wiener filtering today, but something wasn't right.  I was able to either make the cavity motion worse, or completely throw the cavity out of lock.  Making it less noisy didn't happen.

I took only 9 minutes of data the other day, since the PRMI didn't want to stay locked while it was daytime.  So, this wasn't a whole lot to train on.  But, even so, I designed some Wiener filters.  The plots with the designs show the calculated Wiener filter ("Wiener") and the result from vectfit ("Fit"). Below the bode plot is the coherence between that witness (seismometer direction) and the degree of freedom (QPD channel).  The fits were weighted by the choherence, so you can see that in the areas where the coherence was good, the fit was good.  Elsewhere, it's not so great.

Using these filters, and assuming a Cheby1 2nd order lowpass filter at 30Hz, I predicted the following residuals:

After discovering that these filters didn't work, I went rogue and also put in a high pass filter at 0.1 Hz, but that didn't really change anything.

Here is a plot of what happened in Yaw.  The Wiener filters' gains were all 0.3 here, which made the cavity motion larger, but not so large that it lost lock.  The filters ought to have gains of 1 - the Wiener calculation should figure out the gains appropriately, if I've given it enough information.  Here, as in the prediction plots above, red is the reference with the Wiener off, and black is with the Wiener filters on.  Black is supposed to be below red, if the filters are working.  Blue is the estimate of the angular motion that is being fed forward to the PRM, and you can see that at least the general shape is correct.  I do need to figure out what the resonance in the blue trace is from - it's at the same frequency as a peak in the T-240's spectrum (that I didn't save).  I suspect the cable might be touching the spaghetti pot on the inside, and making a mechanical short to pot vibrations.

Anyhow, more work to be done.  I left the PRMI locked for a while this afternoon, starting at 5:15ish, so I'll see tomorrow how long of a lock stretch I was able to capture for training.

Attachment 1: WienerFilter_Witness1.png
Attachment 3: WienerFilter_Witness3.png
Attachment 9: 29Jan2015_Yaw_didnotwork.pdf
10958   Thu Jan 29 17:20:58 2015 manasaConfigurationIOOX Trans Table less crazy but not enough yet

[Koji, Manasa]

We cleared up some optics and optomechanics at the X end table that are not being used and moved them to the SP table. [Ed by KA: They seemed to be leftover of the other projects. I blame them]

10957   Thu Jan 29 16:14:10 2015 manasaUpdateGeneralUpdated to do list for FOL

Since there will be some work that supposedly will involve moving stuff on the table and racks; here is the updated to-do list for FOL.

10956   Thu Jan 29 11:59:48 2015 manasaUpdateGeneralBeat note frequency discrepancy

Below is the set of plots comparing measurements for the green and IR beat notes frequencies. The measurements were made on the spectrum analyzer at the same time. So I have not taken measurement error into account.
From the plots, the discrepancy is not very large.

Attachment 1:
Shows the two sets of measurements scaterred along y=x.

Attachment 2:
Since plot 1 shows the points tightly scattered to y=x, I plotted the difference between the two measurements against their mean to blow out the deviations.

I will do the same comparison using the frequency counter readout once we have RF amplifiers installed.

Attachment 1: Freq_compare1.png
Attachment 2: Freq_compare2.png
10955   Thu Jan 29 10:14:21 2015 manasaUpdateGeneralX end space issues

It is certain that we have space issues at the X end that has been preventing us from sticking in a lens to couple light into the fiber.

The only way out is to install a platform on the table where we can mount the lens. I have attached the a photo of how things look like at the X end (attachment 1) and also a drawing of the platform that which can hold the lens (attachment 2). Additional support to the raised platform will be added depending on how much space we can clear up on the table by moving the clamping forks of the doubler.
Steve and I have been able to gather parts that can be put together into something similar to what is shown in the drawing.

Proposed modifications to the X end table:

1. The side panels of the table enclosure will come out while putting in the new platform.

2. The clamping forks for the doubling crystal will be moved.

Let me know of any concerns about the proposed solution.

Attachment 1: photo.png
Attachment 2: drawing.png
10954   Thu Jan 29 09:50:47 2015 manasaUpdateElectronicsIOO rack amplifier panel

The RF amplifier panel on the IOO rack (Attachment 1) will be used to also hold the RF amplfiers for the frequency counters. The amplifiers mounted on it right now are getting +15 (orange wire) and GND (black wire) from the rack power supply (Attachment 2).

Proposed plan to install RF amplifiers:

1. Disconnect the D sub connector that powers the amplifiers and pull out the panel. The rack power supplies will NOT be shut down for this.

2. Mount the RF amplifiers with bypass capacitors. There will be 4 amplifiers ZFL-500LN mounted on the same panel (2 for each frequency counter).

3. While putting back the panel on the IOO rack, we will need to shut down the +15V and -15V sources to connect the amplifiers to the rack power supply.

I will do this over this weekend so that we dont lose any locking time. If anybody has any concerns, let me know

Attachment 1: panel_front.jpg
Attachment 2: panel_back.jpg
10953   Thu Jan 29 04:27:35 2015 ericqUpdateLSCCARM on REFL11

[ericq, Diego]

Tonight, we transitioned CARM from ALS directly to REFL11 I at 25% Mich Offset.

We attempted the transition twice, the first time worked, but we lost lock ~5 seconds after full transition due to a sudden ~400Hz ringup (see attached lockloss plot). The second barfed halfway, I think because I forgot to remove the CARM B offset from the first time

The key to getting to zero CARM offset with CARM and DARM on ALS is ekeing out every bit of PRMI phase margin that you can. Neither MICH nor PRCL had their RG filters on and I tweaked the MICH LP to attenuate less and give back more phase (the HF still isn't the dominant RMS source.) PRCL had ~60 degrees phase margin at 100Hz UGF, MICH had ~50 deg at 47Hz UGF. The error signals were comparitively very noisy, but we only cared that they held on. Also important was approaching zero slooooooooowly, and having the CARM and DARM UGF servo excitations off, because they made everything go nuts. Diego stewarded the MICH and PRCL excitation amplitudes admirably.

Oddly, and worringly, the arm powers at zero CARM offset were only around 10-12. Our previous estimations already include the high Xarm loss, so I'm not sure what's going on with this. Maybe we need to measure our recycling gain?

I hooked up the SR785 by the LSC rack to the CM board after the first success. For the second trial, I also took TFs with respect to CM slow, but they looked nowhere near as clean as the normal REFL11 I channel; I didn't really check all the connections. I will be revisiting the whole AO situation soon.

In any case, I think we're getting close...

Attachment 1: Jan29_REFL11_lockloss.png
10952   Wed Jan 28 23:53:24 2015 KojiSummaryASCXarm ASS fix

X-Arm ASS was fixed.
ASS_DITHER_ON.snap was updated so that the new setting can be loaded from the ASS screen.

The input and output matrices and the servo gains were adjusted as found in the attached image.
The output matrix was adjusted by looking at the static response of the error signals when a DC offset
was applied to each actuator.

The servo was tested with misalignment of the ITM, ETM, and BS. In fact, the servo restored transmission
from 0.15 to 1.

The resulting contrast after ASSing was ~99% level. (I forgot to record the measurement but the dark fringe level of ASDC was 4~5count.)

Attachment 1: 12.png
ELOG V3.1.3-