40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  ATF eLog, Page 34 of 56  Not logged in ELOG logo
ID Date Author Type Category Subject
  1139   Thu Nov 4 23:22:53 2010 ZachComputingComputingwhy is the elog so slow?

 I have noticed that the elog is taking excruciatingly long to load today. Is this happening to anyone else?

  1138   Thu Nov 4 22:18:31 2010 AlastairComputingComputingChanges to model

I've been working on getting the model to switch the boost on and off based on the transmission pd signal.  So far I have the software part working but not the hardware.

In terms of software, initially I tried modifying the epics atf1.db file.  I added  a calc channel that compared the trans_pd value to a user input channel from the MEDM screen.  I could get this to switch, but got stuck at the point where I tried to write this back out through the DAC.  While you can use an 'ao' channel in epics to do this, we want instead to write out through the front end.  I set up an epics channel that could write out through the front end, by putting it into the model but got stuck trying to work out how to write the calc channel to the channel that is connected to the DAC.  Making them the same channel didn't work and I couldn't find a way to transfer a value from a calc channel to an 'ai' channel.

Instead I got it to work by putting doing the comparison in the Simulink model.  The trans_pd epics value is compared to a user input MEDM value, and the binary output of this then toggles a switch that sets DAC output 10 high or low.  One nice thing about this is that it doesn't require any manual editing of the .db file.

There is one problem with connecting this up right now.  Frank thinks the DAC output is probably differential (we measure 5v out on the boost controller channel when connected to a scope, but 10v on a multimeter), and if we connect it to a grounded piece of equipment (such as the boost input on the PDH box) we will be shorting the output.  We should take the DAC card out of the rack and check that this is the case.  If so then it seems we need a differential input on the boost switch and everything else that we are controlling from the DAC (such as the slow input on the laser).

 

  1137   Wed Nov 3 20:52:14 2010 ZachElectronicsGYROPDH box #1437 gain vs. gain knob setting

Below is a plot of the measured gain of a 1-kHz sine wave through PDH box #1437 with a varying gain knob setting. The variable gain stage (AD8336) is linear in dB with a slope of roughly 5 dB per unit. This allows us to generalize the measured TF at, say, G = 0.5 to any gain setting. Alastair's measurement in ELOG 1080 is consistent with a gain setting of 0.5, so if we can get his data we will have a generally applicable TF.

