Back in Gainesville in 1997, I learned how to do this using the chopper wheel. We had to make the assumption that the wheel's blade was moving horizontally during the time of the chop.
One advantage is that the repetitive slices reduces the random errors by a lot - you can trigger the scope and average. Another advantage is that you can download the average scope trace using USB, floppy, or ethernet instead of pencil and paper.
But, I never analyzed it in enough detail to see if there was some kind of nasty systematic error.
LSC Plant Model. That is all.
Oh, but it gets even better: in order to trust the A2L script in this regard you have to know that the coil driver - coil - magnet gain is the same for each channel. Which you can't.
But we have these handy f2pRatio scripts that Vuk and Dan Busby worked on. They use the optical levers to balance the actuators at high frequency so that the A2L gives you a true spot readout.
But wait! We have 4 coils and the optical lever only gives us 2 signal readouts...
To try the 3-corner hat method on the Marconis, I started to set up the measurement into the DAQ system.
I have set the bottom 2 in the PSL rack to 11.1 MHz. I use a ZP-3MH level 13 mixer as the phase detector. The top one is the LO, it has an output of +13 dBm.
The bottom one is the test unit, it has an output of +6 dBm (should be close to the right level - the IP3 point is +9 dBm). The top one has external DC FM modulation enabled with a FM dev range of 10 Hz.
Mixer output goes through a 50 Ohm in-line termination and then a BLP-5 low pass filter (Steve, please order ~7 of the BLP-1.5 or BLP-1.9 low pass filter from Mini-Circuits) and then into
the DC coupled of a SR560. After some gain and filtering that feedback goes back to the FM input of the top-Marconi to close the PLL. I adjusted the gain to be as small as possible and still stay locked and not
saturate the ADC.
The input to the SR560 is Tee'd into another SR560 with AC coupled input, G = 1000, low-noise. Its output is going directly to the ADC channel - C1:IOO-MC_DRUM1.
I calibrated the channel by opening the loop and setting the AC coupled gain to 1. This lets the Marconis beat at several Hz. The peak-peak signal is equivalent to pi radians.
As usual, I was befuddled by the FM input. For some reason I always forget that since its a straight FM input, we don't need any filtering to get a plain 1/f loop. The attached plot shows how we get bad gain peaking if you forget this and use a 0.03 Hz pole in the SR560.
The grey trace is the ADC signal with everything hooked up, but the RF input set to zero (via setting Carrier = OFF in the bottom Marconi). It is the measurement noise.
The BLUE trace is very close to the true phase noise beat of the two Marconis with a calibration error of ~5%. I have not corrected for the loop gain: its right now around a 1 Hz UGF and 1/f. Next, I will measure the loop and compensate for it in the DTT calibration.
Then I'll measure the relative phase noise of 3 of the signal generators to get the individual noises.
Bottom line is that the sensitivity of this approach is good and we should do this rather that use spectrum analyzers since its easy to get very long averages and high res spectra. To get 5x better sensitivity, we can just use the Rai-FET box instead of a SR560 for the readout, but just have to contend with its batteries. Also should try using BALUNs on the RF and LO signals to get rid of the ground loops.
In order to measure the transfer function of the RC cavity's foam, I've turned off the servo so that the room temperature noise can excite it.
The attached plot shows a step response test from 2 weeks ago. Servo is nominally still working fine.
I've just now re-enabled the temperature control of the reference cavity can. Trend of the last 8 days is attached.
My attempt to passively measure the transfer function of the foam failed fantastically.
As it turns out, the room temperature fluctuations inside the PSL box reach the 1 mK/rHz noise floor of the AD590 (or maybe the ADC) at ~1-2 mHz. Everything at higher frequencies is noise.
So to see what the foam is doing we will have to do something smarter - we need a volunteer to disable the RC temperature servo from the EPICS screen and then cycle the PSL table lights every hour in the morning.
We'll then use our knowledge of the Laplace transform to get the TF from the step responses.
To check the UGF, I increased the gain of the PLL by 10 and looked at how much the error point got suppressed. The green trace apparently has a UGF of ~50 Hz and so the BLUE nominal one has ~5 Hz.
The second attachment shows the noise now corrected for the loop gain. IF the two signal generators are equally noisy, then you can divide the purple spectrum by sqrt(2) to get the noise of a single source.
The .xml file is saved as /users/rana/dtt/MarconiPhaseNoise_100504.xml
more detailed instructions needed....
We've turned off the RC temperature stabilization and the lights will supply the quasi-random heat input to the table and the cavity. Alberto and Kiwamu will be turning the lights on and off at random times.
The attached plot is the spectrum of temperature fluctuations of the room and the vacuum can with no stabilization from this weekend. I think the rolloff above 10 mHz is kind of fake - I had the .SMOO parameter set to 0.99 for both of these channels. I've just now set the .SMOO to 0 for both channels, so we should now see the true ADC or sensor noise level. It should be ~1 mK/rHz.
I added a noise model of the SR560 to the LISO opamp.lib. This assumes you're using it in G=100, low-noise mode. The voltage noise is correct, but I had to guess on the current noise because I didn't measure it before. Lame.
This can be compared with the noise that we measure when locking it down...
To measure the width of a resonance, the standard method is to state the center frequency and the Q. Use the definition of Q from the Wikipedia.
As far as how much phase is OK, you should use the method that we discussed - think about the full closed loop system and try to write down how many things are effected by there being a phase slope around the modulation frequency. You should be able to calculate how this effects the error signal, noise, the loop shape, etc. Then consider what this RFPD will be used for and come up with some requirements.
On Friday, I deleted a bunch of filters from the c1susvme2 optics' screens (MC1,2,3 + SRM) so as to reduce the CPU load and keep it from going bonkers.
This first plot shows the CPU trend over the last 40 days and 40 nights. As you can see the CPU_LOAD has dropped by 1 us since I did the deleting.
In the second plot (on the right) you can see the same trend but over 400 days and nights. Of course, we hope that we throw this away soon, but until then it will be nice to have the suspensions be working more often.
Where did you get the 55nH based notch from? I don't remember anything like that from the other LSC PD schematics. This is certainly a bad idea. You should remove it and put the notch back over by the other notch.
Why is it a bad idea?
You mean putting both the 2-omega and the 55MHz notches next to each other right after the photodiode?
Just a little while ago, at 2330 UTC on 5/11, I swapped the phase noise setup to use another Marconi - this time its the 3rd one from the top beating with the 4th one from the top (2nd from the bottom).
After a little while, I swapped over to beat the 33 w/ the 199. I now have all the measurements. For the measurement of the last pair, I inserted BALUN 1:1 transformers on the outputs of both signal generators'.
This last pair appears to be the quietest of the 3 and also has less lines. The lines are mainly at high frequency and are harmonics of 120 Hz. Probably from the Sorensen switching supplies in the adjacent rack.
I double checked that the 10 MHz sync cable was NOT plugged in to any of these during this and that the front panel menu was set to use the internal frequency standard. In the closed loop case, the beat frequency between the 33/199 pair changes by less than ~0.01 Hz over minutes (as measured by calibrating the control signal).
Finally got the 3-cornered-hat measurement of the IFRs done. The result is attached.
s12, s23, & s31, are the beat signals between the 3 signal generators.
s1, s2, & s3 are the phase noise of the individual generators made by the following matlab calculation:
%% Do the hat
s1 = sqrt((s12.^2 + s31.^2 - s23.^2) / 2);
s2 = sqrt((s12.^2 + s23.^2 - s31.^2) / 2);
s3 = sqrt((s31.^2 + s23.^2 - s12.^2) / 2);
%% Do the hat
s1 = sqrt((s12.^2 + s31.^2 - s23.^2) / 2);
s2 = sqrt((s12.^2 + s23.^2 - s31.^2) / 2);
s3 = sqrt((s31.^2 + s23.^2 - s12.^2) / 2);
As you can see, there is now an estimate of the individual noises. We can do better by doing some fitting of the residuals.
The real test will be to replace the noise one here with the good Wenzel oscillator and see how well we can estimate its noise. If the 11 MHz crystals don't show up, I can just try this with the 21.5 MHz one for the PSL.
This idea was tried before by Dale in the ~1998 generation of PDs. Its OK for damping a resonance, but it has the unfortunate consequence of hurting the dynamic range of the opamp. The 100 Ohm resistor reduces the signal that can be put out to the output without saturating the 4107.
I still recommend that you move the notch away from the input of the 4107. Look at how the double notch solution has been implemented in the WFS heads.
If you have a working 40m Optickle model, put it in a common place in the SVN, not in your own folder.
I can't figure out why changing the arm length would effect the RF sidebands levels. If you are getting RF sidebands resonating in the arms, then some parameter is not set correctly.
As the RF sideband frequency gets closer to resonating in the arm, the CARM/DARM cross-coupling to the short DOFs probably gets bigger.
I uploaded the latest iscmodeling package to the SVN under /trunk. It includes my addition of the 40m Upgrade model: /trunk/iscmodeling/looptickle/config40m/opt40mUpgrade2010.m.
I don't know the causes of this supposed resonances yet. I'm working to try to understand that. It would be interesting also to evaluate the results of absolute length measurements.
Here is what I also found:
It seems that 44, 66 and 110 are resonating.
If that is real, than 37.5m could be a better place. Although I don't have a definition of "better" yet. All I can say is these resonances are smaller there.
RMS which is integrated down to 1Hz is 1.6MHz.
This number is almost what I expected assuming the cavity swings with displacement of x ~< 1um.
Its OK, but the real number comes from measuring the time series of this in the daytime (not the spectrum). What we care about is the peak-peak value of the PZT feedback signal measured on a scope for ~30 seconds. You can save the scope trace as a PNG.
Valera and I put the 2 Guralps and the Ranger onto the big granite slab and then put the new big yellow foam box on top of it.
There is a problem with the setup. I believe that the lead balls under the slab are not sitting right. We need to cut out the tile so the thing sits directly on some steel inserts.
You can see from the dataviewer trend that the horizontal directions got a lot noisier as soon as we put the things on the slab.
Although trends are available, I am unable to get any full data from in the past (using DTT or DV). I started the FB's daqd process a few times, but no luck.
I blame Joe's SimPlant monkeying from earlier today for lack of a better candidate. I checked and the frames are actually on the FB disk, so its something else.
The seismometers showed an increased noise in the Y-direction when put on top of the granite slab. By tapping the slab, you can tell that its really a mechanical resonance of the lead balls + granite system at ~15-20 Hz.
I tried new balls, flipping the slab upside down, and sitting on the slab for awhile. None of this changed the qualitative behavior, although each of the actions changed the resonance frequencies by several Hz.
I have removed the granite/balls and put the seismometers back on the linoleum floor. The excess noise is gone. I have put the new big box back on top of them and we'll see how the data looks overnight.
I expect that we should remove the linoleum in a wider area and put the seismometers directly on the floor.
This plot shows the noise with the box on, but no granite. We're still pretty far off from the Guralp data sheet.
I implemented software rotation in the huddle subtraction as Valera suggested and it works much better. The two plots below show the before and after. So far this is just 2 deg. of rotation around the z-axis. I'm assuming that aligning the seismometers vertically via bubble level is good enough for the z-axis, but I haven't calibrated the bubble yet.
The residual slope is now suspiciously smooth. I somehow suspect that our readout electronics can still be responsible. We need to hook up a 9V battery to the input terminals to check it out. Its a little steeper than 1/f and I thought that we had exonerated the Guralp breakout box in the past, but now I'm not so sure. I'll let Jenne comment on that.
I also noticed that we have not yet divided by sqrt(2) to account for the fact that we are subtracting 2 seismometers. In principle, an unbiased estimate of the single seismometer noise will be lower by sqrt(2) than the green curve.
At ~2350 UTC on June 2, the seismometers were turned off. After the granite slab was repositioned with the new lead, the Ranger was turned on, but not the Guralps.
Now, after ~24 hours, I have put the Guralps onto the granite and turned them on. During this off time, the input channels should be ADC noise limited (or perhaps limited by the INA134 differential receiver chips inside of the Sander Liu AA chassis). The following plot shows that this noise level is ~0.8 uV/rHz and then rising like ~1/sqrt(f) below 5 Hz:
I checked the slab again by whacking it. It still rings with a Q of several, so I think we need to make the lead flatter. There should barely be any room between the granite and the linoleum.
I guessed that it should be possible to make the slab-to-floor coupling better with flatter lead (Brian Lantz suggested to use lead sheets). So I removed my booties and jumped up and down on the granite several times. Because of my soft sole shoes, I was able to make an impulsive impact without shattering the granite. The effect of the stomping was pretty dramatic - the horizontal resonance frequency has gone up by a factor of 2. The red trace shows the new TF after the stomping:
And the resulting spectrum is here too. As you can see, there is no excess between the Ranger and the Guralps until ~50 Hz where the mechanical resonance in the short direction (non-MC dir) takes over.
So, the lesson for next time is to flatten the balls a little more. I leave it to Nancy to calculate the horizontal resonant frequencies of this lead/granite combo to see if it matches with our measurements.
For the huddle test, I have updated the code to divide the residual by sqrt(2) because of the assumption of equal noise from the 2 Guralps. We would have to multiply this trace by sqrt(2) to compare with the previous results.
Now the question is, how do I add a low noise ~50 mV offset to the front of the Guralp breakout box to test for the noise of the box?
While trying to set up the SIS-FFT to use our new ITM phase maps, I noticed that the surface of our ITMs looks pretty good actually (even compared to the aLIGO pathfinder optic map on the AIC wiki). I'm attaching it here for your viewing pleasure.
The code to plot it has been added to the SVN in the PhaseMaps/mat directory.
As before, I am unable to get data from the past. With DTT on Allegra I got data from now, but its unavailable from 1 hour ago. Same problem using mDV on mafalda. I blame Joe again - or the military industrial complex.
I tried running dataviewer and dtt this morning. Dataviewer seemed to be working. I was able to get trends, full data on a 2k channel (seismic channels) and full data on a 16k channel (C1:PEM-AUDIO_MIC1) This was tried for a period 24 hours a go for a 10 minute stretch.
I also tried dtt and was able to get 2k and 16k channel data, for example C1:PEM-AUDIO_MIC1. Was this problem fixed by someone last night or did time somehow fix it?
This is a reminder (mainly for Steve, who somehow doesn't believe these things) that op540m is not to be used for your general pleasure.
No web, no dataviewer, no DTT. Using these things often makes the graphical X-Windows crash. I have had to restart the StripTool, our seismic BLRMS and our Alarms many times because someone uses op540m, makes it crash, and then does not restart the processes.
Stop breaking op540m, Steve!
We obtained a good mode match overlap of 99.0% for the new IOO.
And if we move the position of MMT2 by another 10 cm away from MMT1, we will have 99.6% overlap.
That's hot stuff.
I was getting an excess noise in the C1:IOO-MC_DRUM1 channel - it was a flat spectrum of 10 cts/rHz (corresponding to 600 uV/rHz).
I tried a few things, but eventually had to power cycle the crate with c1iovme in order to recover the standard ADC noise level of 3x10^-3 cts/rHz with a 1/sqrt(f) knee at 10 Hz.
I checked the gain of the channel by injecting a 2 Vpp sine wave at 137.035 Hz. 2Vpp as measured on a scope gives 31919 cts instead of the expected 32768, giving a 2.5% error from what we would have naively calculated.
Even so, the noise in this channel is very surprisingly good: 0.003 / (31919 / 2) = 187 nV /rHz. The best noise I have previously seen from an ICS-110B channel is 800 nV/rHz. What's going on here?
I am trying to get an actual complete install of the 40m svn on my machine. It keeps stopping at the same point:
I have always seen this when checking out the 40m medm SVN on a non-Linux box. I don't know what it is, but Yoichi and I investigated it at some point and couldn't reproduce it on CentOS. I think its some weirdness in the permissions of tmp files. It can probably be fixed by doing some clever checkin from the control room.
Even worse is that it looks like the whole 'SVN' mantra has been violated in the medm directory by the 'newCDS' team. It could be that Joe has decided to make the 40m a part of the official CDS SVN, which is OK, but will take some retraining on our part.
It seems to work, sort of.
Those drawings are an OK start, but its obvious that things have changed at the 40m since 2002. We cannot rely on these drawings to determine all of the channel counts, etc.
I thought we had already been through all this...If not, we'll have to spend one afternoon going around and marking it all up.
Not dead. It just had a HT fault. You can tell by reading the front panel. Cycling the power usually fixes this.
As per Steve's instructions, at 12:43 AM, I used the following steps to stop the pumpdown until the morning:
Kiwamu, Nancy, and I restored the power into the MC today:
We found many dis-assembled Allen Key sets. Do not do this! Return tools to their proper places or else you are just wasting everyone's time!
Just as I expected, since these hunuman didn't actually check MC_L after doing this stuff, MC_L was only recording ZERO. Joe and I reset and restarted c1susmve2 and then
verified (for real this time) that the channel was visible in both the Dataviewer real time display as well as in the trend.
The lesson here is that you NEVER trust that the problem has been fixed until you check for yourself. Also, we must always
specify a very precise test that must be used when we ask for help debugging some complicated software problem.
I re-aligned the beam into the PMC. I got basically no improvement. So I instead changed the .LOW setting so that PMCTRANS would no longer go yellow and make the donkey sound.
I did the same for the MOPA's AMPMON because its decayed state is now nominal.
Steve and I removed the thermal insulation from around the reference cavity vacuum chamber. It wasn't really any good anyways.
Here are the denuded photos:
Steve and I are now planning to replace the foam with some good foam, but before that we will wrap the RC chamber with copper sheets like you would wrap a filet mignon with applewood bacon.
This should reduce the thermal gradients across the can. We will then mount the sensors directly to the copper sheet using thermal epoxy. We will also use copper to cover most of this hugely
oversized window flange - we only need a ~1" hole to get the 0.3 mm beam out of there.
My hope is that all of this will improve the temperature stability of this cavity. Right now the daily frequency fluctuations of the NPRO (locked to the RC) are ~100 MHz. This implies
that the cavity dT = (100 MHz) / (299792458 / 1064e-9) / (5e-7) = 1 deg. That's sad....
I also changed the RC_REFL cam to manual gain from AGC. I cranked it to max gain so that we can see the REFL image better.
After whatever Joe/Alberto did this afternoon, the MC was not locking. Koji and I removed several of the cables in the side of the rack where they
were apparently working (I say apparently because there's no elog).
MC is now locking but the autolocker did not work at first - op340m was unable to access any channels from c1iool0. After several minutes, it mysteriously
started working - the startup.cmd yields errors seen on the terminal. I attach the screen dump/.
Sometimes I like to plot the spectrum of MC_F. Its a good diagnosis of whether something is wrong.
The red trace is noisier than the blue reference. What is the cause of this?
As you can see, there was not much (if any) worsening of the laser frequency fluctuation from removing the RefCav insulation. The plots below are zooomed in:
I have used the same peak-to-peak scale so that its easy to compare the fluctuations before (LEFT) and after (RIGHT).
As you can clearly see, the laser frequency moves just as much now (the SLOW_DC) as it did before when it had the insulation. Only now the apparent (i.e. fake) RC temperature fluctuations are much larger. So this sensor is fairly useless as configured.
To make the beam on the MC trans camera bigger, I removed the lens + ND filter that was in that path.
The camera was getting the transmission through a BS1-33 (33% reflector). The reflection went to the TRANS QPD. I changed
the R=33% into an HR mirror (Y1-45P) so now the camera has a nice beam. The QPD was now saturating so I put a ND06 into that path
so now the TRANS_SUM is ~4.5-5 V when the MC is aligned.
The MC was also misaligned and failing to lock all weekend (why??) so I aligned the MC mirrors to get it to acquire again. Since we want to
collect MC seismic data, please make sure the MC is locked and running after finishing with your various MC or PSL work (this means YOU).
Since we now have a good measurement of the phase noise of the Rb clock Marconi locked to the Rb clock, I wanted to use that to check out the old DAQ system:
I used Megan's phase noise setup - Marconi #2 is putting out 11000013 Hz at 13 dBm into the ZP-3MH mixer. Marconi #1 is putting out 3 dBm at 11000000 Hz into the RF input.
The output goes through a 50 Ohm load and then a Mini-Circuits BNC LP filter (either 2 or 5 MHz). Then an SR560 set for low noise, G = 5, AC coupling, 1-pole LP @ 1 kHz.
This SR560 output goes into the channel C1:IOO-MC_DRUM1 (which is sampled at 16384 Hz with ICS-110B after the usual Sander Liu AA chassis containing the INA134s).
So...who was working around the PSL rack this morning and afternoon? Looks like there was some VCO phase noise work at the bottom of
the rack as well as some disconnecting of the Guralp cables from that rack. Who did which when and who needs to be punished?
I just realized that an unfortunate casualty of this LSC work was the deletion of the slow controls for the LSC which we still use (some sort of AUX processor). For example, the modulation
depth slider for the MC is now in an unknown state.
I reconnected the RF signal to the FSS and to the FSS' EOM so that we could lock the refcav again.
I then started a 3 sec. period trianglewave on the AOM drive amplitude to see if there is a direct coupling from RIN to Frequency. Ideally we will be able to measure this by looking at the RCTRANS and the FSS-FAST.
This is the 0.3 mHz BW spectrum of this test - as you can see the apparent linewidth (assuming the width is all caused by the DAQ jitter) is comparable to the BW and therefore not resolved.
Basically, the Hanning window function is not sharp enough to do this test and so I will do it offline in Matlab.