40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 166 of 344  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  5969   Mon Nov 21 15:47:58 2011 MirkoUpdateIOOOsem loop shape

[Jenne, Mirko]

To reiterate: We changed the OSEM loop shape for MC1-MC3. Below in black is the old loop shape, which simulated pendulum response in there. In red is the new loop shape.

OsemFilterShape.pdf

The differences are due to extra filter in C1:SUS-MC?_SUSPOS module 6,7,9

6: Elliptical LP @ 2.5Hz
7: Inverse Chebychev HP @0.3Hz
8: 1st order LP @ 10Hz

This has the potential to be unstable, but is not. At some point these filters should be tuned further.

  13071   Fri Jun 16 23:27:19 2017 Kaustubh, JigyasaUpdateComputersOttavia Connected to the Netgear Box

I just connected the Ottavia to the Netgear box and its working just fine. It'll remain switched on over the weekend.

Quote:

Kaustubh and I are going to enable the ethernet connection to Ottavia and secure the wiring now.  

 

  13065   Thu Jun 15 14:24:48 2017 Kaustubh, JigyasaUpdateComputersOttavia Switched On

Today, I and Jigyasa connected the Ottavia to one of the unused monitor screens Donatella. The Ottavia CPU had a label saying 'SMOKED''. One of the past elogs, 11091, dated back in March 2015, by Jenne had an update regarding the Ottavia smelling 'burny'. It seems to be working fine for about 2 hours now. Once it is connected to the Martian Network we can test it further. The Donatella screen we used seems to have a graphic problem, a damage to the display screen. Its a minor issue and does not affect the display that much, but perhaps it'll be better to use another screen if we plan to use the Ottavia in the future. We will power it down if there is an issue with it.

  13067   Thu Jun 15 19:49:03 2017 Kaustubh, JigyasaUpdateComputersOttavia Switched On

