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:
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.
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
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)
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.
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.
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.
# Stage 1
r R31 1.58k in n_inU3
op U3 ad829 p_inU3 n_inU3 outU3
r R35 1k p_inU3 gnd
c C33 1u p_inU3 gnd
c C32 10n n_inU3 outU3
r R34 158k n_inU3 outU3
# Stage 2
#r R41 15.8 outU3 n_inU4U5
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.
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,
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],
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.
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.
--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
Before and after pics attached.
[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
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.
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.
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.
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.
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:
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.
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.
[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.
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:
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.
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:
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.
I finally analyzed the sensing measurement I ran on Tuesday evening. Sensing responses for the DRMI DOFs seems consistent with what I measured in October 2017, although the relative phasing of the DoFs in the sensing PDs has changed significantly. For what it's worth, my Finesse simulation is here.
[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.
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]
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:
z1 = -0.9799;
z2 = 2.1655;
z3 = -2.9746- i * 3.7697
z4 = -2.9746+ i * 3.7697
z5 = 95.7703 + 0.0000i
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:
Gain = 20
z2 = -18.2774
z3 = -16.6167
z4 = -1.2486
z5 = 28.1080
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.
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.
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
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
The analysis is as follows: