40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 290 of 344  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  4988   Tue Jul 19 10:18:24 2011 ranaUpdateLSCBig ol' mess

Remember, as per our marker board conversation, that the resistor noise as excitation method only works if the gain of all of the channels is set to something high (like 45 dB).

At 0 dB, the resistor noise is only 30 nV/rHz, whereas the ADC noise is more like 10000 nV/rHz...

  4991   Tue Jul 19 20:36:08 2011 ranaUpdateComputersVirtualBox + Windows 7 on rossa

I installed Virtual Box on rossa. Then I put Windows 7 in there and am now installing Altium.

You can run Windows on rossa by just clicking Applications -> System Tools -> Virtual Box.

  5004   Wed Jul 20 19:24:12 2011 ranaUpdateSUSoplev gains today

I guess Valera forgot to elog it. Steve, please email him and get the info.

I started to check out the OL servos today so that our whole interferometer is not too floppy.

  • The ETMX OPLEV DAQ channels were not in the list. Jamie ran the activateDQ.py script and it came back. Right now, we have no diagnostics to know if people have run this or not so the frames will have missing data now and again depending on how forgetful the rebooters are. Perhaps we can get activateDQ put into the make file???
  • I turned ON all of the offset buttons on the OL1, etc. filter banks. This allows for the dark offsets to be set for the OL quadrants. With these buttons off it doesn't make any sense.
  • I noticed that there are white (INVALID) fields all over the OPTLEV_SERVO screens. This is just because the new SUS models have not captured all of the functionality of the old system. Needs fixing.


Some of these OL spectra are not like the others...


  5023   Sun Jul 24 20:47:21 2011 ranaSummaryElectronicsAA filter tolerance analysis

This is sort of OK, except the capacitor connects across the (+) terminals of the two input opamps, and does not connect to ground.

Also, we don't care about the CMRR at 64 kHz. We care about it at up to 10 kHz, but not above. The sample frequency of the ADC is 64 kHz, but all of the models run at 16 kHz or less, so the Nyquist frequency is 8 kHz.

And doesn't the value depend on the resistors?

  5025   Mon Jul 25 00:35:44 2011 ranaUpdateSUSsomething wrong with ETMY LR sensor


Looks like either the LR OSEM is totally mis adjusted in its holder or the whitening eletronics are broken.

Also looks like the ETMY is just not damped at 1 Hz? How can this be?

I look at the SUS_SUMMARY screen which apparently only Steve and I look at:


Looks like the suspensions have factor of 10-100 different gains. Why?

**  The ETMY just doesn't behave correctly when I bias it. Both pitch and yaw seem to make it do yaw. I leave this for Jamie to debug in the morning.

***  Also, the BIAS buttons are still broken - the HOPR/LOPR limits ought to be 5000 and the default slider increment be 100. Also the YAW button readback doesn't correctly show the state of the BIAS.

****  And.....we have also lost the DAQ channels that used to be associated with the _IN1 of the SUSPOS/PIT/YAW filter modules. Please put them back; our templates don't work without them.

  5058   Thu Jul 28 21:52:40 2011 ranaUpdateComputersanother attempt to use pianosa
  1. Pianosa doesn't cache the SVN pwds so you need to re-enter at each SVN up or commit. This is different from the rest of our workstations. We need to determine what behavior we want.
  2. Tried to use the netGPIB scripts:

pianosa:gpib 0> ./readSR785.csh rb2
netgpibdata.py: Command not found.

  5065   Sat Jul 30 02:47:43 2011 ranaUpdatePSLABSL Laser crystal temp left largely excited & left unattended for more than 3hours

 Hmm. Should have only been +/- 1 GHz. Some setting got changed apparently...

This is a part of the RefCav temperature measurement setup. You'll get an elog from Jenny very soon.

  5072   Sat Jul 30 20:41:50 2011 ranaUpdatePSLRefCav Stabilization back on


I turned the RefCav heater and servo back on a couple days ago. At first it was stabilizing again at a low setpoint, but in reality the right temperature (~40 C). After fixing the in-loop signal offsets, the setpoint now correctly reflects the actual temperature.

Jenny is going to calibrate the sensors using some kind of dunking cannister next week.

  5081   Mon Aug 1 11:46:56 2011 ranaSummaryLSCTolerance of Arm length = 2 cm

wow. This Monte-Carlo matrix is one of the most advanced optical modeling things I have ever seen. We never had this for any of the interferometers before.

  5095   Tue Aug 2 16:55:21 2011 ranaUpdateABSLArm length measurement : cavity kick technique


I made some attempts to measure the current length of the arm cavities by using the mass-kicking technique.

 Why not just scan the Green laser to measure the arm lengths instead? The FSR of the arm is ~3.75 MHz and so all you have to do is lock the arm green and then sweep the PZT until the resonance is found at 3.75 MHz.


  5118   Thu Aug 4 11:18:12 2011 ranaUpdateSUSsus at atm

Remember that the Oplevs are not good references because of the temperature sensitivity. The week long trend shows lots of 24 hour fluctuations.

  5131   Sat Aug 6 13:38:02 2011 ranaSummaryGeneralSummary of today's in-vacuum work

This OSEM placement is just the OPPOSITE of what the proper placement is.

Usually, we want to put them in so that the LED beam is vertical. This makes the OSEM immune to the optic's vertical mode.

The orientation with the horizontal LED beam makes the immunity to the side mode better, but may spoil the vertical.

In reality, neither of these assumptions is quite right. The LED beam doesn't come out straight. That's why Osamu and I found that we have to put in some custom orientations.

Also, the magnet gluings relative to the OSEM bracket centers are not perfectly aligned. So...I am saying that the OSEMs have to be oriented empirically to reduce the couplings which we want to reduce.


  5136   Mon Aug 8 00:12:58 2011 ranaUpdateCDSdiagonalization of MC input matrix

I've finally completed the SUS/peakFit/ scripts which find the new input matrix for the SUS. MC1, MC2, MC3, and ITMX have been matrix'd.

I tried to do the BS, but it came out with very funny matrix elements. Also the BS is missing its DAQ channels again (JAMIE !) so we can't diagnose it with the free swinging method.

To continue, we have to get some good data and try this again. Right now there are some weird issues with a lot of the optics. I've also set the damping gains for the optics with the new matrices.


new_matrix = findMatrix('ITMX')

writeSUSinmat('ITMX', new_matrix)


this script writes the values to the MEDM input SUS matrix. To do the writing, I used the low level 'caput' command instead of ezcawrite since the ezca libraries are getting deprecated.

caput doesn't really have good diagnostics, so I use matlab to check the return status and then display to the terminal. You can just rerun it if it gives you an error.



A coupled of normalization notes:

1) The POS/PIT/YAW rows are scaled so that the mean of abs(FACE elements) = 1. Previously, I had the max element = 1.

2) The SIDE row is scaled so that the SIDE element = +1.

3) I then normalized the ROWS according to the geometrical factors that Jamie has calculated and almost put into the elog.


All these scripts have been added to the SVN. I've removed the large binary data files from the directory though. You can just rsync them in to your laptop if you want to run this stuff remotely.

  5137   Mon Aug 8 00:58:26 2011 ranaUpdateCDSdiagonalization of MC input matrix

Besides the purpose of correctly tuning the suspensions, my hidden goal in the input matrix diagonalization has been to figure out what the 'true' sensing noise of the OSEMs is so that we can accurately predict the noise impact on the OAF.

The attached plot shows the DOFs of ITMX calibrated into microns or microrad as per Jamie's ethereal input matrix calculations.

The main result is in the ratio of POS to BUTTER. It tells us that even at nighttime (when this data was taken) we should be able to get some reduction in the arms at 1 Hz.

Whether we can get anything down to 0.1 Hz depends on how the arm control signal compares to the POS signal here. I leave it to Jenne to overlay those traces using a recent Arm lock.

Attachment 1: null.png
  5138   Mon Aug 8 12:08:05 2011 ranaUpdateSUSsus at atm


A plot showing that the daily variation in the OLs is sometimes almost as much as the full scale readout (-1 to +1).

  5174   Wed Aug 10 14:35:39 2011 ranaUpdatePEMCalibration of Guralp and STS2

I'm pretty sure that don't have any ADC's with this gain. It should be +/- 10V for 16 bits. 

  5180   Wed Aug 10 22:47:22 2011 ranaSummaryVACVacuum Workstation (linux3) re-activated

For some reason the workstation at the vac rack was off and unplugged. Nicole and I plugged its power back in to the EX rack.

I turned it on and it booted up fine; its not dead. To get it on to the network I just made the conversion from 131.215 to 192.168 that Joe had done on all the other computers several months ago.

Now it is showing the Vacuum overview screen correctly again and so Steve no longer has to monopolize one of the Martian laptops over there.

  5312   Sat Aug 27 15:47:59 2011 ranaUpdateCDSOSEM noise / nullstream and what does it mean for satellites

In the previous elog of mine, I looked at the nullstream (aka butterfly mode) to find out if the intrinsic OSEM noise is limiting the displacement noise of the interferometer or possibly the Wiener FF performance.

The conclusion was that its not above ~0.2 Hz. Due to the fortuitous breaking of the ITMX magnet, we also have a chance to check the 'bright noise': what the noise is with no magnet to occlude the LED beam.

As expected, the noise spectra with no magnets is less than the calculated nullstream. The attached plot shows the comparison of the LL OSEM (all the bright spectra look basically alike) with the damped

optic spectra from 1 month week ago.

From 0.1 - 10 Hz, the motion is cleanly larger than the noise. Below ~0.2 Hz, its possible that the common mode rejection of the short cavity lengths are ruined by this. We should try to see if the low frequency

noise in the PRC/SRC is explainable with our current knowledge of seismicity and the 2-dimensional 2-poiint correllation functions of the ground.

So, the question is, "Should we try to upgrade the satellite boxes to improve the OSEM sensing noise?"

Attachment 1: Untitled.png
  5350   Tue Sep 6 22:51:53 2011 ranaSummaryCamerasAll Camera setups a need upgrading

I just tried to adjust the ETMY camera and its not very user friendly = NEEDS FIXING.

* Camera view is upside down.

* Camera lens is contacting the lexan viewport cover; this means the focus cannot be adjusted without misaligning the camera.

* There's no strain relief of the camera cables at the can. Needs a rubber cable grommet too.

* There's a BNC "T" in the cable line.

Probably similar issues with some of the other setups; they've had aluminum foil covers for too long. We'll have a camera committee meeting tomorrow to see how to proceed.

  5352   Wed Sep 7 00:39:34 2011 ranaUpdateSUSITMX adjustments

(What we did)

* Moved SUS to edge of table for OSEM adjustment.

* Leveled the table in this temporary tower position.

* Rotated all OSEMs to give some seperation between magnets and LED/PD packages.

* Moved the upper OSEM bracket a little bit upward.

* All the OSEM holding set screws were short with flat heads; this is annoying since we would like to use them more like thumbscrews. Steve took the long set-screws out of the old ITMX cage and we swapped them. Need to order ~100 silver-plated socket head spare/replacements.

* Took pictures of OSEMs.

* Moved tower back to old position.

* Releveled the table (added one rectangular weight in the NW corner of the table).

* Find that ITMX OSEMs were a couple 100 micron out of position; we adjusted them in-situ in the final position of the tower, trying not to rotate them. All mean voltages now are within 100 mV of ideal half-light.

* Back/front EQ positions adjusted by the screw method. bottom/top stops adjusted earlier.

* OSEM cables tied down with copper wire.

* Increased the incident power up to 91 mW going into MC to temporarily make the POX beam more visible.

* The POX beam was checked. It was exiting from the chamber and going through about the center of the viewport.

  5364   Wed Sep 7 22:17:04 2011 ranaUpdateIOORF Amp for EOM on PSL Table

After Steve pointed out the 'deep hoop' issue, we decided to examine putting an RF Amp on the PSL table, between the RF combiner and the triple resonant box.

This will reduce the chances of standing waves in the cables and reduce the radiation induced pick-up in the RF PD and Demod electronics.

We would like to send ~10 dBm from the distribution box to the combiner. We also want to able to get as much as ~33 dBm of drive at 11 and 55 MHz. So the amp should have a gain of ~20-30 dB and an operating range of 10-100 MHz.

Also desirable are low distortion (high IP3) and good reverse isolation ( > 40 dB).

Some possibilities so far (please add your RF Google Results here):

1) Mini-Circuits ZHL-1-2W-S:  G = +32 dB, Max Out = +33 dBm, NF = 6 dB, Directivity = 25 dB

2) Mini-Circuits TIA-1000-1R8:  G=+40 dB, Max Out = +36 dBm, NF = 15 dB   (AC Powered, Inst. Amp), Directivity = 58 dB.

3) Mini-Circuits ZHL-2-8: G = +27dB, Max out = +29 dBm, NF = 6dB, Directivity = 32 dB

