40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 148 of 171  Not logged in ELOG logo
Entry  Mon Mar 30 15:51:27 2009, steve, Update, Electronics, HP4291A left the lab to be repaired 
Eric Gustafson is handling the old HP4291A rehabilitation. Tarac picked both units up today.
March of 2008 Tucker Electronics failed to fix it's intermittent ~25MHz 0.5V oscillation at the swept sine output
See 40m-elog id:398 on 3-24-2008 by Rob Ward
Entry  Sun Mar 29 17:54:41 2009, Yoichi, Update, SUS, MC1 drift investigation continued Drift1.pdf
The attached plots show the trend of the MC OSEM signals along with the voltages across the output resistors of the bias current buffers.
The channel assignments are:
MC_TMP1 = LL coil 
    Reply  Mon Mar 30 09:07:22 2009, rana, Update, SUS, MC1 drift investigation continued 
[COLOR=chocolate]Maybe we can temporarily just disconnect the bias and just use the SUS sliders for bias if there's enough range?[/COLOR]
       Reply  Mon Mar 30 13:29:40 2009, Yoichi, Update, SUS, MC1 drift investigation continued 
[quote][COLOR=chocolate]Maybe we can temporarily just disconnect the bias and just use the SUS sliders for bias if there's enough range?[/COLOR][/quote]

We could do this, but I'm suspicious of the cables between the coil driver and the coils (including the satellite box). In this case, disabling the bias
Entry  Mon Mar 30 12:46:36 2009, Yoichi, Configuration, IOO, IOO QPDs were missing the beam IOO-QPDs.pdf
When I re-locked the MC, I wanted to check the trend of the IOO QPDs to see if the input beam pointing has changed.
Then I found that the QPDs were not receiving light.
The attached trend plots show that the QPDs missed the beam on March 23rd.
Entry  Mon Mar 30 12:29:17 2009, Yoichi, Configuration, , MC1 glitches not seen during the weekend MC_drift.pdf
The attached is the MC trend for the past 12 hours.
There is no MC1 glitches in the OSEM signals. Moreover, the total amplitude of the drift is smaller than it used to be (now the amplitude is less than
100 but it used to be a few hundreds).
Entry  Sun Mar 29 13:44:27 2009, steve, Update, SUS, ETMY sus damping restored 
ETMY sus damping was found to be tripped.
It was retored.
All fluorecent light were turned off. Please try to conserve some energy.
Entry  Fri Mar 27 02:40:06 2009, pete, Summary, IOO, MC glitch investigation MC1_Drift.png
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
    Reply  Fri Mar 27 15:05:42 2009, Yoichi, Update, IOO, MC glitch investigation MC1_Drift.pdfMC2_Drift.pdf
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:
       Reply  Fri Mar 27 17:52:16 2009, Yoichi, Update, IOO, MC 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.

Entry  Fri Mar 27 02:50:54 2009, Yoichi, Update, Locking, DD demodulation phase suspicious 
I noticed that the gain of PD6_Q (before the phase rotation) was 0 whereas PD6_I gain was 15.
This means the demodulation phase of the PD6 had no meaning other than changing the gain.
According to the conlog, it has been zero since March 2nd. I don't know how it happened.
Entry  Thu Jan 22 23:36:50 2009, pete, HowTo, oplevs, arm cavity oplev calibration ETMYpitpower.pngETMYpitcal.png
calibrated the y-arm oplevs.  the procedure is contained in a matlab script.  the whereabouts of this script will be revealed in a future log entry.

ITMYpit  140 microrad/ct
    Reply  Fri Jan 23 12:48:12 2009, Kakeru, Update, oplevs, arm cavity oplev calibration ITMX_pitch.png
I calibrated optlevs of x and y arm cavity, indipendently from Peter's work.

ITMX pit: 77 microrad/ct
       Reply  Thu Jan 29 17:24:41 2009, Kakeru, Update, oplevs, arm cavity oplev calibration 
I calibrated optlevs again. My previous work has a lot of mistakes, so ignore it.

