40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 324 of 335  Not logged in ELOG logo
ID Date Author Type Category Subjectdown
  3806   Thu Oct 28 04:23:38 2010 ranaUpdateIOOA2L prep

To get the angle to length signal before the c1ioo processor gets going, we need a length signal. We can use either the error signal or the control signal.

I recommend using the control signal since its not puny. The 4-pin LEMO inputs to the OSEM ADC that Suresh has wired are differential so we can, in principle, use either the BNC output of the SERVO plug or the 2-pin LEMO output.

The analog whitening on the OSEM Whitening board should be engaged via the SUS MEDM screen so that we get a good SNR at the A2L dither frequencies.

If the ADC saturates, then we should use a pomona box RC low pass to cut everything off above 100 Hz.

Also, a comment about Yuta's elog: we estimated that the seismic motion was ~1e-7 - 1e-6 meters. The MC linewidth ought to be ~lambda/(2*Finesse) ~ 1e-9.

So, the MC servo as it was was not giving us enough gain (1/f above 50 Hz; UGF ~5-10 kHz) to get the error signal to stay in the linear PDH region. Kevin's filter gave us ~10x more gain at the seismic frequencies (1-3 Hz) of concern.

  13996   Thu Jun 21 14:23:22 2018 Udit KhandelwalSummaryGeneralA summary of the Tip-TIlt Mirror Holder design changes

Here’s a quick summary of the Tip-Tilt Design updates (all files are in the dropbox in [TipTiltSus>TT_New]) that I have been working on with Koji and Steve's help.

1. Plate on top to hold mirror in place:

The plate is 0.5 mm thick. I did a rough FEA with 10 N force on the point of pressure on it, and it bent easily.

2. Weighted screw rod at the bottom for tilting the mirror-holder:

I did a very simplified free body analysis to calculate the required length of the rod to achieve a +/- 15 mRad tilt, and got around 1.5 inches.

3. Set-screws on both side of wire clamp to adjust its horizontal position:

  • Front view (showing set screws on either side of the clamp to push it into the desired position, and the clamp in the middle with screws on top and bottom to fix its position):

  • Exploded view showing protrusion in clamp that sits in the mirror holder inset:

 

  • Exploded view showing inset in the mirror holder to slide protrusion in:

 

 

Comments:

1. Used the same screw size in most places to reduce complexity.

2. The mirror holder I have worked on is a little different from the actual piece I have on my table. Which one do you prefer (Koji)?

  13997   Thu Jun 21 14:57:59 2018 KojiSummaryGeneralA summary of the Tip-TIlt Mirror Holder design changes

> 2. Weighted screw rod at the bottom for tilting the mirror-holder:

Too long. The design of the holder should be check with the entire assembly.
We should be able to make it compact if we heavier weights.
How are these weights fixed on the shaft?
Also can we have options for smaller weights for the case we don't need such a range?
Note the mass of the weights.

> 3. Set-screws on both side of wire clamp to adjust its horizontal position:

How much is the range of the clamp motion limited by the slot for the side screws and the slot for the protrusion? Are they matched?
Can you show us the design of the slot made on the mirror holder?

>>

Where is the center of mass (CoM) for the entire mirror holder assy and how much is the height gap between the CoM and the wire release points. Can you do this with 3/8" and 1/2" fused silica mirrors?

  1409   Thu Mar 19 02:45:36 2009 YoichiConfigurationIOOA loose wire found for MC1
I found a loose connection of a wire in the cross-connect between an ADC and the MC1 coil driver's UL bias input.
I tightened it.
To see if this fixes the MC1 drift problem, I will do another round of MC1 drift measurement.
You can lock the MC if you need to use the IFO but please note it in the elog.

Thanks.
  1410   Thu Mar 19 10:45:43 2009 YoichiConfigurationIOOA loose wire found for MC1
I attached a 6-hour trend of the MC mirror OSEM signals with the MC unlocked.
The drift of the MC1 is within 20 counts (0.6um in terms of each OSEM).
This is comparable to the other MC mirrors.
  15073   Wed Dec 4 19:54:27 2019 gautamUpdateLSCA look to the past

Trawling through some past elogs, I saw that the ALS noise increase as a function of CARM offset reduction is not really a new thing (see e.g. this elog). In the past, when we were able to lock, when the CARM offset is reduced to zero, the arms would "buzz" through resonance. It just wasn't clear to me how much the buzzing was - in all the plots we presented, we were not looking at the fast 16k output, so it looked like the arm powers had stabilized. But today, looking at the frame data at 16k from back in 2016, it is clear to me that the arm transmission was in fact swinging all the way from 0 to some maximum. Once the IR signal (=REFL11) blending is turned on, we were able to stabilize the arm power somewhat. What this means is that we are in a comparable state as to when we were able to lock in the past (since I'm able to sit at 0 CARM offset with the PRMI locked almost indefinitely).

So, I think what I'll try for the next 3 days is to get this blending going, I think I couldn't enable the CM_slow path because when I was experimenting with the high bandwidth Y arm cavity locking, I had increased the whitening gain of this channel, but REFL11 has much more optical gain (=larger signal) than POY11, and so I'll start from 0dB whitening gain and see if I can turn the magic integrator on. Long term, we should try and compensate the optomechanical plant that changes as our CARM offset gets reduced, as this would further reduce the lock acquisition time and simplify the procedure (no need to fiddle with the integrator, offsets etc). A relevant thread from the past.

  59   Sat Nov 3 16:20:43 2007 waldmanSummaryOMCA good day's work

I followed up yesterday's test of the PZT with a whole mess of characterizations of the PZT control and finished the day by locking the OMC with a PZT dither lock and a 600 Hz loop. I haven't analyzed any of the data yet, so its not calibrated in physical units and etc. etc. etc. Since a lot of the sweeps below are of a "drive the PZT, look at the PDH signal" nature, a proper analysis will require taking out the loop and calibrating the signals, which alas, I haven't done. Nonetheless, I include all the plots because they are pretty. The files included below are:

  • DitherLock_sweep: Sweep of the IN2/IN1 for the dither lock error point showing 600 Hz UGF
  • HiResPZTDither_sweep: Sweep of the PZT dither input compared to the PDH error signal. I restarted the front end before the sweep was finished accounting for the blip.
  • HiResPZTDither_sweep2: Finish of the PZT dither sweep


More will be posted later.
  4376   Fri Mar 4 03:31:35 2011 kiwamuUpdateGreen LockingA first noise budget

