40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 70 of 335  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  10017   Mon Jun 9 23:08:58 2014 JenneUpdateIOOMC board checkout

Rana mentioned this in his elog entry re: SLOW computer recovery, but I want to highlight it:

We cannot yet lock the mode cleaner.

It seems that we need to be aware of the sticky slider issue that we have seen for years (although don't deal with too often) that a burt restore will make it seem like an EPICS channel is at some value, but in fact it is at some other value.  For any sliders or buttons in question, change the value by some amount, and then change it back.  This forces things to refresh, and it'll then be at the value that is reported.

However, for the MC board, this seems to not be enough.  Changing the offset slider doesn't seem to actually change the offset value.  The fast output of the MC board is railed at 9.996 V.  So.  We need to check out the MC servo board and ensure that we are actually connected and talking to it through the c1iool0 (C1i-oh-oh-L-zero, to make the characters more clear) slow machine.

  10025   Wed Jun 11 14:36:57 2014 JenneUpdateCDSSLOW controls recovery


 I have brought back c1auxex and c1auxey.  Hopefully this elog will have some more details to add to Rana's elog 10015, so that in the end, we have the whole process documented.

The old Dell computer was already in a Minicom session, so I didn't have to start that up - hopefully it's just as easy as opening the program.  (Edit, JCD, 9July2014:  Startup a terminal session, and then type "minicom" and press enter to get a Minicom session).

I plugged the DB9-RJ45 cable into the top of the RJ45 jacks on the computers.  Since the aux end station computers hadn't had their bootChanges done yet, the prompt was "VxWorks Boot".  For a computer that was already configured, for example the psl machine, the prompt was "c1psl", the name of the machine.  So, the indication that work needs to be done is either you get the Boot prompt, or the computer starts to hang while it's trying to load the operating system (since it's not where the computer expects it to be).  If the computer is hanging, key the crate again to power cycle it.  When it gets to the countdown that says "press any key to enter manual boot" or something like that, push some key.  This will get you to the "VxWorks Boot" prompt. 

Once you have this prompt, press "?" to get the boot help menu.  Press "p" to print the current boot parameters (the same list of things that you see with the bootChange command when you telnet in).  Press "c" to go line-by-line through the parameters with the option to change parameters.  I discovered that you can just type what you want the parameter to be next to the old value, and that will change the value.  (ex.  "host name   : linux1   chiara"   will change the host name from the old value of linux1 to the new value that you just typed of chiara). 

After changing the appropriate parameters (as with all the other slow computers, just the [host name] and the [host inet] parameters needed changing), key the crate one more time and let it boot.  It should boot successfully, and when it has finished and given you the name for the prompt (ex. c1auxex), you can just pull out the RJ45 end of the cable from the computer, and move on to the next one.


  10026   Wed Jun 11 14:41:11 2014 JenneUpdateSUSBurt restored c1scxepics

ETMX had default 1's for gains, 0's for matrix elements, etc., so I did a burt restore to May 25th, 2pm, which was a few days before the Crash.  It looks fine now.

  10027   Wed Jun 11 15:57:18 2014 JenneUpdateCDSNote on cables for talking to slow computers

We have (now) in the lab 2 cables that are RJ45-DB9.  The gray one is LIGO-made, while the blue one is store-bought.  

The gray LIGO-made one works, but the blue store-bought one does not.  I checked their pinouts, and they are completely different.  On the sketch below, the pictures of the connectors is me looking at them face-on, with the cables going out the back of the page.  The DB9 is female. 


  10045   Mon Jun 16 21:22:16 2014 JenneUpdateComputer Scripts / ProgramsRossa having a bad day

[Jenne, Rana]

Today, Rossa has been hanging at bootup.  You get the desktop, and most of the gui things, and can move the mouse pointer around, but clicking the mouse or using the keyboard have no effect.  Once you try clicking something, the mouse pointer turns into the spinning ball, and stays like that.

If, upon rebooting (soft rebooting from another machine, through an ssh session), you hold down the Shift key, you should get to a Grub menu.  If you arrow-key down and select the next-most-recent version (not the recovery mode, but just the regular earlier version), and press Enter, Rossa starts up nice and happily.

I am not sure how to make Rossa always boot into this version of things, or how to get rid of the newest version so that the version that works is the most recent, but I'm hoping one of my Linux buddies will help me out on this one.  I think (maybe) that I need to find out what package was recently updated and could have caused problems, and then revert that one package.  (I think I can look at tail /var/log/apt/history.log to tell me what has recently been updated).

  10046   Mon Jun 16 21:56:53 2014 JenneUpdateComputer Scripts / Programsfstab updates, MC autolocker running, FSS slow loop alive

[Rana, Jenne]

Mc autolocker:

MC autolocker is running.  The trouble was with caput and caget and cavput on Pianosa.  Rana has switched those lines in mcup and mcdown over to ezcaread and ezcawrites, and that seems to have fixed things. For the MC2tickleON and -OFF scripts, we left the caput and caget and cavput, and saw that they do run successfully on Ottavia.  (We tried testing again on Pianosa, and now it seems to be okay with cavput, but we promise it was hanging up on this earlier this evening.)  Anyhow, it's all a bit confusing, but it seems to be running fine now.

The autolocker is now running on Ottavia, and Rana is putting it into Ottavia's cronjob list, and commented it out on op340m.


fstab changes:

We have removed the option "all_squash" from /etc/exports on Chiara (both lines).  We then checked that the files have ownership "controls controls" on Chiara, Pianosa and Rossa.  Ottavia still has ownership of "nobody nogroup", so we still need to figure that out. 


FSS slow loop:

We confirmed that the slow loop is running.  Also, since caput and caget seem to take a while, and the real PID integral gain is the value that we set times a sampling rate, the effective gain had changed.  So, Rana compensated by changing C1:PSL-FSS_SLOWKI from 0.03 to 0.1. 


Other thoughts:

Do we have an autoburt saver on another computer, in addition to op340m?  (It's in the op340m crontab list)  We really only want one of these at a time.


  10047   Mon Jun 16 23:15:44 2014 JenneUpdateLSCIFO alignment recovery

I noticed today, and Rana said that he saw Saturday, that the MC refl value when the MC is unlocked is unusually high.  It typically goes to about 4.5 V, but now is going up to 6.5V.  Since the PMC output is the same as usual (max seen has been about 0.82 today), something must have happened between the PMC and the IMC. 

Late last week, EricG and Nichin were looking at things on the AS table.  Was anything touched on the AS table?  Was anything touched on the PSL table?  'Fess up please, so that we can pinpoint what the change was.


Also, this afternoon, I touched up the MC alignment a bit, although it still needs work (I've asked Manasa to look at it tomorrow).  Rana centered the WFS to my MC alignment (this will need to be redone after the MC is truely aligned), and we turned the WFS on.  I also locked both arms individually, and locked MICH and PRMI sideband.  The PRMI wasn't especially stable unless I turned on the POP ASC.  I assume (hope) that this is just because I was doing it during the day, and not because there is something actually different about the PRMI since the computer meltdown.


Rana and I also took some notes on things that need to be done, starting tomorrow (the first line and the yellow line are scribbles):


  10053   Tue Jun 17 21:49:13 2014 JenneUpdateLSCIFO alignment recovery

PRMI locking with REFL33 is fine.  As it was yesterday, it's a little wobbly without the ASC (just PRM oplev), but I don't know that it's any different than it used to be.  It'll hold for long periods of time, so I feel okay about it. 

When the PRMI is locked, you can push the "up" button on the ASC screen, and it'll turn down the PRM oplev gain by a large factor, and engage the ASC.  When you lose lock, press the "down" button to undo these changes.  (Probably the ifoconfig script should include the ASC down script).  These up and down scripts for the ASC are already included in the carm_up script (the ASC up), and the watch scripts which run a down script (including ASC down) for the whole IFO when ALS loses lock.  If the ASC is engaged, I get bored of watching it before the PRMi loses lock on its own, so I think it's okay.  (Let's say that means I've watched it stay locked for at least a few tens of seconds, but it looks like it always has with the ASC - like it'll stay forever).

The only thing that seems different about the PRMI is that I've increased the PRCL gain from -0.02 to -0.04.  This is a value that it was at some weeks ago, and then we turned it down for loop osc reasons, but now it doesn't want to catch lock with the lower value, and if I turn it down after it's locked, it has trouble holding on.  I have included this change into the PRMI sideband configure script.

I haven't tried anything creative like locking with REFL 165.  I also didn't lock with 11 or 55, since 33 just worked.

  10060   Wed Jun 18 17:38:14 2014 JenneUpdateComputer Scripts / Programsautolocker running again

The MC autolocker is once again running on Ottavia, with the nohup command.  

It was hanging for a long time (at least minutes) on the cavput and the caputs in the MC2 tickle on and off scripts.  I claim that there isn't a good reason to not just use ezcawrite, or whatever the latest and greatest fully functioning function is, so I've changed the cavput to a series of ezcawrites, and all of the caputs are also ezcawrites.  Now I don't see any hanging, and the MC locks itself.

This does not solve the scripto_cron issue, so if Ottavia is rebooted, or the autolocker is otherwise killed, it will not start itself up. 

  10063   Wed Jun 18 19:30:28 2014 JenneUpdateComputer Scripts / ProgramsRossa having a better day

I have modified the /etc/default/grub file, so that we're loading up the previous linux kernel version on reboot.  Now Rossa boots up (at least one time so far) without any fancy button-pushing.

(Note, if things go south again, we have to push "shift" starting after the Dell screen is gone.  Holding it down while the Dell screen is still up doesn't seem to make it register that you want the grub menu).

The grub file USED to look like:

GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`

but now it looks like:

GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`

Note that the first line, GRUB_DEFAULT has changed from 0 (first item in grub menu, if you successfully hit shift and get to it) to 2 (the third item in the list).  I think that the GRUB_HIDDEN_TIMEOUT_QUIET=false is supposed to force it to show the countdown time when you can push shift, but I didn't see any difference there.

To edit this file, you must use "sudo [text editor] grub".  I like emacs, so I used "sudo emacs grub".  After an edit, before a reboot, you must run "sudo update-grub".  Then you can reboot (sudo shutdown -r now is what I use), and hopefully it will boot as you directed.

Right now, the 0th (first) entry in the grub menu is "Ubuntu, with Linux 2.6.32-61-generic".  The 2nd (third) entry is "Ubuntu, with Linux 2.6.32-58-generic".  If we install a new kernel version, the 61 version will bump down in the list, and we'll be booting that, which I assume will fail.  We should not update Rossa until we're ready to go to Ubuntu 12, and when we do, we must ensure that the grub file first line reads GRUB_DEFAULT=0.  (As a side note, the 1st (really 2nd) entry in the grub menu is "Ubuntu, with Linux 2.6.32-61-generic (recovery mode)", which we don't want.  The 58 version has a recovery mode as the next line item, since it alternates version-N, version-N recovery mode, version-(N-1), version-(N-1) recovery mode, etc.)

  10068   Thu Jun 19 00:02:48 2014 JenneUpdateLSCPRMI+2 arms recovery

Arms locked in comm and diff with ALS. PRMI locked with REFL33 I&Q while arms off resonance. Having trouble reducing CARM offset, even to get to arm powers of 1.

After Manasa installed the new Xgreen PD, Koji looked at the PSL table alignment with me.  I saw only a very weak beatnote with the X BBPD, even though I could see the beatnote on the Y PD from the leakage of the X beam to the Y PD  (Yend shutter was closed, so just PSL and X greens were on the table).  I had thought that my near-field and far-field alignments were pretty good (actually, I checked them, but didn't feel that I needed to tweak them since Manasa did the alignment this afternoon).  Anyhow, it was just a matter of tweaking up the alignment a bit, and then the X beatnote got up to about -25dBm at a few tens of MHz.  I am starting to question myself if the other BBPD is broken, or if I just not well enough aligned.  Anyhow, the spare is in, we can still have a look at the previous X BBPD, but it may be okay, and it's just me embarrassing myself by not catching an alignment problem.

Anyhow, after the X beat was found, I was able to (on my first try) lock the arms using ALS comm and diff.  (I already had a nice strong Y beatnote, so that didn't need finding, other than temp adjustment of the end laser).  I ran the carm_cm_up.sh script, and it did everything nicely.  I did a quickie check of the phase tracker loop gains, but that should be redone in the morning.

PRMI was a little reluctant to lock, so I played around with the MICH and PRCL gains, but didn't really find any combination that was any better than the usual (+0.8 for MICH, -0.04 for PRCL as I had last night, although I needed to reduce the PRCL gain back to -0.02 to eliminate loop osc). 

After an arm lockloss, I relocked just the PRMI and used awggui to put a line into C1:LSC-PRM_EXC to check the RF PD phasing.  I changed REFL33 from 133.5 to 138.5, and REFL 165 from -142.5 to -152.5.  I didn't think that REFL11 needed changing, and I didn't check REFL55.  I also checked that I could lock PRMI without arms, using both REFL33 and REFL165 - they seemed about the same to me, both stable.  REFL33 has 1's in the input matrix, and I was using 0.07's for REFL165.  The demod phase adjustment didn't really improve PRMI locking while the arms were held off resonance, even if I moved the arms even farther from resonance (usually we do 3nm, I went out to 5nm to see if that helped - it didn't).  I tried REFL165 locking, but that wasn't any good either.  I tried using REFL165 with the arms held off resonance, but that didn't seem to catch at all (at least with REFL33 I was getting short lock blips). 

Anyhow, of the 3 or 4 times that I caught REFL33 PRMI lock and tried to reduce the CARM offset, only one time did I even get to arm powers of about 1 (CARM digital offset of -0.1, with CARM held on sqrt transmission signals), and then it didn't stay for more than a few tens of seconds.  The other few times, it broke lock on the way up to arm powers of 1. 

So, carm_cm_up.sh works pretty well, although perhaps the arm powers of 1 offset reduction needs to be a little slower.  PRMI doesn't catch and hold lock very easily with REFL33, and even less so with REFL165.  It may be useful to try catching lock with REFL11 or 55, and doing a transition over to 3f.  No real progress forward, but we're pretty much recovered.


  10090   Tue Jun 24 01:07:56 2014 JenneUpdateLSCBootfest 2014!

Still no real luck getting the beam back aligned to the IFO.

Koji and I tried a few minutes of wiggling the input pointing tip tilts (TT1 and TT2) around, and then tried doing some thinking.

We note that the beam propagates (modulo a few pickoffs):

IMC -> Faraday -> TT1 -> MMT1 -> MMT2 -> TT2 -> PRM.

Since moving TT1 to the rails does make beam reflections in the BS chamber move (as seen by movement of the general illumination on the PRM face camera), I posit that the beam is getting through the Faraday.  It is certainly getting at least mostly through the Faraday, although since the MC locked so easily, I assume that we didn't have too much movement after the ~2pm Alaskan earthquake & aftershocks, so we're at pretty much the same alignment as usual, in terms of beam pointing coming from the IMC.

The plan is then to see the position of the beam on MMT1, and steer using TT1 to get the beam to roughly the center.  Then, see the beam propagate to MMT2 (if possible) and TT2 (if possible).    From here, we should be able to see the spot on PRM.  We should be able to use TT2 to tweak things up, and get the beam back to about the right place on POP, or REFL, or somewhere farther along.  Hopefully at this point, we'd see some flashes in the Yarm. 

Using a spare Watek camera, I was able to capture a shot of the face of MMT1.  This is when the TTs were restored to their values that were saved last Monday.  I checked, and this is also roughly the center of the actuation range of TT1, for both pitch and yaw.


I am not able to see the face of MMT2, or TT2.  If I leave TT1, and move TT2, I am not able to see any movement of any beam or reflections seen in the PRM face camera.

Koji and I are checking the MC spot positions, but it may be time to leave this for the morning crew.

EDIT:  The MC spots were actually pretty bad, and the WFS were working really hard.  Koji realigned the MC suspensions, and now the MC spots are slightly better, although quite similar, to what Manasa measured last week.  The restored TT values still don't give us any flashes in the arms.

  10094   Tue Jun 24 18:35:53 2014 JenneUpdateLSCStill no beam going to IFO

[Jenne, EricQ, Manasa]

We are still not able to get the beam to go to the interferometer, which is super frustrating. 

We tried using cameras and viewers to look into several ports, however all we can see is the face of MMT1, which I  posted a still of last night.  I have a camera looking at the back of the PRM, in hopes that we could see the beam on PRM, but no luck.  The thought was that the lever arm between TT2 and PRM is so short that as long as TT2 is reasonably in the center of its range, it doesn't need to be precise.  However, it seems that no matter how much I move TT1, I am not able to get a nice beam spot on PRM.  Part of this is that we have to be close enough to the right alignment to hit MMT1, MMT2 and TT2. 

Anyhow, we're frustrated, and I'm not sure what our next step is.  I would very much prefer it if we didn't have to open any chambers, but I don't currently have any new ideas on how to see the spot on MMT2 or TT2.

  10114   Mon Jun 30 22:06:55 2014 JenneUpdateASCIFO (mostly) aligned - ASS working

[Koji, Jenne]

The Yarm ASS is now working (as is the Xarm ASS).  Both of the TT's pitch servos had a sign flip.  We don't know why.

To start, we lowered the matrix elements that push on the TTs by a factor of 3, to compensate for the new factor of 3 in the slider gains:  ezcastep C1:ASS-YARM_OUT_MTRX_5_5 /3 C1:ASS-YARM_OUT_MTRX_5_7 /3 C1:ASS-YARM_OUT_MTRX_6_6 /3 C1:ASS-YARM_OUT_MTRX_6_8 /3 C1:ASS-YARM_OUT_MTRX_7_5 /3 C1:ASS-YARM_OUT_MTRX_7_7 /3 C1:ASS-YARM_OUT_MTRX_8_6 /3 C1:ASS-YARM_OUT_MTRX_8_8 /3

We turned off all 4 tip tilt ASS servos (in the Yarm ASS servo screen), and turned them on one at a time.  By doing this, we discovered that the pitch servos for both TT1 and TT2 needed to have the opposite sign from what they used to have.  However, the yaw servos kept the original signs.  It really doesn't make sense to me why this should be, but this is the way the ASS servo works.  We left both Xarm and Yarm ASSs on for several minutes, and saw that they didn't push any mirrors out of alignment.

The ASS_DOTHER_ON burt snapshot has been resaved with the new values.


Also, earlier this evening, I aligned the Yarm green beam to the cavity, although the cavity was not optimally aligned, so this needs to be re-done.


On our to-do list should be to add the tip tilt slider values to the DAQ channels list.

  10124   Wed Jul 2 16:18:32 2014 JenneUpdateASCIFO aligned, PRMI + 2 arms achieved

After the meeting, I aligned the IFO to the IR, and then I aligned the Ygreen to the Yarm.  I then found the beatnotes and used ALS to hold the arms with CARM/DARM, locked the PRMI, and reduced the CARM offset until I had arm powers of about 3.  Given that this was at 3pm, and people were tromping all over inside the IFO room, I feel positive about tonight.  

So, IFO seems ready, carm_cm_up script was successful, and got me to arm powers of 1, and then I further reduced the offset by a bit to go a little higher. 

  10125   Wed Jul 2 21:30:42 2014 JenneUpdateLSCLittle Bo-Peep has lost her phase
Little Bo-Peep has lost her phase,
And can't tell where to find it;
Leave it alone, and it'll come home,
Bringing its degrees behind it.
Seriously.  What?  I was holding CARM on sqrtTrans with arm powers of about 1, DARM was still ALS diff, PRMI on REFL33.  CARM was actuating on +ETMX+ETMX, since I kept kicking the MC out of lock, but other than that, everything was set by the carm_cm_up script, so I don't think there should be any big differences.  I took a CARM transfer function, and it seems like the phase bubble has all but disappeared compared to the reference from mid-May. 


I need to figure this out before it's worth trying any acrobatic AO path turn-on scenarios.


Also this evening, I went to the Yend and did another tweak-up of the green beam alignment. 

  10126   Wed Jul 2 22:58:11 2014 JenneUpdateLSCLittle Bo-Peep has found her phase

Never mind.  This is just the low pass filter that Den put in to try to deal with the moving cavity pole. 

Before I realized this, just in case it was a computer quirk, Koji and I rebooted the end station front end machines.  This had no effect other than to keep me searching and measuring until I figured it out.  If I turn off the low pass, the phase pops back up to very close to the reference.  The low pass currently comes on automatically as part of the carm_cm_up script.

  10133   Mon Jul 7 10:35:43 2014 JenneUpdateElectronicsRF PDs needed


 REFL33, AS55, REFL55,REFL165,REFL11,POX11,POP22

There were quite a few more demodulator units labelled with PD names. Do any of them need to be included in the automated frequency response measurement system? Please let me know so that I can include them to the RF switch and check them for proper illumination, which i will do for all the above PDs next week.

 In the order that makes more sense to me, it looks like you have:

REFL11, REFL33, REFL55, REFL165,




We don't really need POP22 right now, although we do want the facility to do both POP22 and POP110 for when we (eventually) put in a better PD there.  Also, we want cabling for POP55, so that we can illuminate it after we re-install it.  If we're working on 2f PDs, we might as well consider AS110 also, although I don't know that there was a fiber layed for it.  The big one that you're missing is POY11.

  10135   Mon Jul 7 13:44:21 2014 JenneUpdateCDSc1sus - bad fb connection



I managed to recover c1sus.  It required stopping all the models, and the restarting them one-by-one:

$ rtcds stop all     # <-- this does the right to stop all the models with the IOP stopped last, so they will all unload properly.

$ rtcds start iop

$ rtcds start c1sus c1mcs c1rfm

I have no idea why the c1sus models got wedged, or why restarting them in this way fixed the issue.

 In addition to needing obnoxiously regular mxstream restarts, this afternoon the sus machine was doing something slightly differently.  Only 1 fb block per core was red (the mxstream symptom is 3 fb-related blocks are red per core), and restarting the mxstream didn't help.  Anyhow, I was searching through the elog, and this entry to which I'm replying had similar symptoms.  However, by the time I went back to the CDS FE screen, c1sus had regular mxstream symptoms, and an mxstream restart fixed things right up. 

So, I don't know what the issue is or was, nor do I know why it is fixed, but it's fine for now, but I wanted to make a note for the future.

  10136   Mon Jul 7 13:55:26 2014 JenneUpdateLSCc1cal model restarted

I'm not sure why the c1cal model didn't come up the last time c1lsc was rebooted, but I did an "rtcds start c1cal" on the lsc machine, and it's up and running now.

  10150   Tue Jul 8 01:55:21 2014 JenneUpdateSUSETMX glitching

[Jenne, Rana]

A few times this evening, I had been having trouble locking CARM and DARM with ALS, and holding it for very long.  When it started happening again, I switched over to locking the individual arms with ALS.  Yarm seems to be totally fine, but Xarm has something funny going on. 

Rana and I have narrowed it down to being a problem with ETMX.  We were watching ETMX's oplev and local damping error signals, and would see occasional glitch events.  This happened when oplev + local damping were both on, both off, and when only local damping was on.  We believe that this points to something weird with the coil driver and actuator chain.

We tried to watch for a while to see if it was a step event (something switching on and off periodically), or an impulse event (some transient oscillation in an opamp perhaps), but the problem went away again.  We have come to no conclusions other than we have a problem that needs watching.

During our investigations, to more softly turn off the damping, Rana set the local damping gains, as well as the oplev gains to zero using a ramp time.  We don't recall the precise numbers, and conlog doesn't have the gains recorded, so we made an educated guess.  The local damping seems fine, but the oplev damping should be re-confirmed.  Steve, can you please show Harry how, and have him help you measure the ETMX pitch and yaw oplev loops, and set the gains so that they match up to the references, and then post the measured bode plots when you're done? 

  10165   Wed Jul 9 17:08:29 2014 JenneUpdateCDSc1auxex "Unknown Host"

c1auxex has forgotten who it is.  Slow sliders for the QPD head were not responding, so I did a soft reboot from telnet. The machine didn't come back, so I plugged the RJ45-DB9 cable into the machine and looked at it through a minicom session.  When I key the crate, it gives me an error that it can't load a file, with the error code 0x320001.  Looking that up on a List of VxWorks error codes, I see that it is:    S_hostLib_UNKNOWN_HOST (3276801 or 0x320001)

I'm not sure how this happened.  I unplugged and replugged in the ethernet cable on the computer, but that didn't help.  Rana is going in to wiggle the other end of the ethernet cable, in case that's the problem.  EDIT:  Replacing the ethernet cable did not help.

Former elogs that are useful:  10025, 10015

EDIT:  The actual error message is:

boot device          : ei                                                      
processor number     : 0                                                       
host name            : chiara                                                  
file name            : /cvs/cds/vw/mv162-262-16M/vxWorks                       
inet on ethernet (e) :                                 
host inet (h)        :                                         
user (u)             : controls                                                
flags (f)            : 0x0                                                     
target name (tn)     : c1auxex                                                 
startup script (s)   : /cvs/cds/caltech/target/c1auxex/startup.cmd             
Attaching network interface ei0... done.                                       
Attaching network interface lo0... done.                                       
Error loading file: errno = 0x320001.                                          
Can't load boot file!! 

  10169   Wed Jul 9 21:43:41 2014 JenneUpdateElectronicsPMC servo card modifications in DCC

[Rana, Jenne]

We have decided to keep better track (using new-fangled digital "computers") of our modifications to electronics boards. 

The idea will be to create a new DCC document for every electronics board (when we pull a board and modify it, it should receive this treatment) that we have, and that document will become a history of the board's life.  Version 1 will be a copy of the original drawing.  Version 2 should be a modified version of that drawing with the current situation.  All future versions should be modified from the most recent version, to reflect any changes.  Notes for each updated version should include an elog reference to the work, so that we know why we did things, and have a place to find photos of the actual modifications.  Elogs should also include a link to the DCC version.  DCC titles should include the phrase "40m Revisions" for ease of searching.

Patient Zero for this new system will be the PMC servo card.  The DCC number is D1400221.  As of this moment, this just has the V1 original drawing with no modifications.

This has been included in the 40m's DCC document tree that Jamie started back in November 2012.

  10173   Thu Jul 10 02:09:20 2014 JenneUpdatePSLFSS Fast gain set

I have put in a new nominal value for the FSS fast gain:  21.5 dB. 

There is an oscillation peak in the MC error point spectra around 41.5 kHz if the FSS gain is set too high.  I used the 4395 to have a look at the MC error point, and saw that if I set the FSS fast gain any lower than about 18 dB, the peak wasn't getting any smaller than -41 dBm.  If I set the fast gain any higher than about 26 dB the peak wouldn't get any larger than about -34 dBm. 

However, if I set the gain to 19.5dB, the PC RMS drive is consistently above 2 V, which isn't so good.  If I crank the gain up to 27 dB or more, the PC RMS will stay below 0.9 V, which is great. 

As a compromise, I have decided on 21.5 dB as the new FSS fast gain.  This puts the oscillation peak at about -39.5 dBm, and the PC RMS around 1.6 V.

I changed the nominal gain by ezcawrite C1:PSL-STAT_FSS_NOM_F_GAIN 21.5.  This sets the nominal value so that the FSS screen's fast slider doesn't turn red at the new value.  And, since the MC autolocker reads this epics channel and puts that into the gain during the mcup script, the MC autolocker now uses this new gain.  For reference, it used to be set to 23.5 dB.

  10174   Thu Jul 10 02:15:36 2014 JenneUpdateLSCQPD dark noise checkout

I have put beam dumps in front of both of the end transmission QPDs so that I could measure the dark noise.  They are still there.

I checked that the Yend QPD sliders and switches were doing things as I expected.  I couldn't do the Xend since c1auxex is still lost (elog 10165).  I'll post plots and actual information on this checkout, as well as my calculation of what this dark noise means in terms of meters for CARM when we're using 1/sqrt(trans) signals tomorrow morning. 

  10187   Fri Jul 11 20:05:34 2014 JenneUpdateLSCQPD dark noise checkout

The other day, I took spectra of the Yend transmission QPD dark noise for several different configurations of the transimpedance gain and the whitening gains. 

I also calculated with Optickle the expected sensitivity vs. CARM offset for the sqrtInv CARM sensor. 

I put these things together to get a plot of transmission QPD noise vs. CARM offset, for a chosen set of analog settings.

Measurement of Yend transmission QPD dark noise

Since EricQ had already checked out the whitening filters (see elog 9637 and elog 9642), I didn't check on them.  I just left them (the analog whitening, and the digital antiwhitening filters) on. 

First, I checked the noise vs. transimpedance gain. There are a few too many settings to put them all on one plot, so I have them sorted by the original transimpedance:  0.5 kOhms vs 5 kOhms.  It's a little tricky to see, but all of the spectra that begin with the 5k transimpedance have a little extra noise around 10 Hz, although I don't know why.  In the legend I have made note of what the settings were.  x1 x1 is my representation of the "inactive" setting.


I then looked at the noise with different whitening gain slider settings.  All but one of the traces are the 20 kOhm setting.  


These .xml files are in /users/jenne/Arms/TransQPDnoise_July2014/

Calculation of inverse sqrt transmission sensitivity

I used Optickle to give me the power transmitted through the ETMs.  I first find the transmission in the FPMI case.  I use that to normalize the full PRFPMI transmission, so that the output units are the same as our C1:LSC-TR[x,y]_OUT units. 

I take the square root of the transmitted power (sum of transmissions from each arm) at each CARM offset point, add 1e-3 as we do in the front end model to prevent divide-by-zero problems, and then take the inverse.

I find the slope by taking the difference in power between adjacent points, divided by the CARM offset difference between those points. 

In this plot, I have taken the absolute value of the sensitivity, just for kicks.  I also display an arbitrarily scaled version of the log of the transmitted power, so that we can see that the highest sensitivity is at half the maximum power.


 Calculate the QPD dark noise in terms of meters

Finally, I put it all together, and find the dark noise of the QPD in terms of meters.  Since the spectra were measured in units where the single-arm transmission is unity, the already match the units that I used to calculate the sqrtInv sensitivity. 

I take the spectra of the QPD dark noise for the 20 kOhm case, and multiply it by the sensitivity calibration number at several different CARM offsets.  As we expect, the noise is the best at half-max transmission, where the sensitivity is maximal. 


  10198   Tue Jul 15 00:16:52 2014 JenneUpdateSUSPRM significantly pitched

I'm starting to lock for the night, and I noticed that PRM is very, very pitched.  Why?  The PRM pitch slider is 5 full integer units higher than the backup (and the backup value is about where I like it, around -0.2).

I am not aware of any scripts that touch the PRM slider values.  The PRM ASS (which I haven't used in ages) offloads the biases to the SUS screen fast channels, so even if someone turned that on and then saved the values, it wouldn't leave the PRM so very, very misaligned.

I have restored it, and relocked the PRMI, so all is well, but it's very weird to have found it so misaligned.

  10200   Tue Jul 15 01:41:43 2014 JenneUpdateLSCData for DARM on sqrtInv investigation

I took some data tonight for a quick look at what combinations of DC signals might be good to use for DARM, as an alternative to ALS before we're ready for RF.

I had the arms locked with ALS, PRMI with REFL33, and tried to move the CARM offset between plus and minus 1.  The PRMI wasn't holding lock closer than about -0.3 or +0.6, so that is also a problem.  Also, I realized just now that I have left the beam dumps in front of the transmission QPDs, so I had prevented any switching of the trans PD source.  This means that all of my data for C1:LSC-TR[x,y]_OUT_DQ is taken with the Thorlabs PDs, which is fine, although they saturate around arm powers of 4 ever since my analog gain increase on the whitening board.  Anyhow, the IFO didn't hold lock for much beyond then anyway, so I didn't miss out on much.  I need to remember to remove the dumps though!!

Self:  Good stuff should be between 12:50am - 1:09am.  One set of data was ./getdata -s 1089445700 -d 30 -c C1:LSC-TRX_OUT_DQ C1:LSC-TRY_OUT_DQ C1:LSC-CARM_IN1_DQ C1:LSC-PRCL_IN1_DQ

  10206   Tue Jul 15 21:43:28 2014 JenneUpdateLSCQPDs back

I removed the dumps in front of the trans QPDs.  The Yend QPD needed re-normalization, so I did that.

  10208   Wed Jul 16 01:04:09 2014 JenneUpdateLSCData for DARM on sqrtInv investigation

I realized while I was looking at last night's data that I had been doing CARM sweeps, when really I wanted to be doing DARM sweeps.  I took a few sets of data of DARM sweeps while locked on ALSdiff.  However, Rana pointed out that comparing ALSdiff to TRX-TRY isn't exactly a fair comparison while I'm locked on ALSdiff, since it's an in-loop signal, so it looks artificially quiet. 

Anyhow, I may consider transitioning DARM over to AS55 temporarily so that I can look at both as out-of-loop sensors. 

Also, so that I can try locking DARM on DC transmission, I have added 2 more columns to the LSC input matrix (now we're at 32!), for TRX and TRY.  We already had sqrt inverse versions of these signals, but the plain TRX and TRY were only available as normalization signals before.  Since Koji put in the facility to sqrt or not the normalization signals, I can now try:

Option 1:  ( TRX - TRY ) / (TRX + TRY)

Option 2:  ( TRX - TRY ) / sqrt( TRX + TRY )

DARM does not yet have the facility to normalize one signal (DC transmission) and not another (ALS diff), so I may need to include that soon.  For tonight, I'm going to try just changing matrix elements with ezcastep.

Since I changed the c1lsc.mdl model, I compiled it, restarted the model, and checked the model in.  I have also added these 2 columns to the AUX_ERR sub-screen for the LSC input matrix.  I have not changed the LSC overview screen.

  10224   Thu Jul 17 00:38:30 2014 JenneUpdateLSCRIN in arm transmission

[Rana, Jenne]

We had a look at the RIN of the transmission signals TRX and TRY, when the arms were individually locked on IR.  If the intensity noise is very bad, then the transmission signals aren't really a good option to use for locking.  So, if the RIN is bad, we need to work on our intensity stabilization. 

We need to understand what the situation is with the AOM, and why it isn't working as expected, so that we can reinstall it.  We also need to decide if we're going to use the SR560 setup, or if the Chas ISS is sufficiently characterized for us to use. 

The RIN is certainly bad.  Also, I don't know why the Xarm's RIN is worse between 10 Hz and a few hundred Hz than the Yarm.


  10241   Sat Jul 19 17:36:44 2014 JenneUpdateLSCRIN in arm transmission

I looked at what the RIN contribution of the sqrtInv sensor is by locking the arms individually on IR using POX and POY.  I then took spectra of the sqrtInv channels.  For the Xarm, I had forced the triggering so that the QPD was being used as the transmission PD, while the Yarm was using the regular Thorlabs PD.  I also had the green lasers locked to the arms, and took beatnote spectra to see what the sensing noise of the beatnotes is, all at the same time.

For the sqrtInv channels, I used the Optickle calibration from elog 10187. For today's plot, I am using the calibration at about 1nm, since that is about where we are when we transition to the sqrtInv Thorlabs signal usually.

For the ALS channel, I was using the _FINE_PHASE_OUT signal, which is in units of degrees of phase for a single green wavelength.  So, since k * x = phi, I want the phase data to be converted to radians (2*pi/360), and use k = 2*pi / lambda_green.  So, doing some algebra, this gives me x = phi_degrees * lambda / 360 for my calibration. 

What I see in the plot is that the ALS sensing noise is pretty bad compared to the sqrtInv channels, so maybe we don't have to work so hard on the ISS this next week.  Also, the Thorlabs PD is much better than the QPDs, which maybe isn't so surprising since we have them set so that they have good SNR at higher power.

Anyhow, here's the plot:


Also, here is the Thorlabs PD only, with single arm locked on RF, with the noise calibrated to different CARM offsets:


  10258   Wed Jul 23 02:01:15 2014 JenneUpdateLSCRIN in arm transmission - revised calibration


As Koji pointed out, I messed up the calibration.  However, fixing it doesn't change things that much.

From this calibration by Yuta, the Xarm ALS calibration is 54 deg / MHz, or 19.17 kHz / deg.  So, I multiply my data which is in these degree units by 19.17e3 to get Hz.  Then I use delta_f / f = delta_L / L to convert to meters.  f = c / lambda_green, and L = 37.5 meters. 

This only changes the calibration by about 10-15%.  It still looks like the ALS noise is well above the RIN level of the sqrtInv signal.


  10330   Mon Aug 4 18:25:46 2014 JenneUpdateGeneralChronic Suspension Problems

Q is working on fixing the "save offsets" script for the ASS, because that has lost me my alignment two more times in the last few hours.  But, right now I have both arms locked with transmitted powers of about 0.9!  To get this, I ran the ASS scripts, and hand-tweaked the bias sliders of some of the optics to relieve the ASS outputs.  Then I turned the ASS gain to zero, and by-hand turned off the oscillators.  So, the ASS outputs are just frozen. 

I haven't seen IMTX suspension kicks, I think since Q did the front end reboot earlier. There has been ITMY activity, however. I think I'm going to be bold, and try locking ALS.

  10331   Mon Aug 4 22:52:03 2014 JenneUpdateLSCALS alignment tweak-up

After aligning the arms to IR, I aligned the Y green beam to the arm.  Also, the X green beatnote was very small, so I aligned the PSL green for X.

  10335   Wed Aug 6 00:14:10 2014 JenneUpdateLSCALS is iffy tonight

The ALS system is iffy tonight.

After putting the cable back to the RF spectrum analyzer (it had been taken to test the frequency counter setup, and not put back), I had a good Yarm beatnote, but again this evening the Xarm beatnote is small.  I touched up the PSL table alignment (very, very little needed, but it did double my peak height).  I *think* that this is happening because we haven't settled into a good IFO alignment place, so the arm pointing keeps changing very slightly, which means that the PSL ALS alignment needs touching.  Anyhow, even after alignment the Xarm beatnote is only -36 dBm at 81 MHz.  It should be at least -25 dBm or so, although I haven't seen it any larger than about -35 dBm since the IFO beam was lost last Friday.

I am not able to hold ALS lock long enough to scan the arms and find the IR resonances.  The only optics that I am actuating on this evening are the 2 ETMs.  When I lose lock and look at the watchdogs, the ETMs are the only optics that have largeish numbers, which comes from the ALS lockloss.  So, I don't think I am suffering from the ITM suspension kicks tonight.  Rather, I think that it's that the ALS system isn't tuned up nicely.

I think that it is past time we tuned up and checked out the ALS PDH setup.  Q:  Can you please measure the loop TFs for both of the ALS PDH boxes tomorrow?  At the very least we want to know what we're working with. 

Evan:  What is the status with the ISS? 

I am going to try tomorrow to look at the suspensions, and see if I can track anything down.  I feel like I see the kicks more often when the arms are locked, i.e. we are sending an LSC signal to them.  The LSC POS signal is a factor of a few hundred larger than the damping SUSPOS signal is.  Are we saturating something somewhere?  Why is this a new thing?  We certainly do see kicks when the LSC is not engaged, so this may not be the right path, but it is something concrete to look at.

  10340   Wed Aug 6 17:29:36 2014 JenneUpdateIOOFSS offset changed

The MC has been unstable and unhappy for the last several hours.  When I looked, I saw that the FSS_FAST monitor has been hovering around 1 V, when it is supposed to be closer to 5ish. 

I changed the C1:PSL-FSS_INOFFSET from -0.08 to -0.8537, and will see if the MC sticks around for longer this time around.

  10344   Thu Aug 7 12:25:14 2014 JenneUpdateIOOFSS offset changed


The fast feedback should be around zero now!

 Dang it, I completely forgot.  Well, anyhow, it pulled itself back down to less than 1V, and the MC stayed happy for several hours.  I'm not totally sure what changing the offset did, but the MC seems happy for right now.  I should take a quick look at the error point to make sure that I didn't mess up your tuning.

  10345   Thu Aug 7 12:34:56 2014 JenneUpdateLSCSuspensions not kicking?

Yesterday, Q helped me look at the DACs for some of the suspensions, since Gabriele pointed out that the DACs may have trouble with zero crossings.  

First, I looked at the oplevs of all the test masses with the oplev servos off, as well as the coil drive outputs from the suspension screen which should go straight out to the DACs.  I put some biases on the suspensions in either pitch or yaw so that one or two of the coil outputs was crossing zero regularly.  I didn't see any kicks. 

Next, we turned off the inputs of the coil driver filter banks, unplugged the cable from the coil driver board to the satellite box, and put in sinusoidal excitations to each of the coils using awggui.  We then looked with a 'scope at the monitor point of the coil driver boards, but didn't see any glitches or abnormalities.  (We then put everything back to normal)

Finally, I locked and aligned the 2 arms, and just left them sitting.  The oplev servos were engaged, but I didn't ever see any big kicks. 

I am suspicious that there was something funny going on with the computers and RFM over the weekend, when we were not getting RFM connections between the vertex and the end stations, and that somehow weird signals were also getting sent to some of the optics.  Q's nuclear reboot (all the front ends simultaneously) fixed the RFM situation, and I don't know that I've seen any kicks since then, although Eric thinks that he has, at least once.  Anyhow, I think they might be gone for now.

  10357   Fri Aug 8 19:42:59 2014 JenneMetaphysicsGeneralkitchen sink flooding

 When I got back to the lab, there was enough water that it was seeping under the wall, and visible outside. Physical plant says it will take an hour before they can come, so I'm getting dinner, then will let them in.

  10358   Fri Aug 8 20:22:12 2014 JenneMetaphysicsGeneralkitchen sink water off


 When I got back to the lab, there was enough water that it was seeping under the wall, and visible outside. Physical plant says it will take an hour before they can come, so I'm getting dinner, then will let them in.

 The guy from physical plant came, and turned off the water to the kitchen sink.  He is putting in a work order to have the plumbers come look at it on Monday morning.  It looks like something is wrong with the water heater, and we're getting water out of the safety overpressure valve / pipe.

The wet things from under the sink are stacked (a little haphazardly) next to the cupboards.

  10368   Tue Aug 12 13:31:58 2014 JenneUpdatePEMSeismometer cables in place, ready for sensors

[TaraV, Jenne]

The short cable from the slab to the sensor has been assembled and installed for the Trillium slab at the corner station.  The corner still needs the sensor and the long cable, both of which are in use by the gyro experiment.

The STS-2 cable that was running to the Xend was pulled, and the new long Guralp cable that Den made was installed with help from Andres.  The Xend just needs the sensor itself, which is also in use in gyro-land.

So, once we get the 2 seismometers and the one cable back from Zach, we should have 3 sensors nicely on the slabs that Den and Steve designed.

  10377   Wed Aug 13 17:37:43 2014 JenneUpdateGeneralGame plan


Here's the game plan for things that we need to do to get this IFO locked up. 

Red is for things that should be done today, or tomorrow if they don't get finished today (eg. laser mode hopping temperature check).  Orange is for things that will become red once the current red things are gone (eg. inferring the POP QPD gouy phase, and moving it to minimized PRM information).  Green is for things that we'd like to do, but aren't high priority (eg. X green mode matching).  Blue is for things that we should remember, but not plan on working on soon (eg. putting PZTs on the Yend table for green).

TODAY so far:

Q already did the tweak up of the PSL SHG crystal alignment.  HE SHOULD ELOG ABOUT THIS.  What was the final power of green that you got?  Do we have any record of a previous measurement to compare to?

Q helped me install PDA55s on each of the lasers (I did the ends, he did the PSL) so that we could do the mode hop temperature check.  For the Yend, I took the leakage transmission through the first Y1 steering mirror after the laser. This beam was dumped, so I replaced the dump with a PDA55. For the Xend, the equivalent mirrors are too close to the edge of the table, so I put in a spare Y1, and reflect most of the light to a beam dump.  The leakage transmission then goes to a PDA55.  Note that for both of these cases, no alignment of main laser path mirrors was touched, so we should just be able to remove them when we're through.  For the PSL, I believe that Q took the rejected light from one of the PBSes before the PMC.  He mentioned that he bumped something, so had to realign the beam into the PMC, but that he was able to get the transmission back up to 0.802, when we were seeing it in the mid 0.7's for the last several days.

The end temporary PDs are using the TRX / TRY cables, so we will be looking at the C1:LSC-TR[x,y] channels for the power of the end lasers.  The PSL's temporary PD is connected to the PMC REFL cable.  For the end PDs, since I had filter banks available, I shuttered the end lasers and removed the dark offset.  I then changed the gains to 1, so the values are in raw counts.  The usual transmission normalization gains are noted in one of the control room notebooks.

I did a slow ezcastep and ramped the temperature of all 3 lasers over about an hour.  I'll write a separate elog about how that went.

  10378   Wed Aug 13 19:23:09 2014 JenneUpdateLSCPSL, Aux laser mode hop check

This afternoon Q helped me put in some temporary PDs for checking for any mode hopping behavior in our 3 main lasers. 

Q helped me install PDA55s on each of the lasers (I did the ends, he did the PSL) so that we could do the mode hop temperature check.  For the Yend, I took the leakage transmission through the first Y1 steering mirror after the laser. This beam was dumped, so I replaced the dump with a PDA55. For the Xend, the equivalent mirrors are too close to the edge of the table, so I put in a spare Y1, and reflect most of the light to a beam dump.  The leakage transmission then goes to a PDA55.  Note that for both of these cases, no alignment of main laser path mirrors was touched, so we should just be able to remove them when we're through.  For the PSL, I believe that Q took the rejected light from one of the PBSes before the PMC. 

The end temporary PDs are using the TRX / TRY cables, so we will be looking at the C1:LSC-TR[x,y] channels for the power of the end lasers.  The PSL's temporary PD is connected to the PMC REFL cable.  For the end PDs, since I had filter banks available, I shuttered the end lasers and removed the dark offset.  I then changed the gains to 1, so the values are in raw counts.  The usual transmission normalization gains are noted in one of the control room notebooks.

I did a slow ezcastep and ramped the temperature of all 3 lasers over about an hour.  Since we usually use the PSL around FSS slow slider value of zero, I swept that from -10 to +10.  Since we usually use the Xend laser at around 10,000 counts, I swept that from 0 to 20,000.  For the Yend laser, it is usually around -10,000 counts, so I swept it from -20,000 to 0.  ezcastep -s 0.2 C1:ALS-X_SLOW_SERVO2_OFFSET +1,20000 C1:ALS-Y_SLOW_SERVO2_OFFSET +1,20000 C1:PSL-FSS_SLOWDC +0.001,20000

I was looking for something kind of similar to what Koji saw when he did this kind of sweep for the old MOPA (elog #2008), but didn't see any power jumps that looked suspicious.

Here is the PSL:


The Xend:


And the Yend:


  10382   Thu Aug 14 02:51:46 2014 JenneUpdateGeneralGame plan

[Jenne, Rana]

* Decided that earlier mode hop scan won't give us the information that we were hoping for.  We need to think about where we can actually see the frequency change.  Can we use the IR beatnote that we will soon have to do this?  We'd only be able to scan one laser temp at a time, but that's okay.  Leave, say, the PSL temperature alone, and scan one of the end laser temps.  Using the PSL as the reference, we will be able to see if the frequency of the end laser goes crazy and jumpy as we pass through a certain temp.  Then, repeat while holding the end laser constant and scan the PSL.  Thoughts?

* Meditated on PSL oplev servo, but I need to make a Matlab script that can evaluate different loops according to a cost function based on elog 9690

* Aligned IFO to IR, then greens to arms (got back to 0.9 for GTRY, but only about 0.5 for GTRX, with the PSL green shutter closed).  Then aligned green beams on the PSL table, since the PSL green pointing had changed a bit from Q's crystal alignment tweak-up earlier today.  Beatnotes are nice and big (see elog 10381 - The Yarm is the larger beatnote, and the Xarm is the smaller one.)

* Was not able to lock ALS comm/diff and hold long enough to get both arms to IR resonance.  Also, saw that TRY's RIN was more than 50%(!!!).  We took a look, and there seems to be much more low frequency noise than there was when the spectrum in the control room was taken for the multicolor metrology paper:


* Tried to balance the ALS comm/diff input matrix, with not a lot of success.  First of all, it looks like the Xarm has overall about 10 times more noise!  We were exciting MC2 in position (~88 Hz, about 130 counts I think), and then looking at DARM_IN1 for the peak.  When DARM_IN1 was just one of the 2 ALS error signals (i.e. one matrix element set to zero), versus when both matrix elements were set to 1, we saw a factor of only about 3 in reduction of the peak height.  We were hoping to have better cancellation of this pure CARM signal in the DARM channel.  The Xarm green PDH loses lock every ~5 or 10 minutes, and when we relock it, this cancellation seems different, so we want to try again tomorrow when the ALS is locked on comm / diff, rather than just the free running ALS that we have now.  Although, if the balance of the input matrix changes lock-to-lock, we may need to consider redoing the green PSL table layout so we get a pure DARM beatnote signal like they have at the sites.

* We want to change how the watch script for ALS works, although this is a low-priority task.  Rather than looking at the control signal, we should maybe look at the sum of all the coil outputs, multiplied by a pendulum TF, and use that as a rough displacement sensor.  We want to be careful of pushing too hard at low frequencies, but we want to allow higher frequency actuation without having the watch script shut things down.

* Also, I should put on the to-do list the revamp of the ALS find IR resonance script.

  10383   Thu Aug 14 14:58:03 2014 JenneUpdateGeneralUpdated game plan


(Updated as of 4pm)

  10386   Thu Aug 14 15:51:37 2014 JenneUpdateGeneralUpdated game plan


 - ALS

End PDH UGF improvement / post mixer LPF investigation (with in 2 weeks)


Riju measured the MC REFL PD transimpedance. See ELOG and related.


Why do we want to see less PRM motion? I thought PRC motion was causing
LSC issue of the central part. We wanted to maximize the PRM effect, don't we?
(Or is this to supress ETM motion during full lock?)

 End PDH - good point, thanks.

ASC - Yes, this is so that we can use the POP QPD to feed back to the common ETMs after the CARM offset is already quite small.  We will not use POP DC QPD for PRC any more. 

Also, for future PRC ASC, I keep coming back to this in my head, but maybe it is less painful to install oplevs for PR2, PR3 than it would be to make an RF QPD.  Neither is going to be trivially easy.  But if we had sensors of the tip tilt motions, we could feed all of that back to the PRM to stabilize the PRC.

  10388   Thu Aug 14 18:05:05 2014 JenneUpdateGeneralUpdated game plan


- Oplevs for PR2, PR3 => Almost impossible.

 Because of the limited table space inside?  That's the main reason I can think of that this method is hard.  Am I missing something?

  10392   Thu Aug 14 19:33:00 2014 JenneConfigurationIOOMoved MC2 spot

Last night, and again just now, I used the ./MC2_spot_[direction] scripts to center the MC2 spot on the trans QPD.  The MCWFS handled overall alignment to correct for the fact that the ratios in the script aren't perfect.  When I was finished, I ran the MC WFS relief script from the WFS screen.  Last night, and again today, things had drifted until the yaw spot was more than 0.5 counts off.

  10394   Thu Aug 14 22:16:02 2014 JenneUpdateSUSViolin Mode filters for ETMs

The instigator of this was that we were seeing ring-ups of ETMs during our ALS locks this evening.  We measured the ETMY violin resonance to be 624.10 Hz, and Rana found an elog saying that the ETMX was around 631 Hz, so we made a 2 notch filter and added it to FM4 of the LSC-SUS filter banks for both ETMs. 

For the ETMY resonance, we measured the frequency in the DARM spectrum, and when we looked at the FINE_PHASE_OUT channels, the resonance was only in the Yarm sensor.  So, we conclude that it is coming from ETMY.

Also in the realm of filter modules, the FM3 boost for CARM, DARM, XARM and YARM was changed from zero crossing to ramp with a 1sec ramp time.

ELOG V3.1.3-