40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 45 of 341  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  7017   Tue Jul 24 03:14:13 2012 JenneUpdateASSCalibration of MC ASS lockins

I wanted to check that the calibration of the MC ASS lockins was sensible, before trusting them forevermore.

To measure the calibration, I took a 30sec average of C1:IOO-MC_ASS_LOCKIN(1-6)_I_OUT with no misalignment. 

Then step MC1 pitch by 10% (add 0.1 to the coil output gains).  Remeasure the lockin outputs.

2.63 / (Lockin1noStep - Lockin1withStep) = calibration.

Repeat, with Lockin2 = MC2 pit, lockin3 = MC3 pit, and lockins 4-6 are MC1-3 yaw.

 

The number 2.63 comes from: half the side of the square between all 4 magnets.  Since our offsets are in pitch and yaw, we want the distance between the line connecting the lower magnets and the center line of the optic, and similar for yaw.  Presumably if all of the magnets are in the correct place, this number is the same for all magnets.  The optics are 3 inches in diameter.  I assume that the center of each magnet is 0.9mm from the edge of the optic, since the magnets and dumbbells are 1.9mm in diameter. Actually, I should probably assume that they're farther than that from the edge of the optic, since the edge of the dumbbell ~touches the edge of the flat surface, but there's the bevel which is ~1mm wide, looking normal to the surface of the optic.  Anyhow, what I haven't done yet (planned for tomorrow...) is to figure out how well we need to know all of these numbers.

We shouldn't care more than ~100um, since the spots on the optics move by about that much anyway.

For now, I get the following #'s for the calibration:

Lockin1 = 7.83

Lockin2 = 9.29

Lockin3 = 8.06

Lockin4 = 8.21

Lockin5 = 10.15

Lockin6 = 6.39

The old values were:

C1:IOO-MC_ASS_LOCKIN1_SIG_GAIN = 7
C1:IOO-MC_ASS_LOCKIN2_SIG_GAIN = 9.6
C1:IOO-MC_ASS_LOCKIN3_SIG_GAIN = 8.3
C1:IOO-MC_ASS_LOCKIN4_SIG_GAIN = 7.8
C1:IOO-MC_ASS_LOCKIN5_SIG_GAIN = 9.5
C1:IOO-MC_ASS_LOCKIN6_SIG_GAIN = 8.5

The new values measured tonight are pretty far from the old values, so perhaps it is in fact useful to re-calibrate the lockins every time we try to measure the spot positions?

  4721   Sun May 15 19:10:12 2011 kiwamuUpdateLSCCalibration of actuators : BS, ITMX and ITMY

The AC response of the actuators on BS, ITMX and ITMY were re-measured by another technique.

Last time I estimated them by measuring the open-loop transfer functions, but this time the responses were measured in a more direct way.

The measured AC responses (60 Hz - 200 Hz) are :

      BS   = 1.643e-98 / f2  [m/counts] (corrected based on the plot below - Manasa)

     ITMX = 3.568e-9 / f2 [m/counts]

     ITMY = 3.542e-9 / f2 [m/counts]

Next : measurement of the PRM actuator response


(The technique) 

 This time a technique that Rana told me a week ago was used.

This technique allows us to directly measure the response of an actuator at high frequency without any loop corrections.

First of all, MICH has to be locked to keep MICH within the linear range of the error signal. So now MICH is a linear sensor to the mirror motions.

In the MICH control a steep low pass filter should be inserted in order to avoid unwanted effects from the control loop at the high frequencies.

For example I put a low pass filter composed of an elliptical filter whose cut-off frequency is at 50 Hz such that the control loop doesn't push the mirrors above the cut-off frequency.

Hence the error signal of MICH above 50 Hz directly corresponds to the motion of the mirrors including BS, ITMX and ITMY.

Taking a transfer function from an actuator to the MICH error signal directly gives the actuator response.

In my measurements MICH was locked by feeding the signal back to BS. The plot below is the expected open-loop transfer function for the MICH control.

oltf.png

You can see that the open loop TF suddenly drops above 50 Hz. The UGF was at about 20 Hz, confirmed by looking at the loop oscillation on DTT.

 

(Measurement)

 In the technique the error signal has to be calibrated to [m]. This time AS55_Q was used and calibrated based on a peak-to-peak measurement.

The peak to peak value in the MICH error signal was 8 counts, which corresponds to the sensor efficiency of 4.72e+07 [counts/m].

Then I took transfer functions from each suspension (i.e. C1:SUS-XXX_LSC_EXC) to the error signal at AS55_Q over a frequency range from 60 Hz to 200Hz.

For the transfer function measurements I ran the swept sine on DTT to get the data. Note that the PD whitening filters were on.

The plot below is the results of the measurements together with the fitting lines.

calib_actuators.png

In the fitting I excluded the data pints at 60 Hz, because their coherence was low due to the power line noise.

  10281   Mon Jul 28 16:34:02 2014 AkhilUpdateGeneralCalibration of measured Thermal Actuator TFs

 To calibrate the measured TFs and characterize the thermal actuator for the FOL loop, we [ Me, Eric Q, Koji ] made the TF measurements of PZT response by giving a  disturbance to the position of  each of X and Y arm ETM  and ITM.

In order to make reasonable conclusions, the measurements were done at frequencies greater than 20 Hz (assuming the PZT response to be flat till a few KHz), which is out of the  bandwidth of the control loops operating for other noises at low frequencies, so that we can get the response only( mainly) due to the disturbance of the masses. 

 For this measurement , a Sine sweep excitation was given as an input to one of the test mass and PZT actuation signal was monitored. The channels used for the measurement are: 

Input( Mirror displacement):

ITMX- C1:SUS-ITMX_LSC_EXC

ETMX- C1:SUS-ETMX_LSC_EXC

ITMY- C1:SUS-ITMY_LSC_EXC

ETMY- C1:SUS-ITMX_LSC_EXC

Output ( PZT Response):

C1:ALS-Y_SLOW_SERV_IN1

The units of the TF of these measurements are not calibrated  and are in count/count. For this I will use the ITMX and ITMY calibration values from Izumi's Elog. I will also make some calculations and post in the calibrations of ETMX and ETMY in a separate elog.

I am now estimating the calibrated Thermal Actuator TF and will estimate the location of poles and zeroes to build the PID loop. I will elog the final calibrated TFs in my next elog.

The attached are the Bode Plots  for ETM and ITM for X and Y arms.

Attachment 1: mirrorTF2.pdf
mirrorTF2.pdf
  11831   Tue Dec 1 11:26:23 2015 yutaroUpdateOptical LeversCalibration of oplevs for ITMX/ETMX

With the same method as reported in elog 11785, I calibrated oplevs for ITMX/ETMX.

 

RESULTS 

 

According to this measurement, ratio of the calibration factor derived with this measurement (NEW) and the calibration factor for now (OLD), i.e. NEW/OLD was:   

ETMX_PIT: 4.470

ETMX_YAW: 2.5970

ITMX_PIT: (-)1.1102

ITMX_YAW: 1.8173

 

NOTE

The calibration factors of the oplevs for ETMY/ITMY are   NOT UPDATED YET. I updated on Dec 11, 2015

 

Attachment 1: ep_l.pdf
ep_l.pdf
Attachment 2: ey_l.pdf
ey_l.pdf
Attachment 3: ip_l.pdf
ip_l.pdf
Attachment 4: iy_l.pdf
iy_l.pdf
  11842   Thu Dec 3 06:15:38 2015 ranaUpdateOptical LeversCalibration of oplevs for ITMX/ETMX

http://blogs.mathworks.com/loren/2007/12/11/making-pretty-graphs/

Let Loren help you make your Oplev data readable to humans.cool

  11843   Thu Dec 3 10:05:07 2015 yutaroUpdateOptical LeversCalibration of oplevs for ITMX/ETMX