I made a noise budget for the ALS noise measurement that I did a week ago (see #4352).

I am going to post some details about this plot later because I am now too sleepy.

noise_budget.png

  15562   Mon Sep 7 23:49:14 2020 gautamUpdateBHDA first look at RF44 scheme

Summary:

Over the last couple of days, I've been working towards getting the infrastructure ready to test out the scheme of sensing (and eventually, controlling) the homodyne phase using the so-called RF44 scheme. More details will be populated, just quick notes for now before I forget.

  • LO beam with RF sidebands needed to be re-coupled into collimator, it wasn't seated tightly and just touching the fiber completely destroyed the alignment.
  • HWP installed before said collimator - IMC wants s-polarized light whereas the IFO field is p-polarized.
  • After my work, the numbers were: ~1.47mW input to collimator, ~1.07mW out of collimator on AS table, ~1mW making it to the BHD board. All seem like reasonable numbers to me.
  • 44 MHz signal synthesis - for now, I use a Marconi (10 MHz synced to Rb clock), I think we could also use a mixer+SLP50 to mix 11 and 55 MHz signals (which are easily available at the LSC rack) to generate this. I looked at Wenzel quadruplers, the specs don't suggest a quadrupler will do much better.
  • CDS model was modified to accept the phase-tracker output as an error signal for the homodyne phase control servo. Compile and install went smooth but I opted against a model restart tonight, I'll do it tmrw.
  • Some trials were done with the Michelson locked to a dark fringe (as was done for the case of the DC LO field beating with the 55 MHz sideband). While the overall spectrum lines up fairly well with earlier trials, the signal looks somewhat more "discontinuous" in its traversal of I/Q space, and it never quite goes to 0. Some offset? What does this mean for locking? More investigations needed....
  15563   Tue Sep 8 01:31:43 2020 KojiUpdateBHDA first look at RF44 scheme

- Loose fiber coupler: Sorry about that. I could not detect something was loose there, although some of the locks were not tightened.

- S incident instead of P: Sorry about that too. I completely missed that the IMC takes S-pol.

  6414   Wed Mar 14 13:16:50 2012 kiwamuUpdateLSCA correction on Noise estimatino in the REFL33Q

A correction on the previous elog about the REFL33Q noise:

 Rana pointed out that the whitening filter's input referred noise should not be such high (I have estimated it to be at 54 nV/sqrtHz).
In fact the measurement was done in a condition where no laser is on the photo diode by closing the mechanical shutter at the PSL table.
Therefore the noise I called "whitening filter input referred noise" includes the voltage noise from the RFPD and it could have such a noise level.
So the noise curve drawn in the plot should be called "whitening filter + RFPD electronics noise".

Quote from #6407

A feasibility study of the REFL33Q as a MICH sensor was coarsely performed from the point view of the noise performance.

  • Whitening filter input referred noise
    • I assumed that it is flat with a level of 54 nV/sqrtHz based on a rough measurement by looking at the spectrum of the LSC input signals.
    • The contribution was estimated by applying some gain corrections from the conversion efficiency of the demod board, transimpedance gain, responsivity and the optical gain.
    • This noise is currently the limiting factor over a frequency range from DC to 1 kHz.

 

  1286   Mon Feb 9 17:09:51 2009 YoichiUpdateComputersA bunch of updates for the network GPIB stuff.
During the work on ISS, we noticed that netgpibdata.py is very unreliable for SR785.
The problem was caused by flakiness of the "DUMP" command of SR785, which dumps the data from the analyzer to the client.
So I decided to use other GPIB commands to download data from SR785. The new method is a bit slower but much more reliable.

I also rewrote netgpibdata.py and related modules using a new class "netGPIB".
This class is provided by netgpib.py module in the netgpibdata directory. If you use this class for your python program, all technical details and dirty tricks are hidden in the class methods. So you can concentrate on your job.
Since python can also be used interactively, you can use this class for a quick communication with an GPIB instrument.

Here is an example.
>ipython #start interactive python
>>import netgpib #Import the module
>>g=netgpib.netGPIB('teofila',10) #Create a netGPIB object. 'teofila' is the hostname of
#the GPIB-Ethernet converter. 10 is the GPIB address.
>>g.command('ACTD0') #Send a GPIB command "ACTD0". This is an SR785 command meaning "Change active display to 0".
>>ans=g.query('DFMT?') #If you expect a response from the instrument, use query command.
#For SR785, "DFMT?" will return the current display format (0 for single, 1 for dual).
>>g.close() #Close the connection when you are done.

Sometimes, SR785 gets stuck to a weird state and netgpibdata.py may not work properly. I wrote resetSR785.py command to reset it remotely.
Wait for 30sec after you issue this command before doing anything.

I wrote two utility commands to perform measurements with SR785 automatically.
TFSR785.py commands SR785 to perform a transfer function measurement.
SPSR785.py will execute spectrum measurements.
You can control various parameters (bandwidth, resolution, window, etc) with command-line options.
Run those commands with '-h' for help.
It is recommended to use those commands even when you are in front of the analyzer, because they save various measurement parameters (input coupling, units, average number, etc) into a parameter file along with the measured data. Those parameters are useful but recording them for each measurement by hand is a pain.
  15820   Thu Feb 18 20:24:48 2021 KojiSummaryElectronicsA bunch of electronics received

Todd provided us a bunch of electronics. I went to Downs to pick them up this afternoon and checked the contents in the box. Basically, the boxes are pretty comprehensive to produce the following chassis

  • 8 HAM-A coil driver chassis
  • 7 16bit Anti-Aliasing chassis
  • 4 18bit Anti-Imaging chassis
  • 5 16bit Anti-Imaging chassis

Some panels are missing (we cannibalized them for the WFS electronics). Otherwise, it seems that we will be able to assemble these chassis listed.
They have placed inside the lab as seen in the attached photo.


HAM-A COIL DRIVER (Req Qty 28+8)

- 8 Chassis
- 8 Front Panels
- 8 Rear Panels
- 8 HAM-A Driver PCBs
- 8 D1000217 DC Power board
- 8 D1000217 DC Power board

16bit AA (Req Qty 7)
- 7 CHASSIS
- 6 7 Front Panels (1 missing -> [Ed 2/22/2021] Asked Chub to order -> Received on 3/5/2021)
- 7 Rear Panels
- 28 AA/AI board S2001472-486, 499-511
- 7 D070100 ADC AA I/F
- 7 D1000217 DC Power board

18bit AI (Req Qty 4)
- 4 CHASSIS
- 4 Front Panels
- 4 Rear Panels
- 8 AA/AI board S2001463-67, 90-92
- 4 D1000551 18bit DAC AI I/F
- 4 D1000217 DC Power board
- bunch of excess components

16bit AI (Req Qty 5)
- 5 CHASSIS
- 4 5 Front Panels (D1101522) (1 missing -> [Ed 2/22/2021] Asked Chub to order -> Received on 3/5/2021)
- 3 5 Rear Panels (D0902784) (2 missing -> [Ed 2/22/2021] Asked Chub to order -> Received on 3/5/2021)
- 10 AA/AI board S2001468-71, 93-98
- 5 D1000217 DC Power board
- 5 D070101 DAC AI I/F

Internal Wiring Kit

[Ed 2/22/2021]
Asked Chub to order:
- Qty 12 1U Hamilton Chassis
- Qty 5 x Front/Rear Panels/Internal PCBs for D1002593 BIO I/F (The parts and connectors to be ordered separately)

  -> Front/Rear Panels received (3/5/2021)
  -> PCBs (unpopulated) received (3/5/2021)
  -> Components ordered by KA (3/7/2021)

  15828   Sat Feb 20 10:01:48 2021 gautamSummaryElectronicsA bunch of electronics received

Will we also be receiving the additional 34 Satellite Amplifier PCBs?

  15830   Sat Feb 20 16:46:17 2021 KojiSummaryElectronicsA bunch of electronics received

We received currently available sets. We are supposed to receive more coil drivers and sat amps, etc. But they are not ready yet.

 

  15866   Fri Mar 5 00:53:09 2021 KojiSummaryElectronicsA bunch of electronics received

Received additional front/rear panels. Updated the original entry and Wiki [Link]

 

  15868   Fri Mar 5 15:03:28 2021 gautamSummaryElectronicsA bunch of electronics received

The PCBs for the D1002593 BIO I/F (5pcs ea of D1001050 and D1001266) were received (from JLCPCB) today. idk what the status of the parts (digikey?) is.

Quote:

Received additional front/rear panels. Updated the original entry and Wiki [Link]

  15870   Fri Mar 5 15:32:53 2021 KojiSummaryElectronicsA bunch of electronics received

The parts will be ordered by Koji The components for the additional BIO I/F have been ordered.

  15981   Wed Mar 31 03:56:37 2021 KojiSummaryElectronicsA bunch of electronics received

We have received 9x 18bit DAC adapter boards (D1000654)

  10038   Fri Jun 13 19:09:44 2014 KojiUpdateIOOA blown fuse found on the euro card crate at 1X2 (IOO) rack.

[Rana Zach Koji]

We tracked down the MC locking issue to be associated with the power supply problem.
Replacing a fuse which had incomplete connection with the new one, the MC started locking.

We still have the MC autolocker not running correctly. This is solely a software problem.


We went down to the IOO electronics rack to investigate the electronics there. After spending
some time to poking around the test points of the MC servo board, we noticed that the -24V
power indicator on the MC demodulator module was not lit. In fact, Steve mentioned on Wednesday
that the -24V Sorensen supply had lower current than nominal. This actually was a good catch
but should have been written in the ELOG!!!

We traced the power supply wires for the crate and found one of the three -24V supply has no
voltage on it. Inspection of the corresponding fuse revealed that it had a peculiar failure mode.
The blown LED was not lit. The connection was not reliable and the -24V power supply was flickering.

We then replaced the fuse.This simply solved all of the issues on the MC servo board. The electronics
should be throughly inspected if it still has the nominal performance or not, as the boards were exposed
to the single supply more than a week. But we decided to try locking ability first of all.

Yes, we now can lock the MC as usual.

Now the newly revealed issue is MC autolocker. It was running on op340m but op340m does not want to run it now.
It should be closely investigated.

Also turning on WFS unlocks the MC. Currently the WFS outputs are turned off.
We need usual align MC / check spot position / adjust WFS QPD spots combo.

  4486   Mon Apr 4 18:58:44 2011 BryanConfigurationGreen LockingA beam of purest green

We now have green light at the Y end. 

The set-up (with careful instructions from Kiwamu) - setting up with 100mW of IR into the oven.

Input IR power = 100mW measured.

 

Output green power = 0.11mW

(after using 2 IR mirrors to dump IR light before the power meter so losing a bit of green there light too)

 

And it's pretty circular-looking too. Think there might be a bit more efficiency to be gained near the edges of the crystal with internal reflections and suchlike things but that gives us an UGLY looking beam.  Note - the polarisation is wrong for the crystal orientation so used a lambda/2 plate to get best green  power out.

 

Efficiency is therefore 0.11/100 = 0.0011 (0.11%) at 100mW input power.

 

Temperature of the oven seems to be around 35.5degC for optimal conversion.

Took a picture. Ta-dah! Green light, and lots more where that came from! Well... about 3x more IR available anyway.

 

P4040042.JPG

 

 

  3942   Wed Nov 17 23:45:20 2010 JenneUpdateSUSA bad day for suspensions

[Jenne, Suresh]

Today has been a downright miserable day in the world of suspension work. Thumbs down to that: 

Yesterday, we had glued 2 full sets of magnets to dumbbells.  Today, half of those broke.  I think I put too thin of a layer of glue on the magnets when gluing them to the dumbbells.  All magnet/dumbbell assemblies should pass the test of being picked up by the dumbbell while the magnet is stuck to the optical table or a razor blade.  6 of the 12 magnets failed this test. Suresh soaked the dumbbells that had been used in acetone, and scrubbed them, so we can reuse them when we reglue things tomorrow.  By some miracle, we have exactly one full set intact (for each set of 6, we need 4 of one direction and 2 of the other).  This was frustrating, but not yet a deal-breaker.  That part comes next....

I got ETMU05 nicely aligned in the magnet gluing fixture, and then was on my last check of whether the side magnets would be glued in the correct place when I realized that the fixture is all wrong for the ETMs.  This final check was added to the procedure after the drama with the ITMs of having the side magnets glued incorrectly as a result of the fixture being specific to the wedge angle of the optic.  Kiwamu and I had set the fixture to be just right for the ~1deg wedge corner station optics, but the ETMs have a 2.35deg wedge (according to the Coastline spec sheet, which is consistent with our measurements when placing the guiderod and standoffs).  Suresh and I need to reset the height of the optic in the fixture using more teflon sheets, but we don't have a whole lot of options ready in the cleanroom.  We're going to cut some more pieces and ask Bob to clean them tomorrow.  Since the way the fixture holds the teflon is a little hoaky, Suresh suggested just resting the optic on teflon pads, rather than screwing the teflon to the fixture, and then putting the optic on the pads.  We'll try Suresh's method tomorrow, and hopefully it will be pretty easy. 

At least the guiderods and standoffs were successfully glued to the optics....

Here's the updated Status Table.  I don't think we're going to be able to have an ETM ready for the chambers early next week, but we should still be able to have both ready for the Monday after Thanksgiving.  The spring plungers arrived today, and were given immediately to Bob and Daphen for cleaning.

StatusTable.png

  2364   Tue Dec 8 09:18:07 2009 JenneUpdateComputersA *great* way to start the day....

Opening of ETMY has been put on hold to deal with the computer situation.  Currently all front end computers are down.  The DAQ AWGs are flashing green, but everything else is red (fb40m is also green).  Anyhow, we'll deal with this, and open ETMY as soon as we can.

The computers take priority because we need them to tell us how the optics are doing while we're in the chambers, fitzing around.  We need to be sure we're not overly kicking up the suspensions. 

  7587   Mon Oct 22 09:10:07 2012 SteveUpdateVAC@750Torr

Quote:

Quote:

Quote:

 

 PSL shutter closed, manual block in place, HV turned off. P1 is at 200 Torr now.  Jenne is taking over here.

 Valves closed, 500 torr.  Steve will finish off Monday morning, then we'll take off doors and get to work.

 We are almost at atm.  P1 750 Torr,  We are slowly reaching equilibrium.

  1659   Sat Jun 6 01:44:53 2009 rob UpdateLocking?

Lock acquisition is proceeding smoothly for the most part, but there is a very consistent failure point near the end of the cm_step script.

Near the end of the procedure, while in RF common mode, the sensing for the MCL path of the common mode servo is transitioned from a REFL 166I signal which comes into the LSC whitening board from the demodulator, to another copy of the signal which has passed through the common mode board, and is coming out of the Length output of the common mode board.  We do this because the signal which comes through the CM board sees the switchable low-frequency boost filter, and so both paths of the CM servo (AO and MCL) can get that filter switched on at the same time.

The problem is occurring after this transition, which works reliably.  However, when the script tries to remove the final CARM offset, and bring the offset to zero, lock is abruptly lost.  DARM, CM, and the crossover all look stable, and no excess noise appears while looking at the DARM, CARM, MCF spectra.  But lock is always lost right about the same offset. 

Saturation somewhere?

  1660   Sun Jun 7 04:57:39 2009 YoichiUpdateLocking?

Quote:

Lock acquisition is proceeding smoothly for the most part, but there is a very consistent failure point near the end of the cm_step script.

Near the end of the procedure, while in RF common mode, the sensing for the MCL path of the common mode servo is transitioned from a REFL 166I signal which comes into the LSC whitening board from the demodulator, to another copy of the signal which has passed through the common mode board, and is coming out of the Length output of the common mode board.  We do this because the signal which comes through the CM board sees the switchable low-frequency boost filter, and so both paths of the CM servo (AO and MCL) can get that filter switched on at the same time.

The problem is occurring after this transition, which works reliably.  However, when the script tries to remove the final CARM offset, and bring the offset to zero, lock is abruptly lost.  DARM, CM, and the crossover all look stable, and no excess noise appears while looking at the DARM, CARM, MCF spectra.  But lock is always lost right about the same offset. 

Saturation somewhere?

 I've seen this before. At that time, the problem was gone spontaneously the next day.

You could stop just before the offset reaches zero and then try to slowly reduce the offset manually to see where is the threshold.

 

  1663   Tue Jun 9 23:25:24 2009 robUpdateLocking?

Quote:

Quote:

Lock acquisition is proceeding smoothly for the most part, but there is a very consistent failure point near the end of the cm_step script.

Near the end of the procedure, while in RF common mode, the sensing for the MCL path of the common mode servo is transitioned from a REFL 166I signal which comes into the LSC whitening board from the demodulator, to another copy of the signal which has passed through the common mode board, and is coming out of the Length output of the common mode board.  We do this because the signal which comes through the CM board sees the switchable low-frequency boost filter, and so both paths of the CM servo (AO and MCL) can get that filter switched on at the same time.

The problem is occurring after this transition, which works reliably.  However, when the script tries to remove the final CARM offset, and bring the offset to zero, lock is abruptly lost.  DARM, CM, and the crossover all look stable, and no excess noise appears while looking at the DARM, CARM, MCF spectra.  But lock is always lost right about the same offset. 

Saturation somewhere?

 I've seen this before. At that time, the problem was gone spontaneously the next day.

You could stop just before the offset reaches zero and then try to slowly reduce the offset manually to see where is the threshold.

 

 

Well, it hasn't gone away yet.  It happened Sat, Mon, and Tues afternoon, as well as Friday.  The threshold varies slightly, but is always around ~200-300 cnts.   I've tried reducing the offset with the signal coming from the CM board and the signal not going through the CM board, I've also tried jumping the signal to zero (rather than a gradual reduction). 

Tonight we'll measure the MC length and set the modulation frequencies, and maybe try some MZ tweaking to do RFAMMon minimization.    

  11685   Tue Oct 13 05:48:39 2015 ericqUpdateLSC:/

[ericq, Gautam]

Despite our best efforts, the grappa remains out of reach: the DRFPMI was not locked tonight. 

We spent a fair amount of time with the AUX X laser, as it was glitching madly again.

DRMI was finicky until I found some more reliable triggering settings; namely aquiring with AS110Q, but after that transitioning the trigger to the same POP22+POPDC combo as PRCL and MICH. With this in place, the DRMI lock seems really indefinite no matter what CARM seems to do; or at least, I always lost lock due to CARM shenanigans after this. 

The most frustrating part was the fact that I just couldn't cross over the AO path stably. It never "clicked" into high circulating power as it normally does (either in PRFPMI, or how it was last week). Various crossover filters and tweaks were attempted to no avail. Morning traffic starts soon, so we're calling it a night. 

  4237   Wed Feb 2 03:27:20 2011 KojiSummaryGreen Locking85MHz Freq divider

The freq divider was built and installed in the beat detection path.

Attachment 1: Circuit diagram

  • Input stage:  Wideband RF amp with DC block at the input and the output. The gain is 10dB typ.
  • 2nd stage: Ultra fast comparator AD9696. Note: AD9696 is an obsolete IC and there are only a few extra at Wilson house.
    The output is TTL/CMOS compatible.
  • 3rd stage: 14bit binary ripple counter (fmax~100MHz.)

Note: I have added 7805/7905 regulators to the circuit as I could not find -5V supply on the 1X1/2 racks.

Attachment 2: Packaging

  • The box is german made Eurocard size box from Techno-Isel Linear Motion http://www.techno-isel.com/lmc/Products/EnclosureProfiles11055.htm
    The box is excellent but I didn't like the fixing bolts as they are self-tapping type. I tapped the thread and used #6-32 screws.
     
  • The prototyping board is BPS's (BusBoard Prototype System http://www.busboard.us/)  SP3UT. The card size is 160mm x 100mm.
    The other side is a ground plane and the small holes on the board are through holes to the ground plane.
    This particular card was not easy to use.
     
  • The input is SMA. Unfortunately, it is not isolated. The output is an isolated BNC.
     
  • The supply voltage of +/-15V is given by the 3pin D-connector. The supply voltages have been obtained from the cross connect of 1X1.

Attachment 3: Input specification

  • The input frequency is 10MHz~85MHz. At lower frequency chattering of the comparator against the multiple zero crossing of the (relatively) slow sinusoidal waves.
  • The input amplitude. There are no apparent degradation of the freq jitter when the input power was larger than -30dBm.

 

  3803   Thu Oct 28 03:07:53 2010 kiwamuUpdateGreen Locking80MHz VCO for green PLL : a health check

 I did a health check for a 80MHz VCO box. 

I started taking care with the black VCO box, which has been sitting on the SP table and will be used for converting the green beat signal from frequency to voltage.

The circuit in the box basically consists of three parts: low pass filters (LPFs), a VCO and RF amplifiers.

Today I checked the LPF stage. It looks pretty healthy.

Tomorrow I will check the VCO part, especially I am curious about the VCO range.

 


 (soldering)

 Since somebody ( surf students ?) removed some resistors, the VCO was just freely running without being applied any voltage.

I put some resistors back on the circuit board by soldering them.

Now the resistors are placed in the same configuration as the original schematic (link to LIGO DCC) except for the wideband signal path, which has a differential input.

I left the wideband path disconnected from the VCO.

 

(transfer function measurement)

The LPF part in 'external mod' path contains two stages in series:

one is for cutting off demodulated signals above fc=80MHz and the other one is for PLL servo with pole=1Hz, zero=40Hz.

In order to activate this path I shorted 10th pin of the analog switch: MAX333A.

During the transfer function measurement I injected signals to 'external mod' input and took the output signal from a test point pin TP7.

The plot below shows a fitting result of the measured transfer function of the whole LPF stage. I used liso for the fitting.

The measured filter's shape agreed with the design. (though I haven't checked 80MHz cut off)

