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

  1342   Mon Mar 7 15:53:43 2011 AlastairLaserGYROVacuum pumpdown part 2...

I realigned the beam into the cavity using the last two steering mirrors.  I was able to get the signal on the transmission PD to come back to the level it was at before the pumpdown.  Having said that I think it is close to (or actually) saturating the PD, so we don't have a good measure of the change in transmitted power.  I measure 48mW transmitted with 108mW incident on the input mirror.

EDIT: I turned the beamsplitter at the output a bit to reduce the power incident on the PD, and added a beamdump for the reflected beam.  It's not saturating now (it has 20mW on it, whereas before it had 25mW) but it only a bit below this level.  I wasn't able to improve the alignment any further.  I wanted to try maximizing the transmission moving the lenses in our modematching, but one is at the max of the range on the translation stage, and the other isn't on a movable stage.  We should replace that and move the other one to the middle of the range so that we can optimize.

Attachment 1: pumpdown2.eps
pumpdown2.eps
  1341   Mon Mar 7 12:46:38 2011 AlastairLaserGYROVacuum pumpdown

I did at trial run at pumping down the vacuum today.  While doing this I monitored the transmission power.  The graph of this is attached.

You can see the start, where therer is good transmission.  Then there's noise where I put the lids on the chambers, and then a locked section in the middle.  You can see that just putting the tops on the chambers and clamping them down has caused some misalignment.  Then there is noise where the pumping happens, and the last section is after the valve is closed and the pump turned off.  Clearly there is significant reduction in transmission power.

Maybe we can improve this with better clamps to hold down the vacuum chambers?  At least the cavity is still locking, so the overall effect is pretty small.

Also, I haven't tried to maximise the transmitted light by playing with the input mirrors.  This may improve things a bit.

No EPS, PS, TIFF, TARGA, GIF87, or BetaMax attachment formats allowed.

Attachment 1: pumpdown.eps
pumpdown.eps
  1340   Sun Mar 6 15:38:15 2011 Zach LaserGYROmore noise analysis -- optical gain problem

I have been saying things like "the new PD is lower-noise than the PDA255". This is not true; the output noise is actually a bit higher even. The way we win is thus because the transimpedance is a little bit better and more importantly because the dynamic range is much higher. Here is the demod noise analysis akin to that from this post for the PDA255.

rfpd01_noise.png

In my post about the shot-noise-limited locking scheme, I claimed that the input-referred noise of the RFPD was well below our requirement curve. This is not true at the moment because of (still) poor optical gain. I calculated that based on the theoretical maximum optical gain in V/Hz we could obtain, assuming that we could at least do as well as a sizable fraction of that. More on this later, but it appears that the purely optical component ([W/Hz]) is orders of magnitude lower than it could be, despite the fact that we are getting ~50% transmission through the cavity.

Since residual common mode noise ("spillover noise") has been our main obstacle to date, I decided to do some analysis of the primary loop error signal before bothering to put together the rest of the gyro. Here is a busy plot, followed by a wordy explanation:

err_sig_evol.png

Note: all traces are calibrated to units of (rad/s)/rHz by dividing the error signal noise level by the appropriate optical gain in V/Hz and then multiplying by (lambda S / 4 A) to get rad/s. Also note that the overall OLTF of the primary loop is roughly the same for all the plots (not entirely true, as I was only able to get our UGF up to about 10 kHz as opposed to the ~15 kHz we had before).

  • Blue trace: this is the error signal noise of the last working state of the gyro, as found in the noise budget. Check that to jog your memory, but otherwise just remember that it accounted for all the gyro noise above 30 Hz, and that we think given the new vacuum system and IOO enclosure it will account for it all below this frequency, as well. The broadband floor at around 6 x 10-7 (rad/s)/rHz was discovered to have been caused by the PDA255 we were using as the REFL PD.
  • Green trace: this was the same error signal as of yesterday morning, with the new PD and the PDH #1437 box modified to have lower gain to accommodate the higher optical gain (from simple power increase on the PD). You can see that the noise is lower below about 100-200 Hz. It is not as much better as we'd hoped because of the increase in output noise level and slight decrease in open-loop gain (that is, since our OL gain went down slightly, the optical gain did not increase exactly as much as our PDH gain decreased). Above this frequency, the noise is dominated by mechanical vibrations and will require a real increase in OL gain to reduce. Barring down-conversion, though, we don't really care what is happening at these frequencies since we don't plan to operate in this band.
  • Red trace: This is the measured, bright output noise of the demod setup calibrated to rotation sensing noise in the same way as the error signal. It accounts for the new low-frequency noise level of the error signal in green.
  • Cyan trace: I realized that since the output noise of the PD is higher than the input noise of the PDH box or of the mixer, and since at this point I didn't have that much light on the PD, I could improve the low-frequency noise simply by redistributing the gain: attenuate signal between the PD and the mixer while increasing the optical power proportionately. I did this to the tune of 13 dB (which made the optical power ~100 mW---we don't want it any higher on the PD), and you can see the direct improvement from the green trace to the cyan trace.
  • Magenta trace: this is the same as the red trace but minus 13 dB from the improvement explained in the last bullet. It is higher than the actual error signal below ~8 Hz because I also did an EOM RFAM minimization in the time between when the two error signal spectra were taken. I think a new measurement of the PD/demod noise would show that it is right were the cyan trace is at low frequencies.

So, the low-frequency spillover noise is now ~30x better than it was in the previous setup. I would put on a party hat and dance in a circle, but this is shit: we are still something like a factor of 200 away from the sensing requirement from 200 mHz - 1 Hz, and worse at 100 mHz since the requirement drops down there. We cannot fix this by adding servo gain as we were planning to do for noise here caused by mirror motion, etc; this is sensor noise, so we need to improve SNR up front.

This is why, in my last post, I suggested we do away with the Cougar---it takes away SNR where we are dying for it, while in the current case we are just attenuating the signal downstream. We also need to improve our modulation depth. Right now, we are at < 0.3 rad, whereas we want something like 1 rad for best signal.

Here's the confusing thing: right now, we have a pure optical gain (cavity response) of ~4 nW/Hz, whereas the theoretical maximum is something like 1 uW/Hz for our power level and cavity parameters. Why is our cavity response so piss-poor? Increasing the modulation depth could improve this by a factor of 4 or so, but that still leaves us at around 1% of the available response. This would seem to fit with my observation that coupling our astigmatic beam to a non-astigmatic-but-elliptical cavity mode should lead to ~1% overlap with the solution that gives 99% coupling for an ideal input beam, but the fact remains that we are still coupling ~50% through the cavity! It is as though this light is not contributing to the error signal but still fits in the cavity mode at the same frequency and just comes along for the ride! What?!

Yes, I have considered that there could be something going on with the demodulation (mixer starvation, non-optimized phase angle, etc.), but this won't account for it because any attenuation there should also attenuate the noise level out of the PD, which appears in the error signal exactly as predicted.

Any ideas?

  1339   Sun Mar 6 00:43:02 2011 Zach ElectronicsGYRORFPD #02 TF

I took a transfer function of RFPD S/N 02 tonight with the Jenne Laser. It was much easier to calibrate this one because I didn't have to worry about what the Cougar was doing (since I didn't put one on this board). I also noticed that for some reason the power leaving each port of the beamsplitter was not equal---there was about 2x the power going to the reference PD as to the DUT---this explains why I was getting less gain than expected by about this factor with the last PD.

Here is a transfer function:

rfpd02_vs_liso.png

