40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  ATF eLog, Page 56 of 56  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  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

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

 

 

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

KEvsMOMENTUM.png

from the Wikipedia article on Dispersion.

  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

 

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

 

  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.

  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
.

 

 

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

 

  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.

  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.

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

  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.

  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.

  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.

  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.

  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?

  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?

  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

  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.

  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.

  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.

 

 

  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>

  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.

  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.

 

ELOG V3.1.3-