ITMX pit: 195 microrad/ct
          Reply  Sat Mar 14 22:53:12 2009, Kakeru, Update, oplevs, arm cavity oplev calibration oplev.pdf
I finished a calibration of optical levers.

To calibrate oplevs, I locked appropriate cavity and tilted a mirror.
             Reply  Fri Mar 20 15:37:58 2009, Kakeru, Update, oplevs, arm cavity oplev calibration 

I calibrated several oplevs with OSEM signal as a confirmation of my fitting method the method is:
                Reply  Thu Mar 26 09:08:18 2009, Kakeru, Update, oplevs, arm cavity oplev calibration 
I uploaded a document about my oplev calibration.
Entry  Thu Mar 26 04:27:26 2009, Yoichi, Update, Locking, 3.8kHz peak as a function of the arm power CARM-PODC.pdf
During the power ramp-up, I actuated CARM using ETMs and measured the transfer functions to the PO_DC at several arm powers.
The peak grows rapidly with the power. It also seems like the frequency shifts slightly as the power goes up, but not much.
Entry  Thu Mar 26 04:09:38 2009, Yoichi, Update, IOO, Single X arm lock spectra with different MC lock schemes XarmSpectra.pdfXarmSpectraZoom.pdf
The attached plots show MC_F, FSS_FAST_F and XARM IN/OUT spectra with different MC locking modes.
The conventional locking means the FSS is used. The direct frequency lock is the new way.
You can see that at low frequencies, the frequency actuator is working hard to suppress the MC pendulum motions.
Entry  Thu Mar 26 04:01:24 2009, Yoichi, Update, PSL, FSS Open Loop Gain OpenLoopTF.png
Yoichi, Peter, Jenne

Attached is the open loop transfer function of the FSS as of today with the common gain = 12dB and the fast gain = 16dB.
Entry  Wed Mar 25 20:41:43 2009, Jenne, Update, IOO, Mode Cleaner Servo Board Transfer Functions (to be updated) MCwithBoxsmall.JPGMCnoBoxsmall.JPGPomonaBoxforMCsmall.JPG
When all things fail (netgpibdata.py is giving me weird data.  When I plot the data it has saved from the 4395A, it's some wierd other universe's
version of my transfer function.  I don't really know what's up.  I'm pretty sure I'm getting the 'correct' data, since each TF looks vaguely
like it should, but with some crazy humps.  I'll talk to Yoichi in the morning about it maybe.) (also, we're low on emergeny floppy discs), you can
    Reply  Thu Mar 26 00:45:24 2009, Jenne, Update, IOO, Mode Cleaner Servo Board Transfer Functions (to be updated) MCwithandwithoutfilter25Mar2009.pngPomonaBoxMCfilter25Mar2009.pngMCServoData25Mar2009.tar.gz

            netgpibdata.py is giving me weird data.  When I plot the data it has saved from the 4395A, it's some wierd other
Entry  Wed Mar 25 17:22:58 2009, Yoichi, Update, IOO, MC lock without FSS MC-loop-gain.png
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.
Entry  Wed Mar 25 09:55:45 2009, steve, Update, IOO, glitching sensors of MC glitchesofMC.jpg
Yesterday's 4.8mag earthquake at Salton Sea is shown on Channel 1
Entry  Wed Mar 25 04:18:28 2009, Yoichi, Update, Locking, Tuesday Locking AO-Loop-p9.png
After the new PO_DC PD was installed, I tweaked several gains to make the locking scripts work right.
First of all, I increased the gain of PD12 (PD12_I is SPOB) by a factor of 1.4 to compensate for the power decrease
by the insertion of the BS. SPOB is used by the PRM alignment script. I was too lazy to modify the scripts.
Entry  Tue Mar 24 19:55:24 2009, Jenne, Update, LSC, New PO DC 
[Rana, Jamie, Jenne]
SPOB DC hasn't been so good lately, so we installed a new PO DC PD on the PO table.  We used a 30% reflecting beam splitter (BS1-1064-30-1025-someotherstuff). 
We didn't check with a power meter that it's a 30% BS, but it seems like that's about right.  The beamsplitter is as close as we could get to the
    Reply  Tue Mar 24 23:23:05 2009, rana, Update, LSC, New PO DC 
