40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  ATF eLog, Page 1 of 55  Not logged in ELOG logo
ID Date Author Type Category Subjectdown
  2236   Mon Aug 13 01:53:21 2018 ranaDailyProgressWOPOzero-span spec OR RF bandpass

I know the squeezing people often use the zero-span feature of a spectrum analyzer to produce their McDonalds plots, but why not just use a LC bandpass (e.g. a 1 MHz wide mini-circuit filter)?

The transimpedance amp could drive a mini-circuits amp which then drives the bandpass into a RMS->DC circuit (some diodes). Then you can plot it on a scope easily. Maybe not worth it for this first measurement.

  2237   Mon Aug 13 15:43:55 2018 ChrisDailyProgressWOPOzero-span spec OR RF bandpass

It's also been done with the AD8361 eval board, for the 40m squeezer way back when. (login reader/password readonly)

Quote:

I know the squeezing people often use the zero-span feature of a spectrum analyzer to produce their McDonalds plots, but why not just use a LC bandpass (e.g. a 1 MHz wide mini-circuit filter)?

The transimpedance amp could drive a mini-circuits amp which then drives the bandpass into a RMS->DC circuit (some diodes). Then you can plot it on a scope easily. Maybe not worth it for this first measurement.

 

  2242   Mon Aug 20 12:08:17 2018 awadeDailyProgressWOPOzero-span spec OR RF bandpass

zero-span is just for a quick and dirty measurement.  As long as the there is ok noise clearance its usually enough to see what is going on.  Chris's AD8361 seems good as well, will just require some extra building.

Not sure what the best BW is to work with 300 kHz - 1 MHz is ok I guess.

Quote:

I know the squeezing people often use the zero-span feature of a spectrum analyzer to produce their McDonalds plots, but why not just use a LC bandpass (e.g. a 1 MHz wide mini-circuit filter)?

The transimpedance amp could drive a mini-circuits amp which then drives the bandpass into a RMS->DC circuit (some diodes). Then you can plot it on a scope easily. Maybe not worth it for this first measurement.

 

  1143   Sat Nov 6 23:48:02 2010 ranaComputingComputingws1 is back, almost

The network interface for ws1 was failing to work for some reason. I tried the usual Linux forums for advice but most of it was useless.

Finally one of them suggested that there was a warm power up v. cold power up issue with the Realtek 8169 Network card chipset.

So I turned off the machine and then reformatted the disk and did a fresh install. The network is now working (allowing this elog access).

But then...I realized that (someone) gave me a 32-bit install DVD and so I'm now wiping it and starting over.

  1067   Mon Sep 20 13:29:53 2010 ranaComputingComputingws1 device query (this is very uninteresting)

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

  998   Fri Aug 27 16:55:55 2010 FrankComputingDAQworking mDV example

i've tested it again and it's still working. You can find a simple,  working example for mDV getting some trend data for two of my channels a couple of days ago attached here: temp_test.m

 you have to change the mdv_config file to point to 131.215.115.216:8088 instead of the 40m framebuilder

Quote:

Still having issues, but now more stuff is not working. Yesterday evening before I left, I noticed that I could load realtime data in DV, but not trended playback (didn't try raw). Still the same issue from here in FL: I get "NO DATA FOUND". I have verified that my channels are active and acquired.

As far as mDV is concerned, I don't get an error anymore when trying to get C2 data with get_data, but instead it just freezes at "C...". Now ligoDV doesn't work, either; it just spits out errors.

I want to try DTT, but without any time series data I don't know of a good time to try taking a spectrum. Is anything working for anyone?

Quote:

Seems to be working now for me. Maybe Zach can tell us when he gets to Fla if his issues are resolved post reboot.

 

 

  911   Sat Aug 7 13:45:13 2010 FrankLab InfrastructureGeneralwireless GPIB network devices now available

i finished configuring the wireless bridges and the gpib-to -network adapters. The adapter have ip-addresses from 10.0.1.40 to 43.
All of them are online right now, but only the device with IP 10.0.1.43 is physically connected to an intrument right now.
The SR785 in the PSL lab has the IP 10.0.1.43, the other ones have to be installed at the instrument.

Once we've done that we should come up with some names for those devices, e.g. SR785-PSL, SR785-ATF  or so, so that we do not have to remember the ip addresses all the time.
I hope we can use the names with the script too, i didn't try it so far.

  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.

  908   Fri Aug 6 00:44:06 2010 FrankLab InfrastructureGeneralwifi bridges configured

see elog entry here : http://nodus.ligo.caltech.edu:8080/PSL_Lab/257

  1544   Tue Oct 4 18:27:57 2011 ZachLaserFuglywhy should a laser do this?

The gyro was dismantled during the installation of the PMC (which itself has been uninstalled---see long overdue elog post next). I have plans to clean every optic and reconstruct the gyro, possibly on the HEPA bench where the 35W was, because we think scattered light may have been an issue.

Before doing so, I wanted to take the clear table space as an opportunity to run some tests. We have already seen that clipping on the faraday isolators can be a problem, and this is why we chose to move them so that they are on the waists of the beams within the MMTs. This may not have done enough, and FI clipping could still have been the cause of the LF noise. So, I figured I would make a simplified setup to lock just the CCW direction in reflection without the need for isolation (just put a PD after reflection off of the input mirror). We have seen that the lock strength (as measured by the TRANS_DC noise) is correlated with the gyro noise in the LF region, so I believe that if we build the simplified setup and observe a different TRANS_DC noise shape, it tells us something about the LF noise mechanism.

So I calculated an MMT solution and put everything out on the table, aligned the input beam to the 00 mode and began scanning, but I didn't see any REFL dips whatsoever. Worse, I saw some bizarre sawtooth-like pattern in the REFL power at the laser sweep frequency. I tried 3 different PDs and it was still there, and then I moved the PD way back to just after the initial PBS and it remained. Below is a picture.

TEK00006.PNG

WTF?

  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?

  1620   Wed Feb 22 01:46:43 2012 ZachLaserGYROviewports finished

I picked up the finished parts for the new gyro vacuum chamber viewports from Mike Gerfen today. They look nice. Here are a few pictures---you can compare with the design if you like.

vp1.png vp2.png

vp3.png vp4.png

The parts, as seen in the top left picture are (clockwise, from bottom left):

  • Delrin outer brace to hold the mirror in place at atmosphere
  • Steel CF338 blank machined to have a beam hole in the middle and 4 1/4-20 tapped holes for mounting the delrin brace
  • Small, stiff viton o-ring for the vacuum seal between the window and the steel flange
  • Larger, soft o-ring for the (non-vacuum) seal between the delrin brace and the window
  • Thin (~few 1/1000") teflon gasket that prevents metal-on-glass around the circumference of the viton o-ring upon compression

The (almost ridiculous looking) assembly is best seen in the "hamburger" shot at bottom left.

I will begin cleaning and mounting the viewports tomorrow, after which I can put the new ATFilms mirrors into the chamber, break rotation sensitivity records, etc.

  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.

  1625   Mon Feb 27 17:19:12 2012 ZachLaserGYROvacuum longevity

Not very good. When I got in this morning, the pressure had been reduced by another factor of 2 or so to 6 uTorr, which is good. I closed the valve to the vacuum pump to see what happened to the gyro vacuum. In a matter of a few hours, the pressure increased up to about 2 mTorr.

So, either ~mTorr-level vacuum is sufficient for gyro operation --OR-- we will need to keep a turbo on the gyro system for maximum sensitivity. Of course, it could turn out that the mechanical noise from the pump is the worse of two evils, but we'll cross that bridge when we come to it.

  1182   Tue Nov 30 11:03:55 2010 AlastairThings to BuyGYROvacuum gauge for gyro system

 I realised that I had not bought a vacuum gauge for the gyro system.  The simplest solution seemed to be to use a wide-range gauge so we don't need to worry about damaging the gauge if the pressure creeps up too high.  I've ordered a combination gauge from Kurt Lesker that gives atmosphere down to 1e-9 Torr with an analogue output so we can hook it up to a DAQ channel.

  1563   Tue Nov 8 00:20:47 2011 ZachLaserGYROvacuum chamber prepped

I cleaned the four corner chambers of the vacuum tank today in preparation for the reinstallation of the mirrors. Specifically, I:

  • Cleaned the interiors of the chambers using cloths soaked in acetone, and then with cloths soaked in methanol
  • Cleaned the viton o-rings with a 10-minute DI-water ultrasonic bath, followed by an isopropanol wipe

I began placing the mirrors and aligning the cavity beam, but I am a bit disturbed by the way we have been forced to mount them to the chamber breadboards. The mirror bases have the three-point design so as to avoid over-constraining, but this means that the tips of the dogclamps must be placed precisely to avoid tipping the mirrors or applying undue stress. It appears that the silvered screws we are using are a bit too short for the dogclamps to be set properly (i.e., so that only the tip pushes the base, and the arm doesn't pull on it at all).

I would like to find some longer silvered screws. Perhaps there are some at the 40m...

  1624   Sun Feb 26 02:23:27 2012 ZachLaserGYROvacuum bettered, PDH2 commissioning begins

Vacuum

When I checked the pressure on Friday when I got in, it was at ~1.5 mTorr (not much better than the 2 mTorr I had left it at the night before). I again tried spraying some isopropanol into various vacuum seals to see if the pressure responded, and again the pressure surged when I got to the same input-side viewport copper CF seal. I tightened one bolt at random and the pressure dropped instantaneously to 1.00 mTorr, but not below. I thought this was suspicious, so I looked over the vacuum gauge manual and discovered that the ion gauge had not actually been engaged (i.e., only the less sensitive convectron gauge was on). I turned on the ion gauge and the pressure read in the 10-4 Torr range and dropping.

Eventually it leveled off at ~13 uTorr, which is over an order of magnitude better than we've ever done. My guess is that there had just been some pesky leaks that we never fully sought to fix.

vac_level.png

 

PDH2 commissioning

While letting the vacuum system equilibrate, I decided to start trying to get the PDH2 servo online. Recall that I am now using the second uPDH box (#2215) in conjunction with the OMC HV driver to lock the PMC, and therefore only have one other uPDH box free to use for the gyro. The idea is to use this other box (#1437) to lock the secondary (AOM) loop, where high gain is not as critical, while using the PDH2 to lock the primary loop, which needs high gain for common-mode noise suppression.

I do not want to use the ATFilms mirrors outside of the vacuum, so I will save them until the chamber is ready. Instead, I felt the easiest thing to do was to set up a mock gyro cavity outside of the vacuum system. I used the mirrors from the old setup, in a rectangular configuration that is equivalent to one half of the original gyro (i.e., roundtrip length is ~1.5 m, only one curved mirror). The only major difference is that it is now strongly overcoupled instead of nearly critically coupled, and it allowed for me to just use the old modematching solution simply by rotating a turning mirror and placing the input mirror the proper distance from the final lens. Voilà.

test_cavity.png

I aligned the cavity, isolated a TEM00 mode and then attempted to lock. Things got nasty. The most immediate problem is that cavity sweeping is very delicate through the PMC. Whereas I needed (read: enjoyed) a full 5-Vpp, 30 Hz sweep of the laser PZT to optimize the error signal before I had the PMC, I can now only manage about 0.5 Vpp, and even then there are nasty power dips in PMC_TRANS. This is crap. I have measured a PMC loop UGF of ~4 kHz, but apparently this isn't really good enough.

Painstakingly, I used the slow laser control to put the 00 flash within my puny PZT range, and was able to get the demod phase set roughly right. I connected the PDH2 and it immediately railed, taking the PMC lock out with it. There are two problems here:

  1. The PMC loop is too slow and/or feeble to handle the necessary upstream frequency shifts -AND-
  2. The PDH2 has an irresponsibly high DC gain. This was the problem back when I was testing it originally, and it looks like I will just have to adjust the circuit so that it is slightly lower. My guess is that a ~20 dB reduction should do the trick.

In any case, since the cavity alignment hadn't been optimized yet, I decided to lock it with the other uPDH servo (that I had already been using to lock the gyro cavity). It did, intermittently, but it looks like the in-air noise is just too high. The PZT control voltage was going from rail to rail within a few seconds, and that was also causing the PMC loop to buckle.

Action items:

  • Vacuum system
    • In-situ baking with heating tape (~1 day)
    • Remove pump and test longevity (since the baseline plan is not to keep the pump connected if we don't need to)
    • Clean mounts and mirrors and install
  • PDH2
    • Put a makeshift enclosure around the test cavity to reduce the displacement noise level to something manageable
    • Use the uPDH box to lock it, and engage the slow feedback so that I can actually finely align the cavity so it is more stable
    • Reduce the PDH2 DC gain and use it to lock the test cavity
    • Characterize the PMC loop's tracking ability
    • Optimize PDH2 servo TF for the new setup

If the vacuum stuff gets done much sooner, then I'll do the rest of the servo testing/commissioning on the real McCoy.

  1343   Mon Mar 7 19:16:26 2011 Zach LaserGYROvacuum = better

 Well, I was here until just about sunrise this morning trying to get my head around how the error signal should change with the optical gain (among many other things---I am not that dense). After a while I realized that increasing the optical gain should have no effect on the error signal; therefore, dividing the error spectrum by the increased optical gain results in a cavity noise spectrum that is lower by exactly the same amount.

Between my last post and last night, I realized that somehow I had nudged the PD---it wasn't properly fastened to the table---and so I didn't have the full REFL power on the diode. Whoops. I now need -12 dB of attenuation between the PD and the mixer to keep the loop stable with 100 mW input power, and I have removed the Cougar, so there's an additional 10 dB. (Actually, though I did remove the Cougar from PD S/N 01, I have replaced that PD altogether with PD S/N 02---which never had a Cougar in the first place---because I have taken a reliable transfer function of it and am confident with its tuning. I will make a post dedicated to that shortly.) What this means is that we now have ~10 dB higher optical gain than we did in that post, which is good. I am going to get a good measurement of the OG once the gyro is finished being built for the spillover estimate.

One of the things that was puzzling me last night was why, if I had increased the optical gain, was there no more improvement in the low-frequency noise? I have no plot for this, but I expected to see more low-f improvement like I did in the linked post when I added gain up front and attenuated the electrical signal by the same amount. This didn't happen, and it was frustrating. Today, Alastair pumped the chamber down, so I thought I would remeasure the error signal spectrum to see any changes. The results are good(!):

prim_error_signal_air_vs_vacuum_3_7_11.png

The noise at low frequencies (which seems to have come from the air) is lower, and so is the noise in the high audio band, which might have come from acoustic buffeting of the cavity optics). This shows that I didn't see any further improvement in the low-frequency region because I had already reduced the effect of electronics noise below the level of environmental noise. I am interested to see if this new low-frequency level is once again the PD noise or instead the lower environmental noise level in vacuum. The former will be limited by the amount of optical gain we can put up front; the latter we can reduce by increasing our OL gain at the servo (but, of course, we can only improve it to the point that it is lower than the PD noise).

Since the breadboard version of the PDH2 has turned out to be a real pain in the ass, I think I will opt for Frank's idea which is to simply modify the #1437 FrankenPDH box further to include a switch that disengages the low-frequency-gain-limiting resistor of the traditionally non-switchable stage. This will give us an extra factor of 1/f below 50 Hz so that we truly have 1/f2, and it should be enough to reduce common-mode environmental noise to below our other noise sources at this stage.

  1843   Tue Sep 17 14:19:40 2013 SteveLab InfrastructureGeneraluse clean cover to keep optics clean

Quote:

[Eric G, Tara, Evan]

We have covered both optical tables with drop cloth in preparation for tomorrow's sprinkler installation. The laser and all electronics on the tables have been switched off, with the exception of the rubidium standard. The gyro HV supply in the rack has also been switched off.

 CP STAT 100 is the right material to use on optical tables. You can borrow some from the 40m. You guys should have a roll in the basement. Buy a roll that is cleaned to class 100 and certified

at CALTEX Plastix Ins

 

  1335   Thu Mar 3 00:59:29 2011 ZachLaserGYROupgrade continues

 I made some more progress on the gyro upgrade today:

  • I found some LM317s at the EE stockroom and put one on the second PD board. I also stuffed it with everything else we need besides the Cougar AP1053. It looks like we won't have one for a while, so I bypassed the Cougar footprint with a wire. I also borrowed another Perkin-Elmer C30642 from Frank/Peter, so this board is now ready for testing at the 40m tomorrow morning.
  • I made some more SMP -> SMA cables for inside the PD boxes:

SMP_SMA.png

  • I also borrowed a 9-pin D-sub breakout board from the 40m, which enabled me to use the first PD in its fully assembled form (with the exception of the BNC for DC out---for this we will need to connect the bare leads of a BNC feedthrough to an SMP connector on the board). The gyro cavity is currently locked in the CCW direction with PD S/N 01, and the error, control, TRANS DC and REFL DC are all being sent to the DAQ (the DC out of the PD is being monitored using the breakout board). Some shots:

PD_with_back1.pngPD_with_back2.png

signals.png

Signals -- Yellow: REFL DC, Blue: ERR, Magenta: CTRL, Green: TRANS DC

  • I got started with building the temporary breadboard version of the PDH2 servo. It should be done by tomorrow.
  • Tomorrow:
    • Take PD S/N 02 to the 40m and take a transfer function, tune it, and put it in its box
    • Finish building the PDH2 servo, take TF and noise spectrum
    • Install CW MMT and isolation optics
    • Lock cavity in both directions
    • Get new spectrum
  417   Fri Oct 30 21:26:10 2009 FrankComputingGeneralupdated network schematic

here an updated version of the network schematic. Some upcoming changes are already integrated, e.g. the fiber to peter's lab. This will be probably installed on monday. The video server device might be installed next week as well. More details on this soon.

devices which have more than one network connected are marked with two (different) colored IP addresses. 10.0.0.xxx is peters network, 10.0.1.xxx is the ATF network

Adhikari-lab-network_v2.1.jpg
.

 

 

  609   Thu Feb 18 18:14:20 2010 ZachLaserGYROupdate (AOM)

 Alastair and I have been working on getting the AOM double-pass setup going. We have borrowed a curved Y1 from Peter to use as a retroreflector while we wait for the one we ordered. We are using a Tektronix FG through the 2-W MiniCircuits RF amp on the shelf to drive the AOM at the moment, and that appears to work decently well. We are running into issues with alignment, however.

Right now, we can get the 1st-order beam isolated with an iris and reflected back along the same path back into the AOM, but what comes back out isn't very clean. What we should see is the singly diffracted beam that gets reflected straight back through the AOM (without a second diffraction), and then the doubly diffracted beam--what we want--which should be a little dimmer and should lie exactly along the input beam. We tried lowering the AOM drive power until only one beam was left (the single-pass beam), but this never happened; all we got was something that looked like two dim beams close together or one very elliptical one.

We think it is because we don't have any way of adjusting the orientation of the AOM at the moment. Alastair has drawn up a new mount which will allow us to put a tilt stage on top. In the meantime, we will try to get something remotely reasonable out and attempt to lock the cavity with that.

  615   Fri Feb 19 10:22:26 2010 AlastairLaserGYROupdate (AOM)

Quote:

 Alastair and I have been working on getting the AOM double-pass setup going. We have borrowed a curved Y1 from Peter to use as a retroreflector while we wait for the one we ordered. We are using a Tektronix FG through the 2-W MiniCircuits RF amp on the shelf to drive the AOM at the moment, and that appears to work decently well. We are running into issues with alignment, however.

Right now, we can get the 1st-order beam isolated with an iris and reflected back along the same path back into the AOM, but what comes back out isn't very clean. What we should see is the singly diffracted beam that gets reflected straight back through the AOM (without a second diffraction), and then the doubly diffracted beam--what we want--which should be a little dimmer and should lie exactly along the input beam. We tried lowering the AOM drive power until only one beam was left (the single-pass beam), but this never happened; all we got was something that looked like two dim beams close together or one very elliptical one.

We think it is because we don't have any way of adjusting the orientation of the AOM at the moment. Alastair has drawn up a new mount which will allow us to put a tilt stage on top. In the meantime, we will try to get something remotely reasonable out and attempt to lock the cavity with that.

Yes, the mount for the AOM sucks ass.  I drew up a new one last night that will incorporate one of the New Focus 9082 alignment stages.  It's with the machine shop now so we should have it towards the end of next week.  I also ordered the alignment stage from Newportfocusnew (as I will now be calling them).

Attachment 1: AOM_mount.pdf
AOM_mount.pdf AOM_mount.pdf
  617   Mon Feb 22 13:24:04 2010 AlastairLaserGYROupdate (AOM)

Quote:

Quote:

 Alastair and I have been working on getting the AOM double-pass setup going. We have borrowed a curved Y1 from Peter to use as a retroreflector while we wait for the one we ordered. We are using a Tektronix FG through the 2-W MiniCircuits RF amp on the shelf to drive the AOM at the moment, and that appears to work decently well. We are running into issues with alignment, however.

Right now, we can get the 1st-order beam isolated with an iris and reflected back along the same path back into the AOM, but what comes back out isn't very clean. What we should see is the singly diffracted beam that gets reflected straight back through the AOM (without a second diffraction), and then the doubly diffracted beam--what we want--which should be a little dimmer and should lie exactly along the input beam. We tried lowering the AOM drive power until only one beam was left (the single-pass beam), but this never happened; all we got was something that looked like two dim beams close together or one very elliptical one.

We think it is because we don't have any way of adjusting the orientation of the AOM at the moment. Alastair has drawn up a new mount which will allow us to put a tilt stage on top. In the meantime, we will try to get something remotely reasonable out and attempt to lock the cavity with that.

Yes, the mount for the AOM sucks ass.  I drew up a new one last night that will incorporate one of the New Focus 9082 alignment stages.  It's with the machine shop now so we should have it towards the end of next week.  I also ordered the alignment stage from Newportfocusnew (as I will now be calling them).

 That's the 9082 stage arrived now.

  653   Mon Mar 8 21:54:01 2010 ZachLaserGYROupdate

This morning, I did some more realigning to make the CCW lock a bit stronger. It still sucks, largely because of the 25 kHz PZT resonance which keeps us from upping the gain enough to suppress the rampant acoustic noise. We will soon have optimized our servos for the final setup, and by then we'll have this taken care of.

I then got to work on the CW (AOM-passed) beam. I maximized the power in what we have thought was the double-pass beam since last week by adjusting the AOM alignment, and sent it into the cavity. I have had a suspicion that this was actually the single-pass beam sent straight back through as I couldn't replicate the pseudo-lock that I had in this post after having lost that first alignment. Once I had a decent 00 while scanning the cavity, I locked the CCW path and tuned the frequency across the full AOM range but was unable to transmit a 00 mode. The closest thing I could get was a pretty strong 11 mode, so I knew something was off..

My suspicions were confirmed when I found this plot from an old elog post, which showed that the 11 mode lay just about 1/2 an FSR from the 00: wrong beam. I then isolated and maximized power in the other beam emerging from the AOM, sent it into the cavity and was able to duplicate the configuration from the other day.

The next step was to attempt to actually lock the CW beam. Last Friday, Alastair and I discovered that something is fishy with the bluebox that Rana modified. For some reason, it seems to oscillate at high frequency (~100-200 kHz) with any appreciable gain. Even worse, the 'PZT Sweep' function appears to be stuck on. Of course, the first problem might be an artifact of the second, but we'll see.

In the meantime, we tried to use an SR560 to lock it. We had everything hooked up when we noticed that the error signal signal was nonexistent. We believe this is because---as a result of absolutely no modematching in the CW path---the REFL beam is hella too big to fit through the faraday on the way back out, so the full power we can get onto the REFL_CW PD is still not enough (even with no screening). Alastair is planning to work out a reasonable telescope for the CW path tomorrow, after which we hopefully be able to get a usable signal. I will also try to find Rana and work out what is happening with the bluebox.

  1163   Thu Nov 11 23:15:14 2010 ZachLaserGYROupdate

 [Zach, Koji]

Yesterday, we replaced the CW REFL PD with the second PDA225. We noticed that turning it on made the output rail so we did some debugging and found that the switch was broken. Koji did some magic and got it working again. We also changed the CCW REFL setup so that we could point the beam at the PD better (before, we didn't have room for a full mount between the faraday isolator and the gyro enclosure, so we had fixed up a lens mount to do the job and had to use the focusing lens and PD height to center the beam).

The InGaAs diodes have a much better response to 1064 nm so---even with the maximum screening from a Y1S-45---we had to reduce the input power to the experiment in order not to cause the loop to oscillate. (This was, of course, after we turned the gain of the PDH box all the way down to "0.0". We should modify the PDH box to have lower gain so that we can turn up the optical power without the loop becoming unstable).

We hooked everything up and got the gyro fully operational again, with both directions locking well. The measured primary loop had a UGF of ~12 kHz with a puny phase margin of ~8 deg. The thought here is that we should swap out the slow OP27s in the PDH box for faster op amps  (in the short term) and eventually design our own servo.

We also noticed that there was a significant DC offset in the primary error signal. We guessed that this was from RFAM from the EOM, so we adjusted the orientation of the HWP before it to minimize it.

We hooked the following signals up to CDS:

ADC:

  • Both error signals
  • Both feedback signals
  • TRANS DC
  • Primary PDH box TP2 (for OLTF measurements)

DAC:

  • TEMP control out (this has been there, of course)
  • PZT SWEEP out

Today, I came in to find that the gyro was not locked. When I got it locking again, I noticed that the PZT drive was sitting close to the rail and the slow loop was doing nothing about it. I played around with the slow loop filter and got it into a reasonably stable configuration (pole @ DC, zero @ 0.1 Hz to cancel the internal pole of the PZT).

As I changed settings in the slow loop, I noticed that the cavity was having a hard time locking again. I realized that the error signal offset had returned, and a slight rotation of the HWP brought the cavity back into a lockable state. I decided to remove all other variables by sweeping the PZT directly (as opposed to through the PDH box) and looking at the error signal directly (as opposed to through INMON). I then rotated the HWP to minimize the error signal offset, retuned the phase shift to maximize the response, and then adjusted the input power to make it as high as possible without an oscillation.

Things seemed to be working, but then the same error offset issue came back. I am not sure what it is, but it needs to be investigated thoroughly. This is the plan for tomorrow morning.

 

 

 

  1203   Fri Dec 10 10:33:46 2010 ZachLaserGYROupdate

 In light of Koji's work, I took new OLTFs of both loops last night. They look almost identical to the old ones, as we should expect if the loops are just below the gain instability point. The gain knob settings on the PDH boxes are:

  • GCCW = 0.00
  • GCW = 3.80

Before the measurements, I adjusted the input power to ensure that we had the maximum optical gain with the CCW servo at 0.00.

Also, when turning the slow loop back on after doing the EOM measurements, I noticed that there was a (slow) error signal offset of about 4000 cts. Koji had recently put in a manual offset of the same amount to counteract what was an offset in the other direction before. I turned this off and was able to get the error signal back to around 0 by clearing the servo memory (i.e. just turning the filter block off and on and then reengaging the output).

I am working on the low-frequency part of the noise budget plot, for which the simple code is done, but it appears that the DAQ is busted again (see next entry). For this, the NB code will pull a series of second-trend data over a longer period, and the low-frequency spectrum produced with it will be stitched to the other one we have been generating.

  1208   Fri Dec 10 13:43:07 2010 KojiLaserGYROupdate

We need some bias to the PZT out.

> 5. I found that if the PZT output goes to negative on the oscilloscope,
> the gyro signal have larger noise than usual. I put an offset to the slow servo
> such that it does not go into the negative side.

Quote:

I noticed that there was a (slow) error signal offset of about 4000 cts. Koji had recently put in a manual offset of the same amount to counteract what was an offset in the other direction before. I turned this off and was able to get the error signal back to around 0 by clearing the servo memory (i.e. just turning the filter block off and on and then reengaging the output).

 

  1378   Mon Apr 4 15:30:22 2011 FrankMiscPulsertwo movies from diode blasting

http://www.youtube.com/watch?v=IRzcoRFkpBQ

http://www.youtube.com/watch?v=hHN20qP0HCY

 

  1229   Mon Dec 20 00:49:55 2010 ranaMiscstuff happenstrivia

KEvsMOMENTUM.png

from the Wikipedia article on Dispersion.

  729   Mon Apr 19 19:09:42 2010 FrankComputingDAQtodays DAQ odyssey - part 1

when we started last week setting up a second fronend i thought it might be simple as making another copy of the main disk, changing some config files and here we go - what alex and i learned is that it is way more complicated with a touch of impossible at all. but lets get started from the beginning:

the idea was to set up a second RT frontend computer with it's own framebuilder, either in the same network or a different subnetwork. The reason why we should have seperate framebuilders is that if we have only one and the first (which whatever we define as the first) of the frontends is down, the whole thing is down. So having more then one model running on different machines, the one which we define as the "main" or first one has to be alive, at all times. If not the others don't work anymore. 

Trying to setting it up with independent framebuilders in the same network is impossible due to broadcast messages on the network prohibiting both working at the same time and still using tools like DTT, which listen only to one broadcasting in the network. The minimum requirement is to have physically seperate networks.

Ok, thats fine with us, we decided to split our networks into seperate subnetworks anyway, but then we can't use the existing workstations and the installed tools for more than one network due to the broadcasting stuff. Using the same workstations requires to log into the corresponding frontend/framebuilder and start all tools localy, which is not nice but still works.


Said this we decided to set everything up like that an the next thing we realized is that the stuff we have currently installed uses a the cvs-stuff mounted from one central source. But the frontend code we had was not designed for that, e.g. important parameters are not set in the matlab model and main configuration files are simply overwritten when compiling one of the frontend codes. So we had to add a couple of things in the matlab file, like the gds_node_id. An example of current cdsparameters are:

site=C3
rate=64K
dcuid=10
gds_node_id=2
shmem_daq=1
specific_cpu=3

We had to hack plenty of things which i can't remember all but e.g. we had to add the right node ID in the testpoint.par file in /opt/apps/Linux/gds/param/ as "L-node" - yes we have to use LHO not Caltech here , e.g

[L-nodex]  (here x=gds_node_id of atf model)
hostname=ip of frontend running atf model
system=atf

[L-nodez] (here y=gds_node_id of psl model)
hostname=ip of frontend running psl model
system=psl

the testpoints are created and written to a file named tpchn_Cx.par, where x equals the gds_node_id again, so a model in ifo=C1 and node-id=2 creates a file tpchn_C2.par !!! So this C2 does not correspond to the IFO set in the model. So e.g. using two different models, IFO=C2 and C3, both running on different frontends (!) but starting with node-id=1 (if you don't specify it in the model default is 1) overwrites the one from the other model each time the model is recompiled !!!! So be carefull. Also a link named tpchn_Lx.par has to point to tpchn_Cx.par (the LHO thing again).... this file has to be also added to the list in the fb master file...

the gds stuff is configured in diag_Cx.conf, x is abritrary, but independent for each system. It looks like:

&nds * *  10.0.1.10 8088 *
&chn * *  10.0.1.10 822087685 1
&leap * * 10.0.1.10 822087686 1
&ntp * *  10.0.1.10 * *
&err 0 *  10.0.1.10 5353 *

containing the ip address for the corresponding machine for all the services.

Same for AWG, which setting can be found in awg.par (again, use LHO(!):

[L1-awg0]
hostname=10.0.1.10

at the end it didn't work because the second frontend computer, even if it is almost identical (it's the same identical model, but a slightly newer version of the mainboard/bios) which is not capable of running the RTcore in realtime.  So, this is the end of part 1 of this odyssey, having only one computer where we can run stuff on which brought us to the point where we had to use the same machine (fb0) for both models, but read part 2 of this odissey why it took another four hours to get it (basically) work, which will be posted soon.....

 

 

  520   Thu Jan 7 17:27:04 2010 ZachLab Infrastructurefubartip of the iceberg

Aidan and I began circling the holes in the ventilation system with Sharpies this afternoon, only to find that the situation was even worse than we thought before (which was already bad). Below is a picture of one particularly bad section (compare with Frank's previous post). We can continue to highlight each one, but by the time we are done the entire lab will look like this--maybe I should have chosen 'fugly'. The worst leaks are not the small ones that can be seen on the sides and bottom of the ducts, but rather the HUGE gaping holes on the top sections of nearly every joint in the system. I am fairly sure that even if we were to highlight each and every hole, we will not get PMA to fix each one. Rana suggests that we at least get them in to fix the largest ones for the time being.

00001.jpg

  1165   Fri Nov 12 12:56:47 2010 ZachLaserGYROtime-varying RFAM

 This morning, I started fresh with this error signal offset issue. I put a beam block in the cavity so that it would not resonate and tried the following things:

  • First, I just tried to null the offset by adjusting the angle of the HWP before the EOM (as I did yesterday).
    • I observed a drift in the error signal at roughly 1 mV per 2-3 minutes. This doesn't seem like much, but it is fatal to the lock loop.
  • Then I adjusted the input QWP to ensure that the beam was linearly polarized on the way in (by iteratively adjusting it and the HWP following it to make the power on one port of the PBS go to zero).
    • The drift was still there after re-nulling the error signal
  • Finally, I decided to analyze the beam coming out of the EOM by circumventing most of the experiment.
    • I removed the HWP following the EOM and installed two steering mirrors to direct the beam to the dedicated steering mirror of the REFL CCW PD (PDA225)
    • I then adjusted the power to a reasonable level and plugged the signal from the PD into the RF analyzer
    • Since pure PM should not show up in the spectrum (the carrier beats with the two sidebands cancel each other out), while AM does, I purified the modulation by eliminating the peak at fmod = 18 MHz
    • Within 5 minutes or so, the peak had grown out of the noise floor by ~20 dBm (noise floor = -98 dBm, peak height = -80 dBm)

Therefore, it appears that there is some (strong) time dependence to the amount of RFAM we get out of the EOM. It's not clear to me why this wasn't an issue before we put in the new PDs, but I guess several things have changed in the past week or two. The experimental setup is below.

RFAM_setup.jpg

  1390   Tue Apr 12 23:17:51 2011 ZachLaserGYROthought I had it!

 I mentioned in the last post that I had measured the AM in the CCW beam after the beam splitter using a PDA255. I saw that the noise spectrum was flat well above where we see the excess low-frequency noise, so I ruled it out as the cause. What I didn't do is the same thing for the CW direction. I had a hunch today that AM could be generated by jitter of the input beam into the AOM caused by the EOM (Rana said that jitter was one source of EOM->AM coupling).

I put a PDA255 in the CW path after the AOM double-pass, stuck the signal into the demod setup, and---lo and behold---I saw low-frequency noise with just about the same shape we're seeing in the gyro signal:

CW_RFAM_4_12_11.png

I decided to try putting separate EOMs in each path. This was extremely messy for a few reasons:

  • sheer lack of space: not only did I need room for the EOMs, but also for several waveplates to rotate the beam to S and then back to P into the faradays.
  • inability to put in focusing lenses to get the beam through the crystal without fudging the whole modematching setup.
  • only having one multi-axis EOM mount---one direction had to use one of the old fixed brass mounts, and I had to use what little parameter space I had to work with before the beam goes through the faraday isolator to do it.

Anyway, I found a way to do it that sort-of-kinda-maybe fit:

two_eoms.png

I split the power from the FG to the EOMs and realigned the beams into the cavity. Needless to say, the setup was far from optimal. Anyway, I decided to lock the cavity and PLL and see if I saw any improvement. There was none; in fact, the noise was worse. I then realized that I had forgotten to put the top on the box. I replaced it, and the noise went down a bit, but still slightly higher than before. I THEN realized that I didn't have the auxiliary box around the CCW injection steering mirrors. I replaced it, and the noise level was at just about where it was before. See below:

two_eoms_4_12_11.png

It is obvious that the sensitivity is suffering au cause d'the shitty way I put it together. I don't think we're seeing oscillator noise in the middle band since the PLL signal looks no better than the AOM signal (see previous post). I think it may be worth trying to do a better job at setting up the twin-EOM scheme, but there are two things that have me on the fence:

  1. Doing this right essentially means redesigning the optical layout altogether. There are too may waveplates to count at the moment, and I'm certain that with a few minutes' thought we can come up with a better layout. We will absolutely need another multi-axis EOM mount to avoid over-constraining the beam path, and we don't have one. I think Frank and Dmass have one, so perhaps we can snag theirs and order another one, but this is time and money. The bright side to this is that we will be replacing the cavity optics either way, and it might be "therapeutic" to rebuild the IO anyway.
  2. This is the tricky one: why do we see an equal improvement in both signals with the replacement of the box cover? No one ordered that, so to speak; the model predicts that IO noise should be suppressed by the CW loop gain, so the PLL should always look better than the AOM in bands where we're limited by IO noise. It could be that the AOM loop has $&#@all gain with my piss-poor attempt, but I think it's unlikely that we've lost over 60 dB of gain, even in this state.

I'll see what kind of loop diagnostics I can do in this limp-mode, and otherwise we'll just have to take a leap of faith that things will look better once we've reconfigured. If not, it will be the same amount of work again just to bring it back to the single-EOM setup. In the meantime, I'll try to think more about how the IO noise could couple to the PLL unsuppressed.

  1742   Tue Aug 21 23:29:38 2012 taraMiscTempCtrlthermal insulation for cold finger and EOM

I made a thermal insulation box for the cell holder that will be used in iodine setupr, see ATF:1665. I used the similar style to CTN refcav insulation. We can make more space in the foam to hold more thermal sensors later. I'll see if I can test how good it can stabilize the temperature tomorrow.

 

 IMG_1607.JPGIMG_1608.jpg

Plus, I also made another thermal insulation for an EOM. It is based on what frank did inPSL:744. It can be used for Gyro or for CTN lab when I have to install two lasers later.

IMG_1609.JPG

  770   Wed May 12 11:12:25 2010 FrankMiscGeneralthe lab this morning

did someone enter the lab this morning already? if yes, can you remember when?

  1336   Fri Mar 4 01:17:24 2011 ZachElectronicsGYROtemporary PDH servo

 I spent the afternoon/evening finishing building the temporary breadboard version of the PDH2 and testing it. As a reminder, this is necessary because we want to get a new, low gyro noise spectrum before the LV meeting for the poster/talk and we won't have time to get the PCB done before then.

Here she is in all her glory:

temp_pdh_box.png

I spared no expense; she's equipped with all four (DIP-switchable) boosts, as well as an invert and a switch-engaged SWEEP input.

I originally built it with all AD829s as we are planning (?) on doing for the final servo, but I had problems with oscillations. I followed the instructions for shunt compensation capacitors in the datasheet, but Frank and I found that there were unavoidable problems from stray capacitances and inductances in the push-in components and the board. We systematically replaced each stage with an OP27 from the input to the output until we had no more issues. We don't expect to see the electronics noise floor at the moment, so the difference between 1.7 nV/rHz and 3 nV/rHz isn't a big one in our case, though we would like to keep as few slower parts in there as possible to retain phase. In any case, we were able to keep two of the AD829s without a problem.

 

Transfer Function

 

Taking a transfer function was a big pain in the ass because of the 105-dB DC gain (i.e. without the boost). I have a trimpot to adjust the offset of the input stage, but the way the Agilent makes swept-sine measurements causes a small change in offset over the course of the sweep that is enough to rail the servo. I ended up avoiding the problem by taking the transfer function with random-noise excitation. I used an SR560 immediately after the source with a 2nd-order HPF so that I had enough at high frequencies where there is much attenuation. Here is the experimental setup and the SR560 settings (for one of the span settings):

setup.pngsr560.png

I got a good measurement in the end; you can see that it agrees very well with the model:

pdhtemp_tf_vs_liso.png

Note: this says "LISO estimate", but that's a mistake; it's actually an ideal model of a TF with the same poles and zeros. This shows that the phase lag introduced by the OP27s is negligible in our region of (current) interest.

 

Noise Spectrum

 

As for the noise level, the agreement isn't quite as great. Here is the input-referred spectrum along with the LISO prediction:

pdhtemp_innoise_vs_liso.png

It converges in the middle frequencies but doesn't at either end. I was suspicious that the analyzer noise was the culprit at higher frequencies---you can see that the input range is different over the higher three measurements---so I looked at how the output noise compared:

pdhtemp_outnoise_vs_liso.png

I would be willing to bet that the high-frequency divergence is indeed caused by the analyzer noise, and I will retake these measurements tomorrow. As for the low-frequency part, I am not quite so sure. It could be that one or more of the stages has a higher-than-quoted noise corner frequency, but this doesn't seem all that likely.

Since the transfer function looked right, I tried very briefly to lock the cavity with it. It didn't work right away (I got some audio-band oscillations), but I had to take off so I didn't mess with it too much. I think that if I adjust the gain by adjusting the input power to the experiment I can get it to lock. This is first on the docket tomorrow. In the meantime, I am taking a low-frequency measurement of the servo noise overnight for inclusion in the noise model. Hopefully this will help to identify the low-frequency noise culprit.

  1337   Fri Mar 4 02:06:22 2011 ranaElectronicsGYROtemporary PDH servo

Quote:

 As for the noise level, the agreement isn't quite as great. Here is the input-referred spectrum along with the LISO prediction:

pdhtemp_innoise_vs_liso.png

Bah! The input referred noise is plenty good enough at low frequencies. Sometimes reality is just not the same as theory on the long time scales (c.f. Hope and Yes We Can). Move On and get gyro noise!

  1338   Fri Mar 4 02:36:42 2011 ZachElectronicsGYROtemporary PDH servo

Okie dokie. I wasn't going to lose much sleep over it anyway, as we won't see it at this level. Just pointing it out.

Quote:

 

Bah! The input referred noise is plenty good enough at low frequencies. Sometimes reality is just not the same as theory on the long time scales (c.f. Hope and Yes We Can). Move On and get gyro noise!

 

  1469   Thu Jul 28 13:15:09 2011 Alastair & ZoeLaserGYROtemperature step

At 995917555 we stepped up the temperature again. We did the same thing as last time (July 22), putting in a large current until the heater reached 298K and then changing back to .2A. We had to turn it on again briefly because the heater went below the desired temperature and the other side of the aluminum hadn't heated up yet.

 

edit:heater off at 995997500.

  1509   Wed Aug 10 12:24:27 2011 Alastair & ZoeLaserGYROtemperature sensors in foam box

We've put two of the temperature sensors inside the foam box (#2 and #3) and the other two are still taped to the optics table. If the fluctuations we're seeing are just noise from the sensors themselves, then we shouldn't see a significant difference between them. However if we are actually measuring temperature changes, then the sensors inside the box should fluctuate much less than the others. Everything is on starting at 997041500. Also we figured out that channel 2 had an anti-aliasing filter and the others didn't, so we added an anti-aliasing filter to all of them (in sitemap) and made sure it had the right sampling rate (in Foton).

  1511   Wed Aug 10 17:30:26 2011 Alastair & ZoeLaserGYROtemperature sensors in foam box

Since there is a lot of temperature noise during the day we are going to wait to look at this data until the morning. There was one more problem with the filters being different from channel to channel (that's why channel 1 appears to turn off after about 4pm in the time series) but it is fixed as of 997057700 so any data after that time should be okay.

Quote:

We've put two of the temperature sensors inside the foam box (#2 and #3) and the other two are still taped to the optics table. If the fluctuations we're seeing are just noise from the sensors themselves, then we shouldn't see a significant difference between them. However if we are actually measuring temperature changes, then the sensors inside the box should fluctuate much less than the others. Everything is on starting at 997041500. Also we figured out that channel 2 had an anti-aliasing filter and the others didn't, so we added an anti-aliasing filter to all of them (in sitemap) and made sure it had the right sampling rate (in Foton).

 

  1513   Thu Aug 11 09:11:06 2011 Alastair & ZoeLaserGYROtemperature sensors in foam box

Here is the time series of temperature data from inside & outside the foam box. As you can see in the long time series there was a chunk of 10 hours (~7:30pm to ~5:30am) that was quieter than the rest. I used that chunk to make the amplitude spectra & transfer function. The transfer function shows that the foam box has no visible effect --which means we are likely seeing sensor noise after all.

Also in the time series & amplitude spectrum you can tell that sensor 2 has a different pattern from the others with more noise at low frequency. Since we double checked all the gain settings etc. perhaps this is actually from the temperature sensor itself and would change if we swapped it for a new one....

Quote:

Since there is a lot of temperature noise during the day we are going to wait to look at this data until the morning.

 

 

Attachment 1: TimeSerAugust10.png
TimeSerAugust10.png
Attachment 2: LongTimeSerAugust10.png
LongTimeSerAugust10.png
Attachment 3: AmpSpecAugust10.png
AmpSpecAugust10.png
Attachment 4: TransFuncAugust10.png
TransFuncAugust10.png
  1506   Wed Aug 10 08:02:50 2011 ZoeLaserGYROtemperature sensor adjustment + plots from last night

At 7:45 I turned the temperature sensors off to check and adjust the resistor values. In particular I thought there might be something wrong with amplifier 2 because the data looks different from the others, but I couldn't see the problem (yet).

EDIT: it had an anti-aliasing filter and the others didn't. We added an anti-aliasing filter to all of them but this means that when we look at the data from inside/outside the foam box we'll have to compare it to the old data.

Now (8 am GPS time 997023620) the temperature sensors are up and running again with amplifier 4 back in the measurable range.

Here is the time series from last night showing that signal 2 looks weird and signal 4 starts railing in the middle of the night. I made a plot of rotation noise using signals 1 and 3 only, and then another using only the second half of the data because from the time series it seems like the room temperature (or the electronics) took a while to settle. The rotation signals are quite a bit higher here than they were yesterday and on August 1, and there is a peak at ~0.6Hz (although that is somewhat less significant in the second half of the data).

Attachment 1: TimeSeriesAugust9.png
TimeSeriesAugust9.png
Attachment 2: RotationNoiseAugust9.png
RotationNoiseAugust9.png
Attachment 3: RotationNoiseAugust9Short.png
RotationNoiseAugust9Short.png
  1507   Wed Aug 10 09:52:41 2011 AlastairLaserGYROtemperature sensor adjustment + plots from last night

That's great that we're above the ADC noise.  I think that we now don't want all this extra gain - it's going to cause the sensors to rail all the time.  We should go back down to a lower gain again.  It would be nice to have +-2K to take account of general drifts in the room. This should keep us above the ADC noise since it's only a factor of 2 lower gain than in your previous plot.

Please can you also post the noise in K/Hz^1/2  as well so we can see the temperature noise.  Can you get hold of a copy of the gyro noise matlab file and add your estimate of temperature noise to this so we can compare it to current sensitivity and other noise sources?  Thanks!

 

Quote:

At 7:45 I turned the temperature sensors off to check and adjust the resistor values. In particular I thought there might be something wrong with amplifier 2 because the data looks different from the others, but I couldn't see the problem (yet). Now (8 am GPS time 997023620) the temperature sensors are up and running again with amplifier 4 back in the measurable range.

Here is the time series from last night showing that signal 2 looks weird and signal 4 starts railing in the middle of the night. I made a plot of rotation noise using signals 1 and 3 only, and then another using only the second half of the data because from the time series it seems like the room temperature (or the electronics) took a while to settle. The rotation signals are quite a bit higher here than they were yesterday and on August 1, and there is a peak at ~0.6Hz (although that is somewhat less significant in the second half of the data).

 

  1508   Wed Aug 10 10:50:08 2011 ZachLaserGYROtemperature sensor adjustment + plots from last night

Nice work. I agree with Alastair that we should have a plot of this in terms of K because there could be other sources of thermal coupling to the gyro noise.

So, this validates my comparison with the H1 PSL spectrum above 100 mHz. Since, according to your plot, the temperature noise floor rises only about a factor of 5 from 100 mHz down to 1 mHz, and the spectra from here and the H1 PSL are within a factor of a few, it's unlikely that the low-frequency floor of the PSL table spectrum is more than a factor of 10 or so lower than ours, if that. Of course, there is always the possibility that this is the sensor noise floor, not a physical temperature spectrum...

Quote:

At 7:45 I turned the temperature sensors off to check and adjust the resistor values. In particular I thought there might be something wrong with amplifier 2 because the data looks different from the others, but I couldn't see the problem (yet). Now (8 am GPS time 997023620) the temperature sensors are up and running again with amplifier 4 back in the measurable range.

Here is the time series from last night showing that signal 2 looks weird and signal 4 starts railing in the middle of the night. I made a plot of rotation noise using signals 1 and 3 only, and then another using only the second half of the data because from the time series it seems like the room temperature (or the electronics) took a while to settle. The rotation signals are quite a bit higher here than they were yesterday and on August 1, and there is a peak at ~0.6Hz (although that is somewhat less significant in the second half of the data).

 

  1510   Wed Aug 10 13:43:53 2011 ZoeLaserGYROtemperature sensor adjustment + plots from last night

Here's the plot in K, and an edited version of the one in rad/s basically showing that the ADC noise converted to rotation signal is lower than it was on August 1 because of the increased V/K. I also added plots in K to my last post with the August 8 and August 1 plots.

Quote:

we should have a plot of this in terms of K because there could be other sources of thermal coupling to the gyro noise. 

 

Attachment 1: TemperatureChangesAugust9.png
TemperatureChangesAugust9.png
Attachment 2: RotationNoiseAugust9.png
RotationNoiseAugust9.png
  1958   Mon Jul 6 08:15:53 2015 ranaMiscTempCtrltemperature noise plot

Since its hard to find, here is a plot from Frank Siefert from years ago, showing the temperature fluctuations in a metal box compared to ambient and sensor noise.

Attachment 1: tempnoise_final.pdf
tempnoise_final.pdf
  829   Wed Jun 23 17:57:00 2010 FrankLab InfrastructureHVACtemperature fluctuations - before and after

the two graphs show the temperature fluctuation in the ATF for 14 days each. The first graph from March, the second for the last 14 days.
scale is the same for both graphs.
Couldn't plot a single graph for the last couple of month as the dataviewer stops displaying most of the June data if you want to plot more than 40 consecutive days or so even if it tells you to do it right.

 

temp_ATF1.png

temp_ATF2.png

  1685   Wed Jun 6 04:28:37 2012 ZachElectronicsIodinetemperature controller circuit (v2)

I have finished the second revision of the design for the precision temperature controller. Here is the schematic, which I tried to lay out intuitively:

temp_ctrl_v2.pdf

Things I added/changed:

  • AC or DC bridge drive: The readout bridge can now be driven either with a DC voltage, provided by a low-noise reference (AD587), or by a sine wave, provided by an onboard XR2206 signal generator chip. If AC is chosen, the output of the differential bridge readout is mixed with the oscillator signal with an audio multiplier (AD633) and then lowpassed; otherwise, the error signal is just the output of the differential readout (which is done with an AD620).
  • External error signal: This isn't really new, but I have implemented the option to provide an external error signal. You would use this, for example, if you wanted to stabilize measured RAM levels by feeding back to an EOM temperature
  • CDS interfacing: There is now the ability to provide the bridge drive as well as acquire the raw differential signal for mixing in the digital domain. The existing analog filter can be whitened digitally so that the only remaining analog components are the bridge itself and the heater driver.
  • Signal shielding: I plan to put a LEMO (or other?) plug right on the board by the bridge reference resistors for the cable that will go to the thermistor. This is because I saw huge pickup effects with the prototype board using just a twisted pair.
  • Filter shape: I have made the filter stage have a single pole/zero pair. The zero should coincide with the thermal pole for the particular application and the pole is movable to DC as a boost.
  • Inverter: I put in an invert option that just swaps the leads of the bridge to the AD620 pins. This is mainly so that I don't have to break my back tracing signs right now, but it can't hurt anyway.
  • Buffer as heater driver: The original plan was to use a voltage-controlled transistor current source as the heater driver, but the current requirement for the typical resistive heaters we will use is easily satisfied by a BUF634, and it is much easier to use. I have tested it with the prototype breadboard and it works fine.

Questions for YOU:

  • My main concern here is that I have a lot of relays (6). I get the impression they are better to use with signals than bare switches, and I don't want to bother with MAX333. Is there any reason I should avoid this many?
  • Switches vs. jumpers: For oft-used things (invert, boost, external error---which can be used as an ON/OFF switch), I plan to put rocker switches on the panel. For the other options, like AC vs. DC and the CDS interfacing, I was thinking of just using jumpers linked to the relays, so that you just have to pull the board out of the rack to switch them. Anything wrong with this?
  • IC choices: The XR2206 was Rich's recommendation, but the AD633 was a more arbitrary choice. There are fancier analog multipliers, but this one seems to have all the necessary functionality. Anyone have any advice?

 

My plan is to make boards with two identical channels, so that each one can control two temperatures. This will be particularly nice in twin setups like the iodine reference.

I'd like to get this printed and stuffed soon so that I can continue with the iodine work, so if you can send me your comments I'd appreciate it! NOTE: I'm sure there are many small things like component choices, voltage ranges for pots, etc., that are not right at the moment---I will verify all these things before ordering but I just wanted some general comments first.

ELOG V3.1.3-