40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 289 of 344  Not logged in ELOG logo
ID Date Authorup Type Category Subject
  4647   Thu May 5 18:38:01 2011 ranaSummaryCDSSub-system TRAMP adjustments

I think that the gain ramping time (_TRAMP) should be set to 1 second for all filter modules by default. We don't want them to switch instantaneously except in a few special cases.

So Jamie and I wrote a script (in scripts/general/) which sets all of these fields to 1 for a given system. The name of the system is an argument to the script. e.g.

>  setTRAMP LSC 1

The idea is that we set it once and then from then on, its captured by the autoBURT. Of course, we have to run this script each time we add new filter modules to a model.

  4661   Sun May 8 17:29:01 2011 ranaUpdateIOOMC beam spot centering

It seems like the best option would be to make the MCASS just adjust the SUS biases and center the beams on the suspended optics. Is this not possible somehow?

  4662   Sun May 8 22:59:40 2011 ranaUpdatePSLPSL reference cavity temperature box modifications

I looked at the PSL temperature box. It started out as D980400-B-C. Then it was revised by Peter King as per the LHO mods E020247.

There are some more things to do to it to make it useful for us:

  1. R3, 4, 7, 8, 12, & 13 should be changed from 1k to 0 Ohms, I think. I cannot figure out their purpose.
  2. All resistors should be made metal-film. Right now, its kind of a mish-mash.
  3. The active filter U6B has a corner frequency of ~50 Hz. This seems not useful for keeping the 4116 DAC noise out of the temperature. We should lower this to ~30 mHz to take advantage of the stability of the LT1021 which was put in.

** Frank reminds me that we don't use the TIdal or VME external inputs anymore since we moved to the EPICS/Perl PID control. So all we have to do is make sure these inputs are hardware disabled/disconnected.

  4672   Mon May 9 20:30:20 2011 ranaUpdatePSLPSL reference cavity temperature box modifications

I re-installed the box (@ ~8:15) after reflowing some of the solder joints. I will observe it over night and then remove the 1K resistors. Attached is a 8 hour minute-trend.

  4681   Tue May 10 20:57:05 2011 ranaUpdatePSLPSL reference cavity temperature box modifications : after 24 hours still OK

Quote:

I re-installed the box (@ ~8:15) after reflowing some of the solder joints. I will observe it over night and then remove the 1K resistors. Attached is a 8 hour minute-trend.

 I compared this 24 hour trend with the one from this day exactly one year ago. Seems the same, so now I can make the resistor change.

  4693   Wed May 11 21:58:30 2011 ranaUpdateSUSETMX_OPLEV : He-Ne replaced

Quote:

Quote:

I found that a He-Ne laser which has been used for ETMX_OPLEV was NOT giving the light.

Since I didn't find the switch key for it I have no idea if the laser is simply off or dead.

 The dead laser was replaced by new JDSU 1104P of  2.6mW. The return beam is big ~5 mm diameter of 0.3 mW,  1400 counts

 Whenever replacing any Oplev laser, please also put into the ELOG when it was installed so that we have an electronic record of the laser lifetime.

  4702   Thu May 12 10:27:02 2011 ranaUpdateRF Systeminstallation of RF splitters in Demod boards

Quote:

Rana also advised that we must use the boards which have the piggy-back amplifiers on those signals which are most useful.  We referred to Alberto's thesis and chose POY55 (MICH and SRCL), REFL11(PRCL)  and AS55 (DARM) as the most useful signals.  We currently have these amps on AS11, REFL11 and AS55.  We need to convert either AS11 or REFL11 into a POY55.  Since we need to troubleshoot REFL11, I thought we might as well modify that and in the process also fix its Q output.  So I renamed AS11 as REFL11 and will convert the old REFL11 into POY55 tomorrow. 

 I think we should leave them as is; the AS11 was made by taking into account the SB levels at the AS port and should not become REFL11. We should instead convert one of the old 25 or 33 MHz diodes into a POY55.

  4705   Thu May 12 22:54:20 2011 ranaUpdateDAQInput Beam Naming change (no more IP)

 We decided to rename the Input Beam channels (while keeping temporary backwards compatible aliases) as:

C1:ASC-IB_POS_X, C1:ASC-IB_POS_Y, C1:ASC-IB_ANG_SUM, etc.

  4707   Thu May 12 23:41:47 2011 ranaUpdateCDSMEDM Snapshots not working

Looks like 2 different MEDM Snapshot functiions (at least) are broken.

The regular update of the screens here as well as the usual "Update Snapshot" and view "previous snapshot" button on all of the auto-generated screens.

Also, how do we add the snapshot button to the custom made screens?

  4718   Sun May 15 03:58:19 2011 ranaUpdateCDSdiagonalization of MC input matrix

There has been some input matrix diagonalization in the past by Yuta and Kiwamu, but I find the automation to be not totally satisfactory.

It would be better if we could automatically fit the data to find the Suspended optic eigenfrequencies and then use that to get the matrix. So I wrote a peak fitter to get the matrix.

It gets the data from mafalda with NDS2, then it makes the PSDs, and then starts with some initial guesses (based on looking at the plots) and them uses fminsearch to get the peak frequencies and Q's.

Using the output of this, we can use Yuta's method and take the passive transfer functions with the free swing data (from April 30, so we got do do it quick) to get the input matrix.

 

Doing the SUS input matrix is nice for having good damping (as long as we remember to include SIDE), but my motivation is to produce a good null stream from the 4 face sensors so that we can estimate the sensor noises at all times.

  4725   Mon May 16 11:14:36 2011 ranaUpdateIOOwiring diagram for IP-POS

Just FYI, the 3113 is a 12-bit ADC, so we won't get very good resolution out of these. We should get one of those purple boxes.

Also, I corresponded some with Dave Barker. The 40m Wiki at LHO is down because of disk errors. He's working on it and will let us know. But suggests that we move it to Caltech since he'll turn the box off at the end of the year.

Mon May 16 13:57:49 2011    Wiki is back up.

  4743   Wed May 18 22:11:31 2011 ranaConfigurationLSCNew digital lockin added to LSC model/screen

Untitled.png

 This is OK....but, the input matrix should come from the same place as the regular input matrix: i.e. it should be just another row like CARM, DARM, etc. rather than have its own screen.

Also, I think a nice mod to all the matrices would be if the ORANGE triangle was only visible when there's a signal flowing through it.

  4745   Thu May 19 00:22:21 2011 ranaUpdateelogRestarted, Italian-style

Quote:

Aka, from a hotel in Pisa.

 Restarted Thu May 19 00:21:49 2011 to recover from Jenne's Italian terrorism.

  4746   Thu May 19 00:23:44 2011 ranaUpdateCDSdiagonalization of MC input matrix

 I've moved all of my SOS peak fitting stuff into the scripts area so that Leo can make it better:

/cvs/cds/rtcds/caltech/c1/scripts/SUS/peakFit

findPeaks.m gets the data and makes the fitted spectra that I put in the previous entry.

findMatrix.m is the barely started script that ought to take the TF data and output the matrix to the MEDM screen.

  4786   Mon Jun 6 02:09:39 2011 ranaUpdateElectronicsPOY11 Rework Nearly Complete

I've finished tuning POY11 and it is now sitting on top of the analyzer waiting for Koji to test its noise.

 Notes:

  1. R2 has been switched from a 50 -> 110 Ohm R and a (29 Ohm | 47 pF) in parallel to it. This makes the gain of the MAX4107 be ~20 above 100 MHz and ~5 around 11 MHz. The high gain at high frequency makes it stable (squashes the 200 MHz oscillation) and the low gain at low frequency is to prevent saturation (the raw 11 MHz transimpedance is too high).
  2. There are two notches: 22.12 MHz and 55.3 MHz.
  3. The TEST IN input has been disabled since it wasn't useful.
  4. 107 Ohms inserted into between the U11 output and the TSENSE feedthrough. This is to prevent oscillations when driving the long Dsub cable. This needs to be done on all Gold Box RFPDs.
  5. R4 -> 50 Ohms.
  6. Had trouble tuning this to get the resonance at 11.06 MHz. This turned out to be the parallel inductance coming from L3 (previously 1.45 uH) whereas we needed a total inductance of ~1.6 uH. So I changed L3 to 33 uH to get it to be negligible compared to 1.7 uH at 11 MHz. This needs to be considered for all the 11 MHz diodes.

 

  4791   Mon Jun 6 22:41:22 2011 ranaUpdateSUSSwitching problem in SUS models

