[Alastair, Zach]

We have completely dismantled the iGYRO. All optical components have been put in the cabinet closest to our table (on the west side), and all cables and electronics have been sorted and put away for easy retrieval. The only exceptions to this are some cables that are strung across the table (above) that we are sure to need later anyway. We also wiped the top of the table down with acetone to remove some dirty/sticky spots and outdated marks, as well as reinstalled the cable trays that used to be on the door to the PSL lab and put the cables back in an organized way. See pictures below. 

We will likely begin the reinstallation tomorrow.

A couple of comments:

When we've got the optics off the bench we should route the new BNC cables and install all the patch bays.  It's better to work above the bench when the optics aren't there.

2) As you say, one of the input mirrors cannot be housed in the original box.  We will need to box this mirror in separately.  Probably it is just a small box that we will add on to the side of the existing one.  We can put something simple together ourselves to begin with.

8)  We had already decided that it is unnecessary to do cylindrical mode matching.  Back last summer Jenna worked on this for a while and the difference in contrast defect is very small.

One of the main priorities will be to get a beam locked in the new cavity with the vacuum pumped down.  As we were discussing the other day, the alignment may shift when we pump and this is something that we're going to want to know about as soon as possible.  Since we don't have our own pump, we won't easily be able to keep going up to air and back down.

The computer system has to be a reasonably high priority I think.  It needs to be working stably and may take some time to fix.

The moment that we have got the parts roughly laid out on the table we should look to see if there is any machining work that needs done.  We should check if there are any critical optics (injection and output) where we would benefit from having stiffer mounts.  As we know from experience any parts that need made will have a lead time associated with them.

I like the idea of keeping all our electronics in the NIM crate.  We should think what other stuff we're going to need.  I would suggest we'll need a differential to single ended board, the new servo boards (which should include switching for the boost stages so we can control them from the computer), notch filters for the PZT input on the laser (we have one active twin T at the moment on a prototyping board).  Anything else we're likely to need?  We were floating the idea of making up a generic filter/amplifier board that we can later stuff for any job needed.  I think I have a lot of the Altium parts for this already.

Lastly I would suggest we should think whether there are any new parts we'd like ordered - again this is just because of the lead time.

 Here is a rough plan for how I imagine the gyro upgrade should work. Anyone is invited to change things as they see fit.

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
   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
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.
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). These need to be sorted out!!

 Before I forgot, I undid the recent change I made to R14 of PDH box #1437. To refresh your memory, I changed this resistor from 25 ohms to 330 ohms to reduce the input stage gain of the box by about a factor of 10 (so that I could increase the optical gain). Unfortunately, this resulted in an exacerbation of the gain-dependent DC offset we noticed some time before. In any case, I am beginning to design our own proprietary gyro PDH boxes, so we will soon leave these aside for general purposes.

I couldn't find a 25-ohm resistor (or 2 50-ohm ones), so I used a 27-ohm one. I will update the schematic on the wiki.

 Zach and I went down to the machine shop today.  They've drilled all the flanges and hopefully they will get them tapped tomorrow.  We are to go back tomorrow afternoon to see how they're getting on.

 I've added pads for the 1mm Perkin-Elmer photodiode.  I've just done this manually rather than adding a new part footprint.  The PD mounting point now looks like this screenshot.

For info I've attached the pdf for the Perkin-Elmer photodiodes from their website and also another pdf that I found that shows the footprints.

 Okay, so most of these violations seem trivial. I've gone into the rule manager and set it up to use the same rules as Rich had on the other RFPD board and all the trivial violations have now gone.  I've fixed all of them except one, which is a maximum hole size.  We are using 195mil for the holes for the stand-offs.  I'll need to check if there is a reason for that  being there (ie is there some limit from the manufacturer) before I remove the rule or change the hole size.

 There are quite a few rule violations that I've just noticed when running the design rule checker.  They're mostly clearance issues between the silk screen layer and various pads, but I want to get rid of them all at this stage.

The PD design is on the svn under gyro_electronics.

 Here is the latest schematic for the PDs along with the board layout.  I'm going to check over the routing one last time but it will probably require checking by someone with more RF experience too.  The pcb drawing doesn't show all the features in the pdf.  It uses split internal planes to distribute the power for the diode bias and also the +/-5v for the opamp.  I've kept a full ground plane as the first one down, so there is a continuous ground plane directly underneath the tracks on the surface.

Done.

simply press OK a couple of times. The warning means "check the DI cartridge". The chiller does not measure the resistivity of the water so an internal timer reminds the user every 1000h or so to "check" the water quality. The user can't disable this feature so we have to press the button once a month or so. We don't care how high the resistivity is.

The water chiller at ATF is crying with error "Di (or D1)". What should we do? ==> Frank

The water level seems to be higher than the minimum.

It also shows temp of 19.5Cdeg.

We are still waiting on the bottom flanges being machined.  I went to the physics machine shop this morning and they have only just got them on to a machine, which is a bit annoying since they've been there for quite a while now.  They should be ready in one week.  

I'm going to speak to Bob about getting them cleaned and baked.  I know that we're not aiming for some super-high-vacuum system but we probably also don't want machining fluid ending up on the optics when we pump this thing down.

I agree that this is a much better idea. How do we go about doing this?

from the Wikipedia article on Dispersion.

Do we need to add extra caps to both the input and output sides of the regulators, or just the output side?

RA: Both. There are multiple schools of thought on what gives the best performance, so its best to have both possibilities. The large electrolytic caps give good filtering of the low frequency stuff but also have a big inrush current when the supply is first activated. Even so, it would be good to have a pad available so that we can have a large-ish cap on the input and output with a 35V or higher rating. Its not necessary that it be surface mount - could also use tantalum. There's no need to make it larger than 100 uF.

