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.

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.

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.

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

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.

 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.

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.

  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 f_c = 47.5 MHz and a nominal deviation of 100 kHz/V
• Marconi with the same as above
• Marconi with f_c = 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.

I acquired GENERIC_DOF5_OUT using the GUI and restarted daqd. Everything appears to be working. Current DAQ rate is 953.

I got rid of the trace bar at the bottom, and I've solved the issue that caused the extra navigation bar at the side.  The 'edit' boxes that were appearing on the main page appear whenever you use more than one heading on a page.  I just moved everything on the first page into a table and that has got rid of those.

Other than that the wiki is now ready to be populated.  If anyone has any comments on the wiki send them my way - otherwise I will leave it as it is for people to use.

I've changed the template for the wiki and it now has most of the structure there.  I haven't put up the DAQ stuff yet.

The new template has some weird issues with the sidebar where it is able to go down through the namespace structure but doesn't want to come all the way back up to the root namespace even if you specify the page location explicitly, for example using :home.  For this reason we should only create pages that are inside the namespaces that we are using higher up.

I have set it up with everything inside the namespace 'main' which then contains all the sub-namespaces.  If you just keep to this convention then the sidebar navigation works just fine.  The directory structure is currently like this:

main

    experiments

        ring_gyro

        doubling_noise

        fiber_stabilization

    resources

        atf_internals

            lab_cleaning

            SOPs

            the_lab

            how_to

                computing

There's a couple of other things I'd like to fix with it: the main page has a lot of 'edit' boxes for reasons I don't understand. Also I'm not sure we want the second sidebar box on the left.  The bottom trace doesn't seem to show the full backlink history, it just randomly changes sometimes rather than following the full path that you have navigated through, so we might just switch the trace off.

Other than that I'm pretty happy with the way the wiki works.  It seems to generate nice looking tables and is flexible enough in terms of how the headings look and the sidebar navigation seems nice.

The calibration in the last post was wrong. I was plugging the CW "output mon" into the ADC, while the true servo output had an attenuator between it and the VCO. The plot below is made using the correct output. I have also included the ADC noise and the noise in the AOM actuation signal with the CW PDH box's input shorted.

Note that this puts us within roughly an order of magnitude of the estimated fundamental noise in most places. Extra stuff we expect here that won't be in the transmission readout signal includes the AOM path noise, which could account for some of the surplus we see here, but since the overall shape is very similar to that we saw in the transmission readout a week or two ago, it is likely that we just have more common-mode noise to suppress with the CCW loop. More analysis to come.

 We now have a new ATF wiki running dokuwiki and living on Nodus in the /cvs/cds/caltech/users/public_html/ATFWiki folder.

You can find it here:

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

I've moved some stuff across from the old wiki, though not all of it yet.  I'm not totally sure about the template yet because the sidebar navigation is slightly strange to use.

Yes; this is one of my ideas for things to try...

Make the noise budget of the circuit. That's the only way to reduce the noise rationally.

EDIT: the calibration in the graph below is WRONG. It remains here for now for documentation.

Attached is a current gyro noise spectrum, taken by measuring the noise in the actuation signal to the AOM VCO. By comparison with the previous spectrum, it is clear that the noise has gone down by a factor of ~2 after the modifications we made to the CCW PDH box.

The proposed mechanism for this is that when the CCW loop acts un-ideally, there is some residual common-mode noise that is corrected for by the CW loop alone, which results in an apparent gyro signal. To test this, I reduced the gain setting of the CCW box from 3.5 to 1.5 and re-measured the gyro noise. The result above ~200 Hz makes sense, as the noise goes up in this region by a noticeable amount. Below 200 Hz, however, the noise seems to have gone down. I'm not sure what to make of this at the moment, but I have some ideas for things to try.

For those wondering, we are looking at the gyro noise in this pathway because it is more practical to do it this way right now. The linked entry above shows that the noise in the AOM feedback signal is actually lower than that in the transmission PLL readout, and we have to get some factor of 100 lower until we expect to see benefits in looking at the PLL noise. Also, this rules out calibration errors and the like from things shifting around in the PLL between measurements.

Attached are the new gyro CCW OLTFs with and without the twin-T notch to cut out the 24kHz resonance. The UGF is ~8.5 kHz without the notch and ~12kHz with it. The notch filter needs to be better optimized for the application, as it's not really buying us that much bandwidth at the moment.

In any case, the low-frequency gain is much better now that we have the 1/f² region back in place (see earlier entries). We can now tap the table reasonably hard with a ball driver, drop bolts/BNC adapters onto it, or clang stools around without dropping lock.

