I've finished, for now, the CDS network tests that I was conducting.  Everything should be back to normal.

What I did:

I wanted to see if I could make the EPICS glitches we've been seeing go away if I unplugged everything from the CDS martian switch in 1X6 except for:

• fb
• fb1
• chiara
• all the front end machines

What I unplugged were things like megatron, nodus, the slow computers, etc.  The control room workstations were still connected, so that I could monitor.

I then used StripTool to plot the output of a front end oscillator that I had set up to generate a 0.1 Hz sine wave (see elog 11662).  The slow sine wave makes it easy to see the glitches, which show up as flatlines in the trace.

More tests are needed, but there was evidence that unplugging all the extra stuff from the switch did make the EPICS glitches go away.  During the duration of the test I did not see any EPICS glitches.  Once I plugged everything back in, I started to see them again.  However, I'm currently not seeing many glitches (with everything plugged back in) so I'm not sure what that means.  I think more tests are needed.  If unplugging everything did help, we still need to figure out which machine is the culprit.

Here's an example of the glitches we've been seeing, as seen in the StripTool trace of the front end oscillator:

You can clearly see the glitch at around T = -18.  Obviously during non-glitch times the sine wave is nice and cleanish (there are still the very small discretisation from the EPICS sample times).

I'm about to start conducting some tests on the CDS network.  Things will probably be offline for a bit.  Will post when things are back to normal.

I've installed Control System Studio (CSS) on pianosa, from the version 3.0.2 Red Hat binary zip.  It should be available as "css" from the command line.

CSS is a new MEDM replacement. It's output is .opi files, instead of .adl files.  It's supposed to include some sort of converter, but I didn't play with it enough to figure it out.

Please play around with it and let me know if there are any issues.

links:

• http://cs-studio.sourceforge.net/docbook/
• http://sourceforge.net/apps/trac/cs-studio
• http://ics-web.sns.ornl.gov/css/updates/apps/epics_css_3.0.2-linux.gtk.x86_64.zip

 So far I've only given it about half an hour of my time, but it is *really* frustrating so far.  There don't seem to be any instructions on how to tell it what our channels are / how to link CSS to our EPICS databases.  Or, the instructions that are there say "do it!", but they neglect to mention how...  Also, there exists (maybe?) an ADL->BOY converter, but I can't find any buttons to click, or how to import an .adl, or what I'm supposed to do.  Also, it's not clear how to get to the editor to start making screens from scratch. 

It looks like it has lots of nifty indicators and buttons, but I would have felt better if I had been able to do anything.

Another thing that is going to be a problem:  the Shell Command button that we use all over the place in our MEDM screens is not supported by this program.  It's listed in the "limitations" of the ADL2BOY converter.  This may kill the CSS program immediately.  Jamie: did Rolf/anyone mention a game plan for this?  It's super nice to be able to run scripts from the screens.

Moral of the story:  I'm annoyed, and going to continue making my OAF screens in MEDM for now.

How to run/use CSS/BOY

(PREPARATION)

0) Everything runs on pianosa for now.

1) type css to launch CSS IDE.

2) You may want to create your own project folder as generally everything happens below this folder.

=== How to make a new project ===
- Right-click on tree view of Navigator pane
- You are asked to select a wizard. Select "General -> Project". Click "Next".
- Type in an appropriate project name (like KOJI). Click "Finish"
- The actual location of the project is /home/controls/CSS-Workspaces/Default/KOJI/ in the above example

(PLAY WITH "Data Browser", THE STRIPTOOL ALTERNATIVE)

1) Select the menu "CSS -> Trends -> Data Browser". A new data browser window appears.

2) Right-click on the data browser window. Select the menu "Add PV". Type in the channel name (e.g. "C1:LSC-ASDC_OUT16")

3) Once the plot configuration is completed, it can be saved as a template. Select the menu "File -> Save" and put it in your project folder.

4) Everything else is relatively straightforward. You can add multiple channels. Log scaling is also available.
I still don't find how to split the vertical axis to make a stacked charts, but I don't surprise even if it is not available.

(HOW TO MAKE A NEW "BOY" SCREEN)

0) Simply to say BOY is the alternative of MEDM. The screen file of BOY is named as  "*.opi" similar to "*.adl" for MEDM.

1) To create a new opi file, right-click on the navigator tree and select the menu "New -> Other".

2) You are asked to select a wizard. Select "BOY -> OPI file" and click "Next".

3) Type in the name of the opi file. Also select the location of the file in the project tree. Click "Finish".

4) Now you are in OPI EDITOR. Place your widgets as you like.

5) To test the OPI screen, push the green round button at the top right. The short cut key is  "CTRL-G".

(HOW TO EDIT AN EXISTING OPI FILE)

1) Right click an OPI file in the navigator tree. Select the menu "Open WIth -> OPI Editor". That's it.

(HOW TO CONVERT AN EXISTING ADL FILE INTO OPI FILE)

1) You need to copy your ADL file into your project folder. In this example, it is /home/controls/CSS-Workspaces/Default/KOJI/

2) Once the ADL file is in the project folder, it should appear in the navigator tree. If not, right-click the navigator pane and select "Refresh".

3) Make sure "ADL Parser" button at the left top part is selected, although this has no essential function.
This button just changes the window layout and does nothing. But the ADL Tree View pane would be interesting to see.

3) If you select the ADL file by clicking it,the tree structure of the ADL file is automatically interpreted and appears in the ADL Tree View pane.
But it is just a display and does nothing.

4) Right-click the ADL file in the navigator pane. Now you can see the new menu "BOY". Select "BOY -> Convert ADL File to OPI".

5) Now you get the opi version of that file.
The conversion is not perfect as we can imagine. It works fine for the simple screens. (e.g. matrix screens)
But the filter module screens get wierd. And the new LSC screen did not work properly (maybe too heavy?)