I would be hesitant to use any second trend for making a noise budget. The trend generation stuff is not been vetted for low noise;

it may have any number of issues, like timing glitches, extra noise in the moving average, window bleeding, etc.

I feel like the path of least pain will be to just set up the mDV-nds2 system to grab data in chunks and downsample as necessary.

Also, we can ask JZ to implement server side decimation.

As I mentioned in my previous sad post, I took your advice and it seemed to work, but then it didn't (hooray!). I chose door #3, namely to revert the first transformer to pull from the half-tap point and then add a resistor of R ~ 75 Ohms to ground at the input of the circuit in order to make the total impedance 50 Ohms. I was not exactly sure of the impedance I measured when using the half-tap point before (I quoted 150 Ohms, but this was a rough memory), so I decided to empirically optimize the coupling by varying the resistance.

Since Frank was using the impedance test kit and I couldn't find him, I decided to do this by measuring the signal reflected from the circuit: I put a directional coupler between the RF source and then took the transfer function from "IN" to "CPL OUT", with "OUT" connected to the circuit and "CPL IN" terminated (50 Ohms). Between "OUT" and the circuit itself I had a T-connector with the third port containing the resistor under test using a BNC-to-clip adaptor. To my surprise, I found that the attenuation was maximum with R = 39 Ohms, which doesn't make sense since the maximum overall impedance of this configuration is 39 Ohms (i.e. R should have been something greater than 50 Ohms). Below is a plot of the frequency response with and without the resistor to ground at the input.

I found that the frequency of the notch was pretty sensitive ( O(+/- 1 MHz) ) to the resistor value and the amplitude was extremely sensitive ( O(+/- 30 dB) ) to not only the resistor value but also the way in which I clipped the resistor or how I had it resting in 3D space when taking the measurement. I am certain this has to do with some spooky RF rule where you can't use a metal film resistor or you can't use clips or you can't wear green underwear while working with resonant circuits or some mumbo jumbo.

By far the worst thing that happened is that even though I got the above beautiful result when half-assedly clipping the resistor in, when I actually soldered it into the Pomona box it did something ENTIRELY different. Unfortunately, I don't have a plot for this and I won't complain if I never see one again.

As I said in the last post, I will try to do the matching using option #1 when I get back (i.e. using a third transformer to match to the true impedance of the LC tank instead of adding parallel resistances to do the job). We'll see how it goes. 

 Earlier this week I planned to do the following things before I went home:

1. Finish with EOM resonant circuit and install
2. Reduce primary PDH box gain in order to increase optical gain without instability
3. Re-optimize primary loop in light of (1) and (2), take new OLTFs
4. Finalize low-frequency noise-budget generation using second trend and stitching, observe improvement in noise from the above modifications
5. Work with Alastair to finalize the RFPD board design

With the exception of (5), for which Alastair deserves the bulk of the credit, all attempts to get the above done have blown up in my face. What's worse, I have finally contracted the cold that has been lingering about. It feels irresponsible to leave for vacation without having gotten anything I wanted done, but I just physically don't have it in me. The gyro is currently in an unlockable state and so I have left everything shut off until my return. Below is a quick recap of what happened, with the numbers corresponding to the individual goals above.

1. I followed Koji and Kiwamu's advice and put a resistor to ground at the input side of the circuit to better match the impedance. I was not 100% sure of the exact impedance value I had gotten using the second 1:16 transformer at the half-tap point, so I empirically switched resistors in until I got the greatest reduction in reflected power (see post to follow). Confusingly, I found that a 39-Ohm resistor did the best job, which doesn't make any sense since this configuration can have a maximum impedance of 39 Ohms, barring any series resistance I don't know about. Even more befuddling is that while the resistor did the trick when put in parallel externally via T-connector, upon its being soldered in the circuit had a broadly qualitatively different response. What gives?
   • Bright side/solution: When I come back, I will choose option 1 instead, which is to just use an extra transformer to match the true impedance of the LC tank to 50 Ohms. This should circumvent all the nasty problems associated with putting an extra resistor in. 
2. I decided to reduce the gain by roughly an order of magnitude. The variable gain stage gives 5.0 dB per turn, so this increase corresponds to about 4 extra turns, or half the range. I accomplished this by increasing the value of R14 (the resistor to ground on the inverting amplifier of the input stage) from 25 Ohms to 330 Ohms. The feedback resistor is 1 kOhm, so the gain was reduced from 41 to 4. This seemed to work at first, as I was able to turn the gain knob up to just under 5.0 before the thing became unstable, however, I noticed that this modification brought back to life our favorite gain-setting-dependent DC offset. When turning the gain down to 0.0 to best capitalize on the optical gain, the DC level was sitting so far above zero that the AC signal could not go negative.
   • Bright side/solution: These circuits have been bent beyond their job description. We have modified them to the point that we don't know what the hell is going on. We have been talking about making our own dedicated servos, and now is the time that we should think about starting. Alastair and I are now reasonably comfortable with Altium, and the topology of the filter is straightforward enough that we should be able to build our own without too much hassle. We should build in cool things like multiple-stage switchable boosts for low frequency, preferably switchable remotely via relay. These boxes can live in our NIM crate and we can finally have everything controllable from the computer.
3. Clearly there was nothing to re-optimize, and therefore no reason to take new OLTFs.
   • Bright side/solution: We now have most of the vacuum equipment, and with any luck we will have RFPDs ready to roll by the time we get everything set back up again. We will need to re-characterize both loops again once this is done, so there's not a whole lot lost on this one.
