40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 115 of 341  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  9172   Fri Sep 27 21:01:50 2013 MasayukiUpdateLSCLSC calibration screen


 I fixed the XARM and YARM real time calibration servo.

I also change the C1CAL_MICH_A servo. Now the actuator response and the suspension TF are combined together and that filter name is BS_act. C1CAL_XARM_A and C1CAL_YARM_A have same kind of filters, ETMX_act and ETMY_act.

There are AI filter in each A servo and inv_AA, inv_DAA filters in CINV servo, but it's doesn't work correctly yet.

  9174   Mon Sep 30 11:33:15 2013 ranaUpdateLSCLSC calibration screen


  I fixed the XARM and YARM real time calibration servo.

I also change the C1CAL_MICH_A servo. Now the actuator response and the suspension TF are combined together and that filter name is BS_act. C1CAL_XARM_A and C1CAL_YARM_A have same kind of filters, ETMX_act and ETMY_act.

There are AI filter in each A servo and inv_AA, inv_DAA filters in CINV servo, but it's doesn't work correctly yet.

 These aren't servos. What he means is that he's changed some filters in the real time calibration screens so as to make the actuation and sensing parts more accurate, but the inversion of the AA filters is not accurate yet.

  381   Fri Mar 14 15:52:07 2008 robConfigurationLSCLSC code change

I've edited the LSC code to send different signals to the ASS box. Now, instead of the previously selected error signals deemed to be acceptable for the Alignment Sensing and Stabalization system, it sends the LSC control signals for each suspension to the ASS box (in its new incarnation as the Adaptive Susurration Subtraction system). These are the signals after the output matrix, and also after the LSC-[SUS] filter modules.
  386   Thu Mar 20 16:06:27 2008 robConfigurationLSCLSC code change

I changed the LSC code again. I noticed that when turning off the LSC (e.g., going from LA to OFF), the cpu time would jump from ~50 to ~80, and irrevocably de-sync all the SUS controllers. This was because turning off the LSC would suddenly zero the inputs to the decimation filters that send information to the ASS box, which for some reason greatly increases the computation time of the iir filter function call. I changed the code so that these inputs are never zeroed. The ASS receives inputs from the LSC all the time now.

I also noticed that the ASS machine was running in ~2400 usec. Yes, 2,400 microseconds. I don't know how long it's been doing that, but I restarted it. Immediately after restart, it ran at 1700 microseconds. After using the "RESET" field in the adaptOnline code, that dropped to ~100 usec. Now it's not doing any adaptive filtering, as I don't know what the good settings are and no-one has been elogging their IFO work the last few days.
  1457   Tue Apr 7 21:39:57 2009 YoichiConfigurationComputersLSC code recompiled with a fix for denormalization problem
This is not my work but I will put it for the record.

A few days ago, Rob recompiled the LSC code with the fix of the denormalization problem provided by Alex.
Since then, the LSC code has been working fine. I recognize that c1lsc is now less loaded.

I believe Rob only recompiled the LSC code, so there could still be the problem in the suspension controllers.
  1460   Wed Apr 8 18:18:33 2009 ranaConfigurationComputersLSC code recompiled with a fix for denormalization problem
Below is the link to the anti-denormalization technique that Rolf and Alex implemented at the sites,
that was pointed out by Chris Wipf from MIT:

  3995   Tue Nov 30 12:25:08 2010 josephbUpdateCDSLSC computer to chassis cable dead


We seemed to have a broken fiber link for use between the LSC and its IO chassis.  It is unclear to mean when this damage occurred.  The cable had been sitting in a box with styrofoam padding, and the kink is in the middle of the fiber, with no other obvious damage near by.  The cable however may have previously been used by the people in Downs for testing and possibly then.  Or when we were stringing it, we caused a kink to happen.

Tried Solutions:

I talked to Alex yesterday, and he suggested unplugging the power on both the computer and the IO chassis completely, then plugging in the new fiber connector, as he had to do that once with a fiber connection at Hanford.  We tried this this morning, however, still no joy.  At this point I plan to toss the fiber as I don't know of any way to rehabilitate kinked fibers.

Note this means that I rebooted c1sus and then did a burt restore from the Nov/30/07:07 directory for c1suspeics, c1rmsepics, c1mcsepics.  It looks like all the filters switched on.

Current Plan:

We do, however, have the a Dolphin fiber which originally was intended to go between the LSC and its IO chassis, before Rolf was told it doesn't work well that way.  However, we were going to connect the LSC machine to the rest of the network via Dolphin.

We can put the LSC machine next to its chassis in the LSC rack, and connect the chassis to the rest of the front ends by the Dolphin fiber.  In that case we just need the usual copper style cable going between the chassis and the computer.


  9312   Wed Oct 30 00:02:25 2013 JenneUpdateLSCLSC demod boards need some thought

As we are meditating on things to look at for PRMI + 2 arms, Rana brought up the question of the demod board situation. 

We then found this table on the wiki (LSC demod boards) that indicates that all of the demod boards were originally given lowpass filters, no matter the demodulation frequency.  Back in September, I switched out the low pass filter for a bandpass filter in POP110, and put in the same bandpass when putting together AS110 (elog 9100).  So, the 11MHz diodes are probably okay with lowpasses, and the 110 diodes are okay, but we need to think about all the other ones. 

We should probably do a first guess by putting in a bandpass filter, but then simulate and measure to figure out what our requirements are for attenuation at the non-demodulation frequencies for each board.

The SXBPs from Minicircuits look pretty good, but there are lots of options on their website.


For tonight, Rana has put a coax 100 MHz highpass filter on the input to the REFL165 demod board.

  9316   Wed Oct 30 03:33:17 2013 RanaUpdateLSCLSC demod boards need some thought



I worked on the script SPAG4395A.py tonight with Masayuki's help. This sets up the parameters on the Agilent 4395A and then acquires the spectrum data. It had a couple of bugs before: no matter what channel you requested, you always got channel R. It also would disobey any requests to reduce the attenuation and left the Auto Atten ON. The version now in the SVN allows you to choose the channel and the attenuation.

It then makes this plot using matplotlib. The attached image is from the REFL165 pickoff at a time tonight when the arm powers were ~5-10. I have converted the spectrum from RF electrical Watts into Volts (V = 50*sqrt(W)). To go from the analyzer input to the demod board input we should scale this spectrum by a factor of ~15 (to account for the 20 dB from the coupler and the 3 dB of the splitter and a little more for losses). On the oscilloscope we see Vpp ~5 mV, so that's ~75 mVpp at the output of the BBPD which we're using for REFL165. Perhaps we can handle another factor of ~2-3 ? I'm not sure what we have in terms of linearity measurements on this thing.

EDIT: Evan is right, its V = sqrt(50*W), not V = 50*sqrt(W). ignore y-axis above

  14313   Wed Nov 21 09:59:26 2018 gautamUpdateLSCLSC feedforward block diagram