PDH_1437_gain_knob_cal.png

 

  1136   Wed Nov 3 20:45:29 2010 ZachElectronicsGYROPDH box IN -> INMON TF

 Here is a transfer function from the IN to INMON ports of the primary PDH box (#1437). It is pretty constant up to about 10kHz, where it begins to fall off. The phase lag at 10kHz is ~3 degrees. This is consistent with Koji's LISO modeling of the stage, and it indicates that cascading OP27s may not be a suitable practice for our application.

in_inmon_tf.png

  1135   Wed Nov 3 20:40:20 2010 ZachElectronicsGYROSLP-1.9+ audio TF

 It is actually an SLP, not BLP that we have in the primary PDH setup (though I assume this just refers to the connector type, and not anything with the circuitry). In any case, we care about the low-frequency response of the filter at least as much as the high frequency attenuation. Here is an audio transfer function showing that the filter is essentially a straight wire in our frequency band of interest.

SLP-1.9plus_audio_tf

  1134   Wed Nov 3 20:25:01 2010 ZachElectronicsGYROdemodulation noise analysis

Koji pointed out that the PD noise at DC is irrelevant to the demod noise. I have repeated the measurement the correct way. All of these spectra were generated by looking at the "INMON" port of the primary PDH box. They were then divided by the meaning of life (42) to reflect the true level at the "IN" port. The traces are:

  1. 50-ohm terminator in place of the PD (demod noise only)
  2. PD connected but shutter closed (demod noise + PD dark noise)
  3. PD connected, 100 mW incident power, EOM off (demod noise + PD dark noise + shot noise)
  4. PD connected, 100 mW incident power, EOM on (demod + PD dark + shot + RFAM from EOM)
  5. Measurement noise floor for (1) and (2)
  6. Measurement noise floor for (3) and (4)

demod_noise.png

Two things of note:

  • There is a large amount of RFAM noise (yellow trace) that needs to be minimized. This might explain a lot of our noise coupling.
  • 100 mW is not sufficient for shot noise to surpass the dark PD noise. This is the highest power I was able to put on the diode downstream of the initial beam split even when putting all of the light through one of the two paths.

I agree with Koji's assertion that our first priority should be replacing the REFL PDs we have in place at the moment. We will likely go back to the PDA255 for the primary loop while we wait on the custom RFPDs.

 

Quote:

 NOTE: The plot below is somewhere between misleading and wrong. See reply.


Attached is a plot showing the following (all of these were taken with the laser shutter closed in order to focus on electronics noise):

  • Voltage noise out of the mixer with the PD connected to it
  • Voltage noise out of the mixer with a 50-ohm terminator in place of the PD
  • Noise directly from the PD. Note: the raw data for this was divided by two to account for the change in transimpedance gain when going from Hi-Z (Agilent) to 50-ohm (mixer)
  • Measurement noise floor

The "mixer output" here is actually the output of the lowpass filter after it.

demod_noise.png

The noise from the demodulation seems negligible in comparison to the dark PD noise, with the exception of a broad peak at around 49 kHz that appears to come from the mixer.

 

  1133   Wed Nov 3 19:00:45 2010 AlastairComputingComputingDAQ

Quote:

I've rebuilt the C2ATF front-end and renamed all the channels for the gyro as well as changing the topology.  I started a list of channels on the wiki here.

I have made one new medm screen for us to use to start with.  It is called C2ATF_GYROMAIN.adl  (see screenshot below).

Most of the channels now just come in and go to a filter so that we can aquire them.  The laser piezo actuation signal does go back out again through channel 9 so we can act on the slow feedback.  I have added 4 general channels that come in and go back out, just in case there are things we wish to do that I haven't thought of yet.

 

The front-end is running happily for the moment.

 

I've made a second MEDM screen for the gyro.  It is more of an indicator screen showing which signals we are aquiring from which part of the gyro.  It has a few charts that we can modify as we think of things that we want displayed (it shows just photodiode DC values and actuation signals at the moment).

I added a matrix to the TEST channels and incorporated that into the C2ATF_GYROMAIN.adl

I've spent a while routing cables.  We now have all the correct channels attached to the ADC and I've labelled them at the gyro end.  I ordered a couple more patch bays so that each bench can have two.  Frank is going to pass on the info for the BNC cables that are used to connect the patch bays - they were custom lengths and he has the original quote.  We'll buy enough new ones that we can route 2*16 channels for both benches.

Attachment 1: Screenshot.png
Screenshot.png
  1132   Wed Nov 3 18:18:19 2010 FrankMiscGeneralThin film and bulk index of refraction and photonics calculations - web page

while searching for optical properties of Tantala thin films i found the following web page to do all kinds of conversion and calculations. So check it out ...

http://www.luxpop.com

  1131   Wed Nov 3 01:27:26 2010 KojiLaserGYROin response to the elog entries 1126-1130

1126

- The input gain of 32.5dB=42 is good.

It seems that the amplifier starts loosing gain above 10kHz. I wonder how much phase delay we get at 10kHz.
==> We need the phase measurement too.
This may indicate that op27 is not adequately fast for our application.
A quick calculation with LISO shows the phase delay of 3deg at 10kHz.

r r1 25 gnd nm
r r2 1k nm no
op op1 op27 np nm no

uinput np 0

# uncomment this for the transfer function
#uoutput no:db:deg
# uncomment this for the noise
noisy all
noise no sum all

gnuterm pdf

freq log 100 1M 400

1127

We need the TF measurement with phase.

1128

Measurement noise floor is too high. You could use the input monitor (OP27 G=41~42) as a preamp.
The above LISO simulation showed 3.3nVrtHz. This is already pretty good preamp. 

I don't understand the dark PD noise. Is it demodulated signal? or DC noise (which is not relevant to us)?

The PD demodulated dark noise of 30nV/rtHz does not agree with our measurement last week (1uV/rtHz => 24nV/rtHz).
Probably the noise level of the FFT is affecting the measurement. USE any PREAMP

We just need the noise levels of the input monitor output in the following configuration:
- The cable terminated (Noise of the demodulation system)
- The PD connected with no light (above + noise of the PD)
- The PD connected with nominal amount of DC light - no cavity / no modulation (+shot noise)

- The PD connected with nominal amount of DC light - no cavity / with modulation (+modulation RFAM noise)

1129

The result is incomprehensible.

Use DC photocurrent (I_DC) and output noise level (V_out) for the horiz and vert axes, respectively.
For V_out, pick the noise level appropriately at an uncontaminated frequency.
Fit this curve by the model V_out = g_det sqrt(I_det + I_DC), where the parameters g_det and I_det are the equivalent transimpedance
and the equivalent noise current. g_det is a kind of gain, and I_det gives you how much DC current do you need to make the shot noise
and the system noise comperable. (i.e. You must put more light than I_det)

And the I_det is the order of the sub-mA for the low noise PD. You need to put ~10mA (= 500mW) to really test the PD shot noise.

AndI am afraid that this is not the demodulated noise.

1130

What to do

> Remeasure the cavity response (V/Hz).

No.

What we need is the precise PZT calibration and precise OPTF modeling.

Once the fast PZT is calibrated and the openloop TF is measured, we can infer the applied frequency disturbance.
Then we can easily deduce the cavity response (V/Hz).


MENU on Wednesday

1. Re-confirm the validity of the Tektronix VCO's purported external FM deviation setting.

Zach has the previous measurement but the value depends on how much output impedance the external source has.
So we test the frequency shift with the excitation we used for the IFO calibration.

2. Try to find two nice equivalent PD and characterize them.

3. Koji measures the circuit TFs while Zach tries to obtain noise plots.

4. Realignment, open loop TF measurement, CDS hooking up, etc... if possible.

 

  1130   Tue Nov 2 23:20:07 2010 ZachLaserGYROList of things to do
  1.  Remeasure the cavity response (V/Hz). I thought I had this from when I measured the finesse, but I realized that I did this with the transmitted power and not the error signal, so I don't have the information I want. Once I have this, I can do several things, including:
    • Convert all the spectra Koji and I measured last week into gyro signal units (rad/s/rHz)
    • Divide the primary error spectrum by the OLTF of the loop to determine the unsuppressed frequency noise level and compare it with the expected free-running laser noise
  2. Remeasure the PDH box TF using the SR785, then
    • Put the new plot on the wiki
    • Refer the measured input-shorted PDH box output noise to the input to determine its contribution to frequency noise, compare this with LISO
  3. Re-confirm the validity of the Tektronix VCO's purported external FM deviation setting. I did this for DC frequency shifts using a calibrator in ELOG 1090, and yesterday I double-checked it by putting the frequency-modulated signal into the RF analyzer to see that the sidebands were at the correct frequencies, but I realized that I was looking around 95 MHz instead of 47.5 MHz, so I was really looking at sidebands on the carrier harmonic. Either way, the frequency spacing was exactly the 1kHz it was supposed to be, but I will make the correct plot and put it here.
  4. Connect the decided-upon signals to CDS so that we can systematically monitor them at any point in the future. Alastair has put the finishing touches on our new-and-improved front end code, so this should be ready to go.
  5. Do a thorough realignment of the cavity in both directions and record the improvement in transmission, then make new measurements of the error signals and OLTF. I was originally going to do this first, but I thought it might be wise to do all the other junk I have done first while Alastair finished up with the front end. 
  1129   Tue Nov 2 23:01:45 2010 ZachLaserGYROPDA10A (REFL CCW PD) intensity noise analysis

 Below is a plot of the measured intensity noise (calibrated to W/rHz using the responsivity and transimpedance from the datasheet) of the PDA10A we are currently using for the primary lock loop, for various levels of incident power. In doing so I realized that this is a Si detector with only 0.02 A/W responsivity @ 1064 nm, which is not ideal for our setup. There are fast InGaAs diodes that we can use instead.

PDA10A_W_noise.png

Below ~200 uW, the spectrum seems to be dominated by the dark noise of the PD. Above this level, the broadband noise floor goes up approximately as sqrt(P), but at a level much higher than the predicted shot noise level. For comparison, the expected shot noise level for P = 500 uW is about 1.4 x 10-11 W/rHz, which is below even the measurement noise floor. So, there is some power-dependent noise source that is limiting us here once we've surpassed the dark noise. Perhaps this is a consequence of using a detector with such poor quantum efficiency for 1064nm. There also seems to be some lower-frequency 1/f noise that increases with incident power.

  1128   Tue Nov 2 22:47:35 2010 ZachElectronicsGYROdemodulation noise analysis

 NOTE: The plot below is somewhere between misleading and wrong. See reply.


Attached is a plot showing the following (all of these were taken with the laser shutter closed in order to focus on electronics noise):

  • Voltage noise out of the mixer with the PD connected to it
  • Voltage noise out of the mixer with a 50-ohm terminator in place of the PD
  • Noise directly from the PD. Note: the raw data for this was divided by two to account for the change in transimpedance gain when going from Hi-Z (Agilent) to 50-ohm (mixer)
  • Measurement noise floor

The "mixer output" here is actually the output of the lowpass filter after it.

demod_noise.png

The noise from the demodulation seems negligible in comparison to the dark PD noise, with the exception of a broad peak at around 49 kHz that appears to come from the mixer.

  1127   Tue Nov 2 22:40:31 2010 ZachElectronicsGYROBLP-1.9+

 Attached is the attenuation plot for the BLP-1.9+ we are using after the mixer from the spec sheet.

BLP-1p9plus.png

  1126   Tue Nov 2 22:36:35 2010 ZachElectronicsGYROPDH schematic updated

 I have updated the schematic for PDH box #1437 (primary loop) and put it in the gyro wiki. I have not been able to take a new transfer function with the Agilent, as it seems to be too noisy for some reason. I will use the SR785 (which has a higher input range) to make one ASAP. In the meantime, the general shape can be found in ELOG 1080 (this TF would be fine but the gain setting was not recorded at the time).

I also measured the change in gain as a function of the dial setting, which is linear in dB (as it should be given the specifications of the AD8336 variable gain stage it is connected to). I did this by injecting a sine wave @ 1kHz with the FG and measuring the amplitude at the output. For some reason, the results I got seemed unreasonably high (~112 dB with G = 0.5, whereas the TF linked above shows ~40 dB @ 1kHz, which would be unattainable for any gain setting given my measurement). It is possible that I was driving with a higher amplitude than I thought; I will repeat the measurement tomorrow).

