40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 129 of 346  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  9701   Thu Mar 6 19:17:05 2014 manasaUpdateIOOMC calmed down

Quote:

The IMC has not been behaving well since this morning and totally not happy when Q was finishing his measurements. The WFS servo had large offsets in pitch. Looking back at the trend and using ezcaservo to restore the suspensions did not help.

I realigned the IMC and brought TRANS SUM to ~18000 and MCREFL to < 0.5. The spot positions are not very good; nearly 2 mm off in pitch on MC1 and MC3. But after the alignment of MC, the WFS servo offsets were below +/-20.

The MC has been locked stably with WFS servo ON for the last few hours.

P.S. I did not touch the WFS pointing or reset the WFS offsets.

MC remained locked with WFS enabled all through last night and this morning. Koji dropped by and looked at the MC. The MC WFS servo, though stable, was at the edge of becoming unstable. This was because I did not touch the WFS pointing on the QPDs yesterday after realigning. So I recentered the WFS, reset the WFS filterbank offsets and reenabled the servo.

I measured the spot positions on MC mirrors for reference.

Spot positions in mm (MC1,2,3 pit MC1,2,3 yaw): [1.405767579680834, 0.79369009503571208, 1.3220430681427462, -1.2937873599406551, -1.1704264340968924, -1.2518046122798692]

Attachment 1: MC_spots_Mar6.png
MC_spots_Mar6.png
  3373   Fri Aug 6 12:22:04 2010 JenneUpdateIOOMC data taking over the weekend

Nancy has the Mode Cleaner for her work for the night, and is going to leave the MC happy, locked, autolocker on, WFS enabled, the works, and write down in the elog the time that she's finished. After that, I'm taking MC/seismic data all weekend long.  During the weekend, if at all possible, please don't go into the IFO room, especially near the Mode Cleaner.  If you do need to go into the IFO room, please elog the time you went in, and the time you left so I can correlate it with my dataThis is actually important, so please stick a quick elog entry in if you even think about opening the doors to the IFO room. It is much appreciated. 

  3375   Fri Aug 6 12:44:29 2010 KojiUpdateIOOMC data taking over the weekend

Question:

Do you like to keep the WFS turned on?

This may change the transfer functions between the ground motion to the angle time by time,
and thus change the TF between the GND and the MCL.

Quote:

Nancy has the Mode Cleaner for her work for the night, and is going to leave the MC happy, locked, autolocker on, WFS enabled, the works, and write down in the elog the time that she's finished. After that, I'm taking MC/seismic data all weekend long.  During the weekend, if at all possible, please don't go into the IFO room, especially near the Mode Cleaner.  If you do need to go into the IFO room, please elog the time you went in, and the time you left so I can correlate it with my dataThis is actually important, so please stick a quick elog entry in if you even think about opening the doors to the IFO room. It is much appreciated. 

 

  10363   Mon Aug 11 21:03:48 2014 ericq, ranaSummaryIOOMC demod measurement

We measured the TF of the MC Demod board today.

We set the Marconi to +3dBm and drove the PD IN port of the demod board, starting at 29.5 MHz. Then we looked at the beat signal amplitude in the output of the demod board. So this is a transfer function but with mag only. Plots from Q below.

Rana took the demod board out and took pictures of it. Inside, the post mixer low pass is a SCLF-5 from mini-circuits. This has a lot of cutoff down low. Since the purpose of this filter is only to cutoff the 2f-1f and the 3f-2f products, we need to have a lot of attenuation at 29.5 MHz. One day, we may want to re-instate that notch for the (3*f1- f_MC) beat frequency, but for now we want stability.

So, I recommend that we (Steve) get 3 each of the SCLF-10 and SCLF-10.7 from Mini-Circuits Tuesday morning. Maybe we can put them into a spare board?

Also, we should probably remove the 140kHz:70kHz lead filter which is in the MC servo board. Its out of date. I think it would be fine for us to get a 7-15 kHz UGF for the CM servo and the MC can basically do that already. Mainly we want to fix the high frequency shape to get more stability.

After the measurements and photos, we had to reset the MCWFS offsets to get the WFS to not break the lock. Seems very sensitive to offsets. Hopefully Andres will give us a new Gouy phase telescope.

  10364   Mon Aug 11 22:07:31 2014 KojiSummaryIOOMC demod measurement

SCLF-5!? It's surprising as the cut off of the OLTF is just above 1Hz. cf this entry

This means that not the demod board but MC or FSS boards seem to have large attenuation above 1MHz.

In this situation, does SCLF-10/10.7 really help us?

  10365   Mon Aug 11 23:32:54 2014 ericqSummaryIOOMC demod measurement

Here's the magnitude plot of the board TF. As mentioned above, this was done with Marconi+Scope, so we were not able to get the phase of this transfer function. 

MCDemod.pdf

Oddly enough, the bump that I saw is not included in Minicircuit's data on the SCLF-5.

Attachment 2: demodLP.txt
# F(Hz) RMS(mV)
1035 38.6
2031 38.47
4031 38.47
8032 38.38
16030 38.10
32030 38.10
64030 38.16
128000 38.10
256000 38.22
... 12 more lines ...
  10879   Thu Jan 8 19:02:42 2015 JaxSummaryElectronicsMC demod modifications

Here's a summary of the changes made to the D990511 serial 115 (formerly known as REFL 33), as well as a short procedure. It needed tuning to 29.5MHz and also had some other issues that we found along the way. 

So here's a picture of it as built:

The changes made are:

1. U11 and U12 changed from 5MHz LP to 10 MHz LP filters.

2. Resistors R8 and R9 moved from their PCB locations to between pins 1 (signal) and 3 (ground) of U11 and U12, respectively. These were put in the wrong place for proper termination so it made sense to shift them while I was already replacing the filters.

Also, please note- whoever labeled the voltages on this board needed an extra cup of coffee that day. There are two separate 15V power supplies, one converted from 24V, one directly supplied. The directly supplied one is labeled 15A. This does NOT mean 15 AMPS.

Transfer functions:

Equipment: 4395A, Signal generator (29.5 MHz), two splitters, one mixer

