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

 Still not got the cavity back to locking properly yet.  It'll have to wait till tomorrow.  I don't understand why the PDH signal has a really large positive side and small negative side when you scan the cavity - it needs more investigating.

I popped out to the 40m around 9pm to check the Rb clocks.  They had come out of lock earlier (possibly due to being too hot inside the igloo).  Rana has put a post up here about them http://nodus.ligo.caltech.edu:8080/40m/3361

They take about 12hrs to lock so the estimate of tomorrow afternoon seems reasonable.

 A million seems like a nice round number to start from.

We found one photodiode over here that we can use for the transmission readout.  I was putting it in.... then the stuff in that other elog post happened.

After we took that noise spectrum we started putting in the PD for the transmission readout.  It can only take 55uW according to the spec sheet so we started by turning the laser power down a bit and then we were putting in a BS to reduce the power even more.  We were just getting this set up when the cavity stopped locking properly.  I was working on the theory that it was the lower laser power was causing issues, so I turned it back up - still won't lock.  I checked the beam is on the reflection PDs (it is) and that they weren't saturating (they're not).

We're getting big dips in power on the reflection PD when I scan the cavity through resonance.  We also get a big error signal out of the mixer when I scan the cavity, but it looks kind of one sided (there is a massive positive side and hardly any negative side).  I can also see the error signals from the sidebands resonating, and they look more normal.

What we're seeing when we try to lock is that it only stays locked for a couple of seconds, and we get big fluctuations in the control signal to the piezo, before it falls out of lock.

More investigation will ensue.

PS.  The mojo beads were on the laser - Jenna has removed them in case they were giving it bad vibes.

That's great! Only a factor of 1 million to go!!

The Tektronix generator is a horrible, horrible, monster and it should not be used as a VCO if at all possible. What's the loop gain for the CW and CCW loops? We need measurements. Also need to see the error point spectra of these loops out to high frequency. By looking at the error spectrum before and after a small increase in gain, one can infer the UGF.

Also, the 40m has one spare PDA255 which can be used to measure the beat frequency in transmission. Its in a plastic tub next to the RF stuff. Luckily Zach is working on a resonant RFPD and we can have something real very soon.

Here's a plot of the AOM feedback signal. The SR560 is DC coupled with a gain of 10, and the calibration for the data is

6.1e-4 V/count / 10 x 700 kHz/V * lambda*S/4A * 2pi (rad/s)/Hz = 3.618e-4

6.1e-4 is the calibration from the DAQ, 10 is the gain from the SR560, 700kHz/V is the deviation set on the Techtronix function generator, S is the perimeter of the cavity, and A is the area. One side of the cavity is .7889m.

 I just ordered a 1811 photodiode from Newport for temporary transmission readout duty.  I've ordered the one with the AC coupled output.  It's in stock so should be with us soon.

Sorry about the camera.  I was using it and didn't put it back in the drawer.  It's in there now.

I put these mode matching lenses in for the ovens...I realigned the Mach Zehnder with no focusing lenses for the PDs and was able to see fringes on the PD.. I can't find the lab camera and my iPhone died, so no picture.

Without trying very hard, I was able to get fringes with a min of 2.32V and a max of 4.88V on the scope, in green. When I get back from LLO I will be going straight to phase noise spectra.

 Scratched in favor of the following:

f=100mm at 0.47 m

f=75mm at 0.758 m

This works well with the current table layout.

taking Zin at PMC to be 371^2*pi/1.064 um

and Zoven to be 1.8*10000/2 um, about 36-37 inches from the PMC

These rayleigh ranges correspond to waists of 151 and 146 um.

The spec for the Mephisto from the operating manual which was shipped with the 35W system gives a location of 9 cm inside the laser, not terribly different from 5 inches inside the laser. They did not seem to provide a number for typical waist size. Contacting Rick.

 This explains something. The chronological story (elog entries hyperlinked):

1. I measured the waist of the NPRO (either I did it wrong, or it changed with temp/current)
2. I calculated the mode matching for that waist, with 250mm and 200mm lenses
3. I put them on the table in what I calculated to be the right spot
4. I measured the waist of the input beam via the transmission through a steering mirror at the PMC waist
   1. It was grossly wrong
5. I adjusted the mirrors by hand to give it the right waist (call these positions X1 and X2)
6. I aligned into the PMC, and locked it, and noticed I only had about 25% transmission
7. I measured the PMC waist
8. I tried to adjust the lens positions by hand, hoping that my mode matching solution was sensitive to position / focal length errors.
   1. I moved the lenses by about a half inch in a few directions, realigning common/differential steering into the PMC each time
   2. I noticed no appreciable gain in any direction
   3. This is not surpising because I set the position of the lenses by forcing a 371 um waist at the PMC waist location
9. I looked at the mode coming out of the laser, and on the PMC reflection
10. I despaired that I might just not have much power in my TEM00
11. I measured the beam profile after my first mode matching lens as a sanity check (250 mm focal length at 18 in) - plot at bottom of this elog
    1. I noticed that I couldn't get fits which were all that good - does this mean my M^2 is high?
12. I redid the mode matching into the PMC with new lenses, aligned them into the PMC, locked it, and noticed a donut mode on REFL
    1. This is indicative of my mode matching being terrible
    2. I measured the waist with the wincamD at the PMC, it was WAY off (2mm instead of 370 um)
13. I redid the beam waist measurement of the NPRO
    
    1. It looks drastically different
    2. I have changed both laser current slightly, and had feedback to the temperature
    3. I dont know if the above could cause that huge of a mode shift, or if it's just a somehow failed measurement with the wincamD. It's NOT a factor of 2.
    4. It had a funny mode shape (to be attached)
14. I redid the mode matching with the new NPRO waist, and old lenses, and got the attached plot
    1. This is very similar to the first set of positions which I got moving the lenses by hand and using the wincamD, which leads me to believe the mode matching was roughly fine in the first place.
15. I expect to find similar crappy (~25%) power transmission with this (old/new) mode matching solution and the "new" beam waist measurement, as I think I already did just this on the table
16. If this is the case, I wonder if using a different laser is better...
17. I was thinking of doing a cavity scan to see if there was a lot of "junk"
    1. If I do a cavity scan, will I see all the modal power? - that is to say, if I have a lot of higher order content, will it necessarily resonate in the cavity at some length
    2. Maybe what I'm asking is "do the resonant mode of the cavity form a complete basis for the HG laser polynomials?"
    3. Intuitively it seems like I could just get "unlucky" and have a lot of power in misc. mode which happen to not resonate strongly / at all in the cavity when my 00 is aligned perfectly - I'm half expecting someone to respond and let me know that this is not possible, and if I lock the cavity and align to 00, then scan, I have to see the higher order content I have in transmitted power.

I redid the NPRO measurement and got this:

This might explain some of the rediculousitude of my inability to get mode matching to make sense...

I had only 25% coupling through the PMC, so was double checking my mode matching with the wincamD.

• Measurement of the H1NPRO beam profile
  • This is either wrong or changed (See this elog)
• Proposed mode matching solution (updated)
  
  • I double checked my mode matching solution with a program Frank put on fb1 (called mm.exe, under /home/controls) from one of the Germans. The results were consistent.
  • The mode I get at the PMC is WAY OFF from what it should be. ~750-800 um waist radius...
  • I saw this inconsistency on the first iteration of mode matching as well, and just tuned the mirrors by hand using the wincamD to make it 370 um and put it in the right place.
  • I had about 25% coupling max with the previous iteration.

I took some profiles with the WINCAMD of the transmission through one of the steering mirrors, and noticed that my fit didn't seem to....fit. This seems consistent with having a high M^2...Some notes on the measurement:

• WinCam did not seems saturated (no white area on the CCD 2d color scale image)
• Bleeding (blooming?) on CCD not on either measurement axis (also was not large)
• used X orientation of the U and V axes for getting waists

IF I DOUBLE CHECK MY MEASUREMENT OF THE H1NPRO WAIST SIZE / LOCATION, AND CONFIRM IT, WHAT DOES THIS ALL MEAN FOR ME?

The fear: There is just loads of higher order content in the beam, and only 25% of the power is in the TEM00...

From Frank - if it's the alignment of the pump diodes inside the NPRO, we can see this quickly by opening up the NPRO. I do not desire to do this before I finish my paper/experiment.

I had never measured the output of the PMC. Here is a measurement of the waist at low power (~120 mW) with the H1NPRO. Nota Bene: The input mode is somewhat trash at this power (pics to be included later). I used the vertical axis of the wincamD to take this (should be tilt insensitive)

Hey Team (aka Jenna and Alastair),

I took my Guralp handheld breakout thing + cabling back to the 40m so I can figure out WTF is up with my seismometers.

 Appropriate zeros added to appease the evil doctor.

 Even better would be to get 3 trillion mW for 12 mW input. Then we could take over the universe!

Sounds pretty good if you ask me. 

The second order RC low pass filter does this according to LISO -

since you can't treat a second order system of RCs like this as though it were modular and just cascade them, it seemed prudent to include a liso plot:

Vin___4.7k________4.7k________Vout

                        |  1n              |  1n

                      gnd               gnd

I was trying to understand why the mode matching through the PMC was so bad (I got 30 mW transmitted with 120 mW input).

• I looked at the mode on the PMC REFL camera, and it did not look very guassian.
• I changed the laser current from 2 A to 2.2 A (what Rick said they ran it at at LHO) and saw no change in the mode
• I tried to take a beamscan...but could not find the WINCAMD and its computer (again.) I checked the usual suspects (PSL/TCS) and didn't see it.

So. Who knows where the wincamD is?

added: pics of PMC REFL before and after locking, in order

Totally possible that my mode matching is just that crappy? Maybe.

I did take beam scans of the mode going into the PMC just before aligning to it for the final time. I can do so again to get real profiles and characterize the H1NPRO

I found a bad 6dB attenuator which I had in rotation, it seems to either be mislabeled, or have a broken connection. I labeled it NFG?

Audio Locking:

I am using 270 kHz at about 5 mV into the PMC to generate audio sidebands. I chose 270 because it has around a modulo pi phase, which means I don't have to build a phase shifter, and it seemed to have an acceptable FM / AM ratio.

The measurements in this plot were made using the 13dB LO mixer.  We increased the gain on the SR560 going into the daq to 1000 and AC coupled it to get above the daq noise floor.

Measurement 1 was made when the phase of the clocks was not quite exactly pi/2.  The issue here is that we can be sensitive to amplitude fluctuations as well as phase.  The output voltage from the mixer was at -200mV.  We then swapped the bnc cable lengths to get as close as possible to a pi/2 phase difference.  In the end we got to 20mV (the calibration here is 1v/pi rads and at 0v the signals have pi/2 phase).

Rana noticed that according to the clock's spec they are pretty sensitive to temperature fluctuations.  The third measurement in these plots was with some 'thermal insulation' on the clocks.  We didn't leave them long enough to reach any sort of equilibrium temperature, but it should have blocked out the external fluctuations a little.  Koji and Jenne then stole the thermal insulation from our experiment - thus putting personal comfort above scientific discovery (though Koji at least did elog what time they did it).

I changed the mixer in the phase measurement for a 7dB local oscillator one at around 7pm.  Data from before this time should still be calibrated using the 1V / pi rads value.  At this point I also had to change the gain on the SR560 to 100 to stop it railing.

When I changed the mixer this evening, I also tried unplugging the 1pps signal that is locking the clocks.  There was no noticeable drift, and I think we could easily make a measurement by leaving them synced and then unplugging them just before we measure.

Rana also suggested that we try making making a measurement with a phase difference of 0 rad, to make an amplitude noise measurement.

RA: I changed most of the 'pi's' above to 'pi/2'. The phase noise measurement is best done with a 90 deg phase shift between the signals. Either 0 or pi gives an optimum for amplitude noise measurements. Alastair changed the mixer from a Level 13 ZP-3MH mixer to a Level 7 XXXX mixer because the 10 MHz output of the Rb clocks has an amplitude of ~450 mVrms into 50 Ohms (that's pretty close to +7 dBm). In the previous setup, the mixer was working in a somewhat non-ideal mode so we can't really trust the results. We will have to take back Jenne and Koji's jackets and retry the measurement.