The CCW error signal is being acquired and we will post a spectrum shortly.

 We changed feedback resistor R24 back to 1k.  The high frequency weirdness went away.

Next we changed the capacitor C6 to 1.5nF in order to move the pole frequency back up to around 98MHz.  I just bodged in a thin film capacitor for now and we'll replace this with a plastic one.  We then changed R16 to 750k to move the low pole back down in frequency (note - this doesn't quite move it back to where it was before but since this resistor gets switched out by the boost stage it shouldn't be critical).  The box is back in the system and the locking on the CCW loop is clearly better.  Next we'll take a TF of the closed loop gain.

Here is the transfer function for the box as it is now.  We couldn't go down to 10Hz because the box saturates.

• http://www.opticsinfobase.org/abstract.cfm?URI=ol-30-6-646
  • 2005 Marty Fejer paper - page 3 Allan deviation plot (range 0.001 to 50 sec) - I need to figure out what they actually measured (there is only an "in loop" measurement in their diagram
•  http://iopscience.iop.org/1742-6596/32/1/025
  • Glen de Vine paper beating two 1064 lasers, with each doubled output locked to an iodine cell. Page 7 for Allan deviation plot - (range 0.1 to 400 sec) - I believe each laser was independently locked to an iodine cell for absolute freq stability, then the relative freq stability of these two was measured. This would explain why it's such a weak bound
• http://www.opticsinfobase.org/abstract.cfm?uri=CLEO-2007-CTuJ1
  • NIST bound - this is the tightest one I could find so far using doubling - Allan Deviation of 3e-16 at 0.1 sec, and 1e-18 at 1000 sec
  • Also shows up in nature photonics: http://www.nature.com/nphoton/journal/v1/n5/abs/nphoton.2007.71.html
• http://www.hindawi.com/journals/aoe/2008/428971.html
  • Low level look at intensity noise coming out of PPLN - should I bother to reference this in a "people have looked at intensity noise before, I am looking at phase noise" way?
•  http://adsabs.harvard.edu/abs/2007ApPhB..89..167S    App Phys B
  
  • NIST paper on stabilization scheme to measure Hg+ and Cs - With some thinking there might be a bound in here in the noise of the setup they present
• http://prl.aps.org/abstract/PRL/v98/i7/e070801  PRL
  • The Hg+ and Cs comparison measurement - same bound as above possibly?

PREVIOUS BOUND PLOT CONSTRUCTION!

Optics Letters: Iodine stabilization of a diode laser in the optical communication band

• Allan Deviation presented (0.001 to 50 sec)
• URL http://www.opticsinfobase.org/abstract.cfm?URI=ol-30-6-646

Journal of Physics: Conference series (Amaldia): Noise-cancelled, cavity-enhanced saturation laser spectroscopy for laser frequency stabilisation

• Allan Deviation presented (0.1 to 400 sec)
• URL http://iopscience.iop.org/1742-6596/32/1/025

Nature Photonics Letters: Coherent optical link over hundreds of metres and hundreds of terahertz with subfemtosecond timing jitter

• Allan Deviation presented (0.1 sec to 2000 sec)
• URL http://www.nature.com/nphoton/journal/v1/n5/abs/nphoton.2007.71.html

Applied Optics: Frequency stability at the kilohertz level of a rubidium-locked diode laser at 192.114 THz

• Allan Deviation presented (0.001 to 10 sec) - ONLY THE OPEN LOOP MEASUREMENT CONTAINS DOUBLING NOISE - shitty bound
• URL http://www.opticsinfobase.org/ao/abstract.cfm?uri=ao-37-27-6410

Optics Letters: Fiber-laser frequency combs with subhertz relative linewidths

• Phase noise power spectrum presented (0.1 to 10^5 Hz)
• URL: http://www.opticsinfobase.org/ol/abstract.cfm?uri=ol-31-20-3046

Science: Optical Frequency Synthesis and Comparison with Uncertainty at the 10^-19 Level

• Allan Deviation presented (1 sec to 100 sec) - see figure 2 caption
• URL http://www.sciencemag.org/cgi/content/short/303/5665/1843

IEEE Journal of Selected Topics in Quantum Electronics: Design and Control of Femtosecond Lasers for Optical Clocks and the Synthesis of Low-Noise Optical and Microwave Signals

• Phase Noise power spectrum presented (in dBc)
• URL http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1250464&tag=1

BPM Report: Absolute frequency measurements of the 532 nm radiation recommended for the
realization of the metre.

• Allan Variance presented - TERRIBLE bound
• URL: http://www.bipm.org/utils/common/pdf/rapportBIPM/2003/07.pdf

LISA Symposium: Iodine laser frequency stabilization for LISA

• Frequency Noise Spectrum presented
• URL: http://cdsweb.cern.ch/record/1035803

Applied Optics: Interferometric testbed for nanometer level stabilization of environmental motion over long time scales

• Length Noise Spectrum presented (0.0001 to 100 Hz) - infer freq noise by asymmetry of michelson IFO used to measure. Weak bound.
• URL: http://www.opticsinfobase.org/ao/abstract.cfm?uri=ao-47-36-6832

PRL: Ultraprecise Measurement of Optical Frequency Ratios

• Allan Deviation Presented (0.1 to 100 sec) - GOOD BOUND HERE - This is also 1064 to 532 doubling
• URL http://prl.aps.org/abstract/PRL/v88/i7/e073601

Eur Phys Jour D: Optical Frequency Synthesis and measurent using fibre based femtosecond lasers

• Allan Dev presented - references above paper, gives weaker bound
• URL: http://www.springerlink.com/content/uh662r5586205xq8/

Optics Express: Testing ultrafast mode-locking at microhertz relative optical linewidth

• Freq Noise PSD presented - experimental setup diagram doesnt show loops - need to double check that this includes doubling noise
• URL: http://www.opticsinfobase.org/abstract.cfm?URI=oe-17-2-558

I've replaced the 3.3uF capacitor as C28 in PDH box 1437.  The measured open loop transfer function of the box now has a weird resonance up around 70kHz though which I really don't like the look of and it loses a huge amount of phase above this.  Below that frequency it looks very much like the liso model.

Zach and I discussed the options this afternoon and I think that we're just going to replace the capacitor for now.  This option gives us the best phase margin around the frequency where we expect our unit gain (~10kHz).  We can do further modifications later if it's deemed necessary.

Attached are a transfer function and noise estimate for a proposed gyro (TRANS) RFPD circuit, generated by LISO. It is topographically identical to the one that Rana made a while back, with the two following modifications:

• the components have been adjusted to change the resonant frequency from 80 MHz to 95 MHz to reflect the current setup, and
• the "resonant readout" and "AC coupling" inductors have been interchanged, in line with how it is done on the aLIGO board.

Here I have included reasonable series resistances for the large and small inductors.

If you compare with the above-linked post, you can see that the noise is at about the same level, with a slight increase because we are right at the MAX4106's bandwidth limit for the prescribed gain of 450/50 = 9.

I am not sure what the other options for photodetector circuitry are, but it seems that this sort of LC design will work (at least for the TRANS PDs, where the signal will be limited by the shot noise of the REFL PDs that gets imprinted on the cavity light, as mentioned in Rana's post), and it can be done on the aLIGO boards.

 I've taken a look at what we can do to the pdh boxes when we put them back to their 1/f^2 configuration.  We checked the datasheet for the LF356  that's used on the second stage and there is no mention there of problems with gains of <1.

If we leave the second stage as it is then it has a pole at 100Hz and a zero at 98kHz, with the switchable integrator to move the bottom pole down to zero hz.

The first stage is more of a question to me.  Here are the options that I see:

1) Put back the 3.3uF capacitor.  This leaves the upper zero of this stage at 5kHz instead of 98kHz.  Plots 1 and 2 below show the full TF for both stages using this design, with integrator off and on

2) Move the zero frequency of the first stage up by decreasing the capacitor (we probably don't want to decrease the resistor on this one since it's already only 10ohms).  If we go to 160nF that puts the upper zero at 98kHz.  If we leave the parallel resistor at 1k then we get plots 3 and 4.  The pole is now at ~1kHz which is higher than we want.