I updated the figures. I think it's easier to read now.

  11875   Fri Dec 11 16:16:36 2015 yutaroUpdateOptical LeversCalibration of oplevs for ITMX/ETMX

Based on calibration measurement I have done (elog 11785, 11831), I updated calibration factors of oplevs on medm screen as follows. Not to change loop gain oplev servo, I also changed oplev servo gain.

C1:SUS-ETMX_OL_PIT_CALIB, C1:SUS-ETMX_OL_PIT_GAIN

(45.1,16) => (200,3.5)

C1:SUS-ETMX_OL_YAW_CALIB, C1:SUS-ETMX_OL_YAW_GAIN

(85.6,8) => (222,3.0) 

C1:SUS-ETMY_OL_PIT_CALIB, C1:SUS-ETMY_OL_PIT_GAIN

(26,-16) => (140,-3.0) 

C1:SUS-ETMY_OL_YAW_CALIB, C1:SUS-ETMY_OL_YAW_GAIN

(31,-21) => (143,-4.5) 

C1:SUS-ITMX_OL_PIT_CALIB, C1:SUS-ITMX_OL_PIT_GAIN

(110,8) => (122,7.2) 

C1:SUS-ITMX_OL_YAW_CALIB, C1:SUS-ITMX_OL_YAW_GAIN

(81,-11) => (147,-6) 

C1:SUS-ITMY_OL_PIT_CALIB, C1:SUS-ITMY_OL_PIT_GAIN

(159,15) => (239,10) 

C1:SUS-ITMY_OL_YAW_CALIB, C1:SUS-ITMY_OL_YAW_GAIN

(174,-21) => (226,-16) 

 

  11881   Mon Dec 14 23:49:03 2015 ericqUpdateOptical LeversCalibration of oplevs for ITMX/ETMX
Quote:

Based on calibration measurement I have done (elog 11785, 11831), I updated calibration factors of oplevs on medm screen as follows. Not to change loop gain oplev servo, I also changed oplev servo gain.

After making sure that the upper UGFs were properly in place, I saved these settings to the SDF files. Thanks Yutaro!

  11785   Wed Nov 18 22:26:33 2015 yutaroUpdateOptical LeversCalibration of oplevs for ITMY/ETMY

Based on elog 1403, I calibrated the oplevs for ITMY/ETMY.

Summary of this method is following:

We lock an arm, and slightly misalign one mirror of the arm. Then, the transmission of the arm starts to decrease quadratically as the misalign angle of the mirror changes. Here, how much the transmission decreases in terms of the misalign angle is determined by geometry of optics, so we can see how much the angle really changes from this quadratic curve.

 

RESULTS  

These are the relationship between misalign angles measured by oplev (the units are based on the calibration for now) and transmission power.

(I updated following figures on Nov 19 2015. You can find the figures I attached once here in the zipped folder attached.) 

 

 

According to this measurement, ratio of the calibration factor derived with this measurement (NEW) and the calibration factor for now (OLD), i.e. NEW/OLD was:  

ETMY_PIT: 5.0265  --->> 5.3922 (without an outlier; the outlier I removed is shown in the figure in zipped folder attached.)

ETMY_YAW: 4.6205

ITMY_PIT: 1.5010

ITMY_YAW: 1.2970

This results show that calibration of oplevs for ITMY is kind of OK, but that for ETMY is so BAD and the calibration factors should be updated.

 

NOTE

The calibration factors of the oplevs for ETMY/ITMY are   NOT UPDATED YET.  I updated on Dec 11, 2015

If these results are reliable, I will update them tomorrow.   

Attachment 1: calib_etmypit2.pdf
calib_etmypit2.pdf
Attachment 2: calib_etmyyaw2.pdf
calib_etmyyaw2.pdf
Attachment 3: calib_itmypit2.pdf
calib_itmypit2.pdf
Attachment 4: calib_itmyyaw2.pdf
calib_itmyyaw2.pdf
Attachment 5: calib_oplev.zip
  11787   Wed Nov 18 23:40:01 2015 ranaUpdateOptical LeversCalibration of oplevs for ITMY/ETMY

OMG. Please try to use larger fonts and PDF so that we can read the plots.

Quote:

Based on elog 1403, I calibrated the oplevs for ITMY/ETMY.

I'm not sure that these calibration measurements are reliable. I would feel better if Steve can confirm them using our low accuracy method of moving the QPD by 1 mm and doing trigonometry.

  11790   Thu Nov 19 16:06:54 2015 yutaroUpdateOptical LeversCalibration of oplevs for ITMY/ETMY

I'm sorry. I will be careful about that. And I updated the plots in elog 11785.

Quote:

OMG. Please try to use larger fonts and PDF so that we can read the plots.

 

Quote:
Quote:

Based on elog 1403, I calibrated the oplevs for ITMY/ETMY.

I'm not sure that these calibration measurements are reliable. I would feel better if Steve can confirm them using our low accuracy method of moving the QPD by 1 mm and doing trigonometry.

 In this morning, Steve and I looked at the ETMY table and we found that the measurement you suggested might interfere with other optics or detectors because of space constraint. So, before doing this measurement, I roughly estimated the calibration factors for ETMY oplev by using the rough value of the arm length of the optical lever and the beam width of the light just before the QPD.

 

How I got the arm length and the beam width:

I measured the length of the optical path between ETMY and the QPD. Then I measured the beam width with an iris to screen the beam. To get the beam width from the decrease of the power of the beam detected by QPD, I used this formula: P/P_{max}=1-\exp(-2r^2/w^2).

Then I got:   (arm length) = 1.8 +/-0.2 m,    w= 0.56 +/- 0.5 mm.

 

How I estimated the calibration factors from these:

The calibration factors (such as C1:SUS-ETMY_OL_PIT_CALIB; (real angle) / (normalized output of QPDXorY)) can be calculated with: \sqrt{\pi/32}\times w\,/\,(\mathrm{arm\,length}). Then, I got

130\,\pm\,20 \,\mu \mathrm{rad},

