40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 335 of 344  Not logged in ELOG logo
New entries since:Wed Dec 31 16:00:00 1969
ID Date Author Typedown Category Subject
  7727   Mon Nov 19 20:17:53 2012 JenneConfiguration40m UpgradingEndtable upgrade for auxiliary green laser : ETMX layout on new table

 

For convenience, I would include a steering mirror in front of the TRX PD.  Also, don't we usually have lenses in the oplev paths?  Also, also, do we need lenses in front of the green refl and TRX PDs?  Do you have a place in mind for the shutter?  Is there a way to compactify the layout a little bit, so that even if the lenses are different for each table, the general layout for both ETMX and ETMY is the same (with an empty space on ETMX where IPANG belongs on ETMY)?  I'm sure it is, since you've talked to Steve about this, but just to check: is the green refl PD far enough away from the edge of the table to accommodate the fancy new box?

  7728   Mon Nov 19 22:42:14 2012 KojiConfiguration40m UpgradingEndtable upgrade for auxiliary green laser : ETMX layout on new table
  • I don't like the idea to place the cylindrical lenses right in front of the laser.
    This design requires the CLs to be tilted to avoid direct reflections going into the laser.
    It is also required that they are made of UV fused silica to avoid thermal lensing.

     
  • Instead, move the CLs after the farday while we keep L1, HWP, QWP after the laser.
    L1 should be UV fused silica lens. I should be placed with slight tilt.
    It is preferrable to place CLs after the faraday at somewhere the beam is not too small.
     
  • The HWP before the SHG can be moved to downstream of the steering mirrors as they can change the poralization.
    (Probably I am too paranoic.)
     
  • Why don't you use the harmonic separator right after the SHG crystal in stead of relying on an arbitrary transmission of the 532nm mirrors?
     
  • I am not confident about such a "nice" separation angle of the returning beam from the green faraday.
    Confirm the separation angle on the actual setup.

    The beams split in the polarizer rather than in the air like in your diagram.
    Then because of this small angle separation, the pick-off mirror may have a bit more critical distance than you indicated.
    (I could be wrong.)
  • I don't think the green faraday is IO-5-532-HP. It should be IO-?-532-LP.
    Rotate the tilt aligner 180deg so that we can easily access to the adjusting screws
     
  • The green PDA36A path needs more length and probably a focusing lens too.
     
  • After the PLCX lens, the beam is big (w=3mm) everywhere. Don't you want to use 2" mirrors and mounts?
     
  • We eventually will install steering PZTs for the green.
    On which mirrors do you want to install the PZTs?
    Do you have enough spare space for them?
     
  • The mount indicated "HS" is one of the trickiest mounts on the table as the big beam goes through the mirror.
    Probably you want to use 2" suprema mount with correct chirality.
     
  • How is the power budget of the IR trans path? Which is the low power PD and which is the high power PD?
    What's the transimpedance of them? Where is the crossover?
    How much power does go into the CCD? Is it a reasonable amount?

     
  • The IR transmon beam is even larger than the green beam (w=5mm)
    You definitely need a lens to shrink the beam. But we don't want to have the QPD and the CDD at the focus.
     
  • As Jenne pointed out, having a steering mirror for the IR PDA36A is a good idea.
    But do you really want to use the Si PD for the IR tmonitor?
  • I feel I don't want to have the pair of steering mirrors in the oplev incident path. One is enough.
    We should be able to accommodate optional mode-matching lenses in the incident path.
    We definitely don't want to have any lens in the returning path of the oplev.
  7731   Tue Nov 20 11:40:19 2012 ranaConfigurationGreen LockingEnd table upgrade for auxiliary green laser : ETMX layout on new table

 

 Mounts:

  1. No more mounts using the 1" dia. pedestal / fork technology.
  2. No more mounts using the 1/2" post / post holder technology. Both of these are loose, weak, and cause noise.
  3. All steerable mirror mounts which carry the important sensing beams should use steel mounts (e.g. Polaris from Thorlabs). Aluminum mirror mounts are not to be used.
  4. The mounts must be mounted to a 3/4" steel post (these are the custom ones we used in the PSL; Steve should get some more of them made).
  5. The post is then mounted on an aluminum base (The BA2 or BA3 (2" x 3" aluminum) from Thorlabs is OK. The 1" x 3" ones are not). These must be fastened to the table using 2 screws, each with a SS washer.

 

  7813   Wed Dec 12 11:04:45 2012 ManasaConfiguration40m UpgradingEndtable upgrade for auxiliary green laser : ETMX layout on new table

I have updated the layout to fix all the issues brought up. The last couple of 2" green steering mirrors will hold the PZTs for input steering. I will update with the list of optical components that we will be ordering for this layout. The ETMY endtable layout will be similar to this one, except that we will have IPANG setup at the empty space in the right top corner.

ETMX_endtable_New_Model.png

  7815   Wed Dec 12 14:59:49 2012 ManasaConfiguration40m UpgradingNew tip-tilts layout in BSC

