ID |
Date |
Author |
Type |
Category |
Subject |
9454
|
Tue Dec 10 17:27:47 2013 |
Jenne | Update | Treasure | Baby oplev LQR designed loop |
I *finally* figured out how to bend Matlab to my will, and close a very simple oplev loop using LQR technology.
This is super, super simple, but it's a step in the right direction. There is no noise, just a simple pendulum with a resonant frequency of 0.75Hz, and a Q of 10. The LQR tries to keep the position of the pendulum at a minimum, and does not care at all about the velocity. You cannot (with Matlab's LQR, at least that I can find) make it care "0" about the control output, so it cares about the control output a factor of 1e-4 as much as the position.
Here are some plots:
The first plot has the open loop system (just the pendulum, no control at all), as well as the closed loop system (the pendulum under control).

Plot 2 is the open loop gain of the controller that the LQR designed.

Plots 3 and 4 are the step and impulse responses of the open loop (pendulum with no control), and closed loop (pendulum with feedback) systems.


The conclusion from the plots (if this were an interesting system) is that it doesn't take much to damp an ideal pendulum. The real conclusion here is that I think I now know how to use the Matlab LQR function, and can make a loop with some noise now. |
9455
|
Thu Dec 12 00:21:04 2013 |
Koji | Update | Green Locking | X end PDH box oscillation issue solved (Re: screwed up the end PDH box) |
What a such long pain we suffered.
After more than three years from Kiwamu's discovery, the PDH box 50kHz oscillation issue was finally solved.
This "weird peak at 50kHz" was caused by the oscillation of the voltage regulator (ON's MC7912).
As it imposed common noise almost everywhere, it screwed up transfer function measurements
like EricQ saw recently.
The negative voltage regulator (79XX) tends to get unstable than the positive counter parts (78XX).
The oscillation was removed by adding 22uF electrolytic capacitor between the output pin (pin3) and the ground pin (pin1) of MC7912.
This is indeed more than 20 times of the specification you can find in the data sheet. |
9456
|
Thu Dec 12 00:47:45 2013 |
Den | Update | LSC | locking activity |
Jenne, Den
Today we worked on PRM angular servos and Y-arm ALS stabilization.
In the current PRMI angular control configuration two servos simultaneously drive PRM - oplev and POP ASC. We considered 2 ways to redesign this topology:
- once lock is acquired, turn on POP ASC servo that corrects oplev error signal
- turn off PRM oplev and turn on POP ASC servo
The first option requires model rewiring so we started from the second one. We had to redesign POP ASC pitch and yaw servos for this because PRM TF has changed. Attached is servo OLTF.
This method worked out well and once PRMI is locked we turned off oplev servo with ramp of 0.5 sec and enable ASC POP servo with ramp of 1 sec.
Once PRMI was locked and ASC running we have turned off PRM angular local damping that presumably prevents us from bringing arms into resonance due to IR coupling to shadow sensors.
PRMI was stable using only ASC POP servo and we moved on to ALS. We found Y-arm beatnote and enabled control to ETMY.
Cavity was stabilized but not robust - we were loosing IR in a minute because green relocked to 01 mode with transmission equal to more than half of 00 mode. This is probably due to angle to length coupling of ETMY.
We were also loosing IMC during cavity stabilization. We made MCL servo and will tune it tomorrow looking at the arm spectrum as an OOL sensor. |
Attachment 1: POP_ASC.pdf
|
|
9457
|
Thu Dec 12 14:57:01 2013 |
Koji | Update | IOO | IMC servo inspection |
In order to accomplish CARM control with the PSL laser frequency, we use two actuators.
One is the longitudinal direction of one of the MC mirrors. The londitudinal motion of the MC induces
the laser frequency control via the MC servo. As we move the mirror, the range is sort of big,
but the BW is limited by the mechanical response.
The other is the additive offset path. We inject a signal to the additional input port of the MC.
The MC servo supresses this injection by giving the same amount but oppsite sign offset to
the error signal (before the addtion of the inputs). The bandwidth of this AO path is limited
by the bandwidth of the MC servo. Basically the BW of the AO path is about 1/10 of that of the MC servo.
In order to confirm the capability of the AO path as a frequency actuator, 1) OLTF of the MC servo
2) TF of the AO input to the servo error was measured.
Attachment 1 shows the openloop TF of the MC servo. The UGF seems just little bit higher than
100kHz. The OLTF is empirically modelled by LISO as seen in the figure.
Attachment 2 shows the TF from the additive input (In2) to the error monitor (MC Servo module Q error mon).
The gain setting of the MC servo box was: In1 +18dB, In2 0dB. The measured TF has arbitorary gain
due to the gain setting, the measuemrent data was multiplied by 4 to mach the DC value to the unity.
This is to compare the measurement with the prediction from the OLTF.
The AO path TF is expected to show the character of -G/(1+G) where G is the OLTF. In my case,
G = 0.75*OLTF showed the best maching. There might have been some misalignment of the MC
upon the AO path measurement as I found after the measurement.
From the plot , we can see that the response is flat up to 20kHz. Above that it rapidly raises.
This should be dealt with the CM servo filter as the bump may hit the unity gain. Since we have to use
strong roll off to avoid the bump, this will eat the phase margin at low frequency.
In the case that we don't like this bump:
This bump is caused by low phase mergin of the OLTF at 30~40kHz. If the total gain
is increased, the bump is reduced. Or, we can decrease the PZT loop gain in order to
reduce the dip at the crossover ferquency between the PZT and PC loops. In both cases,
the PC path suffers more actuation. We may need to think about the HV actuation option
for the PC (Apex PA85).
Well, let's see how the CM servo can handle this.
The key point here is that we have enough data to start the design of the CM servo. |
Attachment 1: OLTF_IMC.pdf
|
|
Attachment 2: AOTF_IMC.pdf
|
|
Attachment 3: 131209.zip
|
9458
|
Thu Dec 12 17:22:07 2013 |
Steve | Update | General | rack power supplies checked |
Instrument rack power supplies checked and labeled at present loads.
The vacuum rack Sorensen is running HOT! Their is only 0.3A load at 24V There is plenty of space around it.
It is alarming to me because all vacuum valve positions are controlled by this 24V |
Attachment 1: 1x1ps.jpg
|
|
Attachment 2: 1X5ps.jpg
|
|
Attachment 3: 1X9ps.jpg
|
|
Attachment 4: 1Y1ps.jpg
|
|
Attachment 5: 1Y4ps.jpg
|
|
Attachment 6: AuxLSCps.jpg
|
|
Attachment 7: AuxOmcSouthRackPs.jpg
|
|
Attachment 8: 1Y2.jpg
|
|
9459
|
Thu Dec 12 21:23:15 2013 |
ericq | Update | Green Locking | Better Xarm OLTF |
With the newly repaired PDH board, I spent some time with the x arm green PDH loop. I found it SO MUCH EASIER to measure the OLTF by injecting before the servo, instead of after it. (i.e. I added a swept sine from the SR785 to the mixer output (error signal) before the servo input). This is likely because the error signal is much flatter. I used a 10mV excitation across the whole frequency range (30-100kHz).
Here's the OLTF. I'm working on fitting it and breaking it up into its constituent TFs, then making a rudimentary noise budget.