though the calibration factors, C1:SUS-ETMY_OL_PIT_CALIB C1:SUS-ETMY_OL_YAW_CALIB, right now are 26.0 and 31.0, respectively. (If I express this in the same way as elog 11785, 5.0 and 4.2 for ETMY_PIT and ETMY_YAW, respectively. they are consistent with yesterday's results.) 

I believe that the calibration factors I estimated today are not different from the true values by a factor of 2 or something, so this estimation indicates that the oplev calibration measurements I did yesterday are reliable, at least for the oplev for ETMY. 

 

 

  1415   Sun Mar 22 22:39:24 2009 ranaSummaryLSCCalibration of the ITM and ETM Actuation
I used the following procedure to calibrate the ITMX actuation signal.

Free Swinging Michelson:
------------------------
- Restore Michelson
- Align Michelson: Minimize AS_DC (PD3_DC_OUT) by tweaking BS alignment.
- Enable Whitening filters for PD1_Q and PD3_DC.
- Run offsets script to get rid of DC and RF offsets.
- Use DTT Triggered Time Series to get time series and measure peak-peak
amplitude of PD1_Q using DTT horizontal cursors. (Templates/Calibration/090322/FreeSwing.xml)

Michelson Sweeps:
-----------------
- Lock Michelson
- Drive ITMX_LSC_EXC using ITMX-MI-Sweep.xml template.
- (Next time remember to turn on a low pass in the MICH loop so that its an open loop measurement below 50 Hz).
- Fit and so some math.

Arm Sweeps for the ETMs:
------------------------
- Lock a single arm
- Sweep ITM & ETM.
- Then sweep MC2 and record drive signal from MC board to the VCO driver.
- Compare and contrast.
Attachment 1: free.png
free.png
  3091   Sun Jun 20 16:07:23 2010 KojiSummaryCOCCalibration of the metrology lab interferometer

Kiwamu and Koji

Summary

We have visited GariLynn's lab to make a calibration of the metrology interferometer. 

The newly calibrated value is

RoC(SRMU01) = 153.3+/- 1.6 [m]

This is to be compared with the specification of 142m +/- 5m

Although the calibration deviation from the previous value was found to be 1.3%, it is far from explaining the curvature difference between the spec (142m) and the measured value.


Motivation

The previous measurements of the SRM curvatures showed larger RoCs by ~10% compared with the spec.

It can be caused by the mis-calibration of the pixel size of the CCD in the metrology interferometer.
In order to confirm the calibration value, an object with known dimension should be measured by the instrument.

Method

We've got a flat blank optic from "Advanced Thin Film" together with a metalic ring.
The ring has been attached on the blank optic with 3 fragments of a double sided tape.
The RoC of SRMU1 was also measured in order to obtain "the radius of curvature of the day".

The calibration process is as follows:

  1. Measure the diameters of the ring by a caliper in advance to its attachment to the blank.
  2. Determine the inner and outer diameter of the ring in the obtained image.
    Note that the obtained image is pre-calibrated by the default value given by the measurement program
      (i.e. 0.270194mm/pixel for horizontal)
  3. Check the ratio of the diameters with the measured value by the caliper. Correct a systematic effect.
  4. Compare the image measurement and the caliper measurement.

Results

  1. The outer and inner diameters of 2.000" and 1.660" (measured by a caliper, error 0.005"). The ratio is 0.830+/-0.003.
  2. The center and radius for the inner circle were estimated to be (79.7924, 91.6372) and 21.4025 [mm].
    The center and radius for the outer circle were estimated to be (79.6532, 91.6816) and 25.6925 [mm].

    The error would be ~0.01mm considering they sweep 500 pixels by the circle and the pixel size is 0.27mm. i.e. 0.27/Sqrt(500) ~ 0.01mm
  3. Ratio of the inner and outer diameter is 0.8330 +/- 0.0005.
    The systematic error of x is given by solving (21.4025+x)/(25.6925-x)=0.83 ==> x = -0.042 +/- 0.043 [mm]. This is just a 0.2% correction.
    By correcting the above effect, we get (Rin, Rout) = (21.36 +/- 0.046, 25.74 +/- 0.047).
  4. By comparing the result with the caliper measurement, we get calibration factor of 1.013 +/- 0.005.
    This means we measured "1mm" as "1.013mm". The scale was too small.

    We have got the calibration of 0.2737+/-0.0014 [mm/pixel].

Discussion

Because of the calibration error, we measured too long RoC. The same day, we measured the curvature of SRMU01 as 155.26 m.
The newly calibrated value is

RoC(SRMU01) = 153.3+/- 1.6 [m]

This is the value to be compared with the specification of 142m +/- 5m

 

Attachment 1: ring1_inner_centering.pdf
ring1_inner_centering.pdf
Attachment 2: ring1_outer_centering.pdf
ring1_outer_centering.pdf
Attachment 3: SRMU01_pic.png
SRMU01_pic.png
  5443   Fri Sep 16 22:51:52 2011 PaulUpdateSUSCalibration plan for the oplevs

 In order to estimate the amount of noise that the oplevs are injecting into the GW channel, we first need to calibrate oplev signals in terms of angular change in the optic. I said in my previous post that there wasn't a calibration factor for OSEM values to radians, but I found that Kakeru had estimated this in 2009 - see entry 1413. However, Kakeru found that this was quite a rough estimate, and that it didn't agree with his calibrated oplev values well. He does quote the 2V/mm calibration factor for the OSEM readings though - does anyone know the provenance of this factor? I searched for OSEM calibration and found nothing.

 
Kiwamu and Suresh suggested a way to calibrate the oplevs without needing to calibrate the OSEMs in the way that Kakeru describes in entry 1413. This should give a calibration for the OSEMs _and_ the oplevs in fact. The method should be as follows:
 
1) Change the coil driver values in DC to give tip or tilt the optic. Measure the resulting change in spot position at a known distance from the optic, perhaps just using a ruler. Record the spot position and OSEM values for each coil driver value. This will definitely require a smaller spot size, so I'll implement the new telescopes first.
 
2) Knowing the length of the lever arm from the optic to the spot measurement position, we can calibrate the OSEM values to radians.
 
3) We can now put the beam onto the oplev QPD, and either change the coil driver values again in the same way (but over a smaller range), or excite the test mass in pitch or yaw, this time measuring both the OSEM values and the oplev QPD values. Since we can already convert from OSEM values to radians, we can now convert from oplev values to radians too.
 
4) I should be careful to consider the input sensing matrix for both the OSEMs and the oplevs in these measurements. Should I divide those out of the calibration to avoid that if they change the calibration factor changes too?
  5448   Sun Sep 18 14:08:52 2011 ranaUpdateSUSCalibration plan for the oplevs

We don't need a high quality calibration for the optical levers. ~50% accuracy is fine.

For that you can use the OSEM calibration of ~1.7 V/mm (its less than 2 since the OSEMs have been degrading) or you can use the cavity power method that Kakeru used; it worked just fine. There's no benefit in trying for a 1% number for optical levers.

  12743   Fri Jan 20 14:42:12 2017 SteveUpdatePEMCaltech weather station

We should be able to connect to this station

  16774   Wed Apr 13 15:57:25 2022 Ian MacMillanUpdateCamerasCamera Battery Test

Tested the Nikon batteries for the camera. they are supposed to be 7V batteries but they don't hold a charge. I confirmed this with multi-meter after charging for days. Ordered new ones Nikon EN-EL9

  16776   Wed Apr 13 18:55:54 2022 KojiUpdateCamerasCamera Battery Test

I believe that the Nikon has an exposure problem and that's why we bought the Canon.

 

  1333   Mon Feb 23 16:42:08 2009 josephbConfigurationCamerasCamera Beta Testing

I've setup the GC650 camera (ID 32223) to look at the mode cleaner transmission.  I've also added an alias to the camera server and client for this camera.

To use, type: "pserv1 &"on the machine you want to run the server on and "pcam1 &" on the machine you want to actually view the video.  At the moment, this only works for the 64-bit Centos 5 machines, Rosalba, Allegra and Ottavia.

Note, you will generally want to start the client first (pcam1 or pcam2) to see if a server is already running somewhere.  The server will complain that it can't connect to a camera if it already is in use.

I've setup the GC750 camera (ID 44026) to look at the the right most analog quad TV.  This can be run by using "pserv2 &" and "pcam2 &". 

If the image stops playing you can try starting and stoping the server to see if will start back up. 

You can also try increasing or decreasing the exposure, to see if that helps.  The increase and decrease buttons change the exposure by a factor of 2 for each press.

  Lastly, the button "Read Epic Channel" reads in the current value from the channel: "C1:PEM-stacis_EEEX_geo" and uses it as the exposure value, in microseconds (in principle 10 to 1000000 should work).

For example, to exposre for 10000 microseconds, use "ezcawrite C1:PEM-stacis_EEEX_geo 10000" and press the "Read Epic Channel" button.

  2371   Wed Dec 9 10:53:41 2009 josephbUpdateCamerasCamera client wasn't able to talk to server on port 5010, reboot fixed it.

I finally got around to taking a look at the digital camera setup today.  Rob had complained the client had stopped working on Rosalba.

After looking at the code start up and not complain, yet not produce any window output, it looks like it was a network problem.  I tried rebooting Rosalba, but that didn't fix anything.

Using netstat -an, I looked for the port 5010 on both rosalba and ottavia, since that is the port that was being used by the camera.  Ottavia was saying there were 6 established connections after Rosalba had rebooted (rosalba is 131.215.113.103).  I can only presume 6 instances of the camera code had somehow shutdown in such a way they had not closed the connection.