4) RFbay MPA-10-40: G = +40dB, Max Out = + 30 dBm, NF = 3.3 dB, Rev Iso = 23 dB

5) No proper stuff from Teledyne Couger


  5372   Fri Sep 9 19:15:17 2011 ranaUpdateIOORF Amp for EOM on PSL Table


After Steve pointed out the 'deep hoop' issue, we decided to examine putting an RF Amp on the PSL table, between the RF combiner and the triple resonant box.

5) No proper stuff from Teledyne Couger


By looking at what Daniel used in the low noise EOM Driver for aLIGO, we found the A2CP2596 from Cougar.

G = +24 dB, NF = 5 dB, Max Out = +37 dBm. It comes in a 2-stage SMA connector package. I've asked Steve to order 2 of them with the appropriate heatsinks.

  5376   Sat Sep 10 11:07:37 2011 ranaHowToSUSOptical Lever Servo Tuning thoughts

Now that we are in a moderately stable condition, its time to design the optical lever feedback transfer functions. We should think carefully about how to do this optimally.

In the past, the feedback shape was velocity damping from 0-10 Hz, with some additional resonant gain around the pendulum and stack modes. There were some low pass filters above ~30 Hz. These were all hand tuned.

I propose that we should look into designing optimal feedback loops for the oplevs. In principle, we can do this by defining some optimal feedback cost function and then calculate the poles/zeros in matlab.

How to define the cost function (? please add more notes to this entry):

1) The ERROR signal should be reduced. We need to define a weight function for the ERROR signal: C_1(f) = W_1(f) * (ERR(f)^2)

2) The OL QPDs have a finite sensing noise, so there is no sense in suppressing the signal below this level. Need to determine what the sensing noise is.

3) The feedback signal at high frequencies (30 Hz < f < 300 Hz) should be low passed to prevent adding noise to the interferometer via the A2L coupling. It also doesn't help to reduce this below the level of the seismic noise. The cost function on the feedback should be weighted apprpriately given knowledge about the sensing noise of the OL, the seismic noise (including stack), and the interferometer noise (PRC, SRC, MICH, DARM).

4) The servo should be stable: even if there is a negligible effect on the ERROR signal, we would not want to have more than 10 dB of gain peaking around the UGFs.

5) The OL QPDs are dominated by drift of the stack, laser, etc. at some low frequencies. We should make sure the low frequency feedback is high passed appropriately.

6) Minimize transmitted power rms in single arm lock etc.

  5379   Sat Sep 10 18:52:45 2011 ranaUpdateComputersconlog getting filled up

One of the reasons that conlog seems so slow lately is that its been writing 100's of MB of .log files every day since early summer. It looks like the people who have been working on the mdl builds have not been properly adjusting the conlog channel lists. When this is not done conlog just gets filled up with non-control channels like OUT, OUTPUT, OUTMON, etc.

Peter Shawhan has supplied us with many scripts in the conlog directory to clean up these bloated files and fix the channel list.

  5381   Sat Sep 10 19:03:57 2011 ranaUpdateLSCY Arm work

I lined up the Y Arm for locking and then centered the oplevs for ETMY and ITMY.

* The ITMY OL has still got the old style laser. Steve, pleaes swap this one for a HeNe. Also the optical layout seems strange: there are two copies of the laser beam going into the chamber (??). Also, the QPD transimpedance needs to be increase by a factor of ~10. We're only getting ~500 counts per quadrant. Its worth it for someone to re-examine the whole ITMY OL beam layout.

* The ETMY OL beam was coming out but clipping on the mount for the ETMY OL HeNe. This indicates a failure on our part to do the ETMY closeout alignment properly. In fact, I get the feeling from looking around that we overlooked aligning the OL and IPPOS/ANG beams this time. If we're unlucky this could cause us to vent again. I undid part of the laser mount and changed the height on the receiving mirror to get the beam back onto the QPD.

I noticed that there is significant green light now getting into some of the IR PDs; beacuse of this there are weird offsets in the TRY QPD and perhaps elsewhere. We had better purchase some filters to tape over the front of the sensitive IR sensors to prevent the couplling from the green laser.

* There is a beam on IPPOS, but its too big for the detector (this has always been the case). We need to put a 2" lens with a weak focusing power on this path so as to halve the beam size on the detector. Right now its clipping and misleading. There is also a 0.9V offset on the SUM signal. I'm not sure if this readout is working at all.