VCO_LPF_fit.png

  3820   Fri Oct 29 06:20:20 2010 kiwamuUpdateGreen Locking80MHz VCO for green PLL : VCO calibration

 I calibrated the VCO frequency as a function of the applied input voltage.

The range is approximately +/- 5 MHz, which is large enough to cover the arm's FSR of 3.75MHz.

calibration.png 

======== measured parameters ======

center frequency: 79.5 MHz

VCO range: 74MHz - 84MHz

coefficient : 1.22MHz/ V (+/- 2V range)

nominal RF power: -0.66 dBm

(Note: The measurement was done by using Giga-tronics hand-hold power meter.)

Quote from #3803

Tomorrow I will check the VCO part, especially I am curious about the VCO range.

  3898   Thu Nov 11 17:47:36 2010 kiwamuUpdateGreen Locking80MHz VCO : improve PLL hold-in range and put a boost

In order to enlarge the hold-in range I modified the control filter and increased the gain by factor of 25 in the PLL.

It successfully enlarged the range, however the lock was easily broken by a small frequency change.

So I put a low frequency boost (LFB) and it successfully engaged the PLL stiffer.

Now it can maintain the lock even when the frequency disturbance of about 1MHz/s is applied.

 


(enlargement of the hold-in range)

I modified the control filter by replacing some resistors in the circuit to increase the gain by factor of 25.

        - R18 390 [Ohm]  => 200 [Ohm]

    - R20 1000 [Ohm] => 5000 [Ohm]

    - R41 39 [Ohm] => 10 [Ohm]

 This replacement also changes the location of the pole and the zero

    - pole 1.5 [Hz] => 0.3 [Hz]

    - zero 40 [Hz] => 159 [Hz]

 Note that this replacement doesn't so much change the UGF which was about 20 kHz before.