Attachment #1 is a block diagram depicting the pathway by which the vertex DOF control signals can couple into DARM (adapted from a similar diagram in Gabriele's Virgo note on the subject). I've also indicated some points where noise can couple into either loop. In general, there are sensing noises that couple in at the error point of the loop, and actuation noises that couple in at the control point. In this linear picture, each block represents a (possibly time varying) transfer function. So we can write out the node-to-node transfer functions and evaluate the various couplings.

The motivation is to see if we can first simulate with some realistic noise and time-varying couplings (and then possibly test on the realtime system) the effectiveness of the filter denoted by "FF" in canceling out the shot noise from the auxiliary loop being re-injected into the DARM loop via the DARM sensor. Does this look correct?

Attachment 1: IMG_7173.JPG
  14326   Fri Nov 30 19:37:47 2018 gautamUpdateLSCLSC feedforward block diagram

I wanted to set up an RTCDS model to understand this problem better. Attachment #1 is the simulink diagram of the signal flow. The idea will be to put in the appropriate filter shapes into the various filter blocks denoting the DARM and auxiliary DoF plants, controllers and actuators, and then use awggui / diaggui to inject some noises and see if in this idealized model I can achieve good subtraction. Then we can build up to applying a time varying cross coupling between DARM and the vertex DoF, and see how good the adaptive FF works. Still need to setup some MEDM screens to make working with the test system easier.

I figured c1omc would be the least invasive model to set this upon without risking losing any of our IR/green alignment references. Compile and install went smooth, see Attachment #2. The c1omc model was clocking 4us before, now it's using 7us.

Attachment #3 shows the top level of the OMC model, while Attachment #4 shows the MEDM screen.

* Note to self: when closing a loop inside the realtime model, there has to be a delay block somewhere in the loop, else a compilation error is thrown.

Attachment 1: LSC_FF_tester.png
Attachment 2: Screenshot_from_2018-11-30_19-41-07.png
Attachment 3: Screenshot_from_2018-12-10_15-31-23.png
Attachment 4: SimLSC.png
  8623   Thu May 23 00:49:13 2013 JenneUpdateLSCLSC filters loaded


 To avoid exciting at the PRM violin mode frequency, I have changed all of the filters relevant to the sensing matrix measurement from 628Hz to 580.1Hz.  This includes notches in the LSC control loops, as well as the band pass filters in the lockins.  I have not yet loaded the new filters, since arm locking is in progress.

 I have loaded these new filters in.  Manasa is still using the IFO for green stuff, so I can try out the PRMI measurement in a day or so.  (Right now I have to make sure I understand my data, anyway.)

  8422   Mon Apr 8 10:19:46 2013 JenneUpdatePSLLSC left enabled


 Note: The TRY PD isn't installed and normalized properly yet, so the IFO OVERVIEW screen indicates lock for the Yarm constantly, which is not true.  Hopefully in the next day or so the screen will be back to telling the truth.

Also, the LSC Locking was left ENABLED (presumably over the weekend).   This is not so good.  It can kick optics around, so we should all take a look when we walk through the control room, and if no one is locking, please disable the LSC master switch. 

  5495   Wed Sep 21 02:49:39 2011 KeikoSummaryLSCLSC matrices

I created 3 kinds of LSC matrices, PRMI condition with carrier resonant in PRC, PRMI condition with SB resonant in PRC, and DRMI with SB resonant in PRC. The matrices are with AS55 and REFL11 which are used for locking right now. The signal numbers are written in log10, and the dem phases are shown in degrees.

From CR reso PRMI to SB reso PRMI, demodulation phases change  ----


PRMI - Carrier resonant in PRC


            PRCL      MICH  SRCL

REFL11 7.7079 2.9578 0
REFL33 5.2054 3.2161 0
REFL55 7.7082 2.9584 0
REFL165 3.9294 2.5317 0
AS11 1.0324 3.5589 0
AS33 1.0286 1.6028 0
AS55 1.1708 4.2588 0
AS165 1.1241 0.9352 0
POP11 2.8015 -1.3331 0
POP33 0.2989 -1.6806 0
POP55 2.8017 -0.6493 0
POP165 -0.9769 -2.3708 0
POX11 3.7954 -0.3363 0
POX33 1.293 -0.7058 0
POX55 3.796 0.355 0
POX165 0.0187 -1.3837 0
Dem Phase      
REFL11 3 179 0
REFL33 165 -172 0
REFL55 13 170 0
REFL165 86 177 0
AS11 -32 73 0
AS33 176 -72 0
AS55 -41 12 0
AS165 -7 146 0
POP11 -11 -116 0
POP33 124 147 0
POP55 -54 -146 0
POP165 -117 -25 0
POX11 -87 15 0
POX33 -105 -80 0
POX55 -76 16 0
POX165 180 -91 0

PRMI - SB resonant in PRC

SB reso PRMI    
REFL11 7.6809 5.2777 0
REFL33 5.2465 3.1565 0
REFL55 7.2937 5.589 0
REFL165 4.3892 2.6857 0
AS11 1.3123 3.545 0
AS33 0.9331 1.6022 0
AS55 1.7425 4.0514 0
AS165 1.5838 1.1344 0
POP11 2.7745 0.3791 0
POP33 0.3401 -1.7392 0
POP55 2.3872 0.6904 0
POP165 -0.5171 -2.2279 0
POX11 3.7684 1.3574 0
POX33 1.3341 -0.7664 0
POX55 3.3815 1.6688 0
POX165 0.4785 -1.2163 0
Dem Phase
REFL11 155 -115 0
REFL33 -8 3 0
REFL55 91 -178 0
REFL165 -62 28 0
AS11 109 62 0
AS33 -39 99 0
AS55 13 -38 0
AS165 -155 168 0
POP11 141 -128 0
POP33 -48 -38 0
POP55 24 115 0
POP165 95 -176 0
POX11 65 155 0
POX33 83 95 0
POX55 2 92 0
POX165 32 123 0

DRMI - SB resonant in PRC

REFL11 7.6811 5.0417 4.2237 
REFL33 5.2751 4.1144 3.7766
REFL55 7.2345 7.0288 6.6801
REFL165 4.3337 4.1266 3.7775
AS11 1.1209 3.512 0.9248
AS33 0.9159 1.6323 0.7971
AS55 2.6425 5.3915 2.5519
AS165 2.6423 2.4881 2.3272
POP11 2.7747 0.1435 -0.6846
POP33 0.3687 -0.7849 -1.122
POP55 2.3244 2.1302 1.7815
POP165 -0.5833 -0.8 -1.1548
POX11 3.7676 3.261 0.8086
POX33 1.3896 0.2372 0.2333
POX55 3.4619 3.0097 3.1326
POX165 0.782 0.6668 0.4357
Dem Phase
REFL11 154 -16 4
REFL33 -5 12 51
REFL55 129 -166 -123
REFL165 -23 40 83
AS11 132 79 69
AS33 -92 -127 -83
AS55 -33 -55 -5
AS165 154 179 -144
POP11 141 -29 -9
POP33 -46 -27 12
POP55 62 127 170
POP165 135 -161 -117
POX11 64 -102 -83
POX33 85 143 118
POX55 57 103 124
POX165 99 155 -164



  10904   Thu Jan 15 14:28:14 2015 JenneUpdateLSCLSC model change idea

