The RC thermal PID is now controllable from its own MEDM screen which is reachable from the FSS screen. The slowpid.db and psl.db have been modified to add these records and all seems to be working fine.

Also, I've attached the c1psl startup output that we got on the terminal. This is just for posterity.

I'm also done tuning the PID for now. Using Kp = -1.0, Ki = -0.01, and Kd = 0, the can servo now has a time constant of ~10 minutes and good damping as can be seen in the StripTool snap below. These values are also now in the saverestore.req so hopefully its fully commissioned.

I bet that its much better now than the MINCO at holding against the 24 hour cycle and can nicely handle impulses (like when Steve scans the table). Lets revisit this in a week to see if it requires more tuning.

I added a new database record (C1:PSL-FSS_RCPID_SETPOINT) to allow for changing of the RC setpoint while the loop is on. This will enable us to step the can's temperature and see the result in the NRPO's SLOWDC.

I stepped the RC can temperature to see the response in the laser frequency. This gives a true measure of the thermal time constant of the RC. Its ~4 hours.

Since the RCPID screen now has a setpoint field, I can remotely type in 1 deg steps. The NPRO SLOW actuator locks the NPRO to the RC at long time scales and so we can use C1:PSL-FSS_SLOWDC to measure the RC length. By knowing what the step response time constant is, we can estimate the transfer function from can temperature to frequency noise and thereby make a better heater circuit.

 Does the observed temperature shift make any sense? Well, John Miller and I measured the SLOW calibration to be 1054 +/- 30 MHz / V.

We know that the thermal expansion coefficient of fused silica, alpha = 5.5 x 10^-7 (dL/L)/deg. So the frequency shift ought to be alpha * c / lambda = 155 MHz / deg.

Instead we see something like 110 MHz / deg. We have to take more data to see if the frequency shift will actually asymptote to the right value or not. If it doesn't, one possibility is that we are seeing the effect of temperature on the reflection phase of the mirror coatings through the dn/dT and the thermal expansion of the dielectric layers. I don't know what these parameters are for the Ta2O5 layers.

A more useful measure of the frequency noise can be gotten by just looking at the derivative in the first 30 minutes of the step, since that short time scale is much more relevant for us. Its 0.04 V / hour / (2 deg) =>  860 (Hz/s)/deg.

In the frequency domain this comes out to be dnu/dT = 860 Hz/deg @ 0.16 Hz or dnu/dT = 137 *(1/f) Hz / deg.

Our goal for the reference cavity frequency noise is 0.01 * (1/f) Hz/rHz. So the temperature noise of the can needs to be < 0.1 mdeg / rHz.

This first plot shows the RC temperature channels' performance from 40 days ago, before we disabled the MINCO PID controller. Although RCTEMP is supposed to be the out of loop sensor, what we really care about is the cavity length and so I've plotted the SLOW. To get the SLOW on the same scale, I've multiplied the channel by 10 and then adjusted the offset to get it on the same scale.

 The second plot shows a period after that where there is no temperature control of the can at all. Same gain scaling has been applied to SLOW as above, so that instead of the usual 1 GHz/V this plot shows it in 0.1 GHz/V.

The third plot shows it after the new PID was setup.

Summary: Even though the PID loop has more gain, the true limit to the daily fluctuations in the cavity temperature and the laser frequency are due to the in-loop sensors measuring the wrong thing. i.e. the out-of-loop temperature is too different from the in-loop sensor. This can possibly be cured with better foam and better placement of the temperature sensors. Its possible that we're now just limited by the temperature gradients on the can.

I've created a 40m Google account. Please post all the 40m related photos to this site. If you don't already have it, download Picasa to make this easier.

40m Installation Photos">

the password is in the usual password place.

>su
>/etc/init.d/xntpd start -c /etc/inet/ntp.conf

server nodus

[root@c1dcuepics sbin]# ./ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 nodus.ligo.calt 0.0.0.0         16 u    -   64    0    0.000    0.000 4000.00
*nodus.ligo.calt usno.pa-x.dec.c  2 u   29   64  377    1.688  -65.616   6.647
-lime7.adamantsy clock.trit.net   3 u   32   64  377   37.448  -72.104   4.641
-montpelier.ilan .USNO.           1 u   19   64  377   18.122  -74.984   8.305
+spamd-0.gac.edu nss.nts.umn.edu  3 u   28   64  377   72.086  -66.787   0.540
-mighty.poclabs. time.nist.gov    2 u   30   64  377   71.202  -61.127   4.067
+monitor.xenscal clock.sjc.he.ne  2 u   16   64  377   11.855  -67.105   6.368