I measured the capacitance of the BLK-89S+ from minicircuits. They include neither a cut off frequency, nor the capacitance in the datasheet. Just a picture of a capacitor.

220 nF is the answer I got.

Thorlabs PD - 50 Ohm output -----220 nF----->mixer input (50 Ohms to ground?) seems to imply that the DC block has a transfer function of S/2/(S+1/2RC), with a frequency of 7 kHz. Everything gets through.

I will soon be taking data with the framebuilder. Please elog restarts / etc...If  dataviewer is frozen when I come in I want to know if someone restarted some process, or if something about the frontend is messed up

I redid the mode matching into the ovens to account for the dispersion of the material affecting the Rayleigh range (like this)

I used Zr = L_crystal / 2 / n

I bought some lenses (of the AR.18 variety) to replace the missing ones from the newport lens kit. People should continue to do this. They will likely arrive while im at LLO, so someone should put them in the kit when they get here.

The bottom 560 was making a bunch of clicking noises and had flashing red lights on the overload and battery indicators. I have turned it off.

 I couldn't get data from dataviewer earlier, so I came over to the 40m to look at it here. Unfortunately the system here is down at the moment and Alberto is rebooting it just now.

I went in to take a look at the beat signal on a scope and the good news is that the clocks have now synced.  I'll get back out here tomorrow some time to take some data.  They are not at the zero-crossing point, but are sitting about 200mV off (500mV is pi radians of phase).  I'll try to adjust this with some different lengths of BNC tomorrow.