4. CDS is in shambles. Trends and full frames are owned by different users, we can't pull data via NDS regardless of which user runs the daemon, and it appears that the only way to get inittab to run daqd and nds is with root. Also, it appears that the installations of the various tools (DataViewer, DTT, MEDM, etc.) are incomplete on different machines in a decidedly random way. For example, DataViewer doesn't run on ws2, nor does Foton, but MEDM runs on ws2 and not on fb1. Also, all the aliases are totally screwed up.
   • Bright side/solution: There really isn't a bright side here. We have fixed the previous issues regarding an incorrect default gateway on fb0 preventing NDS requests from outside, and Alastair has replaced a corrupt hard disk, but everything else is truly, truly a mess. I don't know nearly enough about hardly any of this stuff to feel confident about fixing it on my own, though I am glad to help in any way if someone has ideas!!!
5. This is the triumph of the week. Alastair has worked hard at figuring out how to get Altium to do things that are often uncannily close to what we actually want. We have taken the suggestions and comments on the initial design posted yesterday, and we just need to work on the physical layout of the PCB.

Merry Christmas!

The 4107 replacement that Rich suggests using is the LMH6624MA.  It's pin for pin compatible with the 4107, which is why I hadn't changed the part on the board - I'll do that now though just to avoid confusion.

The AP1053 is a teledyne-cougar RF amp.  Highlights are:

• Gain doesn't roll off till above 1GHz
• 50 ohm input and output
• Power output of 26dBm.  
• This is the 10dB gain model, but it is pin for pin compatible with a whole load of others in the range so we can swap in whatever gain we want.
• Rich tells us the input will be internally AC coupled, so we don't need to do this on the board.  Looking at the website and the datasheet this isn't explicitly mentioned though.

I talked with Kiwamu the EOM master.

- The coil craft's indication like "1:16" means the turn ratio n=4.

- You saw 400Ohm with a single 1:16. This means the resonant impedance of 400*16=6.4KOhm.

- When you connected the second 1:16 transformer, the resonant impedance is 23*16^2= 5.9KOhm. This is reasonable if you consider the loss in the transformers.

- When you connected the second 1:16 with the half-tap point of it,  the turn ratio n=2 was added. This means that the transformer worked as 1:4 rather than 1:8
  although we were not sure why the resonant impedance was higher (150*16*4 =9.6KOhm) the other cases.

- Solution1: Ideally what you need is an additional 1:8. That is realized by 1:2 and 1:4 cascaded. This case the total turn ratio is n=Sqrt(2*4*16)~11. That is your gain. We are not yet sure about the loss by the triple cascade of the transformers.

- Solution2: Put the terminator at the primary side while leaving the first 1:16. As your EOM had 400Ohm with the 1:16, the input impedance will be converted to 44Ohm which is not so bad. The gain will be 4 (=n).
  (By the way this is equivalent to put a 800Ohm resister in parallel to the EOM)

- Solution3: Put the 75Ohm resister at the primary side while using the half tap point of the additiional 1:16. As your EOM had 150Ohm with this condition, the input impedance will be 50Ohm. The gain will be 8.
  (This is equivalent to put a 4.8kOhm resister in parallel to the EOM)

 I finally asked Frank if I could just borrow the impedance test kit to measure the EOM resonant circuit impedance, as I have been having problems with the voltage transfer function method. I took the measurement and found that the peak impedance was 400 Ω (see first figure below). Pleased by the round number, I figured I could just add another transformer at the input to divide this down to 50 Ω.