|
9460
|
Thu Dec 12 21:30:52 2013 |
Jenne | Update | ASC | PRMI-relevant oplevs centered |
The ITM oplevs were pretty close to the edge of their ranges, and none of the oplevs have been centered in a while, so I centered ITMX, ITMY, BS, PRM after having done alignment (arms, then PRMI). |
9461
|
Thu Dec 12 22:12:17 2013 |
Koji | Update | Green Locking | Better Xarm OLTF |
OK, the next question will be "why the loop bandwidth is so miserable?"
In other words, what is preventing us to have the bandwidth of 20~30kHz?
Your breaking down will give us the answer. |
9462
|
Fri Dec 13 02:19:57 2013 |
Jenne | Update | LSC | locking activity |
[Jenne, Den]
Tonight we worked on tweaking up the PRCL new ASC, and then PRMI+1 arm locking. We were unable to get the Xarm to stay locked on a TEM00 mode for very long, and after an hour or two of using the PZTs to try to align the beam to the cavity, we gave up and just used Yarm green.
NB: We haven't done anything to MCL, although it is not in use. Den is still going to get around to elogging what servo shaping he changed on that last night.
I wrote a script that will handle the transitions between the new PRCL ASC and the PRM oplev and local damping. The script is accessible from the PRC ASC screen, and will detect when the PRMI is locked or not. When it is locked, it will turn down the PRM oplev gains and turn on the ASC, and then it will turn off the local shadow sensor damping for PRM pitch and yaw. When the PRMI unlocks, the script will turn off the ASC and restore oplev and local shadow sensor damping.
We saw that the bounce mode of the PRM was getting rung up with our new ASC, so we included a band stop in the ASC, and also turned on the triggering for the PRCL LSC FM6, which has the resonant gain for the bounce mode (as well as roll, and the stack mode). This made the PRMI spot very stable.
We then moved on to green arm locking. The Yarm is behaving perfectly nicely (as nice as it has been lately - it's alignment and mode matching could also use some work), but Xarm was giving us a bit of trouble. As always (since the PZTs were installed?), the mode matching isn't excellent for the green to the arm, so it can be hard to catch a TEM00 mode. Also, even if we did catch a good mode, it would often not stay locked for more than a few tens of seconds. We tried several alignment tweakings, and several different end laser temperatures (within the confines of seeing the beatnote under 100MHz), and didn't have a lot of success. It looks like Eric had the slow servo engaged for the Xend laser, so the temperature offset was something like +300,000, which seemed totally crazy. I turned that off, and found the beatnote somewhere around output of -10,300. So, I haven't gone to the end to look at the temperature, but it's going to be different than when Eric was taking measurements this afternoon. It seems like the main problem with the Xarm is poor mode matching - the maximized input pointing for TEM00, when you unlock and relock the cavity, is just as likely to give you a TEM_9_0 mode, as TEM00.
So, we gave up on the Xarm for the evening, and tried PRMI+1arm, with the new PRCL ASC. This was successful! The Yarm beatnote was around laser slow servo output of +4450. Beatnote at 46.0MHz, -26dBm. We found the IR resonance, moved off, locked the PRMI, transitioned to the new ASC, and brought the Yarm back to IR resonance. What we see is that the power fluctuations in the PRC are much smaller than they were back around Halloween (elog 9338), however the arm power fluctuations still seem very, very large. This is certainly partly due to the fact that we haven't done a thorough Yarm alignment since before messing with the greens, so we will have drifted somewhat. Also, the ALS beatnote sensor isn't perfect, so won't be perfect at holding us near resonance.
Den is thinking about whether we can use the arm transmission QPD signals to feed back to the ETM ASC servos, to try to reduce the RIN in the arms. I feel like we should also see if this amount of power fluctuation can be explained by our ALS noise, because maybe we'll be fine once we transition to IR and turn off the ALS system. Attached is a plot showing that the arm's RIN is coherent with the spot motion seen by the transmission QPD, so we need to check the alignment of the cavity, as well as consider using the trans QPD in an ASC feedback loop.
Here is a plot of the PRC sideband power, as well as the Yarm transmission. The GPS time for this plot is approximately 1070963372.

|
Attachment 2: try_dc.pdf
|
|
9463
|
Fri Dec 13 02:30:22 2013 |
Koji | Update | LSC | locking activity |
According to the measurement by Eric, the X-arm green PDH UGF is too low. We still have some room to increase the gain.
The out of loop stability of the ALS for each arm should be measured everyday.
Otherwise we can't tell whether the arm is prepared for advanced locking activities or not.
We expect to see the arm stablity of ~50pm_rms for the Y arm and ~150pm_rms for the X arm. |
9464
|
Fri Dec 13 11:47:11 2013 |
Gabriele | Update | Green Locking | Better Xarm OLTF |
I'm not as good as a fit, but it seems that there is a loop delay of about 30 microseconds, looking at the high frequency phase. This might explain the limitation on the BW. Eric should be able to get the delay out of the fit with some care. |
9465
|
Fri Dec 13 13:28:07 2013 |
Den | Update | LSC | arm calibration template |
I have calibrated ETMX and ETMY actuators and added a template armSpectra.xml into /users/Templates directory.
Template shows control and error signals of both arms. Procedure is standard: calibrate control to meters and match error based on UGF measurement. XARM UGF: 200 Hz, YARM UGF 210 Hz.
Noise level at high frequencies (>100 Hz) for YARM is 3*10-15 and is factor of 3 better then for XARM. Servo gains are in the same ratio. I think there is less light on POX than on POY RF PD because I checked phase rotation and analog gain. I assume transimpedances are the same. |
Attachment 1: armsCal.pdf
|
|
9466
|
Fri Dec 13 13:45:50 2013 |
Koji | Update | CDS | MEDM/ADL: replace rectangle with specified objects |
rect_replace.py script was updated.
This sounds crazy but it was actually quite easy as I could use a free font data.
/opt/rtcds/caltech/c1/medm/c1lsc/master/generateLSCscreen/rect_replace.py
Usage:
cat C1LSC_OVERVIEW_ADC.adl | ./rect_replace.py > tmp.adl
Description:
The script takes stdin and spits the result to stdout. It parses a given ADL file. When a "rectangle" object
with Channel A with a string "REPLACE_XXXX", it replaces it with the objects predefined as "XXXX".
Now new type "CHAR" (i.e. REPLACE_CHAR) was added. This replaces the string in Channel B slot
into 5x7 dot matrix representation of the string with the specified color. The dot size is derived from the
height of the original rectangular object.
|
Attachment 1: screen_shot.png
|
|
9467
|
Fri Dec 13 16:34:20 2013 |
Steve | Update | VAC | PS will be replaced next week |
Quote: |
Instrument rack power supplies checked and labeled at present loads.
The vacuum rack Sorensen is running HOT! Their is only 0.3A load at 24V There is plenty of space around it.
It is alarming to me because all vacuum valve positions are controlled by this 24V
|
The temperature went down to room temp with temporary fan in the back. Voltage and current are stable.
Regardless, it will be replaced early next week. |
Attachment 1: hotPSvacRack.jpg
|
|
Attachment 2: fan1X8.jpg
|
|
9468
|
Fri Dec 13 18:03:00 2013 |
Den | Update | IOO | common mode servo |
Quote: |
Well, let's see how the CM servo can handle this.
The key point here is that we have enough data to start the design of the CM servo.
|
It seems to me that current design of the common mode servo is already fine. Attached plots show common mode open and closed loop transfer function.
Frequency response of the servo is taken from the document D040180. I assumed coupled cavity pole to be ~100 Hz.
The only question is if our EOM has enough range. Boost 2 increases noise injection by 10 dB in the frequency range 20-50 kHz. Boost 3 has even higher factor. |
Attachment 1: CM_OL.pdf
|
|
Attachment 2: CM_CL.pdf
|
|
9469
|
Fri Dec 13 19:33:56 2013 |
Den | Update | ASC | ETM X,Y QPDs |
I have modified/compiled/installed/restarted c1scx and c1scy models to include arm transmission QPDs in angular controls.
For initial test I have wired normalized QPD pitch and yaw outputs to ASC input of ETMs. This was done to keep the signals inside the model.
QPD signals are summed with ASS dither lines and control. So do not forget to turn off QPD output before turning on dither alignment.
Medm screens were made and put to medm/c1sc{x,y}/master directory. Access from sitemap is QPDs -> ETM{ X,Y} QPD |
9470
|
Fri Dec 13 23:07:04 2013 |
Koji | Update | IOO | common mode servo |
Looks good.
Once the control cable (bakplane cable) is identified, we can install the module to the LSC analog rack.
We should be able to test the CM servo with either POX or POY and only one correspoding arm without modifying the servo TF.
Just for this test, we don't need to use MCL. |
9471
|
Sat Dec 14 02:51:47 2013 |
Den | Update | LSC | locking activity |
I had a look on x,y arms stabilization using ALS. Input green beam was misaligned and I was loosing 00 every few minutes. I vent on the floor and realigned green beams.
YARM alignemt was smooth - transmission increased from 0.4 to 0.85 with PSL shutter off.
XARM was tough. Steering mirrors did not have any derivatives when transmission power was 0.5. I walked the beam with piezos but got only 0.55. It seems that the input beam is mismatched to the cavity. When the transmission was 1 last time? Does anyone have a model of the xend table to compute mode matching?
Input green alignent was improved and I could keep arms stabilized for periods of ~30min - 1 hour. Still not forever.
I noticed that ALS_XARM and ALS_YARM servos have limiters of 6000 and control signal had high frequency components that were not rolled off as shown on the plot "ETMY_DRIVE". I have added a low pass filter that reduced RMS by factor of 5 and took 7 degrees of phase at UGF=150 Hz. Now margin is 33 degrees.
Then I excited ETMY longitudinally at 100 Hz and measured first and second harmonics of the YARM RIN. I got total DC offset of 0.3 nm. This means significant length coupling to RIN. First of all, "scan arm" script does not tune the offset very precise. I guess it looks at DC power, checks when cavity passes through symmetrical points of the resonance and takes the average. It is also useful to look at POX/POY and confirm that average is 0. Plot "ALS_RIN" shows comparison of YARM power fluctuations when it is locked using IR and stabilized using ALS. By manually correcting the offset I could reduce length coupling into RIN, coherence was ~0.1.
Cavity RMS motion also couples length to RIN. Plot "ALS_IR" shows YARM error signal. I also looked at POY signal (LSC-YARM_IN1) as an OOL sensor. At low frequencies POY sees only IMC length fluctuations converted to frequency. I have engaged MCL path and ALS error and LSC error signals overlaped. Cavity RMS motion is measured to be 200 pm. |
Attachment 1: ETMY_DRIVE.pdf
|
|
Attachment 2: ALS_RIN.pdf
|
|
Attachment 3: ALS_IR.pdf
|
|
9472
|
Sat Dec 14 11:56:54 2013 |
rana | Update | LSC | common mode servo |
Quote: |
It seems to me that current design of the common mode servo is already fine. Attached plots show common mode open and closed loop transfer function.
|
These seem like pretty terrible loop shapes. Can you give us a plot with the breakdown of several of the TFs and some .m file?
We should be able to estimate the noise coming out of the MC using the single arm and then make a guess for the CM loop gain requirement. There's no reason to keep the old Boost shapes; those were used in the old MC configuration which had a RefCav. In addition to minimizing the EOM range, we should also minimize the AO signal as Koji has pointed out. In practice, I've seen that using ~300 Hz of offset makes no harm with 4 kHz MC pole. |
9473
|
Sat Dec 14 13:46:54 2013 |
Den | Update | IOO | low bandwidth MCL loop |
Last time we designed MCL loop with UGF ~ 30 Hz and I think, it was hard to lock the arm because of large frequency noise injected to IFO.
This time I made a low bandwidth MCL loop with UGF=8 Hz. MCL error RMS is suppressed by factor of 10 and arms lock fine.
Attached plots show MCL OL, MCL error suppression and frequency noise injection to arms.
It is interesting that spectrum of arms increases below 1 Hz meaning that IMC sensing noise dominates in this range.
I did not include the loop into the IMC autolocker. I think it is necessary to turn it on only during day time activity and when beatnote is moving too much during arm stabilization. |
Attachment 1: MCL_OL.pdf
|
|
Attachment 2: MCL_ERR.pdf
|
|
Attachment 3: MCL_ARMS.pdf
|
|
Attachment 4: MCL_MEDM.png
|
|
9474
|
Sat Dec 14 14:21:46 2013 |
Den | Update | LSC | common mode servo |
Quote: |
These seem like pretty terrible loop shapes. Can you give us a plot with the breakdown of several of the TFs and some .m file?
|
Attached is matlab code that I used
% IMC OL
G = zpk(-2*pi*8964, 2*pi*[-10; -10; -10; -1000; -274000], db2mag(242.5)) * ...
tf([1 0.8*1.55e+05 3.1806e+10], 1);
% CARM PATH
CARM = G/(1+G);
% Common mode boosts
BOOST = zpk(-2*pi*4000, -2*pi*40, 1);
BOOST1 = zpk(-2*pi*20000, -2*pi*1000, 1);
BOOST2 = zpk(-2*pi*20000, -2*pi*1000, 1);
BOOST3 = zpk(-2*pi*4500, -2*pi*300, 1);
% Coupled cavity pole
CCPole = zpk([], -2*pi*100, 2*pi*100);
% Servo gain
Gain = db2mag(43);
% CARM OL with boosts
H = CARM * CCPole * BOOST * Gain;
H1 = H * BOOST1;
H2 = H1 * BOOST2;
H3 = H2 * BOOST3;
% Plot
% bode(H, H1, H2, H3, 2*pi*logspace(3, 5, 10000));
% bode(1/(1+H), 1/(1+H1), 1/(1+H2), 1/(1+H3), 2*pi*logspace(3, 5, 10000)); |
9475
|
Sun Dec 15 03:13:15 2013 |
Den | Update | LSC | attempt to reduce carm offset |
X,Y arms were stabilized using ALS and moved 5 nm from the resonance, PRMI was locked on sideband using REFL165 I&Q. POP angular servo was running; PRMI RIN was good (~2-3%)
During slow offset reduction I was sweeping MICH, PRCL and POP servos for instabilities due to possible optical gain variations, loops were fine.
I could reduce offset down to ~200 pm and then lost lock due to 60 Hz oscillations as shown on the attached plot "arm_offset"
Arms were stabilized with RMS comparable to the offset and power in arms was fluctuating from 3 to 45.
60 Hz line most probably comes from MICH. RMS is dominated by the power lines and is ~ 1 nm as seen on the plot "PRMI_CAL". I think this is too much but we need to do simulations. |
Attachment 1: ARM_OFFSET.pdf
|
|
Attachment 2: PRMI_CAL.pdf
|
|
9476
|
Sun Dec 15 20:37:41 2013 |
rana | Summary | Treasure | There is a Wagonga in the container that Steve does not believe in |
From Linda and Bram: |
Attachment 1: WagSu.pdf
|
|
Attachment 2: Wagonga.jpg
|
|
Attachment 3: MandehlingMedStrong.jpg
|
|
9477
|
Sun Dec 15 21:01:19 2013 |
Koji | Update | LSC | CM servo module installed |
Now the module is inserted at the 2nd crate from the top of 1Y2 (LSC analog rack). It is next to the DCPD whitening module.
I found the backplane cable for the Common Mode servo module.
I traced a cable form XY220 at the right most module on the crate where iscaux2 is living.
This cable was connected to the upper backplane connector.
Switching of the module is tested. All the switches and gain control are doing their job.
It was found that the offset and slow readback are not responding.
I checked the schematic of the CM servo module (D040180).
It seems that there is another cable for the offset and read back voltages. |
9478
|
Mon Dec 16 02:20:49 2013 |
Den | Update | LSC | MICH rms is improved |
When PRMI is locked on REFL 165 I&Q signals MICH rms is dominated by the 60 Hz line and harmonics. It comes from demodulation board.
To increase SNR ZFL-100 LN amplifier (+23.5dB) was installed in LSC analog rack. MICH 60 Hz and harmonics are improved as shown on the plot "mich_err"
I have also added a few resg at low frequencies. MICH rms is not 3*10-10. In Optickle I simulated power dependence in PRC and ARMs on MICH motion. Plot is attached.
I think we need to stabilize MICH even more, down to ~3*10-11 . We can think about increasing RF amplifier gain, modulation index and power on BB PD.
CARM offset reduction was a little better today due to improved MICH RMS. Power in arms increases up to 15 and than starts to oscillate up to 70 and then PRMI looses lock.
Tomorrow we need to discuss where to put RF amplifier. Current design has several drawbacks:
- DC power for the amplifier is wired from a custom (not rack based) +15V power supply that was already inside the lsc rack and used for other ZFL-100LN
- BNC cables are used because I could not find any long SMA cables
- we would like gain of ~40 dB instead of 23.5 dB
|
Attachment 1: MICH_ERR.pdf
|
|
Attachment 2: DC_power.pdf
|
|
Attachment 3: ARM_OFFSET.pdf
|
|
9479
|
Mon Dec 16 20:08:43 2013 |
Koji | Update | LSC | CM servo module installed |
I found another backplane cable for the CM servo module. It is plugged to the module now.
I can see that C1:LSC-CM_SLOW_MON is responding to C1:LSC-CM_REFL_OFFSET.
But C1:LSC-CM_SUM_MON and C1:LSC-CM_FAST_MON are not replated to the given offset.
I probably need to check the cross connects. |
9480
|
Tue Dec 17 02:10:29 2013 |
Den | Update | LSC | locking activity |
Koji, Den
Some results and conclusions from tonight:
PRC macroscopic length is detuned. We measured REFL phases in carrier and sideband configurations - they are different by ~45 degrees for both 11 and 55 MHz sidebands. Additional measurement with phase locked lasers is required.
We got stable lock of PRMI+2arms with CARM offset of ~200 pm. We think this is the point when we should transition to 1/sqrt(TR) signals. We plan to rewire LSC model and also test CM servo with 1 arm during the day.
POP ASC OL shape changes when we reduce CARM offset probably due to normalization by sum inside the PD. Servo gets almost useless when PRMI power fluctuates by a factor of few.
SMA cables were made and installed for the REFL165 RF amplifier in lsc rack. |
9481
|
Tue Dec 17 14:06:59 2013 |
rana | Update | LSC | New Broadband PD for POP 22/110 |
I looked at the BBPD design so that we could make a POP22/110. It looks like it will be easy (I hope).
The first attachment shows the schematic with the RF notch modified to handle 55 MHz. As long as the capacitor in this notch can be kept to below 20 pF, it doesn't degrade the noise so much,
The second attachment shows the TF and input referred noise. We ought to be able to get 20 pA/rHz at the input to the first RF amplifier.
The LISO files are in the svn under liso/examples/aLIGO_BBPD/,
Later, if we have to notch more than just 55 MHz, we can add a notch between the 2 RF amplifiers as Koji has done for the REFL165. |
Attachment 1: POP22110sch.pdf
|
|
Attachment 2: POP22110.pdf
|
|
9482
|
Tue Dec 17 20:59:23 2013 |
Jenne | Update | LSC | 1/sqrt(TR) signals added to frames |
I noticed that we have not been saving the 1/sqrt(TRX) and 1/sqrt(TRY) data, so I modified the c1lsc model and added them to the DAQ channels block. I restarted the c1lsc model, and the _DQ channels are now archived. |
9483
|
Tue Dec 17 21:28:36 2013 |
Jenne | Update | LSC | CM servo slow output digitized |
Den just plugged an output from the common mode board into an LSC whitening board (the spare channel that used to be called "PD_XXX_I" in the LSC model). I have modified the LSC model to reflect the new name of the new signal ("CM_SLOW"), and have added this channel to the LSC input matrix. Koji is, I believe, adding this channel to the LSC screen in the auxiliary error signals section. I am also adding the _OUT of the filter bank to the DAQ channels block. |
9484
|
Wed Dec 18 00:26:15 2013 |
Jenne | Update | LSC | Xend QPD schematic investigation |
I have looked at the photo of the Xend QPD from elog 9367, as well as the schematic for the board (D990272).
Things that will need swapping out:
- Thick film resistors in the signal path need to be changed to thin film.
- MAX333 needs to be replaced with MAX333A. The 333 has "ON Resistance" of 140-175 ohms, whereas the 333A has "ON Resistance" of 20-35 ohms.
- AD797 needs to be replaced by OPA140. The 797 is a low voltage noise op-amp, but for a diode we want low current noise. AD797 has 2pA/rtHz at 1kHz, whereas the OP140 has 0.8fA/rtHz at 1kHz (see Zach's elog 8125 re: OPA140).
I have ordered from digikey via techmart 10 each of the MAX333A's and the OPA140's. (4 per QPD times 2 QPDs plus 2 spares = 10). Both of these new chips have the same footprint and pinout as the part that they are replacing, so it'll be a fairly easy task.
Next up, I need to make a LISO model for the circuit for one of the quadrants, to see what shape it'll turn out to be. Part of this will include deciding what resistors and capacitors to put in the OPA140 gain stage.
Right now, the AD797s say on the schematic that the gain options are different by a factor of 5, but the actual QPD has a different resistor than is on the schematic, and there is also a capacitor in parallel with each resistor, so I need to just pull those out, and pick some values that make sense to me.
Rana and I have discussed ignoring the 2nd and 3rd gain switching options on each quadrant, as that is getting to be more fine control than we need.
Other things on the board:
- The 50 ohm resistors to ground for the "QPD_rtn" have all shorted. Rana says this is good, so leave it as-is.
- The positive input to the AD797's all have a 100 ohm resistor to ground, rather than just being connected to ground. Why is this??
For now, I will probably just work on the QPD head, and not the whitening board. For now, we can run with 1 stage of whitening, and if we need lower noise, we can revisit the whitening board (including replacing the thick film resistors with thin film).
When thinking about what gains I want on my gain stages, I want to have my full arm power (~700 TRX units) be ~20,000 counts from the ADC. So, I want my single arm power (1 TRX unit) to be ~30 counts from the ADC. This is not such a big number, so this may also require more thinking. |
9485
|
Wed Dec 18 03:29:48 2013 |
Den | Update | LSC | yarm locked on mc |
As a CM slow path test I locked free swinging yarm by actuating on MC length with bandwidth of 200 Hz. Crossover with AO is not stable so far.
I used xarm as an ool frequency noise sensor. MC2 violin mode is at 645 Hz, I have added a notch filter to LSC-MC2 bank. |
Attachment 1: MC_ARM.pdf
|
|
9486
|
Wed Dec 18 11:32:34 2013 |
rana | Update | LSC | Xend QPD schematic investigation |
Since we use the TransMon QPD for triggering the high/low gain switching we need to run with the whitening OFF during lock acquisition and the turn it on after we have the arms locked with ALS. This should be put into the up/down scripts. |
9487
|
Wed Dec 18 11:37:12 2013 |
Jenne | Update | LSC | POP22 and POP110 demod phases |
Somehow the POP22 and POP110 demod phases weren't correct anymore. I guess Den saw this after he changed the setup for the REFL165 PD at the LSC rack, but didn't elog it.
I went out to the LSC rack, and found that the power supply that is supplying the amplifiers for both POP22/110 and REFL165 was set to ~16V each channel. I put it back to 15V for each channel. I don't know what Den intended for the 165 amplifier (more volts is more gain), but the POP22/110 amplifier usually runs with 15V.
I also reset the POP22 and POP110 demod phases. Since I'm not able to lock PRMI on sideband this morning (why?!?!), I locked on the carrier, and moved the phases around until POP22 and POP110 were both maximally negative. The phases are/were:
|
OLD [deg] |
NEW [deg] |
POP22 |
107.2 |
-165.0 |
POP110 |
95.0 |
150.0 |
This is a ~60 degree change for both PDs.
I am not sure if Den ever checked the demod phase of REFL165 after he put in the new SMA cable (there's no mention of it in the elog!), so I'm going to check that to see if it helps get PRMI locking back. I know that Den had also been using REFL11 for PRMI locking, but the parameters he used for that aren't in the log either. |
9488
|
Wed Dec 18 13:34:03 2013 |
Steve | Update | General | LIGOX people |
40m crew and visitor Holger Muller from Berkeley. |
Attachment 1: 40m2013Dec.jpg
|
|
Attachment 2: 40mCup.jpg
|
|
9489
|
Wed Dec 18 15:35:48 2013 |
Steve | Update | PEM | excess seismic noise |
This is not a test. Life can be dangerous in the 40m Control Room. |
Attachment 1: seismicCar.jpg
|
|
9490
|
Wed Dec 18 17:28:50 2013 |
Gabriele | Summary | LSC | Estimate of the PRC length error |
Measurement
Looking back at what I did in april (see log #8411) I realized that it is possible to get an estimate of how much the PRC length is wrong looking at the splitting of the sideband resonant peak as visible in the POP_110_I signal. With the help of Jenne the PRMI was aligned and left swinging. The first plot shows a typical example of the peak splitting of 55MHz sidebands. This is much larger than what was observed in April.
When the sidebands resonate inside the PRC they get a differential dephasing given by
dPhi = 4*pi*f_mod/c * dL
where dL is the cavity length error with respect to the one that makes the sidebands perfectly resonant when the arms are not there. This is not exactly the error we are interested in, since we should take into account the shift from anti-resonance of the SBs in the arm cavities.
Nevertheless, I can measure the splitting of the peak in units of the peaks full width at half maximum (FWHM). I did this fitting few peaks with the sum of two Airy peaks. Here is an example of the result

The average splitting is 1.8 times the FWHM. Knowing the PRC finesse, one can determine the length error:
dL = c / (4 * f_mod * Finesse) * (dPhi / FWHM)
Assuming a finesse of 60, I get a length error of 4 cm.
To get another estimate, we kicked the PRM in order to get some almost linear sweeps of the PRC length. Here is one of the best results:

The distance between consecutive peaks is the free spectral range (FSR) of the PRC cavity. Again, I can measure the peak splitting in units of the FSR and determine the length error:
dL = c / (4 * f_mod) * (dPhi / FSR)
The result is again a length error of 4 cm.
Simulation
An error of 4 cm seems pretty big. Therefore I set up a quick simulation with MIST to check if this makes sense. Indeed, if I simulate a PRMI with the 40m parameters and move the PRC length from the optimal one, I get the following result for POP_110_I, which is consistent with the measurement.

Therefore, we can quite confidently assume that the PRC is off by 4 cm with respect to the position that would make the 55 MHz sideband resonant without arms. Unfortunately, it is not possible with this technique to infere the direction of the error.
|
Attachment 3: pop110_vs_dL.png
|
|
9491
|
Wed Dec 18 18:45:39 2013 |
Jenne | Update | LSC | REFL 165 demod phases |
I checked out the REFL165 demod phase, and it looks like it was okay. it was -20.9 degrees. I turned on my sensing matrix oscillators, and maximized the PRCL signal in the REFL165_I_ERR channel, and got a pretty good maximization at +155 degrees. I used this to lock the PRMI on sidebands, with MICH gain of +0.3, and PRCL gain of +0.1 .
Since this is working, I'm leaving the REFL 165 phase here, at +155 degrees, although this is almost exactly 180 degrees from what Den left it at, so I'm not sure why I was not able to lock with a demod phase of -20.9. (I tried all 4 permutations of signs, with gain values of the same magnitude (0.3 for MICH, 0.1 for PRCL), and wasn't able to lock. I'll try to figure this out tomorrow, but it was time for the meeting, then the IFO has been busy doing more important things the rest of the afternoon.
Plan for checking: Lock with demod phase of 155, measure TF to one of the other REFL diodes (11, 33 or 55), lock on that other REFL diode. Then, change the REFL 165 demod phase back to -20.9, and measure the transfer function again. Hopefully the answer is just that I was doing something dumb, and it works easily. This test/measurement should only take a few minutes, but it'll make me happier knowing that things still work as they should. |
9492
|
Thu Dec 19 03:29:34 2013 |
Den | Update | LSC | CM servo test using yarm is complete |
Koji, Den
Procedure:
- lock yarm on IR, wire POY to CM input
- transition arm to CM length path by actuating on IMC
- increase AO gain for a stable crossover
- engage CM boosts
Result:
- arm can be kept on resonance and even acquired on MC2
- stable length / AO crossover is achieved
- high bandwidth loop can not be engaged because POY signal is too noisy and EOM is running out of range
We spent some time tuning CM slow servo such that fast path would be stable in the AO gain range -32db -> 29dB (UGF=20kHz) when all boosts are turned off and common gain is 25dB. Current filters that we use for locking are not good enough - AO can not be engaged due to oscillations around 1kHz. This is clearly seen from slow path closed loop transfer function. I will attach servo shapes tomorrow.
Attached plot "EOM" shows EOM rms voltage while changing AO gain from -10dB to 4dB. For UGF of 20kHz we need AO gain of 29dB.
It seems we can start using CM servo for CARM offset but the sensor should be at least factor of 30 better than POY. Add another factor of 10 if we would like to use BOOST 2 and BOOST 3. |
Attachment 1: EOM.png
|
|
9493
|
Thu Dec 19 12:51:57 2013 |
Jenne | Summary | LSC | Estimate of the sign of the PRC length error |
My hunch is that the PRC is SHORT by a few cm, not long.
In my Optickle simulation, the sidebands are not perfectly co-resonating in the PRMI when the arms are not locked. See Fig 1, which is the fields in the PRMI using the design PRC length. If I add 5cm to the PRC length, I get Fig 2, where the peaks are about the same separation, but the upper and lower sidebands have swapped sides of the 0 mark. However, if I remove 5cm from the PRC length, I get Fig 3, where the peaks are much farther apart than in Fig 1. This case looks more similar to the data that Gabriele plotted in his elog entry, where the peaks are separated by at least a linewidth. This is not at all conclusive, but it's a guess for which direction we need to move. Obviously doing an actual measurement will be better.
My tummy feelings also agree with this simulation: When we flipped PR3 (the only optic change in the PRC since Gabriele and I measured the 55MHz peak separation in April), since the HR side of the optic is now at the back, we had to push the whole suspension cage forward to get the beam aligned to the Yarm. Conversely, however, transmitting through the glass substrate adds to the optical path length. So, my tummy feelings may be wrong.
Figure 1, PRC at design length, PRMI sweep:

Figure 2, PRC 5cm longer than design length:

Figure 3, PRC 5cm shorter than design length:

|
9494
|
Thu Dec 19 14:40:42 2013 |
Koji | Update | CDS | RFM Time over mitigation for c1mcs |
I worked on the mitigation of c1mcs time-over issue this afternoon.
The timing for the c1mcs is successfully reduced from >60us to 45us.
The previous models are svned in redoubt as follows:
MCS rev. 6696
RFM rev. 6697
IOO rev. 6698
What I changed was:
- Remove connection from ALS (on c1ioo) to MCS (on c1sus). This should be all done in LSC. (# of RFM IPC in MCS -1)
- MC2 trans QPD filters are moved from IOO to MCS to reduce the RFM channels in MCS.
Previously the signals for the 4 segments are sent. Now the processed siganls (pit/yaw/sum) are sent. (# of RFM IPC in IOO -1, MCS -1)
- WFS MC3 feedback channels are moved from MCS to RFM to distribute the RFM channels (# of RFM IPC in MCS -2, in RFM +2)
model prev. timing[us] current timing[us] diff in time[us] diff in ch#
c1mcs >60 45 -15 -4
c1rfm 47 53 + 6 +2
c1ioo 47 36 -11 -1
Revisions of the new models:
MCS rev. 6702
RFM rev. 6701
IOO rev. 6700 |
9495
|
Thu Dec 19 18:33:25 2013 |
Gabriele | Summary | LSC | Estimate of the sign of the PRC length error |
Maybe I'm getting confused, but I still believe there is no way to decide the direction from yesterday's measurement.
Let's say for example that the arm sideband detuning from antiresonance is equivalent to a PRC length change of +1cm away from the position of ideal resonance of the sidebands without arms. Then we can get a measured separation of the sidebands, without arms, corresponding to 5cm both if the PRC is off by +4cm or by -6cm... |
9496
|
Thu Dec 19 19:45:12 2013 |
ericq | Update | Green Locking | X-Arm Green PDH Loop Stuff |
With the fixed servo box, I remeasured the OLTF, the servo, and the low pass filter between the mixer output and servo input. Dividing the OLTF by the servo and LPF transfer functions should just leave the the [laser PZT->cavity->PD] transfer function, which should have the shape of the cavity pole plus any delay in the loop, up until the PZT is no longer linear / the measurement has bad SNR.
I'm missing a few pieces of the loop. While I know the PD gain in V/W, I don't know how much power is in the sideband, which affects the slope of the PDH error function. Also, I've found old ELOG posts mentioning either 1 or 5MHz/V being the NPRO PZT response, but am not sure how to determine what it actually is. These are essentially just scalars though, so finding the reason for low phase margin doesn't depend on them.
Here are the TFs I've measured ("residual" refers to OLTF/(servo*LPF)):

The teal "residual" TF presumably owes its shape to the cavity pole + the time delay around the loop. Messing around with the data, the shape fits very well to a real pole at 27kHz and a ~3usec delay. I have no real way to back that up as the unique truth behind it, however. Is there a good way to measure the delay? Without assuming any delay, the shape is best fit by a real pole at 26kHz and some funky complex zeros.
Another thing to look at is the CLG implied by the measurement of the OLTF, given by 1/(1-G). I plotted this quantity for the measured loop, and also for G/2 and 3G/2 to get an idea for how it changes as you turn the servo gain knob. I measured with the knob at 4.0. There seems to be quite a bit of gain peaking!

Also, I drew up a simple block diagram sort of thing to show how everything is connecting down at the green electronics rack at the end of the X arm (while totally glossing over the optical elements involved). This hopefully helps anyone who wants to inspect/take apart/massacre the setup.
 |
9497
|
Thu Dec 19 21:16:16 2013 |
Koji | Configuration | General | netgpibdata is working again now |
Now netgpibdata is working again.
Usage:
cd /cvs/cds/rtcds/caltech/c1/scripts/general/netgpibdata
./netgpibdata -i 192.168.113.108 -d AG4395A -a 10 -f meas01
./netgpibdata -i 192.168.113.105 -d SR785 -a 6 -f meas01
Jenne witnessed and certified that they were working fine.
Now no one can say "it does not work"!
These weeks I was annoyed by the fact that netgpibdata was messed up by dummies.
A terrible situation was found:
1. Someone pushed the factory reset of one of the wifi bridges (LINKSYS WET54G).
2. Someone gave wrong IPs to the bridges (192.168.1.* instead of 192.168.113.*)
3. Someone left a default IP to the bridges. This means the routers had the same IPs.
-------
I gave the IPs to the bridges. According lines of /etc/hosts in linux1 were updated.
192.168.113.230 WET54G1
192.168.113.231 WET54G2
All of the network settings are taped on the bridge now.
The reset switch of each bridge was covered by a tape so that dummies can't randomly push the button.
The command was tested with each device. |
9498
|
Fri Dec 20 00:16:39 2013 |
Koji | Summary | CDS | RCG parsing bug? |
A while ago, I noticed that the most significant bits of the LSC whitening DOs are not toggling.
I track this issue down and found what is happening. I need experts' help.
To illuminate the issue, terminators are connected to Bit15 of the Bit2Word blocks in the LSC model (attached screen shots).
The corresponding source file is found in c1lsc.c at the following location.
The last channels of the Bit2Word are connected to lsc_cm_slow (the filter module).
This is the source of the issue. This wrong assignment of the connections
can't be changed by connecting Go-From tags to the chennels.
/opt/rtcds/caltech/c1/rtbuild/src/fe/c1lsc/c1lsc.c
3881 // Bit2Word: LSC_cdsBit2Word1
3882{
3883double ins[16] = {
3884 lsc_as110_logicaloperator4,
3885 lsc_as110_logicaloperator1,
3886 lsc_refl11_logicaloperator4,
3887 lsc_refl11_logicaloperator1,
3888 lsc_pox11_logicaloperator4,
3889 lsc_pox11_logicaloperator1,
3890 lsc_poy11_logicaloperator4,
3891 lsc_poy11_logicaloperator1,
3892 lsc_refl33_logicaloperator4,
3893 lsc_refl33_logicaloperator1,
3894 lsc_pop22_logicaloperator4,
3895 lsc_pop22_logicaloperator1,
3896 lsc_pop110_logicaloperator4,
3897 lsc_pop110_logicaloperator1,
3898 lsc_as165_logicaloperator4,
3899 lsc_cm_slow
3900};
3901lsc_cdsbit2word1 = 0;
3902for (ii = 0; ii < 16; ii++)
3903{
3904if (ins[ii]) {
3905lsc_cdsbit2word1 += powers_of_2[ii];
3906}
3907}
3908}
3946 // Bit2Word: LSC_cdsBit2Word2
3947{
3948double ins[16] = {
3949 lsc_as55_logicaloperator4,
3950 lsc_as55_logicaloperator1,
3951 lsc_refl55_logicaloperator4,
3952 lsc_refl55_logicaloperator1,
3953 lsc_pop55_logicaloperator4,
3954 lsc_pop55_logicaloperator1,
3955 lsc_refl165_logicaloperator4,
3956 lsc_refl165_logicaloperator1,
3957 lsc_logicaloperator_cm_ctrl,
3958 ground,
3959 ground,
3960 lsc_logicaloperator_popdc,
3961 lsc_logicaloperator_poydc,
3962 lsc_logicaloperator_poxdc,
3963 lsc_logicaloperator_refldc,
3964 lsc_cm_slow
3965};
3966lsc_cdsbit2word2 = 0;
3967for (ii = 0; ii < 16; ii++)
3968{
3969if (ins[ii]) {
3970lsc_cdsbit2word2 += powers_of_2[ii];
3971}
3972}
3973}
|
Attachment 1: Bit2Word1.png
|
|
Attachment 2: Bit2Word2.png
|
|
9499
|
Fri Dec 20 01:24:11 2013 |
Den | Update | LSC | high bandwidth loop achieved for yarm |
Koji, Den
CM Servo with POY11 successfully engaged. UGF: ~15kHz.
Tonight we decided to repeat one arm locking using high-bandwidth CM servo. We low-passed AO signal to avoid saturations of the EOM. We tried different configurations that compromise between noise and loop phase margin and ended up with a pole at 30kHz. SR560 is used as a low-pass filter.
Another problem that we faced was big (~2.6V) electronic offset at the input of 40:4000 BOOST. Once engaged, cavity would be kicked out of lock. We calibrated this offset to be almost half linewidth of the cavity (~300pm). To avoid lock loss during engaging the boost we increased common mode gain to maximum (31 dB).
Measured OL is attached. UGF is 15kHz, phase margin is 60 degrees. We have also simulated evolution of loop shape during bringing AO path. Plot is attached.
The final procedure is
- set common gain up to 31dB, AO gain to 8dB, MC IN2 gain 10dB, CM offset 0.7V
- lock arm with CM slow path with bandwidth of 200 Hz
- enable AO path, gradually increase slow and fast gains by 12 dB
- enable boost
|
Attachment 1: CM_OL_meas.pdf
|
|
Attachment 2: cm_ol_sim.pdf
|
|
Attachment 3: CM_slow_fast_cross.pdf
|
|
9500
|
Fri Dec 20 03:31:07 2013 |
Koji | Update | LSC | lock acquisition path for the CM servo |
up/down scripts are to be made
(Offset Edit on Dec 20 10:38PM)
Configuration:
POY11QMon -> CM Servo In1 -> CM Servo -->Out1 -> ADC -> CM Slow FM -> LSC MC Servo FM -> ETMY(x1.0) -> DAC -> ETMY
|
-->Servo Out -> SR560 (DC, 1st order 30kHz LPF) -> MC In2
Lock acquisition path 1
Initial condition:
CM Slow FM:
CM Servo setting:
- In1 Gain 31dB, SW:OFF, Offset -1.880, Boost Off, Super Boost Off, AO +8dB
MC Servo setting:
Acquisition:
- Engage LSC
- LSC MC servo gain +0.1, FM7/FM10 (Trigger FM2 with 3sec delay)
- Turn on MC
Transition:
- Enable AO path (CM servo In1 SW:ON, MC servo In2 SW:ON)
- LSC MC gain +0.1 -> +0.2
- AO path gain 8dB->14dB
- LSC MC gain +0.2 -> +0.35
- AO path gain 14dB->18dB
- CM servo offset
-1.88 -2.7 -> 0.8 0.0 (gradually)
- Enable CM servo Boost
Lock acquisition path 2
Initial condition:
CM Slow FM:
CM Servo setting:
- In1 Gain 31dB, SW:OFF, Offset -1.880, Boost Off, Super Boost Off, AO +20dB
MC Servo setting:
Acquisition:
- Engage LSC
- LSC Yarm G=+0.25 FM4/5 (Trigger FM3/6/7/8)
Transition:
- Enable MC servo In2 (SW:ON)
- Set LSC MC gain +0.2 FM7/10
- Enable LSC MC (On)
- Enable CM servo In1 (SW:ON)
- Disable LSC Yarm (OFF)
- Change CM servo offset
-1.88 -> +0.700 -2.70 -> 0.0
- Enable CM servo Boost
- Turn on LSC CM FM2 (optional)
Transition to ETMY LSC to MCL
- After all of the transition: LSC output matrix ETMY (+1.00)
- LSC output matrix MC2 (-1.00)
- LSC output matrix ETMY (0.00)
|
9501
|
Fri Dec 20 03:34:40 2013 |
Koji | Update | LSC | high bandwidth loop achieved for yarm |
This too huge offset difference with/without "BOOST" switch should be checked. |
9502
|
Fri Dec 20 10:08:43 2013 |
Jamie | Configuration | General | netgpibdata is working again now |
Quote: |
Now netgpibdata is working again.
Usage:
cd /cvs/cds/rtcds/caltech/c1/scripts/general/netgpibdata
./netgpibdata -i 192.168.113.108 -d AG4395A -a 10 -f meas01
./netgpibdata -i 192.168.113.105 -d SR785 -a 6 -f meas01
|
Just wanted to point out that the correct "modern" path to this stuff is:
/opt/rtcds/caltech/c1/scripts/general/netgpibdata
This is, of course, the same directory, but under the correct "/opt/rtcds", instead of the old, incorrect "/cvs/cds". |
9503
|
Fri Dec 20 11:40:13 2013 |
Jamie | Summary | CDS | RCG parsing bug? |
I submitted a bug report for this:
https://bugzilla.ligo-wa.caltech.edu/bugzilla3/show_bug.cgi?id=553
However, given how old our RCG version is (2.5 vs. 2.8 current deployed at the sites) I don't think we're going to see any traction on this. Even if this is still a bug in 2.8, they'll only fix it in 2.8. There's no way they're going to make a bug fix release for 2.5.
We need to upgrade. |