40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 254 of 339  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  4964   Wed Jul 13 12:24:46 2011 NicoleUpdateSUSWeekly Update
This week, I have been working on the photosensor circuit box.  This photosensor box will contain the current-stabilizing power supply and
voltage readout for the two photosensors I plan to build.
 
Suresh helped to walk me through the design of the photosensor circuit (image below) so I now understand how the circuit works.
PHOTOSENSORPLAN.JPG
 
 
Jaimie helped me to reorganize the original circuit layout I had to make it easier to follow. I have now redone half of the circuit (enough for one LED and photodiode pair). I still need to put in the voltage-regulators to provide the + and - 15 V neeCto power the op-amps but I will do that after testing the circuit.
prelimcircuit.JPG

In order to test this preliminary circuit, I need to build the photosensor heads.  Yesterday, Suresh helped me to open one of the professionally-build photosensors in the lab to understand how to arrange my photosensor heads. I now understand that I need to rigidly-mount the PCB to photosensor head box. I plan to use the PCB below. It will be sufficient for the lower-frequency range (below 10Hz) that I am interested in. 

PCBforphotosensor.JPG

 I would like to use a metal box like the one below to make each photosensor head. I looked in the lab last night for similar boxes but could not find one. Does anyone know where I can find a similar metal box?

lookingforbox.JPG

 

I am now working on accelerometer. I am working on attaching these metal wires to the pins of the accelerometer so that I can use clip leads to power and extract voltage measurements from my circuit.

 accelerometer.JPG

  10096   Wed Jun 25 01:18:24 2014 AkhilUpdateelogWeekly Update

 Plans for the Week:

  • Phase and noise characterization of the UFC RF Frequency Counter.
  •  Characterization of the temperature actuator.

Progress and Problems Faced:

  • Since past two days, I have been trying to measure the phase difference between the input and output signals of the FC using a 16 bit ADC ADS1115 (for input phase measurement) on Raspberry Pi(RPI).For that I have assembled a Circuit on a breadboard( Details will be mentioned in my next eLog). 
  • The interfacing and the codes seem to be alright but the RPI is not able to detect the address of the ADC chip. I will try to debug the issue as soon as possible and try to take data through the Pi so that I can have both delay and noise introduced by the FC.
  • Now since the minimum sampling time of the FC has been brought down to 0.1s, I will test how accurately the FC is writing values every 0.1 s for a modulating input.
  • The output data of the FC will be fitted into the input and the order of accuracy will be presented.Also the gain plots will be plotted at higher frequencies like 50 MHz, 100 MHz, 500 MHz and 1000 MHz using the network analyzer.

Work Inside the Lab:

  • On Friday Morning I will  go inside the  lab with Manasa to make measurements from the NPRO to characterize its response to the temperature.
  • I will be in the lab in the morning session(9 am- 1 pm) and make the required measurements. I will then analyze the data and by the end of the week will finish characterization of the FC and temperature actuator.
  • For the rest of the time in this week, I'll be on my desk and will not be entering  the lab.

Electronics Required:

  • I will require the network analyzer on Wednesday and Thursday to make measurements at higher frequencies(30 MHz <F<1000 MHz) from the R PI.

Goal- By the end of the week:

  • To characterize both the FC and the NPRO that would go into the FOL-PID loop.
  • The FC will be ready to replace the network analyzers that are currently being used in the 40m.

 

 

 

 

 

  10100   Wed Jun 25 09:30:44 2014 HarryUpdateGeneralWeekly Update

See attached weekly update

Attachment 1: Weekly_Update—June_25_thru_July_1.pdf
Weekly_Update—June_25_thru_July_1.pdf
  10161   Wed Jul 9 08:50:30 2014 AkhilUpdateGeneralWeekly Update

 

Last Week's Work:

  • Worked on the setup to mitigate timing issues arising due to the non-synchronization of clocks of the Frequency counter and Raspberry Pi .
  • Took measurements with the mentioned setup and generated PSD plots of the FC.
  • Completed the setup for phase measurements by using an external ADC.

 

Work Plan for this Week:

  • Complete the installation of the Mini Circuits Frequency Counter on the EPICS. This involves installation of EPICS base on Raspberry Pi, creating an IOC server on the R Pi and writing the data from the FC into a specific IOC  channel. 
  • Complete phase measurements and obtain the delay in the FC thus completing the characterization of the FC.
  • Install the FC at a suitable place inside the 40m so that the beat note system can be remotely managed from any of the Control computers thus effectively replacing the spectrum analyzer(This will be done with proper supervision once the recently ordered FC is shipped)

 

Inside the 40m :

  • I will be going inside the lab today around 9 am with Manasa to make a plan about where the FC must be placed and the routing of the RF cables and the cables which run  into computers from the FC.
  • Once the channel is created and tested, we will install the FC inside the lab possibly by the end of this week or by next week.
  10215   Wed Jul 16 07:51:52 2014 AkhilUpdateGeneralWeekly Update

Work Done:

  • Solved all the timing issues pertaining to the R Pi and the FC.
  • Took all the measurements for complete characterization of the frequency counter(Phase Plots to follow shortly).
  • Finished  installation of the FC on the martian and created a channel  for the FC frequencies(will be tested in this week).