We also found that the SPOB RF cable was going through a splitter before going into the SPOB demod board. The other
input of the splitter was open (not terminated). [B]Using 50m Ohm devices without terminated inputs is illegal[/B]. It
makes there be standing waves in the cables and makes the RF phase very dependent on cable lengths. We took away
Entry  Tue Mar 24 13:54:49 2009, Jenne, Update, SUS, Op Levs Centered 
ITMX, ITMY, BS, SRM, PRM op levs were all recentered.  ETM's looked okay enough to leave as-is. 
Entry  Tue Mar 24 13:10:07 2009, Alberto, Configuration, PSL, new mirror installed on the AP table 
New flipping mirror installed on the AP table on the beam path to the REFL199 PD.
If you're missing the double demod signal, please check that it is actually down.
Entry  Tue Mar 24 09:04:02 2009, steve, Update, SUS, 4.8 mag earthquake 
SRM, ITMX, ETMX, ITMY and ETMY lost damping at 4:55am this morning from 4.8 magnitude earthquake.
Their damping were restored.
C1:SUS-ITMX_URSEN_OUTPUT swich was found in off position. It was turned on.
Entry  Tue Mar 24 03:05:25 2009, Yoichi, Update, Locking, Locking tonight 
MC1 issue:
The MC1 seems to be drifting still. I found it was off from the SUS drift-mon reference values and restored the alignment using the SUS drift-mon before
I went home for dinner.
Entry  Mon Mar 23 15:50:44 2009, rana, Configuration, LSC, filters deleted, lsc rebooted 
The LSC time had gone too high. I deleted ~20 filters and rebooted. CPU time came down to 50 usec.
The filters all looked like old trash to me, but its possible they were used.
I didn't delete anything from the DARM, CARM, etc. banks but did from the PD and TM filter banks. You can always go back in time by using the
Entry  Mon Mar 9 23:55:38 2009, Osamu, DAQ, Computers, bscteststand and kami1 outside martian 
This morning there was a confliction of tpman running on fb40m and kami1. Alex fixed it temporary but Rana suggested it was better to move both PCs outside
martian. We moved both PCs physically to the control room and connected to general network with a local router. I believe it won't conflict anymore but
if you guess these PC might have trouble please feel free to shutdown.
    Reply  Sun Mar 22 23:16:41 2009, rana, DAQ, Computer Scripts / Programs, tpman restart 
Could get testpoints but couldn't start excitations. Restarted tpman on daqawg. Works now.