Some weeks ago, Joe, Jamie, and I reworked the ETMY controls.

Today we found that the model rebuilds and BURT restores have conspired to put the SUS damping into a bad state.

1) The FM1 files in the XXSEN modules should switch the analog shadow sensor whitening. I found today that, at least on ETMY and ETMX, they do nothing. This needs to be fixed before we can use the suspensions.

2) I found all of the 3:30 and cts2um buttons OFF AGAIN. There's something certainly wrong with the way the models are being built or BURTed. All of our suspension tuning work is being lost as a consequence. We (Joe and Jamie) need to learn to use CONLOG and check that the system is not in a nonsense state after rebuilds. Just because the monitors have lights and the MEDM values are fluctuating doesn't mean that "ITS WORKING". As a rule, when someone says "it seems to work", that basically means that they have no idea if anything is working.

3) We need a way to test that the CDS system is working...

  4796   Wed Jun 8 22:48:09 2011 ranaUpdateCamerasITM camera lenses changed

I focused these lenses so that we could get a clean image of the mirrors and the OSEMs.

Our goal is to have an image where the optic diameter almost fills the entire monitor. We want the focus to be adjusted for the YAG beam (which is almost the same as focusing for the OSEMs). This will NOT produce a nice image of the cage using visible light, but that is just fine.

When Justin Garofoli was here he found a nice lens combo that did the job, so if anyone can find his old email or elog, lets just go back to that.

For now, we do not need a camera/lens system to focus very tightly on the center of the optic.

  4803   Fri Jun 10 12:02:10 2011 ranaUpdateCDSSecond trends only go back 12 days

Quote:

While answering a quick question by Kiwamu, I noticed we only had second trends going back to 99050000 GPS time, May 27th 2011. 

Trends (I thought) were intended to be kept forever, and certainly longer than full data, which currently goes back several months.

Jamie will need to look into this.

 Our concept is to keep second trends for 1-2 months and minute trends forever. The scheme that Alan had worked out many years ago had it such that we could look back to 1998 and that the minute trends would be backed up somehow.

If its not working, we need to get Alan's help to recover the previous configuration.

  4830   Fri Jun 17 00:17:26 2011 ranaConfigurationElectronics2 RFPDs sent to LLO

Koji and I found 2 RFPD boxes to send to LLO. We've put them onto Steve's desk to be overnighted to Valera.