Finally, I verified that there is a factor of ~40 gain from the INPUT to INPUT_MON ports on the PDH box, as seen below.

in-inmon_gain.png

  1125   Tue Nov 2 19:22:56 2010 AlastairComputingComputingDAQ

I've rebuilt the C2ATF front-end and renamed all the channels for the gyro as well as changing the topology.  I started a list of channels on the wiki here.

I have made one new medm screen for us to use to start with.  It is called C2ATF_GYROMAIN.adl  (see screenshot below).

Most of the channels now just come in and go to a filter so that we can aquire them.  The laser piezo actuation signal does go back out again through channel 9 so we can act on the slow feedback.  I have added 4 general channels that come in and go back out, just in case there are things we wish to do that I haven't thought of yet.

The front-end is running happily for the moment.

Attachment 1: Screenshot.png
Screenshot.png
  1124   Mon Nov 1 22:25:48 2010 FrankLaserGeneral35W laser ON

The 35W laser is on again.

Moved all equipment from EE lab back to the ATF and currently doing some tests. 
All the equipment next to the 35W laser table (near lab corner)  is in use  (automated measurements). 

Plz don't touch those things

  1123   Mon Nov 1 19:46:05 2010 ZachMiscComputingfloppy disk cleared

 I am wiping the floppy disk entitled "Alastair's Agilent traces 1", which I know that several of us have used to transfer data from time to time. I have temporarily backed it up on my hard drive, but if no one claims any data I will delete it.

  1122   Mon Nov 1 16:35:15 2010 AlastairLab InfrastructurefubarOld white board

Quote:

Quote:

RIP Old Whiteboard

I found the old white board and got a photo of the info before the goons who removed it can throw it away.

As a tribute to the old whiteboard, I think that Aidan in particular will appreciate this

 

 Why did we switch whiteboards?

Why would we let them throw this one away?

 

 Don't ask me George, I have no idea.  We now have a huge door sized white board though, and a sort of fake wall covering up the door.  I'm just assuming that at some point the old one will be gone since it no longer has a wall to live on.  Any more questions?

  1121   Sat Oct 30 23:41:31 2010 KojiLaserGYROgyro characterization Oct 27, 2010 (5)

[Zach / Koji]

Other things to do:

Assemble the noise budget plot

  • Put every possible thing into the noise budget plot
  • Propose other noise measurements

Tuning of the secondary loop

  • Take the thorough alignment of the beams
  • Record the improvement of the transmited power by the alignment improvement.
  • Adjust the openloop gain of the secondary loop
  • Measure the new error / feedback signals.

CDS preparation

- At least the following stuffs for each loop are needed to be connected to the CDS system in order to make the characterization continuously:
(ADC)

  • The error signal (or input monitor)
  • TP2 or TP6 (= the signal before the summing point)
  • output monitor (= the signal after the summing point)
  • Reflection DC
  • Transmission DC
  • and Gyro beat signal

(DAC)

  • PZT sweep input

- Consider the whitening filters to amplify the signal above the ADC noise level.

Circuits

- Confirm the circuits and make the latest circuits diagram.

- Measure the latest filter TF. If we already have it, put the numerical data / the liso model somewhere.

- Measure the input equivalent noise of the filter. 
i.e. short the input of the filter box measure the outupt noise of the box (or the notch). Divide it with the TF to convert it
to the input equivalent noise.

- Measure the demodulator noise levels.

- Shot noise characterization: put DC light onto the PDs and measure the demodulator noise with various DC powers.


It is done for now.

  1120   Sat Oct 30 22:49:04 2010 KojiLaserGYROgyro characterization Oct 27, 2010 (4)

[Zach / Koji]

Calibration of the laser PZT drive

Method:

- Lock the primary cavity.
- Inject the sinusoidal signal from DS345 to the PZT sweep input. The frequency was 1kHz. The amplitude display showed 10mVpp(@50Ohm).
- Look at the peak in the PZT feedback and the error signal.
- Also look at the error of the secondary loop. (*)