It becomes able to track the input frequency range of +/- 5MHz if I slowly changes the frequency of the input signal. 

However the PLL is not so strong enough to track ~ 1 kHz / 0.1s frequency step.  

 

(make the PLL stiffer : a low frequency boost)

One of the solution to make the PLL stiffer is to put a boost filter in the loop.

I used another channel to more drive the VCO at low frequency. See the figure below.

 vco_pll.png

The 80MHz VCO box originally has two input channels, one of these inputs was usually disabled by MAX333A.

This time I activated both two input channels and put the input signal to each of them.

Before signals go to the box, one of the signal path is filtered by SR560. The filter has G=20000, pole=0.3Hz. So it gives a big low frequency boost.

VCO_lfb.png

Once the PLL was achieved without the boost, I increased the filter gain of SR560 to 20000 because locking with the boost is difficult as usual.

 

  3896   Thu Nov 11 13:54:05 2010 kiwamuUpdateGreen Locking80MHz VCO : about PLL hold-in range

The hold-in range of the PLL must be greater than +/- 4MHz in order to bring the arm cavity to its resonance. 

(Hold-in range is the range of frequencies over which the PLL can track the input signal.)

However as I mentioned in the past elog (see this entry), the PLL showed a small hold-in range of about +/- 1MHz which is insufficient.