* I couldn't find any beam on IPANG at all. Not sure what's changed since Kiwamu saw it.

  5383   Sat Sep 10 20:30:01 2011 ranaUpdateIOOMC trans re-aligned / MC2 shifted mysteriously / MC2 re-aligned


I re-aligned the beam onto the MC TRANS QPD since Kiwamu had centered the spots on the mirrors. However, I then inspected the MC2F camera. After coming back into the control room I noticed that the MC transmission had gone down by 50% and that the MC2 OSEMs showed a large step. My guess is that somehow the opening and closing of the can shifted the suspension. So I adjusted the MC2 alignment biases to recover the transmitted power (its now ~50000 instead of the ~33000 from Friday).

  5404   Wed Sep 14 12:01:05 2011 ranaUpdateAdaptive FilteringModifications to LSC, RFM models, added OAF model

For the acquisition of the MC_F channel, I suggest taking the FAST_MON BNC output from the blue FSS interface card in the Eurocard crate in the PSL rack. This can then be piped into the 2-pin LEMO plug (Ch. 1) of the Generic Pentek DAQ card which used to acquire the MC_L signal from the MC Servo Board.

  5409   Wed Sep 14 20:30:36 2011 ranaUpdateSUSSome screens are still bad

I've found that a few of the screens still have Whited-Out fields due to naming changes (OL SUM and ALS-> TM OFFSET). I attach a screen shot of it.

The OL screens have the wrong SUM names and the IFO ALIGN screen is pointing to the wrong SUS screens.


  5411   Wed Sep 14 22:07:41 2011 ranaUpdateSUSITM Oplevs are broken

I went to see what was wrong with the ITMs and found that people have been working on them and have left them in a broken state with no elog entry.

This is sad and unacceptable.

Whoever is working on these should post into the elog what the Oplev layout plan is, have someone check it, and ONLY THEN get to work on it.

The layout as it looks tonight is too complicated. With too many optics we will not have a low noise optical lever setup. The new layout should use a bare minimum number of optics and only use very stable mounts.


  5448   Sun Sep 18 14:08:52 2011 ranaUpdateSUSCalibration plan for the oplevs

We don't need a high quality calibration for the optical levers. ~50% accuracy is fine.

For that you can use the OSEM calibration of ~1.7 V/mm (its less than 2 since the OSEMs have been degrading) or you can use the cavity power method that Kakeru used; it worked just fine. There's no benefit in trying for a 1% number for optical levers.

  5466   Mon Sep 19 17:45:39 2011 ranaUpdateSUSSome screens fixed


Kiwamu:       The bad medm screens have been fixed. There are no blank fields and all the links are correct.

Quote from #5409

I've found that a few of the screens still have Whited-Out fields due to naming changes (OL SUM and ALS-> TM OFFSET). I attach a screen shot of it.

The OL screens have the wrong SUM names and the IFO ALIGN screen is pointing to the wrong SUS screens.


 Really? I found this one with ~15 seconds of clicking around.


  5467   Mon Sep 19 18:05:27 2011 ranaUpdateSUSSummary screen


I changed some colors on the Summary of Suspension Sensor  using my italian creativity.

I wrote a script in Python to change the thresholds for the "alarm mode" of the screen.

I've started to fix up the script somewhat (as a way to teach myself some more python):

* moved all of the SUS Summary screen scripts into SUS/SUS_SUMMARY/

* removed the hardcoded channel names (a list of 190 hand-typed names !!!!!!!)

* fixed it to use NDS2 instead of try to use the NDS2 protocol on fb:8088 (which is an NDS1 only machine)

* it was trying to set alarms for the SUS gains, WDs, Vmons, etc. using the same logic as the OSEM PD values. This is non-sensical. We'll need to make a different logic for each type of channel.

New script is called setSensors.py. There are also different scripts for each of the different kinds of fields (gains, sensors, vmons, etc.)

Some Examples:

pianosa:SUS_SUMMARY 0> ./setDogs.py 3 5
Done writing new values.


  5493   Wed Sep 21 00:34:29 2011 ranaUpdateSUSSUS diag stuff... just so I remember what I'm doing

ETMX was ringing up when it was mis-aligned for Y arm locking. I restored the input matrix to something more diagonal and its now damping again. Needs more work before we can use the calculated matrix.

  5494   Wed Sep 21 00:37:01 2011 ranaUpdateSUSITMY and SRM oplev calibrations - measured and estimated

