This is the error point spectrum - it is filled with huge multiples of ~75 kHz as Yoichi noticed a couple years ago.
I tried to use the netgpib.py package to read out the Agilent 4395, but the SVN had been corrupted by someone saving over the netgpib.py package. To get it to work on rosalba I reverted to the previous version, but whoever is busy hacking on netgpib.py needs to checkin the original package and work on some test code instead.
I also noticed that the default output format for the AG4395.py file is in units of Watts. This is kind of dumb - we need someone to develop this package a little as Yoichi did for the SRS785.
I measured the open loop gain of the FSS (as usual, I have multiplied the whole OLG by 10dB to account for the forward loop gain in the box). I used a source level of -20 dBm and made sure this was not saturating by changing the level.
Its clear that the BW is limited by the resonance at ~1.7 MHz. Does anyone know what that is?
I measured the RF spectrum coming out the FSS RFPD to look for saturations - its close to the hairy edge. This is with the 8x power increase from my AOM drive increase. I will increase the FSS's modulation frequency which will lower the Q and gain of the PD to compensate somewhat. The lower Q will also gain us phase margin in the FSS loooop.
I put in a bi-directional 20 dB coupler (its only rated down to 30 MHz, but its only off by ~0.3 dB at 21 MHz) between the RFPD and the FSS box. I looked at the time series on the 300 MHz scope and measured the power spectrum.
The peak signal on the scope was 40 mV; that translates to 400 mV at the RFPD output. Depending on whether the series resistor in the box is 20 or 50 Ohms, it means the MAX4107 is close to saturating.
As you can see from the spectrum, its mostly likely to hit its slew rate limit (500 V/us) first. Actually its not going to hit the limit: but even getting within a factor of 10 is bad news in terms of distortion.
Besides the multiples of the modulation frequency, you can see that most of the RMS comes from the strange large peaks at 137.9 and 181.1 MHz. Anyone know what these are from?
On the middle plot above, I have enabled the 20 MHz BW limit so you can see how much the amplitude goes down when only the 21.5 MHz SB is included. You can also see from the leftmost plot that once in awhile there is some 400mV/10ns slewing. Its within a factor of 10 of the slew rate limit.
Some more words about the RFAM: I noticed that there was an excess RFAM by unlocking the RC and just looking at the RF out with the 50 Ohm input of the scope. It was ~100 mVp-p! In the end our method to minimize the AM was not so sensible - we aligned the waveplate before the EOM so as to minimize the p-pol light transmitted by the PBS cube just ahead of the AOM. At first, this did not minimize the RFAM. But after I got angry at the bad plastic mounting of the EOM and re-aligned it, the AM seemed to be small with the polarization aligned to the cube. It was too small to measure on the scope and on the spectrum analyzer, the peak was hopping around by ~10-20 dB on a few second timescale. Further reduction would require some kind of active temperature stabilization of the EOM housing (maybe a good SURF project!).
For the EOM mount we (meaning Steve) should replace the lame 2-post system that's in there with one of the mounts of the type that is used in the Mach-Zucker EOMs. I think we have spare in the cabinet next to one of the arms.
After the RFAM monkeying, I aligned the beam to the RC using the standard, 2-mirror, beam-walking approach. You can see from the attached plot that the transmission went up by ~20% ! And the reflection went down by ~30%. I doubt that I have developed any new alignment technique beyond what Yoichi and I already did last time. Most likely there was some beam shape corruption in the EOM, or the RFAM was causing us to lock far off the fringe. Now the reflected beam from the reference cavity is a nice donut shape and we could even make it better by doing some mode matching! This finally solves the eternal mystery of the bad REFL beam (or at least sweeps it under the rug).
At the end, I also fixed the alignment of the RFPD. It should be set so the incident angle of the beam is ~20-40 deg, but it was instead set to be near normal incidence ?! Its also on flimsy plastic legs. Steve, can you please replace this with the new brass ones?
Its a good measurement - you should adjust the input range of the 620 using the front panel 'scale' buttons to see how the noise compares to Matt's circuit when the range is reduced to 1 MHz. In any case, we would use it in the 350 MHz range mode. What about the noise of the frequency discriminator from MITEQ?
The Lightwave NPRO should be around 5 MHz/V.
The Innolight PZT coefficient is ~1.1 MHz/V.
(both are from some Rick Savage LHO elog entries)
This evening we measured the noise spectrum of the reference cavity PD used in the FSS loop. From that we estimated the transimpedance and found that the PD is shot-noise limited. We also found a big AM oscillation in correspondence of the FSS modulation sideband which we later attenuated at least in part.
I was checking into the Guralp situation today. I put the rubber balls underneath the granite block (the Q is too high), but found unfortunately that Jenne's styrofoam box is too short to cover the Guralps on top of the granite. If the box was skinny enough to fit on the block or taller by ~6 inches, it would be perfect. We need some new Seismo boxes.
Here's the story of the Gur2 noise so far. We need to pull out and repair the breakout box.
1) At some point we noticed that the Guralp2 X channel was behaving badly.
2) Steve tried recentering with just a +12V supply - this didn't work. Jenne then centered it using the +/- 12V supply. This was OK.
3) Around noon on March 24, the channel 'goes bad' again.
4) On the afternoon of the 25th, most of the channels go to zero, but the GUR2X channel stays bad. There's NO ENTRY in the elog about this. This is UNACCEPTABLE. Apparently, the seismometers were disconnected without shutting off the power to the box. You MUST elog everything - otherwise, go home and sit on your hands.
5) On the evening of the 31st, Steve turns off the Guralp breakout box. From the trend, you can see that the signals all go to zero at that time.
6) From then until today, there is no noise in the GUR2X channel. From these tests we can guess that the problem is in the GUR2X channel of the breakout box, but not in the AA Chassis or the ADC, since those showed no excess noise with the box turned OFF. Its hard to be sure without elog entries, but I assume that 3/25-3/31 was a 'seismometer disconnected', but 'box on' state.
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.
Frank noticed that this particular SR560 had an offset on the output which was unzeroable by the usual method of tuning the trim pot accessible through the front panel.
I tried to zero the offset using the trimpots inside, but it became clear that the offset was due to a damaged FET, so Steve ordered ~20 of the (now obsolete*) NPD5564.
I replaced this part and adjusted the offsets and balanced the CMRR of the differential inputs mostly according to the manual (p. 17). There are a few notes that should be added to the procedure:
It looks like its working fine now. Steve's ordering some IF3602 (low-noise, balanced FET pair from Interfet) to see if we can drop the SR560's input noise to the sub-nV level.
Noise measured with the input terminated with a BNC short (not 50 Ohms) G=100, DC coupled, low-noise mode:
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.
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.