It has been working fine the whole day(we didn't do much testing on it though). We are leaving it on for the night.

Quote:

Today, I and Jigyasa connected the Ottavia to one of the unused monitor screens Donatella. The Ottavia CPU had a label saying 'SMOKED''. One of the past elogs, 11091, dated back in March 2015, by Jenne had an update regarding the Ottavia smelling 'burny'. It seems to be working fine for about 2 hours now. Once it is connected to the Martian Network we can test it further. The Donatella screen we used seems to have a graphic problem, a damage to the display screen. Its a minor issue and does not affect the display that much, but perhaps it'll be better to use another screen if we plan to use the Ottavia in the future. We will power it down if there is an issue with it.

 

  13068   Fri Jun 16 12:37:47 2017 Kaustubh, JigyasaUpdateComputersOttavia Switched On

Ottavia had been left running overnight and it seems to work fine. There has been no smell or any noticeable problems in the working. This morning Gautam, Kaustubh and I connected Ottavia to the Matrian Network through the Netgear switch in the 40m lab area. We were able to SSH into Ottavia through Pianosa and access directories. On the ottavia itself we were able to run ipython, access the internet. Since it seems to work out fine, Kaustubh and I are going to enable the ethernet connection to Ottavia and secure the wiring now.  

Quote:

It has been working fine the whole day(we didn't do much testing on it though). We are leaving it on for the night.

Quote:

Today, I and Jigyasa connected the Ottavia to one of the unused monitor screens Donatella. The Ottavia CPU had a label saying 'SMOKED''. One of the past elogs, 11091, dated back in March 2015, by Jenne had an update regarding the Ottavia smelling 'burny'. It seems to be working fine for about 2 hours now. Once it is connected to the Martian Network we can test it further. The Donatella screen we used seems to have a graphic problem, a damage to the display screen. Its a minor issue and does not affect the display that much, but perhaps it'll be better to use another screen if we plan to use the Ottavia in the future. We will power it down if there is an issue with it.

 

 

  9925   Wed May 7 23:09:06 2014 rana, jamieSummaryComputer Scripts / ProgramsOttavia back on network

After Jamie fixed the third party repo issue with Ottavia, he was able to upgrade it to Ubuntu 12.04 Precise Pangolin. But its network stopped working.

I tried to fix its issues by ifconfig and GUI, but what it really wanted was for me to put the network cable back into its eth0 slot. The eth1 network card appears not be working anymore.

All seems fine now. Next I will mount the shared user disk from linux1 and put in a .bashrc.

  2878   Tue May 4 14:57:53 2010 josephbUpdateComputersOttavia has moved

Ottavia was moved this afternoon from the control room into the lab, adjacent to Mafalda in 1Y3 on the top shelf.  It has been connected to the camera hub, as well as the normal network.  Its cables are clearly labeled.  Note the camera hub cable should be plugged into the lower ethernet port. Brief tests indicate everything is connected and it can talk to the control room machines.

The space where Ottavia used to be is now temporarily available as a good place to setup a laptop, as there is keyboard, mouse, and an extra monitor available.  Hopefully this space may be filled in with a new workstation in the near future.

  11091   Tue Mar 3 04:43:12 2015 JenneOmnistructurePEMOttavia is dead?

After some searching, including help from 4 security guys (I think they don't have a lot to do at 4:30am :), we found that Ottavia is super warm, and smelled burn-y.  She has been powered down and unplugged.  Security guys may call Steve's desk to follow up later today.sad

  10535   Wed Sep 24 18:56:45 2014 ericqUpdateGeneralOttavia slowness

Ottavia was having some severe interaction latency today. Xorg was taking up >90% of the CPU, just sitting around. The machine was logged in to a desktop session with lots of graphical effects turned on. I changed the system default session to "gnome-fallback" in /etc/lightdm/lightdm.conf, which was already set as the default for controls, but wouldn't get chosen for the autologin that happens on boot. 

Hopefully this helps ottavia stay usable...

  9144   Fri Sep 20 08:15:30 2013 SteveUpdateComputer Scripts / ProgramsOttavia, Rossa and Pianosa

Ottavia, Rossa  and Pianosa are running out of storage  space.

  16791   Wed Apr 20 16:11:08 2022 KojiUpdateSUSOutpur resistors updated for LO1 coil drivers / for SR2, LO2, AS1, and AS4 in progress

[JC Koji]

To give more alignment ranges for the SUS alignment, we started updating the output resistors of the BHD SUS coil drivers.
As Paco has already started working on LO1 alignment, we urgently updated the output Rs for LO1 coil drivers.
LO1 Coil Driver 1 now has R=100 // 1.2k ~ 92Ohm for CH1/2/3, and LO1 Coil Driver 2 has the same mod only for CH3. JC has taken the photos and will upload/update an elog/DCC.

We are still working on the update for the SR2, LO2, AS1, and AS4 coil drivers. They are spread over the workbench right now. Please leave them as they're for a while.
JC is going to continue to work on them tomorrow, and then we'll bring them back to the rack.

  16795   Thu Apr 21 15:22:44 2022 KojiUpdateSUSOutpur resistors updates for SR2, LO2, AS1, and AS4 done

[JC Koji]

Quick report: JC has done all the mods for the coil driver circuit in the morning and we worked on the reinstallation of them in the afternoon.
I'll check the damping loops / sus servo settings. JC is going to make an ELOG entry and DCC updates for more precise record of the mods.

  6599   Thu May 3 19:52:43 2012 JenneUpdateCDSOutput errors from dither alignment (Xarm) script

epicsThreadOnceOsd epicsMutexLock failed.
Segmentation fault
Number found where operator expected at -e line 1, near "0 0"
        (Missing operator before  0?)
syntax error at -e line 1, near "0 0"
Execution of -e aborted due to compilation errors.
Number found where operator expected at (eval 1) line 1, near "*  * 50"
        (Missing operator before  50?)
epicsThreadOnceOsd epicsMutexLock failed.
Segmentation fault
Number found where operator expected at -e line 1, near "0 0"
        (Missing operator before  0?)
syntax error at -e line 1, near "0 0"
Execution of -e aborted due to compilation errors.
syntax error at -e line 1, at EOF
Execution of -e aborted due to compilation errors.
Number found where operator expected at (eval 1) line 1, near "*  * 50"
        (Missing operator before  50?)
epicsThreadOnceOsd epicsMutexLock failed.
status : 0
I am going to execute the following commands
ezcastep -s 0.6 C1:SUS-ETMX_PIT_COMM +-0,50
ezcastep -s 0.6 C1:SUS-ITMX_PIT_COMM +,50
ezcastep -s 0.6 C1:SUS-ETMX_YAW_COMM +,50
ezcastep -s 0.6 C1:SUS-ITMX_YAW_COMM +-0,50
ezcastep -s 0.6 C1:SUS-BS_PIT_COMM +0,50
ezcastep -s 0.6 C1:SUS-BS_YAW_COMM +0,50
hit a key to execute the commands above

  16973   Wed Jul 6 15:28:18 2022 TegaUpdateSUSOutput matrix diagonalisation : F2P coil balancing

git repo : https://git.ligo.org/40m/scripts/-/tree/main/SUS/OutMatCalc

local dir:  /opt/rtcds/caltech/c1/Git/40m/scripts/SUS/OutMatCalc

 

Here is an update on our recent attempt at diagonalization of the SUS output matrices. There are two different parts to this: the first is coil balancing using existing F2P code which stopped working because of an old-style use of the print function and the second which should now focus on the mixing amongst the various degrees of freedoms (dof) without a DC/AC split I believe. The F2P codes are now working and have been consolidated in the git repo.  

 

TODO:

  • The remaining task is to make it so that we only call a single file that combines the characterization code and filter generation code, preferably with the addition of a safety feature that restores any changed values in case of an error or interruption from the user. The safety functionality is already implemented in the output matrix diagonalization stem of the code, so we just need to copy this over.  
  • Improve the error minimization algorithm for minimizing the cross-coupling between the various dof by adjusting the elements of the output matrix. 

 

Previous work 

https://nodus.ligo.caltech.edu:8081/40m/4762

https://nodus.ligo.caltech.edu:8081/40m/4719

https://nodus.ligo.caltech.edu:8081/40m/4688

https://nodus.ligo.caltech.edu:8081/40m/4682

https://nodus.ligo.caltech.edu:8081/40m/4673

https://nodus.ligo.caltech.edu:8081/40m/4327

https://nodus.ligo.caltech.edu:8081/40m/4326

https://nodus.ligo.caltech.edu:8081/40m/4762

  12536   Thu Oct 6 15:42:51 2016 LydiaUpdateSUSOutput matrix diagonalization

Summary: At the 40m meeting yesterday, Eric Q. gave the suggestion that we accept the input matrix weirdness and adjust the output matrix by driving each coil individually so that it refers to the same degrees of freedom. After testing this strategy, I don't think it will work. 

Yesterday evening I tested this idea by driving one ITMY coil at a time, and measuring the response of each of the free swing modes at the drive frequency. I followed more or less the same procedure as the standard diagonalization: responses to each of the possible stimuli are compared to build a matrix, which is inverted to describe the responses given the stimuli. For the input matrix, the sensor readings are the responses and the free swing peaks are the stimuli. For the output matrix, the sensors transformed by the diagonalized input matrix as the responses of the dofs which are compared, and the drive frequency peak associated with a coil output is the stimulus. However, the normalization still happens to each dof independently, not to each coil independently. 

The output matrix I got had good agreement with the ITMY input matrix in the previous elog: for each dof/osem the elements had the same sign in both input and output matrices, so there are no positive feedback loops. The relative magnitude of the elements also corresponded well within rows of the input matrix. So the input and output matrices, while radically different from the ideal, were consistent with each other and referred to the same dof basis. So, I applied these new matrices (both input and output) to the damping loops to test whether this approach would work. 

drive-generated output matrix: 

      UL      UR      LR       LL      SD
pit    1.701  -0.188  -2.000  -0.111   0.452  
yaw    0.219  -1.424   0.356   2.000   0.370  
pos    1.260   1.097   0.740   0.903  -0.763  
sid    0.348   0.511   0.416   0.252   1.000  
but    0.988  -1.052   0.978  -0.981   0.060

However, when Gautam attempted to lock the Y arm, we noticed that this change significantly impacted alignment. The alignment biases were adjusted accordingly and the arm was locking. But when the dither was run, the lock was consistently destroyed. This indicates that the dither alignment signals pass through the SUS screen output matrix. If the output matrix pitch and yaw columns refer instead to the free swing eigenmodes, anything that uses the output matrix and attempts to align pitch and yaw will fail. So, the ITMY matrices were restored to their previous values: a close to ideal input matrix and naive output matrix. We could try to change everything that is affected by the output matrices to be independent of a transformation to the free swing dof basis, and then implement this strategy. But to me, that seems like an unneccessary amount of changes with unpredictable consequences in order to fix something that isn't really broken. The damping works fine, maybe even better, when the input matrix is set by the output matrix: we define pitch, for example, to be "The mode of motion produced by a signal to the coils proportional to the pitch row of the naieve output matrix," and the same for the other dofs. Then you can drive one of these "idealized" dofs at a time and measure the sensor responses to find the input matrix. (That is how the input matrix currently in use for ITMY was found, and it seems to work well.) 

 

  12540   Fri Oct 7 20:56:15 2016 KojiUpdateSUSOutput matrix diagonalization

I wanted to see what is the reason to have such large coupling between pitch and yaw motions.

The first test was to check orthogonality of the bias sliders. It was done by monitoring the suspension motion using the green beam.
The Y arm cavity was aligned to the green. The damping of ITMY was all turned off except for SD.
Then ITMY was misaligned by the bias sliders. The ITMY face CCD view shows that the beam is reasonably orthogonally responding to the pitch and yaw sliders.
I also confirmed that the OPLEV signals also showed reasonablly orthogonal responce to the pitch and yaw misalignment.

=> My intuition was that the coils (including the gain balance) are OK for a first approximation.

Then, I started to excite the resonant modes. I agree that it is difficult to excite a pure picth motion with the resonance.


So I wanted to see how the mixing is frequency dependent.

The transfer functions between ITMY_ASCPIT/YAW_EXC to ITMY_OPLEV_PERROR/YERROR were measured.

The attached PDFs basically shows that the transfer functions are basically orthogonal (i.e. pitch exc goes to pitch, yaw exc goes to yaw) except at the resonant frequency.

I think the problem is that the two modes are almost degenerate but not completely. This elog shows that the resonant freq of the ITMY modes are particularly close compared to the other suspensions.
If they are completely degenerate, the motion just obeys our excitation. However, they are slightly split. Therefore, we suffer from the coupled modes of P and Y at the resonant freq.
However, the mirror motion obeys the exitation at the off resonance as these two modes are similar enough.

This means that the problem exists only at the resonant frequencies. If the damping servos have 1/f slope around the resonant freqs (that's the usual case), the antiresonance due to the mode coupling does not cause servo instability thank to the sufficient phase margin.

In conclusion, unfortunately we can't diagnalize the sensors and actuators using the natural modes because our assumption of the mode purity is not valid.
We can leave the pitch/yaw modes undiagnalized or just believe the oplevs as a relatively reliable reference of pitch and yaw and set the output matrix accordingly.

 

The figures will be rotated later.

  12354   Fri Jul 29 13:17:34 2016 KojiUpdateGeneralOven

While the air bake oven situation is being improved, how about to buy a cheepo toaster oven at Target, BestBuy, or anywhere?

We don't need precise temp control for the glue cure test. At LLO I saw that they are using cooking grade oven for this purpose.
(Of course, we should not use this oven for foods once it is used for epoxy)

I have a fryer temp sensor in my office on the freezer stole from the 40m long time ago. You should be able to measure high temp.

If you have such an oven, I'd love to borrow it for the OMC lab later, as I expect to work on epoxy bonding later.

  14073   Mon Jul 16 15:07:19 2018 KojiSummaryVACOven C vent

[Steve Koji]

- Attachment1: Removed the thermal cap. Checked the temperature of the oven. It was totally cold.

- Attachment2: Confirmed the RGA section was isolated. The pumps for the RGA was left running.

- Attachment3: Closed the main valve. The pumps for the main volume was left running.

- Attachment4: Started removing the rid. This did not change the gause readings as they were isolated from the venting main volume.

- Attachment5: Opened the rid. Took the components out on a UHV foil bag. The rid was replaced but loosely held by a few screws with the old gasket, just to protect the frange and the volume from rough dusts.

  15528   Sat Aug 15 15:12:22 2020 JonConfigurationVACOverhaul of small turbo pump interlocks

Summary

Yesterday I completed the switchover of small turbo pump interlocks as proposed in ELOG 15499. This overhaul altogether eliminates the dependency on RS232 readbacks, which had become unreliable (glitchy) in both controllers. In their place, the V4(5) valve-close interlocks are now predicated on an analog controller output whose voltage goes high when the rotation speed is >= 80% of the nominal setpoint. The critical speed is 52.8 krpm for TP2 and 40 krpm for TP3. There already exist hardware interlocks of V4(5) using the same signals, which I have also tested.

Interlock signal

Unlike the TP1 controller, which exposes simple relays whose open/closed states are sensed by Acromags, what the TP2(3) controllers output is an energized 24V signal for controlling such a relay (output circuit pictured below). I hadn't appreciated this difference and it cost me time yesterday. The ultimate solution was to route the signals through a set of new 24V Phoenix Contact relays installed inside the Acromag chassis. However, this required removing the chassis from the rack and bringing it to the electronics bench (rather than doing the work in situ, as I had planned). The relays are mounted to the second DIN rail opposite the Acromags. Each TP2(3) signal controls the state of a relay, which in turn is sensed using an Acromag XT1111.

Signal routing

The TP2(3) "normal-speed" signals are already in use by hardware interlocks of V4(5). Each signal is routed into the main AC relay box, where it controls an "interrupter" relay through which the Acromag control signal for the main V4(5) relay is passed. These signals are now shared with the digital controls system using a passive DB15 Y-splitter. The signal routing is shown below.

Interlock conditions

The new turbo-pump-related interlock conditions and their channel predicates are listed below. The full up-to-date channel list and wiring assignments for c1vac are maintained here.

Channel Type New? Interlock-triggering condition
C1:Vac-TP1_norm BI No Rotation speed < 90% nominal setpoint (29 krpm)
C1:Vac-TP1_fail BI No Critical fault occurrence
C1:Vac-TP1_current AI No Current draw > 4 A
C1:Vac-TP2_norm BI Yes Rotation speed < 80% nominal setpoint (52.8 krpm)
C1:Vac-TP3_norm BI Yes Rotation speed < 80% nominal setpoint (40 krpm)

There are two new channels, both of which provide a binary indication of whether the pump speed is outside its nominal range. I did not have enough 24V relays to also add the C1:Vac-TP2(3)_fail channels listed in ELOG 15499. However, these signals are redundant with the existing interlocks, and the existing serial "Status" readback will already print failure messages to the MEDM screens. All of the TP2(3) serial readback channels remain, which monitor voltage, current, operational status, and temperature. The pump on/off and low-speed mode on/off controls remain implemented with serial signals as well.

The new analog readbacks have been added to the MEDM controls screens, circled below:

Other incidental repairs

  • I replaced the (dead) LED monitor at the vac controls console. In the process of finding a replacement, I came across another dead spare monitor as well. Both have been labeled "DEAD" and moved to Jordan's desk for disposal.
  • I found the current TP3 Varian V70D controller to be just as glitchy in the analog outputs as well. That likely indicates there is a problem with the microprocessor itself, not just the serial communications card as I thought might be the case. I replaced the controller with the spare unit which was mounted right next to it in the rack [ELOG 13143]. The new unit has not glitched since the time I installed it around 10 pm last night.
  273   Sat Jan 26 02:34:34 2008 AndreyUpdateComputer Scripts / ProgramsOvernight Measuremts in XARM

I am running the program for measuring RMS of peaks in XARM tonight. I just started it, and it will run for about 9 hours until noon on Saturday. Please do not disturb the interferometer. Now the XARM is locked, it should stay locked over the night.

Andrey.
  12179   Tue Jun 14 19:37:40 2016 jamieUpdateCDSOvernight daqd test underway

I'm running another overnight test with new daqd software on fb1.  The normal daqd process on fb has been shutdown, and the front ends are sending their signals to fb1.

fb1 is running separate data concentrator (dc) and  frame writer (fw) processes, to see if this is a more stable configuration than the all-in-one framebuilder (fb) that we have been trying to run with.  I'll report on the test tomorrow.

  2541   Fri Jan 22 02:54:06 2010 AlbertoUpdateABSLOvernight measurement

I'm leaving a measurement running overnight. It should be done in about one hour.

Tomorrow morning, If you need to use the interferometer, and you don't want to have the auxiliary beam going onto the dark port, you can turn down the flipping mirror and close the NPRO's mechanical shutter.

  2543   Fri Jan 22 14:40:49 2010 AlbertoUpdateABSLOvernight measurement

Quote:

I'm leaving a measurement running overnight. It should be done in about one hour.

Tomorrow morning, If you need to use the interferometer, and you don't want to have the auxiliary beam going onto the dark port, you can turn down the flipping mirror and close the NPRO's mechanical shutter.

 This is what I measured last night:

2010-01-21_PRCtransmissivityVsModel.png

 This is not a fit. It's just a comparison of the model with the data.

  191   Thu Dec 13 23:56:02 2007 AndreyConfigurationComputer Scripts / ProgramsOvernight measurements

After my disease (fever, vomitting, nose problem, overall weakness) I returned to LIGO today for the first time after the weekend, and I am running the script for the XARM-measurements over this night.

So, suspension dumping gains should undergo changes in the interval from 1 to 10 in both ITMX and ETMX.

XARM has been of course locked.

I started running the script for the first time at about 10PM, but I realized after an hour and a half that my step of gain increase 0.2 was too shallow, too small to execute my program during one night. Therefore, I needed to terminate the program, change my program so that it increases the gain with increment 0.5, not 0.2, and started it again around midnight.

Going home.

P.S. The red pump that I borrowed from the lab (Steve's pump?) is back at its previous place. The tire-worker tells me that I absolutely need to change all four tires for almost 500 dollars. I regret a lot about that huge money loss.
  194   Mon Dec 17 23:42:08 2007 AndreyConfigurationComputer Scripts / ProgramsOvernight measurements in X-arm

I am making overnight measurements this night (from Monday to Tuesday) in XARM.

The X-arm is now locked, and the values for suspension damping gain will be changed in the interval from 1 to 7 with the step 0.5 in both ITMX and ETMX.

This is the second, repeated measurement. The results of the first measurement from Saturday to Sunday night will be reported in the separate ELOG entry (sorry, I did not make an ELOG entry on Saturday evening about running the program overnight).

The very first attempt to run the script in the night from Thursday to Friday was not successful.
  9909   Mon May 5 19:26:43 2014 JenneUpdateLSCOverride ability for whitening triggering

 Today I finally implemented a feature in the whitening triggering that I should have a long time ago:  an override button.

Now, on each RFPD's phase rotation screen, there is a button to either allow triggering for that PD (both quads) or to be in manual mode.  

If you are allowing triggering, they will behave as they have for the last ~year.....if any degree of freedom is using either quadrant of that PD, and that degree of freedom is triggered, then engage analog whitening and digital de-whitening.

If you chose manual mode, then you can engage or disengage the whitening as you please.  (The analog whitening and digital de-whitening are still tied together).

  3344   Sun Aug 1 18:50:35 2010 KojiUpdateVACP1 = 0.48 torr

I resumed the pumping today. Now the pressure is 0.48 torr. The pump was stopped.

Quote:

I resumed the pumping from 19:00.

Now the valve RV1 is full open. But the pumping is really slow as we are using only one RP.

After 3hrs of pumping, P1 reached 1.2mmtorr but still we need 2hrs of pumping...

I stopped pumping at 22:30.

 

  14844   Tue Aug 13 08:07:09 2019 gautamUpdateCDSP1--->P2

This morning, I wanted to move the existing cables going to the P1 connectors of the iLIGO whitening boards to the P2 connector, to test the modifications made to allow whitening stage switching. Unfortunately, I found that the shrouds werent installed. Where can I find these?

  14845   Tue Aug 13 14:36:17 2019 gautamUpdateCDSP1--->P2

As it turns out, only one extra shroud needed to be installed - I did this and migrated the cables for the 4 whitening boards from the P1 to P2 connectors. So until the new Acromag box is installed, we have no control over the whitening gains (slow channels), but do still have control over the whitening filter enable/disable (controlled by fast BIO). I am thinking about the easiest way to test the latter - I think the ambient PD dark noise level is too low to be seen above ADC noise even with the whitening enabled, and setting up drive signals to individual channels is too painful - maybe with +45dB of whitening gain, the (z,p) whitening filter shape can be seen with just PD/demod chain electroncis noise.

Quote:

This morning, I wanted to move the existing cables going to the P1 connectors of the iLIGO whitening boards to the P2 connector, to test the modifications made to allow whitening stage switching. Unfortunately, I found that the shrouds werent installed. Where can I find these?

  14747   Thu Jul 11 12:42:35 2019 gautamSummaryCDSP2 interface board

I looked into the design of the P2 interface board. The main difficulty here is geometric - we have to somehow accommodate sufficient number of D-sub connectors in the tight space between the two P-type connectors. 

I think the least painful option is to stick with Johannes' design for the P1 connector. For the CM board, the P2 connector only uses 6 pairs of conductors for signals. So we can use a D-15 connector instead of 2 D-37 connectors. Then we can change the PCB shape such that the P1 connector can be accommodated (see Attachment #1). The other alternative would be to have 2 P-type connectors and 3 D-subs on the same PCB, but then we have to be extra careful about the relative positioning of the P-type connectors (otherwise they wont fit onto the Eurocrate). So I opted to still have two separate PCBs.

I took a first pass at the design, the files may be found here. I just auto-routed the connections, this is just an electrical feedthrough so I don't think we need to be too concerned about the PCB trace routing? If this looks okay, we should send out the piece for fab ASAP.

I will work on putting together the EPICS server machine (SuperMicro) this afternoon.

Quote:

2. D040180 / D1500308 Common Mode Board

CM servo board itself doesn't need any modification. The CM board uses P1 and P2. So we need to manufacture a special connector for CM Board P2. (cf The adapter board for P1 T1800260). See also D1700058.

  14749   Thu Jul 11 13:08:36 2019 ChubSummaryCDSP2 interface board

It's nice and compact, and the cost of new 15-pin DSUB cables shouldn't be a factor here.  What does the 15p cable connect to?

  14750   Thu Jul 11 13:09:22 2019 gautam SummaryCDSP2 interface board

it will connect to a 15 pin breakout board in the Acromag chassis

Quote:

It's nice and compact, and the cost of new 15-pin DSUB cables shouldn't be a factor here.  What does the 15p cable connect to?

  14785   Sat Jul 20 11:57:39 2019 gautamSummaryCDSP2 interface board

The boards arrived. I soldered on a DIN96 connector, and tested that the goemetry will work. It does yes. The only constraint is that the P2 interface board has to be installed before the P1 interface is installed. Next step is to confirm that the pin-mapping is correct. The pin mapping from the DIN96 connector to the DB15 was also verified.

*Maybe it isn't obvious from the picture, but there shouldn't be any space constraint even with the DB37/DB15 cables connected to the respective adapter boards.

  1289   Tue Feb 10 23:36:25 2009 KakeruUpdatePSLPA current and laser output
I changed the PA current and measured laser output power (monitor PD signal).
The gain of ISS is 13dB
Attached figure is the relation of PA current and the average and standard diviation of laser output.
The average of output power decreas as current increase. It looks something is wrong with PA.
When current is -0.125, 0, 0.5, ISS become ocsilating. This looks to be changed from previous measurement.

I wrote matlab code for this measurement. The code is
/cvs/cds/caltech/users/kakeru/scripts/CS_evaluate.m
This function uses
/cvs/cds/caltech/users/kakeru/scripts/moveCS.m
  1291   Wed Feb 11 07:28:25 2009 YoichiUpdatePSLPA current and laser output
I think we should also plot the laser power at the MOPA output. The horizontal axis should be the absolute current value read from the PA current monitor channel, not the slider value.

This result is consistent with my hypothesis that the thermal effect is canceling the power change at low frequencies (see elog:1276).
But if it is really caused by thermal effect or not is still unknown.

I'd like to see a larger scan into the lower current region.


Quote:
I changed the PA current and measured laser output power (monitor PD signal).
The gain of ISS is 13dB
Attached figure is the relation of PA current and the average and standard diviation of laser output.
The average of output power decreas as current increase. It looks something is wrong with PA.
When current is -0.125, 0, 0.5, ISS become ocsilating. This looks to be changed from previous measurement.

I wrote matlab code for this measurement. The code is
/cvs/cds/caltech/users/kakeru/scripts/CS_evaluate.m
This function uses
/cvs/cds/caltech/users/kakeru/scripts/moveCS.m
  1295   Wed Feb 11 23:51:53 2009 KakeruUpdatePSLPA current and laser output
I attached a plot of ISS monitor PD and MOPA output to PA current.
The both end of PA current (26.0353[A] and 28.4144[A]) correspond to the slider value of -2.0 and 1.0 .
It looks that we must use MOPA with PA current below 27.5[A].
  1299   Thu Feb 12 18:35:10 2009 KakeruConfigurationPSLPA current limitter


I added a PA current limiter.
It is only a voltage devider (composed with 3.09k and 1.02k resiste) between DAC and PA current adjustment input.
The output range of DAC is +/- 10[V] and  the conversion factor of PA current adjustment is 0.84[A/V] (measured value), so the PA current adjustment is limited +/- 2.1[A] ( 10[V]*1.02k/(1.02k+3.09k)*0.84[A/V] ).


Actually, the manual of the PA tells that the conversion factor is 0.25[A/V].
There is 3 possibility.
1) There are some mistakes in channels of digital system.
2) The PA manual is wrong.
  2-1) The conversion factor of current adjustment is wrong.
  2-2) The conversion factor of current monitor is wrong.
I measured the signal of current adjustment and current monitor directly, and confirm that they are consistent to the value monitord from MEDM.
Hence the PA manual must be wrong, but I don't know which factor is wrong (or both?).
If the suspect 2-2) is guilty, it means we adjust PA current with very small range.
This is a completly safety way, but a wast of resource.