In this entry I explain what is the limitation factor for the hold-in range and how to enlarge the range.

 


(Requirement for hold-in range )

 We have to track the frequency of the green beat signal and finally bring it to a certain frequency by controlling the cavity length of the arm.

For this purpose we must be able to track the beat signal at least over the frequency range of 2*FSR ~ +/- 4MHz.

Then we will be able to have more than two resonances, in which both the end green and the PSL green are able to resonate  to the arm at the same time. 

And if we have just two resonances in the range, either one of two resonances gives a resonance for both IR and green. At this phase we just bring it to that frequency while tracking it.

 

  Theoretically this requirement can be cleared by using our VCO because the VCO can drive the frequency up to approximately +/- 5MHz (see this entry)

 The figure below is an example of resonant condition of green and IR. The VCO range should contain at least one resonance for IR.

(In the plot L=38.4m is assumed)

 

 range_green.png

 

(an issue) 

However the measured hold-in range was about +/- 1MHz or less. This is obviously not large enough.

According to a textbook[1], this fact is easily understandable.

The hold-in range is actually limited by gains of all the components such as a phase detector's, a control filter's and a VCO's gain.

Finally it is going to be expressed by,

                         [hold-in range] = G_pd * G_filter * G_vco

PLL.png

 

 At the PD (Phase Detector which is a mixer in our case) the signal does not exceed G_pd [V] because it appears as G_pd * sin(phi).

When the input signal is at the edge of the hold-in range, the PD gives its maximum voltage of G_pd to maintain the lock.

Consequently the voltage G_pd [V] goes through to G_filter [V/V] and G_vco [Hz/V].

This chain results the maximum pushable frequency, that is, hold-in range given above equation.

In our case, the estimated hold-in range was 

                      [hold-in range] ~ 0.4 [V] * 3 [V/V] * 1 [MHz/V]

                          = 1.2 [MHz]

This number reasonably explains what I saw.

In order to enlarge the hold-in range, increase the gain by more than factor of 5. That's it.

* reference [1]  "Phase-Locked Loops 6th edition" Rolan E. Best

  3879   Mon Nov 8 10:48:58 2010 kiwamuUpdateGreen Locking80MHz VCO : PLL open loop looks good

I measured the open loop transfer function of the 80MHz VCO's PLL while locking it to Marconi.

 This measurement is for a health check and a characterization of the PLL

The transfer function looks good, it agrees with the designed filter shape.

 


(measurement setup) 

vco_pll.png

 The frequency of Marconi is set to 79.5MHz which is the center frequency of the VCO.

The signal from Marconi is mixed down with the VCO signal at a mixer ZLW-3SH.

Then the demodulated signal goes to a 80MHz LPF to cut off high frequency components.

And it goes through a control filter which has 1Hz pole and 40Hz zero (see this entry).

The 80MHz LPF, the controls filter, the VCO and the RF amplifier are all built in the box.

 

 In order to measure the open loop transfer function I inserted SR560 before the 80MHz LPF.

