40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  ATF eLog, Page 37 of 56  Not logged in ELOG logo
ID Date Author Type Category Subject
  992   Thu Aug 26 17:09:08 2010 AlastairThings to BuyGYROPossible Vacuum system for the GYRO

Quote:

We're not looking for super high-vacuum though are we?  Maybe we can get away with borrowing the small turbo pumping station from the suspensions lab to pump it down and then we can just valve it off.

Also, we have the cylinder head for a tank of helium now so we should order in a tank to try that (the tanks get delivered really fast so that shouldn't be a problem).  Of course we'll at least need windows before doing that.

I've asked Gina to check on the CVI W2 window order.  The order went in on 22nd July and CVI said that they had them in stock.

 I think that's right - we won't need any better than 1 mTorr. As long as there is no huge leak, we should be fine. It would be handy to have a (EPICS trendable) gauge on the system so that we can know if its leaking.

The system's total volume will be ~20 liters. So we need the leak rate to be below ~1e-6 Torr-liters / hour. A suggestion from Mike Z is to use the usual flexi-hosing from Norcal instead of the rigid nipple type of tube

I was talking about before. flexi hose link ..... I think we can use the 2" ID, 24" long tubes and make up for the difference in the length in the corner chambers. The length of each side of the gyro should be 29.5" with a 100 MHz FSR.

  991   Thu Aug 26 17:00:12 2010 FrankComputingDAQfb1 down?

Quote:

Quote:

can someone plz check or reboot fb1. It doesn't respond anymore but the router is working fine as i can log into it...

if it doesn't come up plz check the main monitor on top of the blck rack what it says...

fb1 appears to have crashed or been restarted. ws1 and ws2 are nonresponsive (as a result?).

fb1 wants to check sdb1, I will let it do so (check forced blah blah).

If I understand correctly, ws1 and 2 drop when fb1 drops because fb1 hosts the /cvs/cds filesystem. I don't understand why this makes them die.

Thanks for taking care David.

It shouldn't make them die as only the tools we use are located on fb1, nothing else. So i don't know. But they should cpme back as soon fb1 is back too.

I can't remember but the last time we rebooted fb1 was last year or so i think. I know it's not a windows computer but maybe it needs to be rebooted once a year

Do you still have problems using mDV?

  990   Thu Aug 26 16:42:01 2010 DmassComputingDAQfb1 down?

Quote:

can someone plz check or reboot fb1. It doesn't respond anymore but the router is working fine as i can log into it...

if it doesn't come up plz check the main monitor on top of the blck rack what it says...

fb1 appears to have crashed or been restarted. ws1 and ws2 are nonresponsive (as a result?).

fb1 wants to check sdb1, I will let it do so (check forced blah blah).

If I understand correctly, ws1 and 2 drop when fb1 drops because fb1 hosts the /cvs/cds filesystem. I don't understand why this makes them die.

  989   Thu Aug 26 16:27:54 2010 FrankComputingDAQfb1 down?

can someone plz check or reboot fb1. It doesn't respond anymore but the router is working fine as i can log into it...

if it doesn't come up plz check the main monitor on top of the blck rack what it says...

  988   Thu Aug 26 15:57:54 2010 FrankComputingDoublingnds server down?

1) : the CVS-directory is a GLOBAL one which contains EVERYTHING for ANY computer in the lab area !.
So the basic answer is : the directory for fb is /cvs/cds/caltech/target/fb/ and the one for fb1 is /cvs/cds/caltech/target/fb1/.

This is important as the versions are different !!!

DON'T USE THE WRONG ONE ON THE WRONG COMPUTER !!

2): everything is working if you do it right on your computer. i tried it yesterday and today, using mDV on my personal computer from my hotel room.
So if anything isn't working it's probably a local problem!

3) the nds-proxy isn't working yet, so don't try to start it.

  987   Thu Aug 26 01:10:11 2010 AlastairThings to BuyGYROPossible Vacuum system for the GYRO

We're not looking for super high-vacuum though are we?  Maybe we can get away with borrowing the small turbo pumping station from the suspensions lab to pump it down and then we can just valve it off.