(HOW TO RUN OUR SHELL/PERL/PYTHON SCRIPTS FROM BOY)

CSS has javascript/python scripting capability.
I suspect that we can make a wrapper to run external commands from python script although it is not obvious yet.

 Previously in elog 8959, I gave a very simple method for determining the noise suppression behavior of the ISS. Recently, I recalculated this requirement in a more correct fashion and again redesigned the ISS to be used in the CTN experiment.

• Determining the Requirement

Just as before, the data from PSL elog 1270 is necessary to infer a noise suppression requirement. The data presented there by Evan consists of two noise spectra, 1) the unstabilized RIN presently observed in the CTN experiment readout and 2) the theoretical brownian noise produced by thermal processes in the mirror coating+substrate. The statement "TF_mag = (Unstabilized RIN) / (Calculated Brownian Noise Limit)", where TF_mag refers to the required open-loop gain of the ISS, is actually a first order approximation of the 'required' noise suppression. In fact if we wanted the laser noise to be suppressed below the calculated brownian noise level, it is more correct to say 

        Closed-loop ISS gain = (Calculated Brownian Noise Limit) / (Unstabilized RIN)

As this essentially gives a noise suppression spectrum i.e. a closed-loop gain in linear control theory. Below is a very simple block diagram showing how the ISS fits into the CTN experiment. The F(f) block represents my full servo board.

Some of the relevant quantities involved:

So looking at the block diagram, our full closed-loop transfer function is given by,

So then to determine the required F(f), i.e. the required transfer function for my servo, we consider the expression 

The plant transfer function is simply Plant = (C(f) * a * P * A) ~ 0.014 V/V, where I have ignored the cavity pole around 97 kHz as our open-loop transfer function ends up crossing unity gain around 10 kHz. In the above, I have included what I call a 'safety factor' of 10. Essentially, I want to design my servo such that it suppresses noise well beyond what is actually required so that we can be sure noise contributions to experiment readouts are not significantly influenced by the laser intensity noise.

• Proposed Servo Design

Using the data Evan reported for the brownian noise and free-running RIN, I came up with an F(f) to the meet the requirement as shown below.

 Where the blue curve includes the safety factor mentioned before. This plot just demonstrates that using my modular ISS design, I can meet the given noise suppression requirements.

To be complete, I'll say a little more about the final design.  As usual, the servo consists of three stages. The first is the usual LP filter that is always 'on' when the ISS loop is closed. The boosts I have chosen to use consist of an integrator with a single zero and a filter that looks somewhat like a de-whitening filter. The simulated open-loop transfer functions are shown below.

 In PSL elog 1270, Evan elucidated the explicit requirements for the CTN ISS board. Essentially, the transfer function of the ISS should be something like:

     TF_mag = (Unstabilized RIN) / (Calculated RIN Requirement)

I took Evan's data and did exactly this. I then designed a servo (using the general design I proposed here) to meet this requirement with a safety factor of ~10. By safety factor, I mean that if the ISS operates exactly according to theory, it should suppress the noise by a factor of 10 more than what is necessary/set out by the requirement. Below is a plot of the loop gain obtained directly from the requirement (the above expression for TF_mag) and the transfer function of the servo I am proposing.

I don't have the actual schematics attached as I was working with a LISO file and have yet to update the corresponding Altium schematic. The LISO file is attached and I will add the schematics later, although one can reference the second link to find a simple drawing.

I goofed on the transfer function requirement by not giving you the plant transfer function, which looks to be about 0.014 V/V, independent of frequency (PSL:1278). This needs to be compensated for in the electronic transfer function.

Following the circuit design in elog 8748, I constructed a prototype for the servo portion of the ISS (not including the differential amp) to be used in the CTN experiment. The device was built on a breadboard and its transfer function was measured with the Swept Sine measurement group of an SR785. For various excitation amplitudes, the transfer function (TF) was not consistent.

Recall the ideal transfer function for this particular servo and consider the following comparisons.

• The unity gain frequency is consistent, and the measured TFs all exhibit some amount of 1/f behavior up to this point, but there is no zero around f~10^3 and individual low-frequency poles/zeros are not visible.
• For each of the inputs, there is a feature that is not exhibited in the ideal TF. We see a large drop in gain a little past 10^3 Hz for a 100mV input, just past 10^2 Hz for a 10 mV input and around 10^1 Hz for a 1 mV input.
• The ideal TF also goes as 1/f for f < 10 Hz, so I believe the low-frequency behavior of each of the above transfer functions is simply a physical limitation of the breadboard or the SR785, although I don't think this is caused by the circuit elements themselves. I used OP27 op-amps in the prototype as opposed to AD829 op-amps which are must faster and end up amplifying noise. To ensure that these op-amps were not the source of the gain limitation, I also tried using AD829 op-amps. The resulting transfer functions are shown below.
• Both the frequency at which we see the anomalous feature and the maximum gain increase nearly proportional to the increasing input excitation amplitude.

This gain limitation is problematic for characterizing prototypes as my particular servo has very large gain at low frequencies. 

At the risk of looking too deeply into the above data,

• It appears there is a slight change in slope around f ~ 10^3 Hz which would be consistent with the ideal TF.
• For f > 10^3 Hz, one can easily see the TF goes as 1/f. The slope for f < 10^3 Hz is not as clear, although it obviously does not show 1/f^2 behavior as we would expect from the ideal TF.
• We see the same gain limitation around G ~ 55 as we did with OP27 op-amps.

Unfortunately, the noise was too large for lower excitation amplitudes to be used to any effect. I'll try this again tomorrow, just as a sanity check, but otherwise I will proceed with learning Altium and drawing up schematics for this servo.