3) The last option is that we do the same as in 2) but we also change R30 to a higher value to move the pole down.  As Zach predicted setting things up like this will push us really close to 180 degrees of phase if we push the pole right back down to 50Hz (figs 5 and 6), particularly when we put the boost on.  We could move it part of the way back down using some in-between value.

From the plots it looks like fig2 and fig3 have similar gain at low frequency.  Fig 4 does give slightly more phase margin at higher frequency.

I was concerned that what I thought was fractional frequency deviation might be different from clock peoples definitions of fractional frequency stability. I looked around a bit and here is what I found out:

References:

• Characterization of Frequency Stability
  
  • This is the Bureau of standards note debating what standard to use for Freq. Stablity. It  discusses Allan Deviation versus Spectral Noise Density, and their relationship
• The Science of Timekeeping
  
  • AN HP note explaining the relationship between Allan Deviation and Spectral Density - see page 63 for general integral relation between the two quantities
• A Frequency-Domain view of Time-Domain Characterization of Clocks and Time and Frequency Distribution Systems
  • David Allan document explaining the relation between Allan Dev and Spectral Density - He doesn't give the exact form of the transfer function you should apply to get Allan Variance from a PSD, but he shows plots of it which are consistent with the previous analytic form.

I used this to make some plots of the Allan Deviation from my power spectra, the units of Allan Deviation are dimensionless, as its a measure of fractional instability.