Some notes:

  • With the resonant notch (aka "aLIGO style") readout, the easiest way to tune the readout notch using an optical transfer function like this is to actually tune the parasitic parallel resonance that occurs nearby to the frequency predicted by a model such as LISO. Before I tuned RFPD01, I found that for a 33 MHz notch and a 200-pF diode capacitance, this resonance occurred at ~35 MHz. As I learned after doing that, the diode capacitance with a 5V bias is more like 100 pF (which explains why the AC coupling resonance of the first PD did not match with the model). I had "35 MHz" stuck in my head today when I tuned the second PD, which means that the readout notch is actually at a lower frequency than 33 MHz. I adjusted the readout notch capacitor in the model so that the TF matched the one I took and it gives a value of about 31 MHz. I will retune it to the proper value (and do the same for the first PD).
    • Another, perhaps easier, way of making sure the readout notch is at the right frequency is to just look at the voltage above the readout capacitor (instead of at the output, which is an amplified version of the voltage between the capacitor and inductor). Here, the readout notch looks just like the rejection notches and can be tuned directly. I think I'll just do this rather than rely on unknown or sketchily known parameters.
  • Besides slight differences in frequency and Q, the measured and predicted transfer functions match up very well, as opposed to the case with the Cougar involved (see link in last bullet). For this reason and more importantly for reasons that will be highlighted in my next post, I propose that we do away with the Cougar altogether for the time being. You can read ahead or just remember that the noise figure of the AP1053 is >3.5 dB at 33 MHz; It's not worth it for this application.
  • I took a noise measurement of this PD, but I forgot to turn off the light source before doing so. The noise is a factor of ~1.5-2 worse than predicted, which could either be a non-ideality in the circuit or else it comes from noise on the light amplified by the PD. New measurement after the retuning.
  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!

 

  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!

  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.

  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
  1334   Thu Mar 3 00:36:11 2011 ZachMiscfubardump or optics lab?

optics lab

 

lab_is_clean.png

Quote:

100_1228.JPG

100_1229.JPG

100_1227.JPG

100_1226.JPG

100_1230.JPG

100_1228.JPG

 

  1333   Wed Mar 2 15:44:36 2011 FrankLaserMOPA35W-laser SOP (LIGO-M070352)

35W-SOP.pdf

35W-SOP.doc

  1331   Wed Mar 2 13:11:23 2011 FrankLab InfrastructureGeneralSOPs missing

OK, never mind. It's only that about five people didn't see it this morning and i checked the the drawer and the desks and couldn't find it. Anyway, there is no 35W laser SOP, not in the lab, not on the wiki and i can't find it in the DCC either. Who wrote it and where is it?

Quote:

Not true; ours has been sitting next to the laser all night. We will find a permanent place for it in the lab, in case we forget how to use the laser (just kidding..).

Quote:

none of the SOP's exists in a printed form posted in or outside of the lab.

 

 

  1330   Wed Mar 2 11:32:08 2011 ZachLab InfrastructureGeneralSOPs missing

Not true; ours has been sitting next to the laser all night. We will find a permanent place for it in the lab, in case we forget how to use the laser (just kidding..).

Quote:

none of the SOP's exists in a printed form posted in or outside of the lab.

 

  1329   Wed Mar 2 11:01:13 2011 FrankLab InfrastructureGeneralSOPs missing

none of the SOP's exists in a printed form posted in or outside of the lab.

  1328   Wed Mar 2 09:14:01 2011 ghostwriterMiscfubardump or optics lab?

100_1228.JPG

100_1229.JPG

100_1227.JPG

100_1226.JPG

100_1230.JPG

100_1228.JPG

  1327   Wed Mar 2 01:57:07 2011 ZachLaserGYROgyro locked with new RFPD

 [Alastair, Zach]

We finally got all the parts together to properly mount the RFPD board to the box, so we did that today. We aligned the cavity mirrors and injected the primary beam in the CCW direction. I used the mode matching solution that I came up with last week, but there is a problem with it in that one of the mirrors has to occupy the same space as a turning mirror for the other beam. I will have to come up with a different solution, but I put the lenses as close to the right place as possible for right now.

Another issue is that---like before---it is going to be very tough to have the faraday isolators so close to the cavities while still having the beam small enough to fit through the center. We have a little more space on the table now, so we could conceivably move them further upstream in the MMT, but this makes the REFL extraction a bit messier. I think someone said that getting new enclosures with larger apertures for the polarizers flanking the rotator is just as difficult as getting a whole new FI, but we may have to figure a way to get the beam through, or else deal with clipping. Since there is no CW beam yet and I have to fix the mode matching of the CCW beam, I have not installed either faraday yet.

In any case, once I got some good TEM00 flashes, I distributed the LO signal from the Tektronix FG as before:

  • Coupler: 23 dBm IN from FG, ~23 dBm OUT to EOM through resonant circuit (which has a resonant gain of ~20 dB), 3 dBm CPL out to PDH mixer LOs
  • Splitter: 3 dBm IN from CPL out of coupler, 0 dBm out to each PDH mixer. Only one is in use now, so I terminated output 2.

I then installed RFPD S/N 01 and put the ~80 mW reflection from the cavity onto it. The DC output was consistent with the design, and dips were evident in conjunction with the spikes in the TRANS signal. I then connected the RF out to the RF IN of the mixer and swept the cavity to see the error signal. At first, I thought what i was getting was some distorted junk, but then I realized that the signal was just so huge that it was saturating the INPUT MON. Turning down the optical power resulted in the classic PDH signal sweep. Nevertheless, I was able to lock the cavity with the full 80 mW, though some UGF instability was evident at this level, so I had to turn it down to about 40 mW.

With the cavity locked, I iteratively adjusted both the cavity mirrors and the input steering mirrors to maximize transmission. I was able to get about 50% after quite a bit of trying, but I'm not convinced I can't do better even with the suboptimal mode matching.

Here are a couple shots of the PD doing its thing. The backplate is not on the box because I did not have a d-sub breakout board to power the thing.

newpd1.pngnewpd2.png

The plan for the immediate future is the following:

  1. Wait on and install remaining parts of RFPD S/N 02
    1. LM317 for bias -- none in Downs, ordered, on way(?)
    2. Cougar AP1053 -- deliberation in progress. We may be able to bypass the Cougar for the second PD temporarily using trickery.
  2. Finish tweaking cavity eigenmode, then pump cavity down
  3. Inject CW beam and install CW/CCW isolation optics
  4. Lock CW using PDH box S/N 2215 as-is.
  5. Measure gyro noise, compare to what is expected
  6. In parallel with above, build breadboard version of PDH2 servo and use it to lock the CCW beam. This will give us the real low-frequency improvement we want to report at the meeting
  7. Signal optimization, noise/loop characterization
  1326   Tue Mar 1 21:40:49 2011 AlastairComputingComputingWiki

 We now have access control lists for the wiki, which means we can choose who has access to what pages.  At the moment I've set the front page to being non-password protected, along with the main experiments page.  I've also made an LVC account, though at the moment this has no different access than the non-password pages.

We should decide how we want the wiki set up.  Here are a couple of options:

1) We could make dedicated "public" pages, and have these non-password protected. Then we could have LVC access to basically all or most of the wiki, but without any editing rights.  Then we can have our own accounts that can edit.  The downside to this approach is that it is unlikely any public pages will ever be updated.

2) Another option is to allow public access to as many pages as we feel comfortable with, but for these to be the same regular pages that make up the wiki.  This has some advantages because the public pages get updated with everything else.  The downside here is that there will be many frustrating links on public pages that come up with "you do not have enough rights to continue" when you click them.

3) Option 3 is to just have no public access at all.  We just keep the whole thing private, and choose what pages to give the LVC account access to.  Again LVC doesn't need to have editing rights.

I should point out that the LVC account will only have one password (rather than using albert.einstein accounts) so people will have to know the password to get in.

  1325   Mon Feb 28 17:47:33 2011 AidanComputingDAQRestarted DAQD on fb1

I added some Hartmann Sensor channels to the frames and restarted DAQD on fb1 to include them.

See here for details ...

  1324   Thu Feb 24 03:54:29 2011 FrankElectronicsGYRORFPD #01 TF

Nice work!

According to your schematic the bias is 5V. If that is the case the capacitance is usually much less than 150pF!
If you check the typical graph in the datasheet the capacitance is ~120pF@5V.
According to the data i measured i expect it to be below 120pF @5V.
Old LIGO diodes had about 105pF@ 7V. The diode you are using is one of those old batches.
If you like we can measure it tomorrow with my pulsing setup. Doesn't take longer than 5 minutes including setting everything up and getting the data

