ID |
Date |
Author |
Type |
Category |
Subject |
860
|
Wed Aug 20 12:04:47 2008 |
Jenne | Update | SUS | Better diagonalization of PRM input matrix |
The values here should replace those in entry #851 from yesterday.
After checking the results of the input matrix diagonalization, I have determined that Sonia's method (described in LIGO-T070168) is more effective at isolating the eigenmodes than Shihori's method (LIGO-T040054).
So, the actual new PRM input matrices are as follows:
| POS | PIT | YAW
|
UL | 0.9678 | 1.000 | 0.7321
|
UR | 1.000 | 0.8025 | -0.9993
|
LR | 0.7235 | -1.1230 | -1.0129
|
LL | 0.6648 | -1.0452 | 1.0000
|
Attached are plots of the spectra of the eigenmodes, using both Shihori's and Sonia's methods. Note that there isn't a good way to get the side peak out of the eigenmodes.
I've put these into the SUS-PRM MEDM screen. |
861
|
Wed Aug 20 12:39:11 2008 |
Eric | Summary | Cameras | Weekly Summary |
I attempted to model the noise produced by the mirror defects in the ETMX images, in order to better assure that the fit to the beam Gaussian in these images is actually accurate. My first attempt involved treating the defects as random Gaussians which were scaled by the power of the beam's Gaussian. This didn't work at all (it didn't really look like the noise on the ETMX), and resulted in very different behavior from the fitting software (it fit to one of the noise peaks, instead of the beam Gaussian). I'll try some other models another time.
I made a copy of the ezcaservo source code and added options to it that allow the addition of minimum value, maximum value, and slew rate limits. This should allow the camera code to servo on ITMX without accidently driving the mirror too far or too fast. In order to get the code to recompile, I had to strip out part of the servo that changed the step value based on the amount of time that had elapsed (it relied on some GDS libraries and header files). Since the amount of time that passes is reasonably constant (about 2-3 steps per second) and the required accuracy for this particular purpose isn't extremely high, I didn't think it would matter very much.
I put together two MATLAB functions that attempt to convert pixel position in an image to actual position in real space. The first function takes four points that have known locations in real space (with respect to some origin which the camera is pointing at) and compares them to where those 4 points fall in the image. From the distortion of the four points, it calculates the three rotational angles of the the camera, as well as a scaling factor that converts pixels to real spatial dimensions. The second function takes these 4 parameters and 'unrotates' the image, yielding the positions of other features in the image (though they must be on the same flat plane) in real space. The purpose of this is to allow the cameras to provide positions in terms of physically meaningful units. It should also decouple the x and y axes so that the two dimensions can be servo'd on independently. Some results are attached; the 'original' image is the image as it came out of the camera (units in pixels), while the 'modified' image is the result of running the two functions in succession. The four points were the corners of the 'restricted access' sign and of the TV screen, while the origin was taken as the center of the sign or the TV. The accuracy of the transformation is reasonably good, but seems to depend considerably on assuring that the origin chosen in real space matches the origin in the image. To make these the same, they will be calculated by taking the intersections of the 2 lines defined by 2 sets diagonal points in each image. The first function will remain in MATLAB, since it only needs to be run once each time the camera is moved. The second function must be ported to C since the transformation must be done in realtime during the servo.
Joe and I attempted another scan of the PMC this morning. We turned the laser power down by a factor of ~50 (reflection off of the unlocked PMC went from ~118 to ~2.2) and blocked one beam in the MZ. We scanned from 40 V to 185 V ( -1 to -4.25 on the PZT ramp channel) with periods of 60 seconds and 10 seconds. In both cases, thermal effects were still clearly visible. We turned the laser power down by another factor of 2 (~1 on the PMC reflection channel), and did a long scan of 300 seconds and a short scan of 10 seconds. The 10 second scan produced what may be clean peaks, although there was clear digitization noise, while the peaks in the 300 second scan showed thermal effects. I've yet to actually analyze the data closely, however. |
862
|
Wed Aug 20 13:23:32 2008 |
rob | Update | Locking | DRMI locked |
I was able to lock the DRMI this afternoon. All the optical levers have been centered. |
863
|
Wed Aug 20 17:02:01 2008 |
Sharon | Update | | More FIR to IIR |
I tested another method for converting from FIR to IIR other than the 2 mentioned in post 841.
I got this one from Yoichi, called poles fitting, you can read about it more if you want at: http://www.rssd.esa.int/SP/LISAPATHFINDER/docs/Data_Analysis/DA_Six/Heinzel.pdf.
Seems it's not doing much good for us though.
I am attaching a PDF file with the plots, which have N=50,100,600,1000, respectivaly. |
864
|
Wed Aug 20 18:09:48 2008 |
Yoichi | Update | IOO | MC still unlocks |
Being suspicious of FSS PC path as the culprit of the MC unlocks, I opened the FSS box and connected a probe to the TP7,
which is a test point in the PC path (before high voltage amplifier).
The signal is routed to an unused fast DAQ channel in the IOO rack. It is named C1:IOO-MC_TMP1 and recorded by the frame
builder. You can use this channel as a generic test DAQ channel later.
By looking at the attachment, the PC path (C1:IOO-MC_TMP1) goes crazy at the same time as other channels. So probably
it is not the trigger for the MC unlock.
Then I noticed the WFS signals drift away just before the unlock as shown in the attached plot. So now the WFS is the
main suspect.
Rob tweaked MC1 pitch to center the WFS QPDs while the MC is not locked. It improved the shape of the MC reflection.
However, the sudden MC unlock still happens. We then lowered the WFS gain from 0.5 to 0.3. Did not change the situation.
It looks like the MC length loop starts oscillating after the WFS signals drift away.
We will measure the WFS and MC OPLTF to see the stability of the loops tomorrow.
|
865
|
Thu Aug 21 10:24:20 2008 |
steve | Configuration | SAFETY | laser safe mode condition |
The MOPA and PSL shutters are closed.
Manual beam blocks are in place.
Enclosure interlock is enabled.
No other high power laser is in operation.
We are in laser safe of operation for visiting students from Japan
NO safety glasses required
|
866
|
Thu Aug 21 16:28:59 2008 |
steve | Configuration | SAFETY | safety glasses required |
I just opened the MOPA shutter so PA is warming up.
High power beam path is cleared and laser safety glasses required. |
867
|
Thu Aug 21 17:55:14 2008 |
rana | HowTo | IOO | MC WFS DC Offsets |
I ran the McWFS_dc_offsets script to trim out the DC offsets on the MC WFS DC signals.
Rob says "who cares?" |
868
|
Thu Aug 21 18:13:24 2008 |
rana | Update | IOO | MC WFS Control signals not responsible for lock losses |
This is a 4 hour, second-trend of the MC WFS error and control signals.
There is no sign that the MC loses lock because of feedback signal saturations. |
869
|
Fri Aug 22 10:39:41 2008 |
Jenne | Update | SUS | Taking Free Swinging spectra of PRM, SRM, ITMX, BS |
I'm taking free swinging spectra of PRM, SRM, ITMX and BS, so I've turned off their watchdogs for now. I should be done around 11:15am, so I'll turn them back on then. |
870
|
Fri Aug 22 13:58:39 2008 |
Sharon | Summary | | Trend of the Wiener TF |
In order to understand if we really need an adaptive filter, I used old data of MC_L and the accelerometers and seismometer to see if the Wiener (ideal) TF between MC_L and the others really changes all the time.
Two tests I made:
- Compare the TF after different segments of time, starting from the same point. Meaning, measuring the TF after 5,10,15,20... minutes, looking when and if the TF stablizes (stops changing).
- Compare the TF between same-length segments, from different times. Meaning, comparing for example 2 segments of 10 minutes taken from different times.
Results:
- As you can see in the attached PDF, the changes start being minor after 200,000 data points, which correspont to 200,000/256 s, which is approximately 13 minutes.
If you look at the PDF file, it is arranged from shorter times to longer in the order of: 3, 6, 13, 26 and 39 minutes.
- As expected, the TF between different segmants of the same length is not completely the same. Again, you can look at the attached PDF.
Sorry the titles are the same. Each 2 consecutive pages represent the same length of segment in different times. The order of segment's lengths is: 3, 13, 26 and 39 minutes
How do I explain what's going on?
Since the Wiener filter finds the correlation matrix between the data and the noise signals, it will maintain some kind of familiar shape when we don't add a significant amount of unusual data. I am assuming that if I had looked at longer time periods, we could see a more significant change in the TF in time. When looking at different times, the average noise is likely to be different which can explain the change in the correlation matrix and the TF.
To sum up
I think we should give adaptive filtering a go. |
871
|
Fri Aug 22 16:06:29 2008 |
steve | Update | PEM | particle counter replaced, flowbenches & HEPAs checked |
MetOne #2 counter was swapped in (on the top of IOC, facing SW direction, at ~75 deg upwards)
with channel one size 0.3 micron and channel two size 1.0 micron.
Sampling time was reduced from 60s to 6 sec at 0.1 cf/min at 25 min rate.
This means that displayed number needs to be multiplied by x100 to get particles/cf/min
HEPA filters and flow benches were checked:
PSL enclosure closed, HEPA speed at 60% 0-0 particles on optical table NW corner
AP covered optical table 1,000 particles of 0.3micron and 10 of 1.0 micron at NE corner
Flow bench at SE 0-0 particle (p)
on the top of SP cover at SE corner 60,000 p of 0.3 micron and 530 p of 1.0 micron
Mobile HEPAs 10cm from output screen in the center 800 p of 0.3 micron and 0 p of 1 micron
These filters will be replaced.
Clean assembly room:
both flow benches 0-0 p for 0.3-1.0 micron
east side bench 520 p of 0.3 micron and 210 p of 1.0 micron
Large hood in baking room with fan on 1.7 million p of 0.3 micron
and 16,000 p of 1.0 micron
Pasadena air just outside of main entrance:
3 million p of 0.3 micron and 30,000 p of 1.0 micron
My desk 743,000 p of 0.3micron, 63,000 p of 0.5 micron and 5,500 p of 1.0 micron cf/min
NOTE: existing COCHECKLIST.adl PEM displays needs to be corrected so it shows the 10 fold increase
and change particle size on this screen to 0.3 micron |
872
|
Fri Aug 22 17:03:41 2008 |
Yoichi | Update | IOO | MC open loop TF |
I measured the open loop TF of the overall MC loop using the sum-amp A of the MC board.
I used the Agilent 4395A network analyzer and saved the data into a floppy disk. However, the data was corrupted when
I read it with my computer. I had the same problem before. The floppy is not reliable. Anyway, I have to re-measure the TF.
From what I remember, the UGF was around 25kHz and the phase margin was less than 15deg.
Above this frequency, the open loop gain was almost flat and had a small bump around 100kHz.
This bump has a gain margin of less than 4dB (the phase is more than 180deg delayed here).
So the MC is marginally stable and either decreasing or increasing the gain will make it unstable easily.
Probably, the broken FSS is responsible for this. We have to fix it.
During the measurement, I also found that the input connectors (IN1 and IN2) of the MC board are freaky.
These are TNC connectors directory mounted on the board. Gently touching the cables hooked up to those connectors
caused a large offset change in the output.
When Rana pulled the board out and pushed it in firmly, the strange behavior went away. Probably, the board was
not correctly inserted into the backplane.
This could have been the reason for the MC unlocks. |
873
|
Sat Aug 23 09:39:51 2008 |
rana, jenne | Update | PSL | PMC Survey |
Jenne, Rana
We scoped out the PMC situation yesterday.
Summary: Not broke. UGF ~ 500 Hz. Needs some electronics work (notches, boosts, LPFs)
Ever since we swapped out the PMC because of the broken PZT of the previous one, the UGF has been
limited to a low value. This is because the notches no longer match the mechanical resonant
frequencies of the body. The old one had a resonance at 31.3 kHz which we were notching using
the LC notch on the board as well as a dangling Pomona box in the HV line to the PZT. The one
has a resonance at ~14.5 kHz which we don't yet have a notch for. Jenne has all the real numbers and
will update this entry with them.
Todo:
- Implement the 4th order Grote low pass after the mixer.
- Replace the AD797 with an OP27.
- Change servo filter to have a boost (need DC gain)
- Make a 14.5 kHz notch for the bode mode.
- Put a 20 lb. gold-foil wrapped lead brick on the PMC.
Here's the link about the modified PMC board which we installed at LHO:
LHO PMC elog 2006 |
874
|
Mon Aug 25 10:07:35 2008 |
Jenne | Update | PSL | Numbers for the PMC servo board (Re: entry # 873) |
Jenne, Rana
These are the numbers that go along with Rana's entry #873:
The existing notch in the PMC servo is at 31.41kHz.
The power spectrum of the PMC has a peak at 14.683kHz when it is just sitting on the PSL table (no extra mass). When we put a pile of steel and aluminum (~20lbs) on top of the PMC, the body resonance moves to 14.622kHz, but is decreased by about 40 dB!
Rana has ordered a lead brick + foil that should arrive sometime this week. To complete the mechanical part of this installation, we need to extend the earthquake mounts around the PMC so that the lead brick can't fall off of the PMC onto the rest of the table. |
875
|
Mon Aug 25 10:23:53 2008 |
steve | HowTo | General | cable killer |
Rack 1Y7 double violation:
BNC cables left to be jammed by door
and see destroyed BNCs
RED fibers should be rerouted.
I placed protective obstacle in position
so the door can not be closed.
Please do not do this!
DNA analysis is in progress on your finger prints. |
876
|
Mon Aug 25 10:51:06 2008 |
steve | Update | PSL | psl headtemp is coming down |
The laser water cooler was overflowing this morning.
I removed 500 cc water from the chiller.
The 4 days plot shows clearly:
that the capacity of the chiller is depending on the water level.
Overflowing water is a heat load for the chiller, so laser head temp goes up. |
877
|
Mon Aug 25 11:43:55 2008 |
Yoichi | Frogs | IOO | MC REFL PD cable had been disconnected through out the weekend |
Most of my morning was wasted by the MC REFL PD cable, which was disconnected on the generic LSC PD interface board.
I know who did this. *ME*. When I pulled out the MC board, which is sitting next to the PD interface, on Friday, I must have
disconnected the PD cable accidentally. The connector of the PD cable (D-Sub) does not have screws to tighten and easily comes off.
I wrote this entry to warn other people of this potential problem. |
878
|
Mon Aug 25 12:13:49 2008 |
Jenne | Update | PSL | Broken PMC Servo Board |
I broke the PMC servo board (on accident).
I was trying to measure the resistance of the extra resistor that someone put between the board and the HV OUT connector, since this is part of an RC filter (where C is the capacitance of the PZT on the PMC) that I need to know the values of as part of my mission to make a 14.6kHz notch for the PMC body mode. The resistance is 63.6k. I had to pull the board to get in to measure this resistance.
This resistor between the board and the center pin of the panel-mount HV OUT connector made a rigid connection between the board and the panel. When I was putting the board back in, I must have strained this connection enough that it broke. We don't have any of the same kind of resistor here at the 40m, so I'm waiting until after lunch to go to Wilson house and see if they've got any. The IFO is down until I get this sorted out. |
879
|
Mon Aug 25 14:18:36 2008 |
Jenne | Update | PSL | PMC servo board is fixed |
The PMC servo board is back in place, all fixed up with a shiny new resistor. The PMC locks, and the MC locks (I'm not saying anything either way about how long the MC will stay locked, but it is locked for now). The resistor is connected to the connector using a short piece of wire, so this problem won't happen again, at least with this connector on this board. |
880
|
Mon Aug 25 14:42:09 2008 |
Eric | Configuration | Cameras | ETMX Digital Camera |
I changed the lens on the camera looking at the ETMX to a 16mm, 1:1.4 zoom lens. This is in preparation to measure a couple parameters that depend on the camera's position and angle, so please avoid repositioning it for a couple of days. |
881
|
Mon Aug 25 15:50:18 2008 |
rana | Summary | PEM | Ranger SS-1 |
The manual for the Ranger SS-1 seismometer can be found on line here:
ftp://ftp.kmi.com/pub/software_manuals/300190/300190nc.pdf
and now in our 40m PEM Wiki page:
Ranger_SS-1
To calibrate it, we use the formula from the manual:
R_x
G_L = G_0 * ------------ = 149 +/- 3 V/(m/s)
R_x + R_c
where
G_0 = 340 V/(m/s) (generator constant)
R_x = 4300 Ohms (external damping resistor in Pomona box)
R_c = 5500 Ohms (internal coil resistance)
Then we have a gain of 200 in the SR560 so that gets us to ~30000 V/(m/s).
And then there's a DAQ conversion factor of the usual 2^16 cts / 4 V.
so the calibration constant is
G = 488 counts / (micron/sec)
in the ~1-50 Hz band |
882
|
Mon Aug 25 17:45:34 2008 |
rana, josephb, rob | HowTo | PEM | Accelerometer range |
Joe shows us by jumping up ~15" in the control rom that the accelerometers are set with not enough gain.
Since this is taken around 5:30 in the evening, so we can take the nearby time series to represent what a
high noise level is. I recommend we up the gain using the ICS-110B .ini file. |
883
|
Mon Aug 25 21:15:23 2008 |
rana | Configuration | LSC | aux NPRO off |
Looks like no one has used the Lightwave NPRO on the AS table after Koji left, so I turned it off so that it can rest until Alberto does the X-arm measurements. |
884
|
Tue Aug 26 09:04:59 2008 |
rana | Configuration | PSL | PMC Servo Board: Out for Repairs |
I've started modifying our PMC board to bring it up to the 21st century - leave the screen alone or else you might zap something. |
885
|
Tue Aug 26 09:58:59 2008 |
steve | Omnistructure | COC | ETMX is #03 |
This is the picture of ETMX from the upper south west viewport |
886
|
Tue Aug 26 12:00:45 2008 |
Jenne | Summary | PEM | Transfer function of Ranger seismometer |
This finishes up the calibration that Rana started in elog # 881.
The calibration of the Ranger seismometer should also include:
2 zeros at 0 Hz
2 poles at 1.02 Hz
This comes from finding the transfer function between the mass's motion and the motion of the ground.
..
m * x = (x_G - x) * k + d(x_G - x) * b
dt
where
- m = mass
- x = displacement of the mass
- x_G = displacement of the ground
- k = spring constant
- b = damping constant
This gives
x w0^2 + i*w*w0/Q
---- = -----------------------
x_G w0^2 + i*w*w0/Q - w^2
where
- w0 = sqrt(k/m) = natural frequency of spring + mass
- w = frequency of ground motion
- Q = q-factor of spring + mass system = 1/2 for critically damped system
The readout of the system is proportional to
d (x - x_G) ( w0^2 + i*w*w0/Q ) . w^2 .
dt = ( ----------------------- - 1 ) * x_G = ----------------------- * x_G
( w0^2 + i*w*w0/Q - w^2 ) w0^2 + i*w*w0/Q - w^2
Since we read out the signal that is proportional to velocity, this is precisely the transfer function we're looking for. With w0 = 1.02 Hz and Q = 1/2 for the critically damped system, we have 2 zeros at 0 and 2 poles at 1.02. |
887
|
Tue Aug 26 15:06:16 2008 |
steve | Configuration | VAC | rga scan |
Pumpdown 66 PRM-maglev vac normal -day 11
short form: pd66PRM-m-d11 |
888
|
Tue Aug 26 18:19:16 2008 |
rana | Omnistructure | Electronics | Resistor Noise at the 40m |
As Stefan points out in his recent ISS ilog entries at LLO, Daniel Sigg recently wrote a
recommendation memo on resistor and capacitor choices: T070016.
While working on the PMC I have had to use leaded resistors and wondered about the noise. As it turns
out we have the RN series of 1/4 W resistors from Stackpole Electronics. The RN series are
metal film resistors (datasheet attached); metal film is what Sigg recommends for lowest flicker
noise.
So we are OK for using the Stackpole 1/4 W leaded resistors in low noise circuits. |
889
|
Tue Aug 26 19:07:37 2008 |
Yoichi | HowTo | Computers | Reading data from Agilent 4395A analyzer through GPIB from *Linux* machine |
I succeeded in reading data from Agilent 4395A analyzer, who's floppy is crappy, through GPIB from a Linux machine using
agilent 82357B USB-GPIB interface.
I installed the linux GPIB driver to one of the lab. laptops (the silver DELL one currently sitting on the 4395A analyzer).
I wrote an initialization script for the USB-GPIB interface and a small python script for reading data from the analyzer.
[Usage]
1. Connect the USB-GPIB interface to the laptop and the analyzer.
2. Run /usr/local/bin/initGPIB command (it takes about 10sec to complete).
3. Run /usr/local/bin/getgpibdata.py > data.txt to save data from the analyzer to a text file.
The data format is explained in the comments of getgpibdata.py
This method is way faster than the unreliable floppy. The data is transfered in a few sec.
I'm now writing a wiki page on this
http://lhocds.ligo-wa.caltech.edu:8000/40m/GPIB
I will install the same thing into the other DELL laptop soon.
Let me know if you have trouble with this. |
890
|
Wed Aug 27 10:55:35 2008 |
Yoichi | HowTo | Computers | Annoying behavior of the touch pads of the lab. laptops is fixed |
I was sick of the stupid touch pad behavior of the lab. laptops, i.e. firefox goes back and forth in the history when the cursor is moved.
It was caused by firefox mis-interpreting the horizontal scroll signal as back/forward command.
I stopped it by going to about:config in firefox and set mousewheel.horizscroll.withnokey.action to 0 and
mousewheel.horizscroll.withnokey.sysnumlines to true. |
891
|
Wed Aug 27 12:09:10 2008 |
Eric | Summary | Cameras | Weekly Summary |
I added a configuration file parser to the Snap code. This allows all command line parameters (like exposure time, etc.) to be saved in a file and loaded automatically. It also provides a method of loading parameters to transform a point from its location on the image to its location in actual space (loading these parameters on the command line would substantially clutter it). The code is now fully set-up to test servo-ing one of the mirrors again, and I will test this as soon as the PMC board stops being broken and I can lock the X-arm.
I also took an image of the OSEMs on ETMX in order to apply the rotation transform code in order to determine the parameters to pass to Snap. The results were alpha = 2.9505, beta = 0.0800, gamma = -2.4282, c = 0.4790. These results are reasonable but far from perfect. One of the biggest causes of error was in locating the OSEMs: it is difficult to determine where in the spot of light the OSEM actually is, and in one case, the center was hidden behind another piece of equipment. Nevertheless, the parameters are good enough to use in a test of the ability to servo, though it would probably be worth trying to improve them before using them for other purposes. The original and rotated images are attached.
I've begun working on calculations to figure out how much power loss can occur due to a given cavity misalignment or change in a mirror's radius of curvature from heating. The goal is to determine how well a camera can indirectly detect these power losses, since a misalignment produces a change in beam position and a change in radius of curvature produces a change in beam waist, both of which can be measured by the camera.
Joe and I hunted down the requisite equipment to amplify the photodiode at the output of the PMC, allowing us to turn the laser power down even more during a scan of the PMC, hopefully avoiding thermal effects. This measurement can be done once the PMC works again. |
892
|
Wed Aug 27 13:55:43 2008 |
rana,jenne | Update | PSL | PMC Servo Board |
Board is back in. PMC is locked.
Nominal gain is now 15 dB with brick. We need to do more studies:
- Find out why there is still 35 MHz signal at the error point. Order some low pass filters to cut off above 35 MHz.
- Explore brick + no-brick loop shapes and error spectra.
- Measure and set the OLG.
We've left the copper-wrapped lead brick installed to let it slowly conform to the glass better. |
893
|
Thu Aug 28 18:56:14 2008 |
rana | Configuration | PSL | beam block distorted |
There was a beam block after the Mach Zender. Who or what put this there?
The going to the MC now looks distorted as if someone has left something funny in the beam or maybe the new PMC has started to degrade??
Use the ELOG people...its good for you. |
894
|
Thu Aug 28 19:02:25 2008 |
rana, josephb, rob | Summary | Computers | big boot |
This afternoon Joe did something with an .ini file (look for his detailed elog entry) and the computers went bad.
RFM network screen not active - filter modules not working.
We went around and booted every machine as has been done before. The correct order for a memory corruption
fixing big boot is the following:
[1] RESET the RFM switches near the FB racks.
[2] Power cycle c1dcuepics.
[3] Power cycle all other crates with real time CPUs:
c1iscey, daqctrl, daqawg, c1susvme1, c1susvme2, c1sosvme, c1iovme, c1lsc, c1asc, & c1iscex
[4] Start up all FEs as described in Wiki.
[5] Burt restore everyone (losepics, iscepics, assepics, omcepics?)
|
895
|
Fri Aug 29 02:40:43 2008 |
rana,jenne | Update | PSL | PMC Servo Board |
Quote: | Board is back in. PMC is locked.
|
This entry has details about the low pass filter after the PMC mixer. This filter has a few purposes:
1] Remove the beat signal (at 2*f_mod) between the PD RF signal at f_mod and the LO signal at f_mod.
2] Remove the beat signal (at f_mod) between the PD RF signal at 2*f_mod (which comes from the
beating of the upper and lower RF sidebands) and the LO signal at f_mod.
3] Remove other RF signals from non-ideal behavior of the LO drive signal and distortion in the RF PD pre-amp.
So its important to have a very good rejection at 35 MHz and higher. I used the Hartmut LC network design which is
installed on H1, H2, & L1. Since there is a high gain in the audio amps right after the mixer we have to get rid of
the RF or else we'll get slew rate limited or otherwise rectified downconversion of the RF signal into our audio band.
Of course, what everyone immediately realizes from the above 3 points, is that this filter can't protect the PMC
noise performance from homodyne mixing (e.g. 2*f_mod in the LO and 2*f_mod in the RF PD). To get around that, we're
ordering some filters from Mini-Circuits to remove the 2f from those signals by ~30 dB. As long as we install
the same filters on the RF and LO legs, there should be no significant phase shift in the demodulated signal.
The attached 2 page PDF shows the calculated before and after TFs of this filter. The 2 attached .m files
calculate the TF's and have ascii art which shows how the filter works.
Here's a comparison of the attenuation (in dB) of 2 candidate Mini-circuits filters:
f(MHz) | SLP-30 | SLP-50
|
31 | 0.5 | 0.4
|
35 | 1.3 | 0.4
|
38 | 6.1 | 0.4
|
40 | 10.8 | 0.42
|
61 | 46.3 | 14.8
|
71 | 60 | 29
|
91 | 76.9 | 48
|
107 | 80 | 60
|
We don't have tabulated data at the same frequencies for both filters so I just made up some of the points by eye-balling the
plots from the catalog - but you get the idea: we can get away with using the SLP-30 at 35 MHz since it only attenuates the
signals by ~1.5 dB. So if someone can find 4 of these then Steve doesn't have to order any from Mini-Circuits. |
896
|
Fri Aug 29 10:20:32 2008 |
Yoichi | Configuration | PSL | beam block distorted |
Quote: | There was a beam block after the Mach Zender. Who or what put this there?
The going to the MC now looks distorted as if someone has left something funny in the beam or maybe the new PMC has started to degrade??
Use the ELOG people...its good for you. |
I put the block. I was frequently reaching to the FSS box to change the test point probes. I put the block to protect my hands/clothes from being burnt accidentally. |
897
|
Fri Aug 29 11:01:49 2008 |
josephb | Configuration | Computers | Attempt to change a channel gain in ICS-110B |
As noted earlier by Rana, I was playing around with the /cvs/cds/caltech/chans/daq/C1IOOF.ini file with help from Rob. I had made a backup before hand and saved it as C1IOOF.ini.Aug-28-2008. (I have since been informed that C1IOOF.ini.082808 would have been prefered as a name).
We had been trying to up the gain in the C1: PSL-ISS_INMONPD_F in order to do a very low power PMC sweep, in an attempt to get clean modes for fitting. Initially we pressed the reconfig button on the C0DAQ_DETAIL screen, but all that seemed to do was change the Config File CRC. We proceeded to reboot fb40m remotely. However, any change to the ini file (even an extra space at the end of the file) caused a 0x2000 status for C1IOVME16k on the C0DAQ_DETAIL screen. At the time I presumed it was comparing the CRC of the ini-file to something else.
Digging around on in Alex's webspace at http://www.ligo.caltech.edu/~aivanov/ , I found the NDS Access page, which indicated that 0x2000 was a conflict between the front-end and frame builder .ini files.
"There is also status bit 0x2000 which gets added when the DCU configuration is different in front-end and frame builder. That is you can change and .ini file an then reload DAQ configuration with Epics button, which reconfigures the front-end, but leaves frame builders with invalid old configuration. They will detect this change and set the status to 0x2000 to indicate this condition. You will have to restart frame builders to pick up new .ini file and set status back to zero for the affected DCU."
It was when I was going to try reseting the c1iovme via the C0DAQ_RFMNETOWRK medm screen that we realized the EPICS controls were not responding properly. The .ini file was returned to its original form, and mass reboots commenced. |
898
|
Fri Aug 29 11:05:11 2008 |
josephb | Summary | Computers | c1asc was down this morning |
I had to manually reboot c1asc this morning, as for some unknown reason its status was red, and the fiber lights on the board were status:red, sig det:amber, own data: nothing. Shut the crate down, turned it back on, heard a beep, then followed wiki reboot instructions. Seems to be working now. |
899
|
Fri Aug 29 12:41:26 2008 |
josephb, Eric | Configuration | Computers | More front ends moved to new network |
Used Cat6 cables to finish moving all the front ends in 1Y4 and 1Y5 over to the new GigE network switches, specifically to the switch in 1Y6. This included the ones labeled c1susvme2, c1sosvme, and c1dscl1epics0. |
900
|
Fri Aug 29 12:43:44 2008 |
josephb | Summary | Computers | c1susvme1 down |
Around noon today, c1susvme was having problems. The C0DAQ_RFMNETWORK light was red. The status light was off, the sig det light was amber and the own data light was green. I could also ssh in, but could not not run startup. I switched off the watchdogs for c1susvme2 (the watchdogs for c1susvme1 had already been tripped), and manually power cycled the crate.
However, when c1susvme1 when it came back up it had not mounted the usual cvs/cds/ directories. c1susvme2 did however. c1susvme1 has been on the new network for awhile, while c1susvme2 was switch over today. So apparently switching networks doesn't help this particular problem.
I did a remote reboot of c1susvme1, and it came up with the correct files mounted. Both machines ran their approriate startup.cmd files and are currently green. |
901
|
Fri Aug 29 15:01:45 2008 |
steve | Update | PSL | MOPA_HTEMP in increasing |
The laser chiller temp is 21.9C ( it should be 20.0C )
Control room temp 73F ok, no obvious block
Ops, there is a piece of paper blocking the intake of the chiller
This is a four day plot. The paper was blocking the air flow all day. |
902
|
Fri Aug 29 16:35:18 2008 |
Yoichi | Configuration | PSL | beam block distorted |
Quote: | There was a beam block after the Mach Zender. Who or what put this there?
The going to the MC now looks distorted as if someone has left something funny in the beam or maybe the new PMC has started to degrade??
Use the ELOG people...its good for you. |
The apparent distortion of the MC refl. was caused by mis-alignment of the MC mirrors.
Because the MC1 was mis-aligned, the reflected light was clipped by a steering mirror.
I restored the MC angle bias values from the conlog history and now the MC locks.
According to conlog, the MC alignment was changed at around 18:30 on Thursday PDT.
It could have been caused by the computer reboots. |
903
|
Fri Aug 29 17:39:25 2008 |
rana | Configuration | PSL | PMC: ADC Channels |
The attached PNG shows the PMC error and controls signals with no calibration.
There are 3 states:
DARK - RF input disabled & output blanked. This should be a measure of the ADC noise
(-10 dB) - This is with the gain slider down at 5 dB instead of the nominal 15 dB.
Looks like the Generic DAQ board whitening is good enough for these signal levels above ~1 Hz.
From the low and high gain spectra it also looks like the UGF is ~500 Hz with the gain at 15 dB. |
904
|
Fri Aug 29 18:24:48 2008 |
rana | HowTo | PSL | PMC: PZT Calibration |
I calibrated the PMC PZT at DC by using 'trianglewave' to drive the DC offset slider
and reading back PMC_PZT and PMC_TRANSPD_F (both are DC coupled DAQ channels).
The attached PDF illustrates the method: look at the voltage required to span 1 FSR and then divide.
PMC_cal (m/V) = (1064 nm)/2 / V_FSR The calibration for our PZT is therefore 10.4 nm/V.
The full scale (0-300 V) range is 3.1 microns.
From Jenne's elog entry we know that the series resistor to the PZT is 63.6 kOhms. The PZT is labeled as
having a capacitance of 279 nF. So the PMC drive's pole frequency is 1/2/pi/63.6e3/279e-9 = 9 Hz +/- 0.5 Hz.
The cable capacitance is ~20 pF/foot so its not significant for this.
The template file is Templates/PMC-PZTcal.xml.
Using the above calibrations, also plot the calibrated PMC ERR and PZT spectra. |
905
|
Fri Aug 29 22:57:48 2008 |
Yoichi | Update | PSL | FSS loop transfer functions |
I've been measuring a bunch of transfer functions of the FSS related stuffs.
There are a lot to be analyzed yet, but here I put one mystery I'm having now.
Maybe I'm missing something stupid, so your suggestions are welcome.
Here is a conceptual diagram of the FSS control board
TP3 TP4
^ ^
| |
RF PD -->--[Mixer]-----[Sum Amp]------>--[Common Gain]--->----[Fast Gain]----[Filter]--> NPRO PZT
^ | ^ | |
| V | V |
LO ---->------- TP1 IN TP2 -->---[Filter]--[High Volt. Amp.] --> Phase Corrector
What I did was first to measure a "normal" openloop transfer function of the FSS servo.
The FSS was operated in the normal gain settings, and a signal was injected from "IN" port.
The open loop gain was measured by TP1/TP2.
Now, I disconnected the BNC cable going to the phase corrector to disable the PC path and locked the ref. cav.
only using the PZT. This was done by reducing the "Common Gain" and "Fast Gain" by some 80dB.
Then I measured the open loop gain of this configuration. The UGF in this case was about 10kHz.
I also measured the gain difference between the "normal" and "PZT only" configurations by injecting
a signal from "IN" and measuring TP3/TP2 and TP4/TP3 with both configurations (The signal from the Mixer was
disconnected in this measurement).
The first attachment shows the normal open loop gain (purple) and the PZT only open loop gain scaled by the
gain difference (about 80dB). The scaled PZT open loop gain should represent the open loop gain of the PZT
path in the normal configuration. So I expected that, at low frequencies, the scaled PZT loop TF overlaps the normal
open loop TF.
However, it is actually much larger than the normal open loop gain.
When I scale the PZT only TF by -30dB, it looks like the attachment #2.
The PZT loop gain and the total open loop gain match nicely between 20kHz and 70kHz.
Closer look will show you that small structures (e.g. around 30kHz and 200kHz) of the two
TFs also overlap very well. I repeated measurements many times and those small structures are always there (the phase is
also consistently the same). So these are not random noise.
I don't know where this 30dB discrepancy comes from. Is it the PC path eating the PZT gain ?
I have measured many other TFs. I'm analyzing these.
Here is the TO DO list:
* Cavity response plot from AOM excitation measurements.
* Cavity optical gain plot.
* Reconstruct the open loop gain from the electric gain measurements and the optical gain above.
* Using a mixer and SR560(s), make a separate feedback circuit for the PZT lock. Then use the PC path
to measure the PC path response.
* See the response of the FSS board to large impulse/step inputs to find the cause of the PC path craziness.
etc ... |
906
|
Sat Aug 30 13:28:01 2008 |
rana | Configuration | PSL | PMC: List of changes |
This is a list of changes made to the PMC board while we had it out for modifying the notch:
- LC-LC 4th order low pass filter
- Replace the AD797 (U2) with an OP27. AD797's are bad - do not use them anywhere for any reason. The OP27 is slower and has a 3x worse input noise but doesn't compromise the bandwidth or noise performance of the PMC by any significant amount. The rule is: use OP27 everywhere unless you have a very good reason why not.
- There is no 'H1' jumper on board. R9 is 90.9 Ohms and R2=900 Ohms so that the U2 stage has a gain of 10.
- Cut a trace and inserted a 500 Ohm resistor between U2-pin6 and U5A-pin2 (the AD602). The AD602 has a 100 Ohm input impedance which cannot be driven without limiting by the AD797 or the OP27. The 500 Ohm resistor makes it a driveable load for low level signals which is all that should be there since its the error point of the servo. it also becomes a 6:1 voltage divider. Since the AD602 has a fixed output voltage noise of 100 nV/rHz, this will limit the noise performance if the VGA gain is less than 20 dB, but whatever.
- R11 7.87k -> 1.74k, R12 = 78.7k -> 700k. This increases the high frequency gain of that stage by 7.87/1.74 = 4.5 and lowers the low frequency pole from 2 to 0.2 Hz to give the PMC some more staying power at DC. The loop shape is now 1/f^2 in the 9-480 Hz band and so the phase dips enough to make it almost conditionally stable, but not quite.
- C26 changed from ??? + a 30 pF trim cap into a fixed NNN pF cap to set the notch frequency for the 14.5 kHz body mode that we measured. Once our brick configuration is more settled we can increase the Q of this notch from small to big.
- Grounded pin 5 of U14 & U15 (AD620). These have sometimes been used as "differential" drivers in LIGO by connecting this reference voltage pin to the remote ground of the next board. This has always lead to insidious oscillation and noise. This beauty also has an output noise of 100 nV/rHz. Just never use this chip if you can help it; we can make true differential drivers - we have the technology.
Of course, we didn't have a current version of a schematic sitting around so I printed out a Rev E schematic and marked it up with red pen. I'll post pictures later and put the schematic into the PSL schematics notebook. Would be useful to take the old schematic and update it in Acrobat so that we have something electronic. |
907
|
Mon Sep 1 04:34:00 2008 |
rana | Update | PSL | FSS loop transfer functions |
I started from 6th item in Yoichi's todo list.
1) Increased the setpoint of the thermostat next to the framebuilder from 73F to 79F. Its freezing over there
in the room with the drill press. Steve's illegal mercury thermometer is reading 19 C.
2) Looked the RFPD's output spectrum using the 20 dB coupled output from the coupler that's in-line.
The first attached PDF file (n.pdf) has several plots:
page 1: 0-500 MHz anomolous peaks at 138 & 181 MHz but nothing too crazy
page 2: 0-100 MHz 80 MHz peak is RF pickup from the VCO Driver - not on the light
page 3: 10-30 MHz totally nuts
page 4: 18-25 MHz that's just wrong
The RF spectrum should only have some action around 21.5 MHz and a little peak at 2x 21.5 MHz. All that extra
junk means that something is broken!
3) To see if I could rid of any of the 80 MHz signal or any of that other trash from 18-25 MHz, I wound the RF cable
around a large toroidal ferrite core. This should have given us many uH of inductance for any signals common to
both the center and shield of the cable with no effect on the differential RF signals. There was no effect.
4) Next went to look at the 21.5 MHz Crystal Oscillator Reference card (D980353...I bet you can't figure out how
this one works). These have the Mini-Circuits SMA 30 MHz low pass (SLP-30) filters on both the LO and EOM outputs.
FSSLO.PNG shows the waveform after 20 dB attenuation going into a scope terminated with 50 Ohms.
FSSLO-Spec.png shows the spectrum of this signal - its pretty distorted. Here's the levels
f (MHz) | before filter (dBm) | after filter (dBm)
---------------------------------------------------
21.5 | -12.8 -13.1
43 -24 -46
64.5 -50 < -80
86 -64 < -80
This would be OK after the filter, but the level is very low. Only 7dBm (accounting for my 20 dB att) !!
The FSS uses a JMS-1H mixer which needs, as everyone knows, a +17 dBm LO signal. Que lastima.
There seems to be something wrong already, but wait...
5) PC25.PNG shows the output signal going to the EOM from 0 - 25 MHz. The step that's visible there at
around 10 MHz is just something inherent to the analyzer (??). But see all that crap there down below
5 MHz ? That is NOT supposed to be there.
pc.pdf shows on the first page the comparison in EOM drive with 2 different slider values on the
RF AM adjust screen for the FSS. But page 2 is the punchline of this long entry: There is a bunch of
excess junk on the drive signal going to the FSS's phase modulator. The FSS is then trying to handle
this extra frequency noise and getting into trouble.
We have to fix this board. I have also ordered a few SBP-21.4 from mini-circuits (SMA bandpass around 21.4 MHz)
just in case. Another option is to just replace this thing with a Marconi and an RF amp.
|
908
|
Mon Sep 1 19:23:17 2008 |
Yoichi | Configuration | PSL | FSS on an auxiliary loop |
Summary: The FSS is now temporarily disabled. Naturally, the MC won't lock. I will fix it tomorrow morning.
Today, I did the 4th item of my TO DO list.
Using a mini-circuit mixer and two SR560s, I constructed an auxiliary servo loop for the reference cavity.
With this loop, I was able to lock the reference cavity without using the FSS box.
By locking the reference cavity with this auxiliary servo, I was able to measure the PC path transfer function.
I will post the analyzed results later.
I borrowed the PD RF and the LO signals from the main FSS loop by power splitters. Therefore, the gain of the main FSS loop
is now about 3dB low. I tried to compensate it by increasing the EOM modulation depth, but the PC path is still a bit noisy.
Probably the already too low LO power is now seriously low (the LO power cannot be changed from EPICS).
Because I did not want to leave the PC path with large output overnight (it will heat up the PA85, and might cause damage, though unlikely),
I disabled the FSS for now.
|
909
|
Tue Sep 2 07:58:34 2008 |
rana | Summary | PSL | FSS & PMC LO trends for 2 years |
The attached plot is a 2 year minute trend of the EPICS readback of the PMC & FSS LO Monitors (FSS_LODET & PMC_LODET).
Clearly the FSS LO has been dying for at least 2 years. The step up from 10 months
ago is probably when Rob removed a 3dB attenuator from in front of the box. |