I found a typo in the old code, uploaded new plot.

Line / X's are calculated from the PSDs.

Circles are directly calculated Allan Deviations.

Moral: LOOKS GOOD!

 I added some instruction to the ATF internals/scripting bit of the wiki for installing liso.  Since it needs gnuplot and this requires all kinds of other stuff it seemed like a good plan to document it for future generations.

In short the message is simple.  If you're using a mac then you should install X-code from your OSX dvd and then install MacPorts.  Your life will be greatly enriched and future dealings with all things linux will be nicer.

The only request I have is that the final GP diodes have green boxes, because this is boss. I agree that green will clash for our setup, though, so we can come up with another awesome color for the first 4.

Rana was just suggesting to me that since we haven't decided on how to power these things one option is to power them from the NIM crate.  That way we don't have vibrating mains adaptors sitting on the bench and they'll all be powered by the same DC supply.  The only important question is what color of anodizing we want for the front panel?

After lengthy discussions with Rich, Alastair and I have decided that the best course of action (in the interest of time) is to order 4 aLIGO RFPD boards, modified to make room for standoffs so that we can mount it to the box we will design.

Rich seemed confident that our application falls within the capabilities of the board as it is, with the appropriate changes to the components. I have not done the LISO modeling to figure out what needs changing, but I will get on that immediately. I realize that part of the plan was for me to learn to use Altium. I am not opposed to this, but it seemed that holding up the entire experiment so that I could do this in order to reproduce something that already exists was a little silly. I will still start playing with the program to get a feel for it. This way, we can decide if changes need to be made to the prototype boards, and I will have the know-how to do it when we go to finalize the design of the general-purpose PDs.

We are planning to use Front Panel Express's online applet to make the packaging. This is the company that makes all the LIGO panels. We will have BNC out for DC, and two SMA outs for the two RF readouts (of which we will only use one for the gyro applications), and some sort of standard power in jack. These will all be connected to the board via SMP adapters or what-have-you. We should also put an LED on it for style points. We can design the box ASAP and then decide how we want to stuff the board while we wait for the boards and boxes to show up.

Is there anything fundamentally wrong with this plan?

I got the dual head stuff working in the following way:

- downloaded the GeForce 7600 GT drivers for 32-bit Linux from the NVidia website.

- drop into runlevel 3 as root and run the install program from there (after giving it the chmod +x).

- CentOS' native display config program chokes and screws up the xorg.conf. Ignore this and let it pick some cheesy default setting.

- Once logged in in cheesy settings, run 'nvidia-xonfig' to get nvidia driver running. Use the GUI to activate monitor 2. Logout and log back in.

- Run 'nvidia-settings' to set up the dual head appropriately and hit the radio button for Xinerama. Log out and log back in.

[ops@ws1 ~]$ /sbin/lspci -v
00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3)
        Subsystem: Tyan Computer Unknown device 2895
        Flags: bus master, 66MHz, fast devsel, latency 0
        Capabilities: <access denied>

00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3)
        Subsystem: Tyan Computer Unknown device 2895
        Flags: bus master, 66MHz, fast devsel, latency 0
        I/O ports at 8c00 [size=1K]

00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2)
        Subsystem: Tyan Computer Unknown device 2895
        Flags: 66MHz, fast devsel
        I/O ports at 1000 [size=32]
        I/O ports at a000 [size=64]
        I/O ports at a040 [size=64]
        Capabilities: <access denied>

00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2) (prog-if 10 [OHCI])
        Subsystem: Tyan Computer Unknown device 2895
        Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 209
        Memory at b0000000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: <access denied>

00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3) (prog-if 20 [EHCI])
        Subsystem: Tyan Computer Unknown device 2895
        Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 201
        Memory at b0001000 (32-bit, non-prefetchable) [size=256]
        Capabilities: <access denied>

00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97 Audio Controller (rev a2)
        Subsystem: Tyan Computer Unknown device 2895
        Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 209
        I/O ports at 1800 [size=256]
        I/O ports at 1400 [size=256]
        Memory at b0002000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: <access denied>

