I have more-or-less finished a rough first draft of the automatic gyro noise budget MATLAB code. The rough architecture is:
In addition to this, there are two functions named "pdh1437" and "pdh2215" which contain analytical expressions for the two respective filters. They take as arguments 1) a frequency vector and 2) the appropriate box's gain setting and return a vector of the transfer function sampled at these frequencies. These are used wherever a spectrum needs to be multiplied or divided by the PDH gain.
The file in (2) takes the OLTF in each direction and divides by the correctly sampled PDH gain and actuator gain to obtain the optical response in V/Hz. This is used to calibrate voltage spectra into (rad/s)/rHz.
(1) is separate so that we can choose whether to pull the gyro noise from the frames or upload our own (e.g. an analog measurement), and there will be a single file that runs everything in one fell swoop.
Below is a sample output. In this case, I have used our analog measurement of the gyro noise from last week as I am still working out the kinks in the NDS method (for some reason, they don't come out quite the same). Obviously, this is still somewhat barebones and we will need to add in more noise sources as they come to us. The good thing is that---at long last---we will be able to simply press a button every time we want an up-to-date noise budget. If we make a change to the setup, it is simply a matter of dropping the new data into the "data" directory and re-running.
Attached is a recent analysis of the "noise spillover" from the primary loop to the secondary (rotation sensing) loop. The plot shows the frequency noise as measured in 1) the primary error signal and 2) the secondary actuation signal. The idea here is that whatever noise is not removed by the primary loop (i.e. the error signal) should be attacked by the secondary loop. In the limit of an ideal secondary loop, the correctly calibrated signals should be exactly equal (that is, the rest of the noise is exactly cancelled by the secondary actuator).
The calibrations are:
It appears as though the gyro noise is in fact dominated by residual common-mode noise above about 30 Hz. Below this, some other source contributes more strongly. The noise here is roughly 300x higher than the expected fundamental gyro noise from displacement, so this suggests that some other non-ideal condition is at fault.
I had word that the router shipped today. Should be here Monday, or Tuesday at the latest.
I finally got through to someone at (**insert name of offending company here**) to ask about our router order for the ATF. It turns out that although it is now out of stock and discontinued they had not bothered to let us know. So not only is the router used at the 40m not available, but the next model up in the range has also been discontinued.
I have therefore ordered this one instead as it appears to be the last wired router that linksys offer. I guess we could have substituted a wireless one but I'm not sure that would have gained us anything.
The specification list on the linksys website is pretty vague:
IEEE 802.3, IEEE 802.3u, IEEE 802.1p
Four 10/100 RJ-45 Switched Ports
One 10/100 RJ-45 Port for Broadband Modem
1 year hardware limited warranty
Lifetime award-winning online support tools
I'm assuming it will allow all the port forwarding settings etc that we need.
made the following changes to optimize the quantity and quality of data taken:
people complained about not be able to access fb0 from outside the lab, but fb1 was working.
I turned out the the default gateway on fb0 was set to 10.0.0.1 instead of 10.0.1.1.
fixed that and now everything is fine...
IEEE 802.3, IEEE 802.3u, IEEE 802.1p
Four 10/100 RJ-45 Switched Ports
One 10/100 RJ-45 Port for Broadband Modem
1 year hardware limited warranty
Lifetime award-winning online support tools
Attached is a current gyro noise budget. It has not yet been fully automated, but Koji wanted to have something to look at this afternoon so I made this one by hand. One very nice thing to note here is that the current gyro sensitivity is clearly limited by the dark noise of the PDA255 REFL diodes above ~20 Hz, which we suspected but until now haven't substantiated.
A couple notes:
spent hours now to figure out why the camera image taken contains only black data when using my program and example programs but working fine with the camera manager utility and everything working fine on two other computers.No error occurs, nothing, just no data.
But now i got it !: the pixel-clock is too high for that computer and is higher by default than using the camera manager software which obviously must reduce the pixel-clock when getting started. After debugging the shit i started adding all options and playing with it, like frame rate etc - nothing helped. But reducing the pixel-clock from 25MHz to 10MHz and suddenly real data is available from the data . So probably the USB or the computer is too slow (it's USB2.0, the camera complains about being connected to something slower). That's my only explanation.
after having issues with a non-working frontend yesterday we rebooted fb0 (using a clean software shutdown and reboot) to bring it back up in a clean state without zombi processes or so.
While booting it was bitching about file system errors which the system couldn't fix on it's own automatically and requested mandatory manual repair.
So i started a manual fsck for sdc1 and Zach was answering all the questions "should we fix whatever is broken" with yes. It finished the check 5min ago and i rebooted the machine again.
Now everything is running, including frontend code and framebuilder.
Since the other computer stops working on a regular basis i finally installed and tested all software on the old IBM notebook we had in the lab. Installed Labview 2009 and the Vision package (30-day trial licenses) on that computer and tested everything. Seems to work fine so far. I went away from the compiled executables as i'm still changing little things from time to time which means that i have to make a new compilation every time. Now having the full development version installed i can modify the code on the exact same computer whenever i want.
I realised that I had not bought a vacuum gauge for the gyro system. The simplest solution seemed to be to use a wide-range gauge so we don't need to worry about damaging the gauge if the pressure creeps up too high. I've ordered a combination gauge from Kurt Lesker that gives atmosphere down to 1e-9 Torr with an analogue output so we can hook it up to a DAQ channel.
The NDS server has been inaccessible from the outside for some time. I checked the port forwarding settings and they look correct, so this might have something to do with the router. Alastair ordered it some time ago so perhaps it is in.
In trying to troubleshoot this issue, I noticed that---when accessing the data with DV from within the network---I couldn't look at data from more than a few minutes ago. While I was on the diagnostics MEDM screen, I noticed that the FB indicators flashed red every few minutes and then went back to normal. This is just about the right timescale to explain why only very recent data is viewable.
In trying to troubleshoot this issue, I unacquired some channels (in case the DAQ rate was too high, which I don't think it was) and tried restarting daqd in the usual way. Then all hell broke loose, and the process wouldn't stay running for more than about a minute, during which the indicator was red all for except a few brief green flashes (with errors).
I enlisted Frank's help. We tried restarting the front end and then the diagnostic indicated no sync signal. Finally, we decided to reboot fb0 to see if that helped. While booting, it found an error and forced a disk check, which is probably still running now.
I will try to get it running again in the morning, and then see if I can get the new router swapped in and get NDS visible.
I've not seen the new router in yet. I have emailed Gina to ask her to look into the status of this order. The techmart info says that it was ordered on 9th Nov, and it was in stock when I ordered it.
Here is the plan for our generic PD board. It is designed to be used in three different readout configurations:
1) Transimpedance amplifier
2) Resonant PD (using capacitance of the photodiode in resonant circuit)
3) Resonant notch readout.
IC4 is the main RF readout. The inputs have jumpers to allow it to be connected in either inverting or non-inverting configuration. The output of this goes either directly to the output of the box (for transimpedance readout) or can go to IC5 which will be an RF amplifier (probably from this company).
IC3 gives DC readout (except for transimpedance design) using a transimpedance setup to connect L1 to ground. At very high frequencies we bypass this using a capacitor to ground.
The diode is biased through a resistor giving a second DC readout option. IC1 reads out the voltage across this resistor differentially. Frank suggested using the setup with IC2 to keep the voltage at the photodiode constant (otherwise when the photocurrent changes, the voltage drop across the resistor will also change causing a change in diode bias).
It seems that the gyro noise level looks much better than that in entry 1150. Can you overlay the improvement of the gyro signal?
Note that your latest gyro signal is not valid above 1kHz considering you only have OLG of less than 10 above 1kHz.
(i.e. error in the noise level estimation is more than 10% above 1kHz unless you conpensate the effect of the control.)
- I wonder how I can obtain 0.67 (rad/s)/V from this formula... (In other word, I like to know the freq stability measured by the VCO.)
- How do we characterize / reduce the low frequency noise? Does going to vacuum really improve this noise? What is expected?
- Where is the VCO phase noise level now?
- We definitely need to have better PHD circuit. Probably we can use the box but should replace the board.
- We should start to look at the beat signal.
500 kHz/V (VCO gain) x (c * 3.15 m) / (4 * 0.62 m2) ~ 0.67 (rad/s)/V
Here is a plot of the CCW and CW loop OLTFs as measured on Wednesday afternoon. They both have a UGF around 12 kHz with a phase margin of 20 degrees for the CW loop and a lousy ~7 degrees for the CCW loop.
Here is the current noise plot as measured in the AOM feedback signal. The level is about the same as before. The calibration is
Now that I have current OLTF models I can continue with the list here.
Added another channel using a small transistor to turn the red laser on and off. Will keep the shutter open when taking pictures even the 1064nm light causes some strange pattern on the diode chip. Should be OK as we are only interested in changes of whatever initial pattern we get. Turning off the 1064nm light would require to close the shutter every time i take a picture. So far i'm planning on taking a picture after every pulse, which would mean 50k-100k of shutter cycles per pulse energy setting. That's way beyond the expected lifetime of the shutter.
I've also added a cylindrical lens to compensate for the large elliptical beam coming from the large angle at which i hit the surface if the diode. No i have a round spot illuminating the active area.
Will do some first measurements with the new setup over the holiday/weekend.
added the readout for the USB CMOS camera watching the scatter from the photodiode surface.
Right now i think i will take a picture after every single pulse even if the amount of data will be very high.
Pictures will be individually saved in a slightly compressed JPEG to not delete much of the valuable information about the changing surface.
If i don't safe them i can't really handle the amount of data (1.3MB per picture, usually 1000 pulses per cycle, so far about 50 cycles, so 65GB of data).
Each picture will also be a frame of a movie. So there will be a movie and hundreds/thousands of individual pictures per cycle.
The photodiode is illuminated by the extra red laser diode. Everything is working so far except that i have to add another switch to turn the red laser on/off before/after pulsing cycle (where i'm taking the pictures) to do all the other measurements.
Yesterday was fun...
I started from where I left off, trying to direct the AOM-passed beam to the cavity and get the TEM00 through, but then I noticed that the PBS for the AOM isolation setup was transmitting a fair amount of light, so I had to realign it to minimize this (the setup is that the S light from the CCW/CW separating PBS goes to a second PBS and then into the AOM, hits a QWP twice on the double-pass and then emerges as P and passes through the second PBS again and to the rest of the experiment).
I then had to completely realign the AOM again, which I did and got ~50% double-pass efficiency again, but then I noticed the same ~2 MHz oscillation in the primary REFL PD signal again when i was trying to lock the cavity and sweep the other direction. This time, however, it could not make it go away by increasing the power (using the HWP at the experiment input) as I could before. I thought perhaps it was the PD, so I switched it out for the other PDA255 we had for the CW REFL, but it saw the same effect. I turned off all the RF oscillators and connected the PD supplies to several different power strips to try and eliminate any ground loops (also, the PDs are on insulating posts).
I then noticed that adjusting the drive current and, sometimes, the temperature of the NPRO made the effect go away or at least stop for a short while. I disconnected the slow and fast actuation signals and meddled with it a bit by hand with the knob, but couldn't see anything obvious except that with a low enough drive current (~half the usual value) it stopped oscillating. The shape of the junk also changed depending on the current and temperature.
I enlisted Frank's help, and we systematically went through the experiment, placing diodes at pickoff spots and adjusting optics one-at-a-time until we found the source. We traced it back all the way to the initial high-extinction PBS at the input to the experiment. We noticed that changing the ratio of admitted and rejected light caused the effect everywhere downstream, so we thought it might have something to do with scattered light. In the end, this appears to have been the case, as PBS had some strange ghost beam reflecting inside and clipping on the custom mount. We think that when the power was high enough this would reflect back into the laser and interfere, causing the oscillation.
We made the effect pretty much go away by moving the thing slightly so that the ghost beam wasn't clipping anymore, but Frank thinks that we might want to replace it anyway since it shouldn't produce a ghost beam by design. I am going to inspect it now and then realign everything. One day I'll get back to the loop measurements.
I did the EOM sweep measurement. It looks like we are fine above ~30 MHz, but the junk at low frequencies could explain why we had excess RFAM at, say, 18 MHz. The plot and a diagram of the experimental setup are below.
The source level was the maximum 15 dBm, the frequency range was 1-100 MHz (linear) over 801 pts (maximum) with 30 averages. The RFAM amplitude is now back below about -80 dBm for the standard DC PD voltage of 100 mV we have been using. Note: the strange ~2 MHz oscillation for low incident power remains...
I also reconfigured the AOM double-pass setup, realigning the polarizing optics and extracting the double-first-order beam. I was able to get ~50% efficiency (~125 mW out / 250 mW in), or a single-pass efficiency of ~71%. Tomorrow I will direct this beam into the cavity and maximize transmission, then continue with the loop measurements.
Remember that you still have to check the crystal for resonances. Sweep the EOM and look at the CCW PD with the cavity blocked internally. The mechanical Q of the crystal can be ~1000s, so it needs to be a fairly fine sweep.
If there are resonances close to the 33 MHz, you'll have to tune it off a little bit. And where's the sketch for the Pomona matching circuit?
I have realigned the primary beam from scratch; the spots are now centered fairly exquisitely on each of the cavity mirrors, as well as on all of the pre-cavity optics downstream of the input optics that Koji adjusted on Wednesday. I also aligned CW/CCW splitting PBS better.
I had somewhat of a difficult time getting everything to lock again very stably, but it appears to stay locked indefinitely now. Some notes:
(side note: we still need a modematching telescope for the CW beam)
After this, I can go back to the other list I made concerning loop measurements and beyond..
1. Alignment check of the IO
The original angle reads of the wave plates were 316deg and 38.0deg for the QWP and HWP, respectively.
The beam power before the EOM was 284mW.
At the last state, with the angle of 318.2deg and 33.7deg, the power of 284mW reached the EOM.
After the adjustment the power after the EOM was 274mW. The transmission efficiency of 96.5% sounds pretty fine.
2. RF leakage investigation
3. RFAM adjustment
4. Power supply AC path
On Friday evening, I acquired the primary error signal into the ADC with the cavity obstructed so that it would not resonate. I tuned the HWP before the EOM so that the error signal was centered about zero. I wanted to see if the RFAM was truly oscillating in amplitude or just monotonically increasing to some level after I had minimized it. Here is a short (5-hour) time series beginning right around then. The following 48 hours looked essentially the same, with a slight variation in the oscillation period and peak-to-peak level.
Today, I tried to get a quantitative handle on the RFAM level, but I was sidetracked by the weird behavior. I once again tried to minimize the circular light getting through the input optics by iteratively adjusting the initial QWP and the HWP immediately after it and minimizing the P light getting through the PBS. I was able to obtain a maximum contrast of 55.5 uW to 159 mW over the full range of the HWP for the optimal QWP setting, so that only ~0.03% of the light remained circularly polarized.
Then, I adjusted the HWP just down the line (immediately before the EOM) to center the far-from-resonance error signal about zero. I observed the same drift as before. I then put my hand on the metal case of the EOM and the drift increased rapidly, indicating that the time dependence of the RFAM is likely due to thermal coupling.
I verified that the beam was not clipping on either end of the EOM (there was some scatter from the edges of the beam, but the spot was centered on the aperture). I tried changing the alignment slightly to see if the drift lessened, but this failed.
I then tried swapping out the HWP for another---no dice. Then, I swapped the EOM for another broadband ThorLabs modulator of the same model. This seemed to work for a few minutes, as the drift appeared less pronounced, but it worsened quickly. It also responded the same way to the "grab the damn thing" test.
An interesting observation: the HWP orientation that minimizes the RFAM when looking at the signal from the PD on the RF analyzer IS NOT the same one that centers the error signal DC level at zero (in fact, the cavity will not lock at this setting). Conversely, when the error signal is centered at zero by setting the HWP, the PD signal shows strong RFAM (~40 dBm above noise level). This is baffling.
As my frustration was maturing, I caught the following sight (several of them, actually, but this was the only one I froze in time) on the scope:
Green is TRANS_DC, yellow REFL DC, blue ERR_INMON (note the offset), and purple the actuation signal to the PZT. The cavity has been locked for quite some time, but the slow loop is not engaged. As the length of the cavity slowly drifts, the feedback signal hops discretely from one level to another. This particular one is about a 3.5-volt step, corresponding to about 14 MHz. I am no expert, but this looks to me like some sort of mode hopping. There is not (and has never been) a dedicated faraday isolator at the experiment input, so I think it is quite possible that back-reflections are getting back into the laser head. From what I understand, mode hopping is uncommon in a short NPRO, and I'm not sure how this would affect the output polarization of the laser, but it seems suspicious. By the time I gave up, the circular light contrast had decreased by a factor of more than 4 (i.e. the minimum achievable power with the same QWP orientation was > 200 uW).
That's just a measure of the total rate at which data is getting acquired. I'm not sure of the units, but for comparison, we were above 1000 before we reconfigured everything (including the channels that Dmass was using).
Come to think of it, "LASER_PZ_ACT_EXC" is not really the channel we want for transfer functions (at least not of the fast loop) because this excitation will go to the temperature control. I have connected the gyro TEST out #1 to the PZT SWEEP input of the primary PDH box, so this is the channel that we should use. I will switch them.
I acquired the necessary channels for the gyro. They are:
We will need to add the TEST input and output channels as we need them, as well as the REFL DCs when that information is available.
Current DAQ rate = 919
What does this DAQ rate=919 thing mean? Is it not running at 32k?
This morning, I started fresh with this error signal offset issue. I put a beam block in the cavity so that it would not resonate and tried the following things:
Therefore, it appears that there is some (strong) time dependence to the amount of RFAM we get out of the EOM. It's not clear to me why this wasn't an issue before we put in the new PDs, but I guess several things have changed in the past week or two. The experimental setup is below.
This is a list of what needs to be done next.
Yesterday, we replaced the CW REFL PD with the second PDA225. We noticed that turning it on made the output rail so we did some debugging and found that the switch was broken. Koji did some magic and got it working again. We also changed the CCW REFL setup so that we could point the beam at the PD better (before, we didn't have room for a full mount between the faraday isolator and the gyro enclosure, so we had fixed up a lens mount to do the job and had to use the focusing lens and PD height to center the beam).
The InGaAs diodes have a much better response to 1064 nm so---even with the maximum screening from a Y1S-45---we had to reduce the input power to the experiment in order not to cause the loop to oscillate. (This was, of course, after we turned the gain of the PDH box all the way down to "0.0". We should modify the PDH box to have lower gain so that we can turn up the optical power without the loop becoming unstable).
We hooked everything up and got the gyro fully operational again, with both directions locking well. The measured primary loop had a UGF of ~12 kHz with a puny phase margin of ~8 deg. The thought here is that we should swap out the slow OP27s in the PDH box for faster op amps (in the short term) and eventually design our own servo.
We also noticed that there was a significant DC offset in the primary error signal. We guessed that this was from RFAM from the EOM, so we adjusted the orientation of the HWP before it to minimize it.
We hooked the following signals up to CDS:
Today, I came in to find that the gyro was not locked. When I got it locking again, I noticed that the PZT drive was sitting close to the rail and the slow loop was doing nothing about it. I played around with the slow loop filter and got it into a reasonably stable configuration (pole @ DC, zero @ 0.1 Hz to cancel the internal pole of the PZT).
As I changed settings in the slow loop, I noticed that the cavity was having a hard time locking again. I realized that the error signal offset had returned, and a slight rotation of the HWP brought the cavity back into a lockable state. I decided to remove all other variables by sweeping the PZT directly (as opposed to through the PDH box) and looking at the error signal directly (as opposed to through INMON). I then rotated the HWP to minimize the error signal offset, retuned the phase shift to maximize the response, and then adjusted the input power to make it as high as possible without an oscillation.
Things seemed to be working, but then the same error offset issue came back. I am not sure what it is, but it needs to be investigated thoroughly. This is the plan for tomorrow morning.
added a ccd camera and a macro lens to monitor changes in surface scatter. I'm using a 670nm diode laser module for illumination.
Due to the added ccd camera i had to change the way i make the whole setup dark in order to be able to measure the dark current and dark noise.
Using a black trash bin to cover the entire setup. Drilled and tapped a 1" hole in on side where i attached the beam tubes which connect to the shutter.
Have to work on the cable feedthroughs and replace the netbook with the IBM notebook. Installed all software today but didn't have time to test it.
Here first pictures of the new setup: red: diagnostic beam, blue: 1064nm beam.
Everything has to fit between the area between the black baseplates on the table (top, left & right of the picture) minus ~0.5" for the trash bin.
covered setup with shutter attached to the right. Trash bin has adhesive-backed foam on bottom (window insulation) as cushion to seal against the table
first sample picture taken from monitor showing scattered light from diode active area taken in the dark with some additional white led light to see the diode structure
You ought to measure the PDA255 noise with the RF analyzer and compare it to the spec and the thermal noise you expect from such a diode.
Is the demodulator noise of the PDH box good enough for our purposes? i.e. will we reap the benefit of a good PD or not?
Below is a plot of some noise measurements on the PDA255 with which we have replaced the old PDA10A as the primary REFL diode. The traces are:
I realized that last time I did this I simply turned off the oscillator to take the no-EOM data. This is wrong because it also turns off the LO to the mixer, so the PD signal is not getting mixed down. This time, I physically disconnected the EOM to take this trace.
The plot is not very illuminating, except in that it shows that the noise in the demodulation setup is dominated by the dark noise of the PD. As seen in a previous post, the dark PD noise level is above but comparable to the input noise of the PDH box above ~1Hz. Below this---in our frequency band of highest interest---the PDH input noise dominates at the moment. The same linked plot shows that the theoretical noise estimate for the PDH input is substantially lower than the measured noise at low frequencies, so the PDs will certainly limit us if we get it to this level.
It goes without saying that both the final PDs and the final servo should contribute much less noise than these do.
Seems fine, now...
The ATF wiki is down. So is the 40m one. The elogs are still running and I can ssh into Nodus which is where the ATF wiki now lives. I'm having a bit more of a look at this now.
That is strange. I had also forgotten that the 40m wiki isn't hosted at Caltech. I still can't get access to either of them.
Below is a comparison of the measured input-referred noise of PDH box #1437 with the estimated noise from LISO. It appears that the measured noise is substantially higher below around a kHz. The only thing not included in the model (besides shielding capacitors, etc.) is the AD8336 variable gain stage, but unless this is a limiting noise source it should not contribute to the input-referred noise. The LISO model output is provided below, as well.
I've ordered the new router. Joe tells us that the 40m router is a Linksys BEFSX41 , however this model doesn't seem to be available anywhere (unless you count secondhand ones on amazon....) even on the linksys website. Instead I have ordered the next one up in the range which appears from the specs to be the same router but with 8ports. It is a BEFSR41. Should be with us in approx 2-3days as it was in stock.
Last week, we did some work towards calibrating the actuation gains of the VCO and NPRO PZT, which was documented in Koji's elog posts. This post summarizes the method.
First, a sine wave with a nominal amplitude of 10 mVpp @ 1 kHz was injected into the PZT sweep of the primary PDH box, and the peaks in the primary error and feedback signals were recorded, as well as that in the secondary error signal (which was being held in the linear response region by the main servo):
Note that the error signals were being read out at INMON, so they are multiplied up by ~42.
Next, the same drive signal was connected to the Tektronix VCO external FM input, with a nominal deviation setting of 100 kHz/V and a carrier frequency of 47.5 MHz (as usual). The output was then connected to the RF analyzer to study its frequency structure and determine the modulation depth.
The structure of an FM signal in frequency space consists of a carrier and a series of sidebands at integer numbers of the modulation frequency from the carrier, whose powers are determined by the bessel expansion. I.e., the nth sideband will be at a frequency fc + n*fmod with a power Pn = ( Jn(Γ)/J0(Γ) )2 * Pc, where Γ = Δf / fmod is the modulation depth and 2*Δf is the peak-to-peak amplitude of the frequency modulation.
The powers of the sidebands were measured (in dBm) and divided by the carrier power, and this array of values was fit to the appropriate array of bessel function ratios to obtain a modulation index and therefore an FM amplitude. Below are two plots, one for the 1-kHz excitation mentioned above and another for the same test done with a 100-Hz excitation with the same amplitude, which is more impressive and used more points.
The inferred peak-to-peak FM deviation was thus ~993 * 2 = 1986 Hz. Since the FG displays the voltage for a 50-ohm load, this value is reasonable as the external FM input has an impedance of 10kohm. So, 0.01 mVpp (*2 for display error) * 10K/(10K + 50) * 100 kHz/V ~ 1990 Hzpp.
This signal was put into the AOM and elicited a peak of 247.258 Vrms in the secondary loop error signal. Since the AOM is double passed, the true optical deviation was 2 * 1986 = 3972 Hzpp. This implies that, when it was put into the PZT sweep input, the same injection caused a deviation
(64.9701 uVrms / 247.258 uVrms) * 3972 Hzpp = 1043 Hzpp.
Using the signal strength in the PZT feedback path from above, we can infer a PZT actuation gain of
GPZT = 1043 Hzpp / (98.7438 uVrms * 2*sqrt(2)) = 3.734 MHz/V
Frank and I had to play some games with openmotif/grace/medm to get things going again. Basically, the EPEL repo should be added to all of the linux machines using rpm.
Then, we must install grace from the EPEL and this will also install the correct 64 bit openmotif which is used by MEDM (Motif Editor and Display Manager). As of now, dataviewer
and DTT and MEDM are working on most machines.
I changed over the user/group ownership of the /frames subdirectories to controls for both fb0 and fb1. Lets see if this is correct.
I also updated the firmware on the linsys router, turned off uPnP, and also turned off DHCP (as a test). I've been noticing that what happens
lately is that the connection to the outside world just goes away sometimes and then comes back after a few minutes. This along with
the fact that our bandwidth to our own LIGO network is only 600 kB/s makes me think that the issue is on Larry's side of the table.
Below is a plot of one particular gyro signal channel along with various electronics noise contributions to the gyro signal in general. The traces are:
All of these signals were then divided by the cavity response in [V/Hz]---which are all the same except for in (3)---and then multiplied by (lambda P / 4A) to obtain spectra in units of (rad/s)/rHz. The input-referred noise of PDH 2 is not shown, but given the same output level would result in roughly 10x the noise contribution to the gyro signal due to the roughly 10x lower optical response of the cavity in the secondary direction.
now 300mJ (20W and 15ms). Beam diameter still 1mm.
I keep increasing the pulse duration until i see first damage of this already heavily used diode to see where the damage threshold is, then use go back a little bit an use a new, unused diode to see if i can measure changes in parameters.
after ~1.5 the netbook stopped working again. Will switch to the old IBM notebook tomorrow. Jan is using it right now as a backup computer.
Below is a comparison of the "unsuppressed" primary loop frequency noise with the free-running NPRO noise taken from Rana's thesis (p.80). The primary error signal was multiplied by the OLTF to obtain the unsuppressed voltage noise at the servo input, and this was then divided by the cavity response quoted in the previous elog post to obtain the unsuppressed noise in Hz. The plot shows that the gyro cavity displacement noise is ~10-100x higher than the free-running laser noise up to a few kHz.
By using the measured NPRO PZT actuation gain of ~4 MHz/V, along with an analytical model of the PDH box and primary OLTF, I estimated a cavity response of roughly 5.6 x 10-8 V/Hz. Using this, I calibrated both the primary error signal and feedback signal into units of frequency to see that they were consistent. The calibrations are
The plot below demonstrates that they are self-consistent. Note that this is only done up to 10 kHz because I have not made an analytical model of the notch filter yet.
As is the standard mandated by CDS, I have converted the UID for controls to 1001 and the groupID of the controls group to 1001 and made the user controls be a member of the controls group only.
I had done this on ws1/ws2 before and there were naturally inconsistencies with it and fb1. I have just now done it fb1 and then fixed up many files by doing:
chgrp -R controls *; chown -R controls *
in /cvs/cds/caltech/ and in /opt/
There will certainly be short term negative consequences of this action, but its better we do it sooner than later. I'll have to get some Seifert consultation to finish fixing fb0.
netbook was frozen the second time this weekend. Software installations didn't change since a week (since i'm using it for the pulsing experiment).
We have seen this before when using it for the wincam or the particle counter, but very rarely.
Now it happend twice within 24h, once after ~23000 pulses, second time after ~6000 (3h of operation after reboot)
Will restart the measurements...
The network interface for ws1 was failing to work for some reason. I tried the usual Linux forums for advice but most of it was useless.
Finally one of them suggested that there was a warm power up v. cold power up issue with the Realtek 8169 Network card chipset.
So I turned off the machine and then reformatted the disk and did a fresh install. The network is now working (allowing this elog access).
But then...I realized that (someone) gave me a 32-bit install DVD and so I'm now wiping it and starting over.