Plans for this Week:

  • Testing of the EPICS soft IOC created for the FC as a channel access server and hence completing the installation of the FC.
  • Placing the FC inside the lab( plan discussed in this elog: http://nodus.ligo.caltech.edu:8080/40m/10163) with proper supervision.
  • Characterization of the temperature actuator.

Inside the 40m Lab:        

I will need to be inside the lab to place the FC . This will be done in the morning session (on thursday) with supervision of Manasa and Steve(if required).

 

 

 

 

 

 

 

 

  10256   Tue Jul 22 17:45:11 2014 HarryUpdateGeneralWeekly Update

 The Past Week

 

I spent the past week coupling NPRO light into the fibers, and subsequently measuring the fiber mode profile using the beam profiler.

The Next Week

In the next week, I plan to at least do measurements of the Polarization Extinction Ratio of the fibers.

Materials

My current optical setup, plus an additional polarizing beam splitter (have it).

  10257   Tue Jul 22 23:10:12 2014 AkhilUpdateGeneralWeekly Update

 Work Done:

  • Created a Channel Access Server on the Raspberry Pi  to write data from the FC into EPICS Channel.
  • Completed characterization and noise estimation of the FC counter with improved timing.
  • Started installation of FC inside the 40m.

Plans for this Week:

  • Testing how well the FC can replace the spectrum analyzer which is in the control room. For this I have asked Steve to order  an RF adder/combiner to see how frequency counter responds to two RF signals at different frequencies(much like the RF signal fed to the spectrum analyzer) .
  • Complete the installation of FC insode the 40m and start initial testing.
  • Characterization of the Temperature Actuator and initial PID loop design.

Inside the 40m Lab:

  • I will have to go inside the 40m lab this week for routing the RF mon cables to the FC box(in detail:http://nodus.ligo.caltech.edu:8080/40m/10163) .
  • Also to setup for characterization of the temperature actuator, I will be required to go inside the lab in this week.
  10260   Wed Jul 23 10:40:23 2014 NichinUpdateGeneralWeekly Update

To do:

  1. Measure and calibrate out  attenuation and phase changes due to RF cables in the PDFR system.
  2. Create a database of canonical plots for comparison each time new data is acquired.
  3. Vector fitting or LISO fitting of transimpedance curves.

Does not require time from a lab expert.

  10297   Wed Jul 30 11:15:44 2014 AkhilUpdateGeneralWeekly Update

 Plan for the week:

  • PID loop design and testing with the Green laser beat note by actuating the arm cavity length.
  • Beat note readout on MEDM screens and Strip tool.
  • Calibration of the laser frequency response to PZT signal in MHz/V using a test DC input(Koji assigned me this task because this calibration has not been done and is very useful).

Inside the Lab:

  • Placing the FOL box sometime in the afternoon today(with supervision of Manasa / EricQ).
  • Calibration of the PZT(Today or tomorrow).

 

  10373   Wed Aug 13 10:49:39 2014 HarryUpdateGeneralWeekly Update

 In the past week, I designed and assembled coupling telescopes for the PSL and Y Arm Lasers

The Y Arm was coupled to ~5mV, and the PSL remains uncoupled.

 

For the next week, I'm planning on working on things like my presentation and/or final report.

Though as of last night, my computer refuses to turn on, so there may be some further "troubleshooting" involved in that whole process.

  10154   Tue Jul 8 16:45:15 2014 NichinUpdateGeneralWeekly plan

 My plan for next week is...

1)    1) Taking DC output readings with multimeter for each PD to create a database for all the PDs. Requires taking off the table tops for each PD.  Also, making sure each PD is illuminated properly.

    2 - 3 Hours inside the lab 

    Requires presence of expert

Occupies all the PDs , RF switch and the Network analyzer.

2)    2)  Integrate the switch selection script with the Network analyzer script to complete the automation part of the project.  (If time permits, build a simple GUI for easy operation)

Occupies the control room computer, RF switch and the Network analyzer

3)    3)  Create a database of canonical plots for each PD to compare with the current plot and maybe even plot the difference between the current plot and canonical plot.

Occupies the control room computer, PDs , RF switch and the Network analyzer.

4)    4)  Fit the transfer function or transimpedance using vector fitting. (vectfit4.m)

5)    5) Update 40m-Wiki

6)    6) Progress Report to be submitted to SFP.

  4835   Mon Jun 20 00:59:02 2011 kiwamuSummaryGeneralWeekly report
This is a summary for the week ending June 19th. Feel free to edit this entry.
(Number of elog entries = 27)

* Refinement of LSC screen
    -> Kissel buttons and some indicators were newly installed
    -> A script to autonatically generate kissel buttons was made

* New BIO installed on ETMY

* LightWave for ABSL
    -> taken out from the MOPA box and put on the AP table with temporary use of the Y end laser controller
 
* Shipping 2 RFPDs to LLO
 
* LEDs on the BIO for the vertex suspensions were blown
    -> fixed and re-installed. A test script will be prepared
 
* PEM AA board was fixed
 
* A plot of the MICH noise was produced for the first time
 
* Schnupp asymmetry measurement : Las = 3.64+/-0.32cm
 
* The photo diode on WFS2 has been replaced by YAG-444-4A
 
* SUS binary IO crates were taken out
 
* Fiber died
     ->C1LSC was unable to communicate to C1SUS. Installing a new copper Dolphine fixed the issue.
 
* SURF students came
  4890   Mon Jun 27 10:04:29 2011 kiwamuSummaryGeneralWeekly report

 Summary for the week ending June 26th.  (Number of elog entries = 53)

- SUS
  A BIO installed on 1X2.
  A peak finding script was prepared for diagonalization of the OSEM input matrices
  The suspension readout coefficients were changed to have unit of [um] and [urad] in each signal.
 
- ABSL
    LWE NPRO controller was brought by Peter King.
    The I-P cuvre and beam profile was measured. Nominal current was chosen to 1.8 [A].
    The access tube between PSL and AS table was back in place.
 
-RFPD
   The REFL55 characterization was analyzed (impedance gain = 615 Ohm, shot noise intercept current = 1.59 mA )
 
- MC
   WFS1 check, the 29MHz resonance need to be adjusted.
   The MC locking gain was increased by 6 dB to avoid an oscillation at 30 kHz.
 
- LSC
  The sensing matrices were measured in DRMI configuration and PRMI configuration
 
- Fiber experiment
   QPDY_PD was repositioned to accommodate the fiber stuff on the ETMY table.
   Succeeded in introducing the IR beam into the fiber coupler.
 
- TT characterization
    Th optic bench next to MC2 was cleaned up and leveled
 
- Vent list wiki page
   A wiki page was made for the vent detailed plan.
 
- CDS
  A foton's malfunction was found. It can run correctly only on Pianosa.
  Some Dell machines were gone to Rod Luna
 
- 40m specfic safety training for the SURFs
  4936   Mon Jul 4 14:27:35 2011 kiwamuSummaryGeneralWeekly report

Summary of the week ending July 3rd.  Number of elog entries = 44 

- SUS

   * The output TO_COIL matrix were simplified
   * Checked all the BO whitening switch => Only ITMY_UL didn't switch
   * All the DOF filters were normalized.
       => All the DOF filters are now ("3:0.0", "Cheby", "BounceRoll") 
       => The High pass should have 30Hz cut off ("30:0.0") ?
   * All the resonant peaks has been fit

- LSC

   * MICH noise budget.
               => dominated by sensing noise.
   * The sensing matrix in the PRMI configuration was measured. 
               => The demodulation phase on AS55 seemed wrong. Need a doublecheck
   * A new screen, called C1LSC_OVERVIEW.adl, was released.

   * A channel name modification: "PRC" and "SRC" => "PRCL" and "SRCL" and etc.
   * The response of the LSC whitening filters were checked. 
                 => CH26 showed different phase response.
 

- MC work

 * Power budget on the AP table was made (in a high power situation).
REFL11 = 7.4 mW
REFL55 = 22 mW
        MCREFL = 114 mW
        WFS1   = 1.24 mW
        WFS2   = 2.7 mW
 * Measurement and adjustment of RFQPD response
         Resonance frequencies of WFS1 and WFS2 were adjusted. WFS1 and WFS2 were installed on the AP table
 * Started working on MCL path. 
         => needs some more CDS jobs to correctly assign ADC channels