One of them is our old 21.5 MHz gold box RFPD from the FSS (which we don't use). The other one is a 2mm gold box one which was previously tuned for 66 MHz.

 

They shipped out on Friday

  4843   Mon Jun 20 17:58:00 2011 ranaUpdateCDSGateway program killed

There was a rogue, undocumented, gateway process running on NODUS since ~4 PM. This guy was broadcasting channels back into the Martian and causing lockups in the IOO controls. I did a kill -9 on its process.

Someone will pay for this.

  4861   Wed Jun 22 21:36:41 2011 ranaSummaryGeneralJuly 2011 vent plan

I put a paper Peet's bag with half of the Mini-Moos into George.

  4864   Thu Jun 23 09:46:16 2011 ranaUpdateLSCPRMI locking : not stable enough

All the suspensions are bad until you fix them. But, ... there is a script which can be used to diagnose them today:

Python SUStest

  4881   Fri Jun 24 22:35:23 2011 ranaConfigurationCDSdataviewer broken on pianosa

When I try to get minute trend, it says "word too long".

  4886   Sun Jun 26 16:17:22 2011 ranaUpdateCDSdiagonalization of MC input matrix

I have updated the scripts/SUS/peakFit/ directory so that it now finds the SUS input matrix coefficients in addition to just finding the free-swinging peaks.

Procedure:

  1. Get OSEM sensors data via NDS2 from a time when the optics have been kicked and then left free swinging.
  2. Downsample the data to 64 Hz and save.
  3. Make power spectra with a 1 mHz resolution (i.e. we need a few hours of data) and  ~10 averages.
  4. use the fminsearch lorentzian peak fitter -> save the peak frequencies
  5. Make Transfer Function estimate matrix at the peak frequencies between all OSEMs (this makes a 5x4 complex matrix)
  6. The matrix should be real, so make sure its mostly real and then take the real part only
  7. Normalize (height of biggest peak for each f_DOF should be 1)
  8. Add a Butterfly mode vector. This makes the sensing matrix go from 5x4 to 5x5. (Butterfly a.k.a. Pringle)
  9. Invert
  10. Normalize so that the biggest element in each Sensor2DOF column is 1.
  11. Load values into MEDM screen and then verify by another free swinging data run.

 

The attached PDF shows how much rejection of the unwanted DOFs we get between the existing diagonal input matrix and this new empirical matrix. Previously, the decoupling was only a factor of a few for some of the modes. Now the decoupling is more like orders of magnitude (at least according to this calculation). It will be worse when we load it and then try another free swinging run. However, the fact that the suppression can be this good means that the variation in the coefficients at the ~hours time scale is at least this small (~< 0.1%)

 

That's the basic procedure, but there are a lot of important but mainly technical details:

  1. Free swinging data must be taken with the angle bias ON. Otherwise, we are not measuring the correct sensing gain (i.e. the magnets are not in their nominal place within the OSEM-LED beam)
  2. Data must be checked so that the shadow sensor outputs are in their linear regime: if they are exploring the cubic part, then the fundamental is being suppressed.
  3. Instead of just using the peak frequency, I average a few points around the peak to get better SNR before inversion. I think this will make the results more stable.
  4. All previous input matrix diagonalization efforts (Buckley, Sakata & Kawamura, Black, Barton, Gonzalez, Adhikari & Lawrence, Saulson,...) for the past ~15 years have been using the spectra's peak height data. Today's technique uses the TF and so is more precise. The coherent transfer function is always better than just using the magnitude data.
  5. This method is now fairly automatic - there's no human intervention in fudging values, choosing peak heights, frequencies, etc.
  6. We'll have to rerun this, of course, after the mirrors are aligned and after the OSEM whitening fiasco is cleaned up somewhat.

I'll set the optics to be aligned and then swing tonight.

  4887   Sun Jun 26 18:35:16 2011 ranaHowToSUSfree swing all optics

I used scripts/SUS/freeswing-all.csh to give the optics a kick and then turn off their watchdogs and collect the free swinging data.  Final script end time = 993173551. Start taking data ~ 993173751

I had to fix up the script a little: it had amateur stuff in there, such as undefined variables.

It still doesn't work that well. On the new Ubuntu workstations, pianosa, it fails by just not setting some of the EPICS variables using the EZCA stuff.

On Allegra, it failed on ~1 out of 10 commands by returning "epicsThreadOnce0sd epicsMutexLock failed" ???

On Pianosa, it sometimes says, instead, "epicsThreadOnceOsd: pthread_mutex_lock returned Invalid argument.".   Ah...now I understand?

So finally, I had to run the script on op340m to get it to actually run all of its commands. That's right; I used a 15 year old Solaris 9 Blade 150 because none of our fancy new Linux machines could do the job reliably.

Fixing our EZCA situation is a pretty high priority; if the locking scripts fail to run ~1 command every hour its going to completely derail the lock acquisition attempts.

If you want to use the IFO tonight, just run the script again on op340m again when you're done.

  4888   Sun Jun 26 22:38:20 2011 ranaUpdateCDSMC1 LR dead for > 1 month; now revived temporarily

 Since the MC1 LRSEN channel is not wasn't working, my input matrix diagonalization hasn't worked today wasn't working. So I decided to fix it somehow.

I went to the rack and traced the signal: first at the LEMO monitor on the whitening card, secondly at the 4-pin LEMO cable which goes into the AA chassis.

The signal existed at the input to the AA chassis but not in the screen. So I pressed the jumper wire (used to be AA filter) down for the channel corresponding to the MC1 LRSEN channel.

It now has come back and looks like the other sensors. As you can see from this plot and Joe's entry from a couple weeks ago, this channel has been dead since May 17th.

The ELOG reveals that Kiwamu caught Steve doing some (un-elogged) fooling around there. Burnt Toast -> Steve.

bt.jpg

993190663   =      free swinging ringdown restarted again

  4889   Mon Jun 27 00:23:11 2011 ranaUpdateCDSETMX SIDE problem

The slow readback of the ETMX side seems to also have something flaky and bi-stable. This is not an issue for damping, but it disables the SIDE watchdog for ETMX and makes it unsafe if we accidentally use the wrong damping sign.

  4892   Tue Jun 28 01:18:53 2011 ranaHowToSUSfree swing all optics

Chris Wipf tells me that the EPICS Mutex Jumbo Mumbo can be overcome by upgrading our EPICS. We should get one of Jamie's assistants to get this going on one of the Ubuntu workstations.

  4914   Wed Jun 29 22:50:02 2011 ranaUpdateIOOmisc. MC work

Today I wanted to investigate the MC Length path situation for obscure reasons.

Jamie has started to revert the "ALTPOS" effect on the MC mirrors. So far, the screens and SLOW channels have been fixed, but the fast channels still say "ALTPOS" in the dataviewer instead of "MCL".

I also noticed that all of our old ADCU channels for diagnosing the PSL, MC, ISS, PMC ,etc. are completely AWOL. Let's blame Joe.

I think that there are probably some ADC channels available and that we'll just have to figure out what Joe intended for this. We certainly need it if we want to diagnose our PMC, ISS, FSS, MC, etc. Kiwamu tells us that the old PSL/IOO AA chassis is being used for some of the GCV signals, so its likely that we just have to do the appropriate channel name mapping in the DAQCONFIG tool.

Forging ahead with no data, I made up some filters in the MC2-MCL filter bank so that there could be a stable crossover between the laser path. I was able to turn it on and get some suppression of the FSS-FAST control signal, but there's no way to be sure without the fast channels. We gotta get Jamie to help us out once he finished the ETM BO mess.

  4926   Thu Jun 30 21:55:16 2011 ranaConfigurationDAQNDS2 conf change

As I recently had trouble getting all of the SUS SENSOR channels at once from NDS2, I asked J.Z. for help. He found that the number of buffers on mafalda was set to only allow a small amount of data to be requested at one time.

He's going to have to figure out a more permanent fix, but for now he's increased the data buffer size to allow somewhat larger chunks to be gotten. I have made a work around in matlab, which gets smaller chunks and then cats them together.

Its in SUS/peakFit/.

  4928   Fri Jul 1 11:47:25 2011 ranaUpdateIOOWFS2 resonances and installation

What is implicit in Suresh's entry is that we decided to run the WFS with the 10 dB internal attenuation set to ON as the nominal. In the past, we have always had all the attenuation OFF for max gain. The layout of the WFS is such that we get that nasty 200 MHz oscillation due to crosstalk between the 2 MAX4106 opamps for each quadrant. The 10 dB attenuator is able to reduce the positive feedback enough to damp the oscillation.

In principle, this is still OK noise-wise. I think the thermal noise of the resonant circuit should be ~2-3 nV/rHz. Then the first opamp has a gain of 5, then the -10 dB attenuator, then another gain of 5. The noise going to the demod board is then ~10-15 nV.

The real noise issue will be the input noise of the demod board. As you may recall, the output of the AD831 mixer goes to a AD797. The AD797 is a poor choice for this application. It has low noise only at high frequencies. At 10 Hz, it has an input voltage noise of 10 nV/rHz and a current noise of 20 pA/rHz. If we wanted to use the AD797 here, at least the RC filter's resistor should be reduced to ~500 Ohms. Much better is to use an OP27 and then choose the R so as to optimize the noise.

We should also be careful to keep the filter frequency low enough so as not to rate limit the OP27. From the schematic, you can see that this circuit is also missing the 50 Ohm termination on the output. There ought to be the usual high-order LC low pass at the mixer output. The simple RC is just not good enough for this application.

As a quick fix, I recommend that when we next want to up the WFS SNR, we just replace the RC with an RLC (R = 500 Ohms, L = 22 uH, C = 1 uF).

 

  4933   Fri Jul 1 20:22:24 2011 ranaUpdateSUSETMY sus controller found to be in a bad state

Actually, ETMY was the only good one. They should all have the 30 Hz High pass as the damping filter. I think these details are in the elog entry that we originally made while doing ETMY.

They should all also have a 3:30 in the XXSEN to compensate the whitening. The logic is supposed to be that FM1 is ON when the hardware whitening is ON. This is the opposite of the old logic and its why the damping filter has to be moved from 3 to 30 Hz.

  4934   Fri Jul 1 20:26:29 2011 ranaSummarySUSAll SUS Peaks have been fit

         MC1    MC2    MC3    ETMX   ETMY   ITMX   ITMY   PRM    SRM    BS     mean   std
Pitch   0.671  0.747  0.762  0.909  0.859  0.513  0.601  0.610  0.566  0.747  0.698  0.129
Yaw     0.807  0.819  0.846  0.828  0.894  0.832  0.856  0.832  0.808  0.792  0.831  0.029
Pos     0.968  0.970  0.980  1.038  0.983  0.967  0.988  0.999  0.962  0.958  0.981  0.024
Side    0.995  0.993  0.971  0.951  1.016  0.986  1.004  0.993  0.973  0.995  0.988  0.019

There is a large amount of variation in the frequencies, even though the suspensions are nominally all the same. I leave it to the suspension makers to ponder and explain.

  4935   Sun Jul 3 21:18:06 2011 ranaUpdateComputer Scripts / ProgramsstatScreen scripts dead since Feb 4 / now revived

This CSHRC mangling on Feb 4 did more than re-arrange FB binaries.

It broke the path to MEDM for the 32-bit machines in the lab (e.g. mafalda) and stopped the MEDM snapshots from being posted onto our MEDM Status Web Page.

This is because, in addition to the paths mentioned in the above elog, the paths to the EPICS directories were also commented out. I've re-inserted them into our

.cshrc file in the 32-bit section; the statScreen CRON that Yoichi set up is now back in business.

 

* for some reason, the 'cronjob.sh' script is wiping out its own log file. It would be great if someone who understands stderr output re-direction can fix it so that the log-file from each run is retained until the next time cron runs.

  4942   Tue Jul 5 21:26:51 2011 ranaUpdateSUSMore normalization of all sus controllers

This is getting closer, but with the whitening left OFF and the cts2um filter also OFF, none of the suspensions are working correctly. I'm shutting down all the watchdogs until someone gets around to setting the damping gains and filters correctly.

I'm attaching a screenshot of some of the problems I see so far with MC3.

I'm going to try to get the MC suspensions working OK for tonight so that we can use them for the PRMI locking work.

Update #1: None of the MC SUS DAQ channels are found by dataviewer....SUS debugging speed reduced by 10x.  Tue Jul 05 21:38:17 2011

Update #2: POS/PIT/YAW BIAS sliders now seem to work, but are ~1000x too weak to do anything.   Tue Jul 05 21:41:38 2011

 

  4972   Fri Jul 15 09:25:02 2011 ranaUpdateSUSSUS oplev spectras

In addition to the OL quadrants, you need to plot the OPLEV_PERROR and OPLEV_YERROR signals since these are the real signals we use for finding the mirror motion. If they're not in the Dataviewer, Jamie should add them as 256 Hz DAQ channels (using these names so that we have the continuity with the past). These DAQ channels correspond to the IN1 channels for the OL filter banks.

Also JPG are banned from the elog - you should put all of the plots into a single, multipage PDF file in honor of the new Wagonga.

  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.

Untitled.png

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

 a.png

  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

a.png

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:

bad.png

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

 Untitled.png

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

Quote:

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.

L.png

  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.

 Ex.

new_matrix = findMatrix('ITMX')

writeSUSinmat('ITMX', new_matrix)

writeSUSinmat.m

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.

ELOG V3.1.3-