- Disconnect VCO feedback and connect DS345 to it. This gives us the calibration signal with known amplitude.
- Look at the error signal of the secondary loop. Compare it with the above (*)

Result:

The result of the signal injection into the primary loop

- The primary loop error showed the peak amplitude of 685.2410 uVrms
- The primary loop feedback showed the peak amplitude of 98.7438 uVrms
- The secondary loop error showed the peak amplitude of 64.9701 uVrms

We put the same signal into the VCO control. (Note: It is not necessary to be the same amplitude.)

- The secondary loop error showed the peak amplitude of 247.258 uVrms

Strangely the primary error signal also showed 0.808uVrms peak, which should not appear in the primary error.

Thought:

Quick calculation

- The response of the VCO driver is 100kHz/V. Assume this has 50Ohm input (TO BE CONFIRMED). The VCO drive has 10k input impedance. => 10K/(10K+50) = 0.995
- This means we shook the VCO frequency by 100kHz/V * 10mVpp * 2 * 0.995 = 2.0kHzpp
- The actual AOM changes the laser frequency twice because of its double pass configuration. ==> 4.0kHzpp ...(a)

- (a) yield 247uVrms, while the PZT injection did 685uVrms 64.97uVrms. ==> 2.8 times larger. 4.0kHz x 0.26 = 1.04kHzpp ...(b)

- PZT actuation of 99uVrms (=280uVpp) caused this (b). ==> 3.7MHz/V

To Do:

  • Confirm the above logic
    • How much was the VCO frequency actually swung?
      Calibrate the VCO driver again by putting the same signal into the VCO and look at the VCO output with the RF analyzer.
  • Calibrate the primary and secondary error signals. How much V/Hz do they have?
  • What cause the strange signal coupling from the secondary cavity to the primary cavity?
    • Is this optical, or electorical?
    • Shake the VCO freq and observe the error signal of the primary. Block the beam of the secondary at various places.
      (i.e. just before the faraday, just after the AOM, before the AOM etc...) Try to understand what is happening?
    • Is this coupling harmful?

 

  1119   Sat Oct 30 20:57:19 2010 KojiLaserGYROgyro characterization Oct 27, 2010 (3)

[Zach / Koji]

Measurement of the secondary (CW) cavity error signal.

Method:

- Lock the primary cavity.
- Tune the VCO frequency such that we can transmit the secondary (CW) beam to the transmission CCD. Tune the error signal to zero.
- Leave the secondary loop open. Look at the error signal of it in order to determine whether it is in the linear range or not. (Yes it was)
- Measure the error signal while the loop is open or closed.

Result:

- The control bandwidth seems to be ~100Hz. The control gain seems to be ~3.
- The error signal seems to be completely dominated by the dark noise of the detection system (= PD+demodulator).

Thought:

- The gain and the bandwidth are way too low to obtain the gyro signal from the VCO feedback
- If you look at the structures above 100Hz, the optical gain is about ten times smaller than that of the primary loop.
  What the heck is and the bandwidth are way too low to obtain the gyro signal from the VCO feedback

- Note that the signal is supposed to be amplified by a factor of +41. This means the dark noise floor level is ~25nV/rtHz.

