40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 275 of 344  Not logged in ELOG logo
ID Date Author Typeup Category Subject
  12900   Wed Mar 22 16:58:25 2017 gautamUpdateIMCWFS sensing matrix measurements

I've taken a bunch of transfer function measurements from the MC ASC PIT and YAW channels to the WFS error signals using the same set of DTT templates Koji used while characterizing the WFS loops a couple of months ago, before the IMC RF changes. Analysis is underway and I will post the results here shortly...

As an aside, Rana had added 10dB and 20dB gains to all of the WFS filter banks yesterday. I tried engaging the 10dB gains on the two MC2_TRANS PD loops, and this did not seem to induce any instability. I stepped both loops and saw that as expected, the 1/e times for both of these loops is about 45 seconds now (compared to ~150 seconds at the nominal gain). These have been running all day today, and the IMC seems well behaved, so I am going to leave these on for now... Jacking up the gain on the MC2_TRANS_QPD loops by 20dB induced instability - same story for the 4 WFS loops with 10dB additional gain...

  12901   Thu Mar 23 01:44:53 2017 gautamUpdateIMCWFS sensing matrix measurements

Thanks to Koji's nice MATLAB script using DttData functions, I was able to quickly analyze the TF data. Essentially, this measurement was a repetition of what was done here. The difference is that the modulation depth has been increased by ~25x compared to that measurement from December 2016. Here are the measured TFs (before accounting for the 1/f^2 normalization) for the various quadrants and the PIT/YAW channels:

  