[root@ottavia controls]#netstat -an | grep 5010
tcp        0      0 0.0.0.0:5010                0.0.0.0:*                   LISTEN     
tcp        0      0 131.215.113.97:5010         131.215.113.103:57366       ESTABLISHED
tcp        0      0 131.215.113.97:5010         131.215.113.103:58417       ESTABLISHED
tcp        1      0 131.215.113.97:46459        131.215.113.97:5010         CLOSE_WAIT 
tcp        0      0 131.215.113.97:5010         131.215.113.103:57211       ESTABLISHED
tcp        0      0 131.215.113.97:5010         131.215.113.103:57300       ESTABLISHED
tcp        0      0 131.215.113.97:5010         131.215.113.103:57299       ESTABLISHED
tcp        0      0 131.215.113.97:5010         131.215.113.103:57315       ESTABLISHED

 

I switched the code to use port 5022 which worked fine.  However, I'm not sure what would have caused the original connection closure failures, as I test several close methods (including the kill command on the server end used by the medm screen), and none seemed to generate this broken connection state.  I rebooted Ottavia, and this seemed to fix the connections, and allowed port 5010 to work.  I also tried creating 10 connections, which all seem to run fine simultaneously.  So its not someone overloading that port with too many connections which caused the problem.  Its like the the port stopped working somehow, which froze the connection status, but how or why I don't know at this point.

  1355   Wed Mar 4 17:20:04 2009 josephbUpdateCamerasCamera code upgrades

I've updated the digital camera python code as well as changed the network topology.

At the moment, both cameras are connected to a small gigabit switch which only talks to Ottavia.  This means all camera servers must be run on Ottavia, allow camera output is still UDP multicast so any machine capable of running gstreamer can pick up the images.

The server and client programs now have the ability to read a configuration file for the setup of the cameras.  They default to pcameraSettings.ini, but this can default can be changed with a -c or --config option

For example, "serverV3.py --config pcam1.ini" will run the server using the pcam1.ini settings file.  Similarly, "client.py --config pcam1.ini" will also take the IP settings from the config file so that it knows at which port and IP to listen.

These programs and .ini files have been placed in /cvs/cds/caltech/apps/linux64/python/pcamera/

I've updated the cshrc.40m aliases so that it uses the new configuration file options, so now pcam1 calls "client.py -c pcam1.ini" in the above directory.

So to start a client use pcam1 or pcam2 (for the 32223 camera in PSL looking at MC trans or 44026 looking at an analog moniter in the control room respectively).  These can be run on Allegra, Rosalba or Ottavia at the moment.

To start a server, use pserv1 or pserv2.  These *must* be run on Ottavia.

I've also added a -n or --no-gui option at Yoichi's request, one which just starts up and plays, with no graphical gui.

Lastly, I've made some changes to the base pcamerasrc.py file, which should make display more robust.  After a failed transmission of an image from the camera to Ottavia, it should re-attempt up to 10 times before giving up. I'm hoping this will make it more robust against packet loss.  The change in network topology has also helped this, allowing 640x480 to be transmitted on both cameras before tens of minutes before a packet loss causes a stop.

  2470   Wed Dec 30 22:17:07 2009 kiwamuUpdateGeneralCamera input and monitor output

The input channels of the cameras and the output channels for the monitors are summarized on the wiki.

The channel table on the wiki is very helpful when you want to make a change in the video matrix.

thank you.

  7569   Wed Oct 17 18:41:27 2012 JenneUpdateCamerasCamera looking at ETMY baffle

The camera titled "watec_mobile" is looking at the front of the black glass baffle (i.e. the side facing the ITM) on the ETMY table.  This required (for my quick hacky solution) removing the regular ETMYF camera.  Steve has a genius plan (I think) so that we can have both at the same time.  Anyhow, eventually we'll move the black glass back, so we'll be back to needing just one camera.

After dinner, I'll try aligning the Yarm.

  2276   Mon Nov 16 17:24:28 2009 josephbConfigurationComputersCamera medm functionality improved

Currently the Camera medm screen (now available from the sitemap), includes a server and client script buttons.  The server has two options.  One which starts a server, the second which (for the moment) kills all copies of the server running on Ottavia.  The client button simply starts a video screen with the camera image.  The slider on this screen changes the exposure level.  The snap shot button saves a jpeg image in the /cvs/cds/caltech/cam/c1asport directory with a date and time stamp on it (up to the second).  For the moment, these buttons only work on Linux machines.

All channels were added to C0EDCU.ini, and should be being recorded for long term viewing.

Feel free to play around with it, break it, and let me know how it works (or doesn't).

  16859   Mon May 16 19:14:17 2022 AnchalUpdateBHDCamera set on AS path and BHDBS output path

[Anchal, Paco, Yuta]

  • We aligned AS path avoiding any clipping to the AP table where we setup a camera with a lens.
    • To do this we had to move AS6 in North direction for ~1cm.
    • The Injection table was imbalanced by this move to drop the IMC transmission to half.
    • We did not balance the table again, we steered the input mirror to reach to 1000 counts (out of 1200 nominal) and then used WFS loop to get to the last bit.
    • The input to the arm cavities did not change much, XARM was still flashing to 0.8 max height and YARM to 0.2. We recovered these easily using the cavity mirror pair.
  • We aligned the LO beam to be spatially matched on BHDBS with AS path.
    • The LO beam was steered to roughly overlap with the AS beam outputs on the BHDBS.
    • However, the LO beam size is very large and diverges after LO4.
    • According to 40m/15379, the 0.15m ROC of LO4 right after the beam waist is supposed to collimate the beam to a 522 um waist.
    • We confirmed that LO4 is marked as a 0.15m ROC mirror on its edge and the HR coating is facing the incident beam.
      • Conjecture (AG): The coating was applied to the flat side of the optic instead of the curved side.
      • This would explain why the beam is continuing to diverge after reflecting from LO4, and diverging fast.
    • We need to fix this issue before pumping down otherwise the mode matching would be too poor in BHDBS to have any meaningful results.
  • The output of BHDBS was steered out and a GigE camera is set up to see this path.
    • The camera is set to see the transmitted AS beam from BHD BS (and reflected LO beam).
    • But the camera is unable to see any LO beam due to large divergence.
    • The LO beam essentially disappears after ~30 cm from the BHDBS.

 

  813   Fri Aug 8 10:58:05 2008 josephbConfigurationCamerasCameras and gstreamer
In regards to camera failure:
1) I forgot to reconnect that particular camera to the network (my fault) so thats why it was failing.

2) Even with the correct camera connected, I've realized at full frame rate, op440m is going to get a few frames and then fail, as I don't think it has a fast enough ethernet card. It will work on Rosalba, and will also work ssh-ing from Rosalba because it is using a new ethernet card. It also works on my laptop, which is where I originally tested the command. One way to get around this is to increase the time between pictures, by changing -l 0 to -l 1 (or higher), where the number after the "ell" is the number of seconds to wait between frame captures.

3) What I should do is figure out the UDP transmission plugins for gstreamers and compress first (using the theoraenc since it gets compression ratios of better than 100:1) and transmit that over the network.

I have since reconnected the camera, so it should work on Rosalba and any sufficiently well connected computer. For other machines like linux2 or op440, try the following line:

Running the following command on Mafalda (via ssh -X mafalda) or Rosalba while in /cvs/cds/caltech/target/Prosilica/40mCode/SnapCode/

CamSnap -F 'Mono8' -c 44058 -E 10000 -X 0 -Y 0 -H 480 -W 752 -l 1 -m 100 | gst-launch-0.10 fdsrc fd=0 blocksize=360960 ! video/x-raw-gray, height=480, width=752, bpp=8,depth=8,framerate=1/1 ! ffmpegcolorspace ! ximagesink

This will be at a much slower frame rate (1 per second) but should work on any of the machines. (Tested on linux2).
  16288   Mon Aug 23 11:51:26 2021 KojiUpdateGeneralCampus Wide Power Glitch Reported: Monday, 8/23/21 at 9:30am