As I showed in [elog 8759], measuring the transfer function of my prototype servo was difficult due to physical limitations of either some portion of the construction or even the SR785 itself. To get around this, I tried using lower input excitation amplitudes, but ran into problems with noise.

Finding a TF consistent with theoretical predictions made by LISO was easy enough when I simply measured the TF of each of the two filter stages individually and then multiplied them to obtain the TF for the full servo. I still noticed some amount of gain limitation for 100 mV and 10 mV inputs, although I only had to lower the input to 5 mV to avoid this and thus did not see significant amounts of noise as I did with a 1 mV input. The individual transfer functions for each stage are shown below. Note that the SR785 has an upper cutoff frequency of 100 kHz so I could analyze the TF beyond this frequency. Additionally, the limited Gain Bandwidth Product of OP27 op-amps (used in the prototype) causes the magnitude and phase to drop off for f > 10^5 Hz approximately. The actual servo will use AD829 op-amps which have a much larger GBWP.

The measured TFs above are very close to ideal and agree quite well with theoretical predictions. Based on the [circuit schematics],

• Stage 1 should have Gain ~ 10^3 until the pole at f ~ 10 Hz  
• Stage 2 should exhibit a DC pole, a zero at f ~ 10^3 Hz and then unity gain for f > 10^3 Hz

Indeed, this is exactly what we can see from the above two TFs. We can also multiply the magnitudes and add the phases (full_phase = phase1 + phase2 - 180) to find the TF for the full servo and compare that to the ideal TF produced by LISO,

And we find exceptionally consistent transfer functions, which speaks to the functionality of my prototype 

As such, I'll proceed with designing this servo in Altium (most of which will be learning how to use the software)

Note that all TFs were taken using the netgpibdata python module. Measurement parameters were entered remotely using the TFSR785.py function (via control room computers) and following the examples on the 40m Wiki.

Four new 2" CVI 50/50 beamsplitters (2 for p-pol and 2 for s-pol) were delivered. They have been stored in the optics cabinet, along with the "Test Data" sheets from CVI.

 I routed cables (RG405 SMA-SMA) from several demodulator boards in rack 1Y2 to the RF Switch in rack 1Y1 using the overhead track. Our switch chassis contains two 8x1 switches. The COM of the "right" switch goes to channel 7 of the "left" switch to effectively form a 16x1 switch. The following is a table of correspondences between PD and RF Switch input.

ThePOP110 demod board has not yet had a cable routed from it to the switch because I ran out of RG405.

We should also consider how important it is to include MCREFL in our setup. Doing so would require fabrication of a ~70 ft RG405 cable. 

I found this very interesting German maker of cool cable cutting tools. It's called Jokari.

We should keep it as a reference for the future if we want to buy something like that, ie RF coax cable cutting knives.

http://www.jokari.de/en.htm

Yeah, this looks nice.

And I also like to have something I have attached. This is "HOZAN P-90", but we should investigate American ones
so that we can cut the wires classified by AWG.

Having finished labeling the existing cables to match their new names, we (Steve, Kiwamu and Larisa) moved on to start laying new cables and labeling them according to the list.

Newly laid cables include: ETMXT (235'), ETMX (235'), POP (110') and MC2 (105').  All were checked by connecting a camera to a monitor and checking the clarity of the resulting image. Note that these cables were only laid, so they are not plugged in.

The MC2 cable needs to be ~10' longer; it won't reach to where it's supposed to. It is currently still in its place. 

The three other cables were all a lot longer than necessary.

[Steve, Suresh, Kiwamu, Larisa]

Only the PRM/BS cable was laid today.

In one of the previous updates on cable laying, it was noted that the MC2 cable needed an additional 10' and the MC2T needed an additional 15' to reach their destinations.  We cut and put BNC ends on 10' and 15' cables and connected them to the original cables in order to make them long enough.

This concludes the laying of new cables. Suresh is currently working on the QUADs...

The video work has crossed a milestone.    

Kiwamu and Steve have shifted the three quads from the control room to the Video MUX rack (1Y1) and have wired them to the MUX.

The monitors in the control room have been repositioned and renumbered.  They are now connected directly to the MUX. 

Please see the new cable list for the input and output channels on the MUX.

As of today, all cables according the new plan are in place.  Their status   indicated on the wiki page above is not verified .  Please ignore that column for now, we will be updating that soon.

I shifted the MC1F/MC3F camera and the MC2F cameras onto the new cables.  Also connected the monitors at the BS chamber and end of the X arm to their respective cables.  I have removed the RG58B BNC (black) cables running from MC2 to BS and from ETMXF to the top of the Flow Bench. 

Some of the old video cables are still in place but are not used.   We might consider removing them to clear up the clutter. 

Some of the video cables in use are orange and if the lab's  cable color code is to be enforced these will have to be replaced with blue ones..

Some of the cables in use running from the MUX to the monitor in the control room are the white 50 Ohm variety.  There are also black RG59 Cables running the same way ( we have surplus cables in that path)  and we have to use those instead of the white ones. 

There are a number of tasks remaining:

a)  The inputs from the various existing cameras have to be verified. 

b) There are quite a few cameras which are yet to be installed.

c) The Outputs may not not be connected to their monitors.  That the monitors may still be connected to an old cable which is not connected to the MUX.  The new cable should be lying around close by.  So if you see a blank monitor please connect it to its new cable. 

d) The status column on the wiki page has to be updated.

e) Some of the currently in place may need to be replaced and some need to be removed.  We need to discuss our priorities and come up with a plan for that.

After checking everything we can certify that the video cabling system is complete.

I would like Joon Ho to take care of this verification+documenting process and declaring that the job is complete. 

Steve attached these two pictures.

[Steve, Kiwamu, Larisa]

Having finished laying new cable last week, we moved on to connecting those on PSL table and AP table.

Cables connected:

--RCR, RCT, PMCR (all three are blue)