[COLOR=orange] Still no log file.[/COLOR] X-(
Entry  Mon Mar 9 19:33:10 2009, rana, Update, DMF, seisBLRMS in temp condition Untitled.png
The seisBLRMS has been running on megatron via an open terminal ssh'd into there from allegra with matlab running. This
is because I couldn't get the compiled matlab functionality to work.
Even so, this running script has been dying lately because of some bogus 'NDS' error. So for today I
    Reply  Fri Mar 13 19:26:09 2009, Yoichi, Update, DMF, seisBLRMS compiled 
 I compiled seisBLRMS.
The tricks were the following:
(1) Don't add path in a deployed command. 
       Reply  Sun Mar 22 22:47:58 2009, rana, Update, DMF, seisBLRMS compiled but still dying 
Looks like seisBLRMS was restarted ~1 AM Friday morning but only lasted for 5 hours. I just restarted it on megatron;
let's see how it does. I'm not optimistic.
Entry  Sun Mar 22 22:39:24 2009, rana, Summary, LSC, Calibration of the ITM and ETM Actuation free.png
I used the following procedure to calibrate the ITMX actuation signal.

Free Swinging Michelson:
Entry  Fri Mar 20 15:54:29 2009, steve, Omnistructure, General, 480V crane power switch on MEZ 
CES Mezzanine is beeing rebuilt to accommodate our new neighbor: the 20ft high water slide...& .jacuzzi
All our ac power transformers are up there. Yesterday we labelled the power switch of 480VAC on the mezz
that we need to keep to run the 3 cranes in the lab.
Entry  Fri Mar 20 12:07:19 2009, Yoichi, Configuration, ASC, ETMY beam centering 
I forgot to put this in the elog.
Last Sunday night, I centered the beam on the ETMY because it was too low.
To do so, I wrote scripts (beamCenterETMY-P and beamCenterETMY-Y) to continuously align the Y-arm while I'm moving the beam on the end QPD.
Entry  Fri Mar 20 11:01:02 2009, steve, Update, PEM, particle counts are high particles32d.jpg
The outside particle counts for 0.5 micron are 3 million this morning at 9am. Low clouds, foggy condition with low inversion layer.
This makes the 40m lab 30-50K
I just turned on the HEPA filter at the PSL enclosure.
Entry  Thu Mar 19 02:45:36 2009, Yoichi, Configuration, IOO, A loose wire found for MC1  
I found a loose connection of a wire in the cross-connect between an ADC and the MC1 coil driver's UL bias input.
I tightened it.
To see if this fixes the MC1 drift problem, I will do another round of MC1 drift measurement.
    Reply  Thu Mar 19 10:45:43 2009, Yoichi, Configuration, IOO, A loose wire found for MC1  AfterWireFix-1.pdf
I attached a 6-hour trend of the MC mirror OSEM signals with the MC unlocked.
The drift of the MC1 is within 20 counts (0.6um in terms of each OSEM).
This is comparable to the other MC mirrors.
Entry  Mon Mar 16 12:26:59 2009, Yoichi, Configuration, IOO, MC1 drift MC1_Drift1.pdf
There seems to be a large drift of MC1 even when there is no WFS feedback.
The attached plot is an example a 20min trend. You can see that MC1 OSEM signals drift significantly larger than that of MC2/MC3.
You can also be sure that there is no drifting voltage applied to the coils on the MC1 during this period.
    Reply  Tue Mar 17 08:44:37 2009, Yoichi, Configuration, IOO, MC1 drift MC1_Drift3.pdf
I'm done with the MC1 drift measurement.
The result is attached. It is clear that MC1 is in trouble. The small drifts in the MC2/MC3 are insignificant compared to the crazy MC1 behavior.
Since there is no drift in the coil feedback voltage monitors, it is probably not a problem of the DACs. 
Entry  Mon Mar 16 15:19:52 2009, Osamu, DAQ, Electronics, SR785 
I borrowed SR785 to measure AA, AI noise and TF.
Entry  Mon Mar 16 01:20:40 2009, rana, Configuration, IOO, MCWFS noise filtered on the SUS-MC  xarm.png
[SIZE=4][COLOR=darkgreen]Recently[/COLOR][/SIZE], we noticed that the IOO-WFS system runs at 2048 Hz and sends its signals to the MC SUS
systems which run at 16 kHz. [B][COLOR=red]There is no upsampling filter[/COLOR][/B] or anti-imaging filter.
Entry  Sun Mar 15 21:50:29 2009, Kakeru, Kiwamu, Osamu, Update, Computers, Some computers are rebooted  
We found c1lsc, c1iscex, c1iscey, c1susvme, c1asc and c1sosvme are dead.
We  turned off all watchdogs and turned off all lock of suspensions.
Then, I tried to reboot these machines from terminal, but I couldn't login to all of these machines.
Entry  Wed Mar 11 16:53:48 2009, Yoichi, Update, Locking, Junks in around kHz MC_F-XARM.pdfold-xarm.pdf
Rana, Yoichi

Last night, we tried to find out the source of the kHz region peaks in the DARM and CARM error signals.
    Reply  Wed Mar 11 22:57:48 2009, Yoichi, Update, Locking, Calibrated XARM error signal spectrum XarmErrorSpeCalibrated.pdf
I did a rough calibration of the XARM error spectrum.
See the attached calibrated spectrum.
       Reply  Fri Mar 13 22:07:14 2009, Yoichi, Update, Locking, Calibrated XARM error signal spectrum XarmErrorSpeCalibrated.pdf
Of course I made a mistake.
I put a pole at 1525Hz whereas it should have been a zero.
Entry  Fri Mar 13 20:23:37 2009, Yoichi, Update, LSC, AO path transfer function with X-arm locked AOPath-Xarm.png
I measured the AO path transfer function while the X-arm is locked with the POX PDH signal.
The POX-I signal was already connected to the input 1 of the CM board. So I injected a signal from the EXC-B channel of the board and measured the transfer
function from TP2B to TP1A. To open the loop, I disabled the switch befor the EXC-B.
Entry  Fri Mar 13 05:16:21 2009, Yoichi, Update, Locking, Locking update AOTF2.pngAOTF2-zoom.png
Yoichi, Osamu,

With adjustments of the loop gains during the CARM offset reduction, the IFO reaches arm_power = 25 sort of robustly unless the 3.8kHz oscillation rings
Entry  Thu Mar 12 15:57:53 2009, Yoichi, Update, IOO, MC drift is terrible MC_Drift-1.pdfMC_Drift-2.pdf
Yoichi, Osamu,

Last night's locking work was totally interrupted by the sabotage by the MC.
    Reply  Thu Mar 12 19:11:27 2009, rana, Update, IOO, MC drift is terrible 
Kakeru, Rana, Yoichi

We used the [SIZE=4][COLOR=purple][B]SUS DRIFT MON screen[/B][/COLOR][/SIZE] to set the MC biases such that the mirrors were returned to the old OSEM values.
       Reply  Thu Mar 12 20:59:04 2009, Kakeru, Update, IOO, MC drift is terrible MCtrans090312.png
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.
Entry  Thu Mar 12 18:48:37 2009, Yoichi, Update, IOO, MC aligned but ... 
After the MZ alignment, I aligned the MC with the periscope mirrors.
It looked like the MC mis-alignment was mainly caused by the input beam change.
So I left the MC mirrors as they were to keep the output beam pointing.
Entry  Thu Mar 12 18:44:02 2009, Yoichi, Update, PSL, MZ aligned 
The MC lost the alignment somehow this afternoon.
So I thought it was good time to touch the MZ because I had to align the MC using the periscope anyway.
Entry  Thu Mar 12 02:18:42 2009, Yoichi, Update, Locking, MC_I spectra (RF_AM) MC_I_Spe.pngMC_I-Xarm.png
I took several spectra of MC_I signal (see attm1).

The blue curve is when the MC was locked. The green curve (RF_AM) shows the MC_I spectrum when the MC is unlocked and MC2 is mis-aligned, 
Entry  Thu Mar 12 00:29:39 2009, Jenne, Omnistructure, DMF, DMF being whiny again 
[QUOTE]The seisBLRMS has been running on megatron via an open terminal ssh'd into there from allegra with matlab running.[/QUOTE]

[Yoichi, Jenne]
Entry  Wed Mar 11 23:41:33 2009, Kakeru, Yoichi, Update, IOO, WFS centering  
We found the MC reflection was distorted . And WFC beam went to upward of QPD
We recentered WFC beam and these problems were fixed
Entry  Wed Mar 11 21:03:51 2009, Kakeru and Kiwamu, Update, IOO, PSL angle QPD 
Kakeru and Kiwamu
We placed a QPD on the PSL bench for PSL angle monitor.
Entry  Wed Mar 11 16:41:22 2009, steve, Update, MOPA, spare NPRO power  
The spare M126N-1064-700,  sn 5519 of Dec 2006 rebuilt  NPRO's power output
 measured   750mW at DC2.06A with Ohpir meter.
Alberto's controller  unit 125/126-OPN-PS,  sn516m was disconnected from lenght measurment NPRO on the AP table.
Entry  Wed Mar 11 14:51:01 2009, Kakeru, Joe, Rob, Update, IOO, MC alignment 
This morning, MC alignment was gone and MC wasn't lock.
We checked old value of pitch, yaw, and position offset of each MC mirror, and found they were jumped.
We don't know the reason of this jump, but we restore each offset value and MC backed to lock.
Entry  Wed Mar 11 11:30:15 2009, josephb, Configuration, Cameras,  
I modified the Video.db file used by c1aux located in  /cvs/cds/caltech/target/c1aux.
I added the following channels to the db file, intended for either read in or read out by the digital camera scripts.
Entry  Wed Mar 11 04:33:57 2009, rana, Configuration, Computer Scripts / Programs, wild ndsproxy tclshexe 
The ndsproxy tcl task on nodus was eating up all the CPU and making the elog slow. I killed it and restarted it.
It looks like it hasn't been making a log file since January. Someone who has some skill in decoding the cryptic csh stdout redirection
syntax should look into this (its in target/ndsproxy/)
Entry  Wed Mar 11 01:16:40 2009, rana, Summary, IOO, rogue trianglewave in the MC Servo offset slider Untitled.pngUntitled.pnga.png
On Monday evening, I ran this command: trianglewave C1:IOO-MC_REFL_OFFSET 0 4 120 600;ezcawrite C1:IOO-MC_REFL_OFFSET
which I thought (from the syntax help) would move that offset slider with a period of 120 seconds for 600 seconds.
Entry  Tue Mar 10 04:55:41 2009, Yoichi, Update, Locking, Locking: 3.7kHz large oscillation CARM_DARM_Spectra.pdfPODC_Spe_AOPath_Engaged.pngPODC_Spe_before_PODC_handoff.pngAOGain3.pngAOGain2.png
Yoichi, Jenne, Alberto,

As I reported on the last Thursday, there is a large oscillation in CARM and DARM error signals (attm1).
Entry  Thu Mar 5 23:18:38 2009, Kakeru, Configuration, Computers, tdsdata doesn't work 
I found that tdsdata doesn't work.

When I star tdsdata, he takes a few ~ 10 seconds of data, and he dies with a message "Segmentation fault".
    Reply  Sun Mar 8 23:14:52 2009, rana, Update, Computer Scripts / Programs, tdsdata doesn't work 
Matt logged in and rebuilt the TDS stuff for us on Mafalda in /cvs/cds/caltech/apps/linux/tds_090304. 
He says that he can't build his stuff on 64-bit because there's not a sanctioned 64-bit build of GDS yet.
This should have all the latest fixes in it. I tried using both the old and new code from allegra and they both are fine:
       Reply  Mon Mar 9 14:57:30 2009, Kakeru, Update, Computer Scripts / Programs, tdsdata doesn't work oldtds.pngnewtds.png
I tested new tdsdata and found it was working well.
I excited C1:SUS-ITMY_SUSPIT_EXC with tdssine, and get data from C1:LSC-TRY_OUT (testpoint) and C1:SUS- ITMY_OPLEV_PERROR (recorded point)
with new and old tdsdata.
          Reply  Mon Mar 9 16:54:52 2009, Kakeru, Rana, Update, Computer Scripts / Programs, tdsdata doesn't work 
We confirmed that new tds(/cvs/cds/caltech/apps/linux/tds_090304/) works well on linux 64, and replaced it to /cvs/cds/caltech/apps/linux/tds/
The old /cvs/cds/caltech/apps/linux/tds is put in /cvs/cds/caltech/apps/linux/tds.bak
             Reply  Mon Mar 9 23:13:22 2009, Yoichi, Update, Computer Scripts / Programs, tdsdata doesn't work 

            We confirmed that new tds(/cvs/cds/caltech/apps/linux/tds_090304/) works well on linux 64, and replaced it to /cvs/cds/caltech/apps/linux/tds/
Entry  Mon Mar 9 19:27:16 2009, rana, Configuration, Computers, Move of the CLIO Digital Controls test setup 
Because of the network interference we've had from the CLIO system for the past 3-4 days, I asked the guys to remove
the test stand from the 40m lab area. It is now in the 40m control room. Since it needed an ethernet connection to get out
for some reason we've let them hook into GC. Also, instead of using a real timing signal slaved to the GPS, Jay suggested
ELOG V3.1.3-