You can't take the TF from PD in to I/Q out directly. Since this is a demod board, there's a demodulating (downconverting) mixer in the I and Q PD in paths. Negligible signal will get through without some signal applied to the L input of the mixer. In theory, this signal could be at DC, but there are blocking capacitors in the LO in paths. Therefore, you have to upconvert the signal you're using to probe the board's behavior before it hits the board.  Using the 4395A as a network analyzer, split the RF out. RFout1 goes to input R, RFout2 goes to the IF port of the mixer. Split the signal generator (SG). SG1 goes to LO in, SG2 goes to the L port of the mixer. The RF port of the mixer (your upconverted RFout2) goes to PD in, and the I/Q out goes back to the A/B port of the 4395A - at the same frequency as the input, thanks to the board's internal downconversion. 

Phase measurement:

Equipment: Signal generator (29.5 MHz), signal generator (29.501 MHz), oscilloscope

Much simpler: 29.5 MHz to the LO input (0 dBm), 29.501 MHz to the PD input (0 dBm), compare the phases of the I/Q outputs on the oscilloscope. There are four variable capacitors in the circuit that are not on the DCC revision of the board - C28-31. On the LO path, C28 tunes the I phase, C30 tunes the Q phase. On the PD path, C29 and 31 appear to be purely decorative - both are in parallel with each other on the PD in Q path, I'm guessing C29 was supposed to be on the PD in I path. Fortunately, C28 and C30 had enough dynamic range to tune the I/Q phase difference to 90 degrees.

Before tuning:

After tuning:

 

  4143   Wed Jan 12 17:22:47 2011 SureshConfigurationLockingMC demod phase adjusted to minimise the I output

[Koji, Suresh]

We wanted to check and make sure that the relative phase of the two inputs ( local oscillator and photodiode signal ) to the demod board is such that the Q output is maximised.   We displayed the I and  Q signals on the oscilloscope in XYmode with I along the X direction.  If Q is maximised (and therefore I is minimised) the oscillocope trace would be perfectly vertical since all the signal would be in Q and none in I. Initially we noted that the trace was slightly rotated to the CCW of the vertical and that a short cable was present in the PD input line.  Removing this rotated the trace CW and made it pretty much vertical.  The screen shot of the oscilloscope is below.

.TEK00000.PNG

  9524   Tue Jan 7 10:44:13 2014 SteveUpdateIOOMC drift

Quote:

 The trend shows a big jolt to the MC1/3 pointing this morning at 8:30.

Was anyone working anywhere near there today? There is no elog.

If not, we will have to put a 'no janitor' sign on all of the 40m doors permanently to prevent mops misaligning our interferometer.

 I was taking pictures at the AP table at the morning and ETMX optical table after noon. There was no activity on the IOO chamber.

 Look at the last 2 hours of  Rana's trend plot. MC1 and MC2 sensor voltage started increasing.

I think it was a drift action.

Attachment 1: 2dTrend.png
2dTrend.png
Attachment 2: driftNotKick.png
driftNotKick.png
  9525   Tue Jan 7 11:11:36 2014 ranaUpdateIOOMC drift

 

 NOT drift. The sudden steps are certainly the result of being kicked. The slow drift at the end of the day might be a slow strain relaxation.

It pays to be careful and not put too much weight or impulsive forces on the chambers or tables.

  1394   Thu Mar 12 15:57:53 2009 YoichiUpdateIOOMC drift is terrible
Yoichi, Osamu,

Last night's locking work was totally interrupted by the sabotage by the MC.

First, after I measured the RF_AM, the MC alignment was somehow shifted largely and the MC did not lock to TEM00 mode.
I only mis-aligned MC2 to measure the RF_AM, but the MC reflection beam was also shifted (looking at the WFS QPD), that means MC1 was mis-aligned somehow.
Moreover, even when the MC is not locked, i.e. no feedback to the mirrors, the OSEM values of the MC mirrors (all of them) drift a lot in 10min scale.
I was totally puzzled. So I rebooted c1iovme and c1sosvme. Then this strange drift of the OSEM values stopped.
Even though, the MC tended to lose lock within ten minutes because the WFS QPDs were not centered.
We did several iterations of re-centering and finally the MC started to stay locked happily. The MC reflection beam was symmetric.

Then this morning when I came in (to be honest, afternoon), the MC reflection looked asymmetric again. The WFS QPDs were mis-centered again.
The attached files show an 8-hour trend of various MC related signals.
There was a half-degree temperature change starting from around 11AM. Corresponding to that, the IOO-QPD signals drifted indicating that the PSL beam pointing
was shifted. The MZ PZT signal shows a similar trend, so the beam pointing may have been shifted by the MZ (not sure).
The MC WFS, transmission QPD signals show the same trend.
This is too bad.

Right now, the PSL beam pointing is monitored by the QPDs detecting the transmitted beam through the first mirror of the periscope.
This means even if we can track the beam pointing drift with the QPDs, we can't correct the beam pointing using the periscope mirrors.
I don't want to touch the MZ mirrors for this purpose.
I propose to put a pick-off mirror after the second mirror of the periscope to send light to the IOO-QPDs. This way, we can use the periscope
mirrors to restore the beam pointing screwed up by the MZ.
Attachment 1: MC_Drift-1.pdf
MC_Drift-1.pdf
Attachment 2: MC_Drift-2.pdf
MC_Drift-2.pdf
  1397   Thu Mar 12 19:11:27 2009 ranaUpdateIOOMC drift is terrible
Kakeru, Rana, Yoichi

We used the SUS DRIFT MON screen to set the MC biases such that the mirrors were returned to the old OSEM values.
To do this, we set the nominals and tolerances using the appropriate scripts in the mDV/extra/C1/ directory.

We then used the MC_ALIGN screen to set the angle bias sliders.

Then Kakeru and I went to the PSL table to the periscope magic and maximize the MC transmission. Kakeru seems to
have the careful Japanese alignment touch and I am hungry, so I am leaving him to optimize the power. After he
finishes he is going to align the beam to the WFS and turn the MC autolocker back on. The x-arm is locked on a
TEM00 mode so the MC alignment is maybe OK.
  1398   Thu Mar 12 20:59:04 2009 KakeruUpdateIOOMC drift is terrible
After Rana went for his dinner, I aligned periscope to make the MC output 3.2 (Attachment 1).

After that, to align WFS, I unlocked the MC, unlocked the MZ and decrease the beam power to WFS QPD, and re-centerd WFC beam.
I restored MZ and MC lock.
I enabled MC autolocker, and change C1:IOO-WFS_Gain_Slider from 0 to 0.02 to lock WFS.


