40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 281 of 341  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  6841   Wed Jun 20 18:43:57 2012 yutaUpdateLSCcalibrated POX error signal

[Jenne, Yuta]

We did the same calibration for POX. It was 3.8e12 counts/m. See elog #6834 for the details of calibration we did.

According to Kiwamu's calibration, actuator response of ITMX is;

A_ITMX  = 4.913e-09 Hz^2*counts/m / freq^2

Plots below are results from our calibration measurement.

LSCxarmTF_usingITMX.pngLSCxarm_HAover1plusG.pngPOXerrorcalibration.png

  6834   Tue Jun 19 23:36:19 2012 yutaUpdateLSCcalibrated POY error signal

[Jenne, Yuta]

We calibrated POY error signal(C1:LSC-POY11_I_ERR). It was 1.4e12 counts/m.

Modeling of Y arm lock:
  Let's say H is transfer function from Y arm length displacement to POY error signal. This is what we want to measure.
  F is the servo filter (filter module C1:LSC-YARM).
  A is the actuator TF using ITMY. According to Kiwamu's calibration using MICH (see elog #5583),

  A_ITMY  = 4.832e-09 Hz^2*counts/m / freq^2

  We used ITMY to lock Y arm because ITMY is already calibrated.

What we did:
  1. Measured openloop transfer function of Y arm lock using POY error signal using ITMY (G=HFA). We noticed some discrepancy in phase with our model. If we include 1800 usec delay, phase fits well with the measurement. I think this is too big.
LSCyarmTF_usingITMY.png


  2. Measured a transfer function between actuator to POY error signal during lock. This should give us HA/(1+G).
LSCyarm_HAover1plusG.png

  4. Calculated H using measurements above. Assuming there's no frequency dependance in H, we got

  H = 1.4e12 counts/m

POYerrorcalibration.png

 For sanity check; Peak to peak of the POY error signal when crossing the IR resonance is about 800 counts. FWHM is about 1 nm, so our measurement is not so crazy.

  6835   Wed Jun 20 00:01:04 2012 JenneUpdateLSCcalibrated POY error signal

[Yuta, Jenne]

We have measured the out of loop residual motion of the Yarm while locked with the ALS.  We see ~70pm RMS, as compared to Kiwamu's best of ~24pm RMS.  So we're not yet meeting Kiwamu's best measurement, but we're certainly not in crazy-land.

The Yarm ALS was locked, I took a spectrum of POY11_I_ERR, and used the calibration that we determined earlier this evening.  For reference, I attach a screenshot of our ALS loop filters - we had on all the boosts, and both resonant gain filters (~3Hz and ~16Hz).

A large part of the RMS is coming from the 60Hz power line and the 180Hz harmonic....if we could get rid of these (how were they eliminated from the measurement that Kiwamu used in the paper?? - plotted elog 6780) we would be closer. 