- CDS

 * Joe modified the automated scripts for producing model webviews

- ABSL

  * The alignment of the injection beam was done.

- Fiber experiment

 * A fiber was laid down from the ETMY table to the PSL table

- TT characterization

 * The mechanical stage for the horizontal displacement measurements is set up. 

- Configuration and other topics

      * Maglev stuff has gone to bridge lab.
      * Chris.W told us that the EPICS mutex issue can be solved by upgrading the EPICS version
      * All the PDs are stored in the east arm cabinet E4
      * Safety interlocks were connected to the ETMY laser and ABSL laser
      * Cshrc.40m was modified to make 32-bit machine happy
      * NDS2 buffer size on Mafalada had been too small and was increased somewhat such that we can still work for the SUS peak fit job
 
  5026   Mon Jul 25 11:02:19 2011 kiwamuSummaryGeneralWeekly report

 Summary of the week ending July 10th.  Number of elog entries = 21

- SUS

 + The cutoff frequency of the high pass filters for the damping were set to 30Hz.
 + Turned off all the BounceRoll filters.
 + The BS oplev was checked and seemed healthy.
 

- LSC


 + All the measred data of the LSC whitening filters were fit.
 + All the zpk parameters are recorded on the wiki.

- ABSL

 

+ The setup completed.  
 + The freqeucy-lock of the ABSL laser was achieved with UGF of ~ 40kHz.
 + The temperature of the ABSL laser was adjusted to be 47.25 deg
 

- ALS

 (Fiber experiment)
 + The I-P curve of the ETMY laser was measred.
 + The current set point is 1.8 [A], which used to be 1.5 [A], corresponding to the output of power of 197 [mW] and 390 [mW] respectively.
 

  5027   Mon Jul 25 11:04:22 2011 kiwamuSummaryGeneralWeekly report

Summary of the week ending July 17th.  Number of elog entries = 20

- LSC
 * BO switching logic for the WF was installed on c1lsc
 * Channel mapping updated

- SUS
 * Oplev health check. Spectrum of each quadrant on every suspension was inspected and looked healthy.

- OAF
 * BNS interface board was attached to an AA board
 * The AA board was installed on 1X7. The Electro-optic fanout chassis on 1X7 is now sitting on a jack, this should be fixed.

- Fiber experiment (ALS)
 * Fibre from the ETMX and EMTY tables were routed to the PSL table

- Misc.
 * Alberto came over to the 40m with Wagonga
 
  5028   Mon Jul 25 11:06:38 2011 kiwamuSummaryGeneralWeekly report

Summary of the week ending July 24th.  Number of elog entries = 45


- LSC
 * Check of LSC WF switching
  -> some were switching, but the majority were not.

- SUS
 * Ran activateDQ.py for seeting some DQ channels of Oplevs
 * Turned ON all the offset buttons on the OL1, etc.
 * Rebuilt and restarted c1msc, c1sus, c1scx and c1scy as an update.
 * ETMY's shadow sensors look bad. Unknown noise below 3 Hz, which is higher than the usual floor by factor of 10.

- ABSL
 * The frequency lock was down.
 * The laser power into the RFPD had been too big, so it was reduced

- OAF
 * Seismometers were connected to the AA-board on 1X6
 * Most of the channels were acquired to the ADC, but some were not.

- Mode Cleaner
 * Gain of quadrants were checked.
 * Due to the SUS model update, the MC locking trigger hasn't worked correctly. This was fixed by changing ioo.db file

- Misc.
 * Virtual box was installed on Rossa. Altium is now available on Rossa.

  5085   Mon Aug 1 22:30:59 2011 kiwamuSummaryGeneralWeekly report

Summary of the week ending July 31st.  Number of elog entries = 53


- SUS
 + ETMY-LR sensor looked strange. Something wrong.
 + Responses from the DC alignment bias to the shadow sensors and the oplevs were checked.
   --> ETMY shows the response with the opposite sign. Wired.
 + ETMY shadow sensors were examined in terms of the spectra.
   --> WF, AA and ADC noise looks reasonably low and not high enough to explain the low frequency noise.
 + Adjusted all the OSEM gains

- LSC
 + MICH noise budget is ongoing. WF filter needs to be greater than 21 dB to have dark noise of the PD greater than ADC noise
 + The arms became lockable

- CDS
 + modified and re-ran activateDQ.py.
 + c1iscex crashed for unknown reasons and we physically rebooted it.

- ALS (Fiber experiments)
 + PMC trans is sampled for the fiber beat-note measurement on the PSL table.
 + The beat-note signal between PSL and X end laser were obtained.
 + Some optics in the ETMY table were rearragend to have the Y green light aligned.

- ACS / ASS
 + incident beam axis has changed a lot.
 + X arm and Y arm ASS were reactivated.
  ---> The sign of some of the control gains had been wrong.
 + The incident beam axis and X/Y arm were re-aligned

- IOO/MCWFS
 + Some medm screens fixed.
 + Adjustment of the demodulation phase on each quadrant on WFS1 and WFS2 are done.
 + The sensing matrix (from optics to WFS sensors) were measured.

- OAF
 + c1pem was modified
 + plugged a seismometers to ADC through an AA board.
   --> channels are coming to the digital land
 
- Preparation for the invac work
 + 7 pieces of beam traps are available
 + Tolerance of the arm length is estimated to be +/- 2 cm.


- PSL/RefCav
 + ABSL is injected into the reference cavity. some flashing happened but no locking.
 + eddited the psl.db file to set EGUF and EGUL
 + turned RefCav heater and servo back on

  4854   Wed Jun 22 12:29:57 2011 IshwitaSummaryAdaptive FilteringWeekly summary