Campus Wide Power Glitch Reported: Monday, 8/23/21 at 9:30am (more like 9:34am according to nodus log)

nodus: rebooted. ELOG/apache/svn is running. (looks like Anchal worked on it)

chiara: survived the glitch thanks to UPS

fb1: not responding -> @1pm open to login / seemed rebooted only at 9:34am (network path recovered???)

megatron: not responding

optimus: no route to host

c1aux: ping ok, ssh not responding -> needed to use telnet (vme / vxworks)
c1auxex: ssh ok
c1auxey: ping ok, ssh not respoding -> needed to use telnet (vme / vxworks)
c1psl: ping NG, power cycled the switch on 1X2 -> ssh OK now
c1iscaux: ping NG -> rebooted the machine -> ssh recovered

c1iscaux2: does not exist any more
c1susaux: ping NG -> responds after 1X2 switch reboot

c1pem1: telnet ok (vme / vxworks)
c1iool0: does not exist any more

c1vac1: ethernet service restarted locally -> responding
ottavia: doesnot exist?
c1teststand: ping ok, ssh not respoding

3:20PM we started restarting the RTS

  16290   Mon Aug 23 19:00:05 2021 KojiUpdateGeneralCampus Wide Power Glitch Reported: Monday, 8/23/21 at 9:30am

Restarting the RTS was unsuccessful because of the timing discrepancy error between the RT machines and the FB. This time no matter how we try to set the time, the IOPs do not run with "DC status" green. (We kept having 0x4000)

We then decided to work on the recovery without the data recorded. After some burtrestores, the IMC was locked and the spot appeared on the AS port. However, IPC seemed down and no WFS could run.

  9412   Tue Nov 19 15:04:14 2013 JenneUpdateCDSCan talk to AUXEY again

The ETMY sliders on IFO_ALIGN were white again this morning, so I went down to the Yend and pushed the RESET button on auxey.  I then did a burt restore to 00:07am this morning for both auxey and auxex (since the stickers on the machines are still the old naming convention, I wonder if the autoburt is also backwards, so I did both).  Now the 'save' and 'restore' scripts for ETMY are working again.

Hopefully it's all better now, but I'll keep an eye on it.

  9375   Wed Nov 13 18:02:08 2013 JenneUpdateCDSCan't talk to AUXEY?

The restore scripts from the IFO config screen half-failed, with this error:

retrying (1/5)...
retrying (2/5)...
CA.Client.Exception...............................................
    Warning: "Virtual circuit disconnect"
    Context: "c1auxey.martian:5064"
    Source File: ../cac.cpp line 1214
    Current Time: Wed Nov 13 2013 17:24:00.389261330
..................................................................

Jamie, do you know what this might be?  When requested, ETMY was not misaligned or restored, but we got these errors.  So, somehow we're not talking properly to EY, but other things seem fine (the models are running okay, the suspension is damped, etc, etc.)

  9387   Thu Nov 14 22:23:22 2013 JenneUpdateCDSCan't talk to AUXEY?

Quote:

The restore scripts from the IFO config screen half-failed, with this error:

retrying (1/5)...
retrying (2/5)...
CA.Client.Exception...............................................
    Warning: "Virtual circuit disconnect"
    Context: "c1auxey.martian:5064"
    Source File: ../cac.cpp line 1214
    Current Time: Wed Nov 13 2013 17:24:00.389261330
..................................................................

Jamie, do you know what this might be?  When requested, ETMY was not misaligned or restored, but we got these errors.  So, somehow we're not talking properly to EY, but other things seem fine (the models are running okay, the suspension is damped, etc, etc.)

 This problem is now worse - the sliders on IFO_ALIGN for ETMY are white.  I can't telnet to the machine either, although auxex works okay.  Rather, it looks like maybe I'm getting to auxey, but then I'm immediately booted.  I can ping both c1auxex and c1auxey with no problem.
 

Heeeeelllp please.  Is this just a "shut off, then turn back on" problem?  I'm wary of hard rebooting things, with all the warnings and threats in the elog lately.  I've sent an email to Jamie to ping him.

There are some vague instructions in the wiki, but they begin at doing the burt restores, not actually restarting the computers: wiki  Back in July, elog 8858 was written, from which the wiki instructions seem to be based.  But in the elog it says "...went to the /cvs/cds/caltech/target/ area and started to (one by one) inspect all of the targets to see if they were alive.", but I don't know what "inspected" means in this case.  I probably should, since I've been here for something like a millennia, but I don't.


controls@rossa:~ 0$ telnet c1auxey
Trying 192.168.113.60...
Connected to c1auxey.martian.
Escape character is '^]'.
Connection closed by foreign host.
controls@rossa:~ 1$ telnet c1auxex
Trying 192.168.113.59...
Connected to c1auxex.martian.
Escape character is '^]'.

c1auxex >
telnet> ^]
?Invalid command
telnet> exit
?Invalid command
telnet> quit
Connection closed.
controls@rossa:~ 0$ telnet c1auxey
Trying 192.168.113.60...
Connected to c1auxey.martian.
Escape character is '^]'.
Connection closed by foreign host.
  9391   Fri Nov 15 10:19:26 2013 manasaUpdateCDSCan't talk to AUXEY?

Quote:

 

 This problem is now worse - the sliders on IFO_ALIGN for ETMY are white.  I can't telnet to the machine either, although auxex works okay.  Rather, it looks like maybe I'm getting to auxey, but then I'm immediately booted.  I can ping both c1auxex and c1auxey with no problem.
 

Heeeeelllp please.  Is this just a "shut off, then turn back on" problem?  I'm wary of hard rebooting things, with all the warnings and threats in the elog lately.  I've sent an email to Jamie to ping him.

There are some vague instructions in the wiki, but they begin at doing the burt restores, not actually restarting the computers: wiki  Back in July, elog 8858 was written, from which the wiki instructions seem to be based.  But in the elog it says "...went to the /cvs/cds/caltech/target/ area and started to (one by one) inspect all of the targets to see if they were alive.", but I don't know what "inspected" means in this case.  I probably should, since I've been here for something like a millennia, but I don't.

 

This is what was done (as I recollect) when we said "inspected":Tenet into the computer, ping them and look at the status. Since c1auxey is not responding, here is how c1auxex responds.

controls@rossa:/cvs/cds/caltech/target 0$ telnet c1auxex
Trying 192.168.113.59...
Connected to c1auxex.martian.
Escape character is '^]'.

c1auxex > h
  1  i
  2  -help
  3  --help
  4  h
  5  2
  6  h
  7  -help
  8  i
  9  h
value = 0 = 0x0
c1auxex > i

  NAME        ENTRY       TID    PRI   STATUS      PC       SP     ERRNO  DELAY