Till I get proper read-out, here is a picture of the scope screen.

 This afternoon I tried getting the clockwise beam (AOM beam) into the cavity.  We didn't have much success the last time, mainly because it was so difficult aligning the beam from waaaaaayy back before the faraday.  So this time I tried a different approach.  The plan this time was to align the CW beam to the cavity, and then to put the faraday back in place after the alignment.

I took out the faraday altogether, and the mirrors after the faraday.  I then aligned the incoming CW beam along a line of holes on the bench and checked the 4" height along the length.  This step was just so that we had a well defined beam path to put the faraday back in place later.

After some fiddling with the mirrors that go after the faraday I got the CW beam aligned to the cavity and resonating.  I made sure it was overlapping the CCW beam in the cavity, and checked that the reflected CW beam was overlapping along the input path.  Then I put the faraday back in place and moved it around till I got the beam through it and the CCW reflected beam back out of it.  I put the 1/2 wave plate back in, checked the polarization and then setup the mirror, lens and PD for the reflection locking of the CCW beam.  I got the cavity locked in the CCW direction again after changing the power back up to 5mW in that direction (somewhere between 5 and 10mW seems to give a nice error signal.  It may lock below this, but we were using 5mW before so I'm continuing with that just now).

With the CCW locked on the 00 mode I then swept through the frequency on the AOM till I got the 00 for the CW direction.  Then I played with the alignment a little till this looked good (I've not tried maximizing the transmitted power in this direction yet like we did for the CCW direction, so that's on the 'to do' list).  Then I got the PD for the reflection locking of this direction aligned and put the signal into the second PDH box.  I checked that we were getting an error signal by sweeping the cavity and we are.  Then I hooked the PDH box up to the frequency modulation input of the VCO for the AOM.  

The CW direction was already close to being resonant on the 00 mode so it was difficult to tell if this was really locking.  As a sanity check I t-ed the output of the PDH box to a scope and then changed the center frequency on the VCO for the AOM.  As I changed the frequency you could see the output of the 2nd PDH box tracking this and the CW direction of the cavity stayed locked to the 00 mode. 

I'm not sure if this is a known issue, but I can't get dataviewer to plot channels from the 40m when I am at a workstation in the ATF.  I can get data using DTT, and I can get dataviewer to connect (using nodus.ligo.caltech.edu and port 8088). I can see the channels listed but when I try either realtime or playback it won't show the data.

I've added SR560s to all three channels of the seismometer now.  They're DC coupled with a gain of 100, low pass filter at 10k and I'm running them on battery to avoid grounding the seismometer outputs.  The manual says that the battery should last 20hours so we might need to use a different solution to get more data (I'm assuming we don't want to use the mini circuits bnc transformers for this since it's not RF?).