This is a trend of the last 20 days. After our work with the NPRO, we have recovered only 5% in PMC trans power, although there's an apparent 15% increase in AMPMON.

The AMPMON increase is partly fake; the AMPMON PD has too much of an ND filter in front of it and it has a strong angle dependence. In the future, we should not use this filter in a permanent setup. This is not a humidity dependence.

The recovery of the refcav power mainly came from tweaking the two steering mirrors just before and just after the 21.5 MHz PC. I used those knobs because that is the part of the refcav path closest to the initial disturbance (NPRO).

BTW, the cost of a 1W Innolight NPRO is $35k and a 2W Innolight NPRO is $53k. Since Jenne is on fellowship this year, we can afford the 2W laser, but she has to be given priority in naming the laser.

 I think that the AMPMON ND problem was just that the responsivity changes with angle. So when I aligned it a little we got some few% improvement in the signal which is not a real power increase.

I don't think we can adjust any of the MOPA parameters because the controller is broken, but we can try the NPRO crystal temperature.

While trying to make the OAF work, I found that the XYCOM switches for MC1/3 have been set in the bad way for awhile. This means that the hardware filters were bypassed and that MC1 & MC3 were moving around too much at high frequency and possibly causing trouble with the locking. I have put them back into the default position.

On Friday, Jenne and I were playing around with turning the dewhitening off/on to see if it efffected the OAF stability. At the time, I didn't pay too much attention to what the state was. Looks like it was in the wrong state (hardware bypassed) when we found it. For the OAF work, we generally want it in that bypassed state, but its bad because it makes noise in the interferometer. The bits in question are bits 16-23 on the XYCOM screen.

I have updated the snapshot and set the screen in the appropriate settings. I used a swept sine measurement to verify the filter state. In the attached plot, green corresponds to XYCOM green and red corresponds to red.

Since we used to run with a gain slider setting of +15 dB on the MZ, I wanted to check that the new setting of +30dB was OK. It is.

To check it I turned it up and looked for some excess noise in the ISS or in the MC. There was none. I also set the input offset slider by unlocking the PMC and zeroing the mixer monitor readback. The new slider setting is -6.5V.

I don't know why we would need more gain on the MZ loop, but we can have some if we want it by turning up the gain before the servo (optical or RF). The attached plot shows the MC_F and ISS signals with the ISS loop on and off. There was no change in either of these spectra with the MZ gain high or low.

cosmic rays in cars

The attached shows the 200 day '10-minute' trend of the CPU meters and also the room temperature.

To my eye there is no correlation between the signals. Its clear that c1susvme2 (SRM LOAD) is going up and no evidence that its temperature.

 Here's a plot of the spectra of the seismometers and MCL. The coherence shows which axes are aligned right now: MC1_X is coherent with GUR_NS which means that its mis-oriented.

I've now swapped the "MC1" cables: so the old "NS" now goes into EW and the old EW now goes into NS. VERT is unchanged.

Also fixed the channel names - the Guralp previously named MC1 is now GUR1 and the other one is GUR2. Also no more EW, NS, & VERT. Its all XYZ.

DAQD restarted with the new channel names.

I drove MC2 in POS and used the resulting response in MC_F to calibrate the IOO-MC_L channel.

Yoichi did an excellent job of calibrating MC_F last year. I have used his calibration of MC_F (220 Hz/count @ DC) to get the MC_L calibration at DC as well as at high frequencies. The hardware dewhitening was OFF for all these measurements.

Method

1. For the DC measurement I excited C1:SUS-MC2_MCL_EXC at 0.0731 Hz. At these frequencies, the MC_L path has much more gain than the MC_F path. So this excitation at the error point makes the length path to drive itself to cancel the digital excitation. Since the overall MC servo gain is huge, this causes the MC_F path to compensate the residual MC_L motion. One can simply take the ratio of MC_L/MC_F to get the calibration of MC_L in Hz.

2. For the AC measurement, I engaged FM9 of the MC2_MCL filter bank. This guy is an elliptic LP with a notch at 660.38 Hz. I then drove MC2_LSC at 660.38 Hz with a sine wave of 500 counts amplitude. The notch makes the gain of the MC_L feedback zero at that frequency. So MC_F has to do all the work. We can simply measure the ratio of MC2_LSC/MC_F to get the AC calibration of MC2_MCL_OUT (aka IOO-MC_L) and MC2_LSC_OUT (aka LSC-MC_L).