Also, we have the cylinder head for a tank of helium now so we should order in a tank to try that (the tanks get delivered really fast so that shouldn't be a problem).  Of course we'll at least need windows before doing that.

I've asked Gina to check on the CVI W2 window order.  The order went in on 22nd July and CVI said that they had them in stock.

  986   Thu Aug 26 01:01:34 2010 ZachLaserGYROgyro back to gyro configuration

 I put the gyro back into the normal configuration today. It is now locking in both directions again. The bandwidth seems slightly improved, as I didn't have to be quite as careful when working on the table to keep it from dropping, but it is far from good, and the 200kHz+ oscillation still shows up with enough gain. I had set up the PLL but was having problems locking it when I had to leave.

A couple changes:

  • I kept the high-speed PDA10A that I used for the linear cavity in place as the CCW REFL PD, instead of the old PDA36A. We eventually want to have the same two PDs for both REFLs, but this doesn't really matter at the moment, and we might as well maximize our optical gain in the main locking loop while using the design modulation frequency of 33 MHz. The CW loop is still a 17-MHz diode, but this loop seems to like the lowest gain setting anyway, and we may end up wanting to reduce lower gain limit of the CW PDH box.
  • The BS1 in the TRANS readout was a 45P, but we are using S, so I changed it to a 45S.

I took some time to label nearly all of the cables we work with at the controls interface. The REFL PD signals, the CW & CCW error signals, the PZT and AOM VCO control signals, the TRANS DC signal, the SWEEP drive from the function generator, and two cables going to dedicated DAQ channels have all been labeled. This way we don't have to tug on cables or follow them across the table to figure out what is what. We should be prudent that we don't change them around without relabeling them appropriately

2010-08-25_13.19.11.jpg2010-08-25_13.20.31.jpg

Tomorrow morning I'm going to figure out what's wrong with the PLL, then lock it and take a spectrum to see if things have gotten better with the new PD, new modulation frequency, and fresh realignment. Then I plan to take a bunch of transfer functions to try and diagnose our loop problem. Specifically:

  1. The closed-loop TF of each direction
  2. The OLTF from the SWEEP input of each PDH box to its output

(2) is necessary to obtain the OLTF of the loops from (1), as we will be using the SWEEP input for the excitation, and the TF from SWEEP to OUT is not the same as that from IN to OUT.

  985   Wed Aug 25 22:58:12 2010 ranaLaserDoublingSpectrum Incoming.

For ease of use, isn't possible to just load the calibrations into EPICS so that the _OUT channels of these filter banks are calibrated into rads?

i.e. write a matlab or shell script that calculates the peak to peak values and then uses 'ezcawrite' to put the correct value into the GAIN field of that filter module.

Then as long as things don't drift at the 20% level, the data written to disk will be calibrated. There can even be a DAQ channel called PHASE_532 and PHASE_1064.

Then there could be a mDV script that just prints out the calibrated spectrum with noise budget automatically.

 

On the DAQ side, I was able to get the channel list with mDV by just pointing the mdv_config.m file at ganymede.ligo.caltech.edu (which is fb1 from the outside). However,

I didn't get any data. I looked on fb1 and for some reason, its running 2 copies of the daqd and nds jobs. fb (aka fb0) is just running 1 copy, as is normal. I suggest that

fb1 should only run daqd/nds from its own fb1 directories and that the fb processes on fb1 should be killed.

 

The NDSPROXY is a TCL script which we should run in the future on our future gateway machine, but not yet.

  984   Wed Aug 25 22:18:35 2010 DmassLaserDoublingSpectrum Incoming.

MZ Sum and Difference spectra as acquired by the DAQ: Calibrations on plot.

Attachment 1: MZSpecSumDiff.pdf
MZSpecSumDiff.pdf
  983   Wed Aug 25 16:54:57 2010 DmassComputingDoublingnds server down?

I was unable to get the channel list via get_data in matlab with a presumably properly configured mdv_config file. Zach says he is epxeriencing the same woes. mDV doesn't work, ligoDV does, dataviewer does. I looked at the nds log file (in /cvs/cds/caltech/target/fb/nds.log) and it seems to have stopped responding.

I heard scuttlebutt that this happened last week, and people found there was really poor/wrong documentatation on how to fix it. I found no record of these tribulations on the elog or the wiki. Maybe Frank or Alastair will read this and, in pity of us, post what happened last week, and maybe even what fixed the problem.

Confusion: There is both /cvs/cds/caltech/target/fb/ and /cvs/cds/caltech/target/fb1. When I looked at the log files, /cvs/cds/caltech/fb/nds.log seemed to be the one we were using recently (It had entries from August 9th - last night, when a DTT query for a test point from a DAQ channel seems to have crashed it). However, in /etc/inittab, it appears /cvs/cds/caltech/target/fb1/start_nds.inittab is the file executed, which does not correspond to the nds log file which reflected our recent queries.

Contents of each:

  • cat /cvs/cds/caltech/target/fb/start_nds.inittab
    #!/bin/sh
    exec env LD_LIBRARY_PATH=/opt/epics-3.14.7-i386/base/lib/linux-x86/:/usr/local-2.95.3/lib /cvs/cds/caltech/target/fb/nds /cvs/cds/caltech/target/fb/pipe >& /cvs/cds/caltech/target/fb/nds.log
     
  • cat /cvs/cds/caltech/target/fb1/start_nds.inittab
    #!/bin/sh
    exec su controls -c 'env /cvs/cds/caltech/target/fb1/nds /cvs/cds/caltech/target/fb1/pipe' >& /cvs/cds/caltech/target/fb1/nds.log
     
  • cat /cvs/cds/caltech/target/fb1/ndsproxy/start_ndsproxy
    #!/bin/csh

    # Startup script for NDS proxy
    # - should make this run in a cron or init tab
    #
    #

    # This is because sometimes the old proxy is running
    pkill tclshexe

    # This is the home directory for NDS Proxy
    #set dir = '/cvs/cds/caltech/target/ndsproxy'
    set dir = '/cvs/cds/caltech/target/fb1/ndsproxy'

    # The command string - the log file gets the PID in the file name
    echo "Starting NDSProxy"
    $dir/ndsproxy -l 8088 -s fb -p 8088  >>&! ${dir}/log/ndsproxy_`date +%e%b%y`_$$.log &
  • There is no /cvs/cds/caltech/target/fb/ndsproxy folder.
  • last line of cat /etc/inittab:
    nds:35:respawn:/cvs/cds/caltech/target/fb1/start_nds.inittab
  •  

WHICH OF THESE THREE IS THE RIGHT ONE TO BE RUNNING? It would be wonderful to get this documented.

  982   Wed Aug 25 01:28:35 2010 ranaThings to BuyGYROPossible Vacuum system for the GYRO

One possible vacuum chamber solution for the Gyro is to use long tubes for the Gyro arms and then to have a small chamber with ports at each corner.

I looked a little at using stock MDC vacuum parts for this; its not out of the question.

For the tubes, we could use something like their NW50 Kwik-Flange nipple. It has an OD of 2" and a length of 6.5". Its $63.

For the corners, we can use one of their '5-way crosses' like the 406002. Its basically 5 flanges welded onto a shell. Depending on the size its ~$250 ea.

I would prefer to get one long tube for each arm, rather than stick a bunch of short ones together, so I'll get a quote from MDC on a custom job.

Uncoated quartz viewports are ~$250 ea. I expect that we will want AR coated and angled viewports. Maybe $400 ea then.

So the total cost, without pumps would be ~5k$.

  981   Wed Aug 25 01:09:43 2010 ZachLaserGYROGyro "single-arm" test

 EDIT: The calibration has been corrected to include the right NPRO temp control coefficient as measured by Rana at the 40m. This makes it of roughly the same level as the incoherent noise in the MZ measurement, but still different in shape. I think the coherent noise dominates in this measurement because of the shorter path length, so it may be that the MZ noise limits us more in the real gyro (this will likely change after we put in the windows).


Here is a spectrum of the slow control signal to the NPRO calibrated to meters. The calibration is:

6.103 x 10-4 V/ct * 1.1 GHz/V * (c / 1064 nm) * 0.75 m = 1.78 x 10-9 m/ct

single_leg_noise.png

Unlike yesterday's measurement, this does not have the right shape to be our current limiting noise source. It does, however, pose an even bigger threat than the noise measured yesterday given our current understanding of how noise couples in. That is, if in fact the differential-mode noise is limiting us now because of our week feedback loops, then once we take care of that we will have to deal with this 0.1-um level noise and its FSR coupling, which raises the "displacement noise altering FSR" curve on the NB by about an order of magnitude.

The fact that this noise is directionally preferential---it shows up along one leg but not in the difference between two like paths, as yesterday---leads me to believe that it is not air noise. The calibration may be off in one of the two (or both) measurements but the data are qualitatively different, and I don't think we would see this if air noise were dominant. 

Let me clarify what I think is happening:

There are two types of noise we are considering here

  1. Incoherent noise from the shaking of the mounts and from air currents. This shows up in the MZ-type measurement and in the linear cavity measurement.
  2. Coherent noise from the stretching of the table. This shows up only in the linear cavity measurement

Now,

  • If our locking loops have infinite gain and bandwidth, then we only see either source as it affects the area of the cavity. That is, we don't see direct length-to-frequency coupling from cavity noise, but rather only the modulation of the 1-FSR offset due to a CM change in cavity size. In this case, we will be concerned with the loudest of the above sources of noise, which I believe (given these past two measurements) is (2).
  • Since our locking loops are far from perfect, we are seeing the noise from (1) couple in much more directly than it will in the final gyro. I do not propose a mechanism, but, for example, it could be that we are seeing noise from the (sometimes shakier) non-cavity optics that should be suppressed by the loops.

If I am right, then we may seriously start to consider the idea of locking the laser to a stable reference, then locking the CCW length of the gyro cavity to the laser via PZT.

 

Quote:

Maybe the word "mode" isn't the right choice. I'm not talking about a vibrational mode, but rather the low-frequency thermal expansion of the table. I find it hard to believe that the perimeter of the table won't change by more than 10-10 m or so over 1-10 mHz timescales.

Regarding the AC on/off spectrum, do you mean a spectrum of the gyro signal, or some other configuration?

I have a feeling that Alastair will know better what to do about the windows, but I can try and think of something in his absence.

About the word wrapping, I don't know; I've never had an issue in Safari (OS X) or Firefox (Linux).

Quote:

 I don't think there's any breathing mode being excited. At low frequencies, we are most likely measuring the air noise. Since the table has its first eigenfrequency above 100 Hz, the flexing at 100 mHz is suppressed by a factor of lots.

Most likely, we just need to plug the giant holes on that box. Where are those windows??? Also, take a spectrum with the AC turned off and make a comparison with it on/off.

P.S. Why do the entries in this elog not word-wrap in some browsers, while the ones in the TCS lab tab do word wrap?

 

 

  980   Wed Aug 25 01:02:17 2010 ranaLaserGYROGyro "single-arm" test

Temperature noise may be a real problem. Probably Frank has a spectrum of the room's temperature noise handy and you can multiply by the CTE of the table top.

I guess the MZ noise and the gyro noise ought to be measured with the air on/off. I think it will point at the HVAC.

  979   Tue Aug 24 20:06:16 2010 ZachLaserGYROGyro "single-arm" test

Maybe the word "mode" isn't the right choice. I'm not talking about a vibrational mode, but rather the low-frequency thermal expansion of the table. I find it hard to believe that the perimeter of the table won't change by more than 10-10 m or so over 1-10 mHz timescales.

Regarding the AC on/off spectrum, do you mean a spectrum of the gyro signal, or some other configuration?

I have a feeling that Alastair will know better what to do about the windows, but I can try and think of something in his absence.

About the word wrapping, I don't know; I've never had an issue in Safari (OS X) or Firefox (Linux).

Quote:

 I don't think there's any breathing mode being excited. At low frequencies, we are most likely measuring the air noise. Since the table has its first eigenfrequency above 100 Hz, the flexing at 100 mHz is suppressed by a factor of lots.

Most likely, we just need to plug the giant holes on that box. Where are those windows??? Also, take a spectrum with the AC turned off and make a comparison with it on/off.

P.S. Why do the entries in this elog not word-wrap in some browsers, while the ones in the TCS lab tab do word wrap?

 

  978   Tue Aug 24 19:24:58 2010 ranaLaserGYROGyro "single-arm" test

 I don't think there's any breathing mode being excited. At low frequencies, we are most likely measuring the air noise. Since the table has its first eigenfrequency above 100 Hz, the flexing at 100 mHz is suppressed by a factor of lots.

Most likely, we just need to plug the giant holes on that box. Where are those windows??? Also, take a spectrum with the AC turned off and make a comparison with it on/off.

P.S. Why do the entries in this elog not word-wrap in some browsers, while the ones in the TCS lab tab do word wrap?

  977   Tue Aug 24 18:52:50 2010 DmassLaserDoublingNotes

New calibration - 10.4 and 15.2 Vpp for green and IR, respectively.

  976   Tue Aug 24 18:37:37 2010 ZachLaserGYROGyro "single-arm" test

 After yesterday's measurement, it dawned on me that the noise measured in the free-running MZ setup is not the only kind of displacement noise we are worried about. It tells us something about the high-frequency shaking of the optics but does not tell us anything about the lower-frequency "breathing mode" type behavior as this is common to both MZ legs. While the gyro is still in pieces (sorry Alastair), I thought I might run a single-arm test, gyro style.

Simply put, I made a linear cavity out of one leg of the gyro, using the big input mirror and the southwestern curved mirror (the one by the laser). This is easy to do because the gyro modematching solution also works for this setup. The idea here is to let it run for some time and measure the low-frequency length drift. Of course, the assumption is that the expansion of the table is isotropic, so that this length drift is an indication of how the area of the cavity will change over long timescales. I don't see why this should not be the case.

Below is a photo diagram of the setup. I left the CW path blocked upstream of its faraday isolator, then installed a PBS/QWP isolator before the last steering mirror into the cavity on the CCW path. The QWP was stolen from the AOM double-pass setup temporarily. I was able to set up the REFL optics in such a way that the normal gyro optics are unaffected; with any luck, we will need no additional realignment as a result of this test.

single_arm.png

The REFL PD is a PDA10A, and the modulation frequency is 33 MHz. I have the slow and fast controls signals acquired, as well as the transmission, so that I can monitor it overnight. I can force the thing to re-lock by messing with the offset to the slow control. This should not be necessary, though, as for some reason we have a MUCH stabler lock with the linear cavity. I have not taken any transfer functions, but it seems clear that we have much higher bandwidth, as I can knock on the table--hard--with no problems. Of course, the cavity is now highly overcoupled, which I believe gives us more optical gain, but in this configuration I can turn the PDH box gain way up before seeing any resonances. The fact that I'm using a 150-MHz REFL PD probably doesn't hurt. This might be reason to believe that our crappy lock issue is PD-related.

  975   Tue Aug 24 16:47:41 2010 ZachComputingGYRONew channels acquired

Quote:

 

 

  I used the GUI to add 4 channels. I logged into fb0 and did "sudo pkill daqd"

 I also added 2 new channels and dropped 2 old ones. DAQ+TP rate is 1703.

  974   Tue Aug 24 15:50:22 2010 DmassComputingGYRONew channels acquired

 

  I used the GUI to add 6 channels. I logged into fb0 and did "sudo pkill daqd"

  • CTRL_ISS_1_OUT = IR PD diff
  • CTRL_ISS_2_OUT = Green diff
  • CTRL_SIG_1_OUT = IR sum
  • CTRL_SIG_2_OUT = Green sum
  • GENERIC_GEN3_OUT = NPRO power
  • GENERIC_GEN4_OUT = PMC Trans Power

I added all the above at 256 Hz (manually adding a 4th order butterworth to each channel at 128 Hz because of the decimation the DAQ uses)

 I had to manually click the "DAQ reload" button on the GDS_TP medm screen to make a funny desynch error dissapear.

The channels seem fine when compared to their fast testpoint counterparts.

  973   Tue Aug 24 15:10:36 2010 DmassComputingCDSFront end rebuilt ----- BURT notes

Burtrestore to Aug 23 00:25

BURT seems to have not been done properly at some point in the last few days (all epics values blank in C2ATF) - I opened up the burtgooey and restored to just before the last backup of the .ini file. This restored everything. Things added since then will have to be toggled back by hand.

 

Do we mean to be taking snapshots every hour?

  972   Tue Aug 24 12:32:41 2010 JennaLaserGYROGyro table displacement noise spectrum

That weird little curve at the low frequency end of the graph is an artificial product of the DTT-- just check the "remove mean" box and it will fix it.

  971   Tue Aug 24 03:00:20 2010 DmassLaserstuff happensThorLabs power meter head appears damaged

Someone burned it.

  970   Tue Aug 24 02:38:42 2010 ZachLaserstuff happensThorLabs power meter head appears damaged

 While I was using the ThorLabs power meter today, I noticed that the slide-out filter appears to have a small bump on it near the center. I don't think I dinged it on anything, and it doesn't even really look like the result of a ding. It's tough to tell from the picture, but the bump is raised up, and not dented in. Has anyone seen this before (on our unit or elsewhere)?

PM_head_damage.jpg

  969   Tue Aug 24 02:18:09 2010 ZachLaserGYROGyro table displacement noise spectrum

 Today, I turned the input and output mirrors round 90 degrees to take a displacement noise spectrum on our table. There were several steps:

  1. Turn the mirrors
  2. Block one input beam path (I chose to use the simpler CCW beam so that I didn't have to have the AOM running, etc., so I blocked the CW path)
  3. Rearrange the setup at the output (in as minimally invasive a way as possible) so that I was looking directly at the power emerging from the two directions. I set up two PDA100A's since they are wide-area and we don't need anything too fast for this.
  4. Ideally, this measurement is done with 50/50 splitters at the input and output, so that the contrast is 100% when the beams are overlapped. Our mirrors are very reflective, so I rotated the input polarization from S to P to take advantage of the fact that the mirrors' R-to-T ratios are not quite as high for P light. I also had the EOM off to avoid adding extra AM and other junk.

I routed the outputs of the PDs to the DAQ, and acquired:

  1. The PD signal with the best contrast. (One output beam has a twice reflected beam plus a twice transmitted beam, while the other has two beams that have each been reflected and transmitted once. If the input and output mirrors had the same R's and T's, then this emerging beam would have 100% contrast. They don't, so it doesn't, but it's better than the other.)
  2. The sum, so that I could normalize the signal in (1) to reject AM.

I then fine-tuned the alignment so that the output was sitting roughly halfway between a bright fringe and a dark one (so that the power was roughly linear with displacement) and took data.

I wanted to normalize the data to the sum as mentioned above, but I don't know of a good way to do it with DTT or the like short of using Simulink to build a divider block and acquire the processed data. In any case, I ligoDV'd the data into Matlab and normalized it there, and the difference is almost unnoticeable. I can include this later if we really think it's necessary. Here is the spectrum:

gyro_disp_noise.png

It is similar in shape and of roughly the same order of magnitude as the MZ noise that Rana measured before (see the SVN NB). It is a bit lower, especially at low frequency, but it's worth noting that the low-frequency noise goes up quite a bit when the lid of our box is open (good work, Alastair).

The calibration here is a bit iffy. I have

dP/dx|phi=0 ~ 4 * pi * r * t * sqrt(P1 * P2) / lambda,

where r, t are the amplitude reflectivity and transmissivity, and P1&2 are the powers in the two beams reaching the output mirror from each side. There is a 50/50 splitter between the output mirror and the PD (I didn't notice this until after), so this is reduced overall by a factor of two.

The PDA100A was on its 0 dB setting, giving GPD = 0.7 A/W * 1510 V/A, and I took the ADC gain to be 6.103 x 10-4 V/ct.

Now the iffy part. Using the powers I measured before the recombination and the r's and t's I measured some weeks ago (yes, for P), I get that the calibration is 2.06 x 10-10 m/ct. However, if I use the measured maximum and minimum values on the PD over full-wavelength swings of the output mirror to calculate dP/dx directly (using the cross term in the equation PPD = |[rE2exp(i*phi) + itE1]|2 ), I get 3.45 x 10-11 m/ct. It is this second calibration that appears above, but it remains to be understood why there is a discrepancy. I could understand it if the contrast got worse due to imperfect overlap, which there surely was, but it appears to be better than calculated. Does not compute.

This would appear to exonerate displacement noise as our limiting noise source at the moment (we've plugged similar numbers into the budget and found that we should be orders and orders of magnitude more sensitive), but it would be either foolish or irresponsible to deny the obvious likeness of the spectrum above and that of our gyro signal. Their characteristics are nearly identical, save for some suppression from the reasonable gain of our feedback loops at lower frequencies. I think we may have to consider the possibility that displacement noise is coupling in through some other mechanism that we haven't yet considered.

  968   Mon Aug 23 20:56:44 2010 ZachComputingGYRONew channels acquired

 I had to acquire a couple of new channels to do the displacement noise measurement today. I added:

  • C2:ATF-GENERIC_DOF7_OUT
  • C2:ATF-GENERIC_DOF8_OUT

I think I inadvertently deactivated C2:ATF-GENERIC_GEN8_OUT, but I don't think we need that one right now anyway.

I used the GUI, and more than one backup .ini file was saved as I did not add the right channels at first. All seems to be working well.

  967   Mon Aug 23 13:13:07 2010 ZachMiscGYROPDH box info put in wiki

 I created a page called "Gyro Equipment" on the Gyro Wiki. This page has links to subpages called "Laser", "Mirrors", "Photodiodes", "PDH Boxes", and "Misc Electronics". I imagined that we can use this to keep track of what equipment we are using when, in case we ever forget. The only living page is "PDH Boxes", which contains information (transfer functions, updated schematics, and--soon--pictures) about each of our boxes as well as a link to the original schematic on the DCC. We should populate the other pages ASAP.

  966   Sat Aug 21 14:28:14 2010 AidanComputingCDSFront end rebuilt ----- BURT notes

Quote:
 1) User directories have been moved into /users. There is now the awesome /users/abrooks/aidan/Aidan/ directory.

Pure awesomeness.

  965   Sat Aug 21 01:50:57 2010 ranaComputingCDSFront end rebuilt ----- BURT notes
 1) User directories have been moved into /users. There is now the awesome /users/abrooks/aidan/Aidan/ directory.
2) The default shell on fb1, ws1, and ws2 is now tcsh. I copied over the .cshrc from the 40m, modified it, and put it into target/.
   The .cshrc in the controls/ directories now is a symlink pointing to target/cshrc.atf. 
3) LIGOTOOLS installed in caltech/apps/linux/. There is now also a apps/linux32/ for all the 32bit apps.

4) MEDM is now setup to use scalable fonts. To launch the usual sitemap, now type 'medm_norm' at the terminal.
   You can do your screen editing using scalable fonts and then everything will look fine with both scalable
   and fixed fonts.

  964   Sat Aug 21 01:06:04 2010 ZachLaserGYROstill noisy (till the day I die)

 you can bring your crew but.. nevermind.