We are now well above the DAQ noise.  Here is a plot showing 10 averages of the vertical, N/S and E/W data plotted calibrated in volts (GPS 964463447).  We will now take seismic data for 24hours.  Setup completed at 11.40am July29.

 The new rubidium clock arrived today from SRS.  It is a FS725 and the calibration sheet, manual and control program on floppy are in the filing cabinet in the ATF.

At the moment we are doing some testing of the clock, beating it against a second rubidium clock at the 40m.  The setup is that we have the 10MHz output feeding into a mixer (it is a 13dBm mixer at the moment but we should change this).  Each output is transformer coupled to avoid ground loops.  The output of the mixer goes through a low pass filter (10MHz I believe) and into an SR560 with a gain of 1 and DC coupling.  This signal is going into the channel mc_drum1 of the ADC.

The clocks are drifting relative to each other with several minutes period.  We need to make the measurement of phase noise close to the zero crossing of the beat so that we are sensitive to phase and not amplitude.  We did a few things to try to get the clocks locked in frequency.

First we tried locking the clocks using the freq adjust input on the back of the new clock.  We took the mixer output (giving ~500mV for pi radians phase difference) and used an SR560 to feedback.  It wasn't clear whether this was doing anything or not.  The frequencies did get closer over ~30mins, but this may just have been because the new clock is still aging (and also warming up).  After this time it appeared not to be getting much closer.