The results weren't as nice as I'd like. First, I forgot that while the voltage ratio is in proportion to the turn ratio, the impedance ratio is in proportion to the turn ratio squared. So, for lack of a 1:8 RF transformer in the kit, I took another 1:16 transformer and only bridged across half of the secondary coil, so as to presumably get a turn ratio of 1:8 (though admittedly I wasn't sure about this). This resulted in a surprising peak impedance of around 150 Ω, though I do not have data for this

Knowing that I needed a larger ratio, I decided to just connect across the full secondary coil (so that I now had two cascaded 1:16 transformers). The resulting peak impedance is now 23 Ω (see second figure---note also that I have adjusted the tunable inductors to make the resonant frequency 33 MHz, instead of the 37 MHz it was in the first plot).

Clearly, I need something in between, but I am not sure how to do this without a THIRD transformer, which seems gratuitous. Perhaps I can measure the reflected power and decide if we can deal with it?

1. Add pads around all the voltage regulators for diodes to prevent transient spikes (e.g. preventing the 7815 output from spiking higher than its input).
2. Add pads to allow more capacitors around the voltage regulators; the large caps ought to be bypasses by little ceramic caps.
3. May want to add an L between the +15V and the power supply pin on the RF amp. This is sometimes done for RF amps to keep the RF out of the supply for the other guys who need +15V.
4. The 4107 can develop DC offsets. Should AC couple the output going in to the RF amp.
5. Add a series L-C in parallel with the R8. Sometimes we like to put a notch in the feedback of the 4107 to get extra notch action.
6. Put a note on the schematic (almost obvious) that all resistors must be metal film. If any resistors require more than a 1/8W power rating, it should be indicated on the schematic.
7. Since the 4107 is nearly obsolete, you ought to also scope out another amp and list it in the schematic notes as a good replacement choice.
8. Put a note on there about what the hell a AP1053 is.

Otherwise, looks pretty good to me. Make sure to calculate the input-referred noise of the AD620 with the gain setting that's there to make sure you're happy with the circuit's RIN sensitivity.

You mean we don't want two +/- connectors run from two separate supplies?  I only put them on there because we are planning on running it from the NIM crate.  You're right though that we should make it just one +/- supply because it is meant to be a general design.  I'll alter it so the 5v regulators are powered from the 15v ones.  Thanks.

I do have a question for someone about how we make up the board.  At the moment we're modifying the aLIGO design, and it has all the power planes inside the board.  My question is this - do we want to add in two extra planes to take the +/-15v to the other opamps?  The number of layers is starting to look like a lot.

you don't wanna have 4 power supplies to power the detector, way too complicated. I would change it to power the entire thing by +/-24V and regulate that to +/-15V. Then use the already regulated +/-15V to regulate it down to something else in addition.

I tried commenting out both daqd and nds from inittab, and then running them manually as controls and chown'ing all the data files in /frames.  It still won't let me get the full data in dataviewer.

I can also take a realtime fft in DTT, but can't get data from the past.

Separate issue is that Dataviewer on WS2 doesn't work.  Realtime and playback both result in the error :

--> Broken or incomplete installation - read the FAQ!

_____________________________________________________________________________________________________-

Running dataviewer on fb1 will give data for realtime, or from the frames for minute trend and second trend data but not full data.  In the frames folder, the second trend files were owned by root, and the minute trend were owned by controls. The full data files were owned by root also.  The daqd process was being run by root, hence the reason the full data was owned by root.

I manually edited inittab to comment out daqd, then I pkill'ed the process.  I then went to the /frames and chown'ed the directory recursively.  Then I tried running the daqd process as controls by going to the folder /cvs/cds/caltech/target/fb/ and running ./start_daqd.inittab  .  I then checked that the process was runing as controls (it was) and that the new data in /frames was owned by controls (it was also).

I then went back to dataviewer on fb1 again to see if I could pull full data from the frames - I couldn't.

I haven't yet been able to work out how to get inittab to run daqd as controls.  The problems pulling full data from the frames may be something else, I don't know.  It basically just hangs and the terminal window shows:

Connecting to NDS Server fb0 (TCP port 8088)
Connecting.... done
T0=10-12-16-03-08-51; Length=60 (s)
10-12-16-03-08-29

One other thing I notice is that nds is running as root, while on fb1 it is running as controls.

Here is our layout for the RFPD in Altium. We are working on routing the board now.

added an hourly cron-job on fb1 which runs the wiper perl-script to delete old frame files.
Script is the wiper.pl in /target/fb1 directory.

Here the latest status:

Wed Dec 15 01:15:18 PST 2010

Directory disk usage:
/frames/trend/minute_raw 4850240k
/frames/trend/second 115772408k
/frames/full 52519332k
Combined 173141980k or 169083m or 165Gb

/frames size 241263968k at 71.76%
/frames is below keep value of 98.00%
Will not delete any files
df reported usage 71.84%

i fixed the problems on fb1. The system is working now and taking data again. The following things have been changed:

1. changed group id for user controls from 121 (oldcon) to 1001 (controls)
2. changed owner for /frames directory to be 1001:1001 (controls:controls) (formerly 1001:121)
3. changed owner for files changed after Nov8 to 1001:1001

i also deleted parts of the old full data on fb1 as the disk was almost full.

We started having a look at the prolems with the frame builder in the ATF today.  As Zach had said, the previous attempts ended at the point where FB0 was rebooted and one of the drives kept coming up with some problem.  The main issue before the reboot was that daqd kept restarting.  It seems that the two problems are unrelated.

1) The first issue, with the hard drive has been solved.  The drive that was causing the problem was sdc1.  The machine FB0 has four drives installed, one of which was labelled "full" and a second one "trend".  We removed these two drives, backed up the fstab file and removed them from the listing in fstab.  The computer was able to boot with no problems.  We identified sdc1 as being "full", mounted in position 3 in the computer casing.  I got a temporary replacement that is 1TB from Larry and have installed that in it's place.  After checking the device name in the /dev directory (didn't want to format the wrong one...) I formatted it using fdisk /dev/sdc and created the filesystem using mkfs.ext3 /sdc1

I then went back and copied the old version of fstab back to it's original place and put the fourth drive, sdd back in place.  The machine was rebooted and I checked that the new drive was mounting correctly as /frames/full.  I noticed that the ownership of /full was not the same as /trend (the new drive was owned by root) so I used chown controls:controls /frames/full to make controls the owner.  Inside /full there is a directory /lost+found that I also chown'ed to be controls.  Everything seems happy with this now.

I've ordered a new 1.5TB drive and a second one to keep as a backup.  They were only $59.99 from Tiger Direct - Bargain!!!

2a) The issue with daqd restarting may be a bit more involved.  The first thing that was noticed was that fb1 exhibits the same problem of daqd restarting.  Since fb0 was out of commission at this point, we checked on fb1 to see when the last data in /frames/full was written.  The date was Nov 13th.  Also the user name changes on the 8th, corresponding to this elog posting that Rana put up.  He had been trying to change over all the machines to having the same group user id.  It seems that fb1 however is still on controls oldcon as the user and group.  At some point when the front-end was restarted it no longer had write permission.

b) However having checked out fb0 it appears that this is controls controls, and that it should not have the same problems.  I looked in /frames/trend/second and there is data in there since the Nov 13th date.  However the owner of the data is root which I'm guessing is bad.  I wonder whether the permissions on the /frames/full folder may have been set such that it was unable to write to this folder, or perhaps it was just that the old drive was failing.  It seems that the easiest way to check is to start the frontend again and see if it will record full data.

