40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
 40m Log, Page 55 of 341 Not logged in
ID Date Author Type Category Subject
5601   Mon Oct 3 14:05:41 2011 JenneUpdateSUSFailing to set SUS summary screen values

I assume it's because the burt restore didn't work for the SUS summary screen, but all of the values for the ifo suspensions (not the MCs...they're okay) are red.

I am trying to run Rana's setSensors.py script, but am failing.  Any inspiration would be appreciated:

rosalba:SUS_SUMMARY>./setSensors.py 1001708529 500 .1 .25
['./setSensors.py', '1001708529', '500', '.1', '.25']
/cvs/cds/caltech/apps/linux64/python/lib64/python2.4/site-packages/nds/__init__.py:28: RuntimeWarning: No protocol specified, attempting protocol nds_v2
super(daq, self).__init__(host, port)
Connecting NDS2 .... authenticate done
Traceback (most recent call last):
File "./setSensors.py", line 81, in ?
mean = acquire(x)
File "./setSensors.py", line 73, in acquire
daq.request_channel(chans[x])
Boost.Python.ArgumentError: Python argument types in
daq.request_channel(daq, str)
did not match C++ signature:
request_channel(_daq_t {lvalue}, daq_channel_t*)

I'm not exactly sure what the problem is.  Line 73, looks like it should have 2 arguments in the daq.request_channel, but even if I put in the "daq" variable (which is set a few lines above), I get the exact same error.  So...something else is wrong.  Ideas from someone who "speaks" python??

5602   Mon Oct 3 16:18:05 2011 JenneUpdateAdaptive FilteringMeditations on the OAF

 Quote: [Mirko, Den, Jenne] We're modifying the c1oaf model, and we got to talking about the "Fx" part of "FxLMS".  In the past, we put in a guess for the filter.  What if we use the static wiener filter as the F, and send the wiener filtered witness channels to the adaptation algorithm?  Are the wiener filter and the plant compensation filter ("Fx") the same?  Will this work?  Or is there some reason that they must be different? Also:  Notes to self:  Put in filtered witness channels as well as regular into Adapt block.  Make sure that the order/number of inputs is correct.

More meditations...

Mirko and I were talking about the tunability required for each DoF.  For right now, we're going to give each DoF its own mu and tau (adaptation gain and adaptation decay), but we're leaving all of the other things (number of taps, number of witnesses, delay, downsample rate) the same for each DoF's adaptation.  This may need to change later, but we'll get there when we get there.

The one I'm most concerned about is the number of witnesses...  Mirko is suggesting that we give each adaptation algorithm all witnesses, and unused ones should converge to ~0.  I agree in principle, but I'm not sure that it's actually going to work that way.  I think we may need to be able to tell the algorithm which witnesses to look at for which DoF.

Also, the Delay.... we may need to adjust it for each DoF.  In Matt's OAF "manual" in elog 395, he mentions the need to calculate the delay based on a plant TF.  Presumably since (except for the MC) all the witnesses come in together, and all the DoFs come in together, the delay should be about the same for all?  We'll have to see...

5603   Mon Oct 3 17:06:27 2011 JenneHowToComputer Scripts / ProgramsKissel Button Generator

 Quote: >pwd /opt/rtcds/caltech/c1/medm/c1lsc_tst/master/KisselButtonGenerator 

I copied the Kissel button generator scripts folder into scripts:

/opt/rtcds/caltech/c1/scripts/KisselButtonGenerator/

Maybe this isn't the most intuitive place ever, since it's a script that only has to do with medm screens, but at least it's better than hidden in the depths of Koji's LSC medm path.....

5604   Mon Oct 3 17:27:23 2011 JenneUpdateSUSFailing to set SUS summary screen values

 Quote: I am trying to run Rana's setSensors.py script, but am failing.  Any inspiration would be appreciated: rosalba:SUS_SUMMARY>./setSensors.py 1001708529 500 .1 .25 ['./setSensors.py', '1001708529', '500', '.1', '.25'] /cvs/cds/caltech/apps/linux64/python/lib64/python2.4/site-packages/nds/__init__.py:28: RuntimeWarning: No protocol specified, attempting protocol nds_v2   super(daq, self).__init__(host, port) Connecting NDS2 .... authenticate done Traceback (most recent call last):   File "./setSensors.py", line 81, in ?     mean = acquire(x)   File "./setSensors.py", line 73, in acquire     daq.request_channel(chans[x]) Boost.Python.ArgumentError: Python argument types in     daq.request_channel(daq, str) did not match C++ signature:     request_channel(_daq_t {lvalue}, daq_channel_t*) I'm not exactly sure what the problem is.  Line 73, looks like it should have 2 arguments in the daq.request_channel, but even if I put in the "daq" variable (which is set a few lines above), I get the exact same error.  So...something else is wrong.  Ideas from someone who "speaks" python??

My guess is that this has something to do with the NDS client version you're using.  Try running the script on a machine where pynds and nds-client are known to be compatible, like pianosa.

5608   Mon Oct 3 21:20:30 2011 JenneUpdateCDSc1lsc and c1sus didn't run

[Jenne, Mirko, Kiwamu, Koji, and Jamie by phone]

We just got off the phone with Jamie.  In addition to all the stuff that Kiwamu mentioned, Mirko reverted the c1oaf model and C-code to stuff that was working successfully on Friday (using "svn export, rev # 1134) since that's what we were working on when all hell broke loose.

We did a few rounds of "sudo shutdown -h now" on c1lsc and c1sus machines, and pulled the power cords out.

We also switched the c1ioo and c1lsc 1PPS fibers in the fanout chassis, to see if that would fix the problem.  Nope.  c1ioo is still fine, and c1lsc is still not fine.

Still getting "No Sync".

We're going to call in Alex in the morning, if we can't figure it out soon.

5612   Tue Oct 4 14:41:47 2011 JenneUpdateIOOMC Trans channels are digital 0

I relocked the PMC (why is it unlocking so much lately??), and then noticed that even though the MC is locked, MC Trans Sum, P, Y, are all seeing digital zero.  I'm putting Suresh, as IOO guy, in charge of figuring it out.

5625   Thu Oct 6 15:37:26 2011 JenneUpdateGreen LockingY-green Mech Shutter Button

[Katrin, Jenne]

We were poking around and tried to make a button for the Y-green shutter, just like the X-green already has.  I don't know where the X-green shutter button goes to in model-land, so I can't figure out if there is already a channel set up for the Y end.  Just switching the X for a Y didn't work.  Someone (maybe me) should fix this in the next soon.

5626   Thu Oct 6 15:40:57 2011 JenneUpdateLSCArm absl length data taken

[Katrin, Jenne]

We took the data for the new absolute length measurement of both arms, after the latest vent and move.  We will analyze soonly.  We had done a round of analysis,  but then Koji pointed out that our data wasn't so clean because the whitening filters were on (and saturated the ADC).  We now have the data (but not the analysis) for the better data with the WF off.

So our dirty-data preliminary number for the X arm is 37.73meters, which is 14cm different from our old length.  We were supposed to move by ~20cm, so....either this measurement is bad because the data sucked (which it did), or we are 6cm off.  Or both.

I'll do another analysis with the clean data for both arms later today/tomorrow.

5653   Tue Oct 11 21:23:51 2011 JenneUpdateLSCArm absl lengths

 Quote: [Katrin, Jenne] We took the data for the new absolute length measurement of both arms, after the latest vent and move.  We will analyze soonly.  We had done a round of analysis,  but then Koji pointed out that our data wasn't so clean because the whitening filters were on (and saturated the ADC).  We now have the data (but not the analysis) for the better data with the WF off. So our dirty-data preliminary number for the X arm is 37.73meters, which is 14cm different from our old length.  We were supposed to move by ~20cm, so....either this measurement is bad because the data sucked (which it did), or we are 6cm off.  Or both. I'll do another analysis with the clean data for both arms later today/tomorrow.

After analyzing the cleaner data, I get the following:

Y_Length_long  =  37.757 meters

X_Length_long  =  37.772 meters

As stated in the wiki, the goal arm length was  L = 37.7974 m for each arm.

So we're within 2cm for X, and within 4cm for Y.

According to Kiwamu's awesome tolerance calculation, we need to be within 2cm for each arm.  Given that we started out 20cm wrong for X and 25cm wrong for Y, we're a lot closer now, even though we aren't meeting our Yarm requirement yet.

Probably some Optickle action is in order, to see what these new lengths give us in terms of sideband phase and other stuff.

If you want more digits on my calculated numbers (which are probably meaningless, but I haven't done a careful error analysis), in my directory ...../users/jenne/Xarm and ..../users/jenne/Yarm run Xarm_find_peaks_and_length.m and Yarm_find_peaks_and_length.m  respectively.  These will output the lengths.

5705   Wed Oct 19 18:16:53 2011 JenneUpdatePSLPMC found unlocked

I just relocked the PMC.  I don't know why it was unlocked.

5707   Wed Oct 19 19:43:16 2011 JenneUpdatePSLPMC found unlocked

 Quote: I just relocked the PMC.  I don't know why it was unlocked.

Again....

5714   Thu Oct 20 18:01:17 2011 JenneUpdateComputer Scripts / ProgramsWhere should the "Update Snapshots" of screens live?

While trying to implement the regular yellow shell script button in MEDM for my new OAF screen, I noticed that the update snapshot stuff in all of the buttons that I checked (including IFO Align and LSC Overview) are pointing to folders in the old /cvs/cds/caltech/ area.  Also, I think some of the folders that it's looking for don't exist anymore, even in the old system.  So.  Has anyone thought about where the snapshots should live in the new world order?  Previously they were in ...../medm/c1/subsystem/ .  Maybe we should make a snapshots folder in each subsystem's medm folder, at the same level as the 'master' folder for the custom screens?  This is my current proposal.

Unless someone objects / has a better plan / knows why they're still pointing to the old place, I'll do this in the morning, and work on changing all the buttons to point to the new place.

5756   Fri Oct 28 14:56:02 2011 JenneUpdateCDSCSS/BOY installed on pianosa

 Quote: I've installed Control System Studio (CSS) on pianosa, from the version 3.0.2 Red Hat binary zip.  It should be available as "css" from the command line. CSS is a new MEDM replacement. It's output is .opi files, instead of .adl files.  It's supposed to include some sort of converter, but I didn't play with it enough to figure it out. Please play around with it and let me know if there are any issues. links:

So far I've only given it about half an hour of my time, but it is *really* frustrating so far.  There don't seem to be any instructions on how to tell it what our channels are / how to link CSS to our EPICS databases.  Or, the instructions that are there say "do it!", but they neglect to mention how...  Also, there exists (maybe?) an ADL->BOY converter, but I can't find any buttons to click, or how to import an .adl, or what I'm supposed to do.  Also, it's not clear how to get to the editor to start making screens from scratch.

It looks like it has lots of nifty indicators and buttons, but I would have felt better if I had been able to do anything.

Another thing that is going to be a problem:  the Shell Command button that we use all over the place in our MEDM screens is not supported by this program.  It's listed in the "limitations" of the ADL2BOY converter.  This may kill the CSS program immediately.  Jamie: did Rolf/anyone mention a game plan for this?  It's super nice to be able to run scripts from the screens.

Moral of the story:  I'm annoyed, and going to continue making my OAF screens in MEDM for now.

5757   Fri Oct 28 15:33:06 2011 JenneUpdateComputersNifty screen generator

Suresh showed me a cool script that Mirko made, but didn't elog about.

You tell the script what filter banks you want, and it creates a screen for each with a bunch of different filter module display formats.  Then you can copy the format you like into the actual screen you're modifying.

Currently PEM, LSC and IOO (and maybe others?) have "fmX" folders inside their medm/c1.../master folders.  For each subsystem, we need to copy this folder, and modify the generic .adl file so that it puts in the correct subsystem letters.  Once this is done, you can just run the generateFMscreens.py after putting in your filter bank names.

5772   Mon Oct 31 19:39:00 2011 JenneUpdateAdaptive FilteringScreens, code, computers

[Mirko, Jenne]

I finished (mostly? maybe?) the OAF screens.  They're pretty awesome.

While we were playing with the OAF, trying to do some oafing, the output of the code decided to just be zeros.  We did a test, and in the c-code set the output to be a constant value, and that worked.  But when we put it back to normal (being adaptive) and recompiled, it still only outputs zeros.  The code is receiving both witness and error signals, so we don't know what's going on.

In the course of trying to make things work again, we did a complete reboot of c1lsc and c1sus.  Did a burt restore.  Everything (except our weird code problem) should be fine again.  Optics are damping happily.

5778   Tue Nov 1 18:45:48 2011 JenneUpdateComputersAllegra's screens

I was trying to give Allegra a second head, and it didn't quite work.  It's still in progress.  Steve, you might not like how I've 'mounted' the second monitor, so we can talk about something that might work tomorrow.

5792   Wed Nov 2 22:02:39 2011 JenneUpdatePhotosNew screen snapshot script written!

After lots of trial and error, and a little inspiration from Koji, I have written a new script that will run when you select "update snapshot" in the yellow ! button on any MEDM screen.

Right now, it's only live for the OAF_OVERVIEW screen.  View snapshot and view prev snapshot also work.

Next on the list is to make a script that will create the yellow buttons for each screen, so I don't have to type millions of things in by hand.

The script lives in:  /cvs/cds/rtcds/caltech/c1/scripts/MEDMsnapshots, and it's called....wait for it....... "updatesnap".

5793   Thu Nov 3 13:00:52 2011 JenneUpdatePhotosFormatting of MEDM screen names

 Quote: After lots of trial and error, and a little inspiration from Koji, I have written a new script that will run when you select "update snapshot" in the yellow ! button on any MEDM screen.  Right now, it's only live for the OAF_OVERVIEW screen.  View snapshot and view prev snapshot also work.  Next on the list is to make a script that will create the yellow buttons for each screen, so I don't have to type millions of things in by hand. The script lives in:  /cvs/cds/rtcds/caltech/c1/scripts/MEDMsnapshots, and it's called....wait for it....... "updatesnap".

Currently the update snapshot script looks at the 3 letters after "C1" to determine what folder to put the snapshots in.  (It can also handle the case when there is no C1, ex. OAF_OVERVIEW.adl still goes to the c1oaf folder).  If the 3 letters after C1 are SYS, then it puts the snapshot into /opt/rtcds/caltech/c1/medm/c1sys/snap/MEDM_SCREEN_NAME.adl

Mostly this is totally okay, but a few subsystems seem to have incongruous names.  For example, there are screens called "C1ALS...." in the c1gcv folder.  Is it okay if these snapshots go into a /c1als/snap folder, or do I need to figure out how to put them in the exact same folder they currently exist in?  Or, perhaps, why aren't they just in a c1als folder to begin with? It seems like we just weren't careful when organizing these screens.

Another problem one is the C1_FE_STATUS.adl screen.  Can I create a c1gds folder, and rename that screen to C1GDS_FE_STATUS.adl?  Objections?

5812   Fri Nov 4 15:26:54 2011 JenneUpdateLSCLSC model recompiled

I moved the place where we take the OAF Degree of Freedom signals from - now it's the error point rather than the feedback for DARM, CARM, MICH, PRCL, SRCL, XARM and YARM.  I didn't do anything to MCL.

While trying to compile, there was something wrong with the lockins that were there...it complained about the Q OUTs being unconnected.  I even reverted to the before-I-touched-it-today version of c1lsc from the SVN, and it had the same problem.  So, that means that whomever put those in the LSC model did so, and then didn't check to see if the model would compile.  Not so good.

Anyhow, I just terminated them, to make it happy.  If those are actually supposed to go somewhere, whoever is in charge of LSC lockins should take a look at it.

Also, as Mirko mentioned in the previous elog 5811, we wanted to calculate the effect on the MC without actuating, so we put in a new summing point and a filterbank so we have testpoints.

LSC model recompiled.

OAF model recompiled.

FB restarted because of the new channels added to OAF.

5828   Mon Nov 7 11:50:42 2011 JenneUpdateelogRestarted elog

Elog restart script killed the elog, but didn't restart it.  Restarted by hand.

5830   Mon Nov 7 14:50:19 2011 JenneUpdateComputersISCEX is having a bad day

I clicked on the FE status screen, just to check on things, and everything on the c1iscex section was red (the IOP and c1scx).  Upon deciding that was probably a bad thing, I did a soft reboot from the control room.  Now the IOP says "NO SYNC", and the c1scx status thing is totally frozen.

I have sent Jamie a whiny email. He promises to be here soon to fix it.

5832   Mon Nov 7 15:15:21 2011 JenneUpdateLSCLSC model recompiled

 Quote: I moved the place where we take the OAF Degree of Freedom signals from - now it's the error point rather than the feedback for DARM, CARM, MICH, PRCL, SRCL, XARM and YARM.  I didn't do anything to MCL. While trying to compile, there was something wrong with the lockins that were there...it complained about the Q OUTs being unconnected.  I even reverted to the before-I-touched-it-today version of c1lsc from the SVN, and it had the same problem.  So, that means that whomever put those in the LSC model did so, and then didn't check to see if the model would compile.  Not so good. Anyhow, I just terminated them, to make it happy.  If those are actually supposed to go somewhere, whoever is in charge of LSC lockins should take a look at it. Also, as Mirko mentioned in the previous elog 5811, we wanted to calculate the effect on the MC without actuating, so we put in a new summing point and a filterbank so we have testpoints. LSC model recompiled. OAF model recompiled. FB restarted because of the new channels added to OAF.

After Rana pointed out the errors of our ways, we reverted all of these changes.

5835   Mon Nov 7 16:42:56 2011 JenneUpdateAdaptive FilteringBLRMS's to monitor OAF channels

I copied Mirko's PEM BLRMS block, and made it a library part.  I don't know where such things should live, so I just left it in isc/c1/models.  Probably it should move to cds/common/models.  To make the oaf compile, you have to put a link in /opt/rtcds/caltech/c1/core/branches/branch-2.1/src/epics/simLink , and point to wherever the model is living.

I then put BLRMSs on the control signals coming into the OAF, and after the Correction filter bank in the Adapt blocks, so we can check out what we're sending to the optics.

5848   Wed Nov 9 14:23:35 2011 JenneUpdateAdaptive FilteringOAF MC Delay Measurement

As described in elog 2063 and the mevans document, we need to measure the TF of the OAF's plant, to find the delay.

At DC, the phase is 2.5deg, and at 32Hz, the delay is -4.6Hz (extrapolated from the points at ~30deg and ~38deg).  The DTT file is in /users/Templates/OAF/OAF-MCL-Delay-9Nov2011.xml .

This gives a phase lag of 7.1deg at the Nyquist freq.

7.1 / 180 * 32 = 1.26, so ~1 cycle delay.  Not so much.  The new ADCs are waaaay faster than the old 110Bs.  Yay!

5853   Wed Nov 9 17:41:17 2011 JenneUpdateComputersETMX restored

Jamie did computer magic.  I burt restored scxepics, and restored ETMX damping.

5861   Thu Nov 10 11:52:00 2011 JenneUpdateCDSRFM signal transferring

I am not so happy with the control signals that are coming into the OAF via the RFM/Dolphin/shmem.

The MCL/MCF signal travels via RFM from the IOO computer to the RFM model on the SUS computer, and then via dolphin to the OAF model on the LSC computer.

The MICH and PRCL signals travel via shmem from the LSC model to the OAF model, all on the LSC computer.  They don't go through the RFM model.

The seismometer channels travel via shmem between the PEM model on the SUS computer and the RFM model on the SUS computer, and then via dolphin between the SUS computer and the OAF model on the LSC computer.

Each pdf shows the power spectrum and a time series of the signals in their "original" model, and in the OAF model.  The seismometer is the only one that seems fine.  The time series match, except for a delay which is not surprising, since the signals have to travel.  The other signals seem pretty distorted.  What is going on??? Why can we trust some, but not all, of the signals that move between models and between computers???

(This data was all taken while the MC was locked, but MICH and PRCL were not.  I don't think this should have any effect on the signal transfer though).

The MCL isn't soooo bad, so maybe we can keep moving forward with it, but I'm concerned that we're not really going to be successful OAF-ing the other degrees of freedom if the signals are so distorted.

5862   Thu Nov 10 12:28:31 2011 JenneUpdateSUSMC2 is being a little wild...WFS to blame

Mirko and  Den are measuring MC_F, which they will report about later, but I noticed that MC2 is totally crazy right now.  It shouldn't matter that they are doing things (like unplugging the feedback to the PSL's PZT), because we actuate on the laser, not on the MC.  I disabled the MC autolocker before they started working.

Anyhow, somehow MC2 got kicked up (whatever, that happens), but it won't re-damp.  I think it's the WFS.  The yaw output from the WFS is truely crazy.

I have disabled the WFS output / ASC input on the MC SUS screens, and MC2 was then able to damp.  My disabling only the MC2 WFS input at first kicked up MC1 and 3, so I disabled all of the WFS stuff, and all 3 MC mirrors are again happy.

SURESH: FIX ME!  (signed, The WFS)

5865   Thu Nov 10 19:41:24 2011 JenneUpdateSUSMusings on SUS dewhitening, and MC ELP28's

The following will be a stream-of-consciousness, approximately chronological story of my last hour or so of looking at screens....

In the old OAF days, we used to bypass the analog dewhitening in the coil driver path, using the XYCOMS.  See, ex. elog 2548.

I began to wonder if we needed to do the same thing now.  I checked several optics, to see how the switching works.

For the whitening on the OSEM sensor input, FM1 is linked to the Contec binary I/O.  FM1 is the inverse whitening filter.  Turn it on, and the analog whitening is on (bit in the binary I/O screen turns red).  Turn it off, and the analog whitening is bypassed (bit in the binary I/O screen turns gray).  Good.  Makes sense.  Either way, the net transfer function is flat.

The dewhitening is not so simple.  In FM9 of the Coil Output filter bank, we have "SimDW", and in FM10, we have "InvDW".  Clicking SimDW on makes the bit in the binary I/O screen gray (off?), while clicking it off makes it red (on?).  Clicking InvDW does nothing to the I/O bits.  So.  I think that for dewhitening, the InvDW is always supposed to be on, and you either have Simulated DW, or analog DW enabled, so that either way your transfer function is flat.  Fine.  I don't know why we don't just tie the analog to the InvDW filter module, and delete the SimDW, but I'm sure there's a reason.

All optics have this setup, except MC1 and MC3.  They don't have the SimDW or InvDW filter modules.  Instead, in FM9 (which on all the other suspensions is SimDW, and controls the binary I/O) there is a 28Hz Elliptic Low Pass filter.  The only thing I can find about these is elog 1405 where Rana talks about implementing ELP28's in MC2.  But right now there is no ELP in the MC2 coil output filters.  So, if Rana's old elog is to be believed, we need to fix up the ELP28 situation.  But that elog was from a long time ago, so maybe things are different now?  If MC1 and MC3 need the SimDW and InvDW (why wouldn't they?) then the ELP28 needs to move to another filter module.  Because right now, when I click the ELP28's on and off, it changes bits in the binary I/O.  Which I don't think it should.  Maybe.  I don't really know.

Okay. So. Now we know where everything is, and which buttons do what.  Maybe not why, but at least what.

In the old world, Rob had lots and lots of trouble (elog 2027) with locking when the analog dewhitening was bypassed.  But right now, I think that all of the analog dewhitening filters are bypassed, for every single optic we have.  So.  Which way do we want things?  What's the new game plan.  What's going on??

\end{stream-of-consciousness}

5886   Mon Nov 14 12:16:41 2011 JenneUpdateComputersOAF model died for unknown reason

I am meditating on the OAF, and had it running and calculating things.  I had the outputs disabled so I could take reference traces in DTT, but the Adapt block was calculating for MCL.  At some point, all the numbers froze, and the CPU meter had gone up to ~256ms.  Usually it's around ~70 or so for the configuration I had (2 witness sensors and one degree of freedom enabled....no c-code calculations on any other signals).  The "alive" heartbeat was also frozen.

I ssh'ed into c1lsc, ran ./startc1oaf in the scripts directory, and it came back just fine.

Anyhow, I don't know why it got funny, but I wanted to record the event for posterity.  I'm back to OAFing now.

5918   Wed Nov 16 21:01:08 2011 JenneUpdateTreasureeom box

I made a super sweet new foam box for our EOM.  It's awesome, and should be reasonably easy to duplicate.  Check out the PHOTOS!

Notes:

* I didn't think I was going to cover the inside of the box at first, since the foam is non-fuzz-generating, but Koji suggested it would be a good idea anyway.  The foam was cut perfectly to the EOM, so adding the tape inside makes it a tight fit.  Especially height-wise...leave a little space next time.

* To cover the insides of the optical path holes, do it in 2 parts.  One half-cylinder, and then another.  Way easier than trying to do the whole thing at once.  Also, pre-cut the tabs on both sides of the foil before inserting.  Then you just have to grab the tabs with tweezers and flatten them, and they hold the aluminum tape in place.

* Having 1" wide, 2" wide and 3" wide aluminum tape was handy.  3" to make the top, 2" for the sides, and 1" for the inside of the holes.

5921   Thu Nov 17 11:04:02 2011 JenneUpdateRF SystemStochmon?

Is there an update on Stochmon?  Are the signals acquired somewhere already?  What's the current deal-io?  The new EOM mount should be here later today, and I'm jazzed to start checking how my EOM box helps (hopefully) the amount of RFAM we see.

I'll start making the adapter plate while I wait...

5922   Thu Nov 17 11:27:58 2011 JenneUpdatePSLHEPA turned down

I was measuring things to see how big my adapter plate needs to be, and I decided that we'd had enough days of the HEPA being on full blast, so I turned it down to 50, from 100.  I think it's been on full since Katrin was working on the Y-green beat a week or so ago.

5924   Thu Nov 17 11:51:14 2011 JenneUpdateEnvironmentIncandescent vs. fluorescent lights?

I'm just on an elog roll this morning...

Again while poking around inside the IFO room, I noticed that they have replaced all of our incandescent lights with CFLs.  Do we care?  The point of having the incandescent lights on a separate switch from the big fluorescent lights was so that we could have only 60Hz lines, not wide-band noise if we want the lights on while locking.

I'm not sure that we actually care, because more often we just turn off all the lights while trying to do serious locking, but if we do care, then someone needs to ask the custodial staff (or someone else?) to undo the change.

5951   Fri Nov 18 19:07:07 2011 JenneUpdateRF SystemFoam house on EOM

[Jenne, Zach, Frank]

Frank helped Zach and I cable up at PT-100 RTD, and make sure it worked with the Newport Model 6000 Laser Diode Controller.  We're using this rather than the Newport 3040 Temperature Controller because Dmass says the output of that isn't working.  So we're using just the temp control part of the Laser Diode controller.

The back of the controller has a 15-pin D-sub, with the following useful connections.  All others were left Not Connected.

1 & 2 (same) - Pin 2 is one side of TEC output (we have it connected to one side of a resistive heater)

3 & 4 (same) - Pin 4 is the other side of the TEC output (connected to the other side of the resistive heater)

7 - connected to one side of PT-100 temp sensor

8 - connected to other side of PT-100 temp sensor

I used aluminum tape to attach the sensor and heater to the 40m's EOM, and we plugged in the controller.  It seems to be kind of working.  Zach figured out the GPIB output stuff, so we can talk to it remotely.

5966   Mon Nov 21 12:48:00 2011 JenneUpdateIOORFAM monitoring test

I don't think I touched/adjusted/whatever anything, but I did open the PSL table ~5-10min ago to measure the size of the Kiwamu-Box, so if the RFAM stuff looks funny for a few minutes, it was probably me.  Just FYI.

5967   Mon Nov 21 14:15:25 2011 JenneUpdateIOORFAM monitoring test

 Quote: DO NOT CHANGE THE IFO ALIGNMENT UNTIL TOMORROW MORNING OR FURTHER NOTICE.

[Mirko,  Jenne]

We're playing with the MC OAF, so we're actuating on MC2.  Again, FYI.

5977   Tue Nov 22 14:39:50 2011 JenneUpdateelogAfternoon elog restart

Gave the elog its afternoon / tea-time reboot, since it was hanging yet again.

5988   Wed Nov 23 14:47:14 2011 JenneConfigurationEnvironmentAC in the IFO room was off

I turned it back on, maybe around 11am?  Definitely a little while before the 12:30 meeting.

EDIT by KI:

Sorry, it's me. I was checking if AC was doing something bad on the ALS noise.

5997   Thu Nov 24 10:27:07 2011 JenneUpdateIOORFAMPD channels / EOM monitor channels added to DAQ

Here is a drawing of where the monitors are coming from:

Since we can't put current into the ADC, the heater drivemon is measuring the input of the OP27, which is related to the amount of current sent to the heater.

 Quote: EOM TEMPMON and HEATER DRIVEMON have been hooked up to the the following channels. C1:IOO-EOM_TEMPMON C1:IOO-EOM_HEATER_DRIVEMON

6022   Mon Nov 28 14:27:35 2011 JenneUpdateRF SystemEOM temp driver

Here is 5 days of trend of the EOM temp sensor and the heater driver monitor.  Unfortunately, it looks like we're regularly railing the heater.  Not so awesome.

6030   Mon Nov 28 19:24:51 2011 JenneUpdateCDSBeware of fancy filter modules

[Rana, Jenne]

Some of the funniness is some kind of mysterious interaction between 2 filter modules in the filter banks.  Just FM1 (30:0.0) or just FM4 (Cheby, which is 2 cheby1's) has reasonable coherence.  Both FM1 and FM4 together doesn't do so well - the coherence goes way down.

Just FM1 (30:0.0)

Just FM4 (Cheby)

Both FM1 and FM4

All the coherences plotted together

You'd think that the signal encounters FM1, gets filtered, and that result is the signal sent to the next active filter module, FM4, so the 2 filter modules shouldn't interact.  But clearly there's some funny business here since engaging both makes things crappy.

Matlab investigations to replicate this behavior offline are in progress.

6048   Wed Nov 30 01:35:49 2011 JenneUpdateCDSOSEM noise / nullstream and what does it mean for satellites

I'm picking points off of this no-magnet OSEM plot, and I thought I'd write them down somewhere so I don't have to do it again when I lose my sticky note...

1e-2 Hz        1.05e-2 um/rtHz

1e-1 Hz        3.4e-3 um/rtHz

1 Hz            1.3e-3 um/rtHz

10 Hz          2.5e-4 um/rtHz

60 Hz          7.5e-5 um/rtHz

100 Hz        7e-5 um/rtHz

400 Hz        7e-5 um/rtHz

6054   Wed Nov 30 14:12:53 2011 JenneUpdateRF SystemNew EOM mount almost ready

The new EOM adapter plate and riser just got back from the shop.  I just had Mike do the milling, and I'll drill and tap them tomorrow after the TAC.  Then we can remount the EOM to see if stiffening the mount helps at all.

6056   Thu Dec 1 01:24:56 2011 JenneUpdateRF SystemEOM temp stabilization at PSL lab

[Frank, Jenne]

Activities in a far, far away land called PSL lab...

We are looking at the RFAM from the detuned ACAV refl pd in the red trace.  Red trace is the demodulated RFAM output.  RCAV was locked, so on a ~min time scale the freq drift follows, so we stay detuned.

Heater and temp sensor are taped to EOM, no foam box.

Around when the red trace starts, we turn on the heater to stabilize the temp.  After a while we reach the set point (no longer railing the heater), and start seeing temp stabilization.  The RFAM fluctuations clearly go down.  Neato.

No calibrations, no RIN, no nothing.  Get over it.

Green trace is the DC level of a different PD, which should also be sensitive to RFAM.

This is using a fancy-pants temp controller chip that Frank found.  It works, so that's handy.

6070   Mon Dec 5 10:13:13 2011 JenneUpdateAdaptive FilteringC1OAF

 Quote: I've added filter banks for correction path in the C1OAF model to use AA filters.  I compiled and installed the new version. I runs but does not sync. Probably, I've made a mistake in the some names of epics channels. Leave it for now, figure out tomorrow. If someone needs an old version, it is in the /opt/rtcds/caltech/c1/userapps/trunk/isc/c1/models/c1oaf_BACKUP20111204.mdl file. Corresponding medm screen is in the /opt/rtcds/caltech/c1/userapps/trunk/isc/common/medm/OAF_OVERVIEW.adl file.

The general rule in the 40m is that if it's not an 'emergency', i.e. something is wrong with the computers and preventing the main locking work, no model recompiling-type activities at nighttime.

Also, if you do things and recompile, you need to do an svn check-in.  That's where backups are kept.  We don't want to clutter folders with backups anymore.

6073   Mon Dec 5 19:38:38 2011 JenneUpdateRF SystemEOM mount getting closer....

I have drilled all the holes necessary, and have tapped all but 4 of the holes for the new EOM mount.  The adapter plate is finished and ready to go (including a 10-min iso sonic bath).  The riser that goes between the table and the 9082 mount is drilled but not yet tapped.

6077   Tue Dec 6 21:37:08 2011 JenneUpdateRF SystemNew EOM mount in place

EOM is remounted on the fancy-pants new mount that I crafted.  EOM is also aligned.  2 green mirrors (the first ones to see the beams coming onto the PSL table from the arm transmissions) had to be moved so I could fit the mount in, since the new mount is bigger than the old one.  I put them back, and approximately realigned them, but didn't do any fine alignment.  This must be done before looking at beatnotes again.

After playing with the EOM, the MC was flashing on higher order modes.  The PSL beam has been realigned to make the MC lock on TEM00, and Suresh helped me center on the WFS and MC2T.

Things look okay for now.  Next step:  Kiwamu needs to find his happy mode cleaner place, and we'll realign the PSL beam to the MC.  The PSL-MC axes were mismatched pretty badly according to Suresh anyway, so this had to be done no matter what.

6082   Wed Dec 7 18:47:36 2011 JenneUpdateRF SystemRAM Mon is now being demodulated

There were 2 open outputs on the splitter in the RAMmon (formerly known as Stochmon) box underneath the BS oplev table.  The input to the splitter comes from the Thorlabs PD that we're using as our RAM monitoring PD.  2 of the outputs go to the RMS detection of 11 and 55 MHz.  Now the other 2 (previously terminated) outputs go over to the LSC rack via SMA cable.  The signal on both channels is ~200mV pk-pk, so -10dBm.  One is plugged into the AS11 demod board (which didn't have a PD input yet), and the other goes to POP55's demod board, so POP55 is not what you think it is for now.

Koji is working on checking out the Rich box, which has 4 demodulators, which we will use eventually.  Right now we're just using the already-plugged-in demod boards so we can start looking at some trends of RAM.  We're going to need to find some channels when we're ready for the switchover.

Zach is nearing completion of the mini-update to the temp sensing system.  Once we have the new more sensitive temp sensor in place, we can have a look-see at the similarities between EOM temperature and RAM levels.

6089   Thu Dec 8 14:47:28 2011 JenneUpdateIOOEOM aligned to minimize RAM

 Quote: Monitoring good, but remember that the EOM alignment must be done carefully to minimize the RAM before we can use these trends.

I temporarily diverted the output of the RAMmon PD to a spectrum analyzer (4195 in Spectrum Analyzer mode), and tweaked the EOM alignment until I minimized the 11 and 55 MHz peaks as much as possible.  It was possible to get each individual peak to disappear into the noise (about -70dBm), but to get both minimized simultaneously I wasn't able to get both down into the noise.  I left the 11MHz at about -55dBm, and the 55MHz at about -60dBm.  If Kiwamu's simulation tells us that one is more significant than the other (55, because we use it for MICH?), then we can decide to favor putting that peak in the noise and sacrifice ~10dB in the other peak.

When I first plugged the PD into the analyzer, I saw 22MHz and 44MHz (small) peaks, but they went away after the first bit of tweaking.

Before having used the analyzer, I was trying to minimize the demodulated signals via StripTool, but that was a slow process.  The spectrum analyzer was obviously much faster.

The PD has been returned to the regular RAMmon electronics.

Next up: putting in the new demod box that Koji tested last night.

6090   Thu Dec 8 16:54:05 2011 JenneUpdateRF SystemInstallation of new demod box

So far:

* New demod box has been placed in the LSC rack.

* An extra set of +\- 24V has been prepared at the terminal block where all the Crates get their power on the LSC rack.  The grounds were all connected up, but the hot wires weren't.  So there were extra spots available, but none that were pre-wired with my voltages.

* To do this I turned off all the power supplies in the short rack, since I decided to be a live chicken rather than a dead duck.  After hooking up the new terminal block slots, I turned on the power supplies.

* Make a power cable to go from the terminal block to the box

Still to do:

* Connect the spare 55MHz LO and the POP (or POX or POY) unused 11MHz LO to the back of the box

* Move the PD inputs to the new demod box rather than the borrowed AS11 and POP55 boards

* Plug the I & Q outs for each freq into some spare ADC channels - must first make sure we have 4 open channels.

* See if it works.

ELOG V3.1.3-