Results:

MCF/MCL @ 0.0731 Hz = 569.4. So the MC_L calibration at DC is 220 x 569.4 = 125 kHz/count or 6.02 nm/count.

From this we would expect the AC calibration to be (6 nm/count)*(660.38/f_pend)^2 = 13.0 x10^-15 m/count.

The AC measurement gave 1445 counts_peak** of MC_F for the 500 counts (peak) excitation in MC2_LSC. From Yoichi's entry we get that the high frequency calibration of MC_F should be 0.089 Hz/count. So the MC_L calibration at 660 Hz is 0.089*1445/500 = 0.25 Hz / count or 12.3 x 10^-15 m/count. So the AC/DC ratio is close to 1.

Splitting the difference, the new official MC_L calibration is 5.87 nm/counts @ DC with a complex pole pair at 0.972 Hz.

** note:  To convert from the peak height observed in DTT with a 50% Overlap Hanning window you must use the following intuitive formula:  counts_peak = (counts / rHz) * sqrt(2 * BW). In this case, BW is the number that DTT reports as BW on the screen, NOT the BW that you asked for on the measurement tab.

*** note: when measuring peak heights in a DTT FFT, make sure to unclick the box for 'Bin' under the config tab. Bin suppresses peaks in a plot with a lot of points and is ON by default.

**** note: I have updated the MCF reference in the Templates directory with the Yoichi calibration - spectrum attached. This is probably the most accurate MCF spectrum we have ever put in the elog in the history of the 40m. The implication is that the VCO phase noise is ~5 mHz/rHz. Not bad.

***** note: with the OAF off, I drove a 1.55 Hz sine wave into MC1 and measured the ratio of MC1_MCL_OUT/IOO-MC_L. This gives the DC calibration of MC1_MCL_OUT = 7.98 nm/count.

I remeasured the OAF time delay using the OAF-TF template from the Templates/ directory.

Troublingly, I found the MC1 dewhitening switches set OFF - please make sure that the MC1 dewhitening is back ON after each OAF tuning so that the interferometer locking is not hosed.

The OAF-TF template had the excitation amplitude set ~20x too high. I reduced it and the coherence was still > 0.95. The phase at 32 Hz was still ~126 deg as Jenne had measured, but since the phase at DC is 180 deg, the overall phase lag is just 180-126 = 54 deg. So the delay should be 54/180 * 32 = 9.7 => 10. Luckily, Jenne is working on an instructional manual for OAF that will make all of this crystal clear.

[Rana, Jenne]

There is some craziness going on with the delay in the PEM path for the OAF.  We plot the difference between the C1:PEM-SEIS_GUR1_X and C1:ASS-TOP_PEM_10.  These are physically the same channel, plugged into the PEM ADCU, and then the signal is used as a regular PEM channel, and is also sent to the ASS computer and used there for the OAF system.  As you can see in the blue trace on the bottom plot, there is a huge amount of delay, and it's very noisy.  We also plot the _GUR2_X / ASS-TOP_PEM_2 pair (red), and it has a similar amount of delay, but it is not nearly as fuzzy and noisy.  For comparison, we plot the SUS-MC2_MCL (which is identical to IOO-MC_L) and ASS-TOP_ERR_MCL pair (green), and they don't have any big overall delay problems, so it's not totally a problem with the signals getting to the ASS computer.

This problem was present during/after all of the following attempts to fix it:

* The sample rate on the ASS computer is 2048.  The PEM channels were being acquired the ADCU at 512.  We changed the ADCU sampling rate to 2048 to match.

* We soft rebooted the ASS computer, in case it was a timing problem.

* Doing a "sudo shutdown -r now" while logged in as controls.

We might also try resetting/power cycling c0dcu in the morning.  Alex has been emailed to help us try to figure this out.