Quote:

 I chose the "final" component values for the first RFPD as follows. Consult the schematic here.

  • AC coupling
    • L6 = 6.8 uH
  • 66 MHz notch
    • L2 = 1 uH
    • C10 = 5.8 pF (1.5 - 15 pF tunable)
  • 33 MHz readout
    • C2 = 24 pF
    • C4 = 7 pF (1.5 - 15 pF tunable)
    • L3 = 750 nH

I have taken a transfer function with the Jenne Laser setup and the result is reasonable but not exactly what we expect. Below is a comparison of the measured transfer function with the prediction from LISO. To get these in a comparable form, I took the raw output of the spectrum analyzer (the ratio of the responses of the DUT and the New Focus 1611 reference PD), multiplied by the flat AC transimpedance of the reference PD (700 V/A), and subtracted the 10 dB of gain from the Cougar (AP1053).

rfpd_vs_liso_log.png

Some notes:

  • As far as the readout and 2f rejection are concerned, the two transfer functions match up fairly well with the exception of a discrepancy in Q.
  • Though the two phases show the same basic behavior, there is a large overall shift across the measurement band. I have no idea why this is.
  • The most staggering difference is that the peak from the AC coupling resonance is much higher in frequency for the measured data. I have been using C = 200 pF for the diode in simulations, while Perkin-Elmer claims that this should be < 150 pF when biased as we have it, but even decreasing it to this level doesn't account for the higher measured frequency.

I have a suspicion that just subtracting 10 dB does not accurately negate the effect of having the Cougar on the end. Though it says nothing about it on the datasheet, I have heard that they have some sort of internal AC coupling, and so this odd behavior could be explained by that somehow. I think I will take the transfer function again, this time using a probe to sense before the Cougar instead of after it, and hopefully then it will conform with the model. In the end, all we care is that it behaves as expected near where we expect to have appreciable input signals (e.g. 33 MHz and 66 MHz), but it;s nice to be able to say that we know what's going on everywhere.

Another thing I noticed on the Cougar datasheet is that the noise figure goes up pretty quickly as you go below ~50 MHz. Using naked-eye extrapolation, I estimate that it is about 3.7 dB @ 33 MHz. I have taken a noise spectrum of the PD, but I am not comfortable enough with the TF calibration to trust the analysis yet. Stay tuned.

 

  1323   Thu Feb 24 01:29:09 2011 ZachElectronicsGYRORFPD #01 TF

 I chose the "final" component values for the first RFPD as follows. Consult the schematic here.

  • AC coupling
    • L6 = 6.8 uH
  • 66 MHz notch
    • L2 = 1 uH
    • C10 = 5.8 pF (1.5 - 15 pF tunable)
  • 33 MHz readout
    • C2 = 24 pF
    • C4 = 7 pF (1.5 - 15 pF tunable)
    • L3 = 750 nH

I have taken a transfer function with the Jenne Laser setup and the result is reasonable but not exactly what we expect. Below is a comparison of the measured transfer function with the prediction from LISO. To get these in a comparable form, I took the raw output of the spectrum analyzer (the ratio of the responses of the DUT and the New Focus 1611 reference PD), multiplied by the flat AC transimpedance of the reference PD (700 V/A), and subtracted the 10 dB of gain from the Cougar (AP1053).

rfpd_vs_liso_log.png

Some notes:

  • As far as the readout and 2f rejection are concerned, the two transfer functions match up fairly well with the exception of a discrepancy in Q.
  • Though the two phases show the same basic behavior, there is a large overall shift across the measurement band. I have no idea why this is.
  • The most staggering difference is that the peak from the AC coupling resonance is much higher in frequency for the measured data. I have been using C = 200 pF for the diode in simulations, while Perkin-Elmer claims that this should be < 150 pF when biased as we have it, but even decreasing it to this level doesn't account for the higher measured frequency.

I have a suspicion that just subtracting 10 dB does not accurately negate the effect of having the Cougar on the end. Though it says nothing about it on the datasheet, I have heard that they have some sort of internal AC coupling, and so this odd behavior could be explained by that somehow. I think I will take the transfer function again, this time using a probe to sense before the Cougar instead of after it, and hopefully then it will conform with the model. In the end, all we care is that it behaves as expected near where we expect to have appreciable input signals (e.g. 33 MHz and 66 MHz), but it;s nice to be able to say that we know what's going on everywhere.

Another thing I noticed on the Cougar datasheet is that the noise figure goes up pretty quickly as you go below ~50 MHz. Using naked-eye extrapolation, I estimate that it is about 3.7 dB @ 33 MHz. I have taken a noise spectrum of the PD, but I am not comfortable enough with the TF calibration to trust the analysis yet. Stay tuned.

  1322   Wed Feb 23 15:33:32 2011 ZachElectronicsGYROPDH box #1437 modified

The input noise of the spectrum analyzer at the lowest range is ~20 nV/rHz. Subtracting this from the measured output noise spectrum of the PDH box before referring to the input, I get a noise spectrum that matches closely the estimated noise from LISO. This box is ready to go. Note that simply subtracting the noise off the way I did does not lead to a large systematic error because the true servo noise is of just about the same level.

pdh1437temp_vs_liso_with_SA_noise.png

Quote:

I corrected the mistakes to the PDH box. The LISO estimate of the noise from the previous post is no longer quite right, however, as I had to reduce the gain at different points than I had originally intended (originally I was going to do at least part of the reduction at the output stage, but this proves difficult because doing so without being very careful results in a different gain for the inverted and non-inverted modes the way the output stage is designed). The result is that the high-frequency noise is higher than anticipated. Taking the increase in optical gain into consideration, though, the high-frequency contribution to the gyro noise is still lower than before.

Here is a transfer function, showing an overall gain decrease of about 35 dB from the previous case (this post, about halfway down):

pdh1437_temp_tf.png

Here is the input-referred noise spectrum, along with the LISO estimate for this circuit. The excess low-frequency noise is now absent, but the noise at high frequencies is higher than estimated. It looks as though this might actually be the noise of the spectrum analyzer (the output noise level here is on the order of 20 nV/rHz, and though I had it auto-ranging it could have gotten hung up). I will check this in the AM. Either way, there is a big improvement in broadband and the servo's contribution to the gyro noise is below requirement in a big chunk of our operational band (see previous post).

pdh1437temp_vs_liso.png

Quote:

 As I outlined in this post, the primary PDH box needed some modifying if we are to see any significant improvement from the new setup. I made these changes:

  • Remove the AD8336 variable gain stage and bypass it altogether
  • Reduce the overall gain of the servo by ~40 dB

The input-referred noise is now at the level explained by the LISO model---unlike it was before---though this calls for a funny story:

When I plotted the noise and divided by the transfer function I measured, I got a noise level that was exactly 10x higher than predicted by LISO. After quite a while of scratching my head and checking my code, I realized that I mistakenly changed the gain of the wrong stage (despite writing down the right one in my notes), causing the noise from the nasty LF356 switchable stage to have 10x the influence. I will correct it and re-measure tomorrow, but the important thing is that we have removed the noisy 8336 from near the input.

Here is a picture of the modified portion of the board and a LISO prediction of the noise when I've corrected the mistake. You can compare with the plot in the link above, but this corresponds to a true low-frequency voltage noise betterment of 20 dB at low frequency, which adds to the 40 dB improvement in the servo's contribution from the expected optical gain increase. This actually puts the servo noise below the aLIGO requirement between about 100-350 mHz.

1437_mod.jpg pdh1437_temp_innoise.png

 

 

  1321   Wed Feb 23 01:40:03 2011 ZachElectronicsGYROPDH box #1437 modified

I corrected the mistakes to the PDH box. The LISO estimate of the noise from the previous post is no longer quite right, however, as I had to reduce the gain at different points than I had originally intended (originally I was going to do at least part of the reduction at the output stage, but this proves difficult because doing so without being very careful results in a different gain for the inverted and non-inverted modes the way the output stage is designed). The result is that the high-frequency noise is higher than anticipated. Taking the increase in optical gain into consideration, though, the high-frequency contribution to the gyro noise is still lower than before.

Here is a transfer function, showing an overall gain decrease of about 35 dB from the previous case (this post, about halfway down):

pdh1437_temp_tf.png