I found that some of the Optical Lever Servos were ON today and injecting nonsense into the interferometer optics. I have set all of the gains = 0 to save us more headaches.

Please leave them OFF until we review the servo and noise characterization results in the elog.

  5500   Wed Sep 21 16:22:14 2011 ranaUpdateSUSSummary screen

The SUS SUMMARY screen is now fully activated. You should keep it open at all times as a diagnostic of the suspensions.

No matter how cool you think you are, you are probably doing something bad when trying to lock, measure any loop gains, set matrices, etc. Use the screen.


This is the link to the automatic snapshot of the SUS SUMMARY screen. You can use it to check the Suspensions status with your jPhone.

Auto SUS SUMMARY Snapshot

When the values go yellow its near the bad level. When its red, it means the optic is misaligned or not damped or has the wrong gain, etc.

So don't ignore it Steve! If you think the thresholds are set too low then change them to the appropriate level with the scripts is SUS/

  5503   Wed Sep 21 17:42:35 2011 ranaUpdateIOOAM modulation misery

I'd like to see some details about how to determine that the ratio of 1:50 is small enough for AM:PM.

* What have people achieved in past according to the elogs©  of the measurements?

* What do we expect the effect of 1:50 to be? How much offset does this make in the MICH/PRC/SRC loops? How much offset is too much?

Recall that we are using frontal modulation with a rather small Schnupp Asymmetry...

  5506   Wed Sep 21 21:13:35 2011 ranaUpdateIOOAM modulation misery

How about changing the x-axis of all these plots into meters or picometers and tell us how wide the PRC resonance is? (something similar to the arm cavity linewidth expression)

Also, there's the question of the relative AM/PM phase. I think you have to try out both I & Q in the sim. I think we expect Q to be the most effected by AM.

  5536   Sat Sep 24 01:51:02 2011 ranaUpdateSUSOplev filter optimization for 2 poles and 2 zeros


I have made a function to optimise the overall gain, pole frequencies and zero frequencies for the oplev filter. The script will optimize any user defined number of poles and zeros in order to minimise the RMS motion below a certain cut off frequency (in this case 20Hz). The overall gain is adjusted so that each trial filter shape always has a UGF of 10 Hz.

I think this is a nice start. Its clear that we don't want to use this feedback law, but the technique can be tweaked to do what we want by just tweaking our cost function.

Let's move the scripts into the SUS/ scripts area and then start putting in weights that do what we want:

1) Limit the gain peaking at the upper UGF to 6 dB.

2) Minimum phase margin of 45 deg.

3) Minimum gain margin of 10 dB.

4) Lower UGF = 0.1 Hz / Upper UGF = 10 Hz.

5) Assume a A2L coupling of 0.003 m/rad and constrain the injected noise at the test mass to be less than the seismic + thermal level.

6) Looser noise contraint above 50 Hz for the non TM loops.

  5596   Sun Oct 2 13:45:13 2011 ranaSummaryGeneralRecovery from the power shutdown: apache / svn

Restarted Apache on nodus using Yoichi's wiki instructions. SVN is back up.

  5641   Mon Oct 10 10:14:43 2011 ranaUpdateLSClength fluctuations in SRCL

 How does it make sense that the motion at 0.1 Hz of PRC is 10x larger than MICH?


 That's actually the point which I was wondering at. One possible reason is that my actuator responses are not so accurate below 1Hz.
I will measure the DC response of all the actuators and it will completely determine the shapes of the actuator responses except for the region around the resonance.
In the process of producing the plot I was assuming that all the actuator response have a 1 Hz resonance with Q of 5.
However in reality this assumption is not true because the resonant frequency is different in each actuator.
  5649   Tue Oct 11 15:14:50 2011 ranaUpdateLSCBS actuator reponse at low frequency : measured


The response of the BS actuator in a low frequency regime has been measured.


This seems like an error prone method for DC responses due to the loop gain uncertainty. Better may be to use the fringe hopping method (c.f. Luca Matone) or the fringe counting method

  5650   Tue Oct 11 15:19:17 2011 ranaHowToEnvironment40m map

The Kinemetrics dudes are going to visit us @ 1:45 tomorrow (Wednesday) to check out our stacks, seismos, etc.