I started on the 16th with a very intense lab tour & was fed with a large amount of data (I can't guarantee that I remember everything....)

Then... did some (not much) reading on filters since I'm dealing with seismic noise cancellation this summer with Jenne at the 40m lab.

I'll be using the Streckeisen STS-2 seismometers & I need to use the anti aliasing filter board that has the 4 pin lemo connectors with the seismometers & its boxes that require BNC connectors. I spent most of the time trying to solder the wires properly into the connectors. I was very slow in this as this is the first time I'm soldering anything.... & till now I've soldered 59 wires in the BNC connectors....

 

 

  4997   Wed Jul 20 10:10:19 2011 SonaliUpdateGreen LockingWeekly summary

 I finished wih the set-up at the ETMY table. Instead of the neutral Density Filter , I put in a mirror(Y1-1037-45S)  which is reflective for IR , so that only 1% of the light is incident on the fibre  as per Rana's suggestion.

Now, the power incident on the fibre is measured to be 6 mW and the power measured out of the fibre is 2.76 mW after the necessary alignments.

On the PSL able, I have routed the beam that is coming out of the back of the PMC(instead of the dumped light from the oven to prevent any light from reflecting back into the laser), to the area where I am putting the set-up for the superposition of the PSL and the ETMX and ETMY beams.

Today I will proceed with the layout.

  4999   Wed Jul 20 11:42:47 2011 Ishwita, ManuelUpdate Weekly summary
  • We gave a white-board presentation on derivation of formula for optimum Wiener filter coefficients and wrote a latex document for the same. relevant elog entry
  • We enjoyed drilling the cover of the AA board and fixing it.
  • The AA board was fixed on rack 1X7 with Jenne's help. relevant elog entry
  • We tried writing a simulation for the transfer function of the stacks in Matlab. Once we get some satisfying results, we will post it on the elog.
  • We started reading the book 'Digital Signal Processing - Alan V. Oppenheim / Ronald W. Schafer' and are still reading it. We also tried watching lecture videos on z-transform...
  5045   Wed Jul 27 12:31:47 2011 Manuel, IshwitaSummaryPEMWeekly summary

We kept reading about digital filtering

We tested the seismometer last friday

Jan came and tested again the seismometer last monday

We wrote a simulation of the stacks transfer functions, and of the distance between the mirrors.

 

  5106   Wed Aug 3 12:24:08 2011 Manuel, IshwitaUpdateWienerFilteringWeekly summary

Last Friday (Jul 29) we reinstalled the blue breakout box, and changed the names of the C1:PEM channels. Elog Reference

We continued the work on the simulation ad applied wiener filter on the simulated ground motion, but the result is unsatisfactory, yet. We will post reasonable results soon.

We did wiener filtering for the first time on real data from the Xarm while it was locked. Elog Reference

  5170   Wed Aug 10 12:33:34 2011 Manuel, IshwitaSummaryPEMWeekly summary

We got the results of the wiener filtering simulations (Elog Entry)

We got the power spectra and coherence of the seismic noise measurements from GURALPs and STS seismometers (Elog Entry)

We tried to whiten the target and the input signal for the computation of the wiener filter for the real data, but the results are unsatisfactory. We should not care about high frequencies in wiener filter computation so we will just filter them off in the filter output with a low pass filter.

We just found the right gain for the system seismometer-AAboard-ADC (Elog Entry)

  7118   Wed Aug 8 11:47:52 2012 YaakovSummarySTACISWeekly summary

As Rana pointed out (http://nodus.ligo.caltech.edu:8080/40m/7112), the geophone/accelerometer noise lines from my last eLog (http://nodus.ligo.caltech.edu:8080/40m/7109) were dominated by ADC noise. I checked this today by terminating the ADC channels with 50 Ohm terminators and measuring the noise. The ADC noise line is included on the plot below, and it is clearly dominating the sensor noise data.

budget_with_adc.pngbudget_with_adc.fig

I set the accelerometer gain to 100, and will hook up the geophones to the SR560 pre-amp today- this should put both signals above the ADC noise, and I can calculate the sensor noises without the ADC noise being significant.

I have also begun to make some progress in understanding the pre-amp circuitry, and I will post a schematic when I've sketched it all.

Another issue that seems increasingly relevant to me is the power supply to the high voltage amplifier. It appears to go into the high voltage board from the power supply, then into the geophone pre-amp, then back into the high voltage board (see block diagram below). I tested this by inputting a signal after the pre-amp, with the geophones disconnected- the signal only drives the PZT if the pre-amp is plugged in, so the power that returns from the pre-amp must be powering some chips on the high voltage amplifier.

 

Power flow through the STACIS :

power_diagram.png

This is somewhat inconvenient, because it means if I want to provide external feedback (with accelerometers, for example) or actuation (such as feedforward), which I want to input after the geophone pre-amp, the pre-amp still needs to be plugged in for the high voltage amplifier to work and drive the PZTs.  I am cataloging all of the pins on the high voltage amplifier and pre-amp so I can figure out how to reroute the power and cut out the geophone pre-amp entirely if necessary. I'll include a pin diagram with the pre-amp circuit sketch.

  720   Wed Jul 23 10:47:05 2008 SharonUpdate Weekly update
This week I spent some time with Alex who updated the adaptive code to save the filter's coeffs all the time, stop when I open the loop, and reload the latest coeffs. when I start it again.
The point was to minimize the adaptation rate. Unfortunately, seems it is making some filters go wild, so it is not in use yet.
After taking some more measurements with the adaptive filter running, I have noticed a new peak in the signal around 22-23 Hz. My first assumption was that this is caused due to internal resonance of MC1 (which is driven when the adaptive code is running, and not when it's not). Therefore, I drove MC1 without the adaptive filter looking for the same peak... which wasn't there.
This sent me back to the adaptive code... Seems there is a matrix in the simulink file of the adaptive filter which doesn't have an MEDM screen. I am now working on making this screen. Once I am done with that, and make sure there is correlation between simulink and MEDM, I'll keep on chasing the peak in the code.
  765   Wed Jul 30 12:36:19 2008 SharonUpdate Weekly update
This week included many computer's issues. I tested Alex's new C code (the one that saves the FIR coefficients and restores them when you start running the code again). Seems there is an improvement in the adaptation time, but not a significant one (more details on the coming report). I had to recompile simulink and the FB whenever I wanted to find a solution for taking the record of those coefficients. This is so I could simulate the adaptive filter with a regular IIR filter and compare the two.
After Rob tried to help and it seems to be an impossible to a huge hassle mission, we thought of a different method to do this. I re-compiled the old simulink file and restored the .ini file and all should be back in place. Instead of finding the FIR coefficients, I am going to use one noise source in the adaptive filter, stop the adaptation (by setting mu and tau to 0), and put excitation instead of the noise signal. The transfer function I will get between the exc. and MC1_IN1 is the filter I am looking for.

Also seems that whenever I get the MC unstable, and the adaptive code stops itself, it doesn't come back. Setting the reset flag to a different number (anything other than 0) and pressing the reset button will get it working again, but the CPU will always flip and the ASS computer needed a restart. Still haven't found a problem in the C code, but that's the plan. Moreover, I want to change Alex's code, so that instead of starting from zero like in Matt's code, or starting from the old coefficients like in Alex's, it is going to calculate a Wiener Filter as the first set of coefficients. This will hopefully reduce the adaptation time.

I have also been working on my progress report, and stood in line for the MC... Still standing...
  3146   Wed Jun 30 12:20:49 2010 RazibUpdatePhase CameraWeekly update

This week I have completed following tasks:

1. Worked out the analytical expressions for the amount of power of the DC and oscillatory part going into the camera.

2. Realigned the He-Ne PhaseCam setup as we had to replace the first steering mirror after the laser with a silvered mirror ( one without a dielectric coating for 1064 nm).

3. Gone through the code written by a previous surfer (Zach Cummings).

4. Read the paper 'Real-time phase-front detector for heterodyne interferometers'- F. Cervantes et. el. where they talk about constructing a phase detector for LISA pathfinder mission. One interesting fact I found was that, they used InGaAs chip for their CCD Cam which has a amazing QE of 80% @ 1064 nm. Unfortunately, the one we are using (Micro MT9V022 CMOS) has only ~5% QE for 1064 nm and 50% for 633 nm. One top of it MT9V022 has a built-in infra-red filter infront of it to make it more insenstive to 1064. In such limitations, we may have to find a work-around for this issue. Any idea?

5. Read about the EOM and AOM and their vibrating (!) way to add on and alter the incident light on them. (Source: Intro to Optical Electronics-Yariv)

 

One task that we couldn't accomplish even though I planned on doing is:

1. Move,if possible, to the Nd:YAG setup.

 

Task for this week:

1. Produce breathtaking calibration of the camera at He-Ne setup.

2. Read 'Fringe Analysis'-Y.Surrel and 'Phase Lock Technique'-Gardner.

3. Modify the phasecam code.

4. Produce an alternate triggerbox using diodes instead of Op-Amp as op-amp is suspected to fail at some point driving the camera due to impedance mismatch.

5. Answer Koji's question at Aidan's ELOG .

  3167   Wed Jul 7 12:17:36 2010 RazibUpdatePhase CameraWeekly update

I have completed the following tasks:

1. Find a simplified calibration of the exposure time for the current He-Ne setup. Basically, I triggered the camera to take 20 snapshots with a 20 Hz driving signal at different exposure time beginning from 100 us (microsecond) upto 4000 us with an increment of 200 us.

    Result: The current power allows the camera to have an exposure time of ~500 us before the DC level begans to saturate.

2. Aidan and I did some alignment and connected the AOM and corrected the driving frequency of its PZT to 40 Mhz(which apparently was disconnected which in turn gets the credit of NO beat signal for me until Tuesday 07/06/2010 5:30 PST) .

    Result: I got the beat signal of 1 Hz and 5 Hz. Image follows (the colormap shows the power in arbitrary units).

3. Finished writing my Progress Report 1 .

DC_1Hz_beat_sig.jpgDC_5Hz_beat_sig.jpg

Attachment 1: DC_1Hz_beat_sig.jpg
DC_1Hz_beat_sig.jpg
  3187   Fri Jul 9 12:07:26 2010 RazibUpdatePhase CameraWeekly update

Here are some more details about the current phasecam setup. We are using a He-Ne laser setup

phase_cam_setup_09_08_10.jpg

A crude snap shot of the setup....

mod_setup_(copy)_annotated.jpg

 

We sent light through SM2 (Steering Mirror 2)  to BS1(Beam-Splitter 1) where the laser light is split into two parts, one going to the AOM and the other to the EOM. The EOM adds 40 MHz sidebands to the incoming carrier light after SM3, and the AOM shifts the frequency of the incident light on it to 40.000 005 MHz. The purpose for doing this juggling is to intentionally create a beat signal off the reference beam from the AOM with the sidebands added at the EOM. Note that, we are driving the AOM at 7dBm and the EOM at 13 dBm with 0 (nil) modulation. The two lights are combined at the BS2 and sent off through SM5 to the camera. The CMOS of the camera contains silicon based Micro MT9V022 chip which has a quantum efficiency of 50% at 633 nm. Thus we expected a fairly good response to this He-Ne setup from the camera. 

Using a trigger circuit, we triggered the camera at 20 Hz by sending a 20Hz sinusoidal signal to it. The trigger circuit converts this to a positive square waves. Then I roughly figured out the optimum exposure time for the camera before the DC levels saturates it by writing a code for taking a series of 25 images at different exposure time. I found that 500µs seems to be a reasonable exposure time. So, using this data, I took 20 consecutive images and sent them through a short Fourier Transform segment using Matlab to see the beat signal. Note that the DC component from these processing of the images have some fringe pattern which is due to the ND 2.5 filter that we were using to reduce the light power incident on the camera. The FT method also gave us the presence of the beat signal at the corresponding bin of the FT (for example: for 5Hz beat signal, I got the DC at bin 1 of the FT and 5Hz component at bin 6 as expected). Then I changed the AOM driving frequency to 40.000 001 MHz in order to see a 1 Hz beat signal. The results for both is in my previous post. 

Quote:

I have completed the following tasks:

1. Find a simplified calibration of the exposure time for the current He-Ne setup. Basically, I triggered the camera to take 20 snapshots with a 20 Hz driving signal at different exposure time beginning from 100 us (microsecond) upto 4000 us with an increment of 200 us.

    Result: The current power allows the camera to have an exposure time of ~500 us before the DC level begans to saturate.

2. Aidan and I did some alignment and connected the AOM and corrected the driving frequency of its PZT to 40 Mhz(which apparently was disconnected which in turn gets the credit of NO beat signal for me until Tuesday 07/06/2010 5:30 PST) .

    Result: I got the beat signal of 1 Hz and 5 Hz. Image follows (the colormap shows the power in arbitrary units).

3. Finished writing my Progress Report 1 .

DC_1Hz_beat_sig.jpgDC_5Hz_beat_sig.jpg

 

  3217   Wed Jul 14 12:12:03 2010 RazibSummaryPhase CameraWeekly update

This week I was mainly interested in investigating the noise source at the phase camera. So having this issue in mind, my activities are the following:

1. I worked on producing multiple beat signal (1Hz and 5Hz). Elog entry.

2. I altered the setup so that instead of triggering the camera from the signal generator, we are now triggering it from the beat signal from the reference beam and sideband.

3. I made the nice little aluminium table for all the amplifiers, mixer and splitters to sit at one place instead of floating around.

4. I talked with Aidan and Joe and verified my calculation and extended it to further investigation of the noise source in the setup.

 

Plan for the upcoming week:

1. Measure and calibrate the camera w.r.t the power incident on it.

2. Investigate the noise source.

  3258   Wed Jul 21 12:20:58 2010 RazibUpdatePhase CameraWeekly update

This past week I have worked on the following:

1. Setting up the infrastructure to do noise analysis: We added a temporary channel on the DAQ to connect to the PD 55 which we are using to take the power measurement. Before that, I connected the PD55 to an oscilloscope and recorded the power.

    phase_cam_setup_21_07_2010.jpg

The power at PD55 as measured using the oscilloscope = 600 µV.

Then I tried to calibrate the channel by sending up a signal from the function generator and measuring up the offset.. However, the channels seems noisy enough, especially due to electronics noise as suggested by the measurements and FFT calculation.

2. I worked on trying to sync the data acquisition of the PD and the CAM. After sometime spent on fiddling with the software method such as taking images at stamped time and then lining them up with the daq timestamps, I found a hardware method as suggested by Aidan. It was putting up a shutter (Uniblitz shutter and driver VMMD1) in the setup. I synced the shutter with the camera for which I had to tear apart the previously made trigger box and add a sync output from the camera (took a while as I also had to make a new cable).

3. I worked (still working) on making a differential amplifier to blow up the signal from the PD.

 

 

 

  6988   Wed Jul 18 13:53:34 2012 YaakovUpdateSTACISWeekly update

I have been working on substituting the internal geophones in the STACIS with accelerometers, and this week specifically I have been trying to modify the accelerometer signal so the STACIS PZTs respond properly.

The major problem was that the high signal amplitude caused the STACIS to oscillate uncontrollably, so I lowered all of the pots (for the z direction) and placed several BNC attenuators before the accelerometer signal enters the first amplifier board. The accelerometers now successfully provide feedback without making the STACIS unstable, as shown by this transfer function (the higher and flatter line is open loop, the lower is closed loop with accelerometers providing feedback):

really_accelFeed.GIF

The next step is to optimize the accelerometer feedback so it provides good isolation from 0.1 to 3 Hz, a span that the geophones introduced a lot of noise into. The accelerometers definitely don't introduce as much noise in that region, but don't seem to be doing much isolation either. I will also make some more quantitative plots of the platform motion (using the calibration value for the Wilcoxon accelerometers in the velocity setting with a gain of 1).

Some random discoveries I made this week which are relevant for STACIS testing:

1) Placing weight on the STACIS platform improves stability, but NOT if several blocks are placed on top of each other (they rub against each other, causing lots of vibrations).

2) The accelerometer that is providing feedback must be VERY securely fastened to the STACIS platform; even with three clamps there was extra motion that caused instability. Luckily, there's a convenient steel flange Steve showed me which has a hole that perfectly accommodates the accelerometer and doubles as a weight for the platform. Here is said flange, clamped to the STACIS platform with the accelerometer sitting in the center:

flange.JPG

 3) Using the shaker next to the STACIS (all on one platform) improves coherence between the base and platform accelerometers above around 10 Hz, but does nothing lower than that, which unfortunately is the region I'm most concerned with.

  7027   Wed Jul 25 12:00:21 2012 YaakovUpdateSTACISWeekly update