In other news, the time delay that we measure from the plot gives us 180degrees in ~210Hz.  This corresponds to a little more than 2msec of delay, with the C1:ASS version lagging behind the C1:PEM version.  (2 samples at 840Hz) Converting to the 2048 sampling rate, we have a delay of 4.8, so 5 front-end cycles.  Since Rana measured this morning that the delay indicated by the transfer function is 10 cycles, and this delay shows that the ASS lags the actual seismometer signal by 5 cycles, we should subtract this 5 from the 10 from the transfer function, giving us a final sample-and-hold delay of 5.  Coincidentally(?), 5 is the delay that was found in the C1:ASS-TOP screen, after it's one year of dormancy.  The point of the delay feature in the code is to help match the delay in the two signal paths: the PEM path and the output path of the filter.  Since the output has a lag of 10, and the PEM path has a lag of 5, to make them match, we artificially put in a delay of 5.

I changed the input channels of the DMF recently so that it now uses 3 Guralp channels in addition to the 3 ACC and 1 Ranger.

op440m:seisblrms>diff seisBLRMS-datachans.txt~ seisBLRMS-datachans.txt
4,7c4,7
< C1:PEM-ACC_MC2_X
< C1:PEM-ACC_MC2_Y
< C1:PEM-ACC_MC2_Z
< C1:PEM-SEIS_MC1_Y
---
> C1:PEM-SEIS_GUR1_X
> C1:PEM-SEIS_GUR1_Y
> C1:PEM-SEIS_GUR1_Z
> C1:PEM-SEIS_RANGER_Y
op440m:seisblrms>pwd
/cvs/cds/caltech/apps/DMF/compiled_matlab/seisblrms

The seisBLRMS channels still have the wrong names of IX and EX, but I have chosen to keep them like this so that we have a long trend. When looking at the historical seisBLRMS trend, we just have to remember that all of the sensors have been around the MC since last summer.

Does anyone know if this master file is the real thing that's in use now? Are we really using a file called tpchn_C1_new.par? If anyone sees Alex, please get to the bottom of this.

allegra:daq>pwd
/cvs/cds/caltech/chans/daq
allegra:daq>more master
/cvs/cds/caltech/chans/daq/C1ADCU_PEM.ini
#/cvs/cds/caltech/chans/daq/C1ADCU_SUS.ini
/cvs/cds/caltech/chans/daq/C1LSC.ini
/cvs/cds/caltech/chans/daq/C1ASC.ini
/cvs/cds/caltech/chans/daq/C1SOS.ini
/cvs/cds/caltech/chans/daq/C1SUS_EX.ini
/cvs/cds/caltech/chans/daq/C1SUS_EY.ini
/cvs/cds/caltech/chans/daq/C1SUS1.ini
/cvs/cds/caltech/chans/daq/C1SUS2.ini
#/cvs/cds/caltech/chans/daq/C1SUS4.ini
/cvs/cds/caltech/chans/daq/C1IOOF.ini
/cvs/cds/caltech/chans/daq/C1IOO.ini
/cvs/cds/caltech/chans/daq/C0GDS.ini
/cvs/cds/caltech/chans/daq/C0EDCU.ini
/cvs/cds/caltech/chans/daq/C1OMC.ini
/cvs/cds/caltech/chans/daq/C1ASS.ini
/cvs/cds/gds/param/tpchn_C1_new.par
/cvs/cds/gds/param/tpchn_C2.par
/cvs/cds/gds/param/tpchn_C3.par

Some of these channels are not like the others.

You can remove the RFAM measuring setup. Once we upgrade, we will no longer have a MZ or the related problems.

This is huge.    Five hours of lock only interrupted by intentional break from transfer function abuse.

Thermal lensing formula:

from (T090018 by A. Abramovici (which references another doc).

In the above equation:

w        1/e^2 beam radius

k        thermal conductivity (not the wave vector) = 1.3 W / m/ K

alpha    absorption coefficient (~10 ppm/cm for our glass)

NP       power in the glass (alpha*NP = absorbed power)

dn/dT    index of refraction change per deg  (12 ppm/K)

d        mirror thickness (25 mm for all of our SOS)

I'm attaching a plot showing the focal length as a function of recycling cavity power for both our current MOS and future SOS designs.

I've assumed a 10 ppm/cm absorption here. It may actually be less for our current ITMs which are made of Heraeus low absorption glass - our new ITMs are Corning 7980-A (measured to have an absorption of 13 ppm/cm ala the iLIGO COC FDD). I expect that our thermal lens focal length will always be longer than 1 km and so I guess this isn't an issue.

In addition to the main mirrors (PRM, SRM) we will also have fold mirrors (called PR1, PR2, SR1, SR2). I am curious to see if we can get away with just using commercial optics; I think that the CVI Y1S coatings may do the trick.

The above plots show the reflectivities v. wavelength. I've asked the sales rep to give us specs on the reflectivity v. angle. I bet that we can guess what the answer will be from these plots.

 Here's the trend.

The transient at ~22:40 is Rob switching to 'Open Loop' on the Piezo Jena PZTs. I don't see any qualitative change in the drift after this event.

At 05:55 UTC, I removed an iris that was blocking the IP POS beam (the sum goes up from 2 to 6.5) without disturbing the mirrors who's oplev beam are on that table. Steve has conceded one sugar Napoleon after betting against my ninja-like iris skills.

We should recenter the beam on IP POS now that its unclipped - I'll let it sit this way overnight just to get more drift data.

I wanted to see how long our IP POS beam has been badly clipped - turns out its since April 1, 2007.

Steve's April Fool's joke is chronicled then. The attached trend shows that the drop in IP POS is coincident with that event.

In trying to align IPPOS, I noticed that someone has placed a ND2.0 filter (factor of 100 attenuation) in front of it. This is kind of a waste - I have removed IPPOS to fix its resistors and avoid this bad optic. Also the beam coming onto the table is too big for the 1" diameter optics being used; we need to replace it with a 2" diamter optic (Y1-2037-45P).

IP ANG dropped by a factor of 2 back in early August of '08.

We need this guy on the investigation:

Its back in and re-centered. Our next move on IPPOS should be to replace its steering mirror with something bigger and more rigid.

Electronics changes:

20K -> 3.65 K  (R6, R20, R42, R31) (unused)

20K -> 3.65 K  (R7, R21, R32, R43, R11, R24, R35, R46)

If you look in the schematic (D990272), you see that its an AD797 transimpedance stage with a couple of LT1125 stages set to give some switchable gain. It looks like some of these

switches are on and some are not, but I am not sure where it would be controlled from. I've attached a snapshot of one quadrant of the schematic below.

The schematic shows the switches in the so-called 'normally closed' configuration. This is what the switches do with zero volts applied to the control inputs. As the schematic also shows,

just disconnecting the 'switch' inputs cause the switch's control inputs to go high (normally open configuration, i.e. pins 2-3 connected, pin4 open). For the record, the default positions of the IPPOS switches are:

switch1   high

switch2   low

switch3   low

switch4   high

** EDIT (Nov 2, 2009): I forgot to attach the before and after images; here they are:

I tried to compare the IP_POS time series with the IPANG and MC_TRANS but was foiled at first:

1) The IPANG scan rate was set to 0.5 second, so it doesn't resolve the pendulum motions well. Fixed in the .db file.

2) Someone had used a Windows/DOS editor to edit the .db file and it was filled with "^M" characters. I have removed them all using this command:   tr -d "\r" <ETMXaux.db > new.db

3) The MC_TRANS P/Y channels were on the MC Lock screen but had never been added to the DAQ. Remember, if there's a useful readback on an EPICS screen. its not necessarily in the frames unless you add it to the C0EDCU file. I have done that now and restarted the fb daqd. Channels now exist.

4) Changed the PREC of the IPPOS channels to 3 from 2.

5) changed the sign for the IBQPD (aka IPANG) so that bigger signal is positive on the EPICS screen.

 The real problem is that we are using frequency synthesizers to make the beat signals (133 and 199) instead of mixers. Luckily, the future 40m will not use beat signals (?) or synthesizers.

This is a plot of the R and T of the existing ETM's HR coating. I have only used 1/4 wave layers (in addition to the standard 1/2 wave SiO2 cap on the top) to get the required T.

The spec is a T = 15 ppm +/- 5 ppm. The calculation gives 8 ppm which is close enough. The calculated reflectivity for 532 nm is 3%. If the ITM reflectivity is similar, the signal for the 532 nm locking of the arm would look like a Michelson using the existing optics.

I would have guessed that you have to calibrate the detectors relative to each other before trying this. Its also going to be tricky if you use 2 different kinds of ADC for this (c.f. today's delay discussion in the group meeting).

I think Osamu used to look at fast transmission signals by making sure the PD at the end had a 50 Ohm output impedance and just drive the 40m long cable and terminate the receiving end with 50 Ohms. Then both PDs go into the SR785.

I used the coh_carpet.m function from the mDV to calculate this plot:

coh_carpet('C1:PEM-ACC_MC1_X','C1:PEM-ACC_MC2_X',gps('now - 3 days'),3600*12,4,10,64)

It shows the coherence v. time of two of our X-direction accelerometers starting around 1AM on Friday and going for 12 hours.

I'm not sure what it means exactly, but it looks like the coherence is relatively steady as a function of time. I will need more RAM than Rosalba or a smarter code to calculate longer time stretches.

 As far as I know, the EPICS channels have nothing to do with test points.

Steps:

1) Turn off feedback to ETMY (the ETMY button on the LSC screen).