---------- ------------ -------- --- ---------- -------- -------- ------- -----
tExcTask   _excTask       fde244   0 PEND          87094   fde1ac   3006b     0
tLogTask   _logTask       fdb944   0 PEND          87094   fdb8a8       0     0
tShell     _shell         ddad00   1 READY         6d974   dda9c8  3d0001     0
tRlogind   _rlogind       fbc11c   2 PEND          2b604   fbbdf4       0     0
tTelnetd   _telnetd       fba278   2 PEND          2b604   fba1a8       0     0
tTelnetOutT_telnetOutTa   db7578   2 READY         2b604   db72e0       0     0
tTelnetInTa_telnetInTas   db6060   2 READY         2b5dc   db5d68       0     0
callback   _callbackTas   f7941c  40 PEND          2b604   f793d4       0     0
scanEvent  ee7ca8         ecacb4  41 PEND          2b604   ecac6c       0     0
tNetTask   _netTask       fd75b8  50 READY         6be6c   fd7550       0     0
scanPeriod ee78f8         ecd554  53 READY         6d192   ecd508       0     0
scanPeriod ee78f8         f23e48  54 DELAY         6d192   f23dfc       0     6
tFtpdTask  _ftpdTask      fb7848  55 PEND          2b604   fb778c       0     0
scanPeriod ee78f8         f266e8  55 READY         6d192   f2669c       0     0
scanPeriod ee78f8         f38678  56 READY         6d192   f3862c       0     0
callback   _callbackTas   f7bcbc  57 PEND          2b604   f7bc74       0     0
scanPeriod ee78f8         f906d8  57 DELAY         6d192   f9068c       0    59
scanPeriod ee78f8         f995ac  58 DELAY         6d192   f99560       0   238
scanPeriod ee78f8         f9c908  59 DELAY         6d192   f9c8bc       0   538
callback   _callbackTas   fa4c1c  65 PEND          2b604   fa4bd4       0     0
scanOnce   ee7764         f9f96c  65 PEND          2b604   f9f92c       0     0
epicsPrint f0501c         e88fa0  70 PEND          2b604   e88f64   c0002     0
ts_Casync  ee5bae         f76b7c  70 DELAY         6d192   f76880  3d0004   178
tPortmapd  _portmapd      fb8d60 100 PEND          2b604   fb8c2c      16     0
EgRam      ea00e4         fa14ac 100 PEND          2b604   fa1458       0     0
CA client  _camsgtask     d85878 180 PEND          2b604   d85774  3d0004     0
CA client  _camsgtask     df91e8 180 PEND          2b604   df90e4       0     0
CA client  _camsgtask     d98bf4 180 PEND          2b604   d98af0       0     0
CA client  _camsgtask     e03cd0 180 PEND          2b604   e03bcc       0     0
CA client  _camsgtask     ddf2b8 180 PEND          2b604   ddf1b4       0     0
CA client  _camsgtask     faaec8 180 PEND          2b604   faadc4       0     0
CA client  _camsgtask     d79f3c 180 PEND          2b604   d79e38       0     0
CA TCP     _req_server    f305dc 181 PEND          2b604   f30540       0     0
CA repeaterf109e2         f215a8 181 PEND          2b604   f21474       0     0
CA event   _event_task    d7fe58 181 PEND          2b604   d7fe10       0     0
CA event   _event_task    d6ce5c 181 PEND          2b604   d6ce14       0     0
CA event   _event_task    dab7e0 181 PEND          2b604   dab798       0     0
CA event   _event_task    d76efc 181 PEND          2b604   d76eb4       0     0
CA event   _event_task    d9bddc 181 PEND          2b604   d9bd94       0     0
CA event   _event_task    d9a864 181 PEND          2b604   d9a81c       0     0
CA event   _event_task    da8d8c 181 PEND          2b604   da8d44       0     0
CA UDP     _cast_server   f2f064 182 READY        efcabe   f2efe4       0     0
CA online  _rsrv_online   f2d84c 183 DELAY         6d192   f2d7bc       0   265
EV save_res_event_task    de88dc 189 PEND          2b604   de8894   3006b     0
save_restor_save_restor   df61cc 190 PEND          2b604   df5c44  3d0002     0
RD save_res_cac_recv_ta   fb47d8 191 READY         2b604   fb46a4  3d0004     0
logRestart f05d42         e861c0 200 PEND+T        2b604   e86174      33  1714
taskwd     ef4d46         e85030 200 DELAY         6d192   e84f7c       0   224
value = 0 = 0x0
c1auxex >
telnet> quit
Connection closed.
controls@rossa:/cvs/cds/caltech/target 0$

  9393   Fri Nov 15 10:49:55 2013 jamieUpdateCDSCan't talk to AUXEY?

Please just try rebooting the vxworks machine.  I think there is a key on the card or create that will reset the device.  These machines are "embeded" so they're designed to be hard reset, so don't worry, just restart the damn thing and see if that fixes the problem.

  9394   Fri Nov 15 12:00:28 2013 KojiUpdateCDSCan't talk to AUXEY?

Quote:

Please just try rebooting the vxworks machine.  I think there is a key on the card or create that will reset the device.  These machines are "embeded" so they're designed to be hard reset, so don't worry, just restart the damn thing and see if that fixes the problem.

 Don't forget to run burtrestore for the target.

  9395   Fri Nov 15 12:38:50 2013 JenneUpdateCDSCan't talk to AUXEY?

Quote:

Please just try rebooting the vxworks machine.  I think there is a key on the card or create that will reset the device.  These machines are "embeded" so they're designed to be hard reset, so don't worry, just restart the damn thing and see if that fixes the problem.

 This is what I remember doing all the time when Rob was around, but with all the new computers, I forgot whether or not this was allowed for the slow computers.

Anyhow, I went down there and keyed the crate, but auxey isn't coming back.  I'll give it a few more minutes and check again, but then I might go and power cycle it again.  If that doesn't work, we may have a much bigger problem.

  9402   Mon Nov 18 21:20:54 2013 JenneUpdateCDSCan't talk to AUXEY?

Quote:

The restore scripts from the IFO config screen half-failed, with this error:

retrying (1/5)...
retrying (2/5)...
CA.Client.Exception...............................................
    Warning: "Virtual circuit disconnect"
    Context: "c1auxey.martian:5064"
    Source File: ../cac.cpp line 1214
    Current Time: Wed Nov 13 2013 17:24:00.389261330
..................................................................

Jamie, do you know what this might be?  When requested, ETMY was not misaligned or restored, but we got these errors.  So, somehow we're not talking properly to EY, but other things seem fine (the models are running okay, the suspension is damped, etc, etc.)

 The auxey machine is back, in that I can interact with the IFO_ALIGN sliders, and they actually make the optic move, but I still can't read and write to and from the EPICs channels:

controls@rossa:/opt/rtcds/caltech/c1/medm/MISC/ifoalign/burt 0$ cdsutils read C1:SUS-ETMY_PIT_COMM
CA.Client.Exception...............................................
    Warning: "Virtual circuit disconnect"
    Context: "c1auxey.martian:5064"
    Source File: ../cac.cpp line 1214
    Current Time: Mon Nov 18 2013 21:13:52.044973819
..................................................................
Could not connect to channel (timeout=2s): C1:SUS-ETMY_PIT_COMM
controls@rossa:/opt/rtcds/caltech/c1/medm/MISC/ifoalign/burt 1$ cdsutils read C1:SUS-ETMY_YAW_COMM
CA.Client.Exception...............................................
    Warning: "Virtual circuit disconnect"
    Context: "c1auxey.martian:5064"
    Source File: ../cac.cpp line 1214
    Current Time: Mon Nov 18 2013 21:14:07.040168660
..................................................................
Could not connect to channel (timeout=2s): C1:SUS-ETMY_YAW_COMM
controls@rossa:/opt/rtcds/caltech/c1/medm/MISC/ifoalign/burt 1$

This is also causing trouble for the BURT save and BURT restore scripts, that are called from the IFO_ALIGN screen.  If I look at the log that is written from an attempted 'save' of the slider values, I see:

**** READ BURT LOGFILE

--- Start processing files
file >/opt/rtcds/caltech/c1/medm/MISC/ifoalign/burt/ETMY.req<
preprocessing ... done
pv >C1:SUS-ETMY_PIT_COMM< nreq=-1
pv >C1:SUS-ETMY_YAW_COMM< nreq=-1
--- End processing files

--- Start searches
C1:SUS-ETMY_PIT_COMM ... ca_search_and_connect() ... OK
C1:SUS-ETMY_YAW_COMM ... ca_search_and_connect() ... OK
--- End searches
Waiting for 2 outstanding search(es) ...
Waiting for 2 outstanding search(es) ...
did not find 2

--- Start reads
C1:SUS-ETMY_PIT_COMM ... not connected so no ca_array_get_callback()
C1:SUS-ETMY_YAW_COMM ... not connected so no ca_array_get_callback()
--- End reads