I put these maps here on the elog since people are always getting lost trying to find the lab.

  5662   Thu Oct 13 21:40:59 2011 ranaSummaryVACRecovery from the power shutdown is completed

 As it turns out Steve is not crazy in this particular instance: the vacuum computer, linux3 , has some issues. I can login just fine, but trying to open a terminal makes the CPU rail and the RAM max out and eventually the machine freezes.

Under KDE, I can open a terminal OK as root, but if I then try a 'su controls', the same issue happens. Let's wait for Jamie to fix this.

  5669   Sat Oct 15 10:58:32 2011 ranaUpdateIOOMC WFS Output Matrix determination

In order to save time and sanity, you should not measure the pitch ->yaw and yaw-> pitch. It makes things too complicated and so far is just not significant. In the past we do not use these for the matrix work.

i.e. there should just be a 3x3 pitch matrix and a 3x3 yaw matrix. Once the loops are working we could investigate these things, but its really a very fine tweak at the end. There are quite a few other, more significant effects to handle before then.

To make things faster, I think we can just make a LOCKIN which has 3 inputs: it would have one oscillator, but 6 mixers. Should be simple to make.

  5673   Sun Oct 16 02:30:00 2011 ranaUpdateElectronicsTesting REFL165

Unless the bias feedback circuit has been tuned for the 1 mm diode, its possible that you are seeing some C(V) effects. Its easy to check by looking at the phase response at 165 MHz v. the DC photocurrent. Then the feedback or feedforward gain can be tuned.


  5674   Sun Oct 16 05:35:18 2011 ranaUpdateComputer Scripts / ProgramsFailing to set SUS summary screen values



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

 Doesn't work on pianosa either. Has someone changed the python environment?

pianosa:SUS_SUMMARY 0> ./setSensors.py 1000123215 600 0.1 0.25
Traceback (most recent call last):
  File "./setSensors.py", line 2, in <module>
    import nds
ImportError: No module named nds

  5682   Mon Oct 17 23:28:32 2011 ranaUpdateElectronicsStochMon

To get to the bottom of the RFAM mystery, we've got to resurrect the StochMon to trend the RFAM after the IMC.

We will put an 1811 on the MC_TRANS or IP_POS beam (the 1811 has an input noise of 2.5 pW/rHz).

Then the Stochmon has an input pre-amp, some crappy filters, and then Wenzel RMS->DC converters. We will replace the hand-made filters with the following ones from Mini-Circuits which happen to match our modulation frequencies perfectly:

11 MHz     SBP-10.7+

55 MHz     SBP-60+

29.5 MHz   SBP-30+

  5688   Tue Oct 18 21:19:18 2011 ranaConfigurationIOOWFS disabled in SUS

I found that the MC WFS had large offset control signals going to the MC SUS. Even though the input switch was off, the integrators were holding the offset.

I have disabled the ASCPIT outputs in the MC SUS. Suresh is going to fix the MC autolocker script to gracefully handle the OFF and ON and then test the script before resuming the WFS testing.

MCL data for OAF may be suspect from this morning.

  5748   Fri Oct 28 00:53:39 2011 ranaUpdateElectronicsPOP 22/110 Design

The attached PDF shows a possible gain / input noise config for the POP 22/110 that we would use to detect the RF power in the DRMI. Design is in the SVN.

If Kiwamu/Jenne say that this has good enough sensing noise for the lock triggering than we will build it. This is using a 2mm diode.

If we can get away with 1 mm, we might as well use a PDA10CF for now.

Attachment 1: poy22110.pdf
poy22110.pdf poy22110.pdf
  5764   Sun Oct 30 14:08:35 2011 ranaUpdateElectronicsRFAM monitor in place. ( Uncalibrated ) EPICS troubles


{Suresh, Jamie, Mirko]

We adapted the Stochmon box to include LP filters at 1.8Hz behind the RMS parts.
Then measured the RMS signals for different RF signal levels at 11.0.65, 29.5, 55.325MHz provided by a RF freq. generator.
As you can see in the data below the suppression of the BP filters of neighboring frequencies is only 35-35dB in power (see also manufacturer specs).

We therefor want to substract crosstalk, by calculating it out. We decided to use C-code in CDS. No computer crashing this time :)

 This is neat idea, but it seems like it would be easier to just add another set of rf BP filters inside of the StochMon box. Luckily, Steve was thinking ahead and ordered extra filters.

ELOG V3.1.3-