Here is the input-referred noise spectrum, along with the LISO estimate for this circuit. The excess low-frequency noise is now absent, but the noise at high frequencies is higher than estimated. It looks as though this might actually be the noise of the spectrum analyzer (the output noise level here is on the order of 20 nV/rHz, and though I had it auto-ranging it could have gotten hung up). I will check this in the AM. Either way, there is a big improvement in broadband and the servo's contribution to the gyro noise is below requirement in a big chunk of our operational band (see previous post).

pdh1437temp_vs_liso.png

Quote:

 As I outlined in this post, the primary PDH box needed some modifying if we are to see any significant improvement from the new setup. I made these changes:

  • Remove the AD8336 variable gain stage and bypass it altogether
  • Reduce the overall gain of the servo by ~40 dB

The input-referred noise is now at the level explained by the LISO model---unlike it was before---though this calls for a funny story:

When I plotted the noise and divided by the transfer function I measured, I got a noise level that was exactly 10x higher than predicted by LISO. After quite a while of scratching my head and checking my code, I realized that I mistakenly changed the gain of the wrong stage (despite writing down the right one in my notes), causing the noise from the nasty LF356 switchable stage to have 10x the influence. I will correct it and re-measure tomorrow, but the important thing is that we have removed the noisy 8336 from near the input.

Here is a picture of the modified portion of the board and a LISO prediction of the noise when I've corrected the mistake. You can compare with the plot in the link above, but this corresponds to a true low-frequency voltage noise betterment of 20 dB at low frequency, which adds to the 40 dB improvement in the servo's contribution from the expected optical gain increase. This actually puts the servo noise below the aLIGO requirement between about 100-350 mHz.

1437_mod.jpg pdh1437_temp_innoise.png

 

  1320   Wed Feb 23 01:22:09 2011 ZachLaserGYROPD boxes in!

[Alastair, Zach]

The PD boxes arrived today, and with the exception of a few minor issues they look great!! Here are a few shots. Here one box is shown assembled and mounted to the brass base and insulator that Alastair designed. The dimensions for these were chosen so that the PD is at 4" from the table.

gyro_pd1.pnggyro_pd2.pnggyro_pd3.png

 

The issues were/are as follows:

  • The only unforeseen issue was that I forgot to countersink the screw holes in the thick bottom panel of the box so that it could sit flush with the insulating layer. We used a drill press to do this and as you can see it worked just fine.
  • The front panel will have a small recess milled out where the PD goes so that the diode case can have a good thermal contact with the un-anodized aluminum. The three tapped holes (4-40) around the PD are there so that we can fashion a copper washer-like plate that will be screwed in from the front to hold the diode in place. The depth of the recess will be a tiny bit less than the thickness of the diode case rim so that the copper plate will hold the PD snugly against the front panel, and the plate will be thick enough that it protects the bare diode from accidental brushing.
  • We are ordering/locating 1/8" standoffs for the board mounting as well as some sort of thermally-but-not-electrically conducting spacer for mounting the negative voltage regulators to the top panel for heat sinking (while the positive regulators have GND on their metal tabs, the negative ones have INPUT---as stupid as that seems).

Also, drool.

  1319   Tue Feb 22 11:21:01 2011 ZachLaserGYROmode matching issue

I agree, but that is what the calculation gives. I haven't plotted this yet, but it could be that in this case there are two coupling maxima (i.e. one where the X solution is closest to the cavity mode and one where the Y one is), and right in between---where the "average" solution is---there is a local minimum. Then, we could easily have adjusted the lenses slightly to get to one of the maxima and have something like 10-20% coupling like we saw, despite the fact that the other axis was way off.

I will do some crunching.

Quote:

I think this 1% is a lot less than we have already seen coupling into the cavity - it doesn't seem quite right to me.

I think that you're correct that is the way we did the calculation, taking some average of the x and y parameters we measured for the beam.  I'd have to go back and check though.

Quote:

 This afternoon I measured the distances required to calculate the mode matching, and then I came up with a solution using code that I wrote. In doing so, I realized that there is a problem with the way we have been calculating the overlap in the past.

Last summer, Jenna used the overlap function to show that an overlap of > 99% could be achieved with a non-astigmatic beam injected into a cavity with an elliptical eigenmode (like our gyro cavity, whose mode has a waist twice as big in one direction as in the other). This is fine, but there are two things to note:

  • The cavity is not astigmatic; the waists of the X and Y projections occur at the same places (i.e. the input and output coupling mirrors). It simply has an elliptical cross section.
  • Our beam is astigmatic! The output beam of the NPRO has X and Y waists that occur at different points on the Z axis.

Jenna calculated such a nice overlap because she assumed that our input beam was not astigmatic. The coupling is far more sensitive to curvature match at the input (i.e. making the beam flat at the flat mirror) than it is to the area of the beam cross section, and a non-astigmatic beam allows you to do that arbitrarily well.

If I take the solution I calculated for the average of the X and Y components of our input beams and apply it to both components individually, the overlap I get with the cavity eigenmode is < 1%, despite the fact that it is >99% if we assume that the average is a real, physical, circular beam.

I think we may need to do the cylindrical mode matching after all.

 

 

  1318   Tue Feb 22 10:47:35 2011 Alastair?LaserGYROmode matching issue

I think this 1% is a lot less than we have already seen coupling into the cavity - it doesn't seem quite right to me.

I think that you're correct that is the way we did the calculation, taking some average of the x and y parameters we measured for the beam.  I'd have to go back and check though.

Quote:

 This afternoon I measured the distances required to calculate the mode matching, and then I came up with a solution using code that I wrote. In doing so, I realized that there is a problem with the way we have been calculating the overlap in the past.

Last summer, Jenna used the overlap function to show that an overlap of > 99% could be achieved with a non-astigmatic beam injected into a cavity with an elliptical eigenmode (like our gyro cavity, whose mode has a waist twice as big in one direction as in the other). This is fine, but there are two things to note:

  • The cavity is not astigmatic; the waists of the X and Y projections occur at the same places (i.e. the input and output coupling mirrors). It simply has an elliptical cross section.
  • Our beam is astigmatic! The output beam of the NPRO has X and Y waists that occur at different points on the Z axis.

Jenna calculated such a nice overlap because she assumed that our input beam was not astigmatic. The coupling is far more sensitive to curvature match at the input (i.e. making the beam flat at the flat mirror) than it is to the area of the beam cross section, and a non-astigmatic beam allows you to do that arbitrarily well.

If I take the solution I calculated for the average of the X and Y components of our input beams and apply it to both components individually, the overlap I get with the cavity eigenmode is < 1%, despite the fact that it is >99% if we assume that the average is a real, physical, circular beam.

I think we may need to do the cylindrical mode matching after all.

 

  1317   Tue Feb 22 00:25:39 2011 ZachLaserGYROmode matching issue

 This afternoon I measured the distances required to calculate the mode matching, and then I came up with a solution using code that I wrote. In doing so, I realized that there is a problem with the way we have been calculating the overlap in the past.

Last summer, Jenna used the overlap function to show that an overlap of > 99% could be achieved with a non-astigmatic beam injected into a cavity with an elliptical eigenmode (like our gyro cavity, whose mode has a waist twice as big in one direction as in the other). This is fine, but there are two things to note:

  • The cavity is not astigmatic; the waists of the X and Y projections occur at the same places (i.e. the input and output coupling mirrors). It simply has an elliptical cross section.
  • Our beam is astigmatic! The output beam of the NPRO has X and Y waists that occur at different points on the Z axis.

Jenna calculated such a nice overlap because she assumed that our input beam was not astigmatic. The coupling is far more sensitive to curvature match at the input (i.e. making the beam flat at the flat mirror) than it is to the area of the beam cross section, and a non-astigmatic beam allows you to do that arbitrarily well.

If I take the solution I calculated for the average of the X and Y components of our input beams and apply it to both components individually, the overlap I get with the cavity eigenmode is < 1%, despite the fact that it is >99% if we assume that the average is a real, physical, circular beam.