Now, the slider to control current adjustment indicate the output of DAC.
I will improve this to indicate  current adjustment input, but it takes some time for me to learn about EPICS.

  3818   Fri Oct 29 04:58:04 2010 KevinUpdatePSLPBS Optimization

[Koji and Kevin]

Since there was still a lot of power being reflected from the PBS before the Faraday rotator, I placed another PBS at the reflection from the first PBS to investigate the problem. If everything was ideal, we would expect the PBS to transmit P polarization and reflect S polarization. Thus, if the laser was entirely in the TEM00 mode, with the quarter and half wave plates we should be able to rotate the polarizations so that all of the power is transmitted through the PBS. In reality, some amount of P is reflected in addition to S reducing the power transmitted. (We are not sure what the PBS is since there are no markings on it but CVI says that their cubes should have less than 5% P reflection).

For the following measurements, the laser crystal temperature was 31.8° C, the current was 2.1 A, the half wave plate was at 267° and the quarter wave plate was at 330°. I first measured the power reflected from the first PBS then added the second PBS to this reflected light and measured the transmitted and reflected powers from this PBS with the following results:

reflection from first PBS 127 mW
reflection from second PBS 48 mW
transmission from second PBS 81 mW

This shows that approximately 81 mW of P polarization was being reflected from the first PBS and that there is approximately 48 mW of S polarization that could not be rotated into P with the two wave plates. Attachment 1 shows the shape of the reflected (S polarization) beam from the second PBS. This shows that the S polarization is not in TEM00 and can not be rotated by the wave plates. The transmitted P polarization is in TEM00.