--OMCR (blue cable, ***now has a camera***), PMCT, IMCR, REFL, AS (white cable), OMCT (***now has camera***)

Unless otherwise noted, the cables are black on the AP table. Also on the AP table: cables were connected directly to the power source.

The wiki has been updated accordingly.

Steve noted that MC2T and POP cameras are not there.

If someone gets time, let's put in all the cable posts and clean up our cable routing on the tables.

[Anchal, Tega, JC]

We installed cable posts in ITMY, BS, and ITMX chambers for all the new suspensions. Now, there is no point where the OSEM connections are hanging freely.

In BS chamber, we installed one post for LO2 near the north edge of the table and another post for PR3 on the Western edge with the blue cable running around the table on the floor.

In ITMY chamber, we installed the cable post in between AS1 and AS4 with the blue cables running around the table on the floor. This is to ensure the useful part of the table remains empty for future and none of the OSEM cables are taught in air.

 There were 4 cables running over the front side of rack 1Y4 such that the front door could not be closed. I re-routed them (one at a time) through the opening on the top of the rack. The concerned channels were

• Green refl mon
• Err mon
• Pzt out (temp) (has been marked "Door Damaged BNC")
• Laser temp ctrl

Before and after pics attached.

Before

.

After

[Alberto, Kiwamu, and Koji]

We removed the BNC cables from the control room.
The work was as hard as the one I had when I swept a 300m tunnel with a vacuum...

If we could remove the video cables, that would be a real epoch.

We found that the cabling behind the AP table is still quite ugly....grurrrh

I have designed new cable supports for the new ribbon cables running up the side of the tables in the vacuum chambers. This is a ribbon cable version of the existing cable clamp cf D010120

The clamps that I have designed (shown in basic sketch attachment 1) will secure the cable at each of the currently used cable supports. 

The support consists of a backplate and a frontplate. The backplate is secured to the leg of the table using a threaded screw. The frontplate clamps the cable to the backplate using two screws: one on either side. Between two fascinating points, the cable should have some slack. This should keep the cable from being stiff and help reduce the transfer of seismic noise to the table. 

It is possible to stack multiple cables in one of these fasteners. Either you can put two cables together and clamp them down with one faceplate or you can stack multiple faceplates with one cable between each faceplate. in this case the stack would go backplate then cable then faceplate then cable then the second faceplate. this configuration would require longer screws.

The exact specifics about which size screws and which size plates to use still have not been measured by me. But it will happen

[Larisa, Suresh]

All the cables needed for the AS11 PD are in place... the heliax cable runs from the AS table to the PSL rack.  The LO and RF cables to demod board as well as the I and Q cables into the LSC Whitening board are connected.

The cables get rather densely packed when the LSC Whitening filter sits between the PD Interface Board and the LSC AA filter board.  This makes it difficult to access the SMA connectors on the LSC whitening filter.  So we shifted the LSC Whitening and AA Filter boards one slot to the right.  The LSC rack looks like this just now.  We have also shifted the binary cables at the back of the Eurocart by one slot so the same cables are associated with the cards.

Last Thursday, Kiwamu and I went through the cabling necessary for a full damping test of the vertex optics controled by the sus subsytem, i.e. BS, ITMX, ITMY, PRM, SRM.  The sus IO chassis is sitting in the middle of the 1X4 rack.  The c1sus computer is the top 1U computer in that rack.

ADCs:

The hardest part is placing the 2x D-sub connectors to scsi on the lemo break out boxes connected to the 110Bs.  The breakout boxes can be seen at the very top of the picture Kiwamu took here.  These will require a minor modification to the back panel to allow the scsi cable to get out.  There are two of these boxes in the new 1X5 rack.  These would be connected by scsi to the ADC adapters in the back of the sus IO chassis in 1X4.  The connectors are currently behind the new 1X5 rack (along with some spare ADCs/DACs/BOs.

There are 3 cables going from 40 IDC to 37 D-sub (the last 3 wires are not used and do not need to be connected, i.e. 38-40).  These plug into the blue and gold ADC adapter box, the top one shown here.  There is one spare connection which will remain unused for the moment.  The 40 IPC ends plug into the Optical Lever PD boxes in the upper right of the new 1X4 rack (as seen in the top picture here - the boards on the right). At the back of the blue and gold adapter box is a scsi adapter which goes to the back of the IO chassis and plugs into an ADC.

In the back of the IO chassis is a 4th ADC which can be left unconnected at this point.  It will eventually be plugged into the BNC breakout box for PEM signals over in the new 1X7 rack, but is unneeded for a sus test.

DACs:

There are 5 cables going from 3 SOS dewhite/anti-image boards and 2 LSC anti-image boards into 3 blue and gold DAC adapter boxes.  Currently they plug into the Pentek DACs at the bottom of the new 1X4 rack.  Ideally we should be able to simply unplug these from the Pentek DACs and plug them directly into the blue and gold adapter boxes.  However at the time we checked, it was unclear if they would reach.  So its possible new cables may need to be made (or 40 pin IDC extenders made). These boxes are then connected to the back of the IO chassis by SCSI cables.  One of the DAC outputs will be left unconnected for now.

Binary Output:

The Binary output adapter boxes are plugged into the IO chassis BO cards via D-sub 37 cables.  Note one has to go past the ADC/DAC adapter board in the back of IO chassis and plug directly into the Binary Output cards in the middle of the chassis.  The 50 pin IDC cables should be unplugged from XY220s and plugged into the BO adapter boxes.  It is unclear if these will reach.

Timing:

We have a short fiber cable (sitting on the top shelf of the new 1X3 rack) which we can plug into the master timing distribution (blue box located in the new 1X6 rack) and into the front of the SUS IO chassis.  It doesn't quite make it going through all the holes at the top of the racks and through the cabling trays, so I generally only plug it in for actual tests.

The IO chassis is already plugged into the c1sus chassis with an Infiniband cable.

So in Summary to plug everything in for a SUS test requires:

• 6x SCSI cables (3 ADC, 3 DAC) (several near bottom of new 1X3 rack)
• 4x 37 D-sub to 37 D-sub connector (end connectors can be found behind new 1X5/1X6 area with the IO chassis stuff - Need to be made) (4 BO)
• 3x 40 IDC to 37 D-sub connectors (end connectors can be found behind new 1X5/1X6 area - Need to be made)(ADC)
• 5x 64 pin ribbon to 40 IDC cable (already exist, unclear if they will reach) (DAC)
• 8x 50 pin IDC ribbon (already exist, unclear if they will reach) (BO)
• 1x Double fiber from timing master to timing card
• 1x Infiniband cable (already plugged in)

Tomorrow, I will finish up a channel numbering plan I started with Kiwamu on Thursday and place it in the wiki and elog.  This is for knowing which ADC/DAC/BO channel numbers correspond to which signals.  Which ADCs/DACs/BOs the cables plug into matter for the actual control model, otherwise you'll be sending signals to the wrong destinations.

WARNING: The channel numbers on the front Binary Output blue and gold adapter boxes are labeled incorrectly.  Channels 1-16 are really in the middle, and 17-32 are on the left when looking at the front of the box.  The "To Binary IO Module" is correct.

Dear whomever setup the camera on the SW corner of the PSL table,

It would be handy if, even for temporary setups, all cables went underneath the white frame around the PSL table.  As it is now, the cables are in the way of the door.  The door is pretty much closed all the way, but if someone were to open other doors, the far door can easily be pushed all the way to the end of the track, thus squishing the cables.  Squished cables are bad cables.

Thanks!

[Kevin, Rana, Koji]

I calculated the dark noise of POX and POY due to Johnson noise and voltage and current noise from the MAX4107 op-amp using nominal values for the circuit components found in their data sheets. I found that the dark noise should be approximately 15.5 nV/rtHz. The measured dark noise values are 18.35 nV/rtHz and 98.5 nV/rtHz for POX and POY respectively. The shot noise plots on the wiki have been updated to show these calculated dark noise sources.

The measured dark noise for POY is too high. I will look into the cause of this large noise. It is possible that the shot noise measurement for POY was bad so I will start by redoing the measurement.

  Calculation for the input mode cleaner

I have been working on the calculation for the input mode cleaner. I have come out with a new optical setup that will allow us increase the Gouy phase different between the WFS to 90 degrees. I use a la mode to calculate it. The a la mode solution :

   label            z (m)      type             parameters         
    -----            -----      ----             ----------         
    MC1                    0    flat mirror      none:            
    MC3               0.1753    flat mirror      none:            
    MC2              13.4587    curved mirror    ROC: 17.8700       
    Lens1            29.6300    lens             focalLength: 1.7183
    BS2              29.9475    flat mirror      none:            
    First Mirror     30.0237    flat mirror      none:            
    WFS1             30.2269    flat mirror      none:            
    Second Mirror    30.2650    flat mirror      none:            
    Third Mirror     30.5698    flat mirror      none:            
    Lens2            30.9885    lens             focalLength: 1     
    Fourth Mirror    31.0778    flat mirror      none:            
    Lens3            31.4604    lens             focalLength: 0.1000
    Fifth Mirror     31.5350    flat mirror      none:            
    Sixth Mirror     31.9414    flat mirror      none:            
    WFS2             31.9922    flat mirror      none:      

I attached a pictures how the new setup is supposed to look like. 

Can you please give us some more details on how this design was decided upon? What were the design considerations?

It would be nice to have a shorter path length for WFS2. What is the desired spot size on the WFS? How sensitive are they going to be to IMC input alignment? Are we still going to be recentering the WFS all the time?

Nic, Andres, and I discussed some more about the MC WFS project today. We want to shorten the proposed WFS2 path. Andres is going to explore moving the 2" diameter lens in coming up with layouts. We also want the WFS to face west so that we can see the diode face with an IR viewer easily and dump the reflected beams in the razor dumps.

We wondered about fixing the power levels and optical gain:

1. What is the MC modulations depth? What would happen if we increase it a little? Does anyone know how to set it? Will this help the MC frequency noise?
2. What is the max power on the WFS? I guess it should be set so that the power dissipation of the detector is less than 1 W with the MC unlocked. So P_diss = (100 V)*(I_tot), means that we should have less than 10 mA or ~50 mW when the MC is unlocked.
3. Another consideration is saturation. The RF signals are tiny, but maybe the DC will saturate if we use any more power. The quadrants are saturated when unlocked and ~200 mV locked. According to D990249, the DC gain in the head is 1000 V/A. The measured power levels going into the heads (w/ MC unlocked) are: P_WFS1 = 4.9 mW and P_WFS2 = 7.7 mW. We don't have control of the DC gain, but there is a 10x and 100x switch available inside the demod board (D980233). From these numbers, I figure that we're in the 100x position and so the effective DC gain between photocurrent and the DC readback voltages is 100 kOhm. Therefore, we are in no danger of optical or electronics saturation. And the unlocked photocurrent of ~40/100000=0.4 mA => 0.04 W heat generated in the diode, so we're OK to increase the power level by another factor of 2-4 if we want.
4.  We noticed that the ADC inputs are moving by ~50 counts out of 65000, so we're doing a really bad job of signal conditioning. This was previously noticed 6 years ago but we failed to follow up on it. Feh.

While checking this out, I converted the McWFS DC offsets script from csh to bash and committed it to the SVN. We need to remove the prefix 'feature' that Jamie has introduced to cdsutils so that we can use C1 again.

 I did the calculation, and I reduced the beam Path. In my calculation, I restricted the waist size at the WFSs to be between 1mm-2mm also the other parameter is that the Gouy Phase different between the WFSs have to be 90 degrees. I also try to minimize the amount of mirrors used. I found the Gouy phase to be 89.0622 degrees between the WFSs and the following table shows the solution that I got from a la mode:

  label                         z (m)                   type               parameters         
    -----                         -----                    ----                  ----------         
    MC1                    0                        flat mirror           none:            
    MC3                    0.1753               flat mirror           none:            
    MC2                   13.4587              curved mirror    ROC: 17.8700 (m)       
    Lens1                 28.8172              lens                   focalLength: 1.7183(m)
    BS2                    29.9475              flat mirror           none:            
    First Mirror         30.0237              flat mirror           none:            
    Lens3                 30.1253              lens                  focalLength: -0.100 (m)
    Lens2                 30.1635              lens                 focalLength: 0.1250(m)
    WFS1                 30.2269              flat mirror         none:            
    Second Mirror    30.2650              flat mirror         none:            
    Third Mirror       30.5698              flat mirror         none:            
    Lens4                30.8113              lens                  focalLength: -0.075 (m)
    WFS2                31.0778              flat mirror         none:            

In the first image attached below is the a la mode solution that show the waist size in the first WFS, and I used that solution to calculate the solution of the waist size for the second WFS, which is shown in figure 2. I photoshop a picture to illustrate how the new setup it supposed to look like. 

Skip to final thought ...

Kiwamu and I have set about measuring the contrast of the signal on the RF PD. We can only do this when the end green laser is locked to the cavity. This is because the green transmission through the cavity, when unlocked, is too low. Unfortunately, once we lock the green beam to the cavity, we can't keep the beatnote on the RF PD stable to within a few hundred Hz of DC (remember that the cavity is swinging around by a couple of FSRs). So we also lock the PSL to cavity.

At this point we're stuck because we can't get both of these beams resonant within the cavity AND have the frequency difference between them be less 1kHz - when the lasers are locked to the cavity, their frequencies are separated by an integer number of FSRs + a fixed frequency offset, f_offset, that is set by the phase difference on reflection from the coating between the two wavelengths (532nm and 1064nm). We can never get the frequency difference between the lasers to be less than this offset frequency AND still have them both locked to the cavity.

So our contrast measuring method will have to use the RF signal.

So this is our method. We know the incident power from each beam on the RF PD (see Kiwamu's elog entry here), but to recap,

P_green_PSL = 72 uW (as measured today)

P_green_XARM = 560 uW (as measured by Kiwamu last week).

The trans-impedance of the RF PD is 240 Ohms. We'll assume a responsitivity of 0.25 A/W. So, if the XARM transmission and PSL green beams are perfectly matched then the maximum value of the RF beat note should be:

RF_amplitude_max = 2* SQRT(P_green_PSL*P_green_XARM) * responsivity * transimpedance = 240*0.25*2*(72E-6*560E-6)^(1/2) (volts)

= 24 mV = -19.5 dBm (or 27.5dBm after the +47 dB from the two  ZFL-1000LN+ amplifiers - with +15V in - that protrude from the top of the PD)

The maximum RF strength of the beat-note that we measure is around -75 dBm (at the RF output of the PD). This means the contrast is down nearly 600x from optimal. Or it means something is broken.

Final thought: at the end of this procedure we found that the RF beat note amplitude would jump to a different and much higher amplitude state. This renders a lot of the above useless until we discover the cause.

The calendar tab now displays calendars with weeks that run from Sunday to Saturday (as opposed to Monday to Sunday). However, the frame on the left hand side of the main page still has 'incorrect' calendars.

                TP3 noise
noise in m/s = -------------------
                 10 * 802(V/(m/s))

Using the numbers from the sensing measurement, I calibrated the measured in-loop MICH spectrum from Tuesday night into free-running displacement noise. For convenience, I used the noise-budgeting utilities to make this plot, but I omitted all the technical noise curves as the coupling has probably changed and I did not measure these. The overall noise seems ~x3  higher everywhere from the best I had last year, but this is hardly surprising as I haven't optimized anything for low noise recently. To summarize:

• DRMI was locked using 1f error signals.
• MICH was controlled using AS55_Q.
• Main difference is that we have a little less (supposedly 10%) light on the AS55 PD now because of the AUX laser injection setup. But the AUX laser was shuttered.
• 1f LSC PDs (REFL11, REFL55 and AS55) had ADC whitening filters engaged in while this data was taken.
• ITM and BS coils were not de-whitened.

I will do a more thorough careful characterization and add in the technical noises in the coming days. The dominant uncertainty in the sensing matrix measurement, and hence this free-running noise spectrum, is that I haven't calibrated the actuators in a while.

[Yuta, Jenne, Koji]

We stabilized the Xarm using the ALS and took a spectrum of POX as our out of loop sensor.  We used the calibration from elog 6841 to go from counts to meters.

We find (see attached pdf) that the RMS is around 60pm, dominated by 1Hz motion.

In other, related, news, I took out the beam pipe connecting the AP and PSL tables and covered the holes with foil.  This makes it much easier and faster to get to the X beat setup for alignment.  Eventually we'll have to put it back, but while the AUX laser on the AP table is not being used for beating against the PSL it'll be nice to have it out of the way.

[Koji, Hiroki] 

Calibrated flow sensor signals from [volt] to [m/s] and displayed them on CDS screen

We added the EPICS calc records to /cvs/cds/caltech/target/c1psl/psl/pem.db (Attachment 1) and made two channels for the calibrated signals of the flow sensors as follows:

C1:PEM-HEPA_FLOW_PSL1_CAL : Calibrated signal of flow sensor 1 [m/s]
C1:PEM-HEPA_FLOW_PSL2_CAL : Calibrated signal of flow sensor 2 [m/s]

At first, we tried to calibrate the output signal by using the 6-order approximation written in the user's manual (P11, D6F-V03A1) but the resulting outputs became 0 and we failed.
The cause of this failure might be due to the large number of the calculation of the 6-order approximation.
Then we used 5-order approximation that was fitted to the 6-order approximation and succeeded in obtaining the calibrated signals.
The used 5-order approximation is as follows:

    v: output voltage from flow sensor [V]
    A=5.11938
    B=-29.7601
    C=68.6169
    D=-78.4301
    E=46.0640
    F=-10.2767  

Attachment 2 shows the time series data of the raw signals and the calibrated signals when the flow speed was changed in minimum - middle - maximum.
Attachment 3 shows the CDS screen displaying the calibrated signals.

I calibrated the REFL signals to meters from counts.  The I-phase signals all line up very nicely, but the Q-phase signals do not at all.  I'm not sure what the deal is.

 I locked  the PRMI on sidebands, and drove the PRM.  I looked at the peak values at the drive frequency in the REFL signals, and used that as my "COUNTS" value for each PD. 

I know the PRM actuator calibration is 19.6e-9 (Hz/f)^2 m/ct , so if I plug in my drive frequency (564 Hz, with the notch in the PRC loop enabled), and multiply by my drive amplitude in counts, I know how many meters I am pushing the PRM.  Then, to get a meters per count calibration, I divide this calibration number (common for every PD) by the peak value in each PD, to get each signal's calibration.

As a side note, I also drove MICH, and tried to use this technique for the Q-phase calibrations, but neither calibration (using the PRCL drive nor the MICH drive) made the Q-phase signals line up at all.

At least for the I-phase signals, it's clear that REFL33 has more noise than REFL11 or REFL165, and that REFL55 has even more noise than REFL33. 

Here are the calibration values that I used:

We usually want to remove PRCL from the Q quadrature for each PD.
Therefore, you are not supposed to see any PRCL in Q assuming the tuning of the demod phases are perfect.
Of curse we are not perfect but close to this regime. Namely, the PRCL in Qs are JUNK.

In the condition where MICH is supressed by the servo, it is difficult to make all of the Qs line up because of the above PRCL junk.
But you shook MICH at a certain freq and the signal in each Q signal was calibrated such that the peak has the same height.
So the calibration should give you a correct sensing matrix.

If you tune the demod phases precisely and use less integrations for MICH, you might be able to see the residual MICH lines up on the Q plot.

 The goal of the measurements we made ( my previous 3 elogs) was to characterize the laser frequency thermal actuator that is a part of the FOL- PID loop.

For this we made indirect TF measurements for the thermal actuator by looking at the PZT response by 1)arm cavity( ETM ,ITM) displacement  and 2) temperature offset excitation. The goal was to do something like getting G1=TF3/TF1 and G2=TF3/TF2 and ultimately dividing G2/G1 to get TF2/TF1 with correct calibration. The final TFs obtained are the X and Y arm TFs for Laser frequency response vs temperature offset in(HZ/count). The calculations  in detail are:

Obtained    G1 = PZT response/ Temperature Offset (count/count): (in detail here )

Obtained    G2 = PZT response/  X and Y arm displacement( count/ count) : (in detail here)

Calibrated G2 to count/m ( in detail here)

Divided G2/G1 to get X and Y arm displacement/ Temperature Offset( m/ count) to get G3

Did these calculations:

dL/ L = dF /F

F = c/lambda ;Lambda = 532 nm  ; L = 

X arm length = 37.79 +/- 0.05 m

Y arm length = 37.81 +/- 0.01 m

TF: Laser Freq/ Temperature Offset = G3 *F/L       (HZ/Count)

The calibration coefficients for the ends  are :

X End:  [23.04 +/-  0.23 ]* 10^3  (HZ/Count)

Y End:    [18.71 +/-  0.2 ]* 10^3 (HZ/Count)

For the TFs of the temperature actuator on laser frequency I used ITMs for both the arms. The bode plots for the calibrated( HZ/Temp Count) are attached.

 For the X-Arm Thermal Actuator, I calculated the TFs at two different frequency ranges and combined the results where the coherence is high(>0.7). At 1 Hz the coherence was not as good as the other frequencies(due to the suspension resonance at 0.977 Hz).

The poles and zeroes are estimated after fitting this data using Matlab vectfit tool.The  graphs showing fit and measured values are attached.