Using T-splitters the input and the output of SR560 are connected to a spectrum analyzer SR785.

 

(results)

 VCO_PLL.png

 Exciting the system using a source channel of SR785, I measured the open loop transfer function.

The unity gain frequency was measured to about 20 kHz.

It agrees with the designed filter shape (though the gain factor is a little bit underestimated).

Apparently there is a phase delay at high frequency above 10kHz, but it is okay because the phase margin is quite acceptable up to 100kHz.

 

However I found that the control range was quite narrow.

The PLL was able to be kept in only +/- 1MHz range, this fact was confirmed by shifting the frequency of Marconi during it's locked.

I will post another elog entry about this issue.

 


 (notes)

 Marconi power = 6dBm

 VCO power after RF amp. = -0.6 dBm

 Marconi frequency = 79.5 MHz

 Phase detection coefficient = 0.4 V/rad (measured by using an oscillo scope)

 

  3881   Mon Nov 8 16:03:46 2010 kiwamuUpdateGreen Locking80MHz VCO : PLL open loop looks good

Quote:

I measured the open loop transfer function of the 80MHz VCO's PLL while locking it to Marconi.

 

Bad; there should be a passive ~1 MHz LP filter between the mixer and anything that comes after. The SR560 + mixer does not equal a demodulator.

  3397   Wed Aug 11 11:51:45 2010 Gopal UpdateWIKI-40M Update8.5.10 - 8.11.10 Weekly Update

Summary of this Week's Activities:

Thursday, August 5:

X-Displacement Transfer Function Measurement

JPL Tour

Friday, August 6:

Y-Displacement Transfer Function Measurement

Z-Displacement Transfer Function Measurement

Monday, August 9:

Worked on COMSOL/MatLab Interface --> problems may be due to older version

Discussed with Koji options for calling our COMSOL sales representative

Jan and I decided that there is in fact something wrong with the installations on both my Mac and Kallo

Reinstalled on both machines, but the problem was not solved

Jan said we'd go see Larry tomorrow

Tuesday, August 10:

Attempted to figure out Time-Dependent Modal Analysis --> don't think it's what we need

Began reading the LiveLink for MatLab documentation --> even the directions in this produced issues

Discovered "Prescribed acceleration" option for gravity:

A test with it on the simplest stack eliminated the unwanted oscillation, which I guess is a partial success...

Trying the same thing with Koji on a simple pendulum, however, didn't produce the expected increase in resonant frequency

(Jan was unable to see Larry today, but we're meeting on Wednesday instead).

Wednesday, August 11 (morning):

Some background research on multiple-layer stack theory

Began working on presentations

 

 

 

  12511   Wed Sep 21 09:04:57 2016 SteveUpdateGeneral8 hours recovery progress

Good 8 hours

Quote:

The misalignment wasn't as bad as I had intially feared; the spot was indeed pretty high on ETMX at first. Both transmon QPDs did need a reasonable amount of steering to center once the dither had centered the beam spots on the optics.

Arms, PRMI and DRMI have all been locked and dither aligned. All oplevs and transmon QPDs have been centered. All AS and REFL photodiodes have been centered. 

Green TM00 modes are seen in each arm; I'll do ALS recovery tomorrow. 

 

  5619   Tue Oct 4 20:34:20 2011 KatrinUpdateGreen Locking7kHz Peak in servo input YARM

[Kiwamu, Katrin]

As reported earlier an oscillation around 7kHz is an the PDH error signal. The lower spectrum show that there is a peak from 6-7kHz.

This peak is somehow dependent on the modulation frequency. This means the peak can be shifted to a higher frequency when the modulation frequency is increased (see for comparsion f_mod=279kHz).

If the power supply for the green PD is switched of the peak vanishes. The same happens if the LO is switched of.

servoinput.png servoinput2.png

  7077   Thu Aug 2 04:58:00 2012 MashaUpdatePEM70 Meter Long Guralp 1 Cable

The parts Jenne and I ordered arrived today, so we made a long cable for Guralp 1 using a 24 + 1 wire 70 meter long cable, a female 37-pin DSub, and a 26-pin milspec. The pin map is the same as the one I specified in my previous E-log. I soldered both the milspec attachment and the DSub attachment, and used a Multimeter to check the connectivity of the cables. 20 of 20 connections worked (beeped), so I plugged  the cable into the Gurlap 1 seismometer and the Guralp box.

The time series comparison for the two cables

Old cable:

BeforeCable.png

New cable: (I had to move GUR 1, so it's still stabilizing in the X and Y time series)

 

 AfterCable.pngNew

The current signal spectrum

 

 NewCableFreq.png

The BLRMS on the seismic strip also look similar using the two cables - it's more visible on the wall, but I will include a StripTool picture:

New Cable BLRMS (similar to old cable BLRMS)

 NewCableStrip.png

  3219   Wed Jul 14 13:03:04 2010 Gopal UpdateWIKI-40M Update7.8.10 - 7.14.10 Weekly Update

Summary of this Week's Activities:

Wed. 7/7: COMSOL Busbar tutorials; began stack design; began base; Viton rubber research

Thurs. 7/8: Completed Viton rubber research; updated materials; finished designing the base layer

Fri. 7/9: Research model coupling papers; extensive eLog entry about base design and troubleshooting

Sun. 7/11: Played around with Busbar to find first eigenfrequency; continued crashing COMSOL

Mon. 7/12: Intrusions in COMSOL eLog tutorial entry; research eigenfrequency analysis; successfully got first eigenmode of rectangular bar

Tues. 7/13: Updated Poisson ratio of Viton and subsequently succeeded in running eigenfrequency tests on base stack layer. Systematic Perturbation Tests were documented in the most recent elog entry. Discussed results with Rana and decided this didn't make sense. Analytical study required.

Wed. 7/14: Went over to machine shop to experimentally extrapolate spring constant of Viton. Calculations to be done in the afternoon.

  3363   Wed Aug 4 20:58:22 2010 GopalUpdateWIKI-40M Update7.28.10 - 8.4.10 Weekly Update

Summary of this week's activities:

7/28:    Finished Y-Translational 4-Stack Analysis

"Tapered Cantilever" COMSOL tutorial

Tried (and failed) isolating gravity from oscillation

7/29:    Developed tilt/rotation load combinations for torsional inputs and showed these to work in the model

Tried using Normal Vector mode on top plate to obtain output tilts; worked for the rectangular bar, but not for the full stack

Talked to Jan about a 1st-order alternative to gravity - requires Weak Form (only found in COMSOL 3.5 right now)

Began Z-Translational 4-Stack Analysis -- Ran Overnight

7/30:    Progress Report 1st Draft

Completed Z-Translational 4-Stack Analysis

8/1:      Progress Report 2nd Draft

8/2:      Progress Report 3rd Draft

Submitted Progress Report

8/3:      Finalized Eigenfrequency Analysis for MC1/MC3 Stack

24 Physical Eigenmodes plotted and recorded, as expected

Should be good enough for the final report --> focus on transfer function analysis for the remainder of the SURF

8/4:      Prescribed Displacement Tests on Simple Rectangular Block --> shown to better produce displacement-displacement transfer functions

X-to-X Transfer Function seems much better when plotted

Should now be able to do the Displacement portion of Transfer Function Analysis on MC1/MC3 for Translational Modes

(I apologize that this update is a little late)

  3307   Wed Jul 28 12:31:00 2010 GopalUpdateWIKI-40M Update7.21.10-7.28.10 Weekly Update

Summary of this week's activities:

7/21: Frequency Domain Analysis of rectangular bar; discussed with Koji how to convert complex eigenfrequencies into phase factors.

7/23: Created Wiki page about FDA; Journal Club

7/26: Recreated Stack_1234.mph due to boundary value issues; FDA for 1,2,3,4,5 Hz

7/27: Discovered MC2 logbooks for later design; ran the complete x-translational FDA for Stack_1234.mph

7/28: Finished y-translational FDA (posted previously); "Tapered Cantilever" COMSOL tutorial for gravity-load analysis.

  3255   Wed Jul 21 11:57:59 2010 GopalUpdateWIKI-40M Update7.14.10-7.21.10 Weekly Update

Summary of this week's activities:

7/14: Analytical calculation of Viton spring constant; updated Viton values in models; experimental confirmation of COMSOL eigenfrequencies (single stack layer)

7/15: Extensions to 2-, 3-, and 4-layer stack legs. Eigenfrequency characterizations performed for each level. Meshing issues with 4-layer stack prevented completion.

7/19: Debugged the 4-layer stack. Turned out to be a boundary condition issue because of non-sequential work-plane definitions. Successful characterization of single-leg eigenfrequencies.

7/20: Prototype three-legged stack completed, but dimensions are incorrect. Read Sievers paper for details of triple-legged stack. Sorted through many stack design binders in efforts to distinguish IOC/OOC, BSC/ITMX/ITMY, MC1/MC3, and MC2 dimensions.

7/21: Researched frequency domain analysis testing in COMSOL. Attempting to first find transfer function of a single-layer stack --> currently running into some run-time errors that will need some more debugging in the afternoon.

  5657   Wed Oct 12 18:54:02 2011 KatrinUpdateGreen Locking60 Hz oscillation due to broken BNC cable

There was a 60 Hz and 120 Hz oscillation on the green PDH photo diode output. After a long search, I could identify that

the source was a broken BNC cable which was connected to the photo diode. I exchanged that BNC cable and the 60 Hz

and 120 Hz are gone :-)

With the new cable the PD output was less noisy so that it was easier to achieve a better alignment of the light to the cavity.

The reflected power could be reduced from 40% to 30%. For perfect alignment the reflected power would be 20%.

  6127   Sat Dec 17 00:00:03 2011 kiwamuUpdateGreen Locking60 Hz line nose gone

Quote from #6126
As shown in the noise budget below, the 60 Hz line noise currently dominates the arm displacement.

 The 60 Hz line noise has gone away.

It turned out that the line noise came from an oscilloscope.
The oscilloscope had been connected to a SR560, which amplifies the frequency-discriminated signal before the ADC as a whitening filter.
I still don't have a good explanation for it, but somehow connecting the oscilloscope made the line noise pretty high.
  3752   Thu Oct 21 12:15:02 2010 ranaUpdatePEM6.9 Mag EQ in Gulf of California
Magnitude 6.9
Date-Time
Location 24.843°N, 109.171°W
Depth 10 km (6.2 miles) set by location program
Region GULF OF CALIFORNIA
Distances 105 km (65 miles) S of Los Mochis, Sinaloa, Mexico
125 km (75 miles) SW of Guamuchil, Sinaloa, Mexico
140 km (85 miles) NE of La Paz, Baja California Sur, Mexico
1200 km (740 miles) WNW of MEXICO CITY, D.F., Mexico
Location Uncertainty horizontal +/- 6.1 km (3.8 miles); depth fixed by location program
Parameters NST=187, Nph=187, Dmin=843.1 km, Rmss=1.17 sec, Gp=133°,
M-type=teleseismic moment magnitude (Mw), Version=6
Source
  • USGS NEIC (WDCS-D)
Event ID us2010crbl
  3166   Wed Jul 7 11:35:59 2010 GopalUpdateWIKI-40M Update6.30.10 - 7.7.10 Weekly Update

Summary of this Week's Activities:

6/30: 2nd and 3rd drafts of Progress Report

7/1: 4th draft and final drafts of Progress Report; submitted to SFP

7/5: Began working through busbar COMSOL example

7/6: LIGO meeting and lecture; meeting with Koji and Steve to find drawing of stacks; read through Giaime's thesis, Chapter 2 as well as two other relevant papers.

7/7: Continued working on busbar in COMSOL; should finish this as well as get good headway on stack design by the end of the day.

  3142   Wed Jun 30 11:35:06 2010 Gopal UpdateGeneral6.23.10 - 6.30.10 Weekly Update

Summary of this Week's Activities:

6/23: LIGO Safety Tour; Simulink Controls Tutorial

6/24: Simulink Diagram for Feedback Loop; Constructed Pendulum Transfer Function; Discussion with Dr. Weinstein

6/25: Prepare for pump-down of vacuum chamber; crane broken due to locking failure; worked through COMSOL tutorials

6/28: Ran through Python Tutorials; Began learning about Terminal

6/29: Wrote Progress Report 1 First Draft

6/30: Began editing Progress Report 1

  3103   Wed Jun 23 12:31:36 2010 GopalUpdateGeneral6.16.10-6.23.10 Weekly Update

Summary of This Week's Activities:

6/16: LIGO Orientation; First Weekly Meeting; 40m tour with Jenne; Removed WFS Box Upper Panel, Inserted Cable, Reinstalled panel

6/17: Read Chapter 1 of Control Systems Book; LIGO Safety Meeting; Koji's Talk about PDH Techniques, Fabry-Perot Cavities, and Sensing/Control; Meeting w/ Nancy and Koji

6/18: LIGO Talk Part II; Glossed over "LASERS" book; Read Control Systems Book Chapter 2; Literary Discussion Circle

6/21: Modecleaner Matrix Discussion with Nancy; Suggested Strategy: construct row-by-row with perturbations to each d.f. --> Leads to some questions on how to experimentally do this.

6/22: Learned Simulink; Learned some Terminal from Joe and Jenne; LIGO Meeting; Rana's Talk; Christian's Talk; Simulink Intro Tutorial

6/23 (morning): Simulink Controls Tutorial; Successfully got a preliminary feedback loop working (hooray for small accomplishments!)

 

Outlook for the Upcoming Week:

Tutorials (in order of priority): Finish Simulink Tutorials, Work through COMSOL Tutorials

Reading (in order of priority): Jenne's SURF Paper, Controls Book, COMSOL documentation, Lasers by Siegman.

Work: Primarily COMSOL-related and pre-discussed with Rana

  11139   Fri Mar 13 03:10:35 2015 JenneUpdateLSC6+ CARM->REFL transitions, 1 DARM->AS transition

Much more success tonight.  I only started my tally after I got the CARM transition to work entirely by script, and I have 6 tally marks, so I probably made the CARM to RF-only transition 7 or maybe 8 times tonight in total.  Unfortunately, I only successfully made the DARM transition to AS55 once.    From the wall striptool, counting the number of times the transmitted power went high, I had about 40 lock trials total. 

The one RF-only lock ended around 1:27am.

I think 2 things were most important in their contributions to tonight's success.  I modified the bounceRoll filters in the CARM and DARM filter banks to eat less phase.  Also, using Q's recipe as inspiration, I started engaging the AO path partway through the CARM transition which makes it much less delicate. 


Bounce roll filter

Koji and I added a ~29Hz resonant gain in the bounce roll filter several months ago, to squish some noise that we were seeing in the CARM and DARM ALS error signals.  This does a lot of the phase-eating.  I'm assuming / hoping that that peak won't be present in the CARM and DARM RF error signals.  But even if it is, we can deal with it later.  For now, that peak is not causing so much motion that I require it.  So, it's gone. 

This allowed me to move the complex zero pair from 30 Hz down to 26 Hz.  Overall I think this gained me about 10 degrees of phase at 100Hz, and moved the low end of the phase bubble down by about 10Hz. 


Prep for REFL 11 I through the CM board and CM_SLOW

In order to use Q's recipe (elog 11138), I wanted to be able to lock CARM on REFL11 using the CM_SLOW filter bank. 

I did a few sweeps through CARM resonance while holding on ALS, and determined that the REFL1 input to the CM board needed a gain of -20dB in order to match the slope of CM_SLOW_OUT to CARM_IN (ALS), leaving all of Q's other settings alone.  Q had been using a REFL1 gain of 0dB for the PRY earlier today.

I needed to flip the sign in the input matrix relative to what Q had (he was using +1 in the CM_SLOW -> CARM_B, I used -1 there).  To match this in the fast path, I flipped the polarity of the CM board (Q was using minus polarity, I am using positive).

The CM_SLOW filter bank had a gain of 0.000189733.  I assume that Q did this so that the input matrix element could be unity.  I left this number alone.  It is of the same order as the plain REFL11I->CARM input matrix element of 1e-4 from Saturday night, so it seemed fine.

During my sweeps through CARM resonance, I also saw that I needed an offset to make CM_SLOW's average about 0.  With the crazy gain number, I needed an offest of -475 in the CM_SLOW filter bank.  As I type this though, it occurs to me that I should have put this in the CM board, since the fast path will have an offset that isn't handled.  Ooops. 


Trying Q's recipe for engaging AO path

I am able to get the MC2 AO gain slider up to -10dB (-7 is also okay).  If I increase the digital CARM gain too much, I see gain peaking at about 800Hz, so something good is happening.  (That was with a CARM_B gain of 2.0 and CARM_A gain of 0.  Don't go to 2.0)

I tried once without engaging his 300:80 1/f^2 filter in the CM_SLOW filter banks to start stepping up the CM REFL1 and MC AO gains together, but I only made it 2 steps of 1dB each before I lost lock. 

I tried once or twice turning on that 300:80 filter that Q said over the phone really helped his PRY locking, but it causes loop oscillations in CARM.  Also, I forgot to turn it off for ~45 minutes, and it caused several locklosses.  Ooops.  Anyhow, this isn't the right filter for this situation.


AS55 whitening problem

Twice I tried turning on the AS55 whitening.  Once, I was only partly transitioned from ALSdiff to AS55, the other time was the one time I made the full transition.  It caused the lockloss from the only RF-only lock I had tonight :(

Unfortunately I don't have the time series before the whitening filters (not _DQ-ed), but you can see a giant jump in the _ERR signals when I turn on the whitening, just before the arm power dies:

AS55whitening_lockloss_12March2015.pdf

The AS55 phase is -30, I has an offset of 28.2 and Q has an offset of 6.4.  Both have a gain of 1.  This should give us enough info to back out what the _IN1 signals looked like before I turned on the whitening if that's useful.


Other random notes

Ramp times for CARM_A, CARM_B, DARM_A and DARM_B are all 5 seconds.  This is set in the carm_cm_up script.

carm_cm_up script freezes the arm ASS before it starts the IR->ALS transition, to make it more convenient to run the ASS each lockloss.

carm_cm_up script no longer has a bunch of stuff at the bottom that we're not using.  It's all archived in the svn, but the remnants from things like variable finesse aren't actively  useful.

carm_cm_down script turns off the CM_SLOW whitening (which gets set in the up script)

carm_cm_down script clears the history of the ETM oplevs, in case they went bad (from some near divide-by-zero action?), but the watchdog isn't tripped. This clears away all the high freq crap and lets them do their job.

FSS Slow has been larger than 0.55 all night, larger than 0.6 most of the night, and larger than 0.7 for the last bit of the night.  MC seems happy.

both carm_cm_up and carm_cm_down are checked into the svn.  The up script is rev 45336 and the down script is 45337.

Some offset (maybe the fact that the fast AO path had an un-compensated offset?) is pulling the arm powers down as I make the transitions:


Recipe overview

  • Lock PRMI with arms held on ALS at 3nm CARM offset.  Bring CARM offset to 0.
  • Turn on CARM_B and DARM_B a little bit, then turn on their integrators
  • Lower the PRCL and MICH gains a little.
  • Increase the CARM_B gain a bit, then turn off FM1 for both CARM and DARM.
  • Increase CARM_B gain, lowering CARM_A gain.
  • Increase DARM_B gain, lowering DARM_A gain.  Now the power should definitely be stable (usually ends up around 80).
  • Partly engage AO path.
    • CM board REFL1 gain = -20dB
    • CM board AO gain = 0dB
    • MC2 board AO gain starts at -32dB, stepped up to -20dB
  • Increase CARM_B gain a bit
  • More AO path:  MC2 board AO gain steps from -20dB to -10dB
  • Increase CARM_B gain to 1.5, turn CARM_A gain to zero
  • CM_SLOW whitening on

After that, I by-hand made the DARM transition on the 6th successful scripted CARM transition, and tried to script what I did, although I was never able to complete the DARM transition again.  So, starting where the recipe left off above,

  • Turn off DARM's FM2 boost to win some more phase margin.
  • Increase DARM_B gain to 0.5, lower DARM_A gain to 0.

Since DARM doesn't have an analog fast path, it is stuck in the delicate filter situation.  I think that I should probably start using the UGF servo once the arm power is stable so that DARM stays in the middle of its phase bubble.

Rather than typing out the details of the recipe, I am attaching the up script.

ELOG V3.1.3-