00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f2) (prog-if 8a [Master SecP PriP])
        Subsystem: Tyan Computer Unknown device 2895
        Flags: bus master, 66MHz, fast devsel, latency 0
        I/O ports at 1c00 [size=16]
        Capabilities: <access denied>

00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3) (prog-if 85 [Master SecO PriO])
        Subsystem: Tyan Computer Unknown device 2895
        Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 217
        I/O ports at 1c40 [size=8]
        I/O ports at 1c34 [size=4]
        I/O ports at 1c38 [size=8]
        I/O ports at 1c30 [size=4]
        I/O ports at 1c10 [size=16]
        Memory at b0003000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: <access denied>

00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3) (prog-if 85 [Master SecO PriO])
        Subsystem: Tyan Computer Unknown device 2895
        Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 225
        I/O ports at 1c58 [size=8]
        I/O ports at 1c4c [size=4]
        I/O ports at 1c50 [size=8]
        I/O ports at 1c48 [size=4]
        I/O ports at 1c20 [size=16]
        Memory at b0004000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: <access denied>

00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2) (prog-if 01 [Subtractive decode])
        Flags: bus master, 66MHz, fast devsel, latency 0
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
        Memory behind bridge: b0100000-b01fffff

00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)
        Subsystem: Tyan Computer Unknown device 2895
        Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 201
        Memory at b0005000 (32-bit, non-prefetchable) [size=4K]
        I/O ports at 1c60 [size=8]
        Capabilities: <access denied>

00:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) (prog-if 00 [Normal decode])
        Flags: bus master, fast devsel, latency 0
        Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
        I/O behind bridge: 00002000-00002fff
        Memory behind bridge: b1000000-b2ffffff
        Prefetchable memory behind bridge: 00000000c0000000-00000000cff00000
        Capabilities: <access denied>

00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
        Flags: fast devsel
        Capabilities: <access denied>

00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
        Flags: fast devsel

00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
        Flags: fast devsel

00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
        Flags: fast devsel

00:19.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
        Flags: fast devsel
        Capabilities: <access denied>

00:19.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
        Flags: fast devsel

00:19.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
        Flags: fast devsel

00:19.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
        Flags: fast devsel

01:05.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A IEEE-1394a-2000 Controller (PHY/Link) (prog-if 10 [OHCI])
        Subsystem: Tyan Computer Unknown device 2895
        Flags: bus master, medium devsel, latency 64, IRQ 11
        Memory at b0104000 (32-bit, non-prefetchable) [size=2K]
        Memory at b0100000 (32-bit, non-prefetchable) [size=16K]
        Capabilities: <access denied>

02:00.0 VGA compatible controller: nVidia Corporation G73 [GeForce 7600 GT] (rev a1) (prog-if 00 [VGA controller])
        Subsystem: ASUSTeK Computer Inc. Unknown device 820d
        Flags: bus master, fast devsel, latency 0, IRQ 50
        Memory at b2000000 (32-bit, non-prefetchable) [size=16M]
        Memory at c0000000 (64-bit, prefetchable) [size=256M]
        Memory at b1000000 (64-bit, non-prefetchable) [size=16M]
        I/O ports at 2000 [size=128]
        Capabilities: <access denied>

08:0a.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 12) (prog-if 00 [Normal decode])
        Flags: bus master, 66MHz, medium devsel, latency 64
        Bus: primary=08, secondary=09, subordinate=09, sec-latency=0
        Capabilities: <access denied>

08:0a.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC (rev 01) (prog-if 10 [IO-APIC])
        Subsystem: Tyan Computer Unknown device 2895
        Flags: bus master, medium devsel, latency 0
        Memory at d0000000 (64-bit, non-prefetchable) [size=4K]

08:0b.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 12) (prog-if 00 [Normal decode])
        Flags: bus master, 66MHz, medium devsel, latency 64
        Bus: primary=08, secondary=0a, subordinate=0a, sec-latency=0
        Capabilities: <access denied>

08:0b.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC (rev 01) (prog-if 10 [IO-APIC])
        Subsystem: Tyan Computer Unknown device 2895
        Flags: bus master, medium devsel, latency 0
        Memory at d0001000 (64-bit, non-prefetchable) [size=4K]

80:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3)
        Subsystem: Tyan Computer Unknown device 2895
        Flags: bus master, 66MHz, fast devsel, latency 0
        Capabilities: <access denied>

80:01.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3)
        Subsystem: Tyan Computer Unknown device 2895
        Flags: bus master, 66MHz, fast devsel, latency 0
        Memory at d0400000 (32-bit, non-prefetchable) [size=4K]

80:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)
        Subsystem: Tyan Computer Unknown device 2895
        Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 233
        Memory at d0401000 (32-bit, non-prefetchable) [size=4K]
        I/O ports at 3000 [size=8]
        Capabilities: <access denied>

80:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) (prog-if 00 [Normal decode])
        Flags: bus master, fast devsel, latency 0
        Bus: primary=80, secondary=81, subordinate=81, sec-latency=0
        Capabilities: <access denied>

Let's see a schematic and what connectors go on the box before making anything. What about the noise and dynamic range spec?

 For documentation and ease-of-access purposes, I have ghetto-scanned the drawing with the specifications of the gyro RFPD board we will need to design the box.

We had some fun with PDH box #1437 (CCW) on Friday. First, we realized that it had 2 poles and 2 zeros, so that it went as 1/f² up to the zeros for the cavity pole. We thought this was unintentional, so we went about changing it. We removed the feedback capacitor in the first filter stage of the box, rendering that stage a unity gain buffer, and then moved the zero of the remaining stage up to where our cavity pole actually is (see previous entry). The new transfer function is below.

It turns out that Rana knew very well that there were two sets of poles and zeros, which shouldn't matter as long as the gain was rolled back to 1/f by the cavity pole before the UGF. We may want to go back to the 2-pole/2-zero topology to increase our low-frequency gain, though since band between the poles and zeros is larger now (due to our shifting the zeros up), the phase will have room to get closer to -180 degrees before the zeros kick in; I will do some LISO modeling.

Here is a plot of gyro OLTF with the above box.

The PZT resonance at ~25 kHz is limiting our bandwidth at the moment. Here is a closeup (forgive the arcane frequency ticks).

This TF was taken with the PDH box gain set just below the point where the system oscillates (@ 25 kHz). We put in Alastair's artisan twin-T notch filter to try and notch it out. This worked reasonably well, but we then ran into problems with a lesser resonance around 17 kHz or so. We may have to make another filter stage for this one (and perhaps fine-tune the original to better match the true 25-kHz resonance). Below is the OLTF with the notch.

The UGF is up slightly, but turning it up any higher than this gives us a 17-kHz oscillation. I am a bit confused about the gain-phase relationship, as it seems---that just below the gain setting that gives us an oscillation---the peaks that are just below unity gain have a reasonable phase margin, while once they hit unity gain the phase jumps all over the place. Need to do more futzing.

i tried to find the optimum combination of L/2 and L/4 together with optimizing the alignment trough the high power PC which we wanna use for the pulsing of the laser.
The polarizer i use is a glan-laser polarizer from Karl Lambrecht with an extinction ration of about 10^5. Without the PC the remaining power in reflection is ~360uW out of 26W (~1:72000).

Screenshot 1 shows the remaining beam:

With the PC in the path and optimized alignment the remaining power is ~130mW, shape of the remaining beam shown in screenshot 2:

 Below is the measured OLTF of the gyro CCW loop. It is admittedly crappy, but I guess the idea is that we can first focus on the high-frequency part---which is actually somewhat clean---and then troubleshoot the lower-frequency stuff later. The main thing to notice here is that the zero we put in the PDH box at a few kHz to negate the cavity pole is not negating anything. Instead, we have a gain that is flat in frequency from there up to wherever the real cavity pole is. This is bad.

The cavity pole estimate we used before is based on the (somewhat higher) finesse we plan to operate with in the future. Since our finesse is quite lower now, our cavity pole is higher, and we must modify the PDH box gains accordingly. I looked through the elog and noticed that we had never finished taking a proper finesse measurement anyway, so I did one this evening. I first used arbcav to simulate the cavity using the most recent T measurements, which are printed and labeled on the cavity mirrors. Below is the output, indicating a finesse of 485.

To measure the finesse, I used the tip Frank had given Alastair about using the known modulation frequency as a reference for converting time to frequency in the sweep trace. In the process, I calculated an NPRO PZT actuation gain of about 17 MHz/V, which is considerably higher than we have been assuming. I used the measured FWHM of the transmission peak (see below) to calculate a finesse of about 400.

This is in the ballpark. Frank suggested that it might be better to use the width of the error response, as the apparent FWHM of the transmission peak is sensitive to the sweep frequency (though I chose the sweep frequency of 10 Hz to be high enough that displacement noise did not distort the peak, but low enough that the peak was symmetric). Using this method, for which I have no figure, I got a finesse that was closer to 500.

I think these measurements bracket the calculated finesse well enough that it can be trusted, so I will modify the PDH boxes to have their zeros at 95 MHz / (485 * 2) ~ 98 kHz.

 The Guralp is now hooked up and recording.  I've put a cover over it and clamped down the cable (time ~11.30am).  The SR560s on all three channels have gain 500, AC coupling, and flat response.

THE 35W LASER IS RUNNING

so plz be careful if working on that table.

Output beam is dumped into the power meter head using one turning mirror. Transmitted beam is used for beam analysis using the WinCam.
Current output power is 31W with rough alignment trough everything.

sorry, did this already earlier this afternoon. Only moved the laser and the first two turning mirrors as they
were in the 35W beam path.

<p>
<table width="98%" cellspacing="1" align="center" style="border: 1px solid rgb(72, 96, 144);">
    <tbody>
        <tr>
            <td style="background-color: rgb(72, 96, 144); color: white;" cellpadding="3px">Quote:</td>
        </tr>
        <tr>
            <td style="background-color: rgb(255, 255, 176);" cellpadding="10px">
            <p>Please wait to mess with the optical path until I take pictures (today)</p>
            </td>
        </tr>
    </tbody>
</table>
</p>
<p>&nbsp;</p>

i re-aligned the NPRO into the amplifier this afternoon after everyone left the lab (and had to open it therefore). That's why i've posted the 808nm warning sign outside at the door. Took only about an hour or so and i removed the sign after work was done. I was in the lab all the time the sign was posted at the door.

So everything is normal, except the 35W laser is running now...

The lab is not out of bounds. Frank is just running the 35W laser overnight.

 I realized that I used the wrong data for the updated "FSR noise" estimate on the SVN NB. I used the MZ noise measurement, but we have been thinking that it is the "single-arm" noise that should be used for this purpose (see the document in the elog). I also added in the phase noise estimate using the MZ measurement, and a plot of the sum of these two mechanical noise contributions. This resulted in another 33-MB addition to the SVN---sorry.

Is the lab now out of bounds?

Maybe we can get an elog post about what's going on and how long it's going to be this way.  Thanks.

Please wait to mess with the optical path until I take pictures (today)

This post will detail the end results of the Mach Zehnder doubling noise experiment.

• I made a full noise budget with the best measurement of Mach Zehnder phase noise that I'm going to get.
• I broke off the leads to one of the oven's temperature sensors.
• At some point after this, one of the Newport 3040 Temperature Controllers failed.
• I added some NTC 833 thermistors to each oven, with beads of epoxy on top of each one
  
  • I make a 4 lead measurement using these with one AD587using 100 kOhm resistors in series - I pull ~ 130 uA from it
  • I use an SR560 to AC couple the signal from the NTC 833's with a gain of 500 and a bandpass from 0.03 Hz to 10 Hz (one pole one zero)
• I took the control signal from the working 3040, and used it to drive the other ovens TEC
• I detuned the oven with the working 3040 so that both ovens produced ~ the same power in green.
  • This means that neither of the ovens are at the peak of their phase matching curves, which has unknown effects.