Alastair and I tried out the new-and-improved box #2215 on the gyro today, to see if the noise was improved at all. The short answer is "not really". There is some slight improvement at higher frequencies but at lower frequency the noise is the same or worse, depending on the gain settings we chose. 

new_box.png

I think there is something tricky about how we distribute the gain in the AOM loop (i.e. between the PDH box and the 'deviation' of the VCO), as playing with these

settings produced substantially different results in that loop, as well as in the gyro signal when it was locked.

It bothers me that the CCW (non-AOM) loop is so finicky; it would be nice to be able to achieve the many-kHz bandwidth we desire, but we are clearly limited by some resonance somewhere.

I think this should be our main priority right now, as it not only limits our sensitivity but also proves to be a huge pain in the ass when doing anything that involves touching the table.

Before we take our next breath, we should rotate the input and output mirrors 90 degrees and get a displacement noise measurement (so we can stop living in the past with the ol' 40m MZ).

After that, I would like to fully realign the gyro cavity, as well as get a reasonable modematching solution done for the CW path like there is for CCW. Then we will have decent coupling from both directions and we can tackle the servo stabilization issue.

  963   Fri Aug 20 21:58:43 2010 ZachElectronicsGYROPDH box S/N: 2215 transfer function

 I finished making the modifications to box #2215 (aka "box 2", "the CW box", "the AOM path box", "Killer" etc etc) so that it is identical to #1437 ("box 1"), which Rana modified a few months ago. Attached is the transfer function, which you can compare with that of the other.

I plan to update the schematics and put them---along with these transfer functions and pictures of the boxes---on the Gyro wiki.

Attachment 1: TF_PDH_no2215.png
TF_PDH_no2215.png
  962   Fri Aug 20 15:36:01 2010 DmassLaserDoublingSpectrum Incoming.
  • File saved under /users/dmass/rawdata/MZSpecs/scrn000(2/3).txt
  • Calibration: 7.04Vpp = Green Diff Span (balanced)
  • 14.2Vpp = IR Diff Span (balanced)

 Big things not done:

  • Phase matching temperature found
  • Box not weighed down / screwed down

Would like to do

  • Quick calibration of MZ PZT control signal to get this trended as well, so I can simultaneously measure ERR and CONTROL of IR along side the  green spectrum
Attachment 1: MZ1_2pn.pdf
MZ1_2pn.pdf
  961   Fri Aug 20 03:11:50 2010 ranaComputingCDSFront end rebuilt ----- BURT notes

Some CDS notes:

1) I suggest that we abandon the 'Router as Port Forward' scheme and just adopt what is running at the 40m and the sites:     A gateway machine sits on the LIGO GC network and allows access to the inside network. A NAT router manages the traffic     from the inside network to the outside. I'm not arguing the merits of one or the other, just that its simpler to maintain    if we are all the same. 
2) The Linux CDS apps we are running are all in /apps/Linux/. I suggest that we move to the same apps structure as is being    adopted for aLIGO. The 40m currently has /cvs/cds/caltech/apps/linux, apps/linux64/, and apps/solaris/. We can pick something    similar and then just move all of the binaries over. Its possible, but unlikely, that we will want some solaris. There's also    this /opt/apps/ area which is partially redundant with the /apps/ stuff. Very likely, this is also causing us problems. 
3) We should also switch over all machines to use tcsh instead of bash. All of the sites have tcsh as the standard shell on    all workstations and all accounts, so it will make the setup of the standard environment using the stdenv.csh scripts easier.     We could argue the merits of bash over tcsh until the cows come home, but its all already been hashed out on internet newsgroups.
4) For some reason, we have bad user directory stuff going on like /cvs/users/abrooks and /cvs/users/users/aidan. Please don't    make your user directories in the ~/ home directory but instead everyone just use e.g. /cvs/users/homer/. /cvs is the shared    disk and is visible on everything. This is the one that we will set up for the daily cron rsync backup to CACR like the 40m does.
5) For BURT, today I made a /cvs/cds/caltech/burt for us along with a autoburt/ dir and a snapshots/ dir in there. This sets up
   the directory structure until 2016. I also copied over the burt.cron and the autoburt.pl. The autoburt.pl has a bunch of hacky
   stuff for finding out what site we're at and bypassing the Y2010 problem, but I'm hacking the hack.
   