I ran startatf, then opened the frond end medm panel and set the Burt restore entry to 1.  The front-end came back up just fine, and the gyro MEDM screens are working.  I kept checking back on the processes running until daqd started, with a time of 16:52.  I then went into the /frames/full folder on the new disk and checked for new data.  There was a new data folder which, just like the trend data, is owned by root.  I'm going to leave it for ten minutes to see if any data is recorded that I can access.  I'll come back and update this elog entry........

.....23:35 and daqd is still up and running on fb0 since this afternoon.  So replacing the hard drive seems to have fixed that problem.  Need to look at dataviewer again tomorrow because I can't seem to pull any data on dataviewer without it coming up with errors.

I am referring to the CCW loop gain---the transmission beat occurs after the light has interacted with the IO, so in principle the IO noise should be suppressed by the loop gain as measured there vs. as measured in the AOM actuation signal.

If this turns out to be true, we will build a box and/or extend the vacuum system to include the transmission setup. If it is false, we will have to enclose the IO and the transmission, or eschew the transmission readout for the AOM readout if it wins out noise-wise.

Alastair and I hammered out much of the RFPD board last Friday. It should be done this morning.

I can't imagine any noise source that would be suppressed by the transmission PLL loop gain. In principle, we could

just use a frequency counter there instead of a loop and get the same information.

Since our incoming vacuum system doesn't suppress any noise in the IO or transmission, you might as well build a sealed

plastic box to encase the transmission to see if there's any effect. Of course, even better would be to

    FINISH THE RFPD ELECTRONICS DESIGN

 I reconfigured the transmission demod and PLL setup today, so that I could compare the gyro noise as measured in the two signal candidates (AOM feedback and PLL feedback). As detailed in the previous post, the DAQ has taken a big stinky poop and will require Alex's wizardry to reemerge from utter chaos. To do today's analysis, I hooked up an SR560 with one pole at 0.1 Hz to use as the slow feedback filter. I used the Pomona-encased voltage divider to get the gain low enough. The gyro seemed to stay locked indefinitely.

To get better low-frequency data, I took spectra down to a 25-Hz span. This doesn't get us that much more information than with 100 Hz given the smooth shape of the spectrum at low frequency, but anything helps. We will be able to get lower-frequency data once CDS is back up.

Below are three traces, all calibrated to angular velocity noise:

1. Feedback to the AOM VCO
2. Feedback to the transmission PLL VCO
3. Feedback to the transmission PLL VCO, but with foil covering the transmission setup

The third trace---which was inspired by Koji and Frank's elegant work last week---I took because I noticed that the low-frequency part of (1) and (2) looked qualitatively the same. Since we hypothesize that noise in the input optics (e.g. from air) will appear in (1) but not in (2), I suspected that covering the transmission optics in foil to reduce air noise would bring the low-frequency junk down, perhaps to or near the level seen by Koji and Frank when they covered the input optics. The foil "enclosure" is seen in the second picture.

As can be seen in the plot, (2) and (3)---which are all but identical---are noisier in broadband than (1), save for some resonances which suggest that the calibration is about right (the calibration for each is simply the appropriate VCO gain in Hz/V times the common gyro factor lambda*S/4A). What I think is that there is some non-ideality in the transmission setup that is contributing some excess noise somehow. I am not yet ready to abandon the conviction that IO noise should be suppressed by the loop gain in the PLL signal, as the data do not show that definitively.

. . . _ _ _ . . .

 I'm sorry to pass the buck, but this DAQ issue is above my linux pay grade. It seems that we have embarked on an infinite loop: today, I restarted the ATF model to see if the problem would go away, and now the hFE diagnostic reports NO SYNC again, as it did last time Frank and I were looking at this. daqd also still appears to be restarting every minute or two. At this point last time, we rebooted fb0, and when it came back up it forced a many-hours-long disk check. I have literally almost no intuition for what is going on, and I am humbly asking for help.

One extra clue is that when the system first breaks (i.e. when daqd begins to restart all the time while everything else appears to be running normally), a bit named "DAC0 OUT OFC" towards the right of the diagnostic screen goes RED. It now appears GREEN, though everything else is in shambles.

. . . _ _ _ . . .

We need some bias to the PZT out.

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

 It does seem to have the same symptoms as before.  When I looked at FB0 it was running daqd with a startup time of 11:25.  I looked again just now and the startup time is listed as 11:35, so it seems it is just re-starting all the time.  The weird thing is that it does appear to be running the whole time.  I've not found one instance where I've checked it and found it to not be running.  The daqd log is not so enlightening for me, but it does list a whole pile of errors - I just don't know what it's normal operation log would look like.  Some of them look quite serious to me, like " test point manager on FB may be down".  Log file reproduced below:

startup file interpreter thread tid=1084229952
calling yyparse(3, 4)
[Fri Dec 10 11:40:02 2010] ->3: set allow_tpman_connect_fail
[Fri Dec 10 11:40:02 2010] ->3: set avoid_reconnect
[Fri Dec 10 11:40:02 2010] ->3: #set cit_40m=1
[Fri Dec 10 11:40:02 2010] ->3: set dcu_rate 10=32768
[Fri Dec 10 11:40:02 2010] ->3: set dcu_rate 11=2048
[Fri Dec 10 11:40:02 2010] ->3: set controller_dcu=10
[Fri Dec 10 11:40:02 2010] ->3: set dcu_status_check=1
[Fri Dec 10 11:40:02 2010] ->3: set debug=0
[Fri Dec 10 11:40:02 2010] ->3: set zero_bad_data=0
[Fri Dec 10 11:40:02 2010] ->3: set master_config="/cvs/cds/caltech/target/fb/master"
[Fri Dec 10 11:40:02 2010] finished configuring data channels
[Fri Dec 10 11:40:02 2010] ->3: configure channels begin end
[Fri Dec 10 11:40:02 2010] ->3: set gds_server = "fb" "fb" 0 0
Fri Dec 10 11:40:04 2010 [16362]:Failed to connect to the test point manager node 1
Fri Dec 10 11:40:04 2010 [16362]:Test point manager on fb may be down
Fri Dec 10 11:40:04 2010 [16362]:tpRequest() returned -4
[Fri Dec 10 11:40:04 2010] ->3: set gps_leaps = 820108813
[Fri Dec 10 11:40:04 2010] ->3: set detector_name="CIT"
[Fri Dec 10 11:40:04 2010] ->3: set detector_prefix="C2"
[Fri Dec 10 11:40:04 2010] ->3: set detector_longitude=-90.7742403889
[Fri Dec 10 11:40:04 2010] ->3: set detector_latitude=30.5628943337
[Fri Dec 10 11:40:04 2010] ->3: set detector_elevation=.0
[Fri Dec 10 11:40:04 2010] ->3: set detector_azimuths=1.1,4.7123889804
[Fri Dec 10 11:40:04 2010] ->3: set detector_altitudes=1.0,2.0
[Fri Dec 10 11:40:04 2010] ->3: set detector_midpoints=2000.0, 2000.0
[Fri Dec 10 11:40:04 2010] ->3: #enable frame_wiper
[Fri Dec 10 11:40:04 2010] ->3: set num_dirs = 200
[Fri Dec 10 11:40:04 2010] ->3: set frames_per_dir=225
[Fri Dec 10 11:40:04 2010] ->3: set full_frames_per_file=1
[Fri Dec 10 11:40:04 2010] ->3: set full_frames_blocks_per_frame=32
[Fri Dec 10 11:40:04 2010] ->3: set frame_dir="/frames/full", "C-R-", ".gwf"
[Fri Dec 10 11:40:04 2010] ->3: #scan frames
[Fri Dec 10 11:40:04 2010] Frame file wiper cannot be enabled when gps_time_dirs==1
Write external script to clean up old frame files

[Fri Dec 10 11:40:04 2010] trend frame wiper enabled
[Fri Dec 10 11:40:04 2010] ->3: enable trend_frame_wiper
[Fri Dec 10 11:40:04 2010] ->3: set trend_num_dirs=60
[Fri Dec 10 11:40:04 2010] ->3: set trend_frames_per_dir=1440
[Fri Dec 10 11:40:04 2010] ->3: set trend_frame_dir= "/frames/trend/second", "C-T-", ".gwf"
[Fri Dec 10 11:40:04 2010] ->3: set raw-minute-trend-dir="/frames/trend/minute_raw"
[Fri Dec 10 11:40:04 2010] ->3: set nds-jobs-dir="/cvs/cds/caltech/target/fb"
[Fri Dec 10 11:40:04 2010] Frame file wiper cannot be enabled when gps_time_dirs==1
Write external script to clean up old frame files

[Fri Dec 10 11:40:04 2010] minute trend frame wiper enabled
[Fri Dec 10 11:40:04 2010] ->3: enable minute-trend-frame-wiper
[Fri Dec 10 11:40:04 2010] ->3: set minute-trend-num-dirs=10
[Fri Dec 10 11:40:04 2010] ->3: set minute-trend-frames-per-dir=24
[Fri Dec 10 11:40:04 2010] ->3: set minute-trend-frame-dir="/frames/trend/minute", "C-M-", ".gwf"
[Fri Dec 10 11:40:04 2010] ->3: #scan minute-trend-frames
[Fri Dec 10 11:40:04 2010] ->3: #scan trend-frames
[Fri Dec 10 11:40:04 2010] ->3: #scan frames
[Fri Dec 10 11:40:04 2010] ->3: start main 30
Error ignored because "allow_tpman_connect_failure" is set in daqdrc file
Fri Dec 10 11:40:04 2010 [16362]:Allocated move buffer size 528014 bytes
[Fri Dec 10 11:40:04 2010] main started
[Fri Dec 10 11:40:04 2010] ->3: start profiler
[Fri Dec 10 11:40:04 2010] ->3: # comment out this block to stop saving data
[Fri Dec 10 11:40:04 2010] frame saver started
[Fri Dec 10 11:40:04 2010] ->3: start frame-saver
[Fri Dec 10 11:40:05 2010] ->3: sync frame-saver
[Fri Dec 10 11:40:05 2010] ->3: start trender
[Fri Dec 10 11:40:05 2010] trender started
[Fri Dec 10 11:40:05 2010] trend frame saver started
[Fri Dec 10 11:40:05 2010] ->3: start trend-frame-saver
[Fri Dec 10 11:40:06 2010] ->3: sync trend-frame-saver
[Fri Dec 10 11:40:06 2010] ->3: # dont' need these
[Fri Dec 10 11:40:06 2010] ->3: #start minute-trend-frame-saver
[Fri Dec 10 11:40:06 2010] ->3: #sync minute-trend-frame-saver
[Fri Dec 10 11:40:06 2010] raw minute trend frame saver started
[Fri Dec 10 11:40:06 2010] ->3: start raw-minute-trend-saver
[Fri Dec 10 11:40:06 2010] ->3: #start frame-writer "225.225.225.1" broadcast="131.215.113.0" all
[Fri Dec 10 11:40:06 2010] ->3: #sleep 5
[Fri Dec 10 11:40:06 2010] producer started
[Fri Dec 10 11:40:06 2010] ->3: start producer
[Fri Dec 10 11:40:06 2010] ->3: start epics dcu
[Fri Dec 10 11:40:06 2010] edcu started
[Fri Dec 10 11:40:06 2010] ->3: start epics server "C0:DAQ-FB0_" "C2:DAQ-FB0_"
[Fri Dec 10 11:40:06 2010] epics server started
[Fri Dec 10 11:40:06 2010] ->3: start listener 8087
[Fri Dec 10 11:40:06 2010] ->3: start listener 8088 1
[Fri Dec 10 11:40:06 2010] ->3: sleep 60
[Fri Dec 10 11:40:06 2010] EDCU has 175 channels configured; first=0