Next we removed the calibration sticker to get at the manual frequency adjust underneath it, and gave 3 clockwise turns (0.0025Hz per turn).  There was no immediate (or noticeable) change to the beat frequency.

We have now left them with the newer clock synced using the 1pps output from the old clock.  The sync light is on, but the frequencies were not getting any closer when I left them.  We're taking data and we'll look at it again tomorrow to see if they are getting closer.  There is some long time constant used for this locking loop (~2hours) that will make this take quite a long time.   We can shorten this time constant using the software and RS232 input if we need to.

 DYM - Not yet, since I am getting the signal for the transfer function by mixing down the beats between the various sidebands, the calibration wasn't immediately obvious to me (though it may well be simple).

Here is a diagram of the measurement.

N.B. there is an attenuator right after the first power splitter on its way to the NPRO PZT, I am not giving it 7 dBm of juice

Here is what I think is a transfer function of the frequency response of the H1NPRO PZT. Ideally, I would use a resonance with modulo 180 degrees
 of phase shift, and a relatively flat phase / frequency response

RA:  No units on the Y-axis???

We have the Gurlap seismometer working, and it took data overnight (mostly) successfully. The North-South channel was not turned on, but as of this morning all three channels (North-South, East-West, and Vertical) are up and running. I've attached a plot of some data for the E-W and Vert channels comparing the noise at 3am and 11am. We calibrated the data by first converting from counts to m/s by multiplying by 40V/2^16*(1/802V/(m/s)). The 802V/(m/s) calibration comes from the Guralp spec sheet (which I've attached as a pdf). The calibration for all three channels is different, but the difference is less than 1%, so I've just chosen the calibration value for East-West and used it for all channels.

