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.
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?
fb1 appears to have crashed or been restarted. ws1 and ws2 are nonresponsive (as a result?).
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.
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 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
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:
(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.
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.
MZ Sum and Difference spectra as acquired by the DAQ: Calibrations on plot.
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:
WHICH OF THESE THREE IS THE RIGHT ONE TO BE RUNNING? It would be wonderful to get this documented.
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$.
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
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
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.
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).
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?
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.
New calibration - 10.4 and 15.2 Vpp for green and IR, respectively.
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.
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.
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.
I used the GUI to add 6 channels. I logged into fb0 and did "sudo pkill daqd"
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.
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?
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.
Someone burned it.
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)?
Today, I turned the input and output mirrors round 90 degrees to take a displacement noise spectrum on our table. There were several steps:
I routed the outputs of the PDs to the DAQ, and acquired:
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:
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.
I had to acquire a couple of new channels to do the displacement noise measurement today. I added:
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.
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.
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.
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.
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.
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.
Big things not done:
Would like to do
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
That is all.
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.
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.
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
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":
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.
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....
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
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?
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.
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.
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.
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.
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.
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.