I think we may need to do the cylindrical mode matching after all.

  1316   Mon Feb 21 23:17:46 2011 ZachElectronicsGYROPDH box #1437 modified

 As I outlined in this post, the primary PDH box needed some modifying if we are to see any significant improvement from the new setup. I made these changes:

  • Remove the AD8336 variable gain stage and bypass it altogether
  • Reduce the overall gain of the servo by ~40 dB

The input-referred noise is now at the level explained by the LISO model---unlike it was before---though this calls for a funny story:

When I plotted the noise and divided by the transfer function I measured, I got a noise level that was exactly 10x higher than predicted by LISO. After quite a while of scratching my head and checking my code, I realized that I mistakenly changed the gain of the wrong stage (despite writing down the right one in my notes), causing the noise from the nasty LF356 switchable stage to have 10x the influence. I will correct it and re-measure tomorrow, but the important thing is that we have removed the noisy 8336 from near the input.

Here is a picture of the modified portion of the board and a LISO prediction of the noise when I've corrected the mistake. You can compare with the plot in the link above, but this corresponds to a true low-frequency voltage noise betterment of 20 dB at low frequency, which adds to the 40 dB improvement in the servo's contribution from the expected optical gain increase. This actually puts the servo noise below the aLIGO requirement between about 100-350 mHz.

1437_mod.jpg pdh1437_temp_innoise.png

  1315   Mon Feb 21 22:08:13 2011 ranaLaserGYROother half of MZ noise analysis

Probably ought to put a thermistor on the can to see if the temperature noise is big enough to cause the low frequency MZ noise.

  1314   Mon Feb 21 11:41:07 2011 ZachLaserGYROother half of MZ noise analysis

  By pushing on the table to force the MZ output through full swings, I have determined the amplitude of the beat and therefore the calibration. The peak-to-peak amplitude is ~3400 cts, so the calibration is:

(1 / 1700 cts) * (1064 x10-9 m) / (2 * pi) = 9.96 x 10-11 m/ct

Here is the calibrated spectrum:

gyro_MZ_noise_2_21_11.png

Comparing it with the spectrum I linked to in the previous post shows that the noise below 1 Hz has gone down significantly (a factor of ~8 at 100 mHz), while the high frequency noise has suspiciously gone up. For the resonances, this could be due to Q enhancement from going into vacuum, but it is also noteworthy that there was a possible calibration issue in the old spectrum, while this time I have used the full swing of the beat in counts to do the calibration without having to multiply by other conversion factors. I will always do it this way in the future so that there is no ambiguity. No matter how you look at it, though, the low-frequency noise is better.

It is also worth noting that this MZ-type noise is expected only to couple in as phase noise at the gyro output beat signal. As such, its influence will be rotated away by a factor of f at low frequencies, where we will instead be dominated by the "FSR modulation noise". Hopefully, the low frequency improvement we see here will have a counterpart in that, as well.

  1313   Sun Feb 20 23:21:45 2011 ZachLaserGYROMZ noise half-analysis

This is the output of the MZ for the first couple hours after we set it up. Since we only watched the first few minutes on the scope, it appeared as though some transient from the slow influx of gas into the chamber was causing it to swing through fringes. This longer time series seems to paint a different picture. It shows something that looks like a damped oscillation that is also increasing in period.

An increase in period alone would be consistent with a slowing differential drift while the vacuum system reached its steady-state pressure, but the change in amplitude doesn't make sense (we have the output going onto a large-area PD using a lens, so even if we were just losing contrast the maximum power on the PD---bottom of the plot here---would stay roughly the same). Instead, this looks like something was actually causing it to oscillate between the maximum and minimum values of the output. 

Screen_shot_2011-02-18_at_7.36.10_PM.png

Not long after this, the large oscillation seemed to have gone away, leaving a more stochastic looking time series (see below). The abrupt jumps and subsequent slow drifts are probably coincident with the lab temperature control system turning on.

Screen_shot_2011-02-20_at_3.00.34_PM.png  ... Screen_shot_2011-02-20_at_3.00.46_PM.png

I chose a small chunk of time during which the time series looked relatively flat and near mid-range (~13:00:00 2/19/11) to take a spectrum. Since I now realize that we probably don't know the contrast for sure, I have to postpone the calibration until I can verify the full-swing amplitude tomorrow morning. Still, a few things can be learned by looking at how the spectrum compares qualitatively with the one I took in air. The main thing to notice is that the low-frequency hill is markedly shallower with respect to the higher-frequency mechanical resonances. There also appears to be a new family of resonances between 10-20 Hz, which might originate in the vacuum system itself.

We will have more information of how much better the low-frequency noise is once we've calibrated this.

Screen_shot_2011-02-20_at_6.39.24_PM.png

 

  1312   Sat Feb 19 03:22:21 2011 FrankElectronicsGeneralcable phase noise

"Inter-Spacecraft Clock Transfer Phase Stability for LISA (Diploma Thesis)"
http://www.lisa.aei-hannover.de/?redirect=157.pdf


"Computation of phase-stability over temperature - Thermal testing of microwave cables for the Laser Interferometer Space Antenna"

http://www.lisa.aei-hannover.de/?redirect=226.pdf


"Phase noise contribution of EOMs and HF cables"
http://www.ice.cat/research/LISA_Symposium/presentations-folder/7thLISAsymposium2008-SimonBarke-AEIhannover.pdf


"Inter-Spacecraft Clock Transfer Phase Stability for LISA"
http://iopscience.iop.org/1742-6596/154/1/012006/pdf/jpconf9_154_012006.pdf

 

One of the companies which is selling some good stuff
http://www.timesmicrowave.com

  1311   Fri Feb 18 20:07:44 2011 ZachLaserGYROMZ measurement in progress

 [Alastair, Zach]

We finished cleaning the in-vac stuff, installed the mirrors in the MZ configuration, injected a beam, aligned it for best contrast, put the output on a PD, and then pumped down. We disconnected the pump once we got down to the level that Alastair had achieved previously (~a few x 10-4 torr) and the pressure rose to a few hundredths of a torr.

The output of the interferometer throughout the process was a slow sine wave, which we figured was due to the small changes in cavity length from the pumping/leaking.

The channel is being acquired. More analysis and a better explanation of the setup to come.

  1310   Fri Feb 18 00:09:55 2011 ZachLaserGYROgyro upgrade progress (repost)

 [Alastair, Zach]

A while ago I posted an entry with an outline of what needs to be done for the gyro upgrade. Here is an updated2 version. Completed items are in green, items in progress in magenta, stricken items are deemed unnecessary, and comments in blue.

  1. Dismantle current setup, inventory parts and store them in an organized way
  2. Inventory space on the table and decide the basic layout for the Enhanced Gyro
    1. As we are planning to house the input/REFL optics (and the laser) in the current gyro box, we will have to choose the layout pretty carefully from the start
    2. We need to think of a way to house the final steering mirrors into the vacuum system. One will be in the input optics box, but one will not. This can contribute noise.
  3. Begin vacuum system setup
    1. Clean parts
    2. Install
  4. In parallel with (3), begin input optics setup:
    1. Mount laser
    2. Install/align input polarization optics
    3. Install/align/configure EOM
      1. Do initial RFAM minimization
    4. Install CW/CCW beam separation polarizing optics
  5. Install/align CW AOM double-pass setup
    1. Maximize double-passed 1st order output beam power 
  6. Full CW/CCW beam profiling
  7. Finalize IO layout to have accurate distances for modematching
  8. Full cylindrical modematching solution for CW/CCW (we decided that cylindrical optics are not necessary, as we can obtain >99% coupling without)
    1. Find optimal solution, consider beam widths at faraday isolators
    2. Order lenses
  9. Install injection/REFL isolation optics and optoelectronics
    1. Faraday isolators
    2. Waveplates
    3. Steering mirrors
    4. Focusing lenses
    5. Attenuators
    6. Gyro RFPDs
  10. If (8.2) lead time is high, work out quick, temporary spherical solution for locking in the meantime
  11. Install cavity optics
    1. Mount into chamber
    2. Steer in input beams
    3. Align cavity eigenmode by eye
  12. RF distribution
    1. Install dedicated LO crystal
    2. Install necessary splitters, couplers and distribute to:
      1. EOM resonant circuit input
      2. CW/CCW PDH mixers
    3. Connect AOM VCO through amplifier to AOM
  13. Optimize signals
    1. Sweep laser, adjust CCW demod phase for optimal error signal
    2. Tweak cavity alignment and maximize transmission
    3. Lock CCW
    4. Sweep AOM and adjust CW demod phase for optimal error signal
    5. Adjust injection alignment to maximize transmission
    6. Iterate above as necessary
  14. Pump down
  15. Reoptimize injection alignment (CW & CCW)
  16. Build transmission demod and PLL...
  17. To be continued...