To Do:

  • Calibrate these spectra in Hz/rtHz.
    • How much is the optical gain in V/Hz or V/m.
    • Overlay calibrated spectra of the primary and secondary loops.
    • There looks excess noise below 10Hz. We must reveal what it is through the measurements.
  • This error signal is the gyro output signal as far as there is no feedback.
    Calibrate this signal to (rad/s)/rtHz (or rad/Hz). Put this measurement on the noise budget plot.
  • Convert the dark noise measurement into the noise budget of the Gyro signal.
  • Measure the control loop gain. Investigate the shape of the loop up to 100kHz.
     
  • Measure the shot noise level
    • How much DC power do we typically have? (Actually we don't have the record during this measurement, but we can measure it again)
  • Measure low frequency spectra with CDS
  • How to improve the noise floor
    • Understand why the optical gain is so low.
    • Is this noise level disturbing in terms of the gyro requirement? How about in the low frequency?
    • How much is the demodulator noise? Put a 50-ohm terminator on the cable instead of the PD. Then measure the same signal.
    • How much is the gain of the input stage. It is supposed to be +41, but we are not sure.
      => Think about the noise level at the demodulator output.
    • How much is the noise level of the PD measured by an RF analyzer? Is it consistent with the above analysis?
    • Do we need a new resonant RF PD? How much should we improve the noise level with the new PD? And how much noise does the new one actually have?
  • Where the VCO frequency noise comes? ==> Measurement of the VCO noise.

 

Attachment 1: error_secondary.pdf
error_secondary.pdf
  1118   Sat Oct 30 20:18:06 2010 KojiLaserGYROgyro characterization Oct 27, 2010 (2)

[Zach / Koji]

Measurement of the primary (CCW) cavity error / feedback signal.

Method:

- Lock the cavity. Measure the spectrum of the input monitor output.
- Close the laser shutter. Measure the same spectrum.

- Measure the feedback signal after the notch filter.

Result:

- The global shape of the error signal is a kind of flat. Though it's spiky due to mechanical resonances.
  Below 10Hz it got smoother but the actual shape is not obvious because of the rough resolution.
- At around 100Hz, the error is below the dark noise. This means the out-of-loop stability does not go below the dark noise level.

Thought:

- The broad peak at around 10Hz is the servo bump.
- Note that the signal is supposed to be amplified by a factor of +41. This means the dark noise floor level is ~25nV/rtHz.

To Do:

  • Calibrate these spectra in Hz/rtHz.
    • How much is the optical gain in V/Hz or V/m.
  • Convert this measurement into the noise budget of the Gyro signal.
  • Make the unsuppressed spectrum
    • => How much cavity length fluctuation does the error signal feel if there is no feedback and the sensor is infinitely linear?
    • This requires the model of the open loop TF
    • Compare the consistency with the same quantity derived from the feedback signal
    • Compare the unsuppressed frequency noise spectra with the free running laser freq noise (see rana's phd thesis P.80).
    • Convert the spectrum into the displacement noise (m/rtHz) and compare with the displacement on the table.
  • Measure the shot noise level
    • How much DC power do we typically have? (Actually we don't have the record during this measurement, but we can measure it again)
  • Measure low frequency spectra with CDS
  • How to improve the noise floor
    • Is this noise level disturbing in terms of the gyro requirement? How about in the low frequency?
    • How much is the demodulator noise? Put a 50-ohm terminator on the cable instead of the PD. Then measure the same signal.
    • How much is the gain of the input stage. It is supposed to be +41, but we are not sure.
      => Think about the noise level at the demodulator output.
    • How much is the noise level of the PD measured by an RF analyzer? Is it consistent with the above analysis?
    • Do we need a new resonant RF PD? How much should we improve the noise level with the new PD? And how much noise does the new one actually have?
Attachment 1: error_primary.pdf
error_primary.pdf
Attachment 2: feedback_primary.pdf
feedback_primary.pdf
  1117   Sat Oct 30 20:02:01 2010 KojiLaserGYROgyro characterization Oct 27, 2010 (1)

[Zach / Koji]

Measurement of the primary (CCW) cavity openloop TF.

Method:

- Inject the actuation signal from the PZT sweep input
- Take after-the-sum signal and before-the-sum signal from TP6 and the output mon, respectively.

Result:

- UGF: 10kHz (this is OK)
- Phase margin: 14deg (this is too small)

Thought:

- The phase compensation between 5k to 20k is not enough.
- The phase delay above 10k seems too big. Possibly come from not-so-fast opamps (op27)?

To Do:

  • Make the model of the openloop tf in alll frequency range (1mHz-100kHz).
    • The cavity cut-off has already been measured fc=98kHz (elog 9062)
    • Measure and characterize the low pass (fc=1.9MHz) just after the demodulator
    • Update the circuit diagram to show the latest condition
    • Make the filter transfer function with dial gain of 2.5
    • Check the gain dependence on the gain dial
    • Measure and characterize the notch filter (utilize earlier measurements?)
    • What is the calibration of the laser fast PZT and the transfer function?
    • Is the low frequency boost useful? (The boost may eat up our phase margin and make the servo unstable.)
    • How to construct the model of the temperature loop?
  • Design and implement better phase compensation.
  • Make a new custom servo circuit.
Attachment 1: open_loop_primary.pdf
open_loop_primary.pdf
  1116   Sat Oct 30 14:09:20 2010 Curious GeorgeLab InfrastructurefubarOld white board

Quote:

RIP Old Whiteboard

I found the old white board and got a photo of the info before the goons who removed it can throw it away.

As a tribute to the old whiteboard, I think that Aidan in particular will appreciate this

 

 Why did we switch whiteboards?

Why would we let them throw this one away?

 

  1115   Fri Oct 29 17:31:41 2010 AlastairLab InfrastructurefubarOld white board

RIP Old Whiteboard

I found the old white board and got a photo of the info before the goons who removed it can throw it away.

As a tribute to the old whiteboard, I think that Aidan in particular will appreciate this

 

Attachment 1: photo.JPG
photo.JPG
  1114   Fri Oct 29 15:34:36 2010 Zach & KojiLaserGYROCCW loop characterization

About two days before this elog post (I am a bad grad student), Koji and I took some more measurements in a continuing effort to fully characterize the CCW (main) loop.

Some things we did:

  • Open-loop transfer function
  • Error signal spectra
  • Calibration using a 1-kHz sine injection

The last two were also done for the CW (AOM) loop, with the second also done with only the CCW loop closed to see the "free-running differential-mode" noise. We noticed at least two interesting things:

  • The CW noise suppression was far from stellar at low frequencies and non-existent above a relatively low frequency (which escapes me at the moment)
  • The 1-kHz calibration line was partially visible in the CCW error spectrum when the excitation was on the AOM VCO. This indicates either electrical cross-coupling or more likely backscatter noise at the cavity input (which surely got worse after we put in windows so that theta = 0 deg). On that note, we may eventually find it necessary to use a different modulation frequency for each of the two directions, but it's certainly not clear that that will be necessary yet.

Since the new front end is not quite up to speed (and due to bandwidth limitations), all of this was done using the Agilent. Due to Koji's far-superior Agilent prowess, he did most of the button-pushing, and he will give me the data once he offloads it so that I can process it.

bart-simpson-generator.png

 

  1113   Thu Oct 28 18:52:16 2010 ZachLaserGeneralLasers were turned off last night for PMA work

I found someone working without safety glasses yesterday evening. I told him he couldn't work without them and he said he was done for the day, but he asked me to see that the lasers were turned off so that he could work early this morning. I spoke with Frank and Koji about it and we decided that we would turn the lasers off to be safe but let the people above us know what happened. We wrote that the lasers were off on the whiteboard in the changing room.

  1112   Sun Oct 24 19:27:44 2010 ranaComputingComputingNow running ELOG 2.8.0
  1111   Fri Oct 22 10:56:51 2010 Rana & AlastairComputingComputingfront-end now working

The front-end code is working again now on FB0.  Many of the folders were owned by root because of some previous badly written documentation - these have all now been chown'ed into submission.  The main lesson learned is: DON'T EVER MAKE THE MODEL AS ROOT!

We now have a really simple route to re-making the model when we have any changes.  This is documented on the ATF Wiki here. Please don't deviate from this process ever.

Dataviewer now works on WS2 (though doesn't work from mainmenu because it doesn't start up grace).  The gyro MEDM screens aren't working right now because I changed some of the parts names in the model.  I also plan on hijacking a few more channels for the gyro before remaking the model again.  There is still an issue with the user accounts on FB0 which needs fixed at some point in the future.

Most importantly we now have a Rana approved color scheme for the terminal shell on WS2.

  1110   Thu Oct 21 12:17:54 2010 FrankComputingComputingDAQ continued

if the boxes of the main screen are white the daqd process will not start. It automatically stops if the frontend code isn't running as it is configured to wait for the right DCU to be up (in that case the only DCU in that system IS the frontend, so it can't be started). Any messages while compiling the stuff? Any errors?  My suggestion: save the current simulink model in a save place, take the last, known to be working version and do all the compiling and see if everything starts. If yes you have a bug in your model, if no the way you compile and start the stuff is wrong.

Once the frontend is running, if the daqd still isn't starting try checking the logfile of the daqd process. it's in the /fb directory. Usually it tells you exactly what's wrong... 

  1109   Wed Oct 20 23:49:54 2010 AlastairComputingComputingDAQ continued

I've been reading T080135 a bit further.  The auto-generated MEDM file in /cvs/cds/caltech/medm/C2/atf/ called C2ATF_GDS_TP.adl is the one that I've been checking to see if the front-end is working properly.  I've checked that this file was generated today when I compiled ATF.mdl, and it was.  I've made sure that the startatf file that I am running is the correct one - first of all making sure /cvs/cds/caltech/scripts is in the PATH (which it is) and secondly trying to do the startatf directly from that directory using ./startatf.  This startatf file was also generated today, so it is not an old version either.  And we still have the same issue that the MEDM screen isn't running properly - all the boxes are just white.

I notice that daqd isn't running again on FB0.  It had definitely started earlier after the reboot.  I did reboot FB0 one more time after this as I left the lab and by the time I got home and checked daqd wasn't running.  I don't know if this is a problem.

  1108   Wed Oct 20 18:43:48 2010 AlastairComputingComputingATF FB0 front-end rebuild

 I've started work on updating the model for our front-end code.  First I want to just rebuild as it is using the existing model.  I'm going to put up idiot-proof instructions on the wiki as I go along.

So far I've tried the method given on the 40m wiki here: http://lhocds.ligo-wa.caltech.edu:8000/40m/Simulink_to_Front-End_code  .  I can get pretty far through these instructions before hitting problems at the point where you copy the .ini file across - at this point I find that the file is not in the location given in the instructions.

The simpler instructions on page 17 of T080135-00-C do work however.  I can get all the way through to the point where i do the startatf command and using ps I can see there are processes with the atf name running.  If I open an MEDM screen there is no data coming in though.  Also the daqd process wasn't running, so I did a sudo reboot on FB0.  When I did this FB0 hung while rebooting.  I power-cycled it and it booted up the next time.  When I ssh into it daqd is now running.  I did startatf again.  When I open MEDM the channels still don't seem to be acquiring.

I wonder whether there is a problem that it is not loading epics BURT data because in the /cvs/cds/caltech/target/c2atf/log.txt the final line, repeated over and over again is "Waiting for EPICS BURT 0"

When I try opening the GDS_TP medm screen it comes up with the error "cannot open file /cvs/cds/caltech/scripts/utilities/nova_logo.gif".  When I check, the utilities folder does not exist.  I tried to see where in the MEDM screen this .gif is supposed to live, but in the end I opted for putting random small gif file in nova_logo.gif in the meantime.  Now the MEDM screen runs without complaining but the boxes are white.

 

  1107   Wed Oct 13 10:08:48 2010 AlastairComputingComputingNetwork diagram

I made a copy of Frank's most recent network diagram in omnigraffle and it is on the wiki here

The .graffle file is there too, so it can easily be updated by anyone as changes occur.

  1106   Fri Oct 8 19:59:00 2010 AlastairMiscGYROSeimometer set up on top of bench / SR560 borrowed from DAQ input channel 13 GYRO

____________________________________________

Borrowed SR560 info

I've borrowed back one of the SR560s.  It was being used between patch channel B5 and channel 13 on the DAQ.  In the MEDM screen channel 13 is writing to GENERIC_DOF5, so that channel will not be doing anything useful just now.  The settings on the SR560 were as follows:

DC coupled

Filter: DC

Input: B

Gain: 2000

Low Noise, Line power

I unplugged it from the setup at 7.28pm on Oct 8th.

____________________________________________

Seismometer

The seismometer is now set up on top of the optics bench.  I notice that at some point (presumably when the SR560 was borrowed?) the power to the seismometer was disconnected.  It's back on now and all three channels are going through their own SR560, set to AC coupled, DC filter, A-B differential input, Gain 200 and Low Noise, Line power.  Measurement began at 7.50pm 8th Oct.  We'll take ~ a week of seismic measurement on the bench and then pass the Guralp back to the 40m.

____________________________________________

  1105   Wed Oct 6 17:06:45 2010 FrankMiscPulserKeithley 2635A i-v curve config files

 - for personal use only -

pd_darkcurrent_100mV_-20V_range1uA_limit1uA.prj

  1104   Wed Oct 6 15:26:56 2010 AlastairLab InfrastructureANTS!insecticide on floor

When the floor got cleaned today we used insecticide in the water.  Hopefully this will improve the ant situation.

  1103   Wed Oct 6 12:23:44 2010 AlastairComputingGeneralInstalled matlab on WS2

Installed matlab on WS2 in /usr/local/matlab.

At first when I ran it the following error came up:

/usr/local/matlab/bin/glnxa64/MATLAB: error while loading shared libraries: /usr/local/matlab/bin/glnxa64/../../bin/glnxa64/../../bin/glnxa64/libtbbmalloc.so.2: cannot restore segment prot after reloc: Permission denied

This is because of a problem with SELinux.  Turning SELinux off using /usr/sbin/setenforce 0   allows matlab to run, confirming that this is the problem.  Following the advice on this page:

http://www.mathworks.com/support/solutions/en/data/1-2SGOXN/?solution=1-2SGOXN

I executed the following commands to get it working with SELinux on.

/usr/sbin/setsebool -P allow_execheap=1

chcon -t texrel_shlib_t /usr/local/matlab/bin/glnxa64/*.so*
chcon -t texrel_shlib_t /usr/local/matlab/sys/java/jre/glnxa64/jre/lib/amd64/*.so

It all seems to be happy now.

 

 

  1102   Wed Oct 6 00:32:45 2010 ranaComputingDAQNetwork Data Server

This is the link to the NDS2 webpage:

https://www.lsc-group.phys.uwm.edu/daswg/wiki/NetworkDataServer2

We should install this so that we can use this modern interface to get data from outside and inside of the lab.

  1101   Tue Oct 5 12:53:26 2010 AidanComputingGeneralAdded link to the users directory in the root directory on ws1

/users links to /cvs/users

(syntax to do this was "ln -s /cvs/users /users")

  1100   Mon Oct 4 23:50:12 2010 ZachLaserGYROCCW-CW crosstalk measurements

 Below is a comparison of the CCW error and CW actuation signal noise spectra, both calibrated into optical frequency noise. For the CCW error signal, this was done by dividing by the cavity response in V/Hz, whereas for the CW actuation signal I simply multiplied by the 100 kHz/V gain of the Tektronix VCO. The cavity response is an estimate based on the recent finesse measurements, and may be off by a factor of 2 or so.

f_noise_CCW-err_vs_CW-act.png

I have been speculating that the CW actuation signal (aka the gyro signal) is dominated by excess noise from the CCW loop. This only appears to be true for a certain few frequency bands, while in other places (especially at low frequencies) it seems that there is other noise coupling in. This could come from anything in the optical path between the initial beam split and the cavity.

I have run into some other strange goings-on with the CW signals. For some reason, the ratio between the CW actuation and error signals does not appear to match up with the measured PDH OLTF (more info on this later).

I hadn't been acquiring the CW error signal, so I decided to look at that today. Below is a plot of the CCW error spectrum, along with the CW error spectrum in three different configurations: one with demodulation completely disabled on the VCO (i.e. loop open), one with G = 4, and one with G = 10. The result makes a little bit of sense in that the CW error noise goes down with increasing G, but it should go down by much more, on the order of the CW open-loop gain. Another interesting effect is that the DC level of the CCW error signal is affected by changing the VCO (on the CW loop, of course) from modulation to continuous or vice-versa. This should in principle have no effect on the CCW loop, and this may indicate some problem with the optical isolation.

I will post more information about the recent measurements and do some more tomorrow.

CCW-CW_err_10_4_10.pdf

 

  1099   Mon Oct 4 15:29:01 2010 AlastairLab InfrastructureGeneralLaser chiller

The chiller unit seems to be emitting a somewhat annoying high pitched whine - way more annoying than it's usual noise.  Maybe someone wants to take a look at this?

DYM - it does the periodically because it doesn't like non DI water - just pressing a button (up or down arrow) on the front panel will disable it

  1098   Fri Oct 1 21:58:29 2010 AlastairComputingComputingwiki

 I've changed the wiki template for one that gives the full screen width.

Also added some more sections and set up the sidebar navigation.  There is now a computing section that we can populate.  The idea is to have first-timer guides for doing all the regular computing jobs that come up in the lab (how to add DAQ channels, how to restart the front-end, how to rebuild the model) as well as places to store more expert information (such as network topology etc).  A lot of this is already there in the elogs and we can just transfer it across.

Again for those that missed it the first time round, the new wiki location is:

https://nodus.ligo.caltech.edu:30889/ATFWiki/doku.php

and you can just ask for a password to be emailed to you by clicking on the login screen.

  1097   Fri Oct 1 13:04:44 2010 FrankComputingComputingno chans in dataviewer

 again, FB1 has NOTHING to do with the realtime system. You will never be able to see channels from the RT system running on FB0 using FB1! It's technically impossible without some additional hardware which we don't have !

Don't touch the daqd on FB1, except when changing environmental monitoring channels or TCS channels !

If you restart FB1 almost any computer has to be restarted too as they share the directory mounted via NFS, not only the ones in the ATF lab ! So, plz, don't touch FB1.

Quote:

On FB1 the process daqd seems to be running okay, but we are not seeing any of our channels in dataviewer.  I tried a DAQ Reload, followed by FE Reset in the master MEDM screen - still nothing in dataviewer.  I used pkill daqd and checked the process had restarted - still nothing.  I rebooted fb1 and checked that the process daqd had restarted - still dataviewer cannot see any of our channels.  I don't see any problems with daqd, it appears to be running and restarting as it should.  daqconfig shows we are set to acquire channels.

  1096   Fri Oct 1 12:28:53 2010 AlastairComputingComputingno chans in dataviewer

Quote:

On FB1 the process daqd seems to be running okay, but we are not seeing any of our channels in dataviewer.  I tried a DAQ Reload, followed by FE Reset in the master MEDM screen - still nothing in dataviewer.  I used pkill daqd and checked the process had restarted - still nothing.  I rebooted fb1 and checked that the process daqd had restarted - still dataviewer cannot see any of our channels.  I don't see any problems with daqd, it appears to be running and restarting as it should.  daqconfig shows we are set to acquire channels.

 Thanks to Aidan, it's up and running again.  FB0 did not appear to be running the front end at all, and using 'startatf' has got it back working.  Next time we have this sort of problem just running a 'ps -e |grep atf' on FB0 should give you back some processes if it is running, otherwise it needs started.  It appears that the FE Reload button on the master MEDM screen is not doing it's job now.

 

  1095   Fri Oct 1 11:53:04 2010 AlastairComputingComputingno chans in dataviewer

On FB1 the process daqd seems to be running okay, but we are not seeing any of our channels in dataviewer.  I tried a DAQ Reload, followed by FE Reset in the master MEDM screen - still nothing in dataviewer.  I used pkill daqd and checked the process had restarted - still nothing.  I rebooted fb1 and checked that the process daqd had restarted - still dataviewer cannot see any of our channels.  I don't see any problems with daqd, it appears to be running and restarting as it should.  daqconfig shows we are set to acquire channels.

  1094   Fri Oct 1 02:02:23 2010 ZachLaserGYROCCW-CW crosstalk

We have been explaining the excess noise in the gyro signal by saying that the residual common-mode noise that isn't removed by the CCW loop "spills over" into the CW loop, causing the CW servo to do what it can to ensure that the beam it controls is as closely matched to the cavity as possible. This effectively results in differential-mode noise, which of course shows up in the gyro signal.

 
It is important to understand what is meant by "common-mode noise". If the loops are ideal, then cavity length changes only affect the gyro signal insofar as they modulate "DC" signals, such as that from the earth's rotation or---more importantly---the 1-FSR shift between the two counter-propagating beams. When the loops are not ideal, the two servos don't do equally well at matching the optical frequencies of their respective beams to the cavity eigenmodes. This means that there is excess noise in the beat signal BEYOND the sagnac shift and the above fundamental noise couplings.
 
This is easy to understand in the case that the gyro is absolutely at rest and there is no FSR upshifting of the CW beam: in this case, ideal loops produce a null output, while non-ideal ones do not (in fact, all that matters in this case is that the CCW loop is ideal; if it is, then the CW error signal is null).
 
Below is the gyro noise/signal diagram that we made a few months ago. Miraculously, it is general enough that it remains accurate despite our vastly different understanding of how noise couples in. The point with the red dot is the point in some abstract space with units of frequency at which the CCW loop influences the CW one. If the CCW loop is ideal, and we ignore shot noise (which is low enough to be irrelevant), then the signal here contains (-1 x): the laser noise, the noise in the optics along the CCW path before the cavity, the common-mode cavity noise, and half the full sagnac shift. When this is summed into the CW servo, it eliminates the laser noise and the noise in all the optics before the beams are separated, as well as the common-mode cavity noise. What is left is the differential noise in the optical paths between the beam separation and the cavity and the full sagnac shift. Since we read out between F2 and A2, we also see the noise in A2 (the AOM and the VCO driving it).
 
If we allow the CCW loop to have non-infinite gain, then the ideally-equal-and-opposite signals are no longer nulled at the summation point, causing the CW loop to work harder than it needs to.
 
This mechanism has been informally verified by simply reducing the gain of the CCW PDH box and watching the gyro noise go up. A more rigorous test, which will also allow us to verify our displacement noise coupling model, is as follows:
 
  1. Take a spectrum of the CCW error signal. This is a measure of the residual common-mode noise.
  2. Calibrate (1) into frequency noise
  3. Take a spectrum of the CW actuation signal.
  4. Calibrate (3) into frequency noise
  5. Compare (1) and (3). We now know if the gyro signal is dominated by spillover noise.
  6. Calculate how much more gain we need in the CCW loop to reduce the spillover noise to below the level of the expected fundamental displacement noise couplings.
  7. Add this much gain.
  8. Repeat (1-5). Now, (3) should not go down if we increase the gain further. We will have reached fundamental noise limit for the gyro without length stabilization.

servo_diagram_dot.png

 
 
  1093   Thu Sep 30 21:09:43 2010 ZachComputingDAQDAQ appears #&*@ed

I'd guess restarting the computer and checking daqd is running when it's reloaded.

Quote:

I was trying to load my error signals into the DAQ. I noticed that they didn't seem to be feeding in correctly (the signal in DV was +/- 1 ct no matter how loud I made the signal). I tried restarting daqd, using FE Reset and DAQ Reload using an admittedly un-systematic approach and this does not seem to work. Right now, it seems that daqd is in a vicious cycle of starting at random times and then closing almost immediately. I do not know what to do.

 

  1092   Thu Sep 30 19:26:57 2010 ZachComputingDAQDAQ appears #&*@ed

I was trying to load my error signals into the DAQ. I noticed that they didn't seem to be feeding in correctly (the signal in DV was +/- 1 ct no matter how loud I made the signal). I tried restarting daqd, using FE Reset and DAQ Reload using an admittedly un-systematic approach and this does not seem to work. Right now, it seems that daqd is in a vicious cycle of starting at random times and then closing almost immediately. I do not know what to do.

  1091   Thu Sep 30 01:01:04 2010 ZachLaserGYROvariation of Alastair's VCO-swap measurement, re-thoughts about readout schemes

 Since we are using the AOM actuation signal readout for the time being, I thought it would be a good time to see what effect AOM/VCO noise currently has on our gyro signal in this readout. My hypothesis was that if VCO noise was currently limiting us in some frequency band, then replacing the Tektronix with a Marconi should reduce the noise there. Alastair did this a while back, but at that point we were reading out in transmission, where the AOM/VCO noise is suppressed by the CW loop gain. When using the AOM actuation signal as the gyro readout, however, we see the full effect of noise in the AOM and VCO. Attached is a noise spectrum with the Marconi in place. Comparing it to the last spectrum, it is clear that there is no change.

gyro_noise_AOM_act_marconi_9_29_10.png

You may be wondering why, if there will be no AOM actuator noise in the final transmission readout, it is that I am even worrying about this at the moment. The answer is that given the recent insight into displacement noise coupling, we may want to reconsider the possibility of using the AOM actuation signal as the final gyro readout after all. Some things to consider:

The main reason we were pursuing the transmission PLL readout was to avoid differential-mode noise incurred in the AOM path, including noise in the AOM itself, noise in the VCO driving the AOM, and noise in the optics encountered only by the CW beam. Analysis showed that this noise is absent from the light emerging from the transmission port of the cavity, so we sought to do the readout at this relatively clean point. The fact is, however, that we will rely on another low-noise oscillator for the PLL, and noise in this oscillator will couple directly into the gyro signal anyway.

What remains is noise in the AOM and from the shaking of the pre-cavity CW mirrors. It may be that noise in the AOM itself is so terrible that the PLL still wins out, but as for phase noise from mechanical displacements, the choice between the two gyro readouts is likely to be a toss-up, as the transmission readout will see the cavity phase noise as described in the recent document on the elog, while (I think) the AOM actuation readout will not. If this effect (not to mention the ADDITIONAL noise contribution of the turning mirrors in the transmission optical demod setup) is of the same order as the mechanical noise in the pre-cavity AOM path, then it may not be worth the hassle to do the PLL at all.

We need to think about this some more, and we should also begin to think in earnest about how we plan to stabilize the cavity via PZT; the conclusion of the displacement noise coupling analysis was that---even with perfect feedback loops---the length of the gyro cavity would need to be stabilized to ~10-12 m/rHz over a wide band in order to reach the sensitivity requirement.

  1090   Thu Sep 30 00:25:31 2010 ZachElectronicsGYROVCO deviation measurements

  Since we rely on our quoted VCO deviation figures of xx kHz/V for the gyro signal calibration, I thought it was a good idea to measure them. I used a calibrator to apply a known voltage to the external modulation input of the VCO and then tracked the peak on the RF analyzer. Attached are the following measurements

  • Tektronix with fc = 47.5 MHz and a nominal deviation of 100 kHz/V
  • Marconi with the same as above
  • Marconi with fc = 95 MHz and a nominal deviation of 375 kHz/V

The first two are in the configuration we use for the driving of the AOM, while the third is what we use for the PLL. I didn't bother doing the Tektronix in the PLL configuration because we will never use it for this. Somewhat surprisingly, the Tektronix is true to its stated value, while the Marconi is a bit under what it quotes. Luckily, they are both linear.

tektronix_47p5.png

marconi_47p5.png

marconi_95.png

ELOG V3.1.3-