Y arm Thermal Actuator:

5th order TF fitted: 

Gain: 9000

Zeroes:

z1 = -0.9799;

z2 = 2.1655; 

z3 = -2.9746- i * 3.7697

z4 = -2.9746+ i * 3.7697

z5 =  95.7703 + 0.0000i 

Poles:

p1 = -0.0985- i* -0.0845

p2 = -0.0985+ i* -0.0845

p3 = -0.6673- i* -0.7084

p4 = -0.6673+ i* -0.7084

p5 = -8.7979.

X-arm Thermal Actuator:

5th order TF fitted: 

Gain = 20

Zeroes:

z1= -305.7766

z2 =   -18.2774

 z3 =  -16.6167

 z4 =   -1.2486

 z5 =   28.1080

Poles:

p1  = -0.1311 - 0.1287i

p2 =  -0.1311 + 0.1287i

 p3  =  -8.3797 + 0.0000i

 p4 =  -4.0588 - 7.5613i

  p5 = -4.0588 + 7.5613i

I will use get the poles and zeroes from these fitted  bode plots and use it to build the PID loop.

To estimate in-loop MICH noise:

(a) Calibrate MICH_ERR:

1. Lock the arms for IR using POX11 and POY11.
2. Misalign the ETMs.
3. Obtain the average peak-to peak (bright to dark fringe) counts from the time series of AS55_Q_ERR. I measured this to be d = 6.358 counts.
4. This gives the calibration factor for AS55_Q_ERR [Calibration factor = 2*pi*d/1064/10^-9 = 3.7546x10^7 counts/m]