[Fri Dec 10 11:40:06 2010] Epics server started
[Fri Dec 10 11:40:06 2010] Opened /rtl_mem_atf_daq
cas warning: Configured TCP port was unavailable.
cas warning: Using dynamically assigned TCP port 49166,
cas warning: but now two or more servers share the same UDP port.
cas warning: Depending on your IP kernel this server may not be
cas warning: reachable with UDP unicast (a host's IP in EPICS_CA_ADDR_LIST)
[Fri Dec 10 11:40:06 2010] Opened /rtl_mem_psl_daq

[Fri Dec 10 11:40:07 2010] Waiting for DCU 10 to show Up
[Fri Dec 10 11:40:07 2010] Detected controller DCU 10

[Fri Dec 10 11:40:08 2010] Minute trender made GPS time correction; gps=976045221; gps%60=21

 The realtime stuff all seems to be working fine, it's just the frames that aren't getting written.  Running dataviewer on FB1 I can get realtime data for our channels.  If I try to get data from the past you get:

Connecting to NDS Server fb0 (TCP port 8088)
Connecting.... done
T0=10-12-10-19-19-05; Length=60 (s)
No data found

Also, the installation of dataviewer on WS2 doesn't seem to work - does anyone know about this?  Last thing I knew was that it wasn't installed at all on WS2.  It opens fine, but when you try to get data it comes up with "incomplete installation" in the terminal window.

I've updated sitemap so it now links to the correct two files for the gyro MEDM screens.

 The DAQ is doing the same thing it was doing a little over a week ago. Namely, it seems to reset itself or otherwise get flustered every minute or so, rendering any useful data requests futile. Let me remind everyone what happened last time:

1. Found the problem, tried to fix it using DAQ Reload, etc.
2. Thought that the DAQ Rate might have been the issue, so I opened daqconfig and removed some channels
3. Restarted daqd
4. daqd didn't seem to stay alive---problem
5. Got Frank
6. Frank observed the issue and saw that I wasn't just drooling on fb0
7. Rebooted fb0
8. fb0 complained about something on boot and forced a disk check
9. A day passed
10. Followed some instructions for removing the problem (mainly "yes, yes, yes, yes")
11. I mistakenly allowed it to reboot again without changing some manual settings that I needed to have
12. fb0 complained about something on boot and forced a disk check
13. A day passed
14. Frank did some magic in the recovery menu and then reboots fb0
15. Everything worked for a week and a half or so
16. Step 1

I'm not sure if Frank got an intuitive grasp on what was wrong last time, but it appears to be the same issue. I imagine that going through this list (perhaps with some omissions) will fix the problem again, but that will take a day or so and it may only last a few days after. Suggestions?

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

• G_CCW = 0.00
• G_CW = 3.80

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

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

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

I modified the circuit by replacing the inductor with a slightly smaller one (actually, we only had ones that were too small in the EE shop, so I soldered two of them together in series). I tuned the new inductors so that the resonance frequency was 33 MHz. Below is a plot.

Again, this plot has had the -34 dB of (measured) attenuation from the two in-line 20-ohm BNC attenuators that were used between the source and the resonant circuit subtracted out to reflect the true magnitude.

I took the same measurement using a (MiniCircuits) 50-ohm terminator in place of the circuit and EOM and verified that the result was 0 dB in broadband, as it should be given the measurement setup. What I don't understand is that---as is explained in the elog thread between Stephanie and Koji linked below---the magnitude should be given by 2Z/(50+ Z), where Z is the impedance of the device under testing. The impedance should be >> 50 ohm on resonance, so the magnitude of the peak should be something like 6 dB. I get 11.4 dB, which doesn't seem right unless there is a factor of two missing here somehow.

I want to be sure of the impedance before I hook everything up, so I have restored the experiment to the standard setup until I am.

 Following Koji's post on the wind noise affecting input optics, I've drawn up the bench area to scale to see how the main parts will fit once we have the vacuum system.  In the first drawing I've left the input optics where they are at the moment, and overlaid the vacuum system on top of the current blue box.

In the second version I've moved everything up the table to see if we can use the current blue box to house the input optics.  The answer seems to be that it will fit (just) and the blue box is very close to being the same area as the current input optics, albeit with everything rotated and a few things that will need to be moved around.  The only downside I can see to this is that we'll need to rearrange all the optics rather than building a new box around them.  Also, at least a few of the final mirrors will not fit inside the box, so we'd have to stick and extra small box on to cover the final turning mirrors before the beam goes into the input mirror.

I just removed the cables and hangers. The cables were rolled up as neatly as possible and put in the cabinet on the west side of the lab between the tables. The hangers are there too. The screws I put in an empty compartment in the carousel bins next to the doors.

[Koji, Zach, Alastair, Frank]

After our very hacky trials, we found the noise source in the low frequency band:
It is the air current on the input/output optics even though the mechanism is still unknown.

We need:

- to know why the air flow in the I/O optics causes the noise.
- to make firm wind shield for the input/output optics too.

First Zach, Alastair and Koji started the afternoon experiment.

1. The first attempt was to put the Al foil on the table in the box to prevent the air flow from the table holes.
We practically saw no improvement.
Frank later pointed that the holes of the table are individually sealed. Therefore it was reasonable not to see any improvement.

2. The second attempt was to introduce He gas into the box just in order to see any possible change in the noise spectrum.
We went to the biology stock room to get the tubing for the gas introduction. As soon as we introduced the gas into the box,
the optical path length started to show drastic change (doe to reflactive index of He?). At the same time we started to see vertical
misalignment. We no longer could lock the cavity on TEM00. It may be caused by the temperature change in the box as the
introduced He was indeed quite cold due to adiabatic expansion? We also observed our voices got strange as we expected.

The He cyrinder is still in the lab. We may prepare some reservoir to accumulate the gas and let it heat???

At this point Zach and Alastair left the lab.

3. The third attempt was to put the air baffles made by Al foils along the cavity path. It made no change in the noise.

4. I was checking the PDH box. I found that the phase setting of the VCO loop was at the edge (10.00). I added a short BNC in the PD path.
Now the phase for the maximum optical gain is 9.60. The phase was adjusted such that the servo starts oscillation with as lower gain as possible.

I was observing the VCO feedback (the current gyro signal). It has ~100mVpp 40MHz signal coupled. It turned out that this signal comes from the
DAQ. I put a 5MHz LPF between the PDH box out mon and the DAQ cable.

The signal is also sent to SR560 to filter out the high freq fluctuations which makes the observation quite tricky.

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

6. As the noise below 100Hz has non-stationary behavior I tried to find any sign of scatteriing / clipping. No luck.

Then I started the attept of putting Al foils to cover the input/output optics.
It indeed helped to reduce the noise between 0.1-20Hz! The improvement is factor of ~5 between 1~10Hz.
See the plot and the first photo. This was one of the hackiest work I ever had...

7. As I could not believe this improvement by myself, I told the story to Frank who was in the room at this time.
He got excited and proposed several ideas.

7a. First we removed the Al foils in order to confirm the effect is real. Yes it is real.

7b. The imptovement could have been given by settling the air flow or shadowing the ambient light.
Frank pointed out that our PD is sensitive to the visible wavelength. He brought the VIS light blocking
filters from PSL lab. The filters didn't help the noise level.
The noise from the ambient light was rejected at least for now.

7c. We partially put the Al foils on the table. The effect was not quite localized but relatively strong at the downstream side of the input optics.
There is the air conditioning working above those optics. We put the Al foils to block the A.C. air. It improved the noise level by factor of 2-3.
Anyway, we confirmed that the main cause is the air flow.

7d. Frank found the plexiglas plates at the edge of the room. We constructed the temporary wind shield by them. See the second photo.
It improved the noise level as shown in the plot, although the effect was not as good as the Al foil case.

8. We decided to finish the work of the day. We cleaned up our mess (expect for the foil on the table in the box).
The stray Al foils were disposed. The Al reel was returned to the suspension lab.

Gyro relocked GPS time at around 975910000. I leave the lab while it is kept locked.
Another elog entry is coming later.

 I built a simple resonant circuit for use with the EOM consisting of:

1. A 1:16 turn ratio RF transformer
2. A tunable inductor
3. That's it

The schematic of the full circuit including the EOM is:

The principle of operation is that the impedance Z of the LC circuit in parallel with the secondary transformer coil becomes very high on resonance. The transformer makes this impedance look like Z/(16²) to an input signal, and the circuit is optimized when this value is 50 Ω so that the impedance is matched and there is maximal power coupling. Meanwhile, the voltage is stepped up by a factor of 16, so the ultimate result is a gain on resonance. The transformer is useful in its own right in the case where the load impedance is not adjustable, in order to match this with the input impedance. In that case, one chooses the appropriate turn ratio to make Z/n² = 50 Ω (for RF applications). In our case, we make Z as high as possible, and in doing so we need to increase n, which in turn increases the voltage gain---pretty neat!

The measurement setup is the same as here. Below is the measured voltage transfer function, with the effect of the attenuators from the source to the circuit (to avoid power reflection, as detailed in the linked post) subtracted out.

It seems like either the inductor I am using is not quite what it says it is, or that the capacitance of the EOM is not the roughly 12 pF it is supposed to be. The latter is not very likely as I got roughly the same resonant frequency of ~26 MHz when simulating the EOM with a mica capacitor. In any case, I am going to replace the inductor with a slightly smaller one and try to adjust the frequency to 33 MHz.

I wanted to plot the LISO prediction for this circuit along with the measured transfer function, but I am running into trouble with getting the Q quite right. The resonant frequency and gain come out to about the same, but the shape was much broader. I realized that I had the coupling efficiency of the mutual inductance line set to unity (ideal), and when I changed this to 0.9 the Q magically increased, resulting in a very sharp spike. I am not sure if I am doing something wrong, but I will either figure it out or just use something to model it analytically.

The last whiteboard covering the door to the PSL lab will be installed Monday morning 8am. I will be supervising the guy who will install the stuff.
Someone has to remove the cable hangers and cables until Monday.

At Koji's suggestion, I have added the residual CCW noise (as measured from the error signal) to the NB plot:

This trace is generated in exactly the same way as the gyro noise trace: 32k data is downloaded and then pwelched.