We then rotated the first PBS (in yaw) to minimize the amount of P being reflected. Repeating the above measurement with the current alignment gives

reflection from first PBS 59 mW
reflection from second PBS 52 mW
transmission from second PBS 8.5 mW

Thus by rotating the cube to minimize the amount of P reflected, ~70 mW more power is transmitted through the cube. This adjustment moved the beam path slightly so Koji realigned the Faraday rotator and EOM. The PMC was then locked and the beam was realigned on the PMC. At 2.1 A, the transmission through the PMC is 6.55 V and the reflection is 178 mV. With the PMC unlocked, the reflection is 312 mV. This gives a visibility of 0.43.

Note by KA:
We realigned the beam toward the PMC at 1.0A at first so that we don't cook any parts. Once we get the TEM00 resonance, the steering mirrors were aligned to maximize the PMC transmission. Then the pumping current was increased to 2.1A.

  7295   Tue Aug 28 16:27:22 2012 ericqUpdatePSLPBS and Half Wave plates introduced

[Jenne, Eric]

We installed a Half Wave Plate -> Polarized Beam Splitter -> Half Wave Plate in the PSL beam line, immediately after the EOM, to be used for attenuating the beam when we vent, as in Entry 6892.

It was illuminating to discover that the optics labeled QWP0-1064-10-2 are indeed half wave plates, instead of quarter wave plates as QWP suggests. 