6) For BURT, I set the hourly cron on fb1 by using 'crontab -e'. At 18 minutes after the hour, each hour, it will save a snapshot
   of whatever in the target/ dir has an autoBurt.req file. Log files are written to autoburt/logs/ and the snaps are saved in
   autoburt/snapshots/. Its failing on the pslepics right now since Frank just turned it off, but its a good test to show that
   a dead FE doesn't crash the autoburt.

   To do restores after a reboot, you can use the 'burtgooey' tool. In principle the 'startatf' will also do an automatic restore
   but that relies on the system being in a good state the last time the 'killatf' was run.

7) Next, we should set up the CONLOG infrastructure so that we can easily find diffs in control settings.

8) We also want to record all of the SLOW channels from our MEDM screens as DAQ channels (e.g. INMON, EXCMON, OUTMON, OUT16, & OUTPUT).
   For this we need to copy over the script Rob wrote to automatically produce an .ini file from the .db file in the corresponding
   target directory.

That is all.

  960   Fri Aug 20 00:56:03 2010 FrankComputingDAQPSL RT fronend code shutdown

i've killed the PSL RT frontend code. Everything else should be ok, so plz check if everything is working.
If not plz let me know and i will fix it.

  959   Thu Aug 19 22:04:55 2010 Alastair & RanaComputingComputingFront end rebuilt