The past few days I've been working on making a noise budget for the STACIS that incorporates all the different noises that might be contributing.

The noises I am concentrating on are accelerometer noise, geophone noise, electrical noise, and ground noise. Noise from the PZT stacks themselves should be tiny according to various PZT spec sheets, but I haven't actually found a value for it (they all just say it's negligible), so I'll keep it in mind as a potential contributor.

Here's how I am determining accelerometer noise: I take two vertical accelerometers side by side, sitting on a granite block and covered in a foam box, and take the time series of both. Then I take the difference of the time series and calculate the PSD of that, which with the calibration factor of the accelerometers (the V/m/s sensitivity) I am able to find the noise in m/s/rtHz. The noise agreed with the accelerometer specs I found at low frequencies but was higher than expected at high frequencies, so I'm still investigating. If I can't find an obvious problem with my measurements I'll try the three-corner hat method (as per Jenne's recommendation), which would allow me to determine the noises of the independent accelereometers.

I tried a similar method for the geophone noise, but the value I came up with was actually higher than the accelerometer noise, which seems very fishy. I realized that the geophones were still connected to the STACIS circuitry when I took the measurements ,which was probably part of the problem. So this morning I disconnected the STACIS entirely and am looking at just the geophone signals which should give a more accurate noise estimate.

Once I have all the noises characterized, the next step is seeing how those noises affect the closed loop performance of the STACIS. I've been working on a block model that incorporates the different noises and transfer functions involved, and when I have the noises characterized I can test a prediction about how a certain noise affects the platform motion.

 

  7251   Wed Aug 22 18:58:12 2012 JenneUpdatePEMWeird BLRMS increase

It seems as though there is something funny going on around ~1.5 Hz, starting a little over an hour ago.

We see it in the BLRMS channels, the raw seismometer time series, as well as in various suspensions and LSC control signals.  It's also pretty easy to see on the camera views of all the spots (MC, arms, transmissions....AS is a little harder to tell since it's flashing, but it's there too).

The plots I'm attaching are only for ~10min after the jump happened, but there has been no change in the BLRMS since it started.  Usually, we'd see an earthquake in all the channels, and even big ones ring down after a little while.  This is concentrated at a pretty narrow frequency (some of Den's plots for later have this peak), and it's not ringing down, so it's not clear what is going on.

Here is a whole pile of plots.  Recall that the T-240 is plugged into the "STS_3" channels, and we don't have BLRMS for it, so you can look at the time series, but not any frequency specific stuff.

Attachment 1: All_seis_time_series.png
All_seis_time_series.png
Attachment 2: Gur1X.png
Gur1X.png
Attachment 3: Gur1Y.png
Gur1Y.png
Attachment 4: Gur1Z.png
Gur1Z.png
Attachment 5: Gur2X.png
Gur2X.png
Attachment 6: Gur2Y.png
Gur2Y.png
Attachment 7: Gur2Z.png
Gur2Z.png
Attachment 8: STS1X.png
STS1X.png
Attachment 9: STS1Y.png
STS1Y.png
Attachment 10: STS1Z.png
STS1Z.png
  7253   Thu Aug 23 00:18:54 2012 JenneUpdatePEMWeird BLRMS increase
While I was gone for dinner break, the BLRMS went back to normal. Then, almost 2 hours later, another peak appeared, this time closer to 1Hz. Den noticed that it was hard to maintain any lock, since the optics were ringing up so much.

The MC was moving pretty significantly, and just to check, I turned off the WFS for a moment. The MC transmitted power was fluctuating by almost 50% until I turned the WFS back on.

Attached is a spectrum of the BS OSEM sensors. The higher frequency peak around 1.65Hz is from the time I posted the time series about earlier. The lower frequency peak around 1.15Hz is from the second interval of noise.

Now, the noise is gone, and things are back to normal (for now....)
Attachment 1: BS_OSEMsensors_higherFreqPeakIsOlder_LowerFreqPeakIsMoreRecent.pdf
BS_OSEMsensors_higherFreqPeakIsOlder_LowerFreqPeakIsMoreRecent.pdf
  8598   Fri May 17 18:58:58 2013 Jamie, KojiSummaryCDSWeird DAC bit flipping at half integer output values

While looking at the DAC anti-imaging filters, Koji noticed an odd feature of the DAC output:

sweep.pdf

What you see here is 16kHz double data from a model right before the DAC part ('C1:SUS-PRM_ULCOIL_OUT', blue), and the full 64kHz int data sent to the physical DAC as reported by the IOP ('C1:X02-MDAC0_TP_CH0', green).  The balls are the actual sample values (as expected there are four green balls for every blue).  The output data is being ramped continuously between 0 and 1.

As the output data crosses the half-count level, the integer DAC output oscillates continuously at every 64kHz sample between the bounding integer values (in this case 0 and 1).

Here's the data as we hold the output continuously at the half-count level; the integer DAC output just oscillates continuously:

const.pdf

After some probing I found that the oscillation happens between [-0.003 +0.004] of the half-count level.

The result of this is a fairly strong 32 kHz line in the DAC analog output.

We looked in the controller.c and couldn't identify anything that would be doing this.  This is the output procedure as I can see it (controller.c lines): 

  1. The double from the model is passed to the IOP
  2. The IOP applies a sample-and-hold or zero-pad if the model is running at a slower speed than the IOP (1799)
  3. The data is then anti-image filtered (1801)
  4. A half-integer is added/subtracted before casting such that the cast is a round instead of a floor (1817)
  5. The data double is cast to an int (1819)
  6. The data is written to the DAC (1873)

There's nothing there that would indicate this sort of bit flipping.

  8599   Fri May 17 19:56:52 2013 KojiSummaryCDSWeird DAC bit flipping at half integer output values

Let me make a complimentary comment on this effect.

Because of this oscillation feature, we have a 32kHz peak in the DAC spectrum rather than a 64kHz peak.

For advanced LIGO, the universal AI (D070081) was made to have 3rd-order 10kHz LPF with 64kHz notch.
If we have a higher peak at 32kHz (where the rejection is not enough) than at 64kHz, the filter does not provide
enough filtering of the DAC artifacts.

For the 40m, the original filter had the cut off of 7kHz as the sampling rate was 16kHz.
If we want to extend the frequency range by 4times, the correspoding cut off should be 28kHz.
The rejection is again not enough at 32kHz.

If this peak is an avoidable feature by using simple sample&hold the peak freq is pushed up to
64kHz and we can use the AI filters as planned.

  8613   Wed May 22 11:09:33 2013 JamieSummaryCDSWeird DAC bit flipping at half integer output values

After querying CDS folks about this issue, I got some responses that indicated the problems was likely limit-cycle oscillations due to zero-padding of the data when upsampling.  Tobin ran some Matlab tests to confirm this issue.

Starting in RCG 2.5 there is a new "no_zero_pad=1" cdsParameters option turns zero padding OFF.  I tried enabling this option c1scy to see how the behavior changed.  Sure enough, the 32 kHz oscillations mostly went away.  There are no oscillations for outputs held at the half-count value, and the oscillations around the half-count transitions went away as well.

The only thing I could see is a bit of oscillation when converging on a constant half-count value that went away after a couple of milliseconds:

nopad.pdf

So we might consider adding the no_zero_pad=1 option to all of our coil driver outputs, which might eliminate the need to add notches at the Nyquist in the analog anti-image filters

  8614   Wed May 22 11:21:28 2013 KojiSummaryCDSWeird DAC bit flipping at half integer output values

Is this limit cycle caused by the residual of the digital AI filtering at the half sampling freq and that his the threshold?
Or is this some nonlinear effect? If this is a linear effect associated with the zero-padding, the absolute
value of the DC may affect the amplitude of the oscillation. (Or equivalently the range of the DC where we get this oscillation.)

Anyway, it seems that we should use no-zero-padding.

You pointed out the ringdown of the digital AI filter in the sample-hold case (i.e. no-zero-padding case).
How does it look like in the conventional zero-padding case?

  8615   Wed May 22 11:35:06 2013 JamieSummaryCDSWeird DAC bit flipping at half integer output values

Quote:

Is this limit cycle caused by the residual of the digital AI filtering at the half sampling freq and that his the threshold?
Or is this some nonlinear effect? If this is a linear effect associated with the zero-padding, the absolute
value of the DC may affect the amplitude of the oscillation. (Or equivalently the range of the DC where we get this oscillation.)

This is a good question.  We may be able to test if it's a linear effect if we have enough DAC range to get the oscillation to be more than a single sample.

Quote:

You pointed out the ringdown of the digital AI filter in the sample-hold case (i.e. no-zero-padding case).
How does it look like in the conventional zero-padding case?

 In the zero-pad case the oscillation just continues indefinitely at the half-count value, so it never dies out (at least as far as I can tell).

  8616   Wed May 22 15:08:37 2013 KojiSummaryCDSWeird DAC bit flipping at half integer output values

It seems that the effect is from the (linear) residual fluctuation of the digital AI filter for the zero-padded signal.

Namely, if we give the larger constant number, we get more oscillation.

Attachment 1: Screenshot.png
Screenshot.png
  11682   Fri Oct 9 16:43:50 2015 ericqUpdateIOOWeird IMC behavior

A few minutes ago, Gautam and I were poking around the IOO rack, looking at where he should power his frequency divider box, and what ADC innputs to use. 

Looking at the mode cleaner signals, it looks like we may have jostled something in a good way. Weird. 

  16113   Mon May 3 18:59:58 2021 AnchalSummaryGeneralWeird gas leakagr kind of noise in 40m control room

For past few days, a weird sound of decaying gas leakage comes in the 40m control room from the south west corner of ceiling. Attached is an audio capture. This comes about every 10 min or so. 

Attachment 1: 40mNoiseFinal.mp3
  16115   Mon May 3 23:28:56 2021 KojiSummaryGeneralWeird gas leakagr kind of noise in 40m control room

I also noticed some sound in the control room. (didn't open the MP3 yet)

I'm afraid that the hard disk in the control room iMac is dying.

 

  13207   Mon Aug 14 20:12:09 2017 Jamie, GautumUpdateCDSWeird problem with GPS receiver

Today we saw a weird issue with the GPS receiver (EndRun Technologies Tempus LX).  GPS timing on fb1 (which is handled via IRIG-B connection to the receiver with a spectracom card) was off by +18 seconds.  We tried resetting the GPS receiver and it still came up with +18 second offset.  To be clear, the GPS receiver unit itself was showing a time on it's front panel that looked close enough to 24-hour UTC, but was off by +18s.  The time also said "GPS" vertically to the right of the time.

We started exploring the settings on the GPS receiver and found this menu item:

Clock -> "Time Mode" -> "UTC"/"GPS"/"Local"

The setting when we found it was "GPS", which seems logical enough.  However, when we switched it to "UTC" the time as shown on the front panel was correct, now with "UTC" vertically to the right of the time, and fb1 was then showing the correct GPS time.

From the manual:

Time Mode
Time mode defines the time format used for the front-panel time display and, if installed, the optional
time code or Serial Time output. The time mode does not affect the NTP output, which is always
UTC. Possible values for the time mode are GPS, UTC, and local time. GPS time is derived from
the GPS satellite system. UTC is GPS time minus the current leap second correction. Local time is
UTC plus local offset and Daylight Savings Time. The local offset and daylight savings time displays
are described below.

The fact that moving to "UTC" fixed the problem, even though that is supposed to remove the leap second correction, might indicate that there's another bug in the symmetricom driver...

  10945   Tue Jan 27 17:58:21 2015 JenneConfigurationTreasureWelcome, Donatella!

Welcome to your new abode, Donatella!

Attachment 1: IMG_1806.JPG
IMG_1806.JPG
  5585   Fri Sep 30 15:22:17 2011 KatrinUpdateGreen LockingWhat happened on green YARM?

 

This is a kind of summary of what I have worked on this week.

After all the changes made last week, I could not manage to lock the green light to the cavity, but the PDH error signal looks nicer.....at least something.

 

Alignment of the light to the cavity:

  • DC level of green PD when light is non-resonating 100%
  • DC level of green PD when light resonates 75%
  • --> Not sure if this alignment is good enough
  • In comparision to last week the cavity mirrors seem to move more or my alignment is way worse than last week. The bright spot on ETMY could not be observed for more than let's say a second in the unlocked configuration.

 

Low-pass filter (LPF)

  • The PDH error signal was covered with oscillations of 3.3 kHz, 7.1 kHz and 35 kHz.
  • Measured cut-off frequency of the LPF used so far is 35 kHz
  • Designed and build a new LPF: second order, cut of frequency of 1.1 kHz (this is just the design value, haven't measured that so far)
  • With the new LPF the PDH error signal is free of the above mentioned oscillations.
  • Impedance should be checked

 

PDH error signal

  • Signal-to-noise ratio (SNR) could be improved to values between 7.8 and 11.1 (old SNR was 5 to 7)
  • Looks more like a PDH signal than with the old LPF (now just derivative of the carrier and the first order sidebands show up)
  • Amplitude of the first order sidebands are smaller than the zero order, but are still too high (about 80% of the first order), need to work on the proper value of the LO amplitude an the voltage averager

 

Phase shift between green PD signal and LO

  • Phase shift is about 1MHz
  • Tried to find a capacity that compensates the phase shift. This was not successful since the PD frequency changed every now and than by +/- 20 kHz
  15080   Fri Dec 6 00:02:48 2019 gautamUpdateLSCWhat is the correct way to set the 3f offsets?

Summary:

I made it to 0 CARM offset, PRMI locked a bunch of times today. However, I could not successfully engage the AO path.

Details:

Much of the procedure is scripted, here is the rough set of steps:

  • Transition control of the arms from IR signals to ALS signals.
  • DC couple the ITM oplev servos
  • Burt-restore the settings for PRMI locking with REFL165I-->PRCL, REFL165Q-->MICH, and then enable the MICH_B / PRCL_B locking servos.
  • Add some POPDC to the PRMI triggering (nominally only POP22_I) to let these loops be locked while POP22_I fluctuates wildly when we are near the CARM=0 point.
  • Zero the CARM offset.
  • Adjust the CARM_A/DARM_A offsets such that CARM_B/DARM_B are fluctuating symmetrically about 0.
  • CARM_B gain --> 1.0, to begin the RF blend.
  • Prepare to hand the DC control authority to ALS by turning off FM1 in the CARM filter bank, and turning ON an integrator in the CARM_B filter.

As I type this out, I realized that I was incorrectly setting offsets to maximize the arm powers by adjusting CARM/DARM offsets as opposed to CARM_A / DARM_A offsets. Tried another round of locking, but this time, I can't even turn the integrator on to get the arms to click into somewhat stable powers. 

One thing I noticed is that depending on the offsets I put into the 3f locking loops, the mean value of REFL11 and AS55 when the ALS CARM/DARM offsets are zeroed changes quite significantly. What is the correct condition to set these offsets? They are different when locking the PRC without arm cavities, and also seem to change continuously with CARM offset. I am wondering if I have too much offset in one of the vertex locking loops?

  15419   Fri Jun 19 17:06:50 2020 gautamUpdateLSCWhat should the short-term commissioning goals be?

Summary:

I want some input about what the short-term (next two weeks) commissioning goals should be.

Details:

Before the vacuum fracas, the locking was pretty robust. With some human servoing of the input beam, I could maintain locks for ~1 hour. My primary goals were:

  1. Transition the vertex length DoF control from 3f signals to 1f signals.
  2. Turn on some MICH-->DARM feedforward cancellation, because the noise between ~100 Hz and ~1kHz is dominated by this cross-coupling.

I didn't succeed in either so far.

  1. I find that there is poor separation of the length DoFs in the 1f sensors, which makes this transition hopeless.
    • Why should this be? I can't get any sensing matrix in Finesse to line up with what I measure in-lock.
    • One hypothesis I came up with (but haven't yet tested) is that the offsets from the 3f photodiodes are changing from time to time, which somehow changes the projection of the various DoFs onto the photodiode quadratures. 
    • The attached GIF shows the variation in the measured sensing matrix on two days - while the sensing of MICH/PRCL in the 3f photodiodes have hardly changed, they are significantly different in the 1f photodiodes. Note that the I and Q have changed for REFL11 and REFL55 between the two days because I changed the demod phase.
    • I also thought that maybe the CARM suppression isn't sufficient for REFL11 to be used as a PRCL sensor - but even after engaging a CM board SuperBoost, I was unable to realize the PRCL 3f-->1f transition, even though the CARM-->REFL11 coupling did get smaller in the measured sensing matrix (red line in the GIF). I don't think we can juice up the CARM gain much more without modifying the CM board boosts, see Attachment #1.
  2. I was able to measure the MICH CTRL --> DARM ERR transfer function with somewhat high coherence (~0.98).
    • I then used the infrastructure available in the LSC model to try and implement some cancellation, but didn't really see any effect.
    • Perhaps the TF needs to be measured with higher coherence.
    • It may also be that if I am able to successfully execute the 3f-->1f transition, the coupling gets smaller because the 1f sensing noise is lower?

I guess apart from this, we want to run the ALS scan to try and infer something about the absorption-induced thermal lens. I guess at this point, the costs outweigh the benefits in trying to bring in the SRC as well, since we will be changing the SRC config?

Attachment 1: CARM_superBoost.pdf
CARM_superBoost.pdf
ELOG V3.1.3-