A few things have been somewhat glossed over in the above:

  1. I still have to finish making the resonant circuit for the EOM. I have borrowed the RF transformer kit from the 40m and I will hopefully have this done before we need it
  2. We haven't ordered a dedicated oscillator for the LO. I guess we will get one of the Wenzel crystals and a power amp(?). This isn't extremely time-sensitive as we can use one of the RF FGs for the moment as we have been (we need to get on this)
  3. I am working on designing the new PDH boxes for the gyro in Altium. I am guessing these won't be completely done (i.e. received, stuffed, etc.) by the time we first want to lock the eGYRO, but we can use the old boxes until they are.
  4. Alastair has finished the RFPD design, and we are pretty much ready to pull the trigger on getting the boards in. We still need to make certain that the board will be compatible with whatever box we use as it is designed. I understand that the turnaround for the PCBs is pretty short, so we can proceed with the stuffing and testing while we await the boxes. (just waiting on boxes)
  5. Not sure about what to do with CDS. Rana is inclined to get an NDS2 server set up for the ATF, so I guess we will have to talk to John Zweizig about that. I understand that there are also plenty of other problems with the computers at the moment, though (e.g. the permissions thing). (Everything is working now as it was before. I think we decided that instead of installing NDS2---at least for now---we will just acquire some signals with multiple rates so that we can make low-frequency measurements, as well.)

 table_layout.png

 

  1309   Fri Feb 18 00:02:54 2011 ZachLaserGYROoptical layout finalized

 [Alastair, Zach]

The bases for our PDs arrived today, which enabled us to finalize the table layout for the new gyro. Alastair has been mounting the cavity mirrors to the new bases and cleaning them for placement into the vacuum system. Here is a shot of the table with rays traced. The (sturdy!) brass PD bases are clearly visible. Note that the MMT lenses shown here are just placeholders; I still need to work out a solution now that the layout is done.

table_layout.png

The fact that the "viewports" on the IO box are very close to the edge of it (from when they were used to inject to the gyro cavity) makes the injection setup a little awkward. We originally thought we would have to cross the beams just before the cavity, but I figured out a way to do it without that. Here is a closeup of the injection/REFL isolation setup, and a slightly-less-close-up shot of it to highlight how the beams are directed into the vacuum system. I have only shown the input beams (blue and yellow) in the second one to avoid confusion.

injection_setup.png  injection_setup2.png

The PD boxes are scheduled to arrive on Monday afternoon. Before they do, I will have two RFPDs ready to go so that we can assemble them and begin open-tank locking immediately. I think we should be able to have an in-vac gyro spectrum by the end of next week if all goes smoothly. Science at work.

  1308   Wed Feb 16 16:47:17 2011 ZachLaserGYROGyro beams profiled

 I profiled the primary and secondary beams so that we have this information when we go to do the modematching. I have started calling them strictly the "primary" and "secondary" beams because geometry might dictate that we switch which one is CW and which is CCW in the new scheme. It is best to keep the names unambiguous so that we don't run into the trouble that they have at the 40m.

full_beam_scan_2_16_11.png

  1307   Wed Feb 16 00:18:27 2011 ZachLaserGYROAOM set up, CCW and CW beams power-balanced @ ~80 mW

 This evening, I set up the AOM double-pass and balanced the two beams going to the injection/extraction optics. This wasn't as simple as last time because I had to re-profile the beam and come up with a modematching solution. I've updated my recent "status" post to reflect the current status.

Here is the profile after the mirror leading into the AOM:

aom_path_profile.png

The beam was slightly elliptical and somewhat astigmatic (|z0x - z0y| ~ 10 cm). Using the average of x and y, I came up with a simple matching solution using an f = 100mm lens and the R = 30cm mirror we were using before. It puts the mirror roughly 30cm from the AOM, and the waist of about 124um near the center of the crystal. Here is the ABCD screenshot:

AOM_mm_ABCD.png

I was able to isolate the double-passed 1st-order beam with an overall efficiency of ~45% (i.e. single-pass efficiency of ~67%). This is slightly worse than before, but the output beams are very close together so it is difficult to know whether we actually had it better before at all. In any case, I balanced the beams heading toward the injection optics at about 80 mW apiece, which is more than what we were counting on already. There is still some power dumped just after the laser, so there is still room to step up the power a bit more should we need it. Here's a picture of the setup as it stands---I am holding an IR card to show where the two beams are going:

gyro_as_of_2_15_11.png

 

 

  1306   Tue Feb 15 12:08:33 2011 ZachElectronicsGYROUniversal PDH box noise problem identified,

I realize that now. The plot you mention was supposed to be and is now in my last post.

For the record, I did mention that the AD8336 could be the problem when I first did the measurement, and no one jumped up to say THAT IS A SHITTY PART! Of course, I am to blame for not looking at the data sheet. 

Quote:

I thought you guys know that, as it's clearly mentioned in the datasheet, in the table on page 2 and in graphs where noise is plotted vs gain setting voltage some pages later. Nobody ever said that this is a low-noise part.

 

 

 

  1305   Tue Feb 15 11:34:48 2011 FrankElectronicsGYROUniversal PDH box noise problem identified

I thought you guys know that, as it's clearly mentioned in the datasheet, in the table on page 2 and in graphs where noise is plotted vs gain setting voltage some pages later. Nobody ever said that this is a low-noise part.

Quote:

It seems that the main issue was a design flaw. The AD8336 has a preamp stage, and if the gain is too low there the noise performance of the whole thing is bad no matter what you choose as the "variable gain". The universal box has this preamp set to unity gain. As seen in the plot, if you extrapolate the "preamp gain = 4x" gain line up by a factor of four, and assume we were using a reasonable gain setting of ("G" = 5) on the dial---corresponding to Vgain = 0---the input noise is 100 nV/rHz. This is bush league.

Also, I don't see a single reference to any frequencies lower than ~100 kHz, and I suspect that the low-frequency behavior is not a priority for them. We should avoid this part.

Quote:

Yes, I am happy about that. For the new box, we confirm the noise levels of the boxes with various gains before they are in use.

Quote:

Second, Koji will be pleased to hear that I think I have traced the excess low-frequency noise seen in this measurement to the AD8336 variable gain stage.

 

 

 

  1304   Tue Feb 15 11:16:29 2011 ZachElectronicsGYROUniversal PDH box noise problem identified

It seems that the main issue was a design flaw. The AD8336 has a preamp stage, and if the gain is too low there the noise performance of the whole thing is bad no matter what you choose as the "variable gain". The universal box has this preamp set to unity gain. As seen in the plot, if you extrapolate the "preamp gain = 4x" gain line up by a factor of four, and assume we were using a reasonable gain setting of ("G" = 5) on the dial---corresponding to Vgain = 0---the input noise is 100 nV/rHz. This is bush league.

Also, I don't see a single reference to any frequencies lower than ~100 kHz, and I suspect that the low-frequency behavior is not a priority for them. We should avoid this part.

Screen_shot_2011-02-15_at_11.09.41_AM.png

Quote:

Yes, I am happy about that. For the new box, we confirm the noise levels of the boxes with various gains before they are in use.

Quote:

Second, Koji will be pleased to hear that I think I have traced the excess low-frequency noise seen in this measurement to the AD8336 variable gain stage.

 

 

  1303   Tue Feb 15 09:12:11 2011 KojiElectronicsGYROUniversal PDH box noise problem identified

Yes, I am happy about that. For the new box, we confirm the noise levels of the boxes with various gains before they are in use.

Quote:

Second, Koji will be pleased to hear that I think I have traced the excess low-frequency noise seen in this measurement to the AD8336 variable gain stage.

 

  1302   Tue Feb 15 02:02:53 2011 ZachElectronicsGYROUniversal PDH box noise problem identified

Since we will not have the new PDH servos ready by the time we are locking the mGyro, it is important for us to think about how we can minimize the gyro noise with the old boxes.

First of all, we will not be able to capitalize on the improved optical gain (from increased power on the new diodes) unless we can decrease the overall gain of the servo; otherwise, the loop will become unstable. We should figure out the best way to reduce the gain by an overall factor of ~40-50 dB, which is the expected enhancement from the new PDs.

Second, Koji will be pleased to hear that I think I have traced the excess low-frequency noise seen in this measurement to the AD8336 variable gain stage. It turns out that they have poor performance when used in low-gain configurations, leading to a likely input noise of greater than 400 nV/rHz in our current configuration, with an apparently high 1/f corner frequency of >10 Hz. By playing with the parameters a bit in LISO (the noise specifications in the data sheet are a bit esoteric), I am able to produce a noise plot that is quite like the one we measured in the above linked post.

I propose that we temporarily circumvent the variable gain stage altogether and reduce the gain of some or all of the stages, leaving a trimpot somewhere so that we can tune it as necessary. The box will of course be reverted for universal use once we get our new boxes. This combination should allow us to reach our estimated unavoidable displacement noise level in broadband above ~10 Hz. The hope is that this unavoidable displacement noise level is actually lower than we think at low frequencies (assuming that most of the low-frequency noise is caused by the air), so that using the new boxes to juice up our gain at low frequencies will put us below the requirement in the operational band. For reference, the most recent gyro noise budget is here.

 

 

 

  1301   Tue Feb 15 00:15:28 2011 ZachLaserGYROgyro upgrade progress

 [Alastair, Zach]

A while ago I posted an entry with an outline of what needs to be done for the gyro upgrade. Here is an updated version. Completed items are in green, items in progress in magenta, stricken items are deemed unnecessary, and comments in blue.

  1. Dismantle current setup, inventory parts and store them in an organized way
  2. Inventory space on the table and decide the basic layout for the Enhanced Gyro
    1. As we are planning to house the input/REFL optics (and the laser) in the current gyro box, we will have to choose the layout pretty carefully from the start
    2. We need to think of a way to house the final steering mirrors into the vacuum system. One will be in the input optics box, but one will not. This can contribute noise.
  3. Begin vacuum system setup
    1. Clean parts
    2. Install (Done with the exception of the mirrors themselves. The mounts should be in tomorrow.)
  4. In parallel with (3), begin input optics setup:
    1. Mount laser
    2. Install/align input polarization optics
    3. Install/align/configure EOM
      1. Do initial RFAM minimization
    4. Install CW/CCW beam separation polarizing optics
  5. Install/align CW AOM double-pass setup
    1. Maximize double-passed 1st order output beam power 
  6. Full CW/CCW beam profiling
  7. Finalize IO layout to have accurate distances for modematching
  8. Full cylindrical modematching solution for CW/CCW (we decided that cylindrical optics are not necessary, as we can obtain >99% coupling without)
    1. Find optimal solution, consider beam widths at faraday isolators
    2. Order lenses
  9. Install injection/REFL isolation optics and optoelectronics
    1. Faraday isolators
    2. Waveplates
    3. Steering mirrors
    4. Focusing lenses
    5. Attenuators
    6. Gyro RFPDs
  10. If (8.2) lead time is high, work out quick, temporary spherical solution for locking in the meantime
  11. Install cavity optics
    1. Mount into chamber
    2. Steer in input beams
    3. Align cavity eigenmode by eye
  12. RF distribution
    1. Install dedicated LO crystal
    2. Install necessary splitters, couplers and distribute to:
      1. EOM resonant circuit input
      2. CW/CCW PDH mixers
    3. Connect AOM VCO through amplifier to AOM
  13. Optimize signals
    1. Sweep laser, adjust CCW demod phase for optimal error signal
    2. Tweak cavity alignment and maximize transmission
    3. Lock CCW
    4. Sweep AOM and adjust CW demod phase for optimal error signal
    5. Adjust injection alignment to maximize transmission
    6. Iterate above as necessary
  14. Pump down
  15. Reoptimize injection alignment (CW & CCW)
  16. Build transmission demod and PLL...
  17. To be continued...

A few things have been somewhat glossed over in the above:

  1. I still have to finish making the resonant circuit for the EOM. I have borrowed the RF transformer kit from the 40m and I will hopefully have this done before we need it
  2. We haven't ordered a dedicated oscillator for the LO. I guess we will get one of the Wenzel crystals and a power amp(?). This isn't extremely time-sensitive as we can use one of the RF FGs for the moment as we have been (we need to get on this)
  3. I am working on designing the new PDH boxes for the gyro in Altium. I am guessing these won't be completely done (i.e. received, stuffed, etc.) by the time we first want to lock the eGYRO, but we can use the old boxes until they are.
  4. Alastair has finished the RFPD design, and we are pretty much ready to pull the trigger on getting the boards in. We still need to make certain that the board will be compatible with whatever box we use as it is designed. I understand that the turnaround for the PCBs is pretty short, so we can proceed with the stuffing and testing while we await the boxes. (mounts should be in this week; boxes should be in next week)
  5. Not sure about what to do with CDS. Rana is inclined to get an NDS2 server set up for the ATF, so I guess we will have to talk to John Zweizig about that. I understand that there are also plenty of other problems with the computers at the moment, though (e.g. the permissions thing). (Everything is working now as it was before. I think we decided that instead of installing NDS2---at least for now---we will just acquire some signals with multiple rates so that we can make low-frequency measurements, as well.)

 gyro_status_2_14_11.png 

 

  1300   Thu Feb 10 22:03:03 2011 FrankComputingDAQeverything is working again

I didn't say that they are out of limits, but they are not normal compared to other disks which indicates that they WILL FAIL NEXT. So we should be prepared and replace e.g. sdd now BEFORE it fails and all data is gone. Same for the boot disk. If you compare the raw values for all disks in fb1 and fb2 (psl lab) you see that for all disks, even for five year old disks those numbers are zero.

Both "Raw_Read_Error_Rate" and "Seek_Error_Rate" are super high for sda and sdc on fb0. If you compare that with other disks you see that this is not normal.
For sdd the "Load_Cycle_Count" is more than 200k, max lifetime is 300k. A good value is a few hundred to thousand. The count for all disks in fb1 and fb2 is less than 50!

Quote:

Frank:

The problems with the disk you showed me were not really problems at all:

  • A worse "Read Error Rate" is indicated by a lower number. sdc's stats were currently 120, worst 099, and the threshold is 006. I think it is fine.
  • Joe and I looked at the other disk that had the "Head Flying Time" with some astronomical number. Every digit in the number changes when you re-run the utility, so there is probably just something wrong with the way that is being generated.
  • Everything else looked well within limits

I do think it's a good idea to get a mirror for sda though.

Quote:

Some more problems:

  • since sda has been replaced some time ago we don't have a mirror of that drive anymore (we used to have that before, so if one disk fails nothing happens).
    However, currently the second drive for that mirror is installed but not used
  • some disks will fail in the near future indicated by the S.M.A.R.T parameters of the disks

This time we should replace the disks BEFORE they fail

 

 

 

 

 

  1299   Thu Feb 10 19:04:14 2011 ZachComputingDAQeverything is working again

Frank:

The problems with the disk you showed me were not really problems at all:

  • A worse "Read Error Rate" is indicated by a lower number. sdc's stats were currently 120, worst 099, and the threshold is 006. I think it is fine.
  • Joe and I looked at the other disk that had the "Head Flying Time" with some astronomical number. Every digit in the number changes when you re-run the utility, so there is probably just something wrong with the way that is being generated.
  • Everything else looked well within limits

I do think it's a good idea to get a mirror for sda though.

Quote:

Some more problems:

  • since sda has been replaced some time ago we don't have a mirror of that drive anymore (we used to have that before, so if one disk fails nothing happens).
    However, currently the second drive for that mirror is installed but not used
  • some disks will fail in the near future indicated by the S.M.A.R.T parameters of the disks