Rana and I re-made the front end code today and restarted the front end at around 8pm.  We didn't change any of the model - this was mainly just an exercise to try to document the process so that it can be put up on the wiki.

Rana also discovered that BURT is working, and we can use this to log and restore the values in our MEDM screens.  We just need to manually write and restore the BURT snapshot files just now.  The auto-BURT isn't working for the moment.

After restarting we now have a new C2ATF.ini file, so if anyone was recording frames in C2 then they will need to use the GUI to restart the frame logging for that channel (use daqconfig to get the GUI up).  Since this GUI is working we should all start using it exclusively when we add new channels.

  958   Thu Aug 19 13:18:17 2010 AlastairLab InfrastructureComputingWiki

Quote:

We need to rebuild the front end soon, so to kill two birds with one stone I thought we could document it on the wiki as we go along.  At the moment the ATF wiki page doesn't want to work.  I'll ask around to find out where it lives and who knows how to get it back up and running I have made this elog the official Rana colours of green and purple along with an assortment of font sizes to appease the wiki gods.

 Wiki gods have been appeased.  The CIT wiki had been moved.  ATF wiki can now be found here.

The top level wiki page is here

  957   Thu Aug 19 12:22:25 2010 AlastairComputingGeneralThe BURT situation

Quote:

Quote:

Quote:

i don't know if there is a wiki or something like that but i do exactly what Alex and Rolf told me to do:

 This is a horrible, horrible precedent to set. Please immediately make a wiki page so that EVERYONE uses the SAME procedure for rebuild each time.

                                 Not following a rigid procedure leads to a lot of wasted time.

 There is one in the ELOG, entry 124 "Realtime code generation (RCG) troubleshooting":

  http://131.215.115.52:8080/AdhikariLab/124

Thanks for posting that link Frank.  We're going to rebuild the front end soon to make changes for the gyro and we'll follow this method.  If it all looks good and works then my plan is to add an 'internals' and 'how to' section to the ATF wiki (following the same site plan as the 40m so that people know where to look for stuff) and we can start putting some useful information in here about standard things.  If there is useful information on how to do things that is already posted on the 40m wiki we can just link to that.

I would suggest we also add such useful information as 'how to add channels to the frame builder' so that everyone is doing the same thing.  Maybe that way we can converge on a more stable computing environment for everyone.

  956   Thu Aug 19 12:01:13 2010 FrankComputingGeneralThe BURT situation

Quote:

Quote:

i don't know if there is a wiki or something like that but i do exactly what Alex and Rolf told me to do:

 This is a horrible, horrible precedent to set. Please immediately make a wiki page so that EVERYONE uses the SAME procedure for rebuild each time.

                                 Not following a rigid procedure leads to a lot of wasted time.

 There is one in the ELOG, entry 124 "Realtime code generation (RCG) troubleshooting":

  http://131.215.115.52:8080/AdhikariLab/124

  955   Thu Aug 19 11:49:15 2010 FrankLab InfrastructureComputingrouter...