The PBS transmits "P"/Horizontal polarization, but the beam coming from the EOM is "S"/Vertically polarized, and we want to keep that, since we do not want the beam attenuated quite yet. 

So, we use the HWP to rotate the P from the EOM to S, so that the majority of the power passes through the PBS. The second HWP then rotates the transmitted S back into P, which continues to the mode cleaner. When we want to attenuate, we will simply rotate the first HWP to change the proportion of S polarized light that will pass straight through the PBS and towards the mode cleaner. 

After setting the proper HWP angles, we aligned the PBS via minimizing the MC reflection.

Since we have not yet attenuated the power, we have not yet changed the BS for the MC reflection, since this would damage the PD. The beam splitter will be changed out for a 100% reflectivity mirror to increase the power to the PD when we do.

 

  7299   Tue Aug 28 17:51:39 2012 JenneUpdatePSLPBS and Half Wave plates introduced

Quote:

[Jenne, Eric]

We installed a Half Wave Plate -> Polarized Beam Splitter -> Half Wave Plate in the PSL beam line, immediately after the EOM, to be used for attenuating the beam when we vent, as in Entry 6892.

It was illuminating to discover that the optics labeled QWP0-1064-10-2 are indeed half wave plates, instead of quarter wave plates as QWP suggests. 

The PBS transmits "P"/Horizontal polarization, but the beam coming from the EOM is "S"/Vertically polarized, and we want to keep that, since we do not want the beam attenuated quite yet. 