The channel names are

Vertical-- C2:ATF-GENERIC_DOF6_OUT_DAQ

North-South-- C2:ATF-GENERIC_DOF7_OUT_DAQ

East-West-- C2:ATF-GENERIC_DOF8_OUT_DAQ

After we have 24 hours of data, we'll make plots for more times on all three channels.

I could sweep a couple FSR using a function generator into the PMC. A few numbers:

• PMC FSR - 713 MHz (From design doc)
• Voltage at drive box for 1 FSR = 3.5 +/- 0.3 V
  • Error bars generated via nonlinearity: (I ran through three FSR on one sweep, with one of the FSR around 0V input, the two FSR were 3.2 and 3.8 Volts, repsectively).
•  
• Voltage at PZT with 0V into driver = 142 V
• 10 Vpp triangle wave at drive box = 184 Vpp at PZT drive (measured using a 10 Vpp triangle wave out of a function generator, watching the PZT voltage with a Fluke)
• Calibration at input to drive box - 202 +/- 20MHz / Volt
  
• Calibration at PZT - 11.1 MHz +/- 1 MHz/ Volt

Spectra shall be calibrated henceforth, or at the very least, calibratable.

Added: Calibrated PMC control signal in Hz/rtHz- As this should be totally coherent with err, I should just be able to divide by the open loop transfer function between ERR and CTRL...(I guess my Hz -> Volts bit of the OLTF on the error signal needs to be measured to get this no matter what...so I would end up with a Volts ->Hz for my error signal anyways...)

• Foton isn't letting me add filters for some reason. It didn't earlier today, and Aidan had to change permissions (via chmod) to some process (Which?), then I could. I left and came back, and I could no longer write to Foton again.
• Note that I am feeding back on the temperature of the NPRO.
• WHOOPS: For correct spectrum I need to apply 2 poles @ 1Hz, 2 zeros at 10 Hz, 1 pole at 72 Hz, and a unity DC gain...

I locked using the PZT pole at 70 Hz with an SR560 - I am using a feed through with the front end to generate an integrator with a pole at 70 Hz and add it to this signal with the other 560 input channel

I ran into some problems seeing anything in DTT. Frank can see all his channels (C3 PSL), but we can't seem to get the C2 ATF) channels. Will investigate further.

The transfer function:

• Dewhitening in Driver Box:
  • 2 zeros at 10 Hz
  • 2 poles at 1 Hz
• PMC PZT Pole from driver box / PZT capacitance
  • 72 Hz
• 2f filtration
  • 2 poles at 10 kHz

Not that I see how this could have changed, but did you do the standard error signal checks? If you switched a cable here or there the RF phase will have changed, and you might need to retune it and/or flip the inverter on the bluebox. I know you know this but it can't hurt to mention.

Also, when you do get the CCW locked again, before you get the other PDH box form the 40m, you might want to check that you indeed have the right beam into/out of the AOM by just looking at the CW output on the TRANS CCD. If you see a 00 somewhere around an f_mod of 47.5 MHz then you're golden; if you only see higher-order modes, you probably have the once-passed first order or something, like we did one time before.

I ran startatf on fb0 after changing the ATF.ini file to include a channel

[controls@fb0 daq]$ startatf
audit_log_user_command(): Connection refused
atfepics: no process killed
audit_log_user_command(): Connection refused
atfepics C2 IOC Server started
./startupC2: line 2: iocC2.log: Permission denied
audit_log_user_command(): Connection refused

I did a "sudo startatf" and there were no error messages about the ./startupC2 script.