The plots above are just to illustrate that the measurement was clean between the band over which the averaging will be done to compute the TF amplitude - i.e. 7-15Hz. The full summary of TF amplitudes, standard deviations, and the sensing matrix in the style of the referenced elog (the actual excel spreadsheet is Attachment #4, minus some of the graphics Koji had on his excel sheet):

Inverting those matrices, we get the matrices that diagonalize the sensor-actuator chain:

PITCH:

\begin{pmatrix} -0.00518 & -0.00305 & -639.6\\ 0.00354 & -0.00281 & 198.8\\ 0.00102 & 0.00672 & -756.6 \end{pmatrix}

YAW:

\begin{pmatrix} 0.00523 & -0.00276 & -856.7\\ 0.000318 & 0.00010 & -366.4\\ 0.00039 & -0.00548 & -851.9 \end{pmatrix}

I will try implementing these matrices tomorrow and take a look at the step responses of the loops - the idea is that perhaps the system wasn't optimally diagonalized before and perhaps we can now improve the bandwidths of all the loops.

 

  12902   Thu Mar 23 08:43:11 2017 ranaUpdateIMCWFS sensing matrix measurements

For sensing matrix, better to use single frequency sine response. We don't want to measure around the bounce or above the 28 Hz cutoff filters in the MC SUS.

  12903   Thu Mar 23 23:38:58 2017 gautamUpdateIMCMC SUS damping gains stepped down

I've reduced the gains of the damping on all 3 MC SUS by a factor of 3 for overnight observation as part of the ongoing feedforward noise cancellation investigations. I will return them to the nominal values tomorrow morning.

  12904   Fri Mar 24 11:26:57 2017 gautamUpdateIMCMC SUS damping gains restored

I've restored the damping loop gains to their nominal values. Analysis of the coherence between MCL and seismometer channels under this reduced gain setting is underway, results to follow.

  12906   Fri Mar 24 19:04:18 2017 gautamUpdateIMCSeismic feedforward and WFS

[valera, gautam]

On Wednesday at the meeting, we were discussing why we aren't able to achieve more seismic feedforward subtraction in MCL. We spent some time thinking about this yesterday, and this elog is meant to be a summary of the stuff we tried. 

  1. We let the WFS loops run for a while and settle, and then turned the input gain down to zero so that the integrators held the outputs to the suspension at a "good" alignment. If the WFS loop bandwidth is ~0.1 Hz, then they aren't helping us at 1Hz anyways. We then looked at coherence between the seismometer signals in this state compared to when the WFS loops were running, and noticed negligible difference. It doesn't seem like the WFS loops are injecting noise into MCL at ~1Hz.
  2. We decided agains implementing the WFS sensing matrix I measured on Wednesday evening, as we found that the relative magnitudes of the matrix elements are virtually the same as in Koji's measurement back in December 2016. But looking at matrix elements like MC1P->WFS1P compared to MC3P->WFS1P - there is a difference of a factor of ~3. Why should there be? The response should be completely symmetric to MC1 and MC3?
  3. While looking at the OSEM channels (i.e. SUSPIT_IN1_DQ, SUSYAW_IN1_DQ etc) for each of the MC optics, we noticed a dramatic difference between MC1 (factor of ~10 higher) and the other two MC optics.
  4. Looking at coherence between MCL and the seismometer channels, we felt that there is less coherence at low frequencies (1Hz and lower) now than there was back in January when I took a measurement. However, there was coherence between the OSEM signals and the seismometers - so it doesn't look like the seismometer is to blame. To make an apples-to-apples comparison, I compared the MCL and Seismometer channel spectra from January to now (for the latter, at two different settings of the damping loop gains on the MC suspensions), and also the maximum predicted achievable subtraction (using EricQs frequency domain multicoherence tool). The two changes I can think of since January are that the MC1 satellite box has been interchanged with the SRM satellite box, and the IMC servo gains have been reallocated since the RF upgrade. My findings are summarized in attachments #1 and #2.

The seismometer spectra look similar enough to be explained by time of day variations, so perhaps the culprit is MC1. The ambient MCL spectrum is almost an order of magnitude higher above 4Hz now, with the nominal damping loop gains, as compared to back in January. I think the damping loops on MC1 need to be tweaked.

 

  12908   Mon Mar 27 15:36:27 2017 SteveUpdatePEMparticle counter inside of PSL enclousure

 

Quote:

The logging script is multiplying by 100 instead of 10 !

Quote:

The MET#1 particle counter was moved from CES wall at ITMX to PSL enclousure south west corner at 11am.

The HEPA filter speed at the Variac was turned down to 20V from 40

This counter pumps air for 1 minute in every 20 minutes. Soft foam in bags used to minimize this shaking as it is clamped.

 

 

Some one turned up the PSL HEPA rotation voltage from 20 V to 33 ( 120V Variac ) and  X-arm AC set temp lowered to 68F

Effects at 12" height from optical table :

                                                            1.0, 0.5 & 0.3 micron particle count  goes to zero and temperature fluctuaion increased

Rotation speed voltage was set to 30V

                                                            

  12909   Mon Mar 27 16:01:55 2017 SteveUpdatePEMX arm AC set to 68F

 

The X arm air conditioner was not regulating properly. The arm temp was warmer than usual. I requested thermistor calibration.

The mechanic reset the thermostate to 68F last week.  It was 70-71F before.

 

The ETMX oplev laser now running 4 C lower at 30 C inside the enclousure.

The ETMX optical table top is 5 C cooler  at 21 C

The ETMX concrete wall temp 20 C at 9am with flow bench on.

ETMY conrete wall  temp 23 C at 9am

  12911   Mon Mar 27 20:41:21 2017 rana, gautamUpdatePSLPMC DAQ assay for feed-forward integration

We are thinking to use the PMC signals to help us in figuring out the feedback / feedforward stuff and making it better.

Today we scoped out the PMC DAQ channels (which were never re-hooked up after the Joe/Jamie CDS upgrade 6 years ago).

There is a 4-pin LEMO connector on the front panel which gives

  1. the error signal (after the 4th order, post-mixer lowpass and a OP27 buffer with a 17 kHz low pass)
  2. the feedback voltage to the PZT, after a resistive divide by 50

Both of these signals are buffered by the AD620 inst amp configured with a gain of 1. In the green scope trace, you can see that there's a ~110 MHz signal strongly evident there. In the spectrum analyzer screen shot there is a instrument noise trace and then a PMC error point trace. You can see that all the peaks are ony there when I connect to the servo board instead of a Terminator. This RF noise is mainly the higher harmonics of the 35.5 MHz modulation getting there. It seems to be in both the error and control DAQ outputs, and a question is whether or not it is also in the servo electronics.

I also attach a close up of the servo board in the region of the post-mixer LC low pass filtering. I think its supposed to be 4th order cutoff at 1 MHz, but maybe the caps are busted or there's a way for the RF from the mixer to bypass the filters and get into the main servo path?

In the medium term, we probably want to use the new PDH servo that Rich is making. Need to buy/make a HV driver to use, but that should be easy.

  12913   Tue Mar 28 16:47:40 2017 SteveUpdatesafetyProjector bulb is out again

Three replacement bulbs ordered

Rana can discribe how it happened.

IF A LAMP EXPLODES

If a lamp explodes, the gas and broken shards may scatter inside the projector and they may comeout of the exhaust vent.
The gas contains toxic mercury.
Open windows and doors for ventilation.
If you inhale the gas or the shardsof the broken lamp enter your eyes or mouth, consult the doctorimmediately.
Quote:

This bulb was blown out on Feb 4, 2017 after 2 months of operation.

 

 

  12915   Wed Mar 29 09:24:28 2017 SteveUpdateloresummery pages

The summery pages are working at a slow motion speed. It's response time 12 minutes.

  12916   Wed Mar 29 11:41:19 2017 gautamUpdatePSLPMC DAQ assay for feed-forward integration

The C1IOO frontend machine that resides in 1X1/1X2 has 2 ADCs, ADC0 and ADC1. The latter has 28 out of 32 channels unused at the moment, so I decided to use this for setting up fast channels for the PMC DAQ. On the RTCDS side of things, the PSL namespace block lives in the C1ALS model. I made the following modifications to it:

  1. Added channels for the PMC DAQ
  2. Added CDS filters for both the newly added PMC DAQ channels and the existing FSS DAQ channels, so that we can calibrate these into physical units
  3. Changed the names of the existing FSS channels from FSS_MIXER and FSS_NPRO to FSS_ERR and FSS_CTRL. The latter is still a bit ambiguous, but I felt that FSS_CM_BOARD_CTRL was too long. 
  4. Added DQ channels for the new PMC channels. These are recording at 16K at the moment, but since we have the fast testpoints courtesy of the CDS filter modules for diagnostics, perhaps the DQ channels need only be recorded at 2K?

The PSL namespace block in C1ALS looks like this now:

I then tried hooking up the DAQ signals from the PMC servo board to the ADC via the 1U generic ADC interface chassis in 1X2 - this has 4pin LEMO inputs corresponding to 2 differential input channels. I used J6 (corresponding to ADC channels 10 and 11) for the PMC_ERR and PMC_CTRL respectively. I was a little confused about the status of the 4 pin LEMO output on the front panel of the PMC servo board. According to the DCC page for the modified 40m servo board, the DAQ outputs are wired to the backplane connector instead of the 4 pin LEMO. But looking at photographs on the same DCC page, there are wires soldered on the rear-side of the PCB from the 4-pin LEMO to the backplane connector. Also, I believe the measurements made by Rana in the preceeding elog were made via the front panel LEMO. In any case, I decided to use the single pin LEMO monitor points on the front panel as a preliminary test. The uncalibrated spectra with ADC terminated, IMC unlocked and IMC locked look like:

So it looks like at the very least, we want to add some gain to the AD620 instrumentation amplifiers to better match the input range of the ADC. We also want to make the PZT voltage monitor path AC coupled. My plan then is the following:

  1. Figure out what is going on with the 4-pin LEMO connector on the front panel - is it connected to the DAQ monitor points or not?
  2. Ground pin 5 of U15 (this has already been done by Koji for U14 according to the DCC page)
  3. Add a resistor between pins 1 and 8 of U14 and U15 to get some gain. According to the datasheet, a 1k resistor will give a gain of 50, which for U15 will mean that we undo the existing 1/50 attenuation. Of course we need to AC couple this path first by adding a capacitor in series with R14. 
  4. Figure out where the RF harmonics are coming from and what is the best way to attenuate them.

I will update with a circuit diagram with proposed changes shortly.

Proposed changes:

  1. Cut PCB trace between R14 and R13, install capacitor - what is is correct type of capacitor to use here? I figured installing a series capacitor after the resistive divider, to the input of the instrumentation amplifier avoids the need for a HV capacitor, so we can use a 1uF WIMA capacitor.
  2. Add gains to U14 and U15 (error and control signal monitors respectively). Based on the uncalibrated spectra attached, I think we should go for a gain of ~50 for U15 (1kohm between pins 1 and 8), and a gain of ~200 for U14 (250ohms between pins 1 and 8).

The PCB layout is such that I think using components with leads is easier rather than SMD components.

If this sounds like a reasonable plan, I will pull out the servo card from the eurocrate and implement these changes today evening...

  12918   Thu Mar 30 00:16:09 2017 gautamUpdatePSLPSL NPRO PZT calibration

As part of the ongoing effort to try and calibrate the PMC DAQ channels into physical units, I tried to get a calibration for the PSL NPRO PZT actuator gain. In order to do this, I selected "Blank" on the PMC servo MEDM screen such that there was no feedback signal to the PMC PZT for length control. Then I used the summing box right before the  PSL PZT to inject a ~1Hz triangular wave, 4Vpp. This was sufficient to sweep the NPRO frequency over 70MHz such that both sidebands and the carrier go through resonances in the PMC cavity. I then simultaneously monitored the applied triangular wave voltage and the PMC error signal (using the single pin LEMO connector on the front panel) on an oscilloscope. Analysis is underway, but a quick look at one measurement suggests a PZT actuator gain of ~1.44MHz/V, which is close to what we expect for the Innolight NPROs. The idea is to use this calibration to convert the DQ channels into physical units. 

Details + plots + error analysis to follow...

  12920   Thu Mar 30 18:11:01 2017 ranaUpdatePSLPMC DAQ assay for feed-forward integration

What you have drawn looks good to me: the cut should be between TP3 and pin3 of the AD620. This should maintain the DC coupled respons for the single-pin LEMO and backplane EPICS monitors.

We want to use the PMC signal down to low frequencies, so the filter on the input of the AD620 should have a low frequency cutoff, but we should take care not to spoil the noise of the AD620 with a high impedance resistor.

It has a noise of 100 nV/rHz and 1 pA/rHz at 1 Hz. If you use 47 uF and 10 kOhm, you'll get fc = 1/2/pi/R/C ~ 0.3 Hz so that would be OK. 

  12921   Fri Mar 31 10:16:07 2017 SteveUpdatesafetylaser safety glasses annual inspection

Laser safety glasses cleaned in " Dawn Ultra " mild soap - water solution and measured for 1064 nm transmission at 150 mW
 

  12922   Fri Mar 31 16:10:33 2017 SteveUpdateTreasureLes Guthman

Les Guthman interviews  gradstudent Graig.

Main laser emergency shut off was acuated by accident during this fiming. The laser is turned on.

  12923   Sun Apr 2 23:14:30 2017 ranaUpdateComputer Scripts / Programsnodus update/upgrade/reboot

I just did remote apt-get update, apt-get upgrade, and then reboot on nodus. ELOG started up by itself.

  12924   Mon Apr 3 17:09:47 2017 gautamUpdateCDSC1PSL burt-restored

When I came in this morning, Steve had re-locked the PMC and IMC - but I could see a ~1Hz intensity fluctuation on the PMC REFL video monitor. I unlocked the PMC and tried to re-lock it, but couldn't using the usual prescription of turning the servo gain down and moving the DC bias slider around. I checked the status of the slow machines - all were responding to pings and could be telnet'ed into, so that didn't seem to be the problem. In the past, this sort of behaviour was characteristic of the infamous "sticky slider" problem - so I simply burt-restored c1psl using a snapshot from 29 March, after which I could easily re-lock the PMC. The transmitted light level looked normal on the scope on the PSL table, and the PMC REFL video monitor also look normal now.

  12925   Mon Apr 3 17:25:13 2017 gautamUpdatePSLPSL NPRO PZT calibration

Summary:

By sweeping the laser frequency and looking at the PMC PDH error signal, I have determined the 2W Mephisto Innolight PZT actuator gain to be 1.47 +/- 0.04 MHz/V

Method:

  1. Re-aligned the input beam into the PMC to maximize transmission level on the oscilloscope on the PSL table to 0.73V.
  2. Disabled control signal from IMC servo to PSL. 
  3. Unlocked the PMC and disabled the loop by selecting "BLANK" on the PMC MEDM screen.
  4. Connected a 0.381 Hz 5Vpp triangular wave with SR function generator to the "SUM" input of the Fast I/F box just before the PSL PZT input. These params were chosen considering the Pomona box just before the NPRO has a corner at 2.9Hz, and also to sweep the voltage to the NPRO PZT over the full 150V permitted by the Thorlabs HV amplifier unit. Monitored the voltage to the Thorlabs HV amp from the "AFTER SUM" monitor point on the same box. Monitored the PMC PDH error signal using the single-pin LEMO monitor point on the PMC servo board (call this Vmon). Both of these signals were monitored using a Tektronix digital O'scope.
  5. Downloaded the data using ethernet.
  6. Fit a line to the voltage applied to the NPRO PZT - I assumed the actual voltage being applied to the PZT is 15*Vmon, the pre-factor being what the Thorlabs HV amplifier outputs. The zero crossings of the sideband resonances in the PDH error signal are separated by 2*fmod (separated by fmod from the carrier resonance, fmod = 35.5MHz assumed). With this information, the x-axis of the sweeps can be converted to Hz, from which we get the PZT actuator gain in MHz/V. 

An example of the data used to calculate the actuator gain (left), and the spread of the calculated actuator gain (right - error bars calculated assuming 5e-4 s uncertainty in the sideband zero-crossing interval, and using the error in the slope of the linear fit to the sweep voltage):

This will now allow calibration of the PMC DAQ channels into Hz.

GV 4 April - The y-axis of the lower plot in Attachment #1 has mis-labelled units. It should be [V], not [MHz/V].

  12926   Mon Apr 3 23:07:09 2017 gautamUpdatePSLPMC DAQ assay for feed-forward integration

I made some changes to the DAQ path on the PMC servo board, as per the plan posted earlier in this thread. Summary of changes:

  1. AC coupling PMC control signal path using 2 x 47uF metal film capacitors (in parallel)
  2. Grounding pin 5 of U15
  3. Adding gain to U14 (gain of ~500) and U15 (gain of ~50)

Details + photos + calibration of DAQ channels to follow. The PMC and IMC both seem to remain stably locked after this work.

  12927   Tue Apr 4 11:24:21 2017 SteveUpdatesafetyProjector bulb is out again

Shipped out for repair.

Quote:

Three replacement bulbs ordered

Rana can discribe how it happened.

IF A LAMP EXPLODES

If a lamp explodes, the gas and broken shards may scatter inside the projector and they may comeout of the exhaust vent.
The gas contains toxic mercury.
Open windows and doors for ventilation.
If you inhale the gas or the shardsof the broken lamp enter your eyes or mouth, consult the doctorimmediately.
Quote:

This bulb was blown out on Feb 4, 2017 after 2 months of operation.

 

 

It is back and running fine witth bulb  4-13-2017

  12928   Tue Apr 4 17:27:58 2017 ranaUpdatePSLPSL NPRO PZT calibration

good cal. I wonder if this data also gives us a good measurement of the cavity pole or if the photo-thermal self-locking effect ruins it. You should look at the data for the positive sweeps and negative sweeps and see if they give the same answer for the cavity poles. Also, maybe we can estimate the PMC cavity pole using the sidebands as well as the carrier and see if they give the same answer? 

  12929   Wed Apr 5 16:05:47 2017 gautamUpdateGeneralNB code checkout

[evan, gautam]

We spent some time trying to get the noise-budgeting code running today. I guess eventually we want this to be usable on the workstations so we cloned the git repo into /ligo/svncommon. The main objective was to see if we had all the dependencies for getting this code running already installed. The way Evan has set the code up is with a bunch of dictionaries for each of the noise curves we are interested in - so we just commented out everything that required real IFO data. We also commented out all the gwpy stuff, since (if I remember right) we want to be using nds2 to get the data. 

Running the code with just the gwinc curves produces the plots it is supposed to, so it looks like we have all the dependencies required. It now remains to integrate actual IFO data, I will try and set up the infrastructure for this using the archived frame data from the 2016 DRFPMI locks..

  12930   Thu Apr 6 15:35:44 2017 SteveUpdatePEM envioirmental noise

Building:         Central Engineering Services

     

Date:             Monday, 04/10/17          

          

Time:             7:00 AM TO 9:00 AM           

 

Notification:     Crane Activity

    

Contact:          Ben Smith, X-4190 Brad Nielsen, X-8751

 

Contractors will be removing the large vaporizer located on the South

side of CES. Vehicle access will be restricted due to crane placement

and operation, but there will be a single traffic lane available. This

work may create minor noise and vibrations.  

  12931   Fri Apr 7 13:46:23 2017 SteveUpdateSUSETMX enclosure feedthough

ETMX enclosure feedtrouh cabeling corrected.

  12932   Mon Apr 10 09:49:32 2017 SteveUpdateOptical Leversoplev laser RIN test planning

We are planning to test 3 identical 1103Ps RIN with  continous temp monitoring and control later.

Selected  temp sensor   Platinum RTD 1PT100KN1515CLA   or           RTD-830 

Temp controller  with analoge output 0-10Vdc, CNi854  and external dc pulse driven  relay

Temperature Measurement Comparison Chart
Criteria Thermocouple RTD Thermistor
Temp Range -267°C to 2316°C -240°C to 649°C -100°C to 500°C
Accuracy Good Best Good
Linearity Better Best Good
Sensitivity Good Better Best
Cost Best Good Better

Order placed 4-12-17 for sensor  RTD-830,  controller CNi8-5-4 and relay  SSRL240DC25 = ~$500.

Still need: fuse, fuse housing, on/off switch, female  AC receptical, chassy box and AC power cord.

 

  12934   Mon Apr 10 14:21:57 2017 ranaUpdateOptical Leversoplev laser RIN test planning

I'm suspicious of this temperature sensor comparison. Usually, what they mean by accuracy is not the same as what we mean. I would not buy these yet. How about we just use what Caryn used several years ago (elog search) ?

  PS  Steve LM34             

  12936   Mon Apr 10 15:37:11 2017 gautamUpdateCOCRC folding mirrors - v3 of specs uploaded

Koji and I have been going over these calculations again before we send a list of revised requirements to Ramin. I've uploaded v3 of the specs to the DCC page. Here is a summary of important changes.

  1. Change in RoC specification - I condensed the mode-matching information previously in 8 plots into the following 2 plots. Between tangential and saggital planes, the harmonic mean was taken. Between X and Y cavities, the arithmetic mean was taken. Considering the information in the following plots, we decided to change the spec RoC from 600 +/- 50m to 1000 +/- 150m. The required sensitivity in sag measurement is similar to the previous case, so I think this should be feasible.

    Why this change? From the phase map information at  /users/public_html/40m_phasemap/40m_TTI gather that we have 2 G&H mirrors, one with curvature ~ -700m and the other with curvature ~ -500m. An elog search suggests that the installed PR2 has RoC ~ -700m, so this choice of RoC for PR3 should give us the best chance of achieving optimal modematching between the RCs and arms as per the plots below.

  2. Cavity stability checks - these plots confirm that the cavity remains stable for this choice of RoC on PR3...
      
  3. Coating design - I've been playing around with the code and my understanding of the situation is as follows. to really hit low AR of 10s of ppms, we need many dielectric layer pairs. But by adding more pairs, we essentially become more susceptible to errors in layer thickness etc, so that even though the code may tell us we can achieve R_AR(532nm) < 50ppm, the minima is pretty sharp so even small perturbations can lead to much higher R of the order of a few percent. On the HR side, we need a large number of layer pairs to achieve T_HR(1064nm)=50ppm. Anyways, the MC studies suggest that for the HR coating design, with 19 layer pairs, we can be fairly certain of T_HR(1064nm)<100ppm and R_HR(532nm)>97% for both polarizations, which seems reasonable. In order to make the R_HR(532nm) less susceptible to errors, we need to reduce the number of layer pairs, but then it becomes difficult to achieve the 50ppm T_HR(1064nm) requirement. Now, I tried using very few layer pairs on the AR side - the best result seems to be with 3 layer pairs, for which we get R_AR(532nm)<1% and T_AR(1064nm)>95%, both numbers seem reasonable to me. In the spectral reflectivity, we also see that the minima are much broader than with large number of layer pairs.

    First row below is for the HR side, second row is for the AR side. For the MC studies, I perturbed the layer thicknesses and refractive indices by 1%, and the angle of incidence by 5%.
        
       

If there are no objections, I would like to send this version of the specs to Ramin and get his feedback. Specifically, I have assumed values for the refractive indices of SiOand Ta2O5 from google, Garilynn tells me that we should get these values from Ramin. Then we can run the code again if necessary, but these MC studies already suggest this coating design is robust to small changes in assumed values of the parameters...

  12937   Mon Apr 10 16:00:26 2017 rebeccaUpdateCamerasPylon installation warning

When trying to install an older version of Pylon packaged for Debian that Joe B. had sent, it gave the warning that the package was of bad quality along with the details below.

Is it safe to ignore the warning? Or should I hold off on the installation?

Lintian check results for /home/controls/Downloads/pylon-2.3.3-1.deb:
Use of uninitialized value $ENV{"HOME"} in concatenation (.) or string at /usr/bin/lintian line 108.
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/.IpConfigurator
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/.PylonViewerApp
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/.SpeedOMeter
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtBase.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtBase.so.1
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtBase.so.1.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtBase.so.1.0.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtStyle.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtStyle.so.1
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtStyle.so.1.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtStyle.so.1.0.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtWidgets.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtWidgets.so.1
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtWidgets.so.1.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonQtWidgets.so.1.0.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonViewerSdk.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonViewerSdk.so.1
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonViewerSdk.so.1.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libPylonViewerSdk.so.1.0.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libQtNetwork.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libQtNetwork.so.4
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libQtNetwork.so.4.3
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libQtNetwork.so.4.3.2
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libjpeg.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libjpeg.so.62
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libjpeg.so.62.0.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libtiff.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libtiff.so.3
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/libtiff.so.3.7.3
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/bin/plugins/imageformats/libqtiff.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libXMLLoader_gcc40_v2_1.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxalan-c.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxalan-c.so.110
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxalan-c.so.110.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxalanMsg.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxalanMsg.so.110
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxalanMsg.so.110.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxerces-c.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxerces-c.so.27
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxerces-c.so.27.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxerces-depdom.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxerces-depdom.so.27
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApi/Generic/libxerces-depdom.so.27.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/GenApiPreProcessor
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/libGCBase_gcc40_v2_1.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/libGenApi_gcc40_v2_1.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/libLog_gcc40_v2_1.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/libMathParser_gcc40_v2_1.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/genicam/bin/Linux64_x64/liblog4cpp_gcc40_v2_1.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libgxapi-2.3.3.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libgxapi.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libpylonbase-2.3.3.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libpylonbase.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libpylongigesupp-2.3.3.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libpylongigesupp.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libpylonutility-2.3.3.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libpylonutility.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxalan-c.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxalan-c.so.110
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxalan-c.so.110.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxalanMsg.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxalanMsg.so.110
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxalanMsg.so.110.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxerces-c.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxerces-c.so.27
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxerces-c.so.27.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxerces-depdom.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxerces-depdom.so.27
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/libxerces-depdom.so.27.0
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/pylon/tl/pyloncamemu-2.3.3.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/pylon/tl/pyloncamemu.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/pylon/tl/pylongige-2.3.3.so
E: pylon: arch-independent-package-contains-binary-or-object opt/pylon/lib64/pylon/tl/pylongige.so

  12938   Mon Apr 10 18:42:09 2017 johannesUpdateCamerasPylon installation warning

It looks like we may not need to use this old Pylon version after all. Gautam and I looked into installing SnapPy with the makefile in scripts/GigE/SnapPy/ that he modified (removed the linkage to paths that don't exist in Pylon 5). Compiling took a while (~10 minutes) but eventually succeeded. The package was installed to /ligo/apps/linux-x86_64/camera/

GV 10pm April 10 2017: We didn't actually try executing an image capture or change some settings using the python utilities, that remains to be done..

  12939   Tue Apr 11 00:38:37 2017 gautamUpdatePSLPMC demod moved off servo board

As discussed at the Wednesday meeting last week, I tried moving the demodulation of the PMC error signal off the PMC servo board, by using some minicircuits components. This is just a quick summary elog, more details to follow tomorrow.

  • I used the Mini Circuits ZAD-6+. This is a level 7 mixer, and the LO board puts out ~16dBm, so I replaced the existing 3dB attenuator between the LO board and the input to the PMC servo board with a 9dB attenuator.
  • On the RF side, I retained the 35.5 MHz bandpass filter on the PD input.
  • On the IF output, I used an in-line 50ohm terminator in series with a minicircuits BLP1.9+ low pass filter
  • The mixer output was routed to the FP1 test input of the servo board
  • After some twiddling with the demod phase MEDM screen, I was able to lock the PMC. I've not done a thorough characterization of the loop with the current configuration, this will be done tomorrow. But the PMC and IMC have been stably locked for the last couple of hours...

During the course of this work, I noticed that there was a 35.5MHz line (at ~-55dBm) in the 4-pin LEMO DAQ outputs even when all other inputs to the servo board were terminated. So it seems like this pickup is not coming from the RFPD or demod path. The LO board has a shield enclosure similar to what we have on the LSC demod boards, but perhaps this shield does not enclose the full RF path, and there is some residual pickup between the two cards in close proximity in the Eurocrate?

On the bright side, with this demod setup, the higher harmonic peaks seem to be significantly suppressed.

In particular, the 3x35.5 MHz peak which was very prominent when I looked at these spectra with the nominal demod setup, seems to be much suppressed. 

I'm leaving the PMC servo in this configuration (off servo board demodulation using minicircuits parts) overnight.

  12940   Wed Apr 12 00:36:53 2017 gautamUpdatePSLPMC demod moved off servo board

Here is a more detailed comparison of the spectra of the signals at the front panel DAQ LEMO output, measured with the Agilent analyzer. I've left the scale linear, it looks like when the demodulation is done on the servo board, the 1x, 3x and 5x harmonics of the 35.5MHz modulation are clearly visible. I also plut in a plot of the spectra when both the PD and LO inputs to the servo board are terminated (and so the PMC is unlocked), but with the HV In and OUT of the servo board still connected. In this case, the higher harmonics vanish, but a 35.5MHz peak of ~-50dBm remains. Since this is present with no input to the servo board, this must be direct pickup from the nearby LO board? 

In any case, it looks like many of the harmonics that are present with the nominal demod setup either vanish or are much more suppressed when the error signal demodulation is done off the servo board yes.


Further down the signal chain, I had noticed sometime last week that the ADC signals for the PMC DAQ channels I set up seemed to saturate around 4000 counts. Rana mentioned that the ADC interface box with LEMO connectors on the front is powered with +/-5V. Valera and co. had simply increased the suppy voltage sometime ago to get around this problem, so I did something similar, and increased the supply voltage to +/- 15V. I then confirmed that the ADC doesn't get saturated by driving the input with a +/-5V signal. So now the amplified AD620 signals from the PMC servo board are better matched to the ADC range. 

Here is an uncalibrated spectrum (taken with IMC locked), compared to the current ADC noise and signal levels before the AD620s were given gain.

I now need to think a little about what exactly the control scheme would be if the PMC is used as a reference for the IMC over some frequency range...

 

  12941   Thu Apr 13 09:48:37 2017 SteveUpdateSUSITMY-UL and ETMX sensors

Why ITMY UL can not see this earth quake? SRM and PRM are misaligned. ETMX is still not well.

We have to remember to check OSEM - magnet alignment when vented.

  12942   Thu Apr 13 19:54:07 2017 ranaUpdateDAQcheckup on minute trends

Our minute trends are still not available through NDS2 from the outside world due to the bad config of the DAQ, but I can confirm that we still have the minute-raw capability. This is 111 days of Seismic BLRMS.

However, it seems we're only able to get ~1 week of lookback on our second trendssadno and that is low-down dirty shame. We used to have over a month of second trend lookback before the last decade of 'upgrades'.

  12944   Tue Apr 18 01:01:03 2017 gautamUpdatePSLPMC OLTF measured, DAQ channels calibrated

Quick entry, details to follow in the AM tomorrow.

  • I calibrated the PMC DAQ channels into physical units - there now exists in the filter modules  cts2m and cts2Hz filter modules, though of course only one must be used at a time
  • Finally measured the PMC OLTF, after moving the PMC PDH error signal demodulation off the servo board - I used the same procedure as Koji when he made the modifications to the PMC servo board, I will put up the algebra here tomorrow. Turns out the previously nominal servo gain of +10dB on the MEDM sliders was a little low, the new nominal gain is +20dB, and has been updated on the MEDM screen.

ToDo:

  • Put up the modified schematic on the 40m DCC tree Done April 18 10pm
  • Check calibration by comparing inferred PMC cavity displacement from error point and control point spectra, using the measured OLTF
  • Finish up looking at multicoherence with MCL and various witness channel combinations

   

  12945   Tue Apr 18 16:10:00 2017 gautamUpdatePSLPMC OLTF measured, DAQ channels calibrated

Here are the details:

  1. PMC OLTF:
    • the procedure used was identical to what Koji describes in this entry.
    • I used the SR785 to take the measurement.
    • MEDM gain slider was at +20dB 
    • I used the two single pin LEMO front panel monitor points to make the measurement. 
    • Mix_out_mon was CH2A, HV_out_mon was CH1A on the SR785
    • A = CH2A/CH1A with the SR785 excitation applied to the EXT_DC single pin LEMO input on the front panel. I used an excitation amplitude of 15mV
    • B = CH2A/CH1A without any excitation
    • Couple of lines of loop algebra tells us that the OLTF is given by the ratio A/B. The plot below lines up fairly well with what Koji measured here, UGF is ~3.3kHz with a phase margin of ~60degrees, and comparable gain margin at ~28kHz. As noted by Koji, the feature at ~8kHz prevents further increase of the servo gain. I've updated the nominal gain on the PMC MEDM screen accordingly... I couldn't figure out how to easily extract Koji's modelled OLTF so I didn't overlay that here... Overlaid is the model OLTF. No great care was taken in analyzing the goodness of the agreement with the model and measurement by looking at residuals etc, except that the feature that was previously at 28.8kHz now seems to have migrated to about 33.5 kHz. I'm not sure what to make of that. 
  2. PMC DAQ calibration:
    • The calibration was done using the swept cavity, the procedure is basically the same as described by Koji in this elog.
    • The procedure was slightly complicated by the fact that I added gain to the AD620 buffers that provide the DAQ signals. So simply sweeping the cavity saturates the AD620 very quickly.
    • To workaround this, I first hooked up the un-amplified single pin LEMO front panel monitor points to the DAQ channels using some of the available BNC-LEMO patch cables.
    • I then did the swept cavity measurement, and recorded the error and control signals fron the single pin LEMO front panel monitor points. Sweep signal was applied to EXT_DC input on front panel.
    • In the nominal DAQ setup however, we have the amplification on the AD620. I measured this amplification factor by hooking up the single pin LEMO monitor point, along with its corresponding AD620 amplified counterpart, to an SR785 and measuring the transfer function. For the PMC_ERR channel, the AD620 gain is ~53.7dB (i.e. approx 484x). For the PMC_CTRL channel, the AD620 gain is ~33.6dB (i.e. approx 48x). These numbers match up well with what I would expect given the resistors I installed on the PMC board between pins 1 and 8 of the AD620. These gains are digitally undone in the corresponding filter modules, FM1.
    • To calibrate the time axis into frequency, I located the zero crossings of the sidebands and equated the interval to 2 x fmod. For the PMC servo, fmod = 35.5MHz. I used ~1Hz triangle wave, 2Vpp to do the sweep. The resulting slope was 1.7026 GHz/s.
    • The linear part of the PDH error signal for the carrier resonance was fitted with a line. It had a slope of 1.5*10^6 cts/s.
    • The round trip length of the PMC cavity was assumed to be 0.4095m as per Koji's previous entry. This allows us to calibrate the swept cavity motion from Hz to m. The number is 1.4534 * 10^-15 m/Hz. I guess we could confirm this by sweeping the cavity with the DC bias slider through the full range of 0-250V, but we only have a slow readback of the PMC reflection (and no readback of the PMC transmission).
    • Putting the last three numbers together, I get the PMC_ERR signal calibration as 1.6496 pm/ct. This is the number in the "cts2m" filter module (FM10).
    • An analogous procedure was done to calibrate the control signal slope: from the sweep, I got 4617 cts/s, which corresponds to 2.7117*10^-6 cts/Hz. Using the FSR to convert into cts/m, I get for PMC_CTRL, 535.96 pm/ct. This is the number in the "cts2m" filter module (FM10).
    • For convenience, I also added "cts2Hz" calibration filters in FM9 in the corresponding filter modules. 

The updated schematic with changes made, along with some pictures, have been uploaded to the DCC page...

Quote:

Quick entry, details to follow in the AM tomorrow.​

 

  12946   Tue Apr 18 23:37:15 2017 ranaUpdatePSLPMC OLTF measured, DAQ channels calibrated

What's the reasoning behind setting the the gain to this new value? i.e. why do these 'margins' determine what the gain should be?

  12947   Wed Apr 19 15:13:30 2017 gautamUpdatePSLPMC/MCL multicoherence

I used a one hour stretch of data from last night to look at coherence between the PMC control signal and MCL, to see if the former can be used as a witness channel in some frequency band for MCL stabilization. Here is a plot of the predicted subtraction and coherence, made using EricQs pynoisesub code. I had thought about adopting the greedy channel ranking algorithm that Eric has been developing for noise subtraction in site data, but since I am just considering 3 witness channels, I figured this straight up comparison between different sets of witness channels was adequate. Looks like we get some additional coherence with MCL by adding the PMC control signal to the list of witness channels, there is about a factor of a few improvement in in the 1-2Hz band...  

  12948   Wed Apr 19 15:46:24 2017 gautamUpdateGeneral1611/1811 inventory check

I looked through the lab area to do a fast photodiode inventory check, as we may need to buy some for the higher order mode spectroscopy SURF project. I looked on the following optical tables: ETMY, ITMY, BS, AS, PSL, SP, ITMX, Jenne laser table, and ETMX, as well as the photodiode cabinet, and could only find two 1611s. Here is a summary of the inventory: 

  • Power supply 0901: 2x in photodiode cabinet (E6 along the Y arm), 1x on Jenne laser table
  • Newfocus 1611 S/N 7284-WX, labelled "REF DET" on ITMY optical table, currently unused
  • Newfocus 1611 S/N 57109 on Jenne laser table

I have not yet checked if these photodiodes are in working order.

 

  12950   Tue Apr 25 19:35:41 2017 gautamUpdateGeneralIPCS -q

Dataviewer wouldn't launch on pianosa - it seemed to work fine on Donatella though. Rana suggested using the ipcs -q command. The complete fix can be found in this elog. This did the trick, dataviewer runs fine on Pianosa now...

  12951   Wed Apr 26 01:00:23 2017 gautamUpdateGeneralDRMI locking

Since we'd like to get back to DRSE locking, I tried locking the DRMI tonight. I did the following:

  • First, I aligned the arms, and ran the dither alignment scripts to maximize the arm transmission
  • Next, I misaligned the ETMs, and tried to lock the PRC resonant for the carrier (i.e. PRCL on REFL11I, MICH on AS55Q). I got brief lock stretches of a few seconds but not longer. Turns out the AS55 beam was barely hitting the photodiode. I guess this wasn't looked at since Johannes modified the AS path for the loss measurements. Anyways, it just required a minor tweak to center the beam on the AS55 photodiode.
  • Once the PRC was locked, I ran the PRC and MICH dither align scripts. The way these are set up right now, the error signals to these servos are REFLDC and ASDC respectively (demodulated at the respective dither frequencies). But looking at the spots on the ITM cameras with the PRC resonant, the spots seem shifted (in both PIT and YAW) relative to the spots when the arm cavity is resonant. Shouldn't they be the same mode? Or maybe I am missing something.
       
  • Next, I tried to lock the DRMI with the 1f error signals: i.e. PRCL on REFL11 I, SRCL on REFL55 I, and MICH on AS55 Q. After some demod phase tweaking, I was able to get some locks going. Turning on the PRC angular feedforward seemed to help the locking, but I have no idea if the installed filters are still the correct ones. I believe the POP QPD channels are the witnesses used to train this filter, I will look at the predicted vs achieved subtraction.
  • At this point, I was able to get locks lasting a few minutes - see the attachment. I ran the UGF servos and tweaked the loop gains a little, but before I could start a loop measurement, I lost the lock. I am calling it for the night.

GV 26 April 2017, 3pm: Forgot to note yesterday that I re-connected the suspect Satellite box, which has been connected to the SRM signal chain, back to the SRM suspension. I did not see any instances of glitching during my work last night. Also added pictures showing shifted spots on ITMs when PRC is locked relative to when arms are locked...

  12952   Thu Apr 27 16:41:13 2017 Eric GustafsonUpdateLSC Status of the 40 m PD Frequency Response Fiber System
There two reports in the DCC describing the state of the system as of October 2014 including: (1)  Alex Cole’s “T1300618 Automated photodiode Frequency Response Measurement System” and a Wiki  created by Alex Cole where there are some instructions on the Master Script at https://wiki.ligo.caltech.edu/ajw?AlexanderCole    

And (2)  P140021 “Final Report: Automated Photodiode Frequency Response Measurement System for 40m Lab” by Nichin Sreekantaswamy and also as part of Nichin’s report by there is an archive of data at   https://wiki-40m.ligo.caltech.edu/Electronics/PDFR%20system   

I made a visual inspection of the system and saw that the following fibers collimators are still mounted in alignment mounts and the fiber is attached and pointed at a photodetector but possibly not aligned. 

ASP Table

Photodetector Label                             Fiber Label

REFL11                                              REFL55 Fiber on mount        

REFL33                                              REFL33 Fiber on mount

REFL55                                              REFL11 Fiber on mount

REFL165                                            No Fiber

AS55                                                   AS55 Fiber on mount

MCREFPD                                         MCREFPD Fiber on mount

No PD                                                 Loose unlabeled Fiber No mount

 

ITMX Optics Table

Photodetector Label                             Fiber Label

POX11                                                POX11 on mount

Unlabeled PD                                      POP22/POP110 on mount

NO PD                                                 POP55 loose fiber No mount

 

The RF switch seems to be hooked up and there is a fiber running from the Diode Laser module to the fiber splitter module. So REFL 11 and REFL545 seem to be illuminated by the wrong fiber. I’ll try and run the software on Monday and check to see if I need to move the fibers or just relabel them.

  12953   Thu Apr 27 17:55:33 2017 SteveUpdateCameraswhich camera to use for IR scatterring pictures

Yesterday I failed to take good pictures of ETMY  resonant arm of 1064 nm with Cannon Rebel T3i in RAW 22-27Mp & JPG dual- format. UFRaw file converter worked well. The IR blocker filter seems to be too good.

Today I used Olympus SP-570UZ ( without IR blocker), in raw format of 15Mp, fl 22.4mm, 15s including 2-3s flashlight,  f/8 and auto focus  This is just too much scattered IR for the Olympus.

Overexposed raw picture' jpg is shown  at the PSL with diffraction patter of the camera.

I'll go back using  the Nikon D40 with zoom 55-200mm as this Atm2 of May 2007 : manual focus, 15s, f/4-5.6, ISO 560,  826KB

  12954   Fri Apr 28 02:04:36 2017 gautamUpdateGeneralDRMI locking

I got a couple of ~30min long DRMI lock stretches today. The settings I used are essentially the same as what I had back in November. Though we have since made some changes to the IMC RF signal chain, I guess it is not unreasonable that the LSC Demod phases that worked then work now as well. 

In the lock stretches, I did the following:

  • Took loop measurements for MICH, PRCL, SRCL
  • Turned on the sensing oscillator lines for error signal calibration
  • Tried turning on the analog whitening on AS55, REFL11 and REFL55. The latter two worked fine, but everytime I turned the REFL55 whitening on, I broke the lock. I'm also unable to acquire lock if I leave the whitening turned on all the time. The ADC overflow indicators also indicate frequent overflows when I turn the whitening on. Oddly, this seems to happen even if I turn the analog whitening gain to 0dB - the signals look well within the ADC range on dataviewer and DTT timeseries mode. Not sure what's going on here, I will investigate further tomorrow.
  • We should have some stretches where we can look at the possibility of seismic feedforward for some DRMI length DOFs.

On the side, I'm also looking at whether the PRC angular feedforward filters, last trained in October 2016, remain valid. Even post midnight, I am unable to lock the DRMI without turning on the FF, and looking at the POP QPD PIT and YAW signal spectra with the FF on vs FF off, there is definitely some improvement in the 1-4Hz band (plot to follow), question is whether we can do better and hence improve the DRMI duty cycle/ make the lock acquisition easier. To this end, I centered the beam on the POP QPD after locking and dither aligning the PRC on carrier, and have taken some data to look at.

So, much data analysis to follow - the idea is to put together a DRMI noise budget with Evan's NB code. For now, here are the uncalibrated control signal spectra.

  12955   Fri Apr 28 13:56:26 2017 ranaUpdateGeneralDRMI locking

one of these signals does not look like the others: explanation?

  12956   Fri Apr 28 18:01:56 2017 rebeccaUpdateCamerasAttempting to Load Camera Client

Using /ligo/apps/linux-x86-64/camera/bin/camera_client.py -c  /opt/rtcds/caltech/c1/scripts/GigE/SnapPy/L1-CAM-MC1.ini, the Python script was able to run without error but didn't show any video feed from the camera in GStreamer. Problem might be in the configuration of the camera in the .ini file.
 

  12957   Fri Apr 28 19:32:06 2017 gautamUpdateGeneralDRMI locking - PRCL angular FF

I took a closer look at the POP QPD/ PRC angular feedforward situation yesterday. I thought it would be useful to have a POP QPD MEDM screen. Looking at the PIT and YAW channel filter modules, the anti-whitening filters seemed different from what we have for other channels that are connected to the Pentek interface board (e.g. MCL). So I copied over the 150:15 (z:p) filter, and also turned on a 60Hz comb. The LSC offsets script does not set the dark offsets for this QPD, so I manually put in the dark offsets for the PIT, YAW and SUM channels as well. For the locking, I first locked the arms on IR an dither aligned them. Then I locked the PRMI on carrier, ran the PRC dither alignment, and went over to the ITMX pickoff table and centered the beam on the QPD by making the PIT and YAW channel timeseries oscillate around approximately zero. 

After these tweaks, I collected ~40mins of data with the angular FF OFF/ON. I did not DC couple the ITM Oplev servos, but Eric tells me that this did not make a difference to the achievable subtraction in the past. Here is the frequency domain multicoherence analysis - I used the BS_X and BS_Y seismometer channels as witnesses. I've also put a plot with what the raw FF filter coefficients look like (no fitting yet). 

      

Looks like we can do better for both DOFs - it even seems like we are injecting noise with the current FF filters in some bands, perhaps we can do a better job of rolling off the filters outside the band of interest. Eric and I were discussing MATLAB's "reduce" routine for this purpose, I will play around with it and see if I get a better fit.

Unfortunately, I encountered a strange error when trying to pull data with nds2 today, it kept complaining RuntimeError: Too many channels or too much data requestedeven though I have pulled longer stretches of data for more channels with 16k sampling rate as recently as last week. Shorter duration requests (<600 seconds) seemed to work fine though... So I had to use cds.getdata to pull the data, and they're much too large to attach. Has anyone else encountered a similar error?


The mystery of the spots on the ITMs when the PRC is locked on carrier remains - after talking this over with Koji, we figured that even with the carrier resonant, the spot will be much dimmer than the spots when the arms are locked, but what I see on the cameras is still a pretty beefy spot. The real cavity mode is actually visible where it should be (I marked the locations of the spots with arms well-aligned with a marker on the monitors), as given away by some twinkling that is visible only when the cavity is locked. But what ghost beam is so intense it looks almost as bright as when the arm is locked?

GV 10pm 28 April 2017: Turns out this is the spot from the single bounce off the ETM transmitting back through the ITM and hitting the suspension cage (hence the bright spot). Johannes and I confirmed by moving the ETM, the spot moved with it. I just never paid attention to this spot before.

  12958   Fri Apr 28 22:50:35 2017 johannesUpdateCamerasAttempting to Load Camera Client

You'll likely have to run camera_server.py using the same ini file first before you can use the client. Since the pylon installation is not on the shared drive but only local to optimus at the moment you would have to do it from there. You'll need to add /opt/pylon5/lib64/ to LD_LIBRARY_PATH or it won't find some required libraries. I couldn't start up the server all the way, probably because we need to define some slow EPICS channels before running the server script, as Joe points out in his document T1300202. You'll find instructions how to do that for example in this elog.

 

Quote:

Using /ligo/apps/linux-x86-64/camera/bin/camera_client.py -c  /opt/rtcds/caltech/c1/scripts/GigE/SnapPy/L1-CAM-MC1.ini, the Python script was able to run without error but didn't show any video feed from the camera in GStreamer. Problem might be in the configuration of the camera in the .ini file.
 

 

  12959   Sun Apr 30 13:24:00 2017 ranaUpdateCamerasAttempting to Load Camera Client

We ought to put the camera software on the shared disk; I don't think there's any speed reasons that it needs to be local.

Its OK to use optimus as the camera server for testing at the moment, but once we have things running, we'll install a few more cameras. With ~4-5 GigE running, we may not want to share with optimus, since we're also using it for comsol and skymap calculations.

  12960   Mon May 1 16:29:51 2017 gautamUpdateGeneralDRMI locking

For the traces I posted, I had not turned on the whitening for the SRCL sensing PD (REFL55). However, I took a spectrum on a subsequent lock, with the analog whitening + digital dewhitening turned on for all 3 PDs (AS55, REFL11 and REFL55), and the HF part of the SRCL spectrum still looked anomalous. I'm putting together the detailed NB, but here's a comparison between the signals from the 3 RFPDs with the PSL shutter closed (but whitening engaged, and with the analog gains at the same values as used during the locking).

 

To convert the y-axis into m/rtHz, I used data from a sensing matrix measurement I took yesterday night during a DRMI lock - I turned on lines between 300 Hz and 325 Hz for the 3DOFs for ~5 minutes, downloaded the RFPD error signal data and did the demodulation. I used numbers from this elog to convert the actuator drive from cts to m. The final numbers I used were:

MICH (AS55_Q):   8.706 * 10^11 cts/m

PRCL (REFL11_I): 2.757 * 10^12 cts/m

SRCL (REFL55_I): 1.995 * 10^10 cts/m

So it looks like there may be something weird going on with the REFL55 signal chain. Looking at the LSC rack (and also suggested by an elog search), it looks like the demodulation is done by a demod board labelled "POP55" - moreover, the demodulated outputs are taken not from the regular output ports on this board, but from the "MON" ports on the front panel. 

Quote:

one of these signals does not look like the others: explanation?

 

ELOG V3.1.3-