2) Put a 1 into the YARM->MC2 output matrix element on the LSC screen.

3) Turn off FM6 (comb), FM7 (0.1:10) on the MC2_MCL filter bank. This is to make the IOO-MCL loop more stable and to reduce the IOO-MCL low frequency gain.

4) Set the MC2-LSC gain to 0.5, turn the output ON, turn ON FM4 & FM5 & FM6 of the MC2-LSC filter bank.

5) Turn on the input of MC2-LSC and the arm should now lock.

6) After locking, set the MC2-MCL gain to zero. Hopefully with a few second ramp time.

Voila!

(A comment by KA - c.f. this entry )

the inside temperature is alarming at the red level today - should check if the HIHI value is set correctly

It looked like the Busby Low Noise Box had too much low frequency noise and so I upgraded it. Here is a photo of the inside - I have changed out the 0.8 uF AC coupling cap with a big, white, 20 uF one I found on Rob's desk.

The Busby Box is still working well. The 9V batteries have only run down to 7.8V. The original designer also put a spare AD743 (ultra low current FET amp) and a OP27 (best for ~kOhm source impedances) in there.

Here's the noise after the fix. There's no change in the DC noise, but the AC noise is much lower than before:

I think that the AC coupled noise is higher because we are seeing the current noise of the opamp. In the DC coupled case, the impedance to ground from the input pins of the opamp is very low and so the current noise is irrelevant.

The change I implemented, puts in a corner frequency of fc = 1/2/pi/R/C = 1/2/pi/10e3/20e-6 = 0.8 Hz.

Overall, the box is pretty good. Not great in terms of current noise and so it misses getting an A+. But its easily a solid A-.

I've measured the voltage noise of the SR560's lead acid battery outputs; they're not so bad.

Steve ordered us some replacement lead-acid batteries for our battery powered pre-amps (SR560). In the unit he replaced, I measured the noise using the following setup:

SR560                              Busby Box

(+12V/GND) -------------AC Input      Out  ----------------   SR785

The SR785 was DC coupled and auto-ranged. The input noise of the SR785 was measured via 50 Ohm term to be at least 10x less than the SR560's noise at all frequencies.

Its clear that this measurement was spoiled by the low frequency noise of the Busby box below 10 Hz. Needs a better pre-amp.

Steve is summarizing the Video Matrix choices into this Wiki page:

http://lhocds.ligo-wa.caltech.edu:8000/40m/Electronics/VideoMUX

Requirements:

Price: < 5k$

Control: RS-232 and Ethernet

Interface: BNC (Composite Video)

Please check into the page on Monday for a final list of choices and add comments to the wiki page.

I propose that from now on, we indicate in the elog what frequencies we're referring to. In this case, I guess its the front panel readback and not the frequency counter -- what is the frequency counter readback? And is everything still locked to the 10 MHz from the GPS locked Rubidium clock?

Plus, what FSS Box? The TTFSS servo box? Or the VCO driver? As far as I know, the RC trans PD doesn't go through the FSS boxes, and so its a real change. I guess that a bad contact in the FSS could have made a huge locking offset.

but the increase in both the RCtrans and the RCrefl is consistent with my theory that the power going to the RC has increased ; its not just an increase in the visibility.

We should scan the AOM/VCO to make sure the frequency is matched to the resonance to within 0.5 dB.

 Plots don't really make sense. The second one is inherently unstable - and what's g?

 Seems like very strange cable loss numbers. The Heliax is lossier than the RG-174? I wonder how these compare with the specs in the cable catalog?

Need to measure the length of the cable, but too lazy to use a measuring tape?

Then you too can become an expert cable length measurer by just using an RF signal generator and a scope:

1. Disconnect or short (not 50 Ohm term) the far side of the cable.
2. Put a T on the near side of the cable.
3. Drive the input of the T with your signal source.
4. Look at the output of the T with the scope while sweeping the signal source's frequency knob.