You may have jitter because of the PZT actuation. It may cause noise in the PDH signal by some mechanism. It was difficult to measure the jitter itself in the 40m case.

Things generally progressed yesterday up until the evening when they started un-progressing a bit.

We got the feedback to the slow channel on and working.  It uses the DAQ and has a filter with zero at 10hz and a pole at 10mHz.  We were able to see that with the cavity locked, the piezo signal was kept around 0v for longer timescale changes.

The second beam is now going through the AOM and we have maximised the power in the first order on the way through the first time, then added an aperture to pick off only the first order before reflecting the beam back through the AOM along the same line.  At the output of this we again pickoff the first order beam and use the power meter to maximise the power by changing the position of the mirror behind the AOM.  We are getting an efficiency of approx 56% from the AOM at the moment.

We then got this beam into the cavity and got it aligned well enough to see fringes and something that looked like a 00 mode flashing.  Not well aligned, but nearly there.  At this point we connected a voltage source to the modulation input on the VCO for the AOM to scan up through the cavity in the CW direction.  We will need to collect the other PDH box from the 40m.

At this point we went back to the CCW loop to lock it - the beam had somehow got misaligned.  We spent the rest of the day trying to get the beam back into alignment with the cavity without really succeeding.  We are pretty certain that none of the cavity mirrors got moved so it should still be aligned.  We only worked on steering the beam into the cavity.  We did see 00mode resonances but it doesn't want to lock on these.  We maximised the power in transmission, and were careful to check the alignment of the beam on all the PDs but to no avail.  We will look at this again today.

I want to lock with the NPRO laser PZT (as done at the 40m) - and thus want the transfer functions of the NPRO PZT to phase / amplitude modulation (measured by Mott @ the 40)

• First plot attached is PZ T to AM response

I will use the 143.8kHz dip in the AM spectrum for locking (as sidebands), then later look at the PZT error signal to find the phase transfer function. I am interested in maximizing the ratio of PM/AM. For the loop:

• I will put in a second order passive component low pass to filter out the 2f (at 10 kHz)
• This is quick and should allow me to take my phase transfer function and tweak the setup if needed (and consider going to that 320ish kHz dip in the AM spectrum)
• I may be able to live with a 1 kHz UGF, as I used a 600 - 800 Hz UGF when I ran with the old frontend

I have a question which I either don't know or can't remember the answer to:

• Is there very little spatial distortion induced on the beam at these frequencies by using funny PZT resonances to lock, or do they exist and  we just don't care because they are out of band (presuming they aren't downconverted somehow)

Right - I am questioning the scalability and sense of this scheme, and inquiring if this is aesthetic.... i.e. is there a reason it cannot be C2SYS for all of bridge, (possibly front end naming limitations)?

I took some pictures of the H1(Innolight Mephisto) NPRO's scatter, and one of the neighboring lightwave NPRO for comparison

• Iris is about 6" in front of Meph NPRO

 Nope.  Each lab has its own number.  I think PSL is C3, TCS is C4, ATF gets C2....Frank has the full listing of these things.  Or at least that's the latest I heard a few months ago after several elogs back and forth.

We are continuing the naming scheme with CX? I thought we were planning on making C2 the whole subbasement...

Like

C2ATF

C2PSL

C2TCS...

I killed and restarted the daqd process because I wanted to add some 16Hz TCS channels to the frame builder. These are from the Athena DAQ box.

I edited the following files:

• on fb1: /cvs/cds/caltech/chans/daq/C4TCS.ini    -the .ini file telling the frame builder what channels to record
• on tcs_daq: /target/TCS_westbridge.db  - added the names for the ADC inputs and DAC outputs for the Athena box

I fixed two machines in the TCS lab to have static IP addresses on the local network.

The Athena DAQ CentOS box: 'tcs_daq' 10.0.1.34

The CentOS workstation: 'tcs_ws' 10.0.1.25

Frank, please add these to the network topology diagram you have ...