So, we use the HWP to rotate the P from the EOM to S, so that the majority of the power passes through the PBS. The second HWP then rotates the transmitted S back into P, which continues to the mode cleaner. When we want to attenuate, we will simply rotate the first HWP to change the proportion of S polarized light that will pass straight through the PBS and towards the mode cleaner. 

After setting the proper HWP angles, we aligned the PBS via minimizing the MC reflection.

Since we have not yet attenuated the power, we have not yet changed the BS for the MC reflection, since this would damage the PD. The beam splitter will be changed out for a 100% reflectivity mirror to increase the power to the PD when we do.

 

 Before we did this, I centered PSL POS and ANG, which gives us a reference of where the PSL beam was good when the MC spots were ~centered.  There had been a beam dump blocking them, possibly from the last time we put in the power attenuator optics.  This beam dump was moved a little to be out of the way of the PSL QPDs, and the PBS placed closer to the lens after the EOM, so that the PBS reflected beam is dumped.  However, we should not remove that razor dump when we remove the attenuation optics, since it is also dumping a stray IR beam from the PSL QPD pickoff windowd.

  11094   Tue Mar 3 19:19:15 2015 ericqUpdateIOOPC Drive / FSS Slow correlation

Jenne and I were musing the other night that the PC drive RMS may have a "favorite" laser temperature, as controlled by the FSS Slow servo; maybe around 0.2.