Quote:

The internet was down again when I came in this morning.  I power cycled the router and left it for longer than I did yesterday and everything came back to normal.  Maybe it was the router that was the problem the other day as well, but I just didn't leave it for long enough before I power cycled the network switch.

We should probably swap this router out to see if the unit itself is causing the problem.  Does anyone know if we have a spare or a preffered vendor?  If we don't have a spare I'll order an identical linksys unit from somewhere.

 It's the router, i've tested that already. We don't know what causes it but Larry said that this might happen if we are running a lot of traffic across it. I don't know if this is true but anyway the plan is to use fb1 as the router instead and also as our internal DHCP and DNS server so that we don't have to give fixed IP addresses and names to computers anymore. Instead we give them a fixed address by knowing their hardware MAC addresses. This is much easier to handle because you only have one config file which contains the entire network setup and if you wanna change something you only have to change that file and not login in all individual computers to make changes. This makes sense as we have almost 30 devices by now...

  The original plan was that Mott will do it but i think now it's on me. I already have the additional network cards we have to install but so far i didn't have the time to shut down everything (we have to shutdown really EVERYTHING as fb1 is used a the global source for all tools incl. the RT code and stuff) and start working on that. We might wanna do that early September as i gonna leave Tue morning to LHO and there are some guys which wanna install sprinklers in the PSL lab until then....

  954   Thu Aug 19 11:44:23 2010 AlastairLab InfrastructureComputingWiki

We need to rebuild the front end soon, so to kill two birds with one stone I thought we could document it on the wiki as we go along.  At the moment the ATF wiki page doesn't want to work.  I'll ask around to find out where it lives and who knows how to get it back up and running I have made this elog the official Rana colours of green and purple along with an assortment of font sizes to appease the wiki gods.

  953   Thu Aug 19 11:33:31 2010 AlastairLab InfrastructureComputingrouter...

The internet was down again when I came in this morning.  I power cycled the router and left it for longer than I did yesterday and everything came back to normal.  Maybe it was the router that was the problem the other day as well, but I just didn't leave it for long enough before I power cycled the network switch.

We should probably swap this router out to see if the unit itself is causing the problem.  Does anyone know if we have a spare or a preffered vendor?  If we don't have a spare I'll order an identical linksys unit from somewhere.

  952   Thu Aug 19 11:23:44 2010 RanaComputingGeneralThe BURT situation

Quote:

i don't know if there is a wiki or something like that but i do exactly what Alex and Rolf told me to do:

 This is a horrible, horrible precedent to set. Please immediately make a wiki page so that EVERYONE uses the SAME procedure for rebuild each time.

                                 Not following a rigid procedure leads to a lot of wasted time.

  951   Thu Aug 19 11:17:43 2010 FrankComputingGeneralThe BURT situation

i don't know if there is a wiki or something like that but i do exactly what Alex and Rolf told me to do:

  • login as controls
  • go to  /cvs/cds/advLigo/
  • "make clean-psl psl install-psl uninstall-daq-psl install-daq-psl install-screens-psl" or  "make clean-atf atf install-atf uninstall-daq-atf install-daq-atf install-screens-atf"

but those scripts have some problems which we know about, e.g. there is no uninstall of the old screens, so we have to delete old ones which don't exist anymore by hand

Quote:

The AutoBURT at the 40m is run by a cron job which runs a perl script.

For this to work, we need for the c2atfepics to have its own autoburt.req file in the target/c2atfepics/ directory.

The usual build procedures have the 'make install-daq' and 'make install-screens' scripts which read the .db files from the atfepics/db/ directory to create the .req file.

If those have not been run, maybe they should be? Where is the wiki procedure for the FE rebuild anyway?

 

  950   Thu Aug 19 04:11:09 2010 DmassLaserDoublingPMC problem solved?

I looked a little closer and found what I think are my problems. When I swept the cavity, the reflection dipped down to zero, so PMC is fine.

  • I was saturating my PDH sensing PD...I also noticed this when I swept the cavity.
  • I noticed that my locked PMC was oscillating at my modulation frequency (280 kHz)...so I added a few attenuators - final count: 13 - 6 - 90 = -83 dBm at laser PZT
  • I changed the sign of my feedback. Loop went to uber locked. Is it really possible that I was sitting on the wrong side (the tail) of my error signal?
  • Power through is now almost complete. I can no longer see the reflected beam on a sensitive card.
  • Measured: 1W transmission (with OPHIR high power meter), 38 mW reflection (with thorlabs meter).
  949   Wed Aug 18 21:14:49 2010 ranaComputingGeneralThe BURT situation