• I put a line on the laser intensity at 85 Hz to see what the intensity noise coupling is
• I turned the HEPA on and off using its lowest setting, getting these results
  • The low frequency noise (below 1 Hz) seems to go down with the lowest HEPA setting (this doesn't seem impossible)
  • The noise above 1 Hz significantly increases
  • For the subtraction, the intensity noise line shows up at about 23 dB above the background, I think we are intensity noise limited but need to double check the line height (easy to do).
  • The high frequency limit is much higher than the results in the "full noise budget", so even if it is intensity limit, it could be the oven detuning which changes this coupling drastically. I can't say that in the good measurement we are limited at high frequency by intensity noise.
  • I believe we are limited by air currents below 10 Hz
  • I think that the noise going up below 1 Hz when we turn the HEPA to "OFF" is not inconsistent with being limited by air currents. It's just like asking "if you took a fluid, could you decrease the temperature variation at one point by stirring it". I think the answer is maybe. I also think that thinking about it too hard will be a waste of time, and that the result is "temperature fluctuations from air currents are the limiting noise coupling, and better ovens / a better box (vacuum) would fix this.

Update - I have uploaded an omnigraffle diagram onto the svn. /trunk/docs/DoublingNoise/MZFullDiagram.graffle. I have tried to make it semi comprehensive in terms of gains, settings, and part numbers.

A few things that happened today:

We preamplified the gyro signal into the DAQ using an SR560 with G = 500 and found that the noise floor from the previous measurement was still there. It was slightly lower, as we were in fact within a factor of 2 or 5 of the DAQ noise, but it was there.

We discovered that the low-noise spectrum was indeed too good to be true as we were able to reproduce the noisier spectrum by increasing the gain in the AOM loop (that is, we probably had the gain set too low during the past few measurements, so that there wasn't much of a gyro signal and we were therefore only seeing phase noise).

To make sure that we were actually measuring what we want, I fed the AOM actuation signal (the other viable gyro signal candidate) into the DAQ so that we could compare it with the PLL readout signal. Remarkably, the UN-calibrated spectra for these two signals are almost smack on top of each other, which shows qualitatively that they contain the same information up to a gain factor (at least up to around a kHz, above which the AOM drive is actually quieter). The uncalibrated spectrum is below.

Upon calibrating, however, the AOM drive signal purports to be quieter in broadband. I am hesitant to believe that this is physical given how well they match up in the above figure. If it is not real, then our calibration is off on one or both of the signals. The calibration for the transmission output is the 3.09 x 10^-4 (rad/s)/ct we have had from before, while for the AOM loop it is 6.103 x 10^-4 V/ct * 100 kHz/V * lambda * P /(4A) = 8.225 x 10^-5 (rad/s)/ct. Here is the calibrated spectrum.

Either way, BOTH of these spectra are way too noisy. What I suspect is happening is that there is residual noise that is not canceled by the CCW loop that spills over into the CW servo. This is another way in which displacement noise can directly couple into the gyro signal. I will get with Rich tomorrow about the PDs. 

I repeated the HEPA on/off test on the "low" setting several times. Here are the results.

First plot is phase noise.

Second plot is temperature noise (read with an NTC 833 atttached to each oven, AC coupled into the DAQ with an SR560).

High frequency noise seems consistently higher with HEPA on. Low frequency noise seems a tiny bit lower (factor of 2) with the HEPA on, though I don't think this really matters insofar as drawing conclusions about what the sources of noise are for us at low frequency.

Below is a measured gyro spectrum from today, plotted with the expected displacement noise sources as described in the document here. It is much quieter than we have had it before, though it has been reproduced enough times for me to believe it is in fact real. It occurs to me that we are now very close to the DAQ noise level, and this could be the broadband noise floor we are seeing. The few spikes above this floor are still a bit higher than calculated, but not by enough that calibration error in the noise estimates are inconceivable.

We may have accidentally done something to dramatically reduce some unexpected noise coupling by messing with the servo settings in both the locking loops and the PLL. We should preamp the gyro signal into the DAQ and get a real spectrum immediately.

I am in the process of fixing the userID and groupID numbers on the controls accounts so that the disk permissions are all good. In the meantime, things will be broken on ws2.

ws1, we are completely wiping to upgrade from Fedora 6(?) into CentOS 5.5. Unfortunately, its 32 bit and will need different apps. I will ask Joe to buy us a new workstation which can be 64-bit.

So in the meantime, you should ssh -X into fb1 to run DTT. You can also run DTT from nodus and just set its NDS server to point at the ATF. Or just use mDV and make a 'gyronoise.m' file and upload it to the SVN so that we can all use it.

 I've added an appendix to the GyroDoc describing the reference cavity stabilization idea. It will need to be fleshed out some more once we've revised the section on displacement noise.

It turns out we would need a length stability of ~6.5 x 10^-14 m/rHz from around 0.01 - 1 Hz with a 20-cm reference cavity. I haven't found a low-frequency spectrum of the PSL refcav, but I know who might have one...

  Attached is a short document analyzing the coupling of displacement noise to the gyro signal. It is not intended to be as formal as it may look; my idea was to have a note that sums up our current understanding of the effect. We can now bicker over which parts are right and wrong and decide what we want to actually go into the GyroDoc. While it is nice to have a "living document" that changes as our understanding does, it pays to have a brief think about what we're going to put into the real document beforehand. It appears to have already devolved into near-chaos, and it would be nice for the thing to be of some use when we're done.

Dmass, I tried to zip this and reupload but the elog rejected it for some reason. Your fault for using full view, heh.

The gyro is "gyrating" again (that was for you, Alastair). I have no access to DTT at the moment but I plugged the gyro signal into the SR785 and it appears to be reading something physical. I tapped on some of the output demod optics to see if I saw peaks, which I did. As soon as I can get into DTT again, I will post a new spectrum.

As an update, we have not produced a real gyro spectrum since having installed the windows. When we tried, we got something that looked unphysically low-noise. The problem is not that we think it is too low-noise to be real, but rather that the last time I realigned the cavity---BEFORE installing the windows---I got a similar too-good-to-be-true spectrum. So, if the noise is indeed this low now, it is not because of the windows but instead due to my rockstar alignment skittles.