I have updated the BSC layout to include the new tip-tilts. The bigger footprints of the tiptilts are on in the way of the existing PRM oplev path. So I have recalculated new PRM oplev paths. The proposed layout requires a new oplev mirror to be included.

 

bs.png

  7866   Thu Dec 20 19:46:20 2012 ranaConfigurationEnvironmentControl Room Projector

 Needs

StevePurple.JPG

  7889   Thu Jan 10 12:41:06 2013 ManasaConfiguration40m UpgradingEndtable upgrade for auxiliary green laser : wiki page

 

I have created a wiki page linked here with all details about the endtable upgrade.

The page has links to the new drawing for doubler post to hold the tilt-aligner that holds it. The Faradays will also be mounted similarly on tilt aligners placed on these posts. The bulk mounts will be made of aluminium similar to the colorful cylindrical mounts (images of which can be seen in the archived layouts on the wiki) that hold the He-Ne lasers and few faradays now.

  8228   Tue Mar 5 00:24:52 2013 ManasaConfiguration40m UpgradingEndtable upgrade for auxiliary green laser : customized mount

 Drawing of customized mount for endtable doubler crystal (PV40+PVP2+NP9071) modified and updated on the endtable upgrade wiki page.

  8303   Mon Mar 18 12:02:12 2013 AnnalisaConfigurationABSLABSL setup for g-factor measurement of PRC
Motivations
The ABSL technique has been already used in the past to measure the absolute length of the interferometer's optical cavities by means of an auxiliary laser source, as described in LIGO-P1200048-v3 and in Alberto Stochino thesis work.
Using the same technique it is possible to measure the g-factor of the power recycling cavity by measuring the cavity Transverse Mode Spacing.
 
Plan for experimental setup
The auxiliary laser is set on the POY table and is injected through the ITMY window in way to follow the same path of the POY beam. It hits the AR wedge of ITMY and is reflected back to the BS and the PRM.
 
Since the main beam is P-polarized, all the optics in the central IFO are P-polarization dependent, so it is useful to P-polarize the auxiliary beam before it enters the IFO.  
I made a mode matching calculation with a la mode script, in order to mode match the auxiliary beam waist to the waist of the main laser.
However, before ordering and installing steering optics and mode maching lenses, I'm waiting to know whether someone has an NPRO laser to install on the END table in place of the broken one, otherwise the one I'm using could be taken.
In this case a possibility could be to take the auxiliary beam from the end table with an optical fiber, but it means to use the auxiliary laser alternately to lock the arm or make a measurement of TMS. If so, a new calculation for the mode matching needs to be done.
Anyway, I hope that another laser will be found!
 
In order to phase lock the auxiliary beam with the main beam, the latter will be taken from the PSL table after the PMC through a single mode fiber, which will be brought up to the POY table. This solution results to be more reliable then taking the POY beam to phase lock the two laser, because POY is related to the locking. 
 
The signal with the beat note between the two lasers can be detected by the transmission from PR2 (POP). 
 
 
 
  8379   Mon Apr 1 09:05:09 2013 Jenne, GabrieleConfigurationLSCPOP22 configuration

On Friday we modified the POP22 set up: now the PD output goes to a bias tee. The DC output goes to the ADC board, while the RF output goes to an amplifier (Mini-circuits ZFL-1000LN+), to a band pass filter at 21.4 MHz and then to the ADC

  8404   Wed Apr 3 17:40:18 2013 JamieConfigurationElectronicsputting together a 110 MHz LSC demod board