I downloaded the past 30 days of mean minute trend data for MC Trans, FSS Slow and PC Drive, and took the subset of data points where transmission was more than 15k, and the FSS slow output was within 1 count of zero. (This was to exclude some outliers when it ran away to 3 for some days). This was about 76% of the data. I then made some 2D histograms, to try and suss out any correlations. 

Indeed, the FSS slow servo does like to hang out around 0.2, but this does not seem to correlate with better MC transmission nor lower PC drive.

In the following grid of plots, the diagonal plots are the 1D histograms of each variable in the selected time period. The off diagnoal elements are the 2D histograms. They're all pretty blob-y, with no clear correlation. 

  3316   Thu Jul 29 11:33:38 2010 kiwamuUpdateCDSPCI5565 driver for RFM

 Yesterday I installed a PCI-5565 driver on new C1SUS in order to test the RFM.

Since the RFM on the new CDS is not working, we had to test it by using some softwares.

I installed a driver for PCI-5565 on C1SUS and ran a test script wich is one of the packaged test scripts in the driver.

So far the RFM card on C1SUS looked correctly mounted, but I didn't check the memory location and the sending/ receiving functions.

This test will continue sometime on August because right now the RFM test is not higher priority.

 


Some notes:

Driver package

      Alex suggested to use a driver package for PIC-5565 called "RFM2g Linux 32/64-bit PCIE/PCI/PMC driver for x86 kernels R7.03" , which is available on  this web site.

And the package contains some useful test scripts which exactly we want to run for RFM test.

 

Installation and test script

      I downloaded the driver and put it on C1SUS.  

After doing usual "unzip", "tar" and "make" things, I ran one of the test script called "rfm2g_util".

Currently it lives under /home/controls/Desktop/162-RFM2G-DRV-LNX-R07_03-000/rfm2g/diags/rfm2g_util on C1SUS.

It invokes an interactive shell and firstly it asks the mount point of the RFM card.

I eventually found the card was mounted on #1 which means the card is correctly mounted.

 

Some detail procedures will be summarized on the wiki later.

  4650   Fri May 6 06:36:18 2011 SureshUpdateRF SystemPD DC signals at each port connected