Something that kind of drives me crazy with our current LSC model setup is that I can't make "finished" error signals before blending them.  The blending happens before the normalization matrix, and there is no place to put an offset to help match a new error signal to the current offset.  So.  While I'm sure this is not going to be immediately popular, here's a cartoon of a proposed model change to the LSC. 

The most important difference between this and the ramping matrix that is used at the sites is that you can put in offsets before the blend.  Also useful is the fact that the normalization can happen before the blend.  This proposal would make the LSC input matrix  and the normalization matrix have twice as many rows, and add an extra "selector matrix" just before the triggering at the error point of the loops. 

I've only drawn one degree of freedom in my cartoon, but assume that they all have the same capability (maybe we don't have to do XARM, YARM and MC this way).  One row is currently being used for the error signal, while the other row is just used to prep a new singal.  For a first transition (say, ALS to DC transmission), maybe the ALS signals are on row 1, and the DC trans is on row 2.  Once the transition is complete, row 1 is available to prep for the next transition (such as AS55Q).


Thoughts?  Is there a better way to achieve what I'm going for here?

Attachment 1: SwitchableErrorSignalProposal_Jan2015.pdf
  10910   Fri Jan 16 03:31:35 2015 JenneUpdateLSCLSC model change implemented

Okay, it has taken me almost exactly 12 hours (with a dinner break), but I have implemented this change.

Everything was svn-ed before I did things, and then again afterward.

Here is the "before" screenshot of the LSC model:

And here is afterward:

If you look extra carefully, you will see that it matches my proposal from http://nodus.ligo.caltech.edu:8080/40m/10904 .  I have made the change for DARM, MICH, PRCL, SRCL and CARM.  I did not alter XARM, YARM or MC.  Also, the CESAR stuff was taken out of the CARM area, since this is now a more generalized version of the same thing.

I have also checked and modified all of the scripts that I could think of, as well as all of the ifoconfig burt .req and .snap files that I could think of.  I also ran the carm_cm_up.sh script once, and it seems to work fine.  All of the transition scripts that are listed below (which are the only ones used currently in the sequence) now use the new error signal blending scheme.


  • Lock_ALS_CARMandDARM.py
  • ALSfindIRresonance.py
  • ALSwatch.py
  • carm_cm_down.sh
  • carm_cm_up.sh
  • CheckPRMIlock.py
  • Transition_MICH_REFL33Q_to_ASDC.py
  • Transition_CARM_ALS_to_TransInvSqrt.py
  • Transition_DARM_ALS_to_DCtrans.py
  • UGFup.py
  • UGFdown.py