The T is kind of acting like a beamsplitter in an asymmetric length Michelson in this case. Just as we can use the RF phase shift between the arms to measure the Schnupp asymmetry, we can also use a T to measure the cable length. The speed of light in the cable is documented in the cable catalog, but in most cases its just 66% of the speed of light in the vacuum.

I ramped the MZ PZT (with the loop disabled on the input switch) to calibrate it. Since the transmission has been blocked, I used the so-called "REFL" port of the MZ to do this.

The dark-to-dark distance for the MZ corresponds to 2 consecutive destructive interferences. Therefore, that's 2 pi in phase or 1 full wavelength of length change in the arm with the moving mirror.

Eyeballing it on the DTT plot (after lowpassing at 0.1 Hz) and using its cursors, I find that the dark-to-dark distance corresponds to 47.4 +/- 5 seconds.

So the calibration of the MZ PZT is 88 +/- 8 Volts/micron.

Inversely, that's a mean of 12 nm / V.

why am I calibrating the MZ? Maybe because Rob may want it later, but mainly because Koji won't let me lock the IFO.

Apparently, we haven't had a fast channel for any of the MZ board. So I have temporarily hooked it up to MC_DRUM at 21:13 and also turned down the HEPA. Now, let's see how stable the MZ and PMC really are overnight.

EDIT: it railed the +/- 2V ADCwe have so I put in a 1:4 attenuator via Pomona box. The calibration of MC_DRUM in terms of MZ_PZT volts is 31.8 cts/V.

So the calibration of MC_DRUM1 in meters is: 0.38 nm / count

For the Laser Gyro, I wondered how much mechanical noise we might get with a non-suspended cavity. My guess is that the PMC is better than we could do with a large ring and that the MZ is much worse than we could do.

Below 5 Hz, I think the MZ is "wind noise" limited. Above 10 Hz, its just ADC noise in the readout of the PZT voltage.

I wanted to see what the noise of the Ranger seismometer should be. I used LISO and file ranger.fil (in our LISO SVN) to calculate the voltage noise referred to the input. In this model, we represent the EMF from the moving magnet in the coil as a voltage source at 'nin' which drives the coil impedance. This is the same approach that Brian Lantz uses in his noise modeling of the GS-13 (PDF is on our Ranger wiki page).

In the simulation, I used the OP27 as a placeholder for the SR560 that we use (I don't know the current noise of the SR560). To do this, I use the new 'inputnoise' feature in LISO (its in the README, but not in the manual).

You can see that we would be limited by the input current noise of the OP27. So we would do a lot better if we used an FET based readout amp like the AD743 (or equivalent) or even better using the new multi-FET readout circuit that Rich Abbott has developed. Clearly, its also silly to have a load resistance in there - I put it in because the manual says to do it, but all it does is damp the mass and reduce the size of the signal.

#  Noise sim for the Ranger SS-1 seismometer
#
#                            \
#                           | \            
#           n2- - - ----  - |  \          
#            |    |         | op1>-- n4 - r4 -- no
#           Rg   RL     n3- |  /     |           
#       n1 - |    |     |   | /      |                
#           Lg    |     |    /       |                        
#            |    |     | - - - R2 - -                    
#           nin  gnd   R1 
#                       |
#                      gnd

We previously measured the Ranger's self noise by locking it down.

The 1/f^3 noise that we see below 1 Hz is roughly consistent with the noise model: to get from my plot into meters you have to multiply by:

(1 + f)^2

----------

340 * f^2

P.S. Secret PDF handshake: You can make your non-compliant applications like LISO or DTT produce a thumbnailing PDF by using Acrobat to open the file and export it as PDF/A.

In the second attachment, I have used an OPA827 (new low-noise FET input amp from TI) as the readout amplifier. This seems like a good choice - main drawback is that Digikey backordered my OPA827s by 19 weeks!

 To me, they both look stable. I guess that the phase has to go to -180 deg to be unstable.

Why does the magnitude go flat at high frequencies? That doesn't seem like 1/f.

How about a diagram of what inputs and outputs are being measured and what the gain knob and boost switch settings are?

This plot shows the Transmission for 532 and 1064 nm as a function of the thickness of the SiO2 layer.

i.e. the thickness is constrained so that the optical thickness of the SiO2 and Ta2O5 pair is always 1/2 of a wavelength.

The top layer of the mirror is also fixed in this plot to be 1/2 wave.

This plot shows the result for 17 pairs. For 16 pairs, we are unable to get as low as 15 ppm for the 1064 nm transmission.