Quote:
Kakeru, Rana, Yoichi

We used the SUS DRIFT MON screen to set the MC biases such that the mirrors were returned to the old OSEM values.
To do this, we set the nominals and tolerances using the appropriate scripts in the mDV/extra/C1/ directory.

We then used the MC_ALIGN screen to set the angle bias sliders.

Then Kakeru and I went to the PSL table to the periscope magic and maximize the MC transmission. Kakeru seems to
have the careful Japanese alignment touch and I am hungry, so I am leaving him to optimize the power. After he
finishes he is going to align the beam to the WFS and turn the MC autolocker back on. The x-arm is locked on a
TEM00 mode so the MC alignment is maybe OK.
Attachment 1: MCtrans090312.png
MCtrans090312.png
  13696   Wed Mar 21 15:52:45 2018 gautamUpdateIOOMC error point calibration

As discussed at the meeting, I decided to calibrate the MC error point into physical units of Hz/rtHz (a.k.a. the PDH discriminant). This is to facilitate the debugging of the hypothesized excess IMC sensing noise. I did this as follows.

  1. Trust the POX calibration that was last updated in Aug 2017.
  2. Hook up spare DAC channel (piped from LSC rack to 1X2) to IN2 of IMC CM board.
  3. Inject excitation into MC error point via "IN2" input of the common board. For an excitation of 30cts with the IN2 gain at -32dB, I was able to see a peak in the calibrated X arm control signal that was ~x10 above the nominal noise level around 150Hz without seeing any nonlinear coupling effects in the DTT spectrum (I'm assuming 150Hz is sufficiently above the UGF of the X arm locking loop such that no loop correction is necessary).
  4. Took a spectrum of the IMC error signal, teed off into the SR785 at the I output of the demod board with the same linewidth as the DTT spectrum.
  5. Confirmed that without any excitation,
  6. Did the math to make these two peaks line up. The resulting calibration is: 13kHz/Vrms.

Math details:

  • DTT peak height @ 150 Hz with Hanning window, 25 avgs = 1.97e-4 nm/rtHz (See Attachment #1).
  • X arm cavity length = 37.79m, using which the above number becomes 1.47 Hz/rtHz.
  • Peak height in SR785 spectrum with Hanning window, 25 avgs = 1.13e-4 Vrms/rtHz (See Attachment #2).
  • Dividing, we get 13kHz/Vrms.

Using this, I can now make up a noise budget of sorts for the IMC sensing.


gautam 20180327 4.30pm: I re-checked the PDH error signal calibration using the oscilloscope method. Attachment #3 shows the PDH I and Q error signals and also the output of the RF monitor port, during a TEM00 flash. This attachment should be compared to Attachment #2 of elog 12822, and the answer lines up quite well. From my Finesse model of the IMC, I calculated that the x-axis of the PDH horn-to-horn is ~12.3kHz. Comparing to the top row of Attachment #3, I get a PDH error signal calibration of ~12.4kHz/Vrms, which lines up well with the number quoted above. So I trust my calibration, and hence, the y-axis of my noise budgets in reply to this elog.

Attachment 1: IMC_PDHdisc_20180321.pdf
IMC_PDHdisc_20180321.pdf
Attachment 2: IMC_PDHdisc785_20180321.pdf
IMC_PDHdisc785_20180321.pdf
Attachment 3: IMC_oscope.pdf
IMC_oscope.pdf
  13697   Wed Mar 21 17:31:21 2018 gautamUpdateIOOMC error point calibration

I did a preliminary noise budget of the transmitted frequency noise of the IMC. Attachment #1 shows the NB. I'm going to use this opportunity to revisit my IMC modeling. Some notes:

  1. The blue, green and red traces are from my measurement of the voltage noise of the demod board with LO driven by Marconi, RF input terminated, measured using the FET preamp + SR785, and calibrated into Hz/rtHz using the number from the immediate preceeding entry.
  2. The grey trace is measured by closing the PSL shutter, manually engaging the POX11 whitening, and looking at the calibrated POX. This sensing noise is ~100x higher than the IMC curves - but I think this makes sense as for the IMC, I am measuring directly at the output of the demod board, whereas for POX, the signal goes through the whole whitening infrastructure first.
  3. The purple trace is the calibrated X-arm control signal converted to Hz/rtHz.
  4. I've only showed the region up to ~1kHz as this is where the excess noise was seen in the original ALS study that precipitated this whole investigation.

Conclusion: From this study, assuming my PDH discriminant calibration was correct, looks like IMC demod / POX11 demod electronics noises are not to blame (this surprises me since there were apparently so many things wrong on the demod board, and yet that wasn't the worst thing in the IMC chain it would seem frown). The POX11 photodiode "dark" noise is also not the problem I think, given the grey curve. Next curve to go on here is the demod board noise with the PSL shutter closed but the IMC REFL PD connected to the RF input (or maybe even better, have light on the PD, but macroscopically misalign MC2 so there is no 29.5MHz PDH signal), just to make sure there isn't anything funky going on there...

Quote:
 

Using this, I can now make up a noise budget of sorts for the IMC sensing.

 

Attachment 1: IMC_RF_noise_calib.pdf
IMC_RF_noise_calib.pdf
  10784   Thu Dec 11 18:00:43 2014 ericqUpdateComputer Scripts / ProgramsMC error signal monitoring

The other day, I hooked up the agilent analyzer to OUT2 of the MC board, which is currently set to output the MC refl error signal.  I've written a GPIB-based program that continuously polls the analyzer, and plots the live spectrum, an exponentially weighted running mean, and the first measured spectrum. 

The intended use case is to see if the FSS or MC loops are going crazy when we're locking. Sometimes the GPIB interface hangs/loses its connection, and the script needs a restart.

The script lives in scripts/MC/MCerrmon

 

 

  8575   Tue May 14 20:30:29 2013 JamieSummaryIOOMC error spectrum at various FSS gain settings.

I used the Agilent 4395A and the GPIB network bridge to measure the MC error spectrum at the MC servo board.

I looked at various settings of the FSS Common and FAST gains.

Here is the spectrum of various Common gain settings, with a fixed FAST setting of 23.5:

f23.5.pdf

The peak at 34k is smallest at the largest Common gain setting of 13.0 (probably expected).  The other higher frequency peaks are higher, though, such as the ones at 24.7k, 29.6k, 34.5k, etc.:

f23.5z1.pdf

Here's a blow up of the peak at 1.06M, which peaks at about 9dB of common gain:

f23.5z2.pdf

 Here's the spectrum with a fixed Common gain of 10.5, and various FAST gains:

c10.5.pdf

and here's a zoom around that 1.06 MHz peak, which is smallest at a FAST gain of 23.5 dB:

c10.5z1.pdf

I'm not sure yet what this points to as the best gain settings.  We can of course explore more of the space.  I'm going to leave it at 13/23.5, which leaves the PC RMS at ~1.5 and the FAST Monitor at ~6.0.

If this does turn out to be a good setting we'll need to adjust some of the alarm levels.

Various settings:

MCS
  in1 gain: 15
  offset: 1.174
  boost enabled
  super boost: 2
  VCO gain: 25

FSS:
  input offset: -0.8537
  slow actuator: 0.6304

I include the python scripts I used to remotely control the AG4395 to take the measurements, and make the plots.

PS: I made some changes/improvements to the netgpib stuff that I'll cleanup and commit tomorrow.

 

Attachment 6: getdata
#!/usr/bin/env python

import os
import sys
import time
import numpy as np
sys.path.append('/opt/rtcds/caltech/c1/scripts/pylibs/')
import pyezcalib as ca
sys.path.append('/opt/rtcds/caltech/c1/scripts/general/netgpibdata/')
import netgpib
... 64 more lines ...
Attachment 7: plot
#!/usr/bin/env python

import os
#import numpy as np
from pylab import *

#name = sys.argv[1]

#atten = 10 # 10dB

... 31 more lines ...
  4145   Wed Jan 12 22:19:54 2011 KojiUpdateIOOMC flakiness solved

[Koji Suresh Kiwamu]

Suresh modified the MC board to have +5V offset at the output. (To be reported in the separated elog)

The MC lock has not been obtained at this point. An investigation revealed that there was very small (~5mVpp) PDH signal.

Kiwamu removed his triple resonant adapter and put the 50Ohm termination insted.
This restored the signal level normal although this changed the demodulation phase about 20deg.
We left the demodulation phase as it is because this is a temporary setup and the loss of the signal is not significant.

Now the MC is steadily locked with the single super boost.

  1081   Fri Oct 24 10:06:16 2008 YoichiConfigurationIOOMC gain and FSS gain changed
Following the measurements of MC and FSS loop gains, I modified mcup script to set the MC VCO gain to 2dB (it was -4dB before).
I also changed the normal value of the FSS common gain to 7dB. The open loop transfer functions posted in the previous two entries
were measured with those settings.
  1435   Fri Mar 27 02:40:06 2009 peteSummaryIOOMC glitch investigation

Yoichi, Pete

The MC loses lock due to glitches in the MC1 coils. 
We do not know which coil for sure, and we do not know if it is a problem going into the board, or a problem on the board. 
We suspect either the UL or LR coil bias circuits (Pete would bet on UL).  If you look at the bottom 4 plots in the attached file, you can see a relatively large 3 minute dip in the UL OSEM output, with a corresponding bump in the LR (and smaller dips in the other diagonal).  
These bumps do not show up in the VMONS which is why we are suspicious of the bias.
To test we are monitoring 4 points in test channels, for UL and UR, both going into the bias driver circuit, and coming out of the current buffer before going into the coils. 
 

We ran cable from the suspension rack to the IOO rack to record the signals with DAQ channels.

The test channels:

UL coil      C1:IOO-MC_DRUM1  (Caryn was using, we will replace when we are done)

UL input   C1:IOO-MC_TMP1 (Caryn was using, we will replace when we are done)

LR coil      C1:PEM-OSA_SPTEMP

LR input   C1:PEM-OSA_APTEMP

We will leave these overnight; we intend to remove them tomorrow or Monday.

We closed the PSL shutter and killed the MC autolocker.

Attachment 1: MC1_Drift.png
MC1_Drift.png
  1437   Fri Mar 27 15:05:42 2009 YoichiUpdateIOOMC glitch investigation
Attached plots are the result of the MC1 trend measurement.
See the attachment #1. The first two plots show the drift of the MC1 alignment as seen by the OSEMs. It is terrible. Other MC mirrors also drifted but the scale is smaller than the MC1.
From the VMon channels, you can see that the control voltages were quiet.
 
The monitor channels we added were:
 
MC_TMP1 = UL coil bias. Input to the coil driver board.
MC_DRUM1 = UL coil bias. Output of the current buffer.
OSA_APTEMP = LR coil bias. Input to the coil driver board.
OSA_SPTEMP = LR coil bias. Output of the current buffer.
 
The bias voltages show no drift except for a glitch around 7AM. This glitch did not show up in the SPTEMP channel (LR coil bias output). This was because the probe was connected to the coil side of the output resistor by mistake.
 
The second attachment shows a zoomed plot of MC1 OSEM signals along with the bias monitor channels (signals were appropriately scaled so that they all fit in +/-1).
There is no correlation between the OSEM signals and the bias voltages.
 
Since we were only monitoring UL and LR coils, I changed the monitor points as follows.
 
MC_TMP1 = LL coil bias. Output of the current buffer.
MC_DRUM1 = UL coil bias. Output of the current buffer.
OSA_APTEMP = UR coil bias. Output of the current buffer.
OSA_SPTEMP = LR coil bias. Output of the current buffer.
 
I will leave the MC unlocked for a while.

Quote:

Yoichi, Pete

The MC loses lock due to glitches in the MC1 coils. 
We do not know which coil for sure, and we do not know if it is a problem going into the board, or a problem on the board. 
We suspect either the UL or LR coil bias circuits (Pete would bet on UL).  If you look at the bottom 4 plots in the attached file, you can see a relatively large 3 minute dip in the UL OSEM output, with a corresponding bump in the LR (and smaller dips in the other diagonal).  
These bumps do not show up in the VMONS which is why we are suspicious of the bias.
To test we are monitoring 4 points in test channels, for UL and UR, both going into the bias driver circuit, and coming out of the current buffer before going into the coils. 
 

We ran cable from the suspension rack to the IOO rack to record the signals with DAQ channels.

The test channels:

UL coil      C1:IOO-MC_DRUM1  (Caryn was using, we will replace when we are done)

UL input   C1:IOO-MC_TMP1 (Caryn was using, we will replace when we are done)

LR coil      C1:PEM-OSA_SPTEMP

LR input   C1:PEM-OSA_APTEMP

We will leave these overnight; we intend to remove them tomorrow or Monday.

We closed the PSL shutter and killed the MC autolocker.

 

Attachment 1: MC1_Drift.pdf
MC1_Drift.pdf
Attachment 2: MC2_Drift.pdf
MC2_Drift.pdf
  1438   Fri Mar 27 17:52:16 2009 YoichiUpdateIOOMC glitch investigation
Per Rob's suggestion, I put the probes across the output resistors of the bias current buffers instead of measuring the output voltage with respect to the ground.
This way, we can measure the current flowing the resistor. The change was made around 17:30.

Quote:
Attached plots are the result of the MC1 trend measurement.
See the attachment #1. The first two plots show the drift of the MC1 alignment as seen by the OSEMs. It is terrible. Other MC mirrors also drifted but the scale is smaller than the MC1.
From the VMon channels, you can see that the control voltages were quiet.
 
The monitor channels we added were:
 
MC_TMP1 = UL coil bias. Input to the coil driver board.
MC_DRUM1 = UL coil bias. Output of the current buffer.
OSA_APTEMP = LR coil bias. Input to the coil driver board.
OSA_SPTEMP = LR coil bias. Output of the current buffer.
 
The bias voltages show no drift except for a glitch around 7AM. This glitch did not show up in the SPTEMP channel (LR coil bias output). This was because the probe was connected to the coil side of the output resistor by mistake.
 
The second attachment shows a zoomed plot of MC1 OSEM signals along with the bias monitor channels (signals were appropriately scaled so that they all fit in +/-1).
There is no correlation between the OSEM signals and the bias voltages.
 
Since we were only monitoring UL and LR coils, I changed the monitor points as follows.
 
MC_TMP1 = LL coil bias. Output of the current buffer.
MC_DRUM1 = UL coil bias. Output of the current buffer.
OSA_APTEMP = UR coil bias. Output of the current buffer.
OSA_SPTEMP = LR coil bias. Output of the current buffer.
 
I will leave the MC unlocked for a while.

 

 

 

  6899   Sun Jul 1 13:20:09 2012 yutaUpdateIOOMC in low power

I modified autolocker for MC in low power mode (/opt/rtcds/caltech/c1/scripts/MC/autolockMCmain40m_low_power) to make it work with the current directory structure.
autolockMCmain40m_low_power currently runs on op340m and it is in crontab.

34 * * * *  /opt/rtcds/caltech/c1/scripts/general/scripto_cron /opt/rtcds/caltech/c1/scripts/MC/autolockMCmain40m_low_power >/cvs/cds/caltech/logs/scripts/mclock.cronlog 2>&1


MC intra-cavity power:
  Currently, incident beam to the MC measured at PSL table is ~15 mW. Reflected power from MC (C1:IOO-MC_RFPD_DCMON) is 0.94 when MC unlocked, and is 0.088 when locked.
  That means, considering MC1/3 power transmission is 2000ppm (calculated finnesse=1570), intra-cavity power in MC is ~7 W.

  15 mW * (0.94-0.088)/0.94 / 2000ppm = 7 W

  We can increase the power by factor of ~2, if needed.


MC beam spot positions:

  I aligned MC to maximize transmission (C1:IOO-MC_TRANS_SUM_ERR), and measured the MC beam spot posisions in atm, low power.

# filename    MC1pit    MC2pit    MC3pit    MC1yaw    MC2yaw    MC3yaw    (spot positions in mm)
./dataMCdecenter/MCdecenter201206290135.dat    2.914584    4.240889    2.149244    -7.117336    -1.494540    4.955329    before vent
./dataMCdecenter/MCdecenter201207011253.dat    3.294659    3.416584    2.620511    -6.691800    -3.164084    4.806517    after vent

  They look the same within the error of the measurement, except for the spot positions on MC2, which we don't care.


Autolocker should be refined:
  To make autolockMCmain40m_low_power, I copied autolockMCmain40m and just changed

- lockthresh from 500 to 100
- use mcdown_low_power instead of mcdown
- use mcup_low_power instead of mcup

  The difference between mcdown_low_power and mcdown should be only

- ezcawrite C1:IOO-MC_REFL_GAIN 31 for lowpower, 9 for usual
- ezcawrite C1:IOO-MC_VCO_GAIN 10 for lowpower, -5 for usual

  The difference between mcup_low_power and mcup should be only

- ezcawrite C1:IOO-MC_REFL_GAIN 31 for lowpower, 12 for usual
- ezcawrite C1:IOO-MC_VCO_GAIN 31 for lowpower, 25 for usual

  Currently, they are not like that. Somebody good at shell scripts should combine them and make it into one code with an option something like usual/low-power.

  6910   Tue Jul 3 20:51:06 2012 yutaUpdateIOOMC in vacuum is back

MC came back to the state as it was before the vent.

What I did:
  1. Removed beam attenuating setup on PSL table(see elog #6892).

  2. Removed 100% reflection mirror before the MC reflection PD and put 10% BS back, so that we can have MC WFS. Also, I changed C1:IOO-MC_RFPD_DCMON.HOPR to 5.

  3. Removed autolockMCmain40m_low_power from crontab on op340m, and put autolockMCmain40m again.

  4. Aligned MC and ran /opt/rtcds/caltech/c1/scripts/MC/WFS/WFS_FilterBank_offsets to adjust WFS offsets.

  5. Measured beam spot positions. They looked same as before the vent.

# filename    MC1pit    MC2pit    MC3pit    MC1yaw    MC2yaw    MC3yaw    (spot positions in mm)
./dataMCdecenter/MCdecenter201206290135.dat    2.914584    4.240889    2.149244    -7.117336    -1.494540    4.955329    before vent
./dataMCdecenter/MCdecenter201207011253.dat    3.294659    3.416584    2.620511    -6.691800    -3.164084    4.806517    after vent
./dataMCdecenter/MCdecenter201207032009.dat    3.737099    3.994597    3.087857    -6.442053    -0.992543    4.714607    after pumping (now)

  6. I also turned on high voltage power supplies for input and output PZTs

  7. Below is captured Sensoray images of the current state.
ALL_1025408289.bmp


Next:
  I will go on to check if IFO works as it was before or not, but I think we should center MC beam spot positions and see if we can avoid clipping in the near future.

  2643   Fri Feb 26 11:48:36 2010 KojiUpdateGeneralMC incident beam shift

Last night I worked on the MC incident beam such that we can hit the center of the MC mirrors.

Steve and I checked the incident beam on MC1. We found the beam is ~5mm south.
This was not too critical but it is better to be realigned. I moved the steering mirror on the OMC
table (in vac). We kept the MC resonated. After the maximization of the resonance, I realigned the
MC1 and MC3 such that the resonance in dominated by TEM00.

Jenne, Kiwamu, and I then closed the light door on to the OMC/IMC.

I will make more detailed entry with photos in order to explain what and how I did.

  2899   Sat May 8 02:38:08 2010 KojiSummaryIOOMC incident power

As per Steve's request I checked the MC incident power as a function of time.

The output is negative: the lower voltage, the higher power.

Before I put the attenuator the incident power was 1.1W. It appear as -5V.

Now the output is -0.1V. This corresponds to 22mW.

 

Attachment 1: MC_input.png
MC_input.png
  5725   Fri Oct 21 16:06:12 2011 SureshUpdateComputer Scripts / ProgramsMC input matrices empty again

The MC suspensions were not damping and the reason was traced to the empty imput matrices in the suspension controls.  This has been an issue in the past as well when the sus machine is rebooted some of the burt restore does not populate these matrices.

I ran the burtgooey and restored c1mcs.snap file.  from a couple of hours ago.

 

 

  5367   Thu Sep 8 20:13:24 2011 kiwamuUpdateIOOMC is back to full power

[Suresh / Kiwamu]

 The attenuator was removed and now the MC is happily locked with the full power of 1.2 W.

 

(what we did)

 + replaced the perfect reflector, which was before the MCREFL_PD, by a 10% beam splitter like it used to be.

 + removed the attenuator (combination of HWP and PBS).

 + realigned the beam path on the AP table, including the MCREFL path and WFS path.

 + made the aperture of the MC2F camera narrower in order to avoid a saturation.

 + aligned the MC suspensions so that it resonates with the TEM00 mode.

 + put a ND filter on the AS camera

 

(notes)

C1:IOO-MC_RFPD_DCMON = 0.98 (locked)

C1:IOO-MC_TRANS_SUM = 17500 (locekd)

 

(next things to do)

 + measurement of the spot positions on each MC mirror.

 + centering of the beam spot by steering the input mirrors on the PSL table

  6292   Fri Feb 17 01:02:22 2012 kiwamuUpdateIOOMC is back to normal

[Koji / Kiwamu]

 The MC is now back to normal. The beam pointing to the interferometer is good.

There were two different issues :

  • A mechanical mount was in the MC WFS path.
  • There were some loose connections in the SUS rack

 

Slid have we the position of the mechanical mount. Nicely the WFS beam go through now.

And also I pushed all the connectors associated with the MC SUS OSEMs in the SUS rack.

After pushing the connectors, the MC1 OSEM readouts dramatically changed, which actually more confused us.

As shown in the 3 hours trend below, the OSEM readouts have changed a lot (shown in the middle of the plot with arrows). Some bumps after the steps correspond to our alignment efforts.

MCconnections.png

Quote from #6291

The MC became crazy again.

 

  5115   Thu Aug 4 01:49:08 2011 SureshUpdateIOOMC is locked

I measured the power transmitted from the PSL to the MC. It is 19mW.

The MC is now locked.  The MC Autolocker script cannot be used now since the tigger conditions are not met.  It has been disabled on the C1IOO-LOCK_MC screen.  The boost switch also is set to zero.  Increasing the boost results in MC unlocking. 

The C1:IOO-MC_RFPC_DCMON was going from 1.4 (MC Unlocked) to 0.66 (MC_locked).  I thought we ought to have a factor of ten drop in this since under high power conditions we used to have a drop of about 5.6 to 0.6.   So I adjusted the zig-zag at the end of the PSL table to improve the alignment.  It now goes from 1.4 to 0.13 when the MC is locked.   The lock is also much more stable now.  It still does not tolerate any boost though.

I checked to make sure that the beam centering on MC_REFL PD is optimal since I touched the zig-zag.  The RFPD output is now 0.7V (MC unlocked).  This matches well with the fact that we used to have 3.5V on it with the MC unlocked.  And we have cut the down the power incident on this by a factor of 5.  Because 1W -> 20mW at the PSL table  and 10% BS -> 100% Y1-...

 

 

  11739   Mon Nov 9 09:27:44 2015 SteveUpdatePSLMC is not happy

I just turned off the PSL enclousure lights.
 

Attachment 1: ioo8d.png
ioo8d.png
  3779   Mon Oct 25 23:10:06 2010 KojiUpdateIOOMC is now flashing

[Suresh / Koji]

The MC mirrors are aligned. Now the flashing of the resonances are visible on the MC2 CCD

although the modematching seemed pretty poor.


- The incident power was adjusted to be ~20mW by rotating HWP after the laser source.
The power before the window of the chamber was ~450mW. Where are those missing 1.5W?

- We checked the spot on the last two steering mirrors and the incident beam on MC1.
The beam was too much off from the center of the 1st steering mirror. It was also hitting 1cm north of the MC1.
We adjusted the steering mirrors such that the incident and reflected beams are symmetrically visible at the MC1 tower.

- The MC mirrors are aligned. We first tried to use only MC2 and MC3. And then we used MC1 too as the spot on the MC2 was too high.

- We saw some TEM00 flashes but with many other modes flashing. We checked the beam diameter on the PSL table and on the MC REFL.
The latter one looked twice large as the former one. We concluded the beam is diverging.

- We closed the tank and decided to work on the mode matching tomorrow.

  920   Thu Sep 4 07:46:10 2008 YoichiUpdateIOOMC is now happy
The MC has been locked for more than 12 hours continuously now !
Changes I made yesterday were:
(1) Removed the 20dB attenuator before the EOM.
(2) Reduced the Fast Gain from 21dB to 16dB, which made the PC to be a little bit more loaded (~0.6Vrms).

As Rana pointed out in the meeting, setting the Fast Gain a bit lower may have put the FSS in a stabler state.
Attachment 1: MC-lock.png
MC-lock.png
  3350   Mon Aug 2 21:52:57 2010 KojiUpdateIOOMC is running at the full power

[Nancy and Koji]

We restored the full power operation of the MC.

Restoration of the suspensions

  1. Found the suspension watch dogs are left turned off.
  2. Found c1susvme1/2 were not running.
  3. Launched the realtime processes on c1susvme1/2 and c1iscey
  4. Restored the watch dogs. The suspensions looked fine.

Preparations for the high power

  1. Put an ND2.0 before the MCT CCD. Confirmed the ND reflection is damped.
    MCT QPD is not necessary to be touched.

The high power operation of the MC / post lock adjustment

  1. Locked the MC under the autolocker being disabled.
  2. Adjusted the aperture on the MC2 face camera
  3. Adjusted the spot positions on the WFS QPDs
  4. Reverted the scripts to the high power ones
    (mcup / mcdown / autolockMCmain40m)
  5. Logged in to op340m and restarted autolockMCmain40m

The autolocker seems working correctly.

  3383   Sat Aug 7 11:07:44 2010 KojiConfigurationPSLMC kept locked / PMC control gain reduced to +13dB

Jenne asked us to keep th MC locked and let the seismometers happy through this weekend.
Note that the work at the control room and the desks are no problem as far as you are quiet.

Nancy told Jenne and me that she finished the work and reverted the WFS to the old state at 4:30AM.
She could not make the elog as it has been crashed.

MC and old MC WFS looks working as usual.

From 6:40AM to 9:40AM the oscillation of the PMC looks present.

At 10:30AM I reduced the gain of the PMC from +15dB to +13dB.

  952   Wed Sep 17 12:55:28 2008 robConfigurationIOOMC length
I measured the mode cleaner length last night:

SR620                Marconi
                     199178070
165981524            165981725
                     132785380
                      33196345


I did the division in Marconi-land, rather than SR620-land.
If someone wants to do this in SR620-land, feel free to do it and post the numbers.
  1664   Wed Jun 10 01:52:34 2009 AlbertoUpdateElectronicsMC length and Marconis' frequencies

Pete, Rob, Alberto,

yesterday we thought that some of the problems we were having in locking the IFO might be related to a change of the length of the mode cleaner. So today we decided to measure it again.

We followed the Sigg-Frolov technique (see 40m Wiki, Waldman, Fricke). For the record, the MC_AO input corresponds to IN2 on the MC Servo board.

We obtained: L = 27.092 +/- 0.001 m

From the new measurement we reset the frequencies of the Marconis to the following values:

33196450 Hz

132785800 Hz

165982250 Hz

199178700 Hz

 

  752   Tue Jul 29 01:03:17 2008 robConfigurationIOOMC length measurement
rob, yoichi

We measured the length of the mode cleaner tonight, using a variant of the Sigg-Frolov method. We used c1omc DAC outputs to inject a signal (at 2023Hz) into the AO path of the mode cleaner and another at DC into the EXT MOD input of the 166MHz IFR2023A. We then moved an offset slider to change the 166MHz modulation frequency until we could not see the 2023Hz excitation in a single-bounce REFL166. This technique could actually be taken a step further if we were really cool--we could actually demodulate the signal at 2023Hz and look for a zero crossing rather than just a powerspec minimum. In any case, we set the frequency on the Marconi by looking at the frequency counter when the Marconi setting+EXT MOD input were correct, then changed the Marconi frequency to be within a couple of Hz of that reading after removing the EXT MOD input. We then did some arithmetic to set the other Marconis.

The new f2 frequency is:

New              OLD
--------------------------
165983145        165977195

  753   Tue Jul 29 09:12:43 2008 KojiConfigurationIOOMC length measurement
I found that the prev modulation freq had been determined with a same kind of measurement by Osamu, which also looked accurate.
http://www.ldas-sw.ligo.caltech.edu/ilog/pub/ilog.cgi?group=40m&task=view&date_to_view=09/12/2002&anchor_to_scroll_to=2002:09:12:17:10:30-ajw

(There is also a document by Dennis to note about this measurement
http://www.ligo.caltech.edu/docs/T/T020147-00.pdf )

So, it means that the round trip length of the MC shortened by 1mm in the 6 years.
New              OLD
--------------------------
27.0924          27.0934    [m]

Quote:
rob, yoichi

We measured the length of the mode cleaner tonight, using a variant of the Sigg-Frolov method.
....
The new f2 frequency is:
New              OLD
--------------------------
165983145        165977195
  16222   Wed Jun 23 09:05:02 2021 AnchalUpdateSUSMC lock acquired back again

MC was unable to acquire lock because the WFS offsets were cleared to zero at some point and because of that MC was very misaligned to be able to catch back lock. In such cases, one wants the WFS to start accumulating offsets as soon as minimal lock is attained so that the mode cleaner can be automatically aligned. So I did following that worked:

  • Made the C1:IOO-WFS_TRIG_WAIT_TIME (delay in WFS trigger) from 3s to 0s.
  • Reduced C1:IOO-WFS_TRIGGER_THRESH_ON (Switchin on threshold) from 5000 to 1000.
  • Then as soon as a TEM00 was locked with poor efficiency, the WFS loops started aligning the optics to bring it back to lock.
  • After robust lock has been acquired, I restored the two settings I changed above.
Quote:

 


At the end, since MC has trouble catching lock after opening PSL shutter, I tried running burt restore the ioo to 2021/Jun/17/06:19/c1iooepics.snap but the problem persists

 

  16223   Thu Jun 24 16:40:37 2021 KojiUpdateSUSMC lock acquired back again

[Koji, Anchal]

The issue of the PD output was that the PD whitened outputs of the sat amp (D080276) are differential, while the successive circuit (D000210 PD whitening unit) has the single-ended inputs. This means that the neg outputs (D080276 U2) have always been shorted to GND with no output R. This forced AD8672 to work hard at the output current limit. Maybe there was a heat problem due to this current saturation as Anchal reported that the unit came back sane after some power-cycling or opening the lid. But the heat issue and the forced differential voltage to the input stage of the chip eventually cause it to fail, I believe.

Anchal came up with the brilliant idea to bypass this issue. The sat amp box has the PD mon channels which are single-ended. We simply shifted the output cables to the mon connectors. The MC1 sus was nicely damped and the IMC was locked as usual. Anchal will keep checking if the circuit will keep working for a few days.

Attachment 1: P_20210624_163641_1.jpg
P_20210624_163641_1.jpg
  12878   Thu Mar 9 20:38:19 2017 ranaConfigurationIOOMC lock acquisition settings changed; no more HOM locks

The MC was sort of misaligned. It was locking on some vertical HOMs. So I locked it and aligned the suspensions to the input beam (not great; we should really align the input beam to the centered spots on the MC mirrors).

With the HOMs reduced I looked at the MC servo board gains which Guatam has been fiddling with. It seems that since the Mod Depth change we're getting a lot more HOM locks. You can recognize this by seeing the longish stretches on the strip tool where FSS-FAST is going rail-to-rail at 0.03 Hz for many minutes. This is where the MC is locked on a HOM, but the autolocker still thinks its unlocked and so is driving the MC2 position at 0.03 Hz to find the TEM00 mode.

I lowered the input gain and the VCO gain in the mcdown script and now it very rarely locks on a HOM. The UGF in this state is ~3-4 kHz (I estimate), so its just enough to lock, but no more. I tested it by intentionally unlocking ~15 times. It seems robust. It still ramps up to a UGF of ~150 kHz as always. 'mcdown' commited to SVN.

  5551   Mon Sep 26 20:04:03 2011 KojiUpdatePSLMC lock has been recovered

[Kiwamu Suresh Koji]

Some main parameters of the PSL has been recovered using Dataviewer and some screen snapshots, as seen in the screenshots below.

Attachment 1: snapshot1.png
snapshot1.png
Attachment 2: snapshot2.png
snapshot2.png
Attachment 3: snapshot3.png
snapshot3.png
  1428   Wed Mar 25 17:22:58 2009 YoichiUpdateIOOMC lock without FSS
I made 40k:4k passive filter in a POMONA box and connected it to IN1 (not TEST IN1) of the FSS box.
With this modification and cut-and-tries with the gain sliders, I was able to lock the MC with 80kHz bandwidth by feeding back directory to the laser frequency.
The attached figure shows the open loop transfer function.
The phase margin is thin at 80kHz. Because of this, I could not turn on the MC super boost filters.
But I believe that we can increase the gain further by modifying the filter shape.

I used the following settings:
[MC Board]
C1:IOO-MC_REFL_GAIN 14
C1:IOO-MC_REFL_OFFSET -4.2381
C1:IOO-MC_BOOST1 0   (You can turn it on if you want, but turn it off for locking)
C1:IOO-MC_BOOST2 0
C1:IOO-MC_POL 1   (Minus)
C1:IOO-MC_VCO_GAIN 4
C1:IOO-MC_LIMITER 1 (Disable)

[FSS box]
C1:PSL-FSS_SW1 0 (Test1 ON)
C1:PSL-FSS_INOFFSET 0.1467
C1:PSL-FSS_MGAIN 30
C1:PSL-FSS_FASTGAIN 14 (Do not increase it, at least while locking. Otherwise the phase lag from the PZT loop gets significant and the MC loop will be conditionally stable).
I also turned down the FSS slow servo's RC transmission threshold to zero so that the slow servo works even without the RC locked.
Attachment 1: MC-loop-gain.png
MC-loop-gain.png
  757   Tue Jul 29 18:15:36 2008 robUpdateIOOMC locked

I used the SUS DRIFT MON screen to return the MC suspensions to near their pre-quake values. This required fairly large steps in the angle biases. Once I returned to the printed values on the DRIFT screen (from 3/08), I could see HOM flashes in the MC. It was then pretty easy to get back to a good alignment and get the MC locked.
  1633   Sat May 30 12:03:34 2009 robUpdatePSLMC locked

I locked to PSL loops, then tweaked the alignment of the MC to get it to lock. 

I first steering MC1 until all the McWFS quads were saturated.  This got the MC locking in a 01 mode.  So I steered MC1 a little more till it was 00.  Then I steered MC2 to increase the power a little bit.  After that, I just enabled the MC autolocker.

  5939   Fri Nov 18 01:27:04 2011 DenUpdateIOOMC locked

[Mirko, Den]

While the MC was unlocked (and the local damping off) we've measured the coherence between GUR1_X and OSEM sensors. It was rather high, close to 1 at frequencies 0.1 - 1 Hz. That means that stack does not kill all coherence between seismic noise and mirror motion.

Then we've turned on the local damping and measured the coherence again between GUR1_X and OSEM sensors. It decreased due to some noise and was on the level of ~0.5. We did reduced the motion between the mirror and the frame by local damping but it is not obvious that we lost some coherence due to this effect. Probably, actuator adds some noise.

When we locked the MC, we did not see any coherence at 0.1 - 1 Hz between GUR1_X or STS1_X and OSEM sensors of MC1 and MC3 but we did see with MC2. The MC1 sensor was fixed by Suresh.

 

Attachment 1: cohnolocalpumping-crop_4.pdf
cohnolocalpumping-crop_4.pdf
Attachment 2: cohlocalpumping4-crop.pdf
cohlocalpumping4-crop.pdf
Attachment 3: cohlock4-crop.pdf
cohlock4-crop.pdf
  8142   Sat Feb 23 00:36:52 2013 ManasaSummaryLockingMC locked

[Yuta, Manasa, Sendhil, Rana]

With MC REFL PD fixed, we aligned MC in high power enabling a fully functional MC autolocker.
We then unlocked MC and aligned the PD and WFS QPDs. Also we checked the MC demodulator and found a ~20% leakage between the Q-phase and I-phase. This must be fixed later by changing the cable length.

We adjusted MC offsets using /opt/rtcds/caltech/c1/scripts/MC/WFS/WFS_FilterBank_offsets.
We then measured the MC spot positions using  /opt/rtcds/caltech/c1/scripts/ASS/MC/mcassMCdecenter
Spot positions seem to have shifted by 2mm in yaw.

We will proceed with aligning the arms now.

Attachment 1: MCdecenter_23Feb2013.png
MCdecenter_23Feb2013.png
  14793   Sun Jul 21 20:23:35 2019 ranaUpdateIOOMC locked

I found the MC2 face camera disabled(?) and the MC servo board input turned off. I turned the MC locking back on but I don't see any camera image yet.

  14797   Mon Jul 22 13:26:41 2019 KruthiUpdateIOOMC locked

The MC2 has 2 GigE cameras right now. I'll put back the analog asap.

Quote:

I found the MC2 face camera disabled(?) and the MC servo board input turned off. I turned the MC locking back on but I don't see any camera image yet.

ELOG V3.1.3-