The AutoBURT at the 40m is run by a cron job which runs a perl script.

For this to work, we need for the c2atfepics to have its own autoburt.req file in the target/c2atfepics/ directory.

The usual build procedures have the 'make install-daq' and 'make install-screens' scripts which read the .db files from the atfepics/db/ directory to create the .req file.

If those have not been run, maybe they should be? Where is the wiki procedure for the FE rebuild anyway?

  948   Wed Aug 18 20:15:45 2010 ranaComputingDAQNever use lower case in MEDM/DAQ/CDS

There is an official policy to never use lower case letters in names of front end systems, channel names, MEDM screens, etc. Don't ask why or ask me to prove to you how exactly it breaks things; just trust me that it does and change all of your lower case stuff into upper and the rebuild the front end.

I also found that there was a profusion of sample rates in the C2ATF.txt filter coefficient file. This doesn't make any sense, so I changed them all to 32768 Hz. I have also now hit 'Load Coefficients' in some random places, so beware. Your filters may have been bogus before.

  947   Wed Aug 18 18:15:49 2010 Alastair, Zach and RanaLaserGYROPDH locking of the CCW loop

Looking at the error signal for locking the laser to the gyro (CCW loop) while we sweep the laser frequency we have the following plots.  Blue is error signal, yellow the reflection signal from the PD, pink is the drive signal and blue is the transmission signal.

The first shot show how the system was to begin.  Rana pointed out that the signal is messy on either side of resonance suggesting something not-so-nice is happening.  We diagnosed that the sidebands were partially leaking into the cavity on resonance.  The sideband frequency was 14MHz at this point.

We tried increasing the frequency to 20MHz but the signal got a lot smaller (due to bandwidth of the PDs).  Instead we turned it down to 6MHz and now get  the second plot where the error signal is nice and smooth and the sideband signals on either side are asymmetric.

 RA:   We also found that attaching a long-ish BNC cable to the PZT drive input (also used for test injections) causes the loop to oscillate at ~235 kHz. It must be that the extra capacitive load is the problem, but I'm not sure why there is any effect. Could be that its the PZT resonance, but that's unknown until Zach/Dmass do the laser beating PZT sweep measurements.

Attachment 1: TEK00003.PNG
TEK00003.PNG
Attachment 2: TEK00004.PNG
TEK00004.PNG
  946   Wed Aug 18 12:03:23 2010 AlastairElectronicsGYROPDH boxes

I was looking at the error signal from the two loops, wondering why the CW one looked so small.  I decided to swap around the locking loops  as we discussed at the meeting the other day.

To begin with I swapped the laser feedback onto the feedback signal from the CW loop.  It would barely lock, so I tried sweeping the laser freq to see what the error signal looked like.  It looked very small.

I decided to swap the PDH boxes to see what that did.  The signal was now very large.  I went back to locking the laser to the cavity using the CCW loop, and took two error signal measurements, one using each PDH box, with exactly the same settings and connections.  You can see from the pictures below that they are very different.  The one with the really small signal is the one we were using to lock the AOM before.

I will take the PDH boxes down to investigate.

**EDIT** Internally the two boxes don't appear to be the same though I'm not sure how big the differences are.  Firstly, the working one has a 1.9MHz low pass filter t-d to a 50ohm terminator going from the output of the mixer to the 'mixer out' bnc connector.  The second box has only a 5MHz low pass filter there.  I swapped the parts out of the first box into the second to test if there was any difference and there was not.

Second obvious difference is that the working box has a 10K resistor added going from the center pin of the piezo sweep input to the op-amp side of R19 the piezo driver output amp.  It would seem that this is basically just bypassing the relay that the piezo sweep switch uses. 

**EDIT 2** I found Rana's elog entry that tracks the changes to box 1 (the working box).  It is here: http://nodus.ligo.caltech.edu:8080/AdhikariLab/642

I don't see any mention that any work has taken place on the second box.  I'll print the schematic and mark up the changes that were made to box 1 on it.

Attachment 1: TEK00000.PNG
TEK00000.PNG
Attachment 2: TEK00005.PNG
TEK00005.PNG
  945   Wed Aug 18 11:52:00 2010 AlastairLab InfrastructureGeneralInternet in lab was down again

I power cycled the Linksys router but that didn't do anything.  Then I power cycled the 3com switch, and it came back on again.

  944   Wed Aug 18 10:31:28 2010 AlastairLaserGYROExcess noise mystery resolved

Quote:

After some navel gazing, this all no longer seems so surprising. A block diagram of the system with the noise terms labeled should reveal why there is almost no beat signal with the CW servo turned off. I believe that there is no gyro signal in the modulation off case.

 

Indeed there is no gyro signal.  With only one path locked, any rotation will cause the laser frequency to shift identically in both directions and there is no signal.

We do however still have a beat signal since the beam is still coming through in transmission.

There are a few noise sources that should still show up in this.  Any non-common mode mechanical noise in the cavity for example.  Also any mechanical noise in the M-Z readout, any noise in the transmission readout and electronics, and any phase noise in the PLL.  We should also see noise from driving the AOM since it is still on.

There are also a lot of noise sources we shouldn't see.  Modulation of the FSR by mechanical noise for example.

I guess the point I was trying to make is that this excess noise can't be a real rotation signal, so perhaps it points us towards what the main source of noise is.

  943   Wed Aug 18 03:01:23 2010 ranaLaserGYROExcess noise mystery resolved

After some navel gazing, this all no longer seems so surprising. A block diagram of the system with the noise terms labeled should reveal why there is almost no beat signal with the CW servo turned off. I believe that there is no gyro signal in the modulation off case.

 

ELOG V3.1.3-