Also, it looks like the hump (in our measurementf ~100Hz, in Kiwamu's ~200Hz) is not quite an order of magnitude higher in amplitude in our measurement vs. Kiwamu's.  We have ~5e-11 m/rtHz, Kiwamu had ~7e-12 m/rtHz.  This increase in noise could be coming from the fact that Yuta and Koji decreased the gain in the Ygreen PDH loop to prevent the PDH box from oscillating. 

While we should still think about why we can't use the same gain that Kiwamu was able to ~6 months ago, we think that we're good enough that we can move on to doing mode scans and residual motion measurements of the Xarm.

 

Attachment 1: LSC_POY_11_I_ERR_calib_19June2012.pdf
LSC_POY_11_I_ERR_calib_19June2012.pdf
Attachment 2: POY_calib_19June2012_FiltBankSettings.png
POY_calib_19June2012_FiltBankSettings.png
  8256   Fri Mar 8 03:07:19 2013 yutaUpdateLSCcalibrated PRM-ITMY length spectra

Measured free swing PRM-ITMY length was 230 nm RMS.
MI differential length was 85 nm RMS(elog #8248). This tells you that PR2, PR3 are not so noisy compared with usual suspensions.

Openloop transfer function:
  OLTF of PRM-ITMY cavity lock using REFL55_Q_ERR as error signal and PRM as actuator is below.
  UGF ~ 120 Hz, phase margin ~ 50 deg.
  Somehow, phase delay was 460 usec, which is smaller than the empirical value 550 usec.
LSCPRCLOLTF_PRITMY.png


PRM-ITMY length spectra:
  Below. Calibration was done using calibrated REFL55_Q_ERR and actuator response(elog #8255).
PRITMYmotion.png

  9606   Wed Feb 5 20:41:57 2014 DenUpdateLSCcalibrated spetra from OAF test

We did online adaptive filtering test with IMC and arms 1 year ago (log 7771). In the 40m presentations I can still see the plot with uncalibrated control spectra that was attached to that log. Now it the time to attach the calibrated one.

Template is in the /users/den/oaf

Attachment 1: oaf_cal.pdf
oaf_cal.pdf
  6938   Sun Jul 8 00:27:54 2012 yutaSummaryLockingcalibrating phase tracking mode scan data

FSR for X/Y arm are 3.97 +/- 0.03 MHz and 3.96 +/- 0.02 MHz respectively. This means X/Y arm lengths are 37.6 +/- 0.3 m and 37.9 +/- 0.2 m respectively.
I calibrated the mode scan results using 11MHz sideband as frequency reference.
Calibration factor between the phase of the phase tracker and IR frequency is 9.81 +/- 0.05 kHz/deg for X arm, 9.65 +/- 0.02 kHz/deg for Y arm.

Calculation:
  For the mode scan measurements, we swept the phase of the phase tracker linearly with time. Previous calculation was done without calibrating seconds into actual IR frequency. The first order calibration can be done using modulation frequency as reference. Note that I'm still assuming our sweep was linear here.

  Relation between FSR and modulation frequency can be written in

f_mod = n * nu_FSR + nu_f

  where f_mod is the modulation frequency, n is an integer, nu_f = mod(nu_FSR,f_mod).
  nu_FSR and nu_f are measurable values (in seconds) from the mode scan. We know that f_mod = 11065910 Hz (elog #6027). We also know that nu_FSR is designed to be ~3.7 MHz(=c/2L). So, n = 2.
  We can calculate f_mod in seconds, so we can calibrate seconds into IR frequency.


Calibrating X arm mode scan:
  From the 8FSR mode-scan data (see elog #6859), positions of TEM00 and upper/lower 11 MHz sidebands in seconds are;

TEM00    242.00     214.76     187.22     159.27     131.33     102.96     74.61     46.00     17.51
upper    236.70     209.05     181.36     153.42     125.06      96.86     68.43     40.20
lower    220.35     192.96     165.03     136.98     108.92      80.65     52.25     23.90


  So, FSR and nu_f in seconds are;

FSR    27.24     27.54     27.95     27.94     28.37     28.35     28.61     28.49
nu_f   21.80     21.82     22.14     22.19     22.26     22.28     22.40     22.40


  By using formula above, modulation frequency in seconds are;

f_mod    76.28    76.90    78.04    78.07    79.00    78.98    79.62    79.38

  By taking average, FSR and f_mod in seconds are

FSR    28.1 +/- 0.2
f_mod    78.3 +/- 0.4

  We know that f_mod = 11065910 Hz, so conversion constant from seconds to frequency is

k1 = 0.1413 +/- 0.0007 MHz/sec

  We swept the phase by 3600 deg in 250 sec, so conversion constant from degree to frequency is

k2 = 9.81 +/- 0.05 kHz/deg

  Also, using k1, FSR for X arm is

FSR = 3.97 +/- 0.03 MHz

  This means, X arm length is

L = c/(2*FSR) = 37.6 +/- 0.3 m


Calibrating Y arm mode scan:
  From the 8FSR mode-scan data (see elog #6832), positions of TEM00 and upper/lower 11 MHz sidebands in seconds are;

TEM00    246.70     218.15     190.06     161.87     133.26     104.75     76.01     47.19     18.60
upper    240.86     212.78     184.32     155.73     127.23      98.48     69.78     41.26
lower    224.53     195.73     167.31     139.13     110.81      82.27     53.60     24.50


  So, FSR and nu_f in seconds are;

FSR    28.55     28.09     28.19     28.61     28.51     28.74     28.82     28.59
nu_f   22.44     22.57     22.60     22.61     22.47     22.48     22.50     22.68


  By using formula above, modulation frequency in seconds are;

f_mod    79.54    78.75    78.98    79.825    79.485    79.955    80.14    79.855


  By taking average, FSR and f_mod in seconds are

FSR    28.5 +/- 0.1
f_mod    79.6 +/- 0.2

  We know that f_mod = 11065910 Hz, so conversion constant from seconds to frequency is

k1 = 0.1390 +/- 0.0003 MHz/sec

  We swept the phase by 3600 deg in 250 sec, so conversion constant from degree to frequency is

k2 = 9.65 +/- 0.02 kHz/deg

  (k2 of X arm and Y arm is different because delay-line lengths are different)
  Using k1, FSR for X arm is

FSR = 3.96 +/- 0.02 MHz

  This means, X arm length is

L = c/(2*FSR) = 37.9 +/- 0.2 m


Summary of mode scan results:
X arm
  Mode matching    MMR = 91.2 +/- 0.3 % (elog #6859) Note that we had ~2% of 01/10 mode.
  FSR         FSR = 3.97 +/- 0.03 MHz (this elog)
  finesse    F = 416 +/- 6 (elog #6859)
  g-factor    g1*g2 = 0.3737 +/- 0.002 (elog #6922)

  length        L = 37.6 +/- 0.3 m (this elog)
  ETM RoC  R2 = 60.0 +/- 0.5 m (this elog and #6922; assuming ITM is flat)

Y arm
  Mode matching    MMR = 86.7 +/- 0.3 % (elog #6828) Note that we had ~5% of 01/10 mode.
  FSR         FSR = 3.96 +/- 0.02 MHz (this elog)
  finesse    F = 421 +/- 6 (elog #6832)
  g-factor    g1*g2 = 0.3765 +/- 0.003 (elog #6922)

  length       L = 37.9 +/- 0.2 m (this elog)
  ETM RoC R2 = 60.7 +/- 0.3 m (this elog and #6922; assuming ITM is flat)

  I think these are all the important arm parameters we can derive just from mode scan measurement.

  Every errors shown above are statistical error in 1 sigma. We need linearity check to put systematic error. Also, we need more precise calibration after that, too, if the sweep has considerably large non-linearity. To do the linearity check, I think the most straight forward way is to install frequency divider to monitor actual beat frequency during the sweep.

  6939   Sun Jul 8 00:58:08 2012 KojiSummaryLockingcalibrating phase tracking mode scan data

Quote:

FSR for X/Y arm are 3.97 +/- 0.03 MHz and 3.96 +/- 0.02 MHz respectively. This means X/Y arm lengths are 37.6 +/- 0.3 m and 37.9 +/- 0.2 m respectively.

These aren't so bad. (Look at this entry)

And interestingly the ETM curvatures are closer to ATF measurements than Coastline's measurement. (Look at wiki)

  6815   Wed Jun 13 17:39:13 2012 yutaUpdateGreen Lockingcalibrating the beatbox

[Jenne, Yuta]

We put 0 dBm sine wave to the RF input of the beatbox and linear-sweeped frequency of the sine wave from 0 to 200 MHz using network analyzer (Aligent 4395A).
(We first tried to use 11 MHz EOM marconi)

Whlile the sweep, we recorded the output of the beatbox, C1:ALS-BEATY_(FINE|COARSE)_(I|Q)_IN1_DQ. We made them DQ channels today. Also, we put gain 10 after the beatbox before ADC for temporal whitening filter using SR560s.

We fitted the signals with sine wave using least squares fit(scipy.optimize.leastsq).
Transision time of the frequency from 200 MHz to 0 Hz can be seen from the discontinuity in the time series. We can convert time to frequency using this and supposing linear sweep of the network analyzer is perfect.

Plots below are time series data of each signal(top) and expansion of the fitted region with x axis calibrated in frequency (bottom).

ALS-BEATY_COARSE_I_IN1_DQ.pngALS-BEATY_COARSE_Q_IN1_DQ.png
ALS-BEATY_FINE_I_IN1_DQ.pngALS-BEATY_FINE_Q_IN1_DQ.png


We got

C1:ALS-BEATY_COARSE_I_IN1_DQ = -1400 sin(0.048 freq + 1.17pi) - 410
C1:ALS-BEATY_COARSE_Q_IN1_DQ = 1900 sin(0.045 freq + 0.80pi) - 95

C1:ALS-BEATY_FINE_I_IN1_DQ = 1400 sin(0.89 freq + 0.74pi) + 15
C1:ALS-BEATY_FINE_Q_IN1_DQ = 1400 sin(0.89 freq + 1.24pi) - 3.4

(freq in MHz)

The delay line length calculated from this fitted value (supposing speed of signal in cable is 0.7c) is;

  D_coarse = 0.7c * 0.048/(2*pi*1MHz) =  1.6 m
  D_fine = 0.7c * 0.89/(2*pi*1MHz) = 30 m

So, the measurement look quite reasonable.

FINE signals looks nice because we have similar response with 0.5pi phase difference.
For COARSE, maybe we need to do the measurement again because the frequency discontinuity may affected the shape of the signal.

  1185   Mon Dec 8 00:10:42 2008 carynSummaryGeneralcalibrating the jenne laser
I apologize in advance for the long list of numbers in the attachment. I can't seem to make them hide for some reason.

So, since Jenne's laser will probably be used for the Stoch mon calibration, Alberto and I took some measurements to calibrate Jenne's laser.
We focused the beam onto the New Focus RF 1GHz photodetector that we stole from rana's lab (powered with NewFocus power 0901). Measured the DC output of the photodetector with scope. Aligned the beam so DC went up (also tried modulating laser at 33MHz and aligning so 33MHz peak went up). Hooked up the 4395a Spectrum/Network Analyzer to the laser and to the AC out of the photodetector (after calibrating Network analyzer with the cables) so that the frequency response of the laser*photodetector could be measured.
(Note: for a while, we were using a splitter, but for the measurements here, I got rid of the splitter and just sent the RFout through the cables to channel A for the calibration, sent RFout to the laser and photodetector to channel A for the measurement)

Measured the frequency response. At first, we got this weird thing with a dip around 290MHz (see jcal_dip_2_norm.png below).
After much fiddling, it appeared that the dip was from the laser itself. And if you pull up just right on the corner of this little metal flap on the laser (see picture), then the dip in the frequency response seems to go away and the frequency response is pretty flat(see jcal_flat_3_norm below). If you press down on the flap, the dip returns. This at least happened a couple of times.
Note that despite dividing the magnitude by the DC, the frequency responses don't all line up. I'm not sure why. In some cases the DC was drifting a bit(I presume the laser was coming out of alignment or decided to align itself better) and maybe with avgfactor=16, and measuring mean DC on the scope, it made the DC meas not match up the the frequ resp meas...
I've attached the data for the measurements made (I'm so sorry for all the #'s. I can't figure out how to hide them)
name/lasercurrent/DC/analyzer SourcePower/analyzer avgfactor
jcal7_1/I=31.7mA/DC=-4.41/SourcePower=0dBm/avgfactor=16
jcal7_2/I=31.7mA/DC=-1.56/SourcePower=0dBm/avgfactor=none
jcal8_1/I=31.7mA/DC=-4.58/SourcePower=0dBm/avgfactor=16
jcal8_2/I=31.7mA/DC=-2.02/SourcePower=0dBm/avgfactor=16
jcal8_3/I=31.7mA/DC=-3.37/SourcePower=0dBm/avgfactor=16
Note also that the data from the 4395a seems to have column1-frequency, column2-real part, column3-imaginary part...I think. So, to calculate the magnitude, I just took (column2)^2+(column3)^2.


To get sort of an upper-bound on the DC, I measured how DCmax varied with laser current, where DCmax is the DC for the best alignment I could get. After setting the current, the laser was modulated at 33MHz and the beam was aligned such that the 33MHz peak in the photodetector output was as tall as I could manage. Then DC was measured. See IvsDCmax.png. Note the DC is negative. I don't know why.

Also, the TV's don't look normal, the alarm's going off and I don't think the mode cleaner's locked.
Attachment 1: IvsDCmax.png
IvsDCmax.png
Attachment 2: data.tar.gz
Attachment 3: jcal_dip_2_norm_log.png
jcal_dip_2_norm_log.png
Attachment 4: jcal_flat_3_norm_log.png
jcal_flat_3_norm_log.png
  1189   Tue Dec 9 10:48:17 2008 CarynSummaryGeneralcalibrating the jenne laser: impedance mismatch?

We sent RFout of network analyzer to a splitter, with one side going back to the network analyzer and the other to the laser modulation input. We observed a rippled transfer function through the splitter. The ripple is probably due to reflection due to an impedance mismatch in the laser.
Attachment 1: reflection.png
reflection.png
  8255   Fri Mar 8 02:17:04 2013 yutaUpdateLSCcalibration of PRM actuator

[Manasa, Yuta]

We measured AC response of PRM actuator using PRM-ITMY cavity.
Result is

PRM:  (19.6 +/- 0.3) x 10^{-9} (Hz/f)^2 m/counts

It is almost the same as in 2011 (elog #5583). We took the same procedure as what Kiwamu did.

What we did:
  1. Aligned PRMI in usual procedure, mis-aligned ITMX and locked PRM-ITMY cavity using REFL55_Q_ERR. POP DC was about 18 when locked.

  2. Made UGF of PRM-ITMY cavity lock at 10 Hz and introduced elliptic LPF at 50 Hz(OLTF below).
OLTF_PRCL.png


  3. Measured transfer function from C1:LSC_ITMY_EXC to C1:LSC_REFL55_Q_ERR. Dividing this by ITMY actuator response(measured in elog #8242) gives calibration of REFL55_Q.

  4. Measured transfer function from C1:LSC_PRM_EXC to C1:LSC_REFL55_Q_ERR to calibrate PRM actuator.

Result:
  Calibration factor for REFL55_Q for PRM-ITMY cavity was (1.37 +/- 0.02) x 10^9 counts/m (plot below). Error is mainly from statistical error of the average.
calibREFL55Q.png


  Measured AC response (50-200 Hz) of PRM is below.
actcalibPRM.png


Next:
  - Measure free-run length spectrum of PRM-ITMY cavity and compare with MICH free-run.

  5637   Sat Oct 8 00:44:42 2011 kiwamuUpdateLSCcalibration of SRM actuator

The AC response of the SRM actuator has been calibrated.

 actuators.png
(Summary of the calibration results)
     BS = 2.190e-08 / f2     [m/counts]
     ITMX  = 4.913e-09 / f2   [m/counts]
     ITMY  = 4.832e-09 / f2   [m/counts]
     PRM   = 2.022e-08 / f2  [m/counts]
     SRM   = 2.477e-08 / f2  [m/counts]    ( NEW ! ) 
 
(Measurement)
The same technique as I reported some times ago (#4721) were used.
The Signal-Recycled ITMY was locked for measuring the actuator response.
Since the ITMY actuator had been already calibrated, first the sensor was calibrated into [counts/m] by exciting the ITMY actuator and then calibrated the SRM actuator with swept sine measurement.
 
 - - notes to myself
   SRCL GAIN = 2.2
   Sensor = REFL11_I
   Demod. phase = 40 deg
   Resonant condition = Carrier resonant
   Gain in WF = 0 dB

Quote from #5583
The AC responses of the BS, ITMs and PRM actuators have been calibrated.

 

  7738   Wed Nov 21 21:06:13 2012 AyakaUpdateLSCcalibration of arms

Motivation

In order to estimate whether we can see acoustic coupling in arms or not, we have to calibrate signals to phase noise.

Method

I used the same method as Yuta and Jenne did (6834).
I switched from ETM locking to ITM locking since only ITM actuators are calibrated (5583), and measured the open loop transfer function and the transfer function from ITM excitation to POX/POY error signal. Then I can estimate the calibration value H [counts/m] from POY/POX error signal to displacement.

Results

Yarm; H = 9.51 x 1011 counts/m
  OL_y.pngerr_exc_y.pngPOY_disp_y.png

Xarm; H = 6.68 x 1011 counts/m
OL_x.pngerr_exc_x.pngPOX_disp_x.png

Phase noise in arms:
XY_phase.png
blue; Xarm, green; Yarm

 

Next Step

I will calibrate the acoustic signal and see if it is reasonable that we can see the acoustic coupling signal in the arms.
But I guess it is difficult. Actually I have not seen coherence between ETM feedback signals and acoustic sounds yet. (I measured acoustic noise near POX and in PSL table.)

If I find that it is hopeless, I will create some sounds and try to measure transfer function from acoustic sound to arm cavity signals.
I am interested in how the transfer function calculated by wiener filtering is different from the measured transfer function.

 

Note

I found that we do not have enough phase margin. This is why the arm locking is not so stable.

  7739   Sat Nov 24 13:58:07 2012 ranaUpdateLSCcalibration of arms

For the loop diagnosis, its best to use the method of "IN1/IN2", rather than manipulate the close loop gain. In this way, you can directly plot the swept sine measurement from DTT as the open loop gain.

Also, for reporting calibration, we should all try to record the current settings better. Anything that may change the loop gain should be recorded along with the Bode plot and the DATA must be posted to the elog - no more of just posting plots.

We need to know, e.g.

  1. what is the power in the arms?
  2. are the LSC whitening filters on?
  3. are the SUS dewhitening filters on?
  4. What normalization is being used in the LSC?
  5. What digital filters are on in the X/YARM loop filter bank?

Resistance is feudal.

  7743   Mon Nov 26 10:42:06 2012 AyakaUpdateLSCcalibration of arms

I uploaded a zip file that contains data files used for the calibration.

OLTF_x/y.txt: the open loop transfer function (measured by IN1/IN2 in arm servo filter bank).
coh_x/y.txt: coherence of OLTF. I used the data where coherence > 0.98.
ext_err_x/y.txt: the transfer function from ITM excitation signal to POX/POY error signal.
coh_x2/y2.txt: coherence of ext_err. I used the data where coherence > 0.98.

The LSC whitening filter was off because the xarm was unlocked when the POX Q whitening filter was turned on. (We have to study what was wrong.)
The SUS whitening filters were on.
The all digital filters except +6dB filter were on.

Attachment 1: armcalib.zip
  8009   Wed Feb 6 15:05:18 2013 SteveUpdateSAFETYcameras must be anchord

Cameras must be immediately anchord to avoid a possible collusion with the view port !

Attachment 1: IMG_0070_1.JPG
IMG_0070_1.JPG
Attachment 2: IMG_0069_1.JPG
IMG_0069_1.JPG
  7178   Tue Aug 14 14:26:40 2012 SteveUpdateCamerascameras touched up

 I optimized the TM views with illuminator light on quad1  It actually looks better there.

I'll post a dark-  OSEM light only in jpg tomorrow.  ETMY camera is malfunctioning in dark condition now.

 

Attachment 1: cameras.png
cameras.png
  2453   Sun Dec 27 20:05:28 2009 kiwamuUpdateComputerscan not communicate with front-ends

In this evening I found that fb40m has been down, then I restarted fm40m successfully.

However there still is a problem, the reflective memory can not communicate with some front-end CPUs ( such as c1iscey, c1susvme, ...etc.)

Right now I don't have any ideas about this, I am leaving them as they are now .... we can deal with them tomorrow. 


The followers are what I did.

(1) ssh to fb40m then "pkill tpman"

(2) telnet to fb40m then typed "shutdown". ( These procedure are on the 40m wiki)

(3) make sure fb40m gets recovered while watching the medm screen C0DAQ_DETAIL.adl

(4) run the backup script in fb40m

(5) in order to fix the communication problem, physically turn off c1dcuepics and c0daqctrl

(6) keying some front-end CPUs. ---> still some of front ends indicate RED on the medm screen C0DAQ_DETAIL.adl ( figure attached )

 

 

Attachment 1: C0DAQ_DETAIL.png
C0DAQ_DETAIL.png
  8714   Mon Jun 17 23:12:19 2013 ManasaUpdateGreen Lockingcan't get IR to resonate

What I did: 

1. Followed the same procedure to enable ALS (http://nodus.ligo.caltech.edu:8080/40m/8703)
2. Enabling ALS servo stabilized the arm fluctuation and the beat frequency.
3. Beat frequency sweep was done (with ALS servo enabled) by changing offset C1:ALS-BEATX_FINE_OFFSET_OFFSET in steps.

Discussion:

I swept the beat frequency through ~10MHz and could not find IR resonance. But TRY TRX varied from 0 - 0.9 counts as the beat frequency sweep was done. I suspected that the offset steps might have been too big and I had jumped over the IR resonance. So, I repeated the offset sweep again in smaller steps (offset steps 0.1) and it did not help. 
I also played with the gain of the ALS servo to stabilize the loop and set the gain to the maximum (smallest error signal oscillating around '0') and did the frequency sweep. The arm cavity would still not resonate through the sweep but only evolve from no flashes to strong flashes for IR (0 - 0.9 counts).
  1836   Wed Aug 5 15:33:05 2009 rob, albertoDAQGeneralcan't get trends

We can't read minute trends from either Dataviewer or loadLIGOData from before 11am this morning. 

 

fb:/frames>du -skh minute-trend-frames/
 106G   minute-trend-frames

So the frames are still on the disk.  We just can't get them with our usual tools (NDS).

 

 Trying to read 60 days of minute trends from C1:PSL-PMC_TRANSPD yields:

Connecting to NDS Server fb40m (TCP port 8088)
Connecting.... done
258.0 minutes of trend displayed
read(); errno=9
read(); errno=9
T0=09-06-06-22-34-02; Length=5184000 (s)
No data output.

 

Trying to read 3 seconds of full data works.

Second trends are readable after about 4am UTC this morning, which is about 9 pm last night.

 


  1841   Thu Aug 6 09:22:17 2009 AlbertoDAQGeneralcan't get trends

Quote:

We can't read minute trends from either Dataviewer or loadLIGOData from before 11am this morning. 

 

fb:/frames>du -skh minute-trend-frames/
 106G   minute-trend-frames

So the frames are still on the disk.  We just can't get them with our usual tools (NDS).

 

 Trying to read 60 days of minute trends from C1:PSL-PMC_TRANSPD yields:

Connecting to NDS Server fb40m (TCP port 8088)
Connecting.... done
258.0 minutes of trend displayed
read(); errno=9
read(); errno=9
T0=09-06-06-22-34-02; Length=5184000 (s)
No data output.

 

Trying to read 3 seconds of full data works.

Second trends are readable after about 4am UTC this morning, which is about 9 pm last night.

 


 Yesterday Alex started transferring the data records to the new storage unit. That prevented us from accessing the trends for a fe hours.

The process had been completed and now we can read the trends again.

  8143   Sat Feb 23 07:14:58 2013 yutaUpdateLSCcan't lock Y arm

I tried to align and lock Y arm for the first time after pumping.
But I couldn't lock Y arm for more than ~1 sec. Why?


What I did:
  1. Centered IPANG/IPPOS using input TT1/TT2.

  2. Restored ITMY/ETMY slider values when it was aligned before pumping. I saw tiny flashes in TRY PD at this point.

  3. Replaced Ygreen REFL camera with ETMYT camera to see transmitted beam mode.

  4. Used TT1/TT2 and ITMY/ETMY to get ~ 0.4 peak in normalized TRY PD output (C1:LSC_TRY_OUT).

  5. Centered POY beam on POY11 PD.

  6. Changed I/Q mixing angle (C1:LSC-POY11_PHASE_R) from -61 deg to -16 deg to get good PDH signal in I_ERR (attached).

  7. Ran LSCoffsets script (now on LSC_OVERVIEW screen) to adjust PD offsets.

  8. Tried to lock Yarm with different gains, but failed. When lock is acquired, TRY fluctuates ~50 % and unlocks suddenly.


What I found:
  1. There was some OFFSETs left turned on in suspension screens. Don't leave them on!! They change alignment of the optics. I will leave it on until we complete Yarm alignment.

  2. C1:SUS-(ITMY|ETMY)_ASC(PIT|YAW) was kept oscillating the optic since Dec 17, 2013. I think this is from interrupted ASS script. Your script should restore everything when interrupted!


Next:
  - Beamspot on ITMY looks off-centered. Maybe A2L is causing unstable lock?
  - Maybe F2A is causing unstable lock?
  - More alignment?
  - FSS related? crontab related?

Attachment 1: TRYPOY.png
TRYPOY.png
  8149   Sat Feb 23 16:54:24 2013 JenneUpdateLSCcan't lock Y arm

I'm not sure that Yuta had found the real Yarm flashes last night.  When I came in today, the Yarm would flash.  However I found that the SRM was aligned, and if I misaligned it, the Yarm flashes would disappear.  So somehow the beam getting into the cavity was related to the reflection off of the SRM.

Later, I moved the TTs, leaving ITMY and ETMY alone, after having misaligned SRM (and ITMX) and I found flashes.  This wasn't ideal though, since the beam was much, much too high on IPANG (beam was half falling off the top of the lens, although yaw was pretty good).  That was also when I changed out the ETMYT camera the first time around.  The flashes on the new camera were visible, but much dimmer than with the Watec.

I tried locking the Yarm in this state, but I could never achieve a lock, even momentarily.  It almost seemed like I wasn't sending actuation signal out to the coils, although signal appeared all the way through the chain until the LSC signal summed with the local damping signal.  I also switched the LSC output matrix to try actuating on the ITM, but I was also not able to lock then.  I have switched it back to have Yarm actuate on ETMY.  I could see a nice PDH signal on POY, and nice flashes on TRY, but no lock at all.  The trigger was triggering, but still no catching of the lock.  I'm not really sure what's up.

After playing with a non-locking, poorly aligned Yarm, I started over by recentering the beam on IPPOS and IPANG using the TTs, but have not been able to get flashing in the cavity again.  After much fitzing around, I put the Watec back at ETMYT, in hopes that we can see flashes again at some point, since it's more sensitive than the old Sony.  Still no flashes though.

I have to leave, but Yuta and Manasa are here, and so I'm leaving the IFO in their custody.

  8150   Sat Feb 23 17:14:59 2013 yutaUpdateLSCcan't lock Y arm

Jenne found that;
  0. If all mirrors are "aligned," Yarm flashes.
  1. If SRM is misaligned, Yarm doesn't flash.
  2. If BS is misaligned, Yarm doesn't flash.
  3. If ITMX is misaligned, Yarm still flashes.

So, my hypothesis from this is that I was playing with " TT1 -> TT2 -> ITMY -> BS -> SRM -> BS -> Yarm "  configuration last night.
This hypothesis can explain;
  1. Why I could not get TRY peak more than 0.5 (additional BS reflection makes incident power to Yarm less).
  2. Why I had to change POY11 I/Q mixing angle by ~ 45 deg (because EOM to Yarm length changed).
  3. Why I couldn't lock Yarm stably (additional reflection by BS and SRM made too much beam jitter?).

We are now trying to get "real" Yarm flash.

  6816   Thu Jun 14 01:36:34 2012 yutaUpdateGreen Lockingcan't scan Y arm for 1FSR

[Jenne, Koji, Yuta]

We tried to scan of the Y arm but we couldn't scan for more than 1FSR.
In principle, we can do that because the error signal we are using, C1:ALS-BEATY_COARSE_I_IN1, has the range of ~ 40 MHz, which is about 10FSR (see elog http://nodus.ligo.caltech.edu:8080/40m/6815).

ALS stays for more than 10 min when we don't do the scan. If we put some offset gradually from C1ALS-OFFSETTER2, the lock breaks.
We monitored PZT output of the Y end laser, C1:GCY-SLOW_SERVO1_IN1, but it stayed in the range when scanning. So, there must be something wrong in the ALS loop.

Current in-loop arm length fluctuation is about 0.1 nm RMS (0.5 counts RMS).
Below is the spectrum of the error signal when the ALS is off(green) and on (pink,red). Below ~ 50 Hz, the measurement of the Y arm length is limited by ADC noise (~ 2uV/rtHz).
BEATY_COARSE_LoopOnOff.png

  14336   Fri Dec 7 19:42:47 2018 ranaFrogselogcan't upgrade DokuWiki because of PHP / SL7

All of our wikis (except the 40m one which unfortunately got turned into ligo.org mess) use DokuWiki. This now has an auto-upgrade feature through the Admin web interface.

I tried this recently and it fails with this message:

DokuWiki 2018-04-22a "Greebo" is available for download.
 You're currently running DokuWiki Release 2017-02-19e "Frusterick Manners".
! New DokuWiki releases need at least PHP 5.6, but you're running 5.4.16. You should upgrade your PHP version before upgrading!

So we'll have to wait until SL7 (which is what NODUS is running).

I DID do a 'yum upgrade' which updated all the packages. I also installed yum-cron so that the RPM listings get updated daily. But sadly, SL7 only has PHP 5.4.16 (which is a June 2013 release):

> Package php-5.4.16-43.el7_4.1.x86_64 already installed and latest version

  4667   Mon May 9 16:12:49 2011 JamieConfigurationCDScanonicalize paths to core and userapps

I have updated the /opt/rtcds paths to reflect the new specification of the CDS aLIGO code release procedures document.


Path to RTS/opt/rtcds/caltech/c1/core/release

This is where the advLigoRTS front-end code generator is checked out.  The "release" directory is a link to the svn branch from which we are currently running ("trunk" by default).

This used to be at /opt/rtcds/caltech/c1/core/advLigoRTS


Path to userapps: /opt/rtcds/caltech/c1/userapps/release

This is where the cds_user_apps code is checked out.  cds_user_apps is where all of the front-end models, medm screen, scripts, etc. will live.  The "release" directory is a link to the svn branch from which we are currently running ("trunk" by default).

This was most recently at /opt/rtcds/cds_user_apps

 

  10938   Fri Jan 23 19:38:02 2015 JenneUpdateLSCcarm_cm_up supports both signs of CARM offset

A small change, but now the carm_up script supports both sides of the CARM offset.  After the arms are locked with ALS it asks for a "+" or a "-", which indicates which sign of digital CARM offset will be added.  In the past, we have been primarily using the "+" sign.
 

  12965   Wed May 3 16:12:36 2017 johannesConfigurationComputerscatastrophic multiple monitor failures

It seems we lost three monitors basically overnight.

The main (landscape, left) displays of Pianosa, Rossa and Allegra are all broken with the same failure mode:

their backlights failed. Gautam and I confirmed that there is still an image displayed on all three, just incredibly faint. While Allegra hasn't been used much, we can narrow down that Pianosa's and Rossa's monitors must have failed within 5 or 6 hours of each other, last night.

One could say ... they turned to the dark side cool

Quick edit; There was a functioning Dell 24" monitor next to the iMac that we used as a replacement for Pianosa's primary display. Once the new curved display is paired with Rossa we can use its old display for Donatella or Allegra.

  12966   Wed May 3 16:46:18 2017 KojiConfigurationComputerscatastrophic multiple monitor failures

- Is there any machine that can handle 4K? I have one 4K LCD for no use.
- I also can donate one 24" Dell

  12971   Thu May 4 09:52:43 2017 ranaConfigurationComputerscatastrophic multiple monitor failures

That's a new failure mode. Probably we can't trust the power to be safe anymore.

Need Steve to order a couple of surge suppressing power strips for the monitors. The computers are already on the UPS, so they don't need it.

  12978   Tue May 9 15:23:12 2017 SteveConfigurationComputerscatastrophic multiple monitor failures

Gautam and Steve,

Surge protective power strip was install on Friday, May 5 in the Control Room

Computers not connected to the UPS are plugged into Isobar12ultra.

Quote:

That's a new failure mode. Probably we can't trust the power to be safe anymore.

Need Steve to order a couple of surge suppressing power strips for the monitors. The computers are already on the UPS, so they don't need it.

 

Attachment 1: Trip-Lite.jpg
Trip-Lite.jpg
  12993   Mon May 15 20:43:25 2017 ranaConfigurationComputerscatastrophic multiple monitor failures

this is not the right one; this Ethernet controlled strip we want in the racks for remote control.

Buy some of these for the MONITORS.

Quote:

Surge protective power strip was install on Friday, May 5 in the Control Room

Computers not connected to the UPS are plugged into Isobar12ultra.

Quote:

That's a new failure mode. Probably we can't trust the power to be safe anymore.

Need Steve to order a couple of surge suppressing power strips for the monitors. The computers are already on the UPS, so they don't need it.

 

  8586   Wed May 15 23:38:04 2013 ranaUpdateelogcategories trimmed

I deleted a bunch of useless categories from the 40m elogd.cfg file. IF you find your category has been deleted, you can now learn how to categorize yourself into the existing categories. ELOG restarted and log file zeroed.

  6922   Thu Jul 5 13:38:05 2012 yutaSummaryLockingcavity g-factor from mode scan

Cavity g-factor for X arm is 0.3737 +/- 0.002, Y arm is 0.3765 +/- 0.003.
If ITMs are flat and arm length L = 39 +/- 1 m, this means RoC of ETMX and ETMY is 62 +/- 2 m and 63 +/- 2 m respectively.

Calculation:
  Transverse mode spacing is expressed by

nu_TMS / nu_FSR = arccos(sqrt(g1*g2)) / pi

  where g1 and g2 is g-factor

gi = 1 - L/Ri

 of ITM/ETM.

  For mode-scan, we swept laser frequency nu. Let's assume this sweep was linear and we can replace laser frequency with time. From the mode-scan result, TMS can be derived by

  t_TMS = sum((n_i-n)*(t_i-t)) / sum((n_i-n)^2)

  where n_i is the order of transverse mode, n is average of n_i's, t_i is the time i-th order mode appeared and t is average of t_i's.
  Since I could only recognize up to 3rd order mode, this can be rewritten as

  t_TMS = 1.5/5 * t_0 + 0.5/5 * t_1 - 0.5/5 * t_2 - 1.5/5 * t_3

  FSR is time between TEM00s. So, g1*g2 can be calculated by

g1*g2 = (cos(pi*t_TMS/t_FSR))^2


X arm result:

  From the 8FSR mode-scan data (see elog #6859), X arm HOM positions in sec are;

HOM 0    242.00     214.76     187.22     159.27     131.33    102.96     74.61     46.00     17.51
HOM 1    234.29     206.78     179.20     150.96     122.90     94.58     66.27     38.10
HOM 2    226.36     198.91     170.80     142.92     114.62     86.51     58.05     29.65
HOM 3    218.14     190.65     162.71     134.78     106.68     78.27     49.95     21.25


  Calculated FSR and TMS in sec are;

FSR    27.24     27.54     27.95     27.94     28.37     28.35     28.61     28.49
TMS     7.951     8.020     8.193     8.151     8.223     8.214     8.220     8.270

  Calculated cavity g-factor are;

g1*g2    0.3699     0.3720     0.3662     0.3704     0.3761     0.3765     0.3839     0.3748

  By taking average,

g1*g2 = 0.3737 +/- 0.002  (error in 1 sigma)


Y arm result:
  From 8FSR mode-scan data (see elog #6832), Y arm HOM positions in sec are;

HOM 0    246.70     218.15     190.06     161.87     133.26    104.75     76.01     47.19     18.60
HOM 1    238.83     210.55     181.88     153.47     124.93     96.08     67.51     39.01
HOM 2    230.48     202.21     173.64     144.80     116.43     86.17     59.84     31.43
HOM 3    222.15     193.47     165.33     137.13     108.60     80.04     51.17     22.25


  Calculated FSR and TMS in sec are;

FSR    28.55     28.09     28.19     28.61     28.51     28.74     28.82     28.59
TMS     8.200     8.238     8.243     8.289     8.248     8.404     8.219     8.240


  Calculated cavity g-factor are;

g1*g2    0.3841     0.3657     0.3683     0.3765     0.3778     0.3683     0.3904     0.3811

  By taking average,

g1*g2 = 0.3765 +/- 0.003  (error in 1 sigma)


Conclusion:
  If ITMs are flat and arm length L = 39 +/- 1 m, this means RoC of ETMX and ETMY is 62 +/- 2 m and 63 +/- 2 m respectively. Designed RoC is 57.35 m.
  Error of RoC is dominated by arm length error. So, we need more precise measurement of the length. This can be done when scan is calibrated and we can measure FSR in frequency.
  Also, we need evaluation of linearity of the sweep. This also can be done by calibration.

  4198   Tue Jan 25 05:26:51 2011 kiwamuUpdateGreen Lockingcavity scan

cavity_scan.png

I scanned the X arm by changing an offset for the feedback to ETMX while the arm stayed locked by the green locking.

But the resultant plot is still far away from a beautiful one.

Changing the offset broke the lock frequently, so eventually I couldn't measure the stability of the IR-PDH signal at the resonance. 

 

 The plot above is a result of the scanning. You can see there is a clear resonance at the center of the plot.

However the lock frequently became unstable when I was changing the offset.

It looked like this unstability came from the end PDH lock. I guess there are two possible reasons:

  (1)  feedback range for the laser PZT is not wide enough. Right now the range is limited by a SR560, which has been used for a summing amplifier.

  (2)  Length to Alignment coupling. Pushing ETMX causes a misalignment.

The issue (1) can be easily solved by engaging the temperature feedback, which helps actuating the laser frequency a lot at DC.

The issue (2) will be also solved by well align the IR beam, the arm cavity and the green beam.

  4205   Wed Jan 26 10:11:47 2011 AidanUpdateGreen Lockingcavity scan

Quote:

cavity_scan.png

 

Whether or not it's as clean as we'd like, it's really nice to see this result with real data.

  7270   Fri Aug 24 13:22:19 2012 DenUpdateModern Controlcavity simulation

I did a simulation of a cavity, feedback signal was calculated using LQG controller. I assumed that there is not length -> angle coupling and 2 mirrors that form the cavity have the same equation of motions (Q and eigen frequencies are the same). Cost functional was chosen in such a way that frequencies below 15 Hz contribute much more then other frequencies.

model.png             controller.png              cavity.png

Gains in the controller are calculated to minimize the cost functional.

cavity_lqg.png

This technique works well, but it requires full information about the system states. If we do not assume that cavity mirrors have the same equations of motion then we need to apply Kalman filter to approximate the position of one of the mirrors.

  7363   Fri Sep 7 15:58:29 2012 Rijuparna ChakrabortyUpdate cavitymode scan

 IMC transmission photodiode has been aligned.

  7366   Fri Sep 7 17:37:16 2012 JenneUpdate cavitymode scan

Quote:

 IMC transmission photodiode has been aligned.

 Which PD?  The 'regular' DC one, or the newer one?  Why did it need realigning?  What mirrors did you touch to do the alignment?

Did you do anything else in the last 3 days?  I want to see ALL the gory details, because it can help people doing future measurements, or help us debug if something is wrong with the interferometer later.

MORE WORDS! Thanks.

  7368   Sat Sep 8 00:15:57 2012 Rijuparna ChakrabortyUpdate cavitymode scan

Quote:

Quote:

 IMC transmission photodiode has been aligned.

 Which PD?  The 'regular' DC one, or the newer one?  Why did it need realigning?  What mirrors did you touch to do the alignment?

Did you do anything else in the last 3 days?  I want to see ALL the gory details, because it can help people doing future measurements, or help us debug if something is wrong with the interferometer later.

MORE WORDS! Thanks.

 No, not the "regular DC one", the "newer one"  along with the controls of the corresponding mirror only i touched.

It needed to be realigned cause last week when we fitted a longer cable there, which may reach the network analyzer, it got misaligned since it got touched.

No other component in that box except that PD and the corresponding mirror controls I touched.

For my last 2 days work, I feel my last elog is reliable.

Today other than doing this, I checked for the higher order modes of the cavity, misaligning one of the MC mirror though the software only. I didn't mention it in my elog cause although I saw the presence of the higher order modes I didn't record it, so I can not upload any picture in support of such a statement.

Thanks

  7376   Wed Sep 12 19:26:08 2012 Rijuparna ChakrabortyUpdate cavitymode scan

 Summary: Recorded the presence of higher order modes in IMC

What I did: Misaligned the flat mirror MC1 by small amount in both pitch and yaw (it was needed to be done cause at the beginning of the experiment no higher order modes were present)  and scanned the cavity for frequency-range 32MHz to 45MHz.

I found the presence of higher order modes around 36.7MHz (1st order)  and 40.6MHz (2nd order) along with two other strong modes near 35MHz and 42.5MHz.

 

Attachment 1: P120912_11.32.jpg
P120912_11.32.jpg
Attachment 2: P120912_14.13.jpg
P120912_14.13.jpg
Attachment 3: P120912_14.17.jpg
P120912_14.17.jpg
Attachment 4: P120912_11.25.jpg
P120912_11.25.jpg
Attachment 5: P120912_14.09.jpg
P120912_14.09.jpg
Attachment 6: P120912_14.30.jpg
P120912_14.30.jpg
Attachment 7: P120912_14.34.jpg
P120912_14.34.jpg
  7486   Thu Oct 4 23:01:49 2012 RijuparnaConfiguration cavitymode scan

 Here I am attaching the schematic diagram of the experimental set-up for IMC cavitymode scanning. A 30- 45MHz scanning signal generated by Agilent 4395A network analyzer enters EOM, which in turn modulates the laser beam entering IMC. The cavity response can be verified from reflected/transmitted beam.

I worked with the reflected beam last days. But I got no clue about the percentage of  reflected light reaching the photodiode and also the photodiode response. I would like to measure the power reaching photodiode and also would like to perform the test with transmitted beam - on wednesday if possible.

 

Attachment 1: diagram1.pdf
diagram1.pdf
  7519   Wed Oct 10 15:31:59 2012 RijuparnaUpdate cavitymode scan

 Rijuparna, Jenne

Today I checked the optical lay-out in MC REFL board of the MC REFL path on the AS table (I will put the updated diagram in a few hours), and took a record of the reflected power of unlocked MC and power entering MC REFL PD. The power coming out of MC cavity when unlocked is 1.25W and power entering REFL PD 112mW (Jenne measured these powers for me). 

I also got a description of the MC demodulation board from Jenne.

(Edits by Jenne)

  7520   Wed Oct 10 15:46:23 2012 JenneUpdate cavitymode scan

Quote:

 Rijuparna, Jenne

Today I checked the optical lay-out in MC REFL board of the MC REFL path on the AS table (I will put the updated diagram in a few hours), and took a record of the reflected power of unlocked MC and power entering MC REFL PD. The power coming out of MC cavity when unlocked is 1.25W and power entering REFL PD 112mW (Jenne measured these powers for me). 

I also got a description of the MC demodulation board from Jenne.

(Edits by Jenne)

 Also, when I walked through the control room later, the WFS were driving the MC crazy.  I turned off / disabled the WFS from the WFS screen.   In my infinite spare time, I need to put in the real-time triggering, so that the WFS turn off as soon as the cavity unlocks. 

  7537   Fri Oct 12 15:31:03 2012 RijuparnaConfiguration cavitymode scan

 Rijuparna, Manasa

Today I have checked the optical layout of the MC transmission RFPD table and measured the laser powers at different points. Manasa helped me for that. I found the power entering the RF photodiode is 0.394mW while the transmitted power of the cavity is 2.46mW. (I will give the diagram later).

  7051   Mon Jul 30 15:49:16 2012 steveUpdateVACcc1 switched

Quote:

Our cold cathode 423 gauges are 10 years old. They get insulated by age and show no ionization current.  We should replace them at the next vent. I'm buying 4 at $317ea

 

 We have two CC1 gauges at the pump spool. One is in vertical position and the spare is in horizontal. Today I switched the cable from vertical to horizontal CC1

This one is reading higher pressure. It is an old dirty gauge. It may trigger the RGA protection when it's reading goes above 1e-5 torr

The real pressure is 2e-6 torr

Attachment 1: cc1changedfVtH.png
cc1changedfVtH.png
  7056   Tue Jul 31 08:01:22 2012 steveUpdateVACcc1 switched

Quote:

Quote:

Our cold cathode 423 gauges are 10 years old. They get insulated by age and show no ionization current.  We should replace them at the next vent. I'm buying 4 at $317ea

 

 We have two CC1 gauges at the pump spool. One is in vertical position and the spare is in horizontal. Today I switched the cable from vertical to horizontal CC1

This one is reading higher pressure. It is an old dirty gauge. It may trigger the RGA protection when it's reading goes above 1e-5 torr

The real pressure is 2e-6 torr

 cc1h spikes closed VM1 last night. VM1 is opened.

Attachment 1: cc1h1d.png
cc1h1d.png
  6562   Tue Apr 24 14:55:00 2012 JamieUpdateCDScds code paths (rtscore, userapps) have moved

NOTE: Unless you really care about what's going on under the hood, please ignore this entire post and go here: USE THE NEW RTCDS UTILITY

Quote:

  • the userapps directory is in a new place (/opt/rtcds/userapps).  Not everything in the old location was checked into the repository, so we need to check to make sure everything that needs to be is checked in, and that all the models are running the right code.

 An important new aspect of this upgrade is that we have some new directories and some of the code paths have moved to correspond with the "standard" LIGO CDS filesystem hierarchy:

  • rtscore:      /opt/rtcds/rtscore/release       -->  RTS RCG source code (svn: adcLigoRTS)
  • userapps: /opt/rtcds/userapps/release  -->  CDS userapps source for models, RCG C code, medm screens, scripts, etc (svn: cds_user_apps)
  • rtbuild:       /opt/rtcds/caltech/c1/rtbuild    -->  RCG build directory

All work should be done in the "userapps" directory, and all builds should be done in the build directory.  Some important points:

WARNING: DO NOT MODIFY ANYTHING IN RTSCORE

This is important.  The rtscore directory is now just where the RCG source code is stored.  WE NO LONGER BUILD MODELS IN THE RTS SOURCE  Please use the rtbuild directory instead.

NO MORE MODEL/CODE SYMLINKS

You don't need to link you model or code anywhere to get it to compile.  The RCG now uses proper search paths to source in the RCG_LIB_PATH to find the needed source.  This has been configured by the admin, so as long as you put your code in the right place it should be found.

ALL CODE/MODELS/ETC GO IN USERAPPS

All RTS code is now stored ENTIRELY in the userapps directory (e.g. /opt/rtcds/userapps/release/isc/c1/models/c1lsc.mdl).  This is more-or-less the same as before, except that symlinking is no longer necessary.  I have placed a symlink at the old location for convenience.

BUILD ALL MODELS IN RTSCORE

You can run "make c1lsc" in the rtbuild directory, just as you used to in the old core directory.  However, don't do that.  USE THE NEW RTCDS UTILITY instead.

  9321   Thu Oct 31 00:06:45 2013 masayukiUpdateComputer Scripts / Programscds fft,tf,offsets

I wrote the scripts for cdsutils.

1. fft

usage: fft.py [-h] [-c N_CYCL] [-a N_AVG] freq channel [channel ...]

Measures the frequency content of one or more NDS channels
at the specified frequecy.
    The measurement results are  magnitude, phase, real part imaginary part, and the standard deviation of the real and imaginary parts.

positional arguments:
  freq        measurement frequency
  channel     list of measurement channel

optional arguments:
  -h, --help  show this help message and exit
  -c N_CYCL   define number of cycles. Default is 10
  -a N_AVG    define number of average. Default is 100

2. tf

usage: tf.py [-h] [-c N_CYCL] [-a N_AVG] [--dB] freq input output

Measures the transfer funtion of one NDS channels pair  at the specified frequecy.
    The measurement results are the coherence, magnitude, phase, real part, imaginary part, and the standard deviation of the real and imaginary parts.

positional arguments:
  freq        measurement frequency
  input       list of measurement input channel
  output      list of measurement output channel

optional arguments:
  -h, --help  show this help message and exit
  -c N_CYCL   define number of cycles. Default is 10
  -a N_AVG    define number of average. Default is 100
  --dB        print the amplitude in dB

 

3.offsets

usage: offset.py [-h] [-t SECONDS] filterbank [filterbank ...]

Zero the offset of one or more filterbank. Take average of OUT16 channel, and put (-1 * average / gain) into offset.  After change offsets, it will turn on the offset.
    example usage) offset -d 25 C1:LSC-AS55_Q C1:LSC-AS55_I

positional arguments:
  filterbank  list of filterbank to zero offset

optional arguments:
  -h, --help  show this help message and exit
  -t SECONDS  define the averaging time. default value is 10

I put these scripts in /opt/rtcds/cdsutils/trunk/lib/cdsutils.
I couldn't put them into cds library, but I will left tomorrow to Japan...

So please help me Jamie or Joe !!

 

 

By the way,

I modified the LSCoffset script  (script)/LSC/LSCoffsets.py.

usage: LSCoffsets.py [-h] [-d SECONDS] [--PDlist]

 Zero the offsets of LSC PDs. During taking average, we will close the PSL and green shutter. After zeroing, it will turn on the offsets switch.
    example usgae) LSCoffset2.py -d 20    

optional arguments:
  -h, --help  show this help message and exit
  -d SECONDS  define the averaging time. default value is 10
  --PDlist    print PD list for LSC and exit

i made new directory 'offset_backup' for old offset script. I move all old offset script into there.

But unfortunately that cannot use right now, because cds offsets script is not available yet...

ELOG V3.1.3-