Burts (listed are the .req files, but I also checked the .snap files, hand-editing the matrix element numbers where needed if I wasn't in the right config to do a save):

  • C1configure_Yarm.req
  • C1configure_YarmALS.req
  • C1configure_Xarm.req
  • C1configure_XarmALS.req
  • C1configure_CARM.req
  • C1configure_DARM.req
  • C1configure_PRM_forCARMdarm.req
  • C1configure_PRM_SBres.req
  • C1configure_PRM_Carr.req
  • C1configure_PRY.req
  • C1configure_DRM.req
  • C1configure_SRM.req

I also modified the screens for the input matrix and for the normalization matrix.  I created a new screen for the final blending matrices (which are all 2x1's), and I also modified the LSC_OVERVIEW screen. 

The input matrix and normalization matrix screens have colored bars that tell you whether a row is in use or not.  If the background to the row is the blue of the whole screen, that row is not being used.

The LSC screen has new hand-modified Kissel Buttons.  I wanted to show the total PD error signal that is being used, regardless of what row (A or B) it is on at that time.  So, I have collapsed the rows so that DARM_A and DARM_B are overlapped, even though they are actually rows 1 and 2 of the matrix.  The PD should only show up green on the LSC screen if that row is in use (so, if you are prepping a row, but aren't using it yet, you won't see those elements in the matrix).  Anyhow, the point is that the LSC overview part of things shouldn't look any different than before.

Brain not working anymore now that it's ~4am, but I need to rethink and recheck to make sure that the PD whitening triggering is still okay and working.  Or maybe we can remove it, and just include that in the scripts, as Rana has been suggesting for ages.  Thoughts for tomorrow.

  10914   Fri Jan 16 18:46:15 2015 KojiUpdateLSCLSC model change implemented

Was the screen modified directly on LSC_OVERVIEW.adl?
Even if so, that's OK. I'll incorporate the change to the screen making script once I'm back.

  10915   Fri Jan 16 20:01:32 2015 JenneUpdateLSCLSC model change implemented

Nope, I used the script.

Yesterday's changes were mostly to the generateLSCscreen/C1LSC_OVERVIEW_INPUT_MATRIX.adl sub-screen.  The UGF servos were added earlier in the week to the LSC screen in the generateLSCscreen/C1LSC_OVERVIEW_SERVOS.adl sub-screen.

  10923   Tue Jan 20 15:09:01 2015 JenneUpdateLSCLSC model change implemented



Brain not working anymore now that it's ~4am, but I need to rethink and recheck to make sure that the PD whitening triggering is still okay and working.  Or maybe we can remove it, and just include that in the scripts, as Rana has been suggesting for ages.  Thoughts for tomorrow.

LSC whitening triggering was not working, because of the implementation of the double-rows for the input matrix.  I have modified the c-code that looks at the input matrix and triggers, and decides when to turn on the PD whitening, so that it now works.

  9820   Thu Apr 17 01:01:02 2014 JenneUpdateLSCLSC model modifications

Last night, EricQ and I were concerned that we might need some CARM UGF servoing, so I added a UGF servo block, copied from the aLIGO LSC model, to our LSC model.  The block is inline with the CARM servo, after the output triggering, just before the output matrix.  Q put together some screens, which are accessible from the main LSC screen. 

The model is compiled and running.  We didn't get very far in testing it though before Koji pointed out that it is a slow solution, and not a fast one like we were searching for.  We were hoping to deal with the momentary power buildup, and thus optical gain change, as the arms flash close to resonance.  The UGF servo will not work nearly that fast though.  We may want it for slow UGF servo-ing, but it's not the solution to what Q and I were thinking about yesterday.  Regular ol' dynamic normalization is closer to the right answer for this.

In tonight's activities, Koji and I found that we probably want a CESAR block for DARM as well as CARM, so that we can independently normalize AS55Q. 

To solve the DARM oscillation issue from last night (that I discovered this evening when I finally looked at the time series data), we may want to implement a DARM UGF servo.  For tonight, as we reduced the CARM offset and started seeing gain peaking in the DARM spectra, I hand-reduced the DARM gain.


  9766   Mon Mar 31 13:26:23 2014 manasaUpdateLSCLSC model modified

I have included Yarm CESAR to the LSC model. It was just a copy paste of the Xarm CESAR. Since we are now meditating about implementing CCESAR and DCESAR, I did not run or install the model as yet.

  5812   Fri Nov 4 15:26:54 2011 JenneUpdateLSCLSC model recompiled

I moved the place where we take the OAF Degree of Freedom signals from - now it's the error point rather than the feedback for DARM, CARM, MICH, PRCL, SRCL, XARM and YARM.  I didn't do anything to MCL.

While trying to compile, there was something wrong with the lockins that were there...it complained about the Q OUTs being unconnected.  I even reverted to the before-I-touched-it-today version of c1lsc from the SVN, and it had the same problem.  So, that means that whomever put those in the LSC model did so, and then didn't check to see if the model would compile.  Not so good.

Anyhow, I just terminated them, to make it happy.  If those are actually supposed to go somewhere, whoever is in charge of LSC lockins should take a look at it.

Also, as Mirko mentioned in the previous elog 5811, we wanted to calculate the effect on the MC without actuating, so we put in a new summing point and a filterbank so we have testpoints.

LSC model recompiled.

OAF model recompiled.

FB restarted because of the new channels added to OAF.

  5832   Mon Nov 7 15:15:21 2011 JenneUpdateLSCLSC model recompiled


I moved the place where we take the OAF Degree of Freedom signals from - now it's the error point rather than the feedback for DARM, CARM, MICH, PRCL, SRCL, XARM and YARM.  I didn't do anything to MCL.

While trying to compile, there was something wrong with the lockins that were there...it complained about the Q OUTs being unconnected.  I even reverted to the before-I-touched-it-today version of c1lsc from the SVN, and it had the same problem.  So, that means that whomever put those in the LSC model did so, and then didn't check to see if the model would compile.  Not so good.

Anyhow, I just terminated them, to make it happy.  If those are actually supposed to go somewhere, whoever is in charge of LSC lockins should take a look at it.

Also, as Mirko mentioned in the previous elog 5811, we wanted to calculate the effect on the MC without actuating, so we put in a new summing point and a filterbank so we have testpoints.

LSC model recompiled.

OAF model recompiled.

FB restarted because of the new channels added to OAF.

 After Rana pointed out the errors of our ways, we reverted all of these changes.

  5833   Mon Nov 7 15:43:25 2011 jamieUpdateLSCLSC model recompiled


While trying to compile, there was something wrong with the lockins that were there...it complained about the Q OUTs being unconnected.  I even reverted to the before-I-touched-it-today version of c1lsc from the SVN, and it had the same problem.  So, that means that whomever put those in the LSC model did so, and then didn't check to see if the model would compile.  Not so good.

Anyhow, I just terminated them, to make it happy.  If those are actually supposed to go somewhere, whoever is in charge of LSC lockins should take a look at it.

 This was totally my fault.  I'm very sorry.  I modified the lockin part to output the Q phase, and forgot to modify the models that use that part appropriately.  BAD JAMIE!  I'll check to make sure this won't bite us again.

  9225   Wed Oct 9 17:27:35 2013 JenneUpdateLSCLSC model sensing matrix upgrades

The modifications to the LSC model are now complete, and the new model has been compiled, installed, and is running. The sensing matrix lockins are all in the c1cal model.  Masayuki is locking right now, so so far, things appear to be back to normal.

The longer version of the story, with all the detours and hiccups:

After several tries of deleting the GoTo and From flags / tags in the lockin area of the LSC model, and continually getting the "something is not connected" errors, I gave up and just drew several long lines.  So, in the new Sensing Matrix block (which is actually in c1cal, not c1lsc, but that's a story for the next paragraph), we should eventually make things back to the more clean flags situation, but for right now, it's working, with lots of lines everywhere.  I've tried to be very organized and clear about what lines go where, so that it's easy to see what's going on.

I eventually was able to compile c1lsc, and then installed it, and restarted the model.  Adding in 5x the lockin modules (we had 27, but now we have 5x27, so that we can look at the sensing matrix elements for every degree of freedom, and every photodiode, all at the same time) was too much for the poor lsc cpu.  I was consistently getting over 70usec per cycle, and was hitting a max of 77usec for the lsc cpu.  Both of those numbers are greater than the allowed 60usec.  So, I made the decision to put the whole sensing matrix / lockin stuff into the calibration model.  This means that I have 27+5 more IPC signals than I used to, but so far things seem to be okay (no rigorous testing yet).  (27 to send the 27 PD inputs over to the cal model, and another 5 to send the oscillator "clocks" from the cal model to the lsc model.)  The lsc model is now running faster than before (because there were 27 lockin modules in the model), at 24-28 usec, and the cal model is running at 39usec.

All seemed well and good, both the lsc and cal models compiled, but the lsc burt restore wasn't working.  Restarting the model did not successfully do a burt restore, and when I tried several different .snap files from today, and other times this month using burtgooey, I kept getting "NOT OK", and numbers weren't being restored into the epics channels.  A very few settings were restored, but most were not.  I ended up copying a .snap file from a few hours ago into a separate directory, then went in and by-hand removed all the lines referring to now non-existant lockin channels.  Burtgooey still told me "NOT OK", but settings seem to be restored, so I think it's okay.  I have not confirmed each and every one of the 10,000+ channels to ensure that the number is the same as the one in the .snap file, but as I glance around in the LSC screen and its dependants, all the numbers and buttons look about right.  

After all this stuff, Masayuki is locking both arms simultaneously in IR, as he prepares to test some new ALS scripts, so things seem okay for now.

  9222   Tue Oct 8 16:56:38 2013 JenneUpdateLSCLSC model sensing matrix upgrades in progress

I have modified the LSC model (the currently-running model is checked into the svn), but it is not compiling for me.  So, if you need to make changes to it, be careful, and probably save my version off to the side, and checkout the latest svn version.  (I don't foresee anyone needing to modify this model any time soon though).

The change that I'm trying to make is adding several more lockin setups, so that we can measure the sensing matrix elements for several degrees of freedom simultaneously. 

Right now, the error that I'm getting is the frustrating "something isn't connected" error, even though if you look in the model, the part that it mentions is fully connected.  Usually the solution to this is to disconnect and reconnect everything, so I'll work on that after I return to the lab in a bit.

  9109   Thu Sep 5 01:55:29 2013 JenneUpdateLSCLSC model upated to have AS110 channels, violin filter triggering

I have modified the c1lsc model so that I have access to the AS110 channels in the triggering and power normalization matrices. 

I also put in a few blocks so that we can have triggering on the violin notches that we moved to the LSC model a week or so ago. 

Here is my svn comment, so I don't have to retype things:

2 changes:  AS110 channels added, and Violin filter triggers added.

AS110:     We recently installed a    new demod board    and PD for an AS110 signal.  Since we will not    be using AS11 in the forseeable    future,    the AS110 demod    board outputs use the former AS11 channels.  I    have left the AS11 channels in the model so that we can easily    add them back if we want to, but they are grounded rather than    connected to the ADC.  I've added digital demodulation for AS110, power normalization,    and then added the I&Q signals to both the trigger matrix and the main    power normalization matrix.  NOTE that these slide the matrix columns around.    Since the AS110    is also    using the former AS11 whitening    channels, swapped those on the    BIO block also.

Violins:  Recently, Rana and I moved the SUS LSC violin    filters    from the individual suspension    models over to the LSC model.  Giving every optic every    optics' violin    notch helps eliminate bad cross-coupling between servo loops.  Here, I have enabled triggering    for these notches, so that the violin filters can come on after a cavity is locked.  Since the    filter banks SHOULD BE THE SAME    for all LSC_SUS banks,    the "mask" is common to    all optics.

I also edited several medm screens, to show the new changes:  the lsc overview screen has a button to the violin notch triggering screen, in addition to being able to get to the new screen from the regular triggering matrix screen.  I made the trigger and normalization matrix screens bigger, since there are now 2 new columns. 

I added AS110 to both the LSCoffsets script, and Masayuki's new, better, LSCoffsets2.py. 

I added new lines to the .req files for the ifo configure burt restores for the new matrix columns, and the violin triggering.

I restored, checked out, and saved the Xarm, Yarm, MICH, PRM_sb, and DRM configurations. 


I tried locking the DRMI, but haven't really been successful.  I'm not 100% sure how to do the phasing for AS110, so that could be a problem.  For POP, I can watch POPDC to see if something is a carrier or a sideband flash, but I don't have something quite as convenient at the AS port.  I have set the AS110 phase to 60 degrees for now, since during free swinging DRMI flashes, it looks like most of the buildup is in the I phase with 60 degrees.  Even with the same configurations as a week or so ago, I'm not getting much more than ~1 second locks.

I also tried locking the SRMI, but am not getting anything at all.  I think I need to go back to simulation-land to figure out what good signals might be.


Other thoughts:

Stefan modified the LSC filter module triggering blocks, so now we have a new epics variable, "_INVERT", which sends the trigger through a NOT or not.  I think that we want to keep this variable set to 0 to be the same as things were, but I do need to expose this new variable on the screens.

The trigger and normalization matrices pictured on the LSC overview screen need to be expanded by the 2 new columns.  The actual matrix screens are good, but I forgot to fix up the little Kissel buttons.

When I have a free swinging SRMI, MICH and SRCL should have the same sign for the gain, if I'm using AS55 I&Q for locking.

LLO is using REFL 9I for SRCL, and ASDC for MICH for the SRMI, but I don't have any REFL beam with a misaligned PRM, so I don't think I can copy what Den and Lisa did on Monday night.

I have figured out / rediscovered why the "sqrt" buttons on the power normalization screen aren't restored when you restart the LSC model - They are controlled by momentary epics records, which go to embedded c-code to do some toggling.  I don't know yet of a good way to save the configuration of these guys for burt restore-type restoration.  This will be a problem for anything that is using these toggle c-codes.

  4912   Wed Jun 29 14:43:12 2011 KojiUpdateLSCLSC model updated

LSC model has been updated and running,

- Now the power and signal recycling cavity lengths are named "PRCL" and "SRCL" in stead of three letter names without "L".

- Names for the trigger monitor were fixed. They are now "C1:LSC-DARM_TRIG_MON", etc., instead of "...NORM"

- Channel order of the DC signals for PDDC_MTRX and TRIG_MTRX were changed.

It was "TRX, TRY, REFL, AS, POP, POX, POY" but now "AS, REFL, POP, POX, POY, TRX, TRY".

We should change the locking script to accomodate these changes.

  4962   Tue Jul 12 11:52:54 2011 Jamie, SureshUpdateLSCLSC model updates

The LSC model has been updated:

Binary outputs to control whitening filter switching

We now take the filter state bit from the first filter bank in all RF PD I/Q filter banks (AS55_I, REFL11_Q, etc) as the controls for the binary analog whitening switching on the RF PD I/Q inputs. The RF_PD part was also modified to output this control bit. The bits from the individual PDs are then combined into the various words that are written to the Contec BO part.

Channel mapping updated/fixed to reflect wiring specification

Yesterday Suresh posted an updated LSC wiring diagram, with correct channel assignments for the RF PD I/Q and DC inputs.  Upon inspection of the physical hardware we found that some of LSC the wiring was incorrect, with I/Q channels swapped, and some of the PDs in the wrong channels.  We went through and fixed the physical wiring to reflect the diagram.  This almost certainly will affect the EPICS settings for some of the input channels, such as offsets and RD rotations.  We should therefore go through all of the RF inputs and make sure everything is kosher.

I also fixed all of the wiring in the LSC model to also reflect the diagram.

Once this was all done, I rebuilt and restarted the LSC model, and confirmed that the anti-whitening filter banks in the PD input filter modules were indeed switching the correct bits.  I'll next put together a script to confirm that the LSC PD whitening is switching as it should.


  1214   Fri Jan 2 18:49:54 2009 YoichiUpdateLSCLSC modulation frequencies adjusted
I noticed that the IFO did not lock in the MICH configuration.
This was because AS166Q signal was too small.
The demodulation phase seemed not right, i.e. the I-phase signal was larger than Q.
I suspected that the 166MHz modulation frequency was not exactly on the MC FSR, since I just
recovered the number written on the Marconi after the power failure.
I measured the optimal frequency by the method explained in elog:752.
It was 165981500Hz, which is pretty close to the number Rob measured in elog:952, but significantly different from
the label on the Marconi.
I set the frequencies of all the MARCONIs accordingly and updated the labels.

After this, the AS166 demodulation phase was still not good enough (the Q and I signals were about the same).
So I rotated the phase by 45deg. In principle, this should set the demod-phase right for DARM too. Is it correct, Rob ?
I also adjusted the PD offsets. After those adjustments, MICH locks stably with a slightly increased gain (20 as compared to 10 before).
  8729   Wed Jun 19 22:38:15 2013 JenneUpdateComputer Scripts / ProgramsLSC normalization sqrt_mon channels added to conlog


 Something has happened that all of the C1:LSC-dof_NORM_SQRT_ENABLEs are disabled, but normally some are enabled and others are not.

In the hopes that miraculously this change happened after Jamie restarted the conlog this afternoon, I checked the conlog.  These channels, however, were not recorded. 

Using the instructions on the conlog wiki page, I added the _MON channels to the conlog list.  The one snag I hit was that the medm screen referred to in the wiki isn't usable if you open it by hand using the medm gui, since it needs to know what IFO you're at to fill in the macro expansion variables.  To remedy this, I changed the "FE STATUS" button on the sitemap to "CDS", and added the conlog screen to the list of options.  

Now I see that the conlog at least knows about these channels, for future reference.

  9868   Mon Apr 28 13:18:18 2014 JenneUpdateLSCLSC offsets script modified


The weird jumps at the beginning of each TRX peak are due to the triggered switching between the Thorlabs trans PD and the QPD trans PD.  Clearly we need to work on their relative normalizations.  There are also little jumps after each peak as the triggering sends the signal back to the Thorlabs PD.

 I was unhappy with the discontinuities between the Thorlabs and QPD versions of our transmitted light powers.  I realized that in the olden days, we just used the Thorlabs PD, and we set the no-light offset in the LSC version of the TR[x,y] filter banks.  However, now that we have brought the QPDs back, we are setting the dark offsets in the end suspension models, so that the signal chosen by the trigger already has its offset taken care of before we send it to the LSC model. 

Anyhow, having the offsets script try to put a value in the C1:LSC-TR[x,y]_OFFSET was giving us an extra offset and then when we did the normalizations, the numbers came out all wrong.  So.  I have removed the C1:LSC-TR[x,y] filter banks from the offset list, since they were made redundant. 

I have redone the normalizations for both arms (after running the ASS scripts).  I checked by watching the _OUT16 versions of the Thorlabs and QPD diodes before the triggering happens, and as I put offsets into the LSC servos to change the transmitted power, the diodes both change in the same way.  So, we'll have to see if this holds true for more than just values 0-1 the next time we lock, but hopefully it won't need changing for a while.

  4644   Thu May 5 15:33:37 2011 steveConfigurationRF SystemLSC rack

New right angle PVC front panel with SMA bulkhead connectors are in place. The connections are still lose. It is ready for Suresh to finalise his vision on it.

Attachment 1: P1070641.JPG
Attachment 2: P1070639.JPG
  4768   Fri May 27 17:52:53 2011 steveUpdateLSCLSC rack cables strain relieved & labeled

LSC rack 1Y2 cables are strain relieved and labeled. Spare and/or obsolete cables are laid out on the top of the beam tube and on the outside of the rack.

The POY 110 MHZ demodboard has a very touchy position in the VME crate. Watch out for it! It has to be fixed.

  4957   Fri Jul 8 19:50:19 2011 SureshUpdateRF SystemLSC rack channel assignment

[Jamie, Suresh]

   We looked at the ADC channel assignments in the LSC model and wanted to make sure that the LSC rack wiring and the LSC model are in agreement with each other.  So the plan is to wire the rack as shown below.  I will also post this file on svn so that we can keep it updated in case there are changes.




  4540   Mon Apr 18 17:47:41 2011 kiwamuConfigurationLSCLSC rack's ADC cabling

To understand the situation of the ADC cabling at the LSC rack I looked around the rack and the cables.

The final goal of this investigation is to have nice and noise less cables for the ADCs (i.e. non-ribbon cable)

Here is just a report about the current cabling.


(current configuration)

At the moment there is only one ribbon-twisted cable going from 1Y2 to 1Y3. (We are supposed to have 4 cables).

At the 1Y2 rack the cable is connected to an AA board with a 40 pin female IDC connector.

At the 1Y3 rack the cable is connected to an ADC board with a 37 pin female D-sub connector.

The ribbon cable is 28AWG with 0.05" conductor spacing and has 25 twisted pairs (50 wires).



(things to be done)

 - searching for a twisted-shielded cable which can nicely fits to the 40 pin IDC and 37 pin D-sub connectors.

 - estimating how long cable we need and getting the quote from a vendor.

 - designing a strain relief support

  6749   Mon Jun 4 17:14:31 2012 JenneUpdateLSCLSC recompiled several times today

As of now, the regular LSC DoF triggers work, just as they used to.  There is a problem with the filter module triggers that I haven't figured out yet. 

We can't send integers (like control words for the filter banks) through Choice blocks, since those pass doubles by default.  I fixed that by removing the choice block, but the triggering still isn't happening properly.

  4818   Tue Jun 14 18:12:34 2011 Jamie, KiwamuUpdateLSCLSC seems to be fully recovered

We are now locking the arms reliably, with reasonable transmitted power.  We zeroed the LSC offsets with script, since they were apparently not being reset with either the overall burt restore or the arm restore scripts.

We have lost a bit of power through the mode cleaner.  However, we have opted not to tweak it up just yet, so that we don't have to realign to the arms.

  10660   Sat Nov 1 02:13:11 2014 KojiConfigurationLSCLSC settings

I'm leaving the iFO now. It is left with the IR arm mode.

I pretty much messed up LSC configurations for my DRMI locking. If one needs to recover the previous setting, use burtrestore.
I have all records of my LSC settings, so you don't need to preserve it. (Of course we can always use the hourly snapshots
to come back this DRMI setting)


  9308   Tue Oct 29 16:51:31 2013 JenneUpdateCDSLSC test points were used up

Masayuki was concerned that some LSC channels were giving him all zeros.  After seeing the error in the terminal window running dataviewer (it said something like 'daqd overloaded'), I checked the lsc model, and sure enough, all the test points were used.

So, I found an entry by Jamie (elog 8431) where he reminds us how to clear the test points.  I followed the instructions, and now we're seeing real data (not digital zeros) again.

  2111   Sun Oct 18 22:05:40 2009 kiwamuUpdateLSCLSC timing issue

Today I made a measurement to research the LSC timitng issue as mentioned on Oct.16th.


I put the triangular-wave into the OMC side (OMC-LSC_DRIVER_EXT) by AWG,

then looked at the transferred same signal at the LSC side (LSC_DARM_IN1) by using tdsdata.

I have compared these two signals in time domain to check whether they are the same or not.

In the ideal case it is expected that they are exactly the same.


*preliminary result

The measured data are shown in attached fig.1 and 2.

In the fig.1 it looks like they are the same signal.

However in fig.2 which is just magnified plot of fig.1, it shows a time-delay apparently between them.

The delay time is roughly ~50 micro sec.

The surprising is that the LSC signal is going beyond the OMC signal, although the OMC signal drives the LSC !!

We can say it is "negative delay"...

Anyway we can guess that the time stamp or something is wrong.


*next plan

Tomorrow I'm going to measure the transfer-function between them to see the delay more clearly.

( And I would like to fix the delay. )

Attachment 1: rough.png
Attachment 2: detail.png
  2113   Sun Oct 18 23:02:03 2009 KojiUpdateLSCLSC timing issue

You yourself told me that tdsdata uses some downconversion from 32k to 16k!

So, how does the downconversion appears in the measurement?
How does the difference of the sampling rate appears in the measurement?
If you like to understand the delay, you have to dig into the downconversion
issue until you get the EXACT mechanism including the filter coefficients.

AND, is the transfer function the matter now?

As far as the LSC and OMC have some firm relationship, whichever this is phase delay or advance or any kind of filering,
this will not introduce any noise. If so, this is just OK.

In my understanding, the additional noise caused by the clock jitter is the essential problem.
So, did you observe any noise from the data?


*preliminary result

The measured data are shown in attached fig.1 and 2.

In the fig.1 it looks like they are the same signal.

However in fig.2 which is just magnified plot of fig.1, it shows a time-delay apparently between them.

The delay time is roughly ~50 micro sec.

The surprising is that the LSC signal is going beyond the OMC signal, although the OMC signal drives the LSC !!

We can say it is "negative delay"...

Anyway we can guess that the time stamp or something is wrong.


*next plan

Tomorrow I'm going to measure the transfer-function between them to see the delay more clearly.

( And I would like to fix the delay. )


  2122   Mon Oct 19 23:14:32 2009 kiwamuUpdateLSCLSC timing issue

I measured the noise spectrum of LSC_DARM_IN1 and OMC-LSC_DRIVE_EXC by using DTT,

while injecting the sin-wave into the OMC-LSC_DRIVE by AWG.

The attached are the results.

No significant differences appears between OMC and LSC in this measurement.

It means, in this measurement we can not figure out any timing noise which might be in LSC-clock.

In addition there are the noise floor, whose level does not change in each 3-figures. The level is about ~4*10^{-8} count/sqrt[Hz]

(The source of the noise floor is still under research.)

Attachment 1: SPE20Hz.png
Attachment 2: SPE200Hz.png
Attachment 3: SPE2kHz.png
  6735   Thu May 31 23:53:00 2012 JenneUpdateLSCLSC trigger update

I modified the lsc model (after Jamie finished) to use a new triggering scheme.  It HAS NOT yet been compiled and tested, since it's way past time for us to start beatnote-ing.  I will compile, test, debug, etc. tomorrow. Don't compile the LSC model tonight. 

Now we also have (assuming no bugs.....) triggering capability for the filter modules in the filter banks.  Yay!  Testing, etc will commence tomorrow.

  6829   Mon Jun 18 16:23:59 2012 JenneUpdateLockingLSC trigger update

The LSC triggers for the individual filter modules in a filter bank now works.  This is handy so that boosts can come on as soon as a cavity is locked, but will turn off when the cavity unlocks.

You choose which filter modules you want to be triggered, and which ones you want to be manually controlled. 

Example:  LSC-YARM    FM4 and FM5 should always be on, but FM2 and FM3 are controlled by the trigger.  You can set the trigger thresholds for the filter modules independently of the main DoF enable trigger thresholds.

  13921   Wed Jun 6 14:50:25 2018 gautamUpdateGeneralLSC triggering

I though that the "C1LSC_TRIG_MTRX" MEDM screen completely controls the triggring of LSC signals. But today while trying to trigger the X-arm locking servo on AS110 instead of TRX, I found some strange behaviour. Summary of important points:

  1. Even though the servo was supposed to be triggered on AS110, the act of me blocking the beam on the EX table destroyed the lock. I verified the correlation between me blocking the beam and the lock being destroyed by repeating the blocking at least 10 times at different locations along the beam path (to make sure I wasn't accidentally clipping the Oplev beam for example).
  2. Investigating further, I found that me turning off the TRX signal digitally also deterministically led to the X arm lock being lost. To be clear, the TRX DC element in the trigger matrix was 0.
  3. Confirmed that TRX wasn't involved in any way in the locking servo (I was checking for normalization of the PDH error signal by the DC transmission value, but this is not done). To do this, I locked the arm, and then turned all elements corresponding to TRX in the PowNorm matrix to 0. Then I disabled the locking servo and re-enabled it, and the lock was readily re-acquired readily.

All very strange, not sure what's going on here. The simulink model diagram also didn't give me any clues. Need's further investigation.

Attachment 1: LSC_TRIG.png
  4430   Wed Mar 23 09:54:46 2011 steveOmnistructurePhotosLSC visitors

The 40m lab was visited by  ~ 30 LSC members  the end of last week.

Attachment 1: P1070467.JPG
Attachment 2: P1000414.jpg
  8444   Thu Apr 11 11:58:21 2013 JenneUpdateComputersLSC whitening c-code ready

The big hold-up with getting the LSC whitening triggering ready has been a problem with running the c-code on the front end models.  That problem has now been solved (Thanks Alex!), so I can move forward.

The background:

We want the RFPD whitening filters to be OFF while in acquisition mode, but after we lock, we want to turn the analog whitening (and the digital compensation) ON.  The difference between this and the other DoF and filter module triggers is that we must parse the input matrix to see which PD is being used for locking at that time.  It is the c-code that parses this matrix that has been causing trouble.  I have been testing this code on the c1tst.mdl, which runs on the Y-end computer.  Every time I tried to compile and run the c1tst model, the entire Y-end computer would crash.

The solution:

Alex came over to look at things with Jamie and me.  In the 2.5 version of the RCG (which we are still using), there is an optimization flag "-O3" in the make file.  This optimization, while it can make models run a little faster, has been known in the past to cause problems.  Here at the 40m, our make files had an if-statement, so that the c1pem model would compile using the "-O" optimization flag instead, so clearly we had seen the problem here before, probably when Masha was here and running the neural network code on the pem model.  In the RCG 2.6 release, all models are compiled using the "-O" flag.  We tried compiling the c1tst model with this "-O" optimization, and the model started and the computer is just fine.  This solved the problem.

Since we are going to upgrade to RCG 2.6 in the near-ish future anyway, Alex changed our make files so that all models will now compile with the "-O" flagWe should monitor other models when we recompile them, to make sure none of them start running long with the different optimization. 

The future:

Implement LSC whitening triggering!

  4915   Thu Jun 30 00:58:19 2011 KojiSummaryLSCLSC whitening filter test

[Jenne, Koji]

We have tested the LSC whitening filters. In summary, they show the transfer functions mostly as expected (15Hz zerox2, 150Hz pole x2).
Only CH26 (related to the slow channel "C1:LSC-PD9_I2_WhiteGain. VAL NMS", which has PD10I label in MEDM) showed different
phase response. Could it be an anti aliasing filter bypassed???

The 32 transfer functions obtained will be fit and summarized by the ZPK parameters.


The CDS system was used in order to get the transfer functions
- For this purpose, three filter modules ("LSC-XXX_I", "LSC-XXX_Q", "LSC-XXX_DC") were added to c1lsc
in order to allow us to access to the unused ADC channels. Those filter modules have terminated outputs.
The model was built and installed. FB was restarted in order to accomodate the new channels.

- Borrow a channel from ETMY UL coil output mon. Drag the cable from the ETMY rack to the LSC analog rack.
- Use 7 BNC Ts to split the signal in to 8 SMA cables.
- Put those 8 signals into each whitening filter module.

- The excitation signal was injected to C1:SUS-ETMY_ULCOIL_EXC by AWGGUI.
- The transfer functions were measured by DTT.
- The excitation signal was filtered by the filter zpk([150;150],[15;15],1,"n")
   so that the whitened output get flat so as to ensure the S/N of the measurement.

- For the switching, we have connected the CONTEC Binary Output Test board to the BIO adapter module
   in stead of the flat cable from the BIO card. This allow us to switch the individual channels manually.

- The whitening filters of 7 channels were turned on, while the last one is left turned off.
- We believe that the transfer functions are flat and equivalent if the filters are turned off.
- Use the "off" channel as the reference and measure the transfer functions of the other channels.
- This removes the effect of the anti imaging filter at ETMY.

- Once the measurement of the 7 channels are done, switch the role of the channels and take the transfer function for the remaining one channel.


- We found the following channel assignment

  • The ADC channels and the PDs. This was known and just a confirmation. 
  • The ADC channels and the WF filter on MEDM (and name of the slow channel)

- We found that the binary IO cable at the back of the whitening filter module for ADC CH00-CH07 were not connected properly.
This was because the pins of the backplane connector were bent. We fixed the pins and the connector has been properly inserted.

- CH26 (related to the slow channel "C1:LSC-PD9_I2_WhiteGain. VAL NMS", which has PD10I label in MEDM) showed different
phase response from the others although the amplitude response is identical.

Summary of the channel assignment (THEY ARE OBSOLETE - SEPT 20, 2011)

ADC                    Whitening Filter
CH  PD                 name in medm   related slow channel name for gain
00  POY11I             PD1I           C1:LSC-ASPD1_I_WhiteGain. VAL NMS
01  POY11Q             PD1Q          
02  POX11I             PD2I           C1:LSC-SPD1_I_WhiteGain. VAL NMS
03  POX11Q             PD2Q           C1:LSC-SPD1_Q_WhiteGain. VAL NMS
04  REFL11I            PD3I           C1:LSC-POB1_I_WhiteGain. VAL NMS
05  REFL11Q            PD3Q           C1:LSC-POB1_Q_WhiteGain. VAL NMS
06  AS11I              PD4I           C1:LSC-ASPD2_I_WhiteGain. VAL NMS
07  AS11Q              PD4Q           C1:LSC-ASPD2_Q_WhiteGain. VAL NMS
08  AS55I              AS55_I         C1:LSC-ASPD1DC_WhiteGain. VAL NMS
09  AS55Q              AS55_Q         C1:LSC-SPD1DC_WhiteGain. VAL NMS
10  REFL55I            PD3_DC         C1:LSC-POB1DC_WhiteGain. VAL NMS
11  REFL55Q            PD4_DC         C1:LSC-PD4DC_WhiteGain. VAL NMS
12  POP55I             PD5_DC         C1:LSC-PD5DC_WhiteGain. VAL NMS
13  POP55Q             PD7_DC         C1:LSC-PD7DC_WhiteGain. VAL NMS
14  REFL165I           PD9_DC         C1:LSC-PD9DC_WhiteGain. VAL NMS
15  REFL165Q           PD11_DC        C1:LSC-PD11DC_WhiteGain. VAL NMS
16  NC (named XXX_I)   PD5I           C1:LSC-SPD2_I_WhiteGain. VAL NMS
17  NC (named XXX_Q)   PD5Q           C1:LSC-SPD2_Q_WhiteGain. VAL NMS
18  AS165I             PD6I           C1:LSC-SPD3_I_WhiteGain. VAL NMS
19  AS165Q             PD6Q           C1:LSC-SPD3_Q_WhiteGain. VAL NMS
20  REFL33I            PD7I           C1:LSC-POB2_I_WhiteGain. VAL NMS
21  REFL33Q            PD7Q
           C1:LSC-POB2_Q_WhiteGain. VAL NMS
22  POP22I             PD8I
           C1:LSC-ASPD3_I_WhiteGain. VAL NMS
23  POP22Q             PD8Q
           C1:LSC-ASPD3_Q_WhiteGain. VAL NMS
24  POP110I            PD9I
           C1:LSC-PD9_I1_WhiteGain. VAL NMS
25  POP110Q            PD9Q
           C1:LSC-PD9_Q1_WhiteGain. VAL NMS
26  NC (named XXX_DC)  PD10I
          C1:LSC-PD9_I2_WhiteGain. VAL NMS
27  POPDC              PD10Q
          C1:LSC-PD9_Q2_WhiteGain. VAL NMS
28  POYDC              PD11I
          C1:LSC-PD11_I_WhiteGain. VAL NMS
29  POXDC              PD11Q
          C1:LSC-PD11_Q_WhiteGain. VAL NMS
30  REFLDC             PD12I
          C1:LSC-PD12_I_WhiteGain. VAL NMS
31  ASDC               ASDC
           C1:LSC-PD12_Q_WhiteGain. VAL NMS

Attachment 1: chans_24_31_WeirdPhase.pdf
Attachment 2: Octopus.jpg
Attachment 3: Test_Inputs_Plugged_In.jpg
Attachment 4: Contec_Tester_Board.jpg
  4577   Wed Apr 27 21:19:25 2011 kiwamuUpdateLSCLSC whitening for PD1-4

On the back side of 1Y2 rack I found a cable, CAB-1X2-LSC_7, which is supposed to be connected to the whitening filter was disconnected.

I plugged it back and confirmed that the whitening filter is under control of EPICS.

Now all the gain sliders seem to be working because I can change the amplitude of signals with the sliders.



  To check if the gain sliders are working or not, I intentionally disconnected all the inputs to the whitening filter.

Then I brought a gain slider of interest to the maximum. Due to the big gain I was easily able to see noise lying above ADC noise.

Also if the gain slider is 0 dB, which is the minimum value, the spectrum becomes just ADC noise.

In this way I checked all the gain sliders from PD1 to PD4. The picture below is just an example screenshot when I was doing this test.

Note that each filer is designed to have two poles at 150 Hz and two zeros at 15 Hz.


Quote from #4570

While checking whitening filters on the LSC rack, I found some epics controls for the whitening looked not working.

So I powered two crates off : the top one and the bottom one on 1Y3 rack.

These crates contain c1iscaux and c1iscaux2. Then powered them on. But it didn't solve the issue.

ELOG V3.1.3-