(b) In-loop MICH noise:

1. Lock MICH using AS55_Q.
2. Since LSC input matrix sets MICH_IN1 = 1* AS55_Q_ERR, the power spectrum measured using dtt and calibrated using the calibration factor from step 4 in (a) gives us the calibrated in-loop MICH noise.

The plot below shows the in-loop MICH noise and the dark noise (measured by closing the PSL shutter):

Compared with old measurements done by Keiko elog 6385 the noise levels are much better in the low frequency region below 100 Hz.
(No, no, no... this is not an apple-to-apple comparison: KA)

I calibrated noise spectrum of green lock.

1. Measurement of conversion factor of ADC input from V to ct:

As a preparation, first I measured a conversion factor at ADC input of C1;GCX1SLOW_SERVO1.

It was measured while the output of AI ch6 as the output of C1;GCX1SLOW_SERVO2 with 1Hz, 1000ct(2000ct_pp) was directly connected into AA ch7 as the input of C1;GCX1SLOW_SERVO1. Amplitude at the output at AI ch6 was 616mVpp measured by oscilloscope, and C1;GCX1SLOW_SERVO1_IN1 read as 971.9ct_pp. So the conversion factor is calculated as 6.338e-4[V/ct].

2. Injection of a calibration signal:

When Green laser was locked to cavity with fast PZT and slow thermal, I injected 100Hz, 1000ct EXC at ETMX ASL. The signal was measured at C1:GCX1SLOW_SERVO1_IN1 as 5.314ct_rms. It can be converted into 3.368e-3Vrms using above result, and then converted into 3368Hz_rms using PZT efficiency as 1MHz/V. This efficiency was obtained from Koji's knowledge, but he says that it might have 30% or higher error. If somebody get more accurate value, put it into the conversion process from V to Hz here.

3. Conversion;

Frequency of green f=c/532nm=5.635e14[Hz] is fluctuating with above 3368Hz_rms,so the fluctuation ratio is 3368/5.635=5.977e-12, and it corresponds to length fluctuation of 37.5m. So, cavity fluctuation will be 5.977e-12*37.5=2.241e-10m_rms by 100Hz, 1000ct EXC at ETMX ASL.

4. Results;

Finally, we knew 5.314ct corresponds to 3368Hz and 2.241e-10m, so conversion factor from ct to Hz and ct to m are ;

633.8[Hz/ct] @ C1:GCX1SLOW_SERVO1

4.217e-11[m/ct] @ C1:GCX1SLOW_SERVO1

5. Calibration:

You can measure green noise spectrum at C1;GCX1SLOW_SERVO1_IN1 during lock,  and mutiply above result to convert Hz or m.

This calibration is effective above corner frequency of slow and fast servo around 0.5Hz and UGF of fast servo around 4kHz.

I show an example of calibrated green noise.

Each color show different band-width. Of course this results of calibration cactor does not depend on band-width. Noise around 1.2Hz is 6e-8Hz/rHz. It sounds a bit too good by factor ~2. The VCO efficiency might be too small.

Note that there are several assumptions in this calibration;

1. TF from actual PZT voltage to PZT mon is assumed to be 1 in all frequency. Probably this is not a bad assumption because circuit diagram shows monitor point is extracted PZT voltage directly.

2. However above assumption is not correct if the input impedance of AI is low.

3. As I said, PZT efficiency of 1MHz/V might be wrong.

I also measured a TF from C1:SUS-ETMX_ALS_EXC to C1:GCX1SLOW_SERVO1_IN1. It is similar as calibration injection above but for wide frequency. This shows a clear line of f^-2 of suspension.

Files are located in /users/osamu/:20110127_Green_calibration.

Plan to calibrate single arm actuation strength

1. Lock single arm cavity (e.g. YARM)
2. Lock YAUX laser to arm cavity (actuation point is ETMY)
3. With the notch on the YARM loop filter (actually on ETMY),
4. Turn on cal line (e.g. DARM osc) to move ITMY; here the frequency is chosen to be away from 600 Hz (line harmonic) and from violin modes for ITMY (642 Hz). The lower value of 575.17 Hz was chosen to avoid demodulating noise peaks at 455 Hz and 700 Hz.
5. Get raw YALS beatnote (we chose the demod angle of -35 deg to minimize Q).

The analysis is as follows:

1. Get demodulated IQ timeseries for the duration of the locks before lowpass filter (C1:CAL-SENSMAT_DARM_BEATYF_I_DEMOD_I_IN1); we are also storing the raw beatnote if we want to do software demodulation.
2. Look at the allan deviation of I and Q to establish the timescale over which our measurement is dominated by statistical uncertainty -- after this time, the uncertainty is expected to be due to systematic error / drift. In this case as shown by Attachment #1 the time is around 60.6 seconds.
3. At this frequency and with 500 gain the ITMY coils should be actuating 7.32 pm of amplitude displacement.
4. The minimum allan deviation does indeed predict the statistical uncertainty limited rms if we look at the power spectra of the demodulated cal line over different time periods (Attachment #2), notice I lowpassed the raw timeseries.
5. I think the next step is to get the nominal calibration value and repeat the measurment for more than a single cal line.
6. Roughly from the deviation plot, our fractional beatnote deviation is a proxy for the calibration uncertainty. 1.15e-16 of beatnote stability should translate to a fractional displacement stability of ~4.57e-15 at 60 seconds; giving an ultimate statistical calibration uncertainty of 0.06% at this particular frequency when averaging for this long. It might be interesting to see a calibration frequency dependent allan deviation plot.