We now have the DC signal from three PDs available in the ADC channels 14,15 and 16.  The signals are from  REFL55, AS55 and POY photodiodes respectively.  As the DC signals on all the other PDs of the same port (REFL, AS and PO)  have the same information we do not need to monitor more than one DC PD at each port.

The LSC PD Interface Card, D990543 - Rev B, can take 4 PDs and provides the DC signals of the PDs on the connector P2 (the lower of the two) on the back plane of the chassis. An adaptor card, D010005-00, plugs into the back plane from the rear of the Eurorack and provides the four DC signals on two-pin lemo sockets.

I have connected the three DC signals from the relevant RF PDs (above) to a DC whitening filter, D990694-B-1 which is associated with the channels 9 to 16 of the ADC card.

The cables are in a bit of a mess right now as some of the PD power supply lines are too short to reach up the the Interface card in the top Eurocart. Steve and I plan to redo some of the cabling later today

 

 


 

  8870   Thu Jul 18 15:34:15 2013 Alex ColeUpdateElectronicsPD Frequency Response Update

 [Eric, Alex]

Our RF Switch arrived today, and we mounted it in rack 1Y1 (1st attachment). 

We connect our input fiber and all of our output fibers to our 1x16 optical splitter (2nd attachment). Note that the 75 meter fiber we are using for the splitter's input is in a very temporary position (3rd attachment - it's the spool).

We successfully turned our laser on and tested the optical splitter by measuring output power at each fiber using our Thorlabs PM20 power meter. Data was taken with the laser running at 67.5 mA and 24 degrees Celsius:

Detector name                  Power

REF DET 192 µW
AS55 146 µW
REFL55 180 µW
REFL11 172 µW
MCREFL 133 µW
REFL33 146 µW
REFL165 180 µW
POP22/POP110 182 µW
POP55 193 µW
POX11 123 µW

 

 

  10034   Thu Jun 12 16:56:31 2014 NichinUpdateElectronicsPD Inspection

I and Eric Gustafson inspected the automated PD frequency response measurement system which Alex Cole built last summer. We just lifted the tops off the tables [AS table, POY table and ITMX table] and looked at the alignment checking to see if the correct optical fibers from the fiber splitter were illuminating the correct photodiodes. We did not change anything at all and put the covers back on the tables.

The PDF attached shows the state of each PD fiber pair.  The fibers labeled REFL11 and REFL55 were reversed and illuminating the wrong photodiodes.

We will do a manual measurement of REFL33 tomorrow using the network analyzer and the modulatable laser but not the RF switch.  Afterward we will check to make sure the RF cables are connected to the correct channels of the RF switch according to the switch list (/users/alex.cole/switchList).

  10086   Sat Jun 21 01:25:12 2014 NichinHowToElectronicsPD Trasimpedence measurement theory

 Here is the logic that I have been using to calculate the transimpedence of PDs. Please let me know if you think anything is wrong.

  8478   Tue Apr 23 16:31:13 2013 EricConfiguration PD frequency response

[Eric, Riju]

Summary: Routing Fibers on AP table for Photo Diode Frequency Response Measurement System

Objective: We are to set-up one simultaneous transfer-function measurement system for all the RF-PDs present in 40m lab. A diode laser output is to be divided by 1x16 fiber splitter and to be sent to all the PDs through single-mode fiber. The transfer function of the PDs will be measured using network analyzer. The output of the PDs will be fed to network analyzer via one RF-switch.

Work Done So Far: We routed the fibers on AP table. Fibers from RF PDS - namely  MC REFL PD, AS55, REFL11, REFL33, REFL55, REFL165, have been connected to the 1x16 fiber splitter. All the cables are lying on the table now, so they are not blocking any beam.

We will soon upload the schematic diagram of the set up.

 

Missing Component: Digital Fiber Power Meter, Thorlab PM20C

 

 

  8484   Wed Apr 24 14:24:40 2013 RijuUpdate PD frequency response

 Here I am attaching the first schematic diagram of the PD frequency response set-up, I will keep updating it with relevant informations with the progress of the work.

Description: Our objective is to set-up one simultaneous transfer-function measurement system for all the RF-PDs present in 40m lab. A diode laser will be used to illuminate the PDs. The diode laser output will be divided by 1x16 fiber splitter and will be sent to all the PDs through single-mode fiber. The transfer function of the PDs will be measured using network analyzer(Agilent 4395A). The output of the PDs will be fed to network analyzer via one RF-switch. The diode laser will be controlled by the controller ILX LDC 3744C. The scanning frequency signal will be fed to this controller from network analyzer through its external modulation port. The output of the controller will be splitted  into two parts: one will go to laser diode and the other will be used as reference signal for network analyzer.

 

 

  8485   Wed Apr 24 14:36:06 2013 JenneUpdateRF SystemPD frequency response

I think you have the splitter that splits the RF signal from the network analyzer in the wrong place. 

Usually you split the signal immediately after the RF Out, so that half of the signal goes to the A-input of the Analyzer, and the other half goes to your controller (here, the laser diode controller).  Then you would take the output of your controller and go straight to the actual laser diode, with no splitting in this path.

  8487   Wed Apr 24 18:51:12 2013 KojiConfigurationoptical tablesPD frequency response

The fibers should be routed beneath the electrical cables.
They should be fixed on the table for strain relieving.
The slack of the fibers should be nicely rolled and put together at the splitter side.

These are expected to be done next time when the fiber team work around the table.

We also expect to have the table photo every time the work of the day is finished.

ELOG V3.1.3-