--- Start wait for pending reads

-- End wait for pending reads 0 outstanding read(s)

**** END BURT LOGFILE

The burt save file has no values in it.  Even if I copy over the ETMX save file and put in the correct channel names and values, a burt restore is unsuccessful. 

So, I can do locking tonight by restoring and misaligning by hand, but this sucks, and needs to be fixed. Other optics (at least PRM, SRM, ETMX) seem to be working just fine.  It's just ETMY that has a problem.

 

  2516   Fri Jan 15 12:04:26 2010 Sanjit, mevansUpdateAdaptive FilteringCanceling noise again!

 

OAF is successfully canceling noise again, thanks to Matt!

Here is a plot showing more than a factor of 10 noise reduction around 3Hz (similar to what we saw in the simulations)

The changes that has made it work are:

  • use of RANGER channel (with ACC_MC1_X and/or ACC_MC2_X)
  • mu = 0.01, tau = 1.0e-6, ntaps = 2000, nDown = 16
  • nDelay = 5 and nDelay = 7 both work (may not be so sensitive on delay at low frequencies)
  • Main changes: filter bank on the PEM channels (ASS_TOP_PEM_## filters: 0.1:0, 1:, Notch24, AA32)
  • Added the AI800 filter for upsampling in MC1 (should not matter)

 Matt suggested playing with the emphasis (EMPH) filters to cancel noise in different frequency bands.

 

Attachment 1: OAF_15JAN2010.png
OAF_15JAN2010.png
  7687   Thu Nov 8 09:04:45 2012 SteveUpdateCamerasCanon T3i purchased

Canon EOS Rebel T3i has been purchased. See rating

Attachment 1: BH_409130400.pdf
BH_409130400.pdf
  16250   Sat Jul 17 00:52:33 2021 KojiUpdateGeneralCanon camera / small silver tripod / macro zoom lens / LED ring light borrowed -> QIL

Canon camera / small silver tripod / macro zoom lens / LED ring light borrowed -> QIL

Attachment 1: P_20210716_213850.jpg
P_20210716_213850.jpg
  16255   Sun Jul 25 18:21:10 2021 KojiUpdateGeneralCanon camera / small silver tripod / macro zoom lens / LED ring light returned / Electronics borrowed

Camera and accesories returned

One HAM-A coildriver and one sat amp borrowed -> QIL

https://nodus.ligo.caltech.edu:8081/QIL/2616

 

  3052   Sun Jun 6 08:08:05 2010 rana, sanjitSummaryElectronicsCapacitor Bridge Test

To get a feel for the Capacitive Bridge problems, we setup a simple bridge using fixed (1 nF) caps on a breadboard. We used an SR830 Lock-In amplifier to drive it and readout the noise.

CapacitanceBridge.png

We measured the cap values with an LCR meter. They were all within a few % of 0.99 nF.

With a 0.5 V drive to the top of the bridge, the A-B voltage was ~2 mV as expected from the matching of the capacitors.

(** Note about the gain in the SR830: In order to find the magnitude of the input referred signal, one has to divide by G. G = (10 V)/ Sensitivity. 'Sensitivity' is the setting on the front panel.)

  1. Directly measuring from Vs to ground gives 0.5 V, as expected. This is done to verify the calibration later on.
  2. Shorting the A and B wires to ground gives ~0 V and lets us measure the noise. On the spectrum analyzer it was ~400 nV/rHz at 100 Hz and rising slowly to 4 uV/rHz at 100 mHz. In this state, the sensitivity was 10 mV, so the overall gain was 1000. That gives an input referred level of ~0.4 nV/rHz at the input.
  3. Hooking up now to A-B: the signal is ~10x larger than the 'dark' noise everywhere. 2 uV/rHz @ 100 Hz, 10 uV/rHz @ 10 Hz, 50 uV/rHz @ 1 Hz. The spectrum is very non-stationary; changing by factors of several up and down between averages. Probably a problem with the cheapo contacts in the breadboard + wind. The gain in this state was still 1000. So at 1 Hz, its 50 nV/rHz referred to the input.

To convert into units of capacitance fluctuation, we multiply by the capacitance of the capacitors (1 nF) and divide out by the peak-peak voltage (1 V). So the bridge sensitivity is 50e-9 * 1e-9 = 5 x 10^-17 F/rHz.

If we assume that we will have a capacitive displacement transducer giving 1 nF capacitance change for a 0.1 mm displacement, this bridge would have a sensitivity of 5 x 10^-12 m/rHz @ 1 Hz. We would like to do ~50-100x better than this. The next steps should be:

  1. Solder it all together on a PCB to have less air current sensitivity and decent contacts.
  2. Use a low-noise FET input. Since the impedance of the bridge is ~5 kOhms at this frequency, we are probably current noise limited.
  3. Estimate the oscillator amplitude noise sensitivity.
  3053   Mon Jun 7 07:39:38 2010 AlbertoOmnistructureElectronicsCapacitor Bridge Test

Quote:

To get a feel for the Capacitive Bridge problems, we setup a simple bridge using fixed (1 nF) caps on a breadboard. We used an SR830 Lock-In amplifier to drive it and readout the noise.

The measurement setup for the Capacitor Bridge Test is still sitting on one of the work benches.

Unless the experiment is supposed to continue today, the equipment shouldn't have been left on the bench. It should have been  taken back to the lab.

Also the cart with HP network analyzer used for the test was left in the desk area. That shouldn't have left floating around in the desk area anyway.

The people responsible for that, are kindly invited to clean up after themselves.

  8736   Fri Jun 21 16:30:04 2013 SteveUpdateGeneralCapacitor Inventory

The 3 Panasonic Ceramic Kits Books, 1206 NPO, SMT are well stocked. The 4 th one needs to be refilled at some values.

I labeled them on the cover for fast access. See Atm1

 

The Metalized Polyester Film Book with through holes mount are in good shape also. Atm2

 

The AVX Ceramic 1206,  Garrett cab, range: 1pF - 22 microF 50V...... 67 values

Note here: that the value of dielectric, capacitance / voltage will vary

NPO: 1 pF - 1 nF /  50V .......37 values

X7R : 1 nF -  0.082 microF /  50V,  0.1 microF /  100V.......27 values

Y5V:  4.7 microF / 6.3 V,  10 microF / 10V,  22 microF / 6.3V.........3 values 

 

Attachment 1: CeramicCaps1206NPOsmt.jpg
CeramicCaps1206NPOsmt.jpg
Attachment 2: PolyesterFilmCapThroughHole250VDC.jpg
PolyesterFilmCapThroughHole250VDC.jpg
  13105   Mon Jul 10 17:13:21 2017 jigyasaUpdateComputer Scripts / ProgramsCapture image without pylon GUI

Over the day, I have been working on a C++ program to interface with Pylon to capture images and reduce dependence on the Pylon GUI. The program uses the Pylon header files along with opencv headers. While ultimately a wrapper in python may be developed for the program, the current C++ program at, 

/users/jigyasa/GigEcode/Grab/Grab.cpp when compiled as

g++ -Wl,--enable-new-dtags -Wl,-rpath,/opt/pylon5/lib64 -o Grab Grab.o -L/opt/pylon5/lib64 -Wl,-E -lpylonbase -lpylonutility -lGenApi_gcc_v3_0_Basler_pylon_v5_0 -lGCBase_gcc_v3_0_Basler_pylon_v5_0 `pkg-config opencv --cflags --libs`

returns an executable file named Grab which can be executed as ./Grab

This captures one image from the camera and displays it, additionally it also displays the gray value of the first pixel.

I am working on adding more utility to the program such as manually adjusting exposure, gain and also on the python wrapper (Cython has been installed locally on Ottavia for the purpose)!

  1068   Wed Oct 22 16:22:53 2008 steveBureaucracySAFETYCaryn received safety training
Caryn Polatchi has received 40m safety training on Monday, Oct 20
  3356   Wed Aug 4 03:01:56 2010 JenneUpdatePEMCatastrophic Cable Failures

Quote:

After some cable swapping this morning, I have determined which cable is bad.  It's the Gur1 cable between the seismometer and the breakout box.  This is a milspec -> 37pin d-sub cable.  I'll pull out the cable and have a look at it after lunch.

 So, I was wrong about which cable it was, probably in my rush to get some lunch.  The actual culprit was the octopus cable that Bob made waaay back in the day (~2 years ago) to go from the "ADC out" of the breakout box (37pin Male Dsub) to 9 BNCs.  As it turns out, the Gur1Z channel of that cable was broken on both ends!!! 

On one end, we have the 37 pin Dsub.  The cable used was so thick (way too thick for this application) that it made a super rigid connection between the wires and the connector, and any bending of the cable stressed this connection, despite the strain-relief of the backshell.  The Gur1Z connection snapped off when I was gently wiggling the connections to check them out.  Also, since the wires were all so thick, they didn't really fit into the hole in the backshell, so 2 or 3 of them were squished.....straight through the insulation so that several channels were shorted together / potentially shorted to ground.  This may explain some of the nasty behavior that Rana and I had seen (although I might have forgotten to elog? My bad.) that even with the inputs of the breakout box all terminated, there was high coherence between the channels.  Terminated inputs should give random noise, so this was fishy. 

On the other end of the cable we have the 9 BNCs.  I had finished redoing the 37pin end of the cable, and was 'beeping' it to check it out, when to my dismay I found that the Gur1Z channels (the inside and the outer shield of the BNC connector) were shorted together.  I removed these 2 wires from the Dsub connector to confirm that the BNC was at fault.  Koji looked at the BNC with me after I chopped it off of the cable.  Bad news strikes again.  To get the wires to fit in the inner pin of the BNC connector, the cable-maker had cut off several strands of the wire to make it skinnier.  It appears that over the years these cut-off strands wiggled their way to touching the outer shield.  This appears to be a danger for all of the BNCs on this cable: a little bit of torque (which one might expect during plugging and unplugging a BNC) and the 2 sides of the differential measurement will be shorted together.

I then decided to start afresh and make my own cable.  I found some AWG26 8-twisted-pair cable laying around underneath the Yarm (since this was all I could find, I was just going to do the Gur1 and Gur2 channels, and leave out the Gur3's).  The 37 Dsub side was easy, but I seem not able to connect such skinny wire to the BNC connectors in a robust way.  Since this bad cable has so far cost me ~2.5 16-hour days of grief, I don't want my new version of it to also be bad.  At this point, I await the advice of one wiser than I. I think BNC connectors are designed for something a little closer to ~20AWG, but I could be wrong.  Also, they are obviously optimized for coax cable. So what I have now is never going to be great.  Maybe tomorrow I can go to the Electronics Shop / Store and buy BNC connectors that are meant to be soldered-to.  That would be awesome.

Since I currently have no functional cable to go from Breakout box to ADC, the Guralps are unplugged for tonight.

Conclusions for the day / evening:  Frank, Alastair and Jenna are mostly absolved of blame, although the traveling to Bridge and opening and closing the box (which usually involves more plugging and unplugging of cables) probably didn't help this cable out too much.  Also, Bob definitely owes me a Sugar Napoleon or something.

 In other news, since the Gur2Z ADC channel is totally wacked, I have taken over (but not renamed) the Ranger channel for Gur2Z for now.  Jan still has the Ranger hostage over in Bridge, so this is okay for now.

  13116   Thu Jul 13 16:10:34 2017 KaustubhSummaryComputer Scripts / ProgramsCavity Scan Simulation Code

The code to produce a cavity scan simulation and then fitting the data and re-evaluating the initiallt set parameters can be found in this git repo.


The 'CavitScanSimulation' python script now produces a cavity scan with custom parameters which can be easily modified. It also introduces the first TEMs(n+m=0,1,2,3,4) to the laser with power going as (1/(2(n+m)+1))^2 {Selected carefully}. The only care that needs to be taken is that the frequency span should be somewhere near an integral multiple of the FSR so that there are equal number of resonances for all modes and sidebands. This code, as of now also calls the 'FitCavityScan' script which performs the fitting procedure on the data generated above{This data is actually written in a '.mat' file} and generates the Fit parameter data files. The Simulation code then calls the 'CalculatingPhysicalParameters' script which evaluates the data based on the Fit parameters and outputs some physically relevant results like the FSR, Finesse, Modulation Depths, TMS{Current Output is the Estimated RoCs of the two mirrors which isn't something we want directly, so it can be modified a bit to output TMS based on the HOMs}. The scripts do some 'Linearity' checks which might not really be of much significance but can be seen as a reference. Also, the ipython notebook will show all intermediate plots for the actual data and data with custom noise, fit data, FSR fitting, linearity checks, Bessel Ratio plot with mod_depths.

 

Note: The scripts should be run using either an IDE like 'spyder'{for .py files}{Comes with Anaconda} or using an ipython notebook{for .ipynb files}.
  13155   Mon Jul 31 23:39:02 2017 ranaUpdateCOCCavity Scan Simulation Code

Hiro Yamamoto has updated SIS (Static Interferometer Simulation) to allow us to do the MCMC based inference of the 40m arm cavity mirror maps. 

The latest version is in git.ligo.org: IFOsim/SIS/

In the examples directory I have put 3 files:

  1. mcmcCavityScans.m - runs many cavity scans using parfor and saves the data
  2. plotCavityScans.m - loads the .mat file with the data and plots it
  3. plotCavityScans.py - python file which also loads & plots, but nicer since python has a transparency option for the traces.

Attached is the plots and the data. The first attached plot is a low resolution one: 200 scans of 100 frequency points each. Second plot is 200 scans of 300 points each.

The run was done assuming perfect LIGO arm params with a random set of Zernike perturbations for each run. The amplitude of each Zernike was chosen from a Normal distribution with a standard deviation of 10 nm.

We need to come up with a better guess for the initial distribution from which to sample, and also to use the more smart sampling that one does using the MCMC Hammer.

Attachment 1: manyCavityScans-SIS.pdf
manyCavityScans-SIS.pdf
Attachment 2: manyCavityScans-SIS.pdf
manyCavityScans-SIS.pdf
Attachment 3: MonteCarlo_CavityScans.mat
  4585   Fri Apr 29 03:39:49 2011 KojiSummaryLSCCavity lengths

I tried the idea that the PRC can resonate f1 and f2 at the same time if the arm gives the reflection phase to f1 and f2 with the ratio of 1 vs 5.

The details are described on wiki. The point is this removes all of the PRC/SRC/asymmetry mumbo jumbo.

The calculated cavity lengths for f_mod of 11.065399MHz are:

  • Arm Length: 37.7974 [m]

  • PRC Length: 6.7538 [m]

  • SRC Length: 5.39915 [m]

  • Asymmetry (lx-ly): 0.0342 [m]


Here is the actual values derived from the photos.

  • Arm Length: 37.54 [m] (0.26m too short)

  • PRC Length: 6.760 [m] (6mm too long)

  • SRC Length: 5.415 [m] (16mm too long)

  • Asymmetry (lx-ly): 0.0266 [m] (8mm too long)

  7351   Thu Sep 6 17:06:25 2012 Rijuparna ChakrabortyConfigurationelogCavitymode scan

 Aim: to scan the cavitymodes of IMC

The circuit used: 

 Attachment4

Results obtained:

Attachment 1,2,3

 

Attachment 1: 3.pdf
3.pdf
Attachment 2: 2.pdf
2.pdf
Attachment 3: 1.pdf
1.pdf
Attachment 4: cavityscanconnections.pdf
cavityscanconnections.pdf
ELOG V3.1.3-