This time we should replace the disks BEFORE they fail

 

 

 

 

  1298   Thu Feb 10 16:28:24 2011 FrankComputingDAQeverything is working again

Some more problems:

  • since sda has been replaced some time ago we don't have a mirror of that drive anymore (we used to have that before, so if one disk fails nothing happens).
    However, currently the second drive for that mirror is installed but not used
  • some disks will fail in the near future indicated by the S.M.A.R.T parameters of the disks

This time we should replace the disks BEFORE they fail

 

Quote:

Out of interest, what does ndsd do?

I'd like to update the wiki with info on how inittab should be set up.

Quote:

 [Alex, Joe, Zach]

Problem 1:

  • The wiper was defining the percentage used wrong. It used "used space" over "total space", which sounds right, but due to the fact that there is some reserved space (~5% of the total), this is not the same as [ 1 - (available space)/(total space)].
  • The wiper, which uses the first method, reported 87%, while df (second method) reported 93% full. Since the wiper was set to keep 95% before, this means that it was actually using up more than all of the available space.
  • Joe couldn't find an easy way to implement the second method into the wiper script, so he settled for a different one:      percentage used = used / (used + avail)
  • Now the wiper reports a much closer value to df.
  • We also changed the wiper setting to 90% for the time being, and observed that it worked properly

Problem 2:

  • Even though daqd had been set to run as controls, ndsd had not. Therefore, when we tried to access old data from the frames, we got error #13: permission denied.
  • We changed the ndsd inittab to run as controls, so that it is matched with daqd
  • Everything works now

Booyakasha.

 

 

  1297   Thu Feb 10 16:11:56 2011 AlastairComputingDAQeverything is working again

Out of interest, what does ndsd do?

I'd like to update the wiki with info on how inittab should be set up.

Quote:

 [Alex, Joe, Zach]

Problem 1:

  • The wiper was defining the percentage used wrong. It used "used space" over "total space", which sounds right, but due to the fact that there is some reserved space (~5% of the total), this is not the same as [ 1 - (available space)/(total space)].
  • The wiper, which uses the first method, reported 87%, while df (second method) reported 93% full. Since the wiper was set to keep 95% before, this means that it was actually using up more than all of the available space.
  • Joe couldn't find an easy way to implement the second method into the wiper script, so he settled for a different one:      percentage used = used / (used + avail)
  • Now the wiper reports a much closer value to df.
  • We also changed the wiper setting to 90% for the time being, and observed that it worked properly

Problem 2:

  • Even though daqd had been set to run as controls, ndsd had not. Therefore, when we tried to access old data from the frames, we got error #13: permission denied.
  • We changed the ndsd inittab to run as controls, so that it is matched with daqd
  • Everything works now

Booyakasha.

 

  1296   Thu Feb 10 13:00:28 2011 ZachComputingDAQeverything is working again

 [Alex, Joe, Zach]

Problem 1:

  • The wiper was defining the percentage used wrong. It used "used space" over "total space", which sounds right, but due to the fact that there is some reserved space (~5% of the total), this is not the same as [ 1 - (available space)/(total space)].
  • The wiper, which uses the first method, reported 87%, while df (second method) reported 93% full. Since the wiper was set to keep 95% before, this means that it was actually using up more than all of the available space.
  • Joe couldn't find an easy way to implement the second method into the wiper script, so he settled for a different one:      percentage used = used / (used + avail)
  • Now the wiper reports a much closer value to df.
  • We also changed the wiper setting to 90% for the time being, and observed that it worked properly

Problem 2:

  • Even though daqd had been set to run as controls, ndsd had not. Therefore, when we tried to access old data from the frames, we got error #13: permission denied.
  • We changed the ndsd inittab to run as controls, so that it is matched with daqd
  • Everything works now

Booyakasha.

  1295   Wed Feb 9 20:13:46 2011 ZachElectronicsGYROPD boxes ordered

 [Alastair, Steve, Zach]

I finalized the dimensions of the RFPD boxes this morning. This afternoon, Alastair and I went over them and made sure they jived with the base dimensions.

Steve let me use his P-card to order them. The grand total was $700 ($175/box).

Lead time is 5 days from order to shipping, then UPS ground.

  1294   Wed Feb 9 01:35:06 2011 ZachLaserGYROgyro RFPD transfer function (sort of)

With Koji's help, I was able to get the PD working today. Yesterday, I was having trouble getting the DC readout to work. We traced it back to the conical inductor to ground from the PD anode, which was open for some reason (I later broke it when removing it from the board, but it wasn't obviously broken before that --- I am trying to fix it). I replaced it with a normal coil for the moment.

After this, things worked fine. There was a strange ~75 kHz oscillation in the DC signal, but Rana postulated that this could be from the less-than-stellar lab supplies. I decided to move on to the RF output. I hooked it up to the Jenne Laser rig and swept it. Below is a log-scale plot and a linear close-up. I am still working on the calibration and making it match up with the model, but I have to have another look at the measurement setup and measure some component values tomorrow.

Essentially, though, it looks like what we expect:

  • AC coupled
  • "Resonant" spike at 33 MHz for the REFL readout (the actual peak is at a higher frequency, but the transimpedance at 33 MHz is at a point where it is very weakly sensitive to diode capacitance fluctuations
  • Notch at 66 MHz, for 2f rejection
  • Roll-off at higher frequency

More details and comparison with the model to follow.

plotlog.pngplotlin.png

  1293   Tue Feb 8 21:28:33 2011 Alastair & Co.ComputingComputingFB0 issues....

Problem 1

Disk sdc was full.  See below list of files, showing that it stopped at 05:43:

-rw-r--r--  1 controls controls 19126210 Feb  8 05:40 C-R-981207616-32.gwf
-rw-r--r--  1 controls controls 19126385 Feb  8 05:41 C-R-981207648-32.gwf
-rw-r--r--  1 controls controls 19104189 Feb  8 05:41 C-R-981207680-32.gwf
-rw-r--r--  1 controls controls  2629632 Feb  8 05:42 .C-R-981207712-32.gwf
-rw-r--r--  1 controls controls        0 Feb  8 05:43 .C-R-981207776-32.gwf
-rw-r--r--  1 controls controls        0 Feb  8 05:44 .C-R-981207840-32.gwf
-rw-r--r--  1 controls controls        0 Feb  8 05:45 .C-R-981207904-32.gwf
-rw-r--r--  1 controls controls        0 Feb  8 05:46 .C-R-981207968-32.gwf

The wiper was running, and was set to 95%:

[controls@fb0 fb]# more wiper.log

Tue Feb  8 20:27:01 PST 2011

Directory disk usage:
/frames/full 912389612k
Combined 912389612k or 891005m or 870Gb

/frames/full size 961432072k at 94.90%
/frames/full is below keep value of 95.00%
Will not delete any files
df reported usage 94.92%

However the disk was full:


[controls@fb0 fb]# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
                     234476168  24758300 197615008  12% /
/dev/sda1               101086     28296     67571  30% /boot
tmpfs                  1029676         0   1029676   0% /dev/shm
/dev/sdd1            1442145212 149825928 1292319284  11% /frames/trend
/dev/sdc1            961432072 912594164         0 100% /frames/full
fb1:/cvs             961432032 108480608 852951424  12% /cvs

Something is screwed up with the way that wiper calculates how full the disk is.  We changed the value down to 90%, and the disk is now at 91%.  The wiper script says it's at 85%, so it's still getting the wrong value, but the disk is no longer full and we are recording frames again.

 

______________________________________________________________

Problem 2

Now that the frame data is being taken again, we can see the realtime data in dataviewer.  However, we cannot get any frame data from the past.  Dataviewer throws up the following error.  The frame data is definitely there, is owned by controls, and we are definitely acquiring the channel whose data we are trying to retrieve.  There is something wrong here that I cannot work out.

Connecting to NDS Server fb0 (TCP port 8088)
Connecting.... done
read(); errno=0
LONG: DataRead = -1
No data found

read(); errno=9
read(); errno=9
T0=11-02-08-04-59-52; Length=60 (s)
No data output.

I think this is going to be a problem we need to get Alex to take a look at.

ELOG V3.1.3-