40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 173 of 344  Not logged in ELOG logo
ID Date Author Type Category Subject
  8615   Wed May 22 11:35:06 2013 JamieSummaryCDSWeird DAC bit flipping at half integer output values

Quote:

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

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

Quote:

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

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

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

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

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

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

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

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

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

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

nopad.pdf

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

  8612   Wed May 22 00:42:13 2013 KojiSummarySUSviolin Q

While looking at the decay of the violin mode of the PRM, I made a simple measurement of the decay rate.

Error signal: REFL33I

The peak @628Hz became 0.372 to 0.303 in 60 sec.

-> Half life of the amplitude T_{1/2} is 203sec.

Q = 4.53 f0 T_{1/2} = 5.8 x10^5

  8611   Wed May 22 00:08:19 2013 KojiUpdateLSCSensing matrix scripts modified to include actuator calibration

It was too embarassing to see that the actuation frequency was set at the violin mode frequency in order to avoid designing a new filter!?

I ran Jenne's sensing matrix code and the immitated the same result by manual measurement with DTT.
I noticed that the PRM excitation was not transmitted to the mirror. I tracked down the cause and found that
Jenne is using 628Hz which is the notch frequency of the viloing filter.

There is no way we can measure the precise calibration of the error signal exactly at the violin mode frequency.

Nevertheless I waited for the ringdown of the violin mode to the floor level and ran the code again WITH the violin mode filter OFF
at PRM SUS.

The result was stored in the data file

sensematPRM_2013-05-22.12615.dat

The code spit the message at the end

Sensing Matrix, magnitude only, units = cts/meter
 
            MICH          PRCL         
AS55        5.304E+08     1.716E+09     
REFL11      1.732E+13     2.151E+11     
REFL33      1.616E+11     5.384E+09     
REFL55      1.681E+11     6.950E+09

Now I replicated the same measurement with DTT.

MICH or PRCL were excited with the lockin. In order to aviod the violin mode, I shifted the excitation freq by 1Hz. (i.e. 629.125Hz)

The peaks in REFL33I/Q and RFL55I/Q were observed with PSD and TF. The spectrum was measured with the FLATTOP window with the line resolution of 0.1Hz
DTT suggested that this corresponds to the BW of 0.471271Hz if I correctly understood what DTT plot said. We need this information to convert cnt/rtHz to cnt_pk
if we need. For the TF measurements, I needed to find the excitatin monitor but I could not. Therefore, I set the offset of LSC-LOCKIN1_SIG to be 1000,
so that C1:LSC-LOCKIN1_I_IN1 produce the same signal as the excitation.

Note that during the measurement, 628Hz nothces in the LSC servos were on. I confirmed that this provides the reduction of the feedback by a factor of 76.
As the original openloop gain at 629Hz is lower than the unity more than a factor of 2, this was sufficient attenuation to measure the optical gain with the systematic error of less than a %.

MICH excitation (ITMX -1, ITMY +1)
        PSD (cnt/rtHz)   TF Mag    Phase

REFL33I 0.098590         9.5691e-5 74.4344
REFL33Q 0.019294         1.8665e-5 71.1204
REFL55I 0.016123         1.3890e-5 77.3132
REFL55Q 0.157522         1.5285e-4 91.5594

PRCL excitation (PRM +1)
        PSD (cnt/rtHz)   TF Mag    Phase

REFL33I 15.7565          1.5298e-2 -109.727
REFL33Q  0.171648        1.6310e-4 -141.73
REFL55I 16.2834          1.5809e-2 -109.672
REFL55Q  0.634096        6.1012e-4 -143.169

These measurements are saved in the XML files (for DTT) in
/cvs/cds/caltech/users/koji/130521/
as
130521_MICH_EXC.xml and 130521_PRCL_EXC.xml

As the actuator of the PRM/ITMX/ITMY are {19.6, 4.70, 4.66}/f^2 nm/cnt, the optical gains were calculated from the TF measurements.

MICH excitation (ITMX -1, ITMY +1)
        OPTICAL GAIN
(cnt/m)
REFL33I 4.0e9
REFL33Q 7.9e8
REFL55I 5.9e8
REFL55Q 6.5e9

PRCL excitation (PRM +1)
        OPTICAL GAIN

REFL33I 3.1e11
REFL33Q 3.3e9
REFL55I 3.2e11
REFL55Q 1.2e10

These should be compared with the measurement by the script and we get more information from the script (like AS55, REFL11)

  8610   Tue May 21 23:29:57 2013 ManasaUpdateGreen LockingXend Green aligned

X-green and PSL green have been aligned so that they interfere at the beat PD for X.

I haven't scanned the X-end NPRO temperature to find the beat note. I found the earlier elog when this was done (elog 6851) and will use those temperatures to start with.

  8609   Tue May 21 18:22:18 2013 JenneUpdateLSCSensing matrix scripts modified to include actuator calibration

The PRMI sensing matrix scripts have been modified to output a sensing matrix which is calibrated into units of counts/meter.

To run, you should just need to run .../scripts/LSC/runPRMI_SENS.py . 

If it looks like the drive amplitude is not large enough (no nice peak in the photodiode signals), you can increase the drive amplitude, which is line 21 in runPRMI_SENS.py  

  8608   Tue May 21 18:18:28 2013 JamieUpdateComputer Scripts / ProgramsnetGPIB stuff update/modernized/cleanedup/improved

I did a bunch of cleanup work on the netGPIB stuff:

  • Removed extensions from all executable scripts (executables should not have language extensions)
  • fixed execution permissions on executables and modules
  • committed HP8590.py and HP3563A.py instrument modules, which were there but not included in the svn
  • committed NWAG4395A (was AG4395A_Run.py) to svn, and removed old "custom" copies (bad people!)
  • cleaned up, modernized, and fixed the netgpibdata program
  • removed plotting from netgpibdata, since it was only available for one instrument, there's already a separate program to handle it, and it's just plotting the saved data anyway
  • added a netgpibcmd program for sending basic commands to instruments.
  • added a README

Probably the most noticeable change is removing the extensions from the executables.   There seems to be this bad habit around here of adding extensions to executables.  It doesn't matter to the person running the program what language it was written in, so don't add extensions.  It only matters for libraries.

  8607   Tue May 21 18:18:23 2013 ManasaUpdateGreen LockingXend Green aligned

X arm aligned to green.

Aligned the X arm to IR.
Used steering mirrors to align the X end green to the X arm while remaining locked for IR. X arm locks to green stably with GTRX at the PSL table measuring 235uW and corresponds to 2560counts in C!:ALS-TRX_OUT.

Next
1. PSL green alignment.
2. Search for beat note.
3. Resurrect ALS for X arm.

  8606   Tue May 21 17:03:45 2013 SteveUpdateendtable upgradeenclosure tops are sealed

Quote:

 

 I'm planning to remove the ETMY optical table enclosure and move it over to CES Shop 8am Thursday morning.

We'll install spring loaded lathes, hooks and quick release pins.

The bridge will be reinforced with steel plate to support release pins on posts.

There will be an other cut out for cable feedtrough as it is shown on elog #8472

Let me know if this timing does not fit your work.

 The bridge support posts were shimmed today. Surgical tubing 402R - o - rings were glued togeather with " instant krazy glue "

Atm2  Carey CH-3540 latches are compressed ~2.5 mm in the clamped position.

Atm3 is showing the captured quick release pin in the steel reinforced bridge that is supported by the post. It works great. The post screw is sealed by o-ring. The quick-pin is sealed by an epoxy attached copper cap.

Atm4 Enclosure is on it's back. Bottom o-ring can be seen. The hole reinforced bridge structure is visible.

Now I'm working on the window connection to the chamber. I'm very close leak checking this box.

In case of leaking around the top tubing seals we have two options:

a, cut down on the cover rim by 0.040"  or b, increase tubing diameter

Attachment 1: ETMYoptable.jpg
ETMYoptable.jpg
Attachment 2: surgtubclamps.jpg
surgtubclamps.jpg
Attachment 3: quickrelease.jpg
quickrelease.jpg
Attachment 4: reinforcbridge.jpg
reinforcbridge.jpg
  8605   Tue May 21 16:23:06 2013 ManasaUpdateGeneral40MARS wireless network problem RETURNS

Quote:

Here's an example of the total horribleness of what's happening right now:

controls@rossa:~ 0$ ping 192.168.113.222
PING 192.168.113.222 (192.168.113.222) 56(84) bytes of data.
From 192.168.113.215 icmp_seq=2 Destination Host Unreachable
From 192.168.113.215 icmp_seq=3 Destination Host Unreachable
From 192.168.113.215 icmp_seq=4 Destination Host Unreachable
From 192.168.113.215 icmp_seq=5 Destination Host Unreachable
From 192.168.113.215 icmp_seq=6 Destination Host Unreachable
From 192.168.113.215 icmp_seq=7 Destination Host Unreachable
From 192.168.113.215 icmp_seq=9 Destination Host Unreachable
From 192.168.113.215 icmp_seq=10 Destination Host Unreachable
From 192.168.113.215 icmp_seq=11 Destination Host Unreachable
64 bytes from 192.168.113.222: icmp_seq=12 ttl=64 time=10341 ms
64 bytes from 192.168.113.222: icmp_seq=13 ttl=64 time=10335 ms
^C
--- 192.168.113.222 ping statistics ---
35 packets transmitted, 2 received, +9 errors, 94% packet loss, time 34021ms
rtt min/avg/max/mdev = 10335.309/10338.322/10341.336/4.406 ms, pipe 11
controls@rossa:~ 0$ 

Note that 10 SECOND round trip time and 94% packet loss.  That's just beyond stupid.  I have no idea what's going on.

This has not been fixed!

Temporary solution: I ssh'd to nodus from the 40m wifi network and was able to connect to the FE machines.This works but the bandwidth is limited this way as expected.

40m MARS network needs to be fixed.

  8604   Tue May 21 14:50:52 2013 Max HortonUpdate Importing New Code

There was an issue with running the new summary pages, because laldetchar was not included (the website I used for instructions doesn't mention that it is needed for the summary pages).  I figured out how to include it with help from Duncan.  There appear to be other needed dependencies, though.  I have emailed Duncan to ask how these are imported into the code base.  I am making a list of all the packages / dependencies that I needed that weren't included on the website, so this will be easier if/when it has to be done again.

  8603   Tue May 21 14:48:08 2013 JenneUpdateLSCPRMI sensing matrix - not high quality data

The PRMI sensing matrix, as measured last Thursday, in a more readable format:

EDIT: DON'T Look at this yet!  I forgot to calibrate it!  Please hold.....

            PRCL          MICH        
AS55_I      1.228E-01     5.476E-03    
AS55_Q      1.547E-01     1.345E-01    
REFL11_I    9.946E+03     8.106E+01    
REFL11_Q    2.346E+03     2.707E+01    
REFL33_I    9.639E+01     8.717E-01    
REFL33_Q    9.707E-01     6.626E-02    
REFL55_I    1.040E+02     8.464E-01    
REFL55_Q    2.018E+00     5.803E-01

 

Okay, Calibrated, but forgot to include loop compensation (since notches didn't exist yet):

Sensing Matrix, units = cts/meter
 
            MICH          PRCL        
AS55_I      5.024E+08     9.418E+07    
AS55_Q      6.328E+08     2.313E+09    
REFL11_I    4.068E+13     1.394E+12    
REFL11_Q    9.594E+12     4.656E+11    
REFL33_I    3.942E+11     1.499E+10    
REFL33_Q    3.970E+09     1.140E+09    
REFL55_I    4.253E+11     1.456E+10    
REFL55_Q    8.252E+09     9.981E+09

 

  8602   Mon May 20 18:50:22 2013 JenneUpdateLSCKiwamu's sensing matrix measurement script revived

So that I don't have to do loop compensation every time I measure a sensing matrix, I have put (back) in notches into FM10 of all the LSC filter banks, except MC2.  

MICH already had this notch, PRCL and CARM both had it, although it was mislabeled in the filter title as "Notch410" rather than the truth, which is "Notch628". 

The XARM and YARM filter banks were full, since we have not (in those filter banks) combined all of the resonant gains - 3.2Hz, 16Hz, 24Hz - into one module.  I took out a CLP3000 (  cheby1('LowPass",2,3,3000)gain(1.41254)  ) in each of those filter banks, and put in the notch.

I also have changed the band pass filters in the LSC-Lockin#_SIG filter banks to match this new drive frequency.

  8601   Mon May 20 18:47:47 2013 KojiUpdateLSCPRMI sensing matrix - not high quality data

For now forget about the demodulation phase and assume all of the ports are independent.
I want to know the numbers in the following format.

          PRCL     MICH   (unit: cnt/m)
REFL11I:  x.xxxEx x.xxxEx
REFL11Q:  x.xxxEx x.xxxEx
REFL33I:  x.xxxEx x.xxxEx
REFL33Q:  x.xxxEx x.xxxEx
REFL55I:  x.xxxEx x.xxxEx
REFL55Q:  x.xxxEx x.xxxEx
REFL165I: N/A     N/A
REFL165Q: N/A     N/A
AS55I:    x.xxxEx x.xxxEx
AS55Q:    x.xxxEx x.xxxEx

If you really want to resolve the TF phase difference between the I and Q  demod-signals,
you need to look at the transfer functions between the excitation and these ports.
We can't understand what is happening only from the single point measurement.

  8600   Mon May 20 17:49:36 2013 JenneUpdateLSCPRMI sensing matrix - not high quality data

Just so we have some numbers, I did a by-hand analysis of the PRMI sensing matrix numbers I posted here in the elog the other day.  This analysis is ignoring the error bar data.

For each sensor (PD_I or PD_Q), I do loop compensation, since these measurements were taken fairly close to the UGFs of the loops, and notches were not in use at the drive frequency.  To do the loop compensation, I multiply the complex value (lockin_I + i*lockin_Q) by (1-G), where G is the (complex) open loop gain of the degree of freedom I'm shaking.

 When I'm shaking a single degree of freedom (ex. shaking the PRM to get PRCL information), for each PD_I or PD_Q, we get 2 numbers, the lockin_I and lockin_Q values.    I check the phase between the lockin_I and lockin_Q values, since that phase (after loop compensation) should be either 0 or 180, and if it is not, something is wrong. 

Of the 16 sensors I measure (where PD_I and PD_Q count as 2 sensors), 11 sensors had phases more than 20 degrees away from either 0 or 180.  This is not good, and indicates that something is wrong with my measurement.  I suspect that I may not be driving hard enough -  I was using an amplitude 4x smaller than the previous value.  Next time the PRMI is locked, I will turn on the drive oscillation, and ensure that I can see the line in all of the PD signals.

The results of my quickie analysis script:

Bad REFL11_I_MICH phase!  Phase is -82.0185 degrees!
Bad REFL11_Q_MICH phase!  Phase is -35.9697 degrees!
Bad REFL33_I_MICH phase!  Phase is -134.952 degrees!
Bad REFL55_I_MICH phase!  Phase is -79.7997 degrees!
Bad AS55_I_PRCL phase!  Phase is -142.6016 degrees!
Bad AS55_Q_PRCL phase!  Phase is 90.6194 degrees!
Bad REFL11_I_PRCL phase!  Phase is 52.471 degrees!
Bad REFL11_Q_PRCL phase!  Phase is 52.2324 degrees!
Bad REFL33_I_PRCL phase!  Phase is 52.909 degrees!
Bad REFL33_Q_PRCL phase!  Phase is 25.14 degrees!
Bad REFL55_I_PRCL phase!  Phase is 52.8113 degrees!

Sensing Matrix, calculated even though most of the measurement data isn't any good:
AS55: MICH = 0.13502, -1.6122deg.  PRCL = 0.14993, -2.245deg
REFL11: MICH = 29.6373, -2.6365deg.  PRCL = 7376.3206, -2.9098deg
REFL33: MICH = 0.35649, -2.9633deg.  PRCL = 69.5133, -3.1302deg
REFL55: MICH = 0.62084, -2.0261deg.  PRCL = 75.0214, 3.1176deg

Attachment 1: PRMIsensMatQuickAnalysis.m.gz
  8599   Fri May 17 19:56:52 2013 KojiSummaryCDSWeird DAC bit flipping at half integer output values

Let me make a complimentary comment on this effect.

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

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

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

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

  8598   Fri May 17 18:58:58 2013 Jamie, KojiSummaryCDSWeird DAC bit flipping at half integer output values

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

sweep.pdf

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

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

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

const.pdf

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

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

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

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

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

  8597   Fri May 17 18:24:04 2013 AnnalisaUpdate40m upgradingETMY - progress

I aligned the green beam into the Faraday. I needed an HWP to have the right polarization for the light entering the Faraday itself.

I tried to dump as much beams as possible with razor dumps, but eventually I had to use some "temporary solutions" for higher beams, because I didn't find the right mounts for razor dumps.

I measured the beam waist after the Faraday with the beam scan. Analysis and MM calculation to follow.

  8596   Fri May 17 16:06:14 2013 ranaUpdate40m upgradingETMY op table disabled

 

 TODO:

  1. We need to replace all of the floppy anodized Al dumps with clean razor blade dumps on stiff mounts. BOTH of the rejected ports of the 1064 FI need some kind of custom dump.
  2. All of the leakthrough beams of the HR mirrors also need razor dumps. A good rule of thumb is that your first notion of how to implement the beam dump is NOT good enough.
  3. The whole lens / modematching situation for the 1064 and 532 paths will have to be redone so as to put the beam waists inside the Faraday crystal (NOT outside). The beam waist in the 4.7 mm diameter Faraday should be ~0.3-0.4 mm.
  4. The efficiency that we got for the doubling shows that we don't need the cylindrical lenses - they are nice, but not needed to get 90% of the max power.
  5. The lenses between the 1064 FI and the doubler should be put onto a base that can be used to adjust the lens position for MM optimization. Nothing fancy, just something slideable.
  6. For this iteration of the table, we can do as Annalisa has written so as to get the green MM lenses ordered ASAP. After next week we can come up with a new plan before dismantling the EX table.
  8595   Fri May 17 15:38:51 2013 SteveUpdate40m upgradingETMY enclosure is on the way back

 

 It  will arrive around 10 am Monday morning.

 

  8594   Fri May 17 00:32:32 2013 AnnalisaUpdate40m upgradingETMY - progress

[Rana, Annalisa] 

 GREEN

 The alignment for the green has been improved, so that we have much more green power.

The first lens position along the IR path has been changed in way to have the beam waist at the center of the first Faraday. In this way we had about 91% of the input power out from it.

The two cylindrical lenses which were used to correct the ellipticity of the beam have been replaced by a single lens. Its focal length is intermediate between the focal lengths of the two cylindrical. 

Moving the position of the lens before the doubler crystal and improving the alignment we got about 1mW of green light (0.35% of the incoming IR beam).

TO DO

 

After aligning the green beam through the second Faraday, the beam waist of the outgoing beam has to be measured and the mode matching calculation has to be done to choose the two MM lenses. Then the steering mirrors will be placed to send the beam into the arm.

Attachment 1: IMG_0536.JPG
IMG_0536.JPG
  8593   Thu May 16 23:48:39 2013 JenneUpdateLSCKiwamu's sensing matrix measurement script revived

Koji locked the PRMI for me, and I took some data.  I haven't finished figuring out what to do with it / writing a processing script.

Here is the data, in a python dictionary (not for you to read, but so that it's here and you can use it later if you want).

{'AS55_Q': [['ErrorBarData0', '-1.60826e-05', '0.000154774'], ['ErrorBarData1', '-1.61949e-05', '-9.69142e-05'], ['ITMs', '-0.134432', '0.00240338'], ['PRM', '0.0525864', '0.145516']], 'REFL55_Q': [['ErrorBarData0', '-0.00088166', '-0.00294315'], ['ErrorBarData1', '0.00298076', '-0.000466507'], ['ITMs', '-0.573825', '-0.0865747'], ['PRM', '1.94537', '0.534968']], 'REFL33_Q': [['ErrorBarData0', '0.000868208', '0.000785702'], ['ErrorBarData1', '-0.00136268', '-0.000288528'], ['ITMs', '-0.0653009', '-0.0112035'], ['PRM', '0.875275', '0.419765']], 'REFL11_I': [['ErrorBarData0', '-0.147347', '0.136075'], ['ErrorBarData1', '0.351823', '0.160556'], ['ITMs', '-12.0739', '-80.1513'], ['PRM', '6991.11', '7073.74']], 'REFL33_I': [['ErrorBarData0', '-0.00100624', '0.00134366'], ['ErrorBarData1', '0.00373581', '0.000783243'], ['ITMs', '-0.399404', '-0.774793'], ['PRM', '67.4138', '68.8886']], 'REFL11_Q': [['ErrorBarData0', '-0.0173368', '0.0141987'], ['ErrorBarData1', '0.100048', '0.0882165'], ['ITMs', '6.46585', '-26.2841'], ['PRM', '1653.42', '1663.96']], 'AS55_I': [['ErrorBarData0', '-1.87626e-05', '2.24596e-05'], ['ErrorBarData1', '-5.46466e-05', '-2.96552e-07'], ['ITMs', '-0.00531763', '0.00130579'], ['PRM', '-0.100501', '-0.0706334']], 'REFL55_I': [['ErrorBarData0', '-0.000774208', '-5.32631e-05'], ['ErrorBarData1', '0.00347621', '0.0025103'], ['ITMs', '-0.115633', '-0.83847'], ['PRM', '72.8058', '74.2347']]}

The structure is that each sensor has some "error bar" measurements, when there was no drive to any optics (I, then Q of the lockin), and then response to different optics' drives (waiting 20sec after turning on the oscillator before making a measurement, since the lockin has 0.1Hz lowpasses.  ).

The amplitude that Kiwamu had of 4000 cts in the LSC lockin was fine for MICH, but made PRCL unlock, so this data was taken with an amplitude of 1000 counts, at a frequency 283.1030 Hz. 

Since this is only barely above the UGF for both MICH and PRCL loops, I also have OLTF information at 283Hz from DTT:  PRCL mag = -1.05264 dB, phase = 24.6933 deg, MICH mag = -8.50951 dB, phase = 31.3948 deg.

I have started writing a script SensMatAnalysis.py in the scripts/LSC directory to do the analysis, but after having talked to Koji, I need to do more thinking to make sure I know what I'm doing.  Stay tuned for actual analysis later.

  8592   Thu May 16 22:03:16 2013 KojiConfigurationLSCY Green BBPD returned to the PSL table

I borrowed the GTRY BBPD  for the REFL165 trial before.

Now the PD is back on the PSL table.

The PD is intentionally misaligned so that anyone can find it is not aligned.

  8591   Thu May 16 11:50:25 2013 KojiConfigurationElectronicsMeasurement and empirical models of the AI board TFs

Yesterday, I pulled out the AI board for the PRM/BS SUSs. (After the investigation it was restored)

Contrary to our expectation, the board D000186 was not Rev. A but Rev. B.

According to Jay's note in D000186 (for Rev.D), the differences of the Revs are as follows

Rev.A: Initial Release (Analog Biquad version, 4dB 4th order elliptic with notches)
Rev.B: Filter implemented by Freq Devices chip
Rev.C: Differential input version with better RF filtering
Rev.D: 3rd order 0.5dB ripple Cheby with notches at 16K&32K, DB25 input version


I went to the WB EE shop and found bunch of AI filter modules. At least I found one Rev.A and six Rev.D.
I found at least one Rev. C.

I took Rev.A and Rev. D to see the difference of the transfer functions.
Rev.A has more ripple but steeper roll-off. Rev. D is flater at the pass band with slower roll-off.
Rev.D has more phase lag, but it will be fine once the entire frequency response is shifted to x4 high frequency.
The notch frequency of the Rev. D looked right.

I made the empirical pole/zero modeling of the transfer functions.
The LISO models are attached as the ZIP file.
I faced an unexplainable phase behavior at around one the notches for Rev.A.
This may suggest there could have been internal saturation is the stage during the sweep.

More importantly, Rev. D has differential inputs although the connector formfactor is different from the current 40pin IDC.
In fact we should not use Rev.A or Rev.B as they have single end inputs.
Currently the inputs of the AI's for the SUSs are single ended while the DACs are differential.
This means that
1) We waste a half of the DAC range.
2) The negative outputs of the DACs are short-circuited. OMG
3) The ground level fluctuation between the DAC and the SUS rack fluctuates the actual actuation voltage.

Now I am looking at the noise performance of the filters as well as the DAC output noise and range.
I hope we can use Rev.D by replacing the connector heads as this will remove many of the problems we currently have.

Attachment 1: D000186AD_TF.pdf
D000186AD_TF.pdf
Attachment 2: D000186AD_TF.zip
  8590   Thu May 16 08:32:05 2013 SteveUpdate40m upgradingETMY op table disabled

 

All ETMY optical table electronics- lasers-pds turned off, disconnected in order to remove enclosure.

linguaa.jpg

  8589   Thu May 16 04:46:37 2013 JenneUpdateLSCKiwamu's sensing matrix measurement script revived

Kiwamu had an old set of scripts for measuring the sensing matrices, but they were hidden away in ..../scripts/general/kiwamuscripts/pyplant . I have moved them to a more useful place, and updated them.

The useful scripts (the main one is SensResp.py, and the PRMI-specific one, runPRMI_SENS.py, which calls SensResp.py) have been moved to .../scripts/LSC .  I have also created a folder within the LSC scripts folder called SensMatData for the data.

The 2 big changes to Kiwamu's scripts:  The ezca library that he was calling wasn't working.  I switched it over to using the one that Yuta wrote, in ..../scripts/pylibs.  Also, Kiwamu's script was written back during a time where we must have only had one total lockin for the whole LSC model.  Now we have one per PD in the input matrix.  This meant that several of his channel names were wrong.  I have fixed this, and also made it measure all the sensors at once using tdsread of the _OUT16 channels (the OUT16's have some AA action, other EPICS channels don't).

So, now (after you're locked), it shakes one "mirror" (the ITMs are shaken differentially at the same time, as one "mirror"), and reads out all of the RF PD lockin values.  Then it moves to the next mirror.  (For the PRMI case, there are only 2 "mirrors":  The ITM set and the PRM.)  All of the information is stored in a dictionary, which is written to a text file. 

The format of the dictionary is:

{ OPTIC_1: [Photodiode_1, Lockin_I, Lockin_Q], [Photodiode_2, Lockin_I, Lockin_Q], OPTIC_2: [Photodiode_1, Lockin_I, Lockin_Q], [Photodiode_2, Lockin_I, Lockin_Q] }

At this point, I am too tired to actually do a measurement, although next time the PRMI is locked, we should just have to run the runPRMI_SENS.py, and look at the data.  I'm also not quite sure how to extract the information from a dictionary after it has been written to a text file.  This may not be a good way to store data, and I'll ask Jamie about it tomorrow.

OTHER NOTES:

* I need to set up another iteration of the sensing matrix measurement with no drive, measuring several times, to get an estimate of the error in a single measurement.

 

* I had the PRMI locked on AS55Q/REFL33I for more than half an hour.  Then the MC started unlocking semi-regularly.  Seismic was good except for one EQ ~2 hours ago.  After the earthquake (unlocked MC, but no tripped optics), the MC has remained locked.

* The LSC Lockin Overview screen does not click-through to the _SIG individual screens.  We need to fix the path to these screens.

* All of the _SIG filters are band passes around 285 Hz, but the names of the filters all say 238Hz.  I need to fix all 27 of these.

* We can perhaps change the LSCoffsets script someday to use tdsread a few times, and average the results (since the PDs don't have lowpass filters, and we're measuring the offset of the IN1 location, not the OUT).  This way we can hopefully measure all the PDs at once and speed up the script, without having failed tdsavg runs.

  8588   Thu May 16 02:34:38 2013 ranaUpdateComputer Scripts / ProgramsAutoRUN GUI resurrected

We talked about the thing that watches the scripts for autolocking during the meeting today.

I've resurrected the Perl-Tk GUI that we used through i/eLIGO for watching the IFO and running the appropriate scripts. This is not meant to be a replacement for aLIGO stuff, but just something to get us going for now. I expect that we will make some new fanciness which will eclipse this, but I brought it back so that we don't start off with some 'Advanced' system which is worse than the old one.

You can run it from scripts/c1/ by typing ./AutoRUN.pl. It pops up the GUI and starts in a Disabled mode where it watches and does nothing.

I have done some editing of the GUI's code so that it uses caget / caput instead of ezca binaries. New stuff is in the SVN.

Next up is to start testing it and fixing it up so that it uses the thresholds set in the LSC screens rather than some hardcoded values.

Eventually we should also convert all of its daughter scripts from tcsh to bash to keep Jamie's blood pressure in the low hundreds...

Attachment 1: Autorun.png
Autorun.png
  8587   Thu May 16 01:41:31 2013 JenneSummaryIOOFSS gain settings set

Quote:

I'm not sure yet what this points to as the best gain settings.  We can of course explore more of the space.  I'm going to leave it at 13/23.5, which leaves the PC RMS at ~1.5 and the FAST Monitor at ~6.0.

 I changed the value of the nominal FSS common gain in the PSL Settings screen (It's called the 'FSS global gain' there).  To get to this screen:  sitemap -> PSL_main -> PSL_settings.  The MC autolocker reads these settings from the screen and uses those values.  Now the FSS returns to this value of 13 that Jamie has chosen.  For the past few days, it's been going back to the old value of 10.1 .  The FAST gain was already set to this 23.5 value.

  8586   Wed May 15 23:38:04 2013 ranaUpdateelogcategories trimmed

I deleted a bunch of useless categories from the 40m elogd.cfg file. IF you find your category has been deleted, you can now learn how to categorize yourself into the existing categories. ELOG restarted and log file zeroed.

  8585   Wed May 15 22:47:11 2013 JamieSummaryCDSAccounting of ADC/DAC channel availability

Quote:
  1. What are we using 16 DAC channels for in the LSC?

For the new input and output tip-tilts.  Two input, two output, each requires four channels.

Quote:
  1. What are the functions of those IOO DAC channels which go to cross-connects? If they're not properly sending, then we may have malfunctioning MC or MCWFS.

I have no idea.  I don't know what the hardware is, or is supposed to be, connected to.  DAC for WFS??  Was there at some point supposed to be fast output channels in the PSL?

Quote:
  1. Can we just use the SLOW DAC (4116) for the ALS PZTs? We used this for a long time for the input steering and it was OK (but not perfect).

 Probably. I'm not as familiar with that system.  I don't know what the availability of hardware channels is there.  I'll investigate tomorrow.

  8584   Wed May 15 21:27:39 2013 AnnalisaUpdate40m UpgradingEndtable upgrade for auxiliary green laser : progress

 

GREEN

I still have problems in maximizing the power out from the doubler. I realized that the real green power I obtain is about 30 uW, and it is the power which really enters the Faraday.

Before I was measuring it just after the Harmonic separator, and there was some residual IR beam which increased the power on the power meter, that's why I obtained about 200 uW.

I also tried to slightly vary the position of the mode matching lens, but I was not able to get more than 30 uW on the power meter.

TRANSMON PATH

The 50 cm focal length lens has been added in the position shown on Manasa's layout, and the beam has been focused on the PD.

 

 

  8583   Wed May 15 19:32:04 2013 ranaSummaryCDSAccounting of ADC/DAC channel availability
  1. What are we using 16 DAC channels for in the LSC?
  2. What are the functions of those IOO DAC channels which go to cross-connects? If they're not properly sending, then we may have malfunctioning MC or MCWFS.
  3. Can we just use the SLOW DAC (4116) for the ALS PZTs? We used this for a long time for the input steering and it was OK (but not perfect).
  8582   Wed May 15 17:48:25 2013 JamieUpdateCDSmisc problems noticed in models

I noticed a couple potential issues in some of the models while I was investigating the ADC/DAC situation:

c1ioo links to ADC1, but there are broken links to the bus selector that is supposed to be pulling out channels to go into the PSL block.  They're pulling channels from ADC0, which it's not connected to, which means these connections are broken.  I don't know if this means the current situation is broken, or if the model was changed but not recompiled, or what.  But it needs to be fixed.

c1scy connects ADC_0_11, label "ALS_PZT", to an EpicsOutput called "ALS_LASER_TEMP", which means the exposed channel is called "C1:SCY-ALS_LASER_TEMP".  This is almost certainly not what we want.  I don't know why it was done this way, but it probably needs to be fixed.  If we need and EPICS record for this channel it should come from the ALS library part, so it gets the correct name and is available from both ends.

  8581   Wed May 15 17:38:49 2013 JamieSummaryCDSAA/AI requirements

Quote:

What this means:

  • We definitely have enough DACs for the ALS PZTs.  The free channels are also in the right places: at the end stations and in the c1ioo FE, which is close to the PSL and hosts the c1als controller.
  • We appear to have enough ADCs for the QPD in c1ioo.
  • We don't have any available DAC outputs in c1lsc for the Fibox.  If we can move the Fibox to the IOO racks (1X1, 1X2) then we could send LSC channels to c1ioo and use c1ioo's extra DAC channels.

Of course we'll have to investigate the AA/AI situation as well.  I'll try to asses that in a follow up post.

It looks like we have spare channels in the AA chassis for the existing c1ioo ADC inputs to accommodate the POP QPD. 

We need AI interfaces for the ALS PZTs.  What we ideally need is 3x D000186, which are the eurocard AI boards that have the flat IDC input connects that can come straight from the DAC break-out interfaces.  I'm not finding any in the spares in the spare electronics shelves, though.   If we can't find any we'll have to make our own AI interfaces.

  8580   Wed May 15 17:17:05 2013 JamieSummaryCDSAccounting of ADC/DAC channel availability

We need ADC and DAC channels for a couple of things:

  • POP QPD: 3x ADC
  • ALS PZTs: 3x 2x 2x DAC (three pairs of PZTs, at ends and vertex, each with two channels for pitch and yaw)
  • Fibox: 1x DAC

What's being used:

  • c1iscex/c1iscey:
    • DAC_0:   7/16 = 9 free
    • ADC_0: 17/32 = 15 free
  • c1sus:
    • DAC: ?
    • ADC: ?
  • c1ioo
    • DAC_0:   0/16 = 16 free ?? This one is weird. DAC in IO chassis, half it's channels connected to cross connect (going ???), but no model links to it
    • ADC_0: 23/32 = 9 free
    • ADC_1:  8/32 = 24 free
  • c1lsc
    • DAC_0: 16/26 = 0 free
    • ADC_0: 32/32 = 0 free

What this means:

  • We definitely have enough DACs for the ALS PZTs.  The free channels are also in the right places: at the end stations and in the c1ioo FE, which is close to the PSL and hosts the c1als controller.
  • We appear to have enough ADCs for the QPD in c1ioo.
  • We don't have any available DAC outputs in c1lsc for the Fibox.  If we can move the Fibox to the IOO racks (1X1, 1X2) then we could send LSC channels to c1ioo and use c1ioo's extra DAC channels.

Of course we'll have to investigate the AA/AI situation as well.  I'll try to asses that in a follow up post.

PS: this helps to identify used ADC channels in models:

grep adc_ sus/c1/models/c1scx.mdl | grep Name | awk '{print $2}' | sort | uniq

 

  8579   Wed May 15 15:33:49 2013 SteveUpdateGeneralOn-Track QPD

I tested On-Track (from LLO) OT 301  amp with PSM2-10 qpd. It was responding. Jenne will calibrate it.  The 12V DC ps input is unipolar.

The one AC to DC adapter that Jenne tried was broken.

  8578   Wed May 15 08:29:28 2013 SteveConfigurationRF Systemfiber protection at splitter box area

 I positioned the fiber loaded protecting tubing and anchored them so they can do their job.

However, the area needs a good clean up.

 

Attachment 1: fiberprotect.jpg
fiberprotect.jpg
  8577   Wed May 15 00:45:28 2013 ranaConfigurationLSCOpenloop gain for PRMI lock May 13

 

 Pfft. Why 500 usec delay? We should be using the known parameters for the hardware and software AA/AI.

  8576   Tue May 14 21:03:15 2013 AnnalisaUpdate40m UpgradingEndtable upgrade for auxiliary green laser : progress

 

GREEN

The new lenses arrived, and I put the right 250mm before the doubler. I'm still not so confident with the alignment, because I cannot get more than 11-12 uW out from the "green" Faraday, with more than 200uW going in.

TRANSMON

I replaced the Y1 mirror with an HR1064-HT532. The alignment has to be done. Today the 50cm focal length lens arrived, and I'm going to put in tomorrow.

 

  8575   Tue May 14 20:30:29 2013 JamieSummaryIOOMC error spectrum at various FSS gain settings.

I used the Agilent 4395A and the GPIB network bridge to measure the MC error spectrum at the MC servo board.

I looked at various settings of the FSS Common and FAST gains.

Here is the spectrum of various Common gain settings, with a fixed FAST setting of 23.5:

f23.5.pdf

The peak at 34k is smallest at the largest Common gain setting of 13.0 (probably expected).  The other higher frequency peaks are higher, though, such as the ones at 24.7k, 29.6k, 34.5k, etc.:

f23.5z1.pdf

Here's a blow up of the peak at 1.06M, which peaks at about 9dB of common gain:

f23.5z2.pdf

 Here's the spectrum with a fixed Common gain of 10.5, and various FAST gains:

c10.5.pdf

and here's a zoom around that 1.06 MHz peak, which is smallest at a FAST gain of 23.5 dB:

c10.5z1.pdf

I'm not sure yet what this points to as the best gain settings.  We can of course explore more of the space.  I'm going to leave it at 13/23.5, which leaves the PC RMS at ~1.5 and the FAST Monitor at ~6.0.

If this does turn out to be a good setting we'll need to adjust some of the alarm levels.

Various settings:

MCS
  in1 gain: 15
  offset: 1.174
  boost enabled
  super boost: 2
  VCO gain: 25

FSS:
  input offset: -0.8537
  slow actuator: 0.6304

I include the python scripts I used to remotely control the AG4395 to take the measurements, and make the plots.

PS: I made some changes/improvements to the netgpib stuff that I'll cleanup and commit tomorrow.

 

Attachment 6: getdata
#!/usr/bin/env python

import os
import sys
import time
import numpy as np
sys.path.append('/opt/rtcds/caltech/c1/scripts/pylibs/')
import pyezcalib as ca
sys.path.append('/opt/rtcds/caltech/c1/scripts/general/netgpibdata/')
import netgpib
... 64 more lines ...
Attachment 7: plot
#!/usr/bin/env python

import os
#import numpy as np
from pylab import *

#name = sys.argv[1]

#atten = 10 # 10dB

... 31 more lines ...
  8574   Tue May 14 20:27:19 2013 KojiConfigurationLSCOpenloop gain for PRMI lock May 13

The OLTFs for PRCL and MICH for the last night's lock were modelled using Yuta's python script.

Attachment 1: LSCPRCLOLTF.png
LSCPRCLOLTF.png
Attachment 2: LSCMICHOLTF.png
LSCMICHOLTF.png
Attachment 3: 130513.zip
  8573   Tue May 14 19:52:58 2013 RijuConfigurationRF SystemPD frequency response

 [Eric, Riju, Annalisa]

Today we have cleared up the fiber spool near AP table. We have put the 1x16 fiber splitter and a box (we made two openings on it) for fiber spool on a different part of the rack. Also put a plastic tubing or the fibers coming out of AP table. Now the fibers coming out from AP table and also from POX table first enter the box through one opening and the end of the fibers come out of the other opening to get connected to to splitter. Photographs of the work are attached. I don't think enough fiber is there to make a similar loop for fiber coming from POY table.

 

 

Attachment 1: IMG_0520.JPG
IMG_0520.JPG
Attachment 2: IMG_0521.JPG
IMG_0521.JPG
  8572   Tue May 14 16:14:47 2013 Max HortonUpdateSummary PagesImporting New Code

I have figured out all the issues, and successfully installed the new versions of the LAL software.  I am now going to get the summary pages set up using the new code.

  8571   Tue May 14 14:24:56 2013 SteveUpdate40m Upgradingenclosure removal

 

 I'm planning to remove the ETMY optical table enclosure and move it over to CES Shop 8am Thursday morning.

We'll install spring loaded lathes, hooks and quick release pins.

The bridge will be reinforced with steel plate to support release pins on posts.

There will be an other cut out for cable feedtrough as it is shown on elog #8472

Let me know if this timing does not fit your work.

  8570   Tue May 14 02:19:13 2013 KojiUpdateGreen LockingXend Green tweaked

Note that I'm supposed to return one of the two green beat PDs and the power supply.
They are on the REFL path. I'll work on the restoration of the beat configuration.

  8569   Tue May 14 01:56:20 2013 JenneUpdateGreen LockingXend Green tweaked

I locked the Xarm on green.  At the PSL table, I adjusted the steering mirror to get the beam centered on the GTRX DC PD.  We need a lens for this, and presumably for the GTRY as well. 

I then went down to the Xend, and adjusted the steering mirrors to maximize the transmitted green power.  I got as high as 2150 counts.

Either the alignment is particularly delicate, or something isn't quite right, but when I put the lid back on the optical table's box, the arm will no longer lock on the 00 mode.  It's pretty typical that the cavity will unlock while you put on the lid, but usually if you bang on the underside of the table, or toggle the green shutter, you'll get back to the 00 mode.  Tonight however, I can't get the 00 mode if the lid is on.  If I slide the lid off just enough to get my hand inside, then block the green beam with my hand, I immediately lock on the 00 mode.  Even if I gently slide the lid back on, I unlock the cavity, and with the lid on can't get better than a 01 mode in yaw.  I repeated this a few times, with the same result. 

A goal for the next few days:  Re-find the Xgreen beatnote.  Once we have the PRMI locking stably and reliably, we want to move on to PRFPMI.   

  8568   Tue May 14 01:13:35 2013 JenneUpdate40m UpgradingTRY realigned

Koji noticed that earlier this afternoon the Yarm ASS was working, but then after dinner it was no longer working.  I saw that the ETMY trans camera beam was clipped.  These things precipitated a visit to the Yend station. 

I saw that the beam on the optic that steers the camera beam to the camera was very, very low, almost falling off the optic.  The only mirror which steers to this optic is the harmonic separator which reflects the IR, and transmits the green.  I turned the pitch knobs on the harmonic separator until the beam was roughly centered on all 3 optics between the separator and the camera (BS to QPD, BS to TRYDC and Y1 for camera).  The yaw was fine, so I didn't touch it.

I then adjusted the steering mirror to the camera, and the BS pointing to the DC PD.  I have not touched the BS pointing to the QPD.  Once the beam was on the TRY PD, Koji ran the ASS script, and I recentered the beam on the DC PD.  During this time, Koji had the Yarm triggering using -1 in the POYDC element of the matrix.

The harmonic separator is not mounted in a nice way (I'm assuming that Annalisa is in the middle of things, and she'll get back to it after the green work), so the TRY PD and camera will need to be aligned again, so I didn't do any ASS-recentering-ASS iteration tonight.

The Yarm ASS works nicely again, getting TRY to ~0.89 . 

  8567   Mon May 13 23:05:51 2013 JenneUpdatePEMGUR1 masses recentered

[Evan, Jenne]

Evan brought the Guralp handheld readout paddle and cables back from the ATF (Zach is using GUR2 and one of the T240s for gyro stuff this week), and we recentered the GUR1 masses.  N/S and Vert were okay (within 0.1 V), but E/W was at -0.5 V, so we set it at zero.  We then plugged the Guralp back in, and turned on the readout box.

There isn't much of a change on the BLRMS on the wall, so it's possible that we weren't actually having any trouble anyway. 

  8566   Mon May 13 23:05:26 2013 KojiConfigurationLSCPRMI locking

- Disabled MCL path in mcdown/mcupscript.

Nominal gain in mcdown/mcup was -50 and -100 respectively.

- Confirmed the stable lock was just because of the quiet seismic of the Friday night.

- Improvement of the PRM ASC servo
RG3.2 (3.2Hz Q=2 Height 30dB)
=>
RG3.2 (3.2Hz Q=10 Height 30dB) +  zero[f, 1, .5] pole[f, 2, 3] zero[f, 4.5, .5] pole[f, 3.5, 3]

Filter shape comparison is found in the second plot attached.

The resulting spectra (freerun vs controlled) is found in the first plot.

Nominal PRM ASC gain is +70

- Openloop TF measurement

OLTF PRCL 250Hz 30deg / MICH 200Hz 45deg

- REFL55/REFL33 phase adjustment (in lock)

REFL55 phase fine tune (95.25deg) (x1,x0.3)
REFL33 phase (-13.0deg) (x1, x2)

Attachment 1: 130513_PRC_ASC.pdf
130513_PRC_ASC.pdf
Attachment 2: 130513_PRC_ASC_servo.pdf
130513_PRC_ASC_servo.pdf
ELOG V3.1.3-