I started to look into putting together a 110 MHz demod board to be used as POP110 (see #8399).

We have five spare old-skool EuroCard demod boards (LIGO-D990511).  From what I gather (see #4538, #4708) there are two modifications we do to these boards to make them ready for prime time:

  • appropriate LP filter at PD RF input (U5 -> MC SCLF-*)
  • swap out T1 transformer network with a commercial phase shifting power splitter (MC PQW/PSCQ)

#4538 also describes some other modifications but I'm not sure if those were actually implemented or not:

  • removal of the attenuator/DC block/ERA-5 amp sections at the I/Q outputs
  • swap ERA-5 amp with "Cougar"(?) amp at LO input.

What we'll need for a 110 demod:

I'll scrounge or order.

  8407   Wed Apr 3 18:41:22 2013 JamieConfigurationElectronicsputting together a 110 MHz LSC demod board

This SCPQ-150+, which is surface mount, might also work in place of the PSCQ-2-120, which is through-mount.  Would need to be reconciled with the board layout.

  8409   Wed Apr 3 22:26:51 2013 ranaConfigurationElectronicsputting together a 110 MHz LSC demod board

 For the 110 MHz demod boards, we would ideally have a plugin bandpass filter. If you have some specs in mind, you can email mini-circuits or pulsar microwave about making a custom part; its not too expensive usually.

For the meantime, you should remove the onboard one and replace with a combination of low/high pass filters from Mini-Circuits. If you put a SLP-150 and a SHP-100 in series, the insertion loss should be less than 1 dB.

I think the ERA amps are OK for now, but they die with time, so they just need to be tested and replaced if necessary.

  8415   Thu Apr 4 14:37:15 2013 JamieConfigurationElectronicsputting together a 110 MHz LSC demod board

I'm having Steve order the following:

2x  SXBP-100+
2x  SCLF-135+
2x  PSCQ-2-120+

If you want him to add anything to the order let him know ASAP.

  8426   Tue Apr 9 00:32:39 2013 ranaConfigurationIOOTurn on MCL

 Listening to the free swinging Y-arm, its clear that the fringe velocity is higher with the MCL path off, than on. I checked that the default gain of -300 was too high and changed it to -100 in the mcup script. With the higher gain value, there was clear gain peaking at just under 60 Hz (where the 60 Hz comb filter starts). We basically want the UGF to be between 20 and 60 Hz so that we can have the Bounce mode RG at 16.25 Hz and also the notch filter at 60 Hz.

Den is measuring and setting the UGF to be ~45 Hz.

With the MCL path on there is a high frequency horn-like noise in the Yarm when it locks. Its reduced a little by reducing the loop gain, but clearly this is just noise introduced by the MCL loop as Den noted before (and also tonight). He is cleaning up the whole MCL MEDM situation so that its useable by us. At the moment I've re-enabled it in the mcup.

My belief is that the frequency noise from the unstabilized MC is making the PRC locking harder. This will be investigated by tuning the shape of the MCL/MCF crossover so that we can turn it on without ruining the arm cavity spectra. Since the PRC length is ~2x smaller than the MC, we would expect it to be less sensitive to the MC frequency noise. But, since there is some common mode rejection in there, this may not be true. We'll only know by measuring PRC control signal with MCL on/off.

  8434   Wed Apr 10 03:59:41 2013 DenConfigurationIOOTurn on MCL

Quote:

 My belief is that the frequency noise from the unstabilized MC is making the PRC locking harder. This will be investigated by tuning the shape of the MCL/MCF crossover so that we can turn it on without ruining the arm cavity spectra. Since the PRC length is ~2x smaller than the MC, we would expect it to be less sensitive to the MC frequency noise. But, since there is some common mode rejection in there, this may not be true. We'll only know by measuring PRC control signal with MCL on/off.

 I think if we make MCL UGF higher then 20 Hz, arm cavity spectra will feel it. It might be possible to use a combination of feedback and feedforward control from ground seismometers. I made MCL UGF at 3 Hz to reduce 1 Hz motion of the pendulum; feedforward OAF subtracted the stack at 3.3 Hz. Once OAF converged, I blocked adaptation and the filter became static FIR. MC length RMS was reduced by a factor of 10 and arm cavity spectra was not affected at frequencies >20 and became better at low frequencies. We'll see if this enough.

On the attached plot red color shows MC_F with MC_L OFF, blue - MC_L is ON, green - MC_L and OAF are ON.

Then I locked PRCL (using AS_Q and REFL55_I) to carrier and aligned the cavity. Power RIN was 50-70% and 00 beam on the POP camera was moving significantly. BS oplev was shaking the optics at 5 Hz. I fixed it, but there should be something else as RIN was still high.

  8437   Wed Apr 10 15:49:22 2013 AnnalisaConfigurationCOMSOL TipsYend table eigenfrequency simulation with COMSOL

 I made a Simulation with COMSOL for the Yend table. Mainly, I tried to see how the lower eigenmode changes with the number and the size of the posts inside.

The lateral frame is just sitting on the table, it is fixed by its weight. I also put a couple of screws to fix it better, but the resulting eigenfrequency didn't change so much (less than 1 Hz). 

In Fig. 1 I didn't put any post. Of course, the lowest eigenfrequency is very low (around 80 Hz).

Then I added 2 posts, one per side (Fig. 2 and Fig. 3), with different diameter.

In some cases posts don't have a base, but they are fixed to the table only by a screw. It is just a condition to keep them fixed to the table

Eventually I put 4 posts, 2 per side. 

The lowest eigenfrequency is always increasing.

At the end I also put a simulation for 4 1.6 inch diameter posts without base, and the eigenfrequency is slightly higher. I want to check it again, because I would expect that the configuration shown in Fig.5a could be more stable.

P.S.: All the post are stainless steel.

 

  8468   Mon Apr 22 11:26:25 2013 KojiConfigurationCDSsome RT processes restarted

When I came to the 40m, I found most of the FB signals are dead.

The suspensions were not dumped but not too much excited. Use watchdog switches to cut off the coil actuators.

Restarted mxstream from the CDS_FE_STATUS screen. The c1lsc processes got fine. But the FB indicators for c1sus, c1ioo, c1iscex/y are still red.

Sshed into c1sus/ioo, run rtcds restart all . This made them came back under control.

Same treatment for c2iscex and c1iscey. This made c1sus stall again. Also c1iscey did not come back.

At this point I decided to kill all of the rt processes on c1sus/c1ioo/c1iscex/c1iscey to avoid interference between them.
And started to restart from the end machines.

c1iscex did not come back by rtcds restart all.
Run lsmod on c1iscey and found c1x05 persisted stay on the kernel. rmmod did not remove the c1x05 module.
Run software reboot of c1iscey. => c1iscey came back online.

c1iscey did not come back by rtcds restart all.
Run software reboot of c1iscex. => c1iscex came back online.

c1ioo just came back by rtcds restart all.

c1sus did not come back by rtcds restart all.
Run software reboot of c1sus => c1sus came back online.

This series of restarting made the fb connections of some of the c1lsc processes screwed up.
Run the following restarting commands => all of the process are running with FB connection.
rtcds restart c1sup
rtcds restart c1ass
rtcds restart c1lsc

Enable damping loops by reverting the watchdog switches.

All of the FE status are green except for the c1rfm bit 2 (GE FANUC RFM CARD 0).

  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

 

 

  8480   Tue Apr 23 22:59:05 2013 ranaConfigurationSUSOptical Lever Gains normalized

Due to the recent addition of cal factors in the OL error points, the OLPIT_GAIN and OLYAW_GAIN have been reduce to tiny numbers (e.g. 0.002).

Since our MEDM only shows 3 digits past the decimal point by default, it makes more sense to have the gains around 1.

So I reduced the gains in all of the FM1 filters from 1000 to 1 and multiplied the GAIN values by 1000 (using ezcastep) to compensate.

All of the active optics seem to be behaving as before. Haven't tested ETMs or SRM yet.

  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.

  8492   Thu Apr 25 17:56:28 2013 RijuConfiguration PD frequency response

 [Eric, Riju]

Today we have routed the fibers from 1x16 fiber splitter to POX table for POX11 PD and POP55 PD. Also we labeled the fibers on AP table, they have been fixed on the table. The photo of the table after work is attached here. We will do it for POX table tomorrow. 

  8493   Thu Apr 25 18:58:06 2013 KojiConfiguration PD frequency response

No.... what I told was to put the roll next to the splitter, not on the table.
The table area is more precious than the rack space.

Koji> The slack of the fibers should be nicely rolled and put together at the splitter side.

  8497   Fri Apr 26 17:08:42 2013 RijuConfiguration PD frequency response

Quote:

No.... what I told was to put the roll next to the splitter, not on the table.
The table area is more precious than the rack space.

Koji> The slack of the fibers should be nicely rolled and put together at the splitter side.

 Ok, will do it on the coming week.

  8499   Fri Apr 26 21:38:06 2013 JenneConfigurationRF SystemPD frequency response

I was sad to see that there wasn't a photo of the POX situation after the fiber work was done on Thursday.

Also, I was out looking at something else, and noticed that the fibers aren't in a very good/safe place from the POX table over to your splitter.  Getting to the POX table is certainly more tricky than the AP table, since the fiber splitter is right next to the AP table, but we should go back and try to make sure the fibers to the more distant tables are laid in a nice, safe way.

Is there a reason that we're not using the clear plastic tubing that Eric bought to put the fibers into?  It seems like that would help a lot in keeping the fibers safe.

I took a few photos of the things that I'm sad about:

1. We should not be keeping fibers on the floor in an area where they can be stepped on.  This will be fixed (I hope) as part of putting the extra coiled length over by the splitter.

IMG_0498.JPG

2. Again, in an area where we semi-regularly walk, the fibers should not be a tripping hazard.  Behind the table legs (rather than under the middle of the table) is safer, and will help tuck them out of the way.

IMG_0499.JPG

3.  It's not obvious when we're pumped down, but we remove the access connector (top right side of this photo), and need to walk in this area.  I can pretty much guarantee that within 1 day of the next time we vent, these fibers will be stepped on, tripped over, and broken if they are not moved to a different location.  I'm not yet sure what the best way to route these fibers is, but this is not it. 

IMG_0500.JPG

Riju, since Eric will be away next week, please let one of us "40m Regulars" know when you plan to come over (at least a few hours ahead of time), and we can give you a hand in protecting these fibers a little bit better.  Thanks!

  8506   Mon Apr 29 17:26:22 2013 RijuConfigurationRF SystemPD frequency response

 Today I have rerouted the fibers on AP table to remove the fiber rolls out of the AP table.  I removed the fibers one by one from both ends - from the 1x16 splitter and from the AP table - keeping the fiber roll intact, and then connected it in reverse way, i.e. the fiber end which was on AP table now is connected to the splitter (since length of the outside the roll is shorter that side) and the fiber end connected to splitter is now rerouted on AP table.

We need to keep the fibers in such a fashion so that no sharp bending occurs anywhere, and also it does not get strained due to its weight, particularly near the 1x16 splitter. Jenne suggested to use a plastic box over the splitter rack to keep the fiber rolls for time-being. We discussed a lot how this can be done nicely; in future we may use array of hooks, Koji suggested to use cable hangers and to tie the rolls using more than one hanging point, Jenne suggested to use the bottom shelf of the rack or to use one plastic box with holes. We tried to make holes on the plastic box using drill, but it developed crack on the box. So ultimately I used the opened box only and put it over the rack.

The corresponding photographs are attached herewith.

Tomorrow we will reroute the fibers for POX table.  

  8509   Mon Apr 29 23:02:48 2013 KojiConfigurationLSCQuestons

Q. How much Schnupp asymmetry we want in order to improve the signal ratio between PRCL/MICH in REFL ports?

Q. How much can we increase Schnupp asymmetry in the practical constraints?

Q. How PRCL/MICH ratio is different the REFL ports?
=> My modeling (many years ago) shows the ratio of {115, 51, 26, 23} for REFL{11, 33, 55, 165}.
These numbers should be confirmed by modern simulation of the 40m with updated parameters.
I should definitely use 55MHz but also prepare better 165MHz too.

Q. How the TT/PRM motions are affecting the lock stability? How can we quantify this effect? How can we mitigate this issue?

Q. Can we somehow change the sensing matrix by shifting the modulation frequency?

Q. Is normalization by POP22 or POP110 actually working well?
=> Time series measurement of error signals & servo inputs

  8512   Tue Apr 30 19:39:14 2013 RijuConfigurationRF SystemPD frequency response

Today I have rerouted the fibers on POX table. The aim was to lay it overhead through the plastic pipe. A pipe ~50ft (~15.5m) long was taken for this purpose. I disconnected the two 25m long fibers for POP55 and POX11 PD (those had been already routed) from both of their ends - i.e. from the POX table and also from 1x16 splitter. Jenne and Koji suggested that we may have another two PDs ( POP22 and POP110) on POX table in future. So we used another 25m long fiber for these two (POP22/POP110). We could not use two fibers for these two since we have only four 25m long fibers and one of them we need for POY11 PD on POY table. Jenne and me put the three fibers inside the pipe using a copper tube. The tube then was put on the overhead rack, Manasa helped me to do it. The fiber ends were finally laid on the POX table at one end and connected to the 1x16 splitter at the other end.

The corresponding photos are attached herewith.

  8513   Tue Apr 30 21:24:15 2013 JenneConfigurationRF SystemPOX fiber laying

Nice work.  That was a lot of effort, but having done it so nicely will definitely pay off, since it is now much harder to break the fibers.

2 small issues:  In your attachment 3, I see a coil of fiber just outside the POX table.  I thought Koji had asked that all spare coiled-up length of fiber always be at the splitter side.  Also, in securing the plastic tubing as it comes down near the PSL table, you have zip-tied the tubing to the PSL table.  Since that is a space that we need to access to align the Xgreen beatnote stuff, please disconnect that zip tie, and secure the tubing on the north side somewhere, underneath the AP table, rather than the PSL table (when you look closer, you may notice that no cables in that bundle are attached to the PSL side at the bottom, for this same reason). 

  8515   Tue Apr 30 23:04:23 2013 JenneConfigurationRF SystemOnly 4 25m cables ordered

I have found in the depths of the elog the (original?) list of fibers and lengths that were decided upon:  elog 6535.

In Suresh's elog, we were assuming that POP22 & POP110 would be served by a single PD.  This is still the nominal plan, although we (Rana is maybe still thinking about this in the back of his head?) think that it might not be feasible.  Riju and I were hoping to put a 4th fiber in the tubing so that we wouldn't have to add it later if POP22 & POP110 are eventually 2 separate PDs.  Anyhow, for now, all we have available are 3 fibers for the POX table, so that is what was installed this afternoon.

  8520   Wed May 1 17:36:26 2013 RijuConfigurationRF SystemPD frequency response

 Today I routed fiber from 1x16 splitter to POY table. Manasa helped me doing that. The fiber(25m) was laid on overhead rack through plastic pipe of length ~76ft. We put the fiber inside the pipe using one copper tube, and then tied the plastic pipe on the overhead rack. Finally one end of the fiber was laid on POY table and the other end was connected to the 1x16 splitter. The photographs corresponding are attached. There is no picture of splitter end, cause it was dark that time.

  8529   Sat May 4 00:21:00 2013 ranaConfigurationComputersworkstation updates

 Koji and I went into "Update Manager" on several of the Ubuntu workstations and unselected the "check for updates" button. This is to prevent the machines from asking to be upgraded so frequently - I am concerned that someone might be tempted to upgrade the workstations to Ubuntu 12.

We didn't catch them all, so please take a moment to check that this is the case on all the laptops you are using and make it so. We can then apply the updates in a controlled manner once every few months.

  8547   Tue May 7 23:03:12 2013 KojiConfigurationCDSCDS work

Summary:

c1rfm / c1lsc / c1ass / c1sus were modified. They were recomplied and installed. They are running fine
and confirmed PRMI locking (attempt), arm locking, and Yarm ass with the new codes.

Motivation:

1a. SQRTing switching for POP110 was wrong. 0 enabled sqrting, 1 disabled sqrting. I wanted to fix this.
1b. Sqrting for POP22 was not implemented.

2. Preparation for the shadow sensor control with POPDC.

3. ASS had only an input. I want to run two ASS for the X and Y arms.

SQRTing for POP110/22:

- Flipped the input of the bypass switch. Correspoding MEDM indicators are fixed on the power normalization screen.
- Copied the sqrting structure from POP110 to POP22. Correspoding MEDM buttom was made on the power normalization screen.

- The function of the sqrting buttons were confirmed.

Additional ASS output:

- The output path "NPRO" was removed. Corresponding RFM channels have also removed.
- The previous NPRO path was turned to the "ASS1" path. The previous "ASS" path was turned to "ASS2".
- Corresponding shared memory channel are created/renamed.
- c1ass was modified to receive the new ASS shared memory channels. ASS1 is assigned to the X arm. ASS2 is assigned to the Y arm
- The output matrix screen and the lockin screen were modified accordingly.
- Only script/ASS/Arm_ASS_Setup.py was affected. The corespoding lines (matrix assignment) was fixed.

- The function of Den's version of  ASS was confirmed.

LSC->PRM ASC path

- We want to connect POPDC to PRM ASC. POPDC is acquired on c1lsc.
- So, for now we use the LSC input matrix to assign POPDC to one of the servo bank.
- The last row of the LSC output matrix was assigned to the PCIE connection to c1sus.
- This PCIE connection was connected to the PRM ASC YAW input.

- The connection between LSC and SUS was confirmed.

- During this process I found that there are bunch of channels transferred from LSC to SUS via RFM.
  These channels are transferred via PCIE(dolphin) and then via RFM. But LSC and SUS are connected
  with dolphin. So this just adds additional sampling delay while there is no benefit. I think we should remove the RFM part.
  Note that we need to use RFM for the end mirrors but this also should use only the RFM connection.


Rebuilding the codes

- Prior to the tests of the new functionalities, the codes were rebuild/installed as usual.
- The suspension were shutdown with the watch dogs before the restart of the realtime codes.
- Once the realtime codes were restarted successfully, the watch dogs were reloaded.
- As we removed/added the channels, fb was restarted.
- c1rfm / c1lsc / c1ass / c1sus codes were checked-in to svn
 

  8549   Wed May 8 17:03:35 2013 JamieConfigurationCDSmake direct IPC connections between c1lsc and c1sus/c1mcs

Previously, for some reason, many IPC connections were routed through the c1rfm model, even if a direct IPC connection was possible.  It's unclear why this was done.  I spoke to Joe B. about it and he couldn't remember either.  Best guess is that it was just for book keeping purposes.  Or maybe some old timing issue that has been fixed by DMA fixes in the RTS.  So the point is that it's no longer needed, and we can reduce delays by making direct connections.

I made direct IPC connections from c1lsc to both c1sus and c1mcs, bypassing the c1rfm, through which they had previously been routed.  All models were rebuilt/installed/restarted and everything seems to be working fine.

  8550   Wed May 8 17:23:04 2013 JamieConfigurationCDSfixed direct IPC connection between c1als and c1mcs

As with the previous post, I eliminated and unnecessary hop through c1rfm for the c1als --> c1mcs connection for the ALS output to MC2 POS.

As a side note, we might considering piping the ALS signals into the LSC input matrix, elevating them to actual LSC error signals, which in some since they are.  It's just that right now we're routing them directly to the actuators without going through the full LSC control.

  8551   Wed May 8 17:45:49 2013 JamieConfigurationCDSMore bypassing c1rfm for c1mcs --> c1ioo IPCs

As with the last two posts, I eliminated more unnecessary passing through c1rfm for IPC connections between c1mcs and c1ioo.

All models were rebuilt/installed/restarted and svn committed.  Everything is working and we have eliminated almost all IPC errors and significantly simplified things.

  8553   Wed May 8 19:31:17 2013 JamieConfigurationLSCLSC: added new SQRT_SWITCH to power normalization DOF outputs

This removes the old sqrt'ing from the inputs to the POW_NORM matrix (was only on the POP110 I/Q) and moves it to the DOF outputs.  Koji wanted this so that he could use the DC signals for normalization both sqrt'd and not sqrt'd.

The POW_NORM medm screen was updated accordingly.

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

- Disabled MCL path in mcdown/mcupscript.

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

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

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

Filter shape comparison is found in the second plot attached.

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

Nominal PRM ASC gain is +70

- Openloop TF measurement

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

- REFL55/REFL33 phase adjustment (in lock)

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

  8573   Tue May 14 19:52:58 2013 RijuConfigurationRF SystemPD frequency response

 [Eric, Riju, Annalisa]

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

 

 

  8574   Tue May 14 20:27:19 2013 KojiConfigurationLSCOpenloop gain for PRMI lock May 13

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

  8577   Wed May 15 00:45:28 2013 ranaConfigurationLSCOpenloop gain for PRMI lock May 13

 

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

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

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

However, the area needs a good clean up.

 

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

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

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

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

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


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

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

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

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

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

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

I borrowed the GTRY BBPD  for the REFL165 trial before.

Now the PD is back on the PSL table.

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

  8654   Thu May 30 10:40:59 2013 JamieConfigurationCDSAttempt to cleanup c1ioo ADC connections

I have attempted to reconcile all of the ADC connections to c1ioo.  Upon close inspection, it appears that there was a lot of legacy stuff hanging around.  Either that or things have not been properly connected.

The c1ioo front end machine has two ADC cards, ADC0 and ADC1, which are used by two models, c1ioo and c1als.  The CURRENT ADC connections are listed in the table below.  The yellow cells indicate connections that were moved.  The red cells indicate connections that were removed/unplugged:

  channel block connection channel usage  model
ADC0 8-15 MC WFS1 interface   MC WFS1 c1ioo
16-23 MC WFS2 interface   MC WFS2 c1ioo
0-7

generic interface card (2 pin lemo)

0    
1    
2    
3 ALS TRX c1als
4 ALS TRY c1als
5    
6 MCL c1ioo
7 MCF c1ioo

 

  channel block connection channel usage model
ADC1 0-31 1U interface board 0/1 (J1A) PSL FSS MIXER/NPRO c1ioo
2/3 (J2) ALS BEAT X/Y DC c1als
4/5 (J3) PSL eurocrate DAQ interface J4  
6/7 PSL eurocrate DAQ interface J5  
8/9 PSL eurocrate DAQ interface J6  
10/11 MC eurocrate DAQ interface J1  
12/13 MC servo board DAQ  
14/15 (J8)    
16/17 (J9A) UNLABELLED ("DAQ ISS1"???)  
18/19 (J10) "DAQ ISS2"  
20/21 "DAQ ISS3"  
22/23 ALS BEAT X I/Q c1als
24/25 ALS BEAT Y I/Q c1als
26/27    
28/29    
30/31 (J16)    

The following changes were made:

  • "MC L" had been connected to ADC_0_0, moved to ADC_0_6
  • "MC F" had been connected to ADC_0_6, moved to ADC_0_7

The c1ioo model was rebuilt/restarted to reflect this change.

The PSL-FSS_MIXER and PSL-FSS_NPRO connections were broken in the c1ioo so I fixed them when I moved the MC channels.

All the removed connections from ADC1 were not used by any of the front end models, which is why I unplugged them.  Except for the MC DAQ interface J1 and MC servo DAQ connections, I left all other cables plugged in to wherever they were coming from.  The MC cables I did fully remove.

I don't know what these connections were meant for.  Presumably they expose they expose some useful DAQ channels that we're now getting elsewhere, but I'm not sure.  We don't currently have an ISS, which is presumably why the cables labelled "ISS" are not going anywhere.

TODO

I would like to see some more 4-pin lemo --> double BNC cables made.  That would allow us to more easily use the ADC1 generic interface board:

  • Moved ALS TRX/Y to ADC1, so that we can keep all the ALS connections together in ADC1.
  • POP QPD X/Y/SUM

We should also figure out if we're sub-optimally using the various "DAQ" connections to the DAQ cable connectiosn to the eurocrate DAQ interface cards and servo boards.

  8656   Thu May 30 11:28:34 2013 JamieConfigurationCDSc1als model cleanup

The c1als model was pulling out some ADC0 connections that were no longer used for anything:

  • ADC_0_1 --> sfm "FD" --> IPC "C1:ALS-SCX_FD"
  • ADC_0_5 --> sfm "OCX" --> term
  • ADC_0_6 --> sfm "ADC" --> term

The channels would have shown up as C1:ALS-FD, C1:ALS-OCX, C1:ALS-ADC.  The IPC connection that presumably was meant to go to c1scx is not connected on the other end.

I removed all this stuff from the model and rebuilt/restarted.

  8657   Thu May 30 11:33:26 2013 JamieConfigurationComputer Scripts / ProgramsASS medm/model changes need to be committed to SVN

There are a lot of changes to the ASS stuff that have not been committed to the SVN:

controls@rossa:/opt/rtcds/userapps/release/isc/c1 0$ svn status | grep -v '?'
M       medm/c1als/C1ALS_X_SLOW.adl
D       medm/c1ass/C1ASS_TRY_YAW_LOCKIN.adl
D       medm/c1ass/ASS_SERVOS.adl
D       medm/c1ass/ctrl_yaw_mtrx.adl
D       medm/c1ass/C1ASS_QPDS.adl
D       medm/c1ass/C1ASS_SEN_YAW_MTRX.adl
M       medm/c1ass/C1ASS_XARM_SEN_MTRX.adl
D       medm/c1ass/SITEMODEL_LOCKINNAME.adl
D       medm/c1ass/C1ASS_TRX_YAW_LOCKIN.adl
D       medm/c1ass/C1ASS_LOCKIN1.adl
D       medm/c1ass/C1ASS_LOCKIN2.adl
D       medm/c1ass/C1ASS_LOCKIN3.adl
D       medm/c1ass/C1ASS_LOCKIN4.adl
D       medm/c1ass/C1ASS_LOCKIN5.adl
D       medm/c1ass/C1ASS_LOCKIN6.adl
D       medm/c1ass/C1ASS_LOCKIN7.adl
D       medm/c1ass/C1ASS_LOCKIN8.adl
D       medm/c1ass/C1ASS_LOCKIN9.adl
D       medm/c1ass/C1ASS_REFL11I_PIT_LOCKIN.adl
M       medm/c1ass/C1ASS.adl
D       medm/c1ass/C1ASS_LOCKIN10.adl
D       medm/c1ass/C1ASS_LOCKIN11.adl
D       medm/c1ass/C1ASS_LOCKIN12.adl
D       medm/c1ass/C1ASS_LOCKIN13.adl
D       medm/c1ass/C1ASS_LOCKIN14.adl
D       medm/c1ass/C1ASS_LOCKIN15.adl
D       medm/c1ass/sen_yaw_mtrx.adl
D       medm/c1ass/C1ASS_LOCKIN16.adl
D       medm/c1ass/C1ASS_LOCKIN17.adl
D       medm/c1ass/C1ASS_DOF_YAW.adl
D       medm/c1ass/C1ASS_LOCKIN18.adl
D       medm/c1ass/C1ASS_LOCKIN19.adl
D       medm/c1ass/C1ASS_TRY_PIT_LOCKIN.adl
D       medm/c1ass/ctrl_pit_mtrx.adl
D       medm/c1ass/C1ASS_SEN_PIT_MTRX.adl
D       medm/c1ass/C1ASS_LOCKIN20.adl
D       medm/c1ass/C1ASS_LOCKIN21.adl
D       medm/c1ass/C1ASS_LOCKIN22.adl
D       medm/c1ass/C1ASS_LOCKIN23.adl
D       medm/c1ass/C1ASS_LOCKIN24.adl
D       medm/c1ass/C1ASS_LOCKIN25.adl
D       medm/c1ass/C1ASS_LOCKIN26.adl
D       medm/c1ass/C1ASS_LOCKIN27.adl
D       medm/c1ass/C1ASS_TRX_PIT_LOCKIN.adl
D       medm/c1ass/C1ASS_LOCKIN28.adl
D       medm/c1ass/C1ASS_LOCKIN29.adl
D       medm/c1ass/C1ASS_XARM_QPDS.adl
D       medm/c1ass/C1ASS_YARM_QPDS.adl
M       medm/c1ass/C1ASS_XARM_OUT_MTRX.adl
D       medm/c1ass/ASS_SEN_MTRX.adl
D       medm/c1ass/ASS_LOCKINS.adl
D       medm/c1ass/sen_pit_mtrx.adl
D       medm/c1ass/C1ASS_REFL11I_YAW_LOCKIN.adl
D       medm/c1ass/C1ASS_LOCKIN30.adl
D       medm/c1ass/C1ASS_DOF_PIT.adl
M       models/c1ass.mdl
controls@rossa:/opt/rtcds/userapps/release/isc/c1 0$
  8673   Tue Jun 4 20:19:07 2013 ranaConfigurationIOOChanged threshold for FSS SLOW loop

The FSS SLOW actuator often runs off away from zero and into a region where the mode hopping is bad and makes a lot of frequency noise (e.g. that 8 hour period a few weeks ago when Jamie couldn't lock the MC).

It should not have this behavior. The SLOW loop should only be running when the MC is locked.

Today I found that the threshold was set back to 0.2 V (which is approximately the correct value for the RefCav locking). Its being compared to the MC TRANS, so the correct value should be ~1/2 of the maximum MC TRANS.

To find this out, I read this piece of text:

    # Make sure the loop is supposed to be active
    if (get_value("C1:IOO-MC_TRANS_SUM") < get_value("C1:PSL-FSS_LOCKEDLEVEL")) {
    print("Reference Cavity not locked -- control loop disabled.\n");
    next;
    }

from scripts/PSL/FSS/FSSSlowServo. I set the threshold using the commmand:

caput -c -t C1:PSL-FSS_LOCKEDLEVEL 12000

Then I restarted the code on op340m, by typing:

> nohup FSSSlowServo

and then closing the terminal. Seems to be behaving correctly now. Previously, the value was so low that the SLOW loop was never turning itself off.

  8725   Wed Jun 19 16:04:56 2013 JamieConfigurationComputer Scripts / Programsconlog startup fixed, and restarted

I cleaned up a bunch of conlog stuff to make it all a little more sane and simple.  I also fixed the messy startup shenanigans, so that it should now start up sanely and on it's own (using Ubuntu's native upstart system).  The conlog wiki page was updated with all the new info.

  8726   Wed Jun 19 16:47:34 2013 JamieConfigurationComputer Scripts / Programsconlog startup fixed, and restarted

Quote:

I cleaned up a bunch of conlog stuff to make it all a little more sane and simple.  I also fixed the messy startup shenanigans, so that it should now start up sanely and on it's own (using Ubuntu's native upstart system).  The conlog wiki page was updated with all the new info.

 By the way, I also did confirm that it is running and registering EPICS changes.

ELOG V3.1.3-