40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 268 of 339  Not logged in ELOG logo
ID Date Author Typeup Category Subject
  12561   Fri Oct 14 10:31:53 2016 gautamUpdateGeneraldoors are off ITMY and BS/PRM chambers

[steve,ericq,gautam]

We re-checked IMC locking, arm alignments (we were able to lock and dither align both arms today, and also made the michelson spot look reasonable on the camera) and made sure that the AS and REFL spots were in the camera ballpark. We then proceeded to remove the heavy doors off ITMY and BS/PRM chambers. We also quickly made sure that it is possible to remove the side door of the OMC chamber with the current crane configuration, but have left it on for now.

The hunt for clipping now begins.

  12562   Fri Oct 14 15:47:00 2016 ranaUpdateTreasurefilters + clip

I say just fix the clipping. Don't worry about the PRM OSEM filters. We can do that next time when we put in the ITM baffles. No need for them on this round.

  12563   Fri Oct 14 18:33:55 2016 gautamUpdateGeneralAS clipping investigations

[steve,ericq,gautam]

In the afternoon, we took the heavy door off the OMC chamber as well, such that we could trace the AS beam all the way out to the AP table. 

In summary, we determined the following today:

  1. Beam is centered on SRM, as judged by placing the SOS iris on the tower
     
  2. Beam is a little off on OM1 in yaw, but still >2 beam diameters away from the edge of the steering optic, pitch is pretty good
  3. Beam is okay on OM2 
  4. Beam is okay on OM3 - but beam from OM3 to OM4 is perilously close to clipping on the green steering mirror between these two steering optics (see CAD drawing). We think this is where whatever effect of the SR2 hysteresis shows up first.
  5. Beam is a little low and a little to the left on OM4 (the first PZTJena mirror)
  6. Beam is well clear of other optics in the BS PRM chamber on the way from OM4 to OM5 in the OMC chamber
  7. Beam is a little low and a little to the left of OM5 in the OMC chamber. This is the second PZTJena mirror. We are approximately 1 beam diameter away from clipping on this 1" optic
    Link to IMG_2289.JPG
  8. Beam is off center on OMPO-OMMTSM partially transmissive optic, but because this is a 2" optic, the room for error is much more
    Link to IMG_2294.JPG
  9. Beam is well clear of optics on OMC table on the way from OMPO-OMMTSM to OM6, the final steering mirror bringing the AS beam out onto the table
  10. Beam is low and to the left on OM6. It is pretty bad here, we are < 1 beam diameter away from clipping on this optic, this along with the near miss on the BS/PRM chamber are the two most precarious positions we noticed today, consistent with the hypothesis in this elog that there could be multiple in vacuum clipping points
    Link to IMG_2306.JPG
  11. Beam clears the mirror just before the window pretty confortably (see photo, CAD drawing). But this mirror is not being used for anything useful at the moment. More importantly, there is some reflection off the window back onto this mirror frame which is then scattering and creating some ghost beams, so this could explain the anomalous ASDC behaviour Koji and Yutaro saw. In any case, I would favour removing this mirror since it is serving no purpose at the moment.
    Link to IMG_2310.JPG

Attachment #5 is extracted from the 40m CAD drawing which was last updated in 2012. It shows the beam path for the output beam from the BS all the way to the table (you may need to zoom in to see some labels. The drawing may not be accurate for the OMC chamber but it does show all the relevant optics approximately in their current positions.

EQ will put up photos from the ITMY and BS/PRM chambers.

Plan for Monday: Reconfirm all the findings from today immediately after running the dither alignment so that we can be sure that the ITMs are well-aligned. Then start at OM1 and steer the beam out of the chambers, centering the beam as best as possible given other constraints on all the optics sequentially. All shutters are closed for the weekend, though I left the SOS iris in the chamber...

Here is the link to the Picasa album with a bunch of photos from the OMC chamber prior to us making any changes inside it - there are also some photos in there of the AS beam path inside the OMC chamber...

Attachment 1: IMG_2289.JPG
IMG_2289.JPG
Attachment 2: IMG_2294.JPG
IMG_2294.JPG
Attachment 3: IMG_2306.JPG
IMG_2306.JPG
Attachment 4: IMG_2310.JPG
IMG_2310.JPG
Attachment 5: ASBeamClipping.pdf
ASBeamClipping.pdf
  12564   Fri Oct 14 19:59:09 2016 YinziUpdateGreen LockingContinuing work with the TC 200

Oct. 15, 2016

Another attempt (following elog 8755) to extract the oven transfer function from time series data using Matlab’s system identification functionalities.

The same time series data from elog 8755 was used in Matlab’s system identification toolbox to try to find a transfer function model of the system.

From elog 8755: H(s) is known from current PID gains: H(s) = 250 + 60/s +25s, and from the approximation G(s)=K/(1+Ts), we can expect the transfer function of the system to have 3 poles and 2 zeros.

I tried fitting a continuous-time and a discrete time transfer function with 3 poles and 2 zeros, as well as using the "quick start" option. Trying to fit a discrete time transfer function model with 3 poles and 2 zeros gave the least inaccurate results, but it’s still really far off (13.4% fit to the data).

Ideas:

1. Obtain more time domain data with some modulation of the input signal (also gives a way to characterize nonlinearities like passive cooling). This can be done with some minor modifications to the existing code on the raspberry pi. This should hopefully lead to a better system ID.

2. Try iterative tuning approach (sample gains above and below current gains?) so that a tune can be obtained without having to characterize the exact behavior of the heater.

Oct. 16, 2016

-Found the raspberry pi but it didn’t have an SD card

-Modified code to run directly on a computer connected to the TC 200. Communication seems to be happening, but a UnicodeDecodeError is thrown saying that the received data can’t be decoded.

-Some troubleshooting: tried utf-8 and utf-16 but neither worked. The raw data coming in is just strings of K’s, [‘s, and ?’s

-Will investigate possible reasons (update to Mac OS or a difference in Python version?), but it might be easier to just find an SD card for the raspberry pi which is known to work. In the meantime, modify code to obtain more time series data with variable input signals.

  12565   Mon Oct 17 14:48:12 2016 SteveUpdatesafetysafety training

Ashley Fowler  "high shool" student received basic 40m safety training and Lydia is her guarding angle.

 

  12566   Mon Oct 17 22:45:16 2016 gautamUpdateGeneralAS beam centered on all OMs

[ericq, lydia, gautam]

IMC realignment, Arm dither alignment

  • We started today by re-locking the PMC (required a c1psl restart), re-locking the IMC and then locking the arms
  • While trying to dither align the arms, I could only get the Y arm transmission to a maximum of ~0.09, while we are more used to something like 0.3 when the arm is well aligned this vent
  • As it turns out, Y arm was probably locked to an HOM, as a result of some minor drift in the ITMY optical table leveling due to the SOS tower aperture being left in over the weekend

ITMY chamber

  • We then resolved to start at the ITMY chamber, and re-confirm that the beam is indeed centered on the SRM by means of the above-mentioned aperture
  • Initially, there was considerable yaw misalignment on the aperture, probably due to the table level drifting because of the additional weight of the aperture
  • As soon as I removed the aperture, eric was able to re-dither-align the arms and their transmission went back up to the usual level of ~0.3 we are used to this vent
  • We quickly re-inserted the aperture and confirmed that the beam was indeed centered on the SRM
  • Then we removed the aperture from the chamber and set about inspecting the beam position on OM1
  • While the beam position wasn't terribly bad, we reasoned that we may as well do as good a job as we can now - so OM1 was moved ~0.5 in such that the beam through the SRM is now well centered on OM1 (see Attachment #1 for a CAD drawing of the ITMY table layout and the direction in which OM1 was moved)
  • Naturally this affected the beam position on OM2 - I re-centered the beam on OM2 by first coarsely rotating OM1 about the post it is mounted on, and then with the knobs on the mount. The beam is now well centered on OM2
  • We then went about checking the table leveling and found that the leveling had drifted substantially - I re-levelled the table by moving some of the weights around, but this has to be re-checked before closing up... 

BS/PRM chamber

  • The beam from OM2 was easily located in the BS/PRM chamber - it required minor yaw adjustment on OM2 to center the beam on OM3
  • Once the beam was centered on OM3, minor pitch and yaw adjustments on the OM3 mount were required to center the beam on OM4
  • The beam path from OM3 to OM4, and OM4 to the edge of the BS/PRM chamber towards the OMC chamber was checked. There is now good clearance (>2 beam diameters) between the beam from OM4 to the OMC chamber, and the green steering mirror in the path, which was one of the prime clipping candidates identified on Friday

OMC chamber

  • First, the beam was centered on OM5 by minor tweaking of the pitch and yaw knobs on OM4 (see Attachment #2)
  • Next, we set about removing the unused mirror just prior to the window on the AP table (see Attachment #3). PSL shutter was closed for this stage of work, in order to minimize the chance of staring directly into the input beam!
  • Unfortunately, we neglected checking the table leveling prior to removing the optic. A check after removing the optic suggested that the table wasn't level - this isn't so easy to check as the table is really crowded, and we can only really check near the edges of the table (see Attachment #3). But placing the level near the edge introduces an unknown amount of additional tilt due to its weight. We tried to minimize these effects by using the small spirit level, which confirmed that the table was indeed misaligned
  • To mitigate this, we placed a rectangular weight (clean) around the region where the removed mirror used to sit (see Attachment #3)Approximately half the block extends over the edge of the table, but it is bolted down. The leveling still isn't perfect - but we don't want to be too invasive on this table (see next bullet point). Since there are no suspended optics on this table, I think the leveling isn't as critical as on the other tables. We will take another pass at this tomorrow but I think we are in a good enough state right now. 
  • All this must have bumped the table quite a bit, because when we attempted re-locking the IMC, we noticed substantial misalignment. We should of course have anticipated this because the mirror launching the input beam into the IMC, and also MMT2 launching the beam into the arms, sits on this table! After exploring the alignment space of the IMC for a while, eric was able to re-lock the IMC and recover nominal transmission levels of ~1200 counts. 
  • We then re-locked the arms (needed some tip-tilt tweaking) and ran the dither again, setting us up for the final alignment onto OM6
  • OM5 pitch and yaw knobs were used to center the beam on OM6 - the resulting beam spot on OMPO-OMMTSM and OM6 are shown in Attachment #4 and Attachment #5 respectively. The centering on OMPO-OMMTSM isn't spectacular, but I wanted to avoid moving this optic if possible. Moreover, we don't really need the beam to follow this path (see last bullet in this section)
  • Beam path in the OMC chamber (OM5 --> OMPO-OMMTSM --> OM6 --> window was checked and no significant danger of clipping was found
  • Beam makes it cleanly through the window onto the AP table. We tweaked the pitch and yaw knobs on OM6 to center the beam on the first in-air pick off mirror steering the AS beam on the AP table. The beam is now visible on the camera, and looks clean, no hint of clipping
  • As a check, I wondered where the beam into the OMC is actually going. Turns out that as things stand, it is hitting the copper housing (see Attachment #6, it's had to get a good shot because of the crowded table...). While this isn't critical, perhaps we can avoid this extra scatter by dumping this beam?
  • Alternatively, we could just bypass OMPO-OMMTSM altogether - so rotate OM5 in-situ such that we steer the beam directly onto OM6. This way, we avoid throwing away half (?) the light in the AS beam. If this is the direction we want to take, it should be easy enough to make the change tomorrow

In summary...

  • AS beam has been centered on all steering optics (OM1 through OM6)
  • Table leveling has been checked on ITMY and OMC chambers - this will be re-checked prior to closing up
  • Green-scatter issue has to be investigated, should be fairly quick..
  • In the interest of neatness, we may want to install a couple of beam dumps - one to catch the back-reflection off the window in the OMC chamber, and the other for the beam going to the OMC (unless we decide to swivel OM5 and bypass the OMC section altogether, in which case the latter is superfluous)

C1SUSAUX re-booting

  • Not really related to this work, but we couldn't run the MC relief script due to c1susaux being unresponsive
  • I re-started c1susaux (taking care to follow the instructions in this elog to avoid getting ITMX stuck)
  • Afterwards, I was able to re-lock the IMC, recover nominal transmission of ~1200 counts. I then ran the MC relief servo
  • All shutters have been closed for the night
Attachment 1: OM1Moved.pdf
OM1Moved.pdf
Attachment 2: IMG_3304.JPG
IMG_3304.JPG
Attachment 3: OMCchamber.pdf
OMCchamber.pdf
Attachment 4: IMG_3292.JPG
IMG_3292.JPG
Attachment 5: IMG_3307.JPG
IMG_3307.JPG
Attachment 6: IMG_3297.JPG
IMG_3297.JPG
  12567   Tue Oct 18 17:11:42 2016 YinziUpdateGreen LockingMore serial port troubleshooting

I connected to the serial port using screen (through Terminal) and using Arduino's serial monitor and basically received the same strings that were received through python, so it's not a python issue. Checked the other TC 200 module and was also receiving nonsense, but it was all question marks instead of mostly K's and ['s.

This rules out a few possible reasons for the weird data. Next steps are to set up and configure the Raspberry Pi (which has been interfaced before) and see if the problem continues.

  12568   Tue Oct 18 18:56:57 2016 gautamUpdateGeneralOM5 rotated to bypass OMC, green scatter is from window to PSL table

[ericq, lydia, gautam]

  • We started today by checking leveling of ITMY table, all was okay on that front after the adjustment done yesterday. Before closing up, we will have detailed pictures of the current in vacuum layout
  • We then checked centering on OMs 1 and 2 (after having dither aligned the arms), nothing had drifted significantly from yesterday and we are still well centered on both these OMs
  • We then moved to the BS/PRM chamber and checked the leveling, even though nothing was touched on this table. Like in the OMC chamber, it is difficult to check the leveling here because of layout constraints, but I verified that the table was pretty close to being level using the small (clean) spirit level in two perpendicular directions
  • Beam centering was checked on OMs 3 and 4 and verified to be okay. Clearance of beam from OM4 towards the OMC chamber was checked at two potential clipping points - near the green steering mirror and near tip-tilt 2. Clearance at both locations was deemed satisfactory so we moved onto the OMC chamber
  • We decided to go ahead and rotate OM5 to send the beam directly to OM6 and bypass the partially transmissive mirror meant to send part of the AS beam to the OMC
  • In order to accommodate the new path, I had to remove a razor beam dump on the OMC setup, and translate OM5 back a little (see Attachment #1), but we have tried to maintain ~45 degree AOI on both OMs 5 and 6
  • Beam was centered on OM6 by adjusting the position of OM5. We initially fiddled around with the pitch and yaw knobs of OM4 to try and center the beam on OM5, but it was decided that it was better just to move OM5 rather than mess around on the BS/PRM chamber and introduce potential additional scatter/clipping
  • OMC table leveling was checked and verified to not have been significantly affected by todays work
  • It was necessary to loosen the fork and rotate OM6 to extract the AS beam from the vacuum chambers onto the AP table
  • AS beam is now on the camera, and looks nice and round, no evidence of any clipping. Some centering on in air lenses and mirrors on the AP table remains to be done. We are now pretty well centered on all 6 OMs and should have more power at the AS port given that we are now getting light previously routed to the OMC out as well. A quantitative measure of how much more light we have now will have to be done after pumping down and turning the PSL power back up
  • I didn't see any evidence of back-scattered light from the window even though there were hints of this previously (sadly the same can't be said about the green). I will check once again tomorrow, but this doesn't look like a major problem at the moment

Lydia and I investigated the extra green beam situation. Here are our findings.

  1. There appears to be 3 ghost beams in addition to the main beam. These ghosts appeared when we locked the X green and Y green individually, which lead us to conclude that whatever is causing this behaviour is located downstream of the periscope on the BS/PRM chamber
    Link to greenGhosts.JPG
  2. I then went into the BS/PRM chamber and investigated the spot on the lower periscope mirror. It isn't perfectly centered, but it isn't close to clipping on any edge, and the beam leaving the upper mirror on the periscope looks clean as well (only the X-arm green was used for this, and subsequent checks). The periscope mirror looks a bit dusty and scatters rather a lot which isn't ideal...
    Link to IMG_3322.JPG
  3. There are two steering mirrors on the IMC table which we do not have access to this vent. But I looked at the beam coming into the OMC chamber and it looks fine, no ghosts are visible when letting the main beam pass through a hole in one of our large clean IR viewing cards - and the angular separation of these ghosts seen on the PSL table suggests that we would see these ghosts if they exist prior to the OMC chamber on the card...
  4. The beam hits the final steering mirror which sends it out onto the PSL table on the OMC chamber cleanly - the spot leaving the mirror looks clean. However, there are two reflections from the two surfaces of the window that come back into the OMC chamber. Space constraints did not permit me to check what surfaces these scatter off and make it back out to the PSL table as ghosts, but this can be checked again tomorrow.
    Link to IMG_3326.JPG

I can't think of an easy fix for this - the layout on the OMC chamber is pretty crowded, and potential places to install a beam dump are close to the AS and IMC REFL beam paths (see Attachment #1). Perhaps Steve can suggest the best, least invasive way to do this. I will also try and nail down more accurately the origin of these spots tomorrow.


Light doors are back on for the night. I re-ran the dithers, and centered the oplevs for all the test-masses + BS. I am leaving the PSL shutter closed for the night

 

Attachment 1: OMCchamber.pdf
OMCchamber.pdf
Attachment 2: greenGhosts.JPG
greenGhosts.JPG
Attachment 3: IMG_3322.JPG
IMG_3322.JPG
Attachment 4: IMG_3326.JPG
IMG_3326.JPG
  12569   Wed Oct 19 08:28:11 2016 SteveUpdateSUSITMY_UL

Everybody is happy, except ITMY_UL or satalite box.

Gautam shows perfect form in the OMC chamber.

Attachment 1: 12hrs.png
12hrs.png
Attachment 2: vent79.jpg
vent79.jpg
  12570   Wed Oct 19 14:43:15 2016 SteveUpdateGeneral Viewports & coating of 2001

Tilted viewports installed in horizontal position. Atm2

Attachment 1: vacViewp2001.PDF
vacViewp2001.PDF vacViewp2001.PDF
Attachment 2: tiltedViewport.PDF
tiltedViewport.PDF
  12571   Wed Oct 19 16:41:55 2016 gautamUpdateGeneralHeavy doors back on

[ericq, lydia, steve, gautam]

  • We aligned the arms, and centered the in-air AS beam onto the PDs and camera
  • Misaligned the ITMs in a controlled ramp, observed ASDC level, didn't see any strange features
  • We can misalign the ITMs by +/- 100urad in yaw and not see any change in the ASDC level (i.e. no clipping). We think this is reasonable and it is unlikely that we will have to deal with such large misalignments. We also scanned a much larger range of ITM misalignments (approximately +/-1mrad), and saw no strange features in the ASDC levels as was noted in this elog - we used both the signal from the AS110 PD which had better SNR and also the AS55 PD. We take this to be a good sign, and will conduct further diagnostics once we are back at high power.
  • Opened up all light doors, checked centering on all 6 OM mirrors again, these were deemed to be satisfactory 
  • To solve the green scattering issue, we installed a 1in wide glass piece (~7inches tall) mounted on the edge of the OMC table to catch the reflection off the window (see Attachment #1) - this catches most of the ghost beams on the PSL table, there is one that remains directly above the beam which originates at the periscope in the BS/PRM chamber (see Attachment #2) but we decided to deal with this ghost on the PSL table rather than fiddle around in the vacuum and possibly make something else worse
    Link to IMG_2332.JPG
    Link to IMG_2364.JPG
  • Re-aligned arms, ran the dither, and then aligned the PRM and SRM - we saw nice round DRMI flashes on the cameras
  • Took lots of pictures in the chamber, put heavy doors back on. Test mass Oplev spots looked reasonably well centered, I re-centerd PRM and SRM spots in their aligned states, and then misaligned both
  • The window from the OMC chamber to the AS table looked clean enough to not warrant a cleaning..
  • PSL shutter is closed for now. I will check beam alignment, center Oplevs, and realign the green in the evening. Plan is to pump down first thing tomorrow morning

AS beam on OM1

Link to IMG_2337.JPG

AS beam on OM2

AS beam on OM3

AS beam on OM4

 
AS beam on OM6

I didn't manage to get a picture of the beam on OM5 because it is difficult to hold a card in front of it and simultaneously take a photo, but I did verify the centering...

It remains to update the CAD diagram to reflect the new AS beam path - there are also a number of optics/other in-vacuum pieces I noticed in the BS/PRM and OMC chambers which are not in the drawings, but I should have enough photos handy to fix this.  

Here is the link to the Picasa album with a bunch of photos from the OMC, BS/PRM and ITMY chambers prior to putting the heavy doors back on...


SRM satellite box has been removed for diagnostics by Rana. I centered the SRM Oplev prior to removing this, and I also turned off the watchdog and set the OSEM bias voltages to 0 before pulling the box out (the PIT and YAW bias values in the save files were accurate). Other Oplevs were centered after dither-aligning the arms (see Attachment #8, ignore SRM). Green was aligned to the arms in order to maximize green transmission (GTRX ~0.45, GTRY ~0.5, but transmission isn't centered on cameras).

I don't think I have missed out on any further checks, so unless anyone thinks otherwise, I think we are ready for Steve to start the pumpdown tomorrow morning.

Attachment 1: IMG_2332.JPG
IMG_2332.JPG
Attachment 2: IMG_2364.JPG
IMG_2364.JPG
Attachment 3: IMG_2337.JPG
IMG_2337.JPG
Attachment 4: IMG_2338.JPG
IMG_2338.JPG
Attachment 5: IMG_2356.JPG
IMG_2356.JPG
Attachment 6: IMG_2357.JPG
IMG_2357.JPG
Attachment 7: IMG_2335.JPG
IMG_2335.JPG
Attachment 8: Oplevs_19Oct2016.png
Oplevs_19Oct2016.png
  12572   Wed Oct 19 17:02:34 2016 ranaUpdateGeneral Viewports & coating of 2016

These old specs are not so bad. But we now want to get replacements for the TRX and TRY and PSL viewports that are R <0.1% at 532 and 1064 nm.

I don't know of any issues with keeping BK-7 as the substrate.

  12573   Wed Oct 19 18:32:25 2016 rana, yinziUpdatePSLRefCav thermal control: heater is dead

We wanted to re-activate the Heater for the reference cavity today to use it as a testbed for PID autotuning and the new heater driver circuit that Andrew is working on for the coating thermal noise experiment.

Unfortunately, it seems that the large power supply which is used for the heater is dead.sad Or maybe I don't remember how to use it?

The AC power cord was plugged in to a power strip which seems to work for IO chassis. We also tried swapping power strip ports.

We checked the front panel fuses. The power one was 3 Ohms and the 'bias' one was 55 Ohms. We also checked that the EPICS slider did, in fact, make voltage changes at the bias control input.

Non of the front panel lights come onfrown, but I also don't remember if that is normal.

Have those lights been dead a long time? We also reconnected the heater cable at the reference cavity side.

  12574   Thu Oct 20 09:17:08 2016 SteveUpdateVACPumpdown 80 has started

Pumping again after 7 days at atmosphere.

BS, ITMY and OMC chambers were open only.

Checked: jam nuts, viewport covers and beam shutters.

Oplev servo turned off and medm screens shots taken.

New item in vacuum:  green shade 14 glass beam block at IR-input [ from the PSL ] viewport to block green reflection-scatter.

Reminder: viewport is not AR coated for green!

 

 

 

Attachment 1: readyPd80.png
readyPd80.png
Attachment 2: beforePd80.png
beforePd80.png
Attachment 3: pd80at1h.png
pd80at1h.png
Attachment 4: 7d_atm.png
7d_atm.png
  12575   Thu Oct 20 15:59:52 2016 SteveUpdateVACPumpdown 80 has completed

IFO pressure 1.7E-4 Torr on new not logged cold cathode gauge. P1 <7E-4 Torr

Valve configuration: vac.normal with anunulossess closed off.

TP3 was turned off with a failing drypump. It will be replaced tomorrow.

Attachment 1: 7hPd80.png
7hPd80.png
Attachment 2: 8hPd80.png
8hPd80.png
Attachment 3: 9hPd80.png
9hPd80.png
  12576   Fri Oct 21 02:06:20 2016 gautamUpdateGeneralIFO recovery

The pressure on the newly installed gauge on the X arm was 6E-5 torr when I came in today evening, so I decided to start the recovery process.

  1. I first tried working at low power. I was able to lock the IMC as well as the arms. But the dither alignment didn't work so well. So I decided to go to nominal PSL power.
  2. I first changed the 2" HR mirror that is used to send all the MC REFL light to the MC REFL PD in low power operation with a 10% BS. I then roughly aligned the beam onto the PD using the tiny steering mirror. At this point, I also re-installed the ND filters on the end Transmon QPDs and also the CCD at the Y end.
  3. I then rotated the waveplate (the second one from the PSL aperture) until I maximized the power as measured just before the PSL shutter with a power meter. I then re-aligned the PMC to maximize transmission. After both these steps, we currently have 1.09W of IR light going into the IMC
  4. I then re-aligned MC REFL onto the PD (~90mW of light comes through to the PD) and maximized the DC output using an oscilloscope. I then reverted the Autolocker to the nominal version from the low power variant that has been running on megatron during the vent (although we never really used it). The autolocker worked well and I was able to lock the IMC without much trouble. I tweaked the alignment sliders for the IMC optics, but wasn't able to improve the transmission much. It is ~14600 cts right now, which is normal I think
  5. I then centered the beams onto the WFS QPDs, ran the WFSoffsets script after turning the inputs to the WFS servos off, and ran the relief script as well - I didn't try anything further with the IMC
  6. I then tried to lock the arms - I first used the green to align the test-masses. Once I was able to lock to a green 00-mode, I saw strong IR flashes and so I was able to lock the Y arm. I then ran the dither. Next, I did the same for the X arm. Even though I ran LSCoffsets before beginning work tonight, the Y arm transmission after maximization is ~5, and that for the X arm is ~2.5. I refrained from running the normalization scripts in case I am missing something here, but the mode itself is clearly visible on the cameras and is a 00-mode.
    GV edit 21Oct2016: For the Y-arm, the discrepancy was down to TRY being derived from the high gain PD as opposed to the QPD. Switching these and running the dither, TRY now maxes out at around 1.0. For TRX, the problem was that I did not install one of the ND filters - so the total ND was 1.2 rather than 1.6, which is what we were operating at and which is the ND on TRY. Both arms now have transmission ~1 after maximizing with the dither alignment...
  7. The AS spot looks nice and round on the camera, although the real check would be to do the sort of scan Yutaro and Koji did, and monitor the ASDC levels. I am leaving this task for tomorrow, along with checking the recycling cavities.
  8. Lastly, I centered the Oplevs for all the TMs

 

  12577   Fri Oct 21 09:28:21 2016 SteveUpdateVACVac Normal reached

Dry pump of TP3 replaced after 9.5 months of operation.[ 45 mTorr d3 ]

The annulosses are pumped.

Valve configuration: vac normal, IFO pressure 4.5E-5 Torr [1.6E-5 Torr d3 ] on new ITcc gauge, RGA is not installed yet.

Note how fast the pressure is dropping when the vent is short.

Quote:

IFO pressure 1.7E-4 Torr on new not logged cold cathode gauge. P1 <7E-4 Torr

Valve configuration: vac.normal with anunulossess closed off.

TP3 was turned off with a failing drypump. It will be replaced tomorrow.

All time stamps are blank on the MEDM screens.

Attachment 1: VacNormal.png
VacNormal.png
  12578   Mon Oct 24 11:39:13 2016 gautamUpdateGeneralALS recovered

I worked on recovering ALS today. Alignments had drifted sufficiently that I had to to the alignment on the PSL table onto the green beat PDs for both arms. As things stand, both green (and IR) beats have been acquired, and the noise performance looks satisfactory (see Attachment #1), except that the X beat noise above 100Hz looks slightly high. I measured the OLTF of the X end green PDH loop (after having maximized the arm transmission, dither alignment etc, measurement done at error point with an excitation amplitude of 25mV), and adjusted the gain such that the UGF is ~10kHz (see Attachment #2).

Attachment 1: ALSOutOfLoop20161024.pdf
ALSOutOfLoop20161024.pdf
Attachment 2: XendPDHOLTF20161024.pdf
XendPDHOLTF20161024.pdf
  12579   Tue Oct 25 15:56:11 2016 gautamUpdateGeneralPRFPMI locked, arms loss improved

[ericq,gautam]

Given that most of the post vent recovery tasks were done, and that the ALS noise performance looked good enough to try locking, we decided to try PRFPMI locking again last night. Here are the details:


PRM alignment, PRMI locking

  • We started by trying to find the REFL beam on the camera, the alignment biases for the 'correct' PRM alignment has changed after the vent
  • After aligning, the Oplev was way off center so that was fixed. We also had to re-center the ITMX oplev after a few failed locking attempts
  • The REFL beam was centered on all the RFPDs on the ASDC table

Post the most recent vent, where we bypass the OMC altogether, we have a lot more light now at the AS port. It has not yet been quantified how much more, but from the changes that had to be made to the loop gain for a stable loop, we estimate we have 2-3 times more power at the AS port now.


PRFPMI locking

  • We spent a while unsuccessfully trying to get the PRMI locked and reduce the carm offset on ALS control to bring the arms into the 'buzzing' state - the reason was that we forgot that it was established a couple of weeks ago that REFL165 had better MICH SNR. Once this change was made, we were readily able to reduce the carm offset to 0
  • Then we spent a few attempts trying to do blend in RF control - as mentioned in the above referenced elog, the point of failure always was trying to turn on the integrator in the CARM B path. We felt that the appearance of the CARM B IN1 signal on dataviewer was not what we are used to seeing but were unable to figure out why (as it turns out, we were locking CARM on POY11 and not REFL11 indecision, more on this later)
  • Eric found that switching the sign of the CARM B gain was the solution - we spent some time puzzling over why this should have changed, and hypothesized that perhaps we are now overcoupled, but it is more likely that this was because of the error signal mix up mentioned above...
  • We also found the DC coupling of the ITM Oplev loops to be not so reliable - perhaps this has to do with the wonky ITMY UL OSEM, more on this later. We usually turn the DC coupling on after dither aligning the arms, and in the past, it has been helpful. But we had more success last night with the DC coupling turned off rather than on.
  • Once the sign flip was figured out, we were repeatedly able to achieve locks with CARM partially on RF - we got through about 3 or 4, each was stable for just tens of seconds though. Also, we only progressed to RF on CARM on 1 attempt, the lock lasted for just a few seconds
  • Unfortunately, the mode cleaner decided to act up just about after we figured all this out, and it was pushing 4am so we decided to give up for the night.
  • The arm transmissions hit 300! We had run the transmission normalization scripts just before starting the lock so this number should be reliable (compare to ~130 in October last year). The corresponding PRG is about 16.2, which according to my Finesse models suggest we are still undercoupled, but are close to critical coupling (this needs a bit more investigation, supporting plots to follow). => Average arm loss is ~150ppm! So looks like we did some good with the vent, although of course an independent arm loss measurement has to be done...
  • Lockloss plot for one of the locks is Attachment #1

Other remarks:

  • Attachment #2 shows that the ITMY UL coil is glitchy (while the others are not). At some point last night, we turned off this sensor input to the damping servos, but for the actual locks, we turned it back on. I will do a Satellite box swap to see if this is a Sat. Box problem (which I suspect it is, the bad Sat. Boxes are piling up...)
  • Just now, eric was showing me the CM board setup in the LSC rack, because for the next lock attempts, we want to measure the CARM loop - but we found that the input to the CM board was POY and not REFL! This probably explains the sign flip mentioned above. The mix-up has been rectified
  • The MICH dither align doesn't seem to be working too well - possibly due to the fact that we have a lot more ASDC light now, this has to be investigated. But last night, we manually tweaked the BS alignment to make the dark port dark, and it seemed to work okay, although each time we aligned the PRMI on carrier, then went back to put the arms on ALS, and came back to PRMI, we would see some yaw misalignment in the AS beam...
  • I believe the SRM sat. box is still being looked at by Ben so it has not been reinstalled...
  • Eric has put together a configure script for the PRFPMI configuration which I have added to the IFO configure MEDM screen for convenience
  • For some reason, the appropriate whitening gain for POX11 and the XARM loop gain to get the XARM to lock has changed - the appropriate settings now are +30dB and 0.03 respectively. These have not been updated in some scripts, so for example, when the watch script resets the IFO configuration, it doesn't revert to these values. Just something to keep in mind for now...
Attachment 1: PRFPMIlock_25Oct2016.pdf
PRFPMIlock_25Oct2016.pdf
Attachment 2: ITMYwoes.png
ITMYwoes.png
  12580   Tue Oct 25 18:07:28 2016 KojiUpdateGeneralPRFPMI locked, arms loss improved

Great to hear that we have the PRG of ~16 now!

Is this 150ppm an avg loss per mirror, or per arm?

  12581   Wed Oct 26 16:06:01 2016 JohannesUpdateGeneralAutolocker maintenance

[Gautam, Johannes]

The autolocker was acting up today, Gautam traced it to EPICS channels ( namely C1:IOO-MC_LOCK_ENABLE and C1:IOO-MC_AUTOLOCK_BEAT ) served by c1iool0 not being responsive and keyed the crate. This restored it nominal operation.

  12582   Thu Oct 27 09:38:32 2016 SteveUpdatePEMmouse

We may have a mouse in the lab.  Do not leave any food scrap in trash ! Traps will be set.

 

Attachment 1: mouse.jpg
mouse.jpg
  12583   Thu Oct 27 12:06:39 2016 gautamUpdateGeneralPRFPMI locked, arms loss improved
Quote:

Great to hear that we have the PRG of ~16 now!

Is this 150ppm an avg loss per mirror, or per arm?

I realized that I did not have a Finesse model to reflect the current situation of flipped folding mirrors (I've been looking at 'ideal' RC cavity lengths with folding mirrors oriented with HR side inside the cavity so we didn't have to worry about the substrate/AR surface losses), and it took me a while to put together a model for the current configuration. Of course this calculation does not need a Finesse model but I thought it would be useful nevertheless. 

In summary - the model with which the attached plot was generated assumes the following:

  • Arm lengths of 37.79m, given our recent modification of the Y arm length
  • RC lengths are all taken from here, I have modelled the RC folding mirrors as flipped with the substrate and AR surface losses taken from the spec sheet
  • The X axis is the average arm loss - i.e. (LITMX+LITMY+LETMX+LETMY)/2. In the model, I have distributed the loss equally between the ITMs and ETMs.

This calculation agrees well with the analytic results Yutaro computed here - the slight difference is possibly due to assuming different losses in the RC folding mirrors. 

The conclusion from this study seems to be that the arm loss is now in the 100-150ppm range (so each mirror has 50-75ppm loss). But these numbers are only so reliable, we need an independent loss measurement to verify. In fact, during last night's locking efforts, the arm transmission sometimes touched 400 (=> PRG ~22), which according to these plots suggest total arm losses of ~50ppm, which would mean each mirror has only 25ppm loss, which seems a bit hard to believe.

Attachment 1: PRG.pdf
PRG.pdf
  12584   Thu Oct 27 13:48:20 2016 KojiUpdateGeneralPRFPMI locked, arms loss improved

It is also difficult to have a high arm transmission without having high PRG.

What about to plot the arm trans and the REFL DC power in a timeseries?
Or even in a correlation plot (X: Arm Trans or PRG vs Y: REFL Reflectivity)

This tells you an approximate location of the critical coupling, and allows you to calibrate the PRG, hopefully.

  12585   Thu Oct 27 23:29:47 2016 ericqUpdateGeneralPRFPMI locked, arms loss improved

As Gautam mentioned, we had some success locking the PRFPMI last night. (SRM satellite box is still in surgery...)

Unsurprisingly, changing the loss/PRG/CARM finesse means we had to fiddle with the common mode servo parameters a little bit to get things to work. However, before too long, we achieved a first lock on the order of a few minutes. Not long afterwards, we had a nice half hour lock stretch where we could tune up the AO crossover and loop UGFs. The working locking script was committed to SVN. Really, no fundamentally new tactics were used, which is encouraging. (One thing I wondered about was whether a narrower CARM linewidth would still let our direct ALS->REFL11 handoff with no offset reduction work. Turns out it does)

However, the step where we increase the analog CARM gain isn't as bulletproof as it once had been. The light levels "sputter" in and out sometimes if the gain increases are too agressive, and can cause a lockloss. Maybe this is an effect of the narrower linewidth and injecting more ALS noise at high frequencies with the higher CARM bandwidth.


The spatial profiles of the light on the cameras is totally bananas. Here's AS and REFL.


As Koji suggested, here is a 2D histogram of TRY vs REFLDC. It appears that the visibility would max out at 75% or so at arm powers around 400. Indeed, we briefly saw powers that high, but as can be seen on the plot, we were usually a little under 300. Exploring the transmon QPD offset space didn't seem to have much effect here.


One thing that I hadn't looked at in previous locks is coherence with our ground seismometers. It would be cool to have more seismic feedforward, and looking at the frequency domain multiple coherence, it looks like we can win a lot between 1 and 20 Hz. I expected more of a win at 1Hz, though.

Attachment 4: seis_sub.pdf
seis_sub.pdf
  12586   Fri Oct 28 01:44:48 2016 gautamUpdateGeneralPRFPMI model vs data studies

Following Koji's suggestion, I decided to investigate the relation between my Finesse model and the measured data.

For easy reference, here is the loss plot again:

Sticking with the model, I used the freedom Finesse offers me to stick in photodiodes wherever I desire, to monitor the circulating power in the PRC directly, and also REFLDC. Note that REFLDC goes to 0 because I am using Finesse's amplitude detector at the carrier frequency for the 00 mode only. 

  

Both the above plots essentially show the same information, except the X axis is different. So my model tells me that I should expect the point of critical coupling to be when the average arm loss is ~100ppm, corresponding to a PRG of ~17 as suggested by my model.

Eric has already put up a scatter plot, but I reproduce another from a fresh lock tonight. The data shown here corresponds to the IFO initially being in the 'buzzing' state where the arms are still under ALS control and we are turning up the REFL gain - then engaging the QPD ASC really takes us to high powers. The three regimes are visible in the data. I show here data sampled at 16 Hz, but the qualitative shape of the scatter does not change even with the full data. As an aside, today I saw the transmission hit ~425!

  

I have plotted the scatter between TRX and REFL DC, but if I were to plot the scatter between POP DC and REFL DC, the shape looks similar - specifically, there is an 'upturn' in the REFL DC values in an area similar to that seen in the above scatter plot. POP DC is a proxy for the PRG, and I confirmed that for the above dataset, there is a monotonic, linear relationship between TRX and POPDC, so I think it is legitimate to compare the plot on the RHS in the row directly above, to the plot from the Finesse model one row further up. In the data, REFL DC seems to hit a minimum around TRX=320. Assuming a PRM transmission of 5.5%, TRX of 320 corresponds to a PRG of 17.5, which is in the ballpark of the region the model tells us to expect it to be. Based on this, I conclude the following:

  • It seems like the Finesse model I have is quite close to the current state of the IFO 
  • Given that we can trust the model, the PRC is now OVERCOUPLED - the scatter plot of data supports this hypothesis
  • Given that in today's lock, I saw arm transmission go up to ~425, this suggests that at optimal alignment, PRG can reach 23. Then, Attachment #1 suggests the average arm loss is <50ppm, which means the average loss per optic is <25ppm. I am not sure how physical this is, given that I remember seeing the specs for the ITMs and ETMs being for scatter less than 40 25ppm, perhaps the optic exceeded the specs, or I remember the wrong numbers, or the model is wrong

In other news, I wanted to try and do the sensing matrix measurements which we neglected to do yesterday. I turned on the notches in CARM, DARM, PRCL and MICH, and then tuned the LO amplitudes until I saw a peak in the error signal for that particular DOF with peak height a factor of >10 above the noise floor. The LO amplitudes I used are 

MICH: 40

PRCL: 0.7

CARM: 0.08

DARM: 0.08

There should be about 15 minutes of good data. More impressively, the lock tonight lasted 1 hour (see Attachment #6, unfortunately FB crashed in between). Last night we lost lock while trying to transition control to 1f signals and tonight, I believe a P.C. drive excursion of the kind we are used to seeing was responsible for the lockloss, so the PRFPMI seems pretty stable.

With regards to the step in the lock acquisition sequence where the REFL gain is turned up, I found in my (4) attempts tonight that I had most success when I adjusted the CARM A slider while turning up the REFL gain to offload the load on the CARM B servo. Of course, this may mean nothing... 

Attachment 1: loss.pdf
loss.pdf
Attachment 2: REFLDC.pdf
REFLDC.pdf
Attachment 3: CriticalCoupling.pdf
CriticalCoupling.pdf
Attachment 4: PRFPMI_Oct282016.pdf
PRFPMI_Oct282016.pdf
Attachment 5: PRFPMI_scatter.pdf
PRFPMI_scatter.pdf
Attachment 6: 1hourPRFPMILock.png
1hourPRFPMILock.png
  12588   Fri Oct 28 19:13:57 2016 ranaUpdateGeneralPR gain

I don't think the loss of 25 ppm is outrageous. Its just surprisingly good. The SIS model predicted numbers more like 1 ppm / mirror taking into account just the phase map and not the coating defects.

However, we should take into account the lossed in the DRMI to be more accurate: AR coating reflectivities, scatter loss on those surfaces, as well as possible clipping around BS or some other optics.

https://chat.ligo.org/ligo/channels/40m

  12589   Mon Oct 31 16:20:50 2016 SteveUpdateVACRGA is reinstalled

Quad rods and  ionizer kit: consisting of repeller cage, anode grid, focus plate and  filament were replaced....... under repair # RGA200/12 ECA 100416-12967

The electronic ECU is not connected. It is beeing pumped at IFO ITcc 9.7E-6 Torr vacNormal

Quote:

The RGA is removed for repaire. It's volume at atmophere and sealed.. P4 reading of 38 Torr is not correct.

 

 

  12590   Tue Nov 1 09:03:08 2016 SteveUpdateSUSseismic activity is up

Salton See is shaking again.

 

Attachment 1: seismicActivity.png
seismicActivity.png
  12591   Wed Nov 2 12:05:00 2016 ericqUpdateASCQuick WFS thoughts

I poked around a bit thinking about what we need for a single AS WFS. 

New things that we would need:

Things we have:

  • Many Eurocard-style Whitening chassis, such as we use for all of the LSC PDs. 
  • Enough ADC (c1ioo has two ADCs, but doesn't even use 32 channels, so we can steal one, and throw it into c1lsc)

We'd have 12 new signals to acquire: 4 quadrants x DC, I, Q. In principle the DC part could go into a slow channel, but we have the ADC space to do it fast, and it'll be easier than mucking around with c1iscaux or whatever.

Open question: What to do about AA? A quick search didn't turn up any eurocard AA chassis like the ones we use for the LSC PDs. However, given the digital AA that happens from 64kHz->16kHz in the IOP, we've talked about disabling/bypassing the analog AA for the LSC signals. Maybe we can do the same for the QPD signals? Or, modify the post-demod audioband amplifer in the demod chassis to have some simple, not too agressive lowpass.

  12592   Wed Nov 2 22:56:45 2016 gautamUpdateCDSc1pem revamped

installing the BLRMS 2k blocks turned out to be quite non-trivial due to a whole host of CDS issues that had to be debugged, but i've restored everything to a good state now, and the channels are being logged. detailed entry with all the changes to follow.

  12593   Thu Nov 3 08:07:52 2016 SteveUpdateGeneralpower glitch

Building:         Campus Wide         

       

Date:             Thursday 11/03/16 at Approx. 6:20 a.m.   

          

Notification:     Unplanned City Wide Power Glitch Affecting Campus   

 

*This is to notify you that the Caltech Campus experienced a campus wide power glitch at approx. 6:20 a.m. this morning.

The city was contacted and they do not expect any further interruptions related to this event.

 

The vacuum was not effected. ITM sus damping restored. IFO room air conditions on.

PSL Innolight and ETMY Lightwave lasers turned on

 

Attachment 1: powerGlitch.png
powerGlitch.png
  12594   Thu Nov 3 11:33:24 2016 gautamUpdateGeneralpower glitch - recovery

I did the following:

  • Hard reboots for fb, megatron, and all the frontends, in that order
  • Checked time on all FEs, ran sudo ntpdate -b -s -u pool.ntp.org where necessary
  • Restarted all realtime models
  • Restarted monit on all FEs
  • Reset Marconi to nominal settings, fCarrier=11.066209MHz, +13dBm amplitude
  • In the control room, restarted the projector and set up the usual StripTool traces
  • Realigned PMC
  • Slow machines did not need any touchups - interestingly, ITMX did not get stuck during this power glitch!

There was a regular beat coming from the speakers. After muting all the channels on the mixer and pulling the 3.5mm cable out, the sound persisted. It now looks like the mixer is broken sad

     ProFX8v2

 

  12595   Thu Nov 3 12:38:42 2016 gautamUpdateCDSc1pem revamped

A number of changes were made to C1PEM and some library parts. Recall that the motivation was to add BLRMS channels for all our suspension coils and shadow sensor PDs, which we are first testing out on the IMC mirrors.

Here is the summary:

BLRMS_2k library block

  • The name of the custom C code block in this library part was named 'BLRMSFILTER' which conflicted with the name of the function call in the C code it is linked to, which lead to compilation errors
  • Even though the part was found in /opt/rtcds/userapps/release/cds/c1/models and not in the common repository, just to be safe, I made a copy of the part called BLRMS_2k_40m which lives in the above directory. I also made a copy of the code it calls in /opt/rtcds/userapps/release/cds/c1/src

C1PEM model + filter channels

  • Adding the updated BLRMS_2k_40m library part still resulted in some compilation errors - specifically, it was telling me to check for missing links around the ADC parts
  • Eric suggested that the error messages might not be faithfully reporting what the problem is - true enough, the problem lay in the fact that c1pem wasn't updated to follow the namespace convention that we now use in all the RT models - the compiler was getting confused by the fact that the BLRMS stuff was in a namespace block called 'SUS', but the rest of the PEM stuff wasn't in such a block
  • I revamped c1pem to add namespace blocks called PEM and DAF, and put the appropriate stuff in the blocks, after which there were no more compilation errors
  • However, this namespace convention messed up the names of the filter modules and associated channels - this was resolved with Eric's help (find and replace did the job, this is a familiar problem that we had encountered not too long ago when C1IOO was similarly revamped...)
  • There was one last twist in that the model would compile and install, but just would not start. I tried the usual voodo of restarting all the models, and even did a soft reboot of c1sus, to no avail. Looking at dmesg, I tracked the problem down to a burt restore issue - the solution was to press the little 'BURT' button next to c1pem on the CDS overview MEDM screen as soon as it appeared while restarting the model

All the channels seem to exist, and FB seems to not be overloaded judging by the performance overnight up till the power outage. I will continue to monitor this...

GV Edit 3 Nov 2016 7pm:

I had meant to check the suitability of the filters used - there is a detailed account of the filters implemented in BLRMSFILTER.c here, and I quickly looked at the file on hand to make sure the BP filters made sense (see Attachment #1). These the BP filters are 8th order elliptical filters and the lowpass filters are16th order elliptical filters scaled for the appropriate frequency band, which are somewhat different from what we use on the seismometer BLRMS channels, where the filters are order 4, but I don't think we are significantly overloaded on the computational aspect, and the lowpass filters have sufficiently steep roll-off, these should be okay...

Attachment 1: BLRMSresp.pdf
BLRMSresp.pdf
  12596   Thu Nov 3 12:40:10 2016 gautamUpdateGeneral projector light bulb is out

The projector failed just now with a pretty loud 'pop' sound - I've never been present when the lamp goes out, so I don't know if this is usual. I have left the power cable unplugged for now...

Replacement is ordered Nov 4

  12597   Thu Nov 3 13:36:16 2016 ericqUpdateCDSc1pem revamped

It seems that the EX and EY BLRMS banks were missing the BP and LP filters for the 0.03-0.1 and 0.1-0.3 bands. I've copied over the filters from the BS seismometer.

However, if it looks like the integrated C code BLRMS block works out well, we could replace the seismometers' filter module heavy BLRMS blocks and cut down on the PEM model bloat.

  12599   Fri Nov 4 18:31:05 2016 LydiaUpdateCDSc1auxex channels/pins for Acromag

Here are the channels we are planning to switch over from c1auxex to Acromag, and their current pin numbers on the existing VME boards. 

Analog inputs: 

C1:SUS-ETMX_UL_AIOut    #C0 S0
C1:SUS-ETMX_LL_AIOut    #C0 S1
C1:SUS-ETMX_UR_AIOut    #C0 S2
C1:SUS-ETMX_LR_AIOut    #C0 S3
C1:SUS-ETMX_Side_AIOut    #C0 S4
C1:SUS-ETMX_OL_SEG1    #C0 S5
C1:SUS-ETMX_OL_SEG2    #C0 S6
C1:SUS-ETMX_OL_SEG3    #C0 S7
C1:SUS-ETMX_OL_SEG4    #C0 S8
C1:SUS-ETMX_OL_X    #C0 S9
C1:SUS-ETMX_OL_Y    #C0 S10
C1:SUS-ETMX_OL_S    #C0 S11
C1:SUS-ETMX_ULPD    #C0 S12
C1:SUS-ETMX_LLPD    #C0 S13
C1:SUS-ETMX_URPD    #C0 S14
C1:SUS-ETMX_LRPD    #C0 S15
C1:SUS-ETMX_SPD    #C0 S16
C1:SUS-ETMX_ULV    #C0 S17
C1:SUS-ETMX_LLV    #C0 S18
C1:SUS-ETMX_URV    #C0 S19
C1:SUS-ETMX_LRV    #C0 S20
C1:SUS-ETMX_SideV    #C0 S21
C1:SUS-ETMX_ULPD_MEAN    #C0 S12
C1:SUS-ETMX_LLPD_MEAN    #C0 S13
C1:SUS-ETMX_SDPD_MEAN    #C0 S16

Analog Outputs:

C1:ASC-QPDX_S1WhiteGain    #C0 S0
C1:ASC-QPDX_S2WhiteGain    #C0 S1
C1:ASC-QPDX_S3WhiteGain    #C0 S2
C1:ASC-QPDX_S4WhiteGain    #C0 S3
C1:SUS-ETMX_ULBiasAdj    #C0 S4
C1:SUS-ETMX_LLBiasAdj    #C0 S5
C1:SUS-ETMX_URBiasAdj    #C0 S6
C1:SUS-ETMX_LRBiasAdj    #C0 S7
C1:LSC-EX_GREENLASER_TEMP    #C0 S0 This appears to have the same pin as another channel-- is it not being used? 

Binary Outputs:

C1:SUS-ETMX_UL_ENABLE    #C0 S0
C1:SUS-ETMX_LL_ENABLE    #C0 S1
C1:SUS-ETMX_UR_ENABLE    #C0 S2
C1:SUS-ETMX_LR_ENABLE    #C0 S3
C1:SUS-ETMX_SD_ENABLE    #C0 S4
C1:ASC-QPDX_GainSwitch1    #C0 S7
C1:ASC-QPDX_GainSwitch2    #C0 S8
C1:ASC-QPDX_GainSwitch3    #C0 S9
C1:ASC-QPDX_GainSwitch4    #C0 S10
C1:AUX-GREEN_X_Shutter2    #C0 S15

  12600   Sat Nov 5 15:45:44 2016 ranaUpdateCDSc1auxex channels/pins for Acromag

We don't need to record any of the AIOut channels, the OL channels (since we record them fast), or the _MEAN channels (I think they must be CALC records or just bogus).

  12601   Mon Nov 7 08:00:11 2016 SteveUpdateSUSSRM -PRM sat. amp swap

I just realized that Gautam set this test up and turned damping off......He will explane the details

 

Attachment 1: SRM.jpg
SRM.jpg
Attachment 2: SRM-UR_OK.png
SRM-UR_OK.png
  12602   Mon Nov 7 16:05:55 2016 gautamUpdateSUSPRM Sat. Box. Debugging

Short summary of my Sat. Box. debugging activities over the last few days. Recall that the SRM Sat. Box has been plugged into the PRM suspension for a while now, while the SRM has just been hanging out with no electrical connections to its OSEMs.

As Steve mentioned, I had plugged in Ben's extremely useful tester box (I have added these to the 40m Electronics document sub-tree on the DCC) into the PRM Sat. Box and connected it to the CDS system over the weekend for observation. The problematic channel is LR.  Judging by Steve's 2 day summary plots, LR looks fine. There is some unexplained behavior in the UR channel - but this is different from the glitchy behaviour we have seen in the LR channel in the past. Moreover, subsequent debugging activities did not suggest anything obviously wrong with this channel. So no changes were made to UR. I then pulled out the PRM sat.box for further diagnostics, and also, for comparison, the SRM sat. box which has been hooked up to the PRM suspension as we know this has been working without any issues. 

Tracing out the voltages through the LED current driver circuit for the individual channels, and comparing the performance between PRM and SRM sat. boxes, I narrowed the problem down to a fault in either the LT1125CSW Quad Op-Amp IC or the LM6321M current driver IC in the LR channel. Specifically, I suspected the output of U3A (see Attachment #1) to be saturated, while all the other channels were fine. Looking at the spectrum at various points in the circuit with an SR785, I could not find significant difference between channels, or indeed, between the PRM/SRM boxes (up to 100kHz). So I decided to swap out both these ICs. Just replacing the OpAmp IC did not have any effect on the performance. But after swapping out the current buffer as well, the outputs of U3A and U11 matched those of the other channels. It is not clear to me what the mode of failure was, or if the problem is really fixed. I also checked to make sure that it was indeed the ICs that had failed, and not the various resistors/capacitors in the signal path. I have plugged in the PRM sat. box + tester box setup back into our CDS data acquisition for observation over a couple of days, but hopefully this does the job... I will update further details over the coming days.

I have restored control to PRM suspensions via the working SRM sat. box. The PRM Sat. Box and tester box are sitting near the BS/PRM chamber in the same configuration as Steve posted in his earlier elog for further diagnostics...


GV Edit 2230 hrs 7Nov2016: The signs from the last 6 hours has been good - see the attached minute trend plot. Usually, the glitches tend to show up in this sort of time frame. I am not quite ready to call the problem solved just yet, but I have restored the connections to the SRM suspension (the PRM and SRM Sat. Boxes are still switched). I've also briefly checked the SRM alignment, and am able to lock the DRMI, but the lock doesn't hold for more than a few seconds. I am leaving further investigations for tomorrow, let's see how the Sat. Box does overnight.

Attachment 1: D961289-B2.pdf
D961289-B2.pdf
Attachment 2: PRMSatBoxtest.png
PRMSatBoxtest.png
  12603   Mon Nov 7 17:24:12 2016 gautamUpdateGreen LockingGreen beat setup on PSL table

I've been trying to understand the green beat setup on the PSL table to see if I can explain the abysmal mode-matching of the arm and PSL green beams on the broadband beat PDs. My investigations suggest that the mode-matching is very sensitive to the position of one of the lenses in the arm green path. I will upload a sktech of the PSL beat setup along with some photos, but here is the quick summary.

  1. I first mapped the various optical components and distances between them on the PSL table, both for the arm green path and the PSL green path
  2. Next, setting the PSL green waist at the center of the doubling oven and the arm green waist at the ITMs (in vacuum distances for the arm green backed out of CAD drawing), I used a la mode to trace the Gaussian beam profile for our present configuration. The main aim here was to see what sort of mode matching we can achieve theoretically, assuming perfect alignment onto the BBPDs. The simulation is simplified, the various beam splitters and other transmissive optics are treated as having 0 width
  3. It is pretty difficult to accurately measure path lengths to mm accuracy, so to validate my measurement, I measured the beam widths of the arm and PSL green beams at a few locations, and compared them to what my simulation told me to expect. The measurements were taken with a beam profiler I borrowed from Andrew Wade, and both the arm and PSL green beams have smooth Gaussian intensity profiles for the TEM00 mode (as they should!). I will upload some plots shortly. The agreement is pretty good, to within 10%, although geometric constraints on the PSL table limited the number of measurements I could take (I didn't want to disturb any optics at this point)
  4. I then played around with the position of a fast (100mm EFL) lens in the arm green path, to which the mode matching efficiency on the BBPD is most sensitive, and found that in a +/- 1cm range, the mode matching efficiency changes dramatically

Results:

Attachments #1 and 2: Simulated and measured beam profiles for the PSL and arm green beams. The origin is chosen such that both beams have travelled to the same coordinate when they arrive at the BBPD. The agreement between simulation and measurement is pretty good, suggesting that I have modelled the system reasonably well. The solid black line indicates the (approximate) location of the BBPD

     

Attachment #3: Mode matching efficiency as a function of shift of the above-mentioned fast lens. Currently, after my best efforts to align the arm and PSL green beams in the near and far fields before sending them to the BBPD results in a mode matching efficiency of ~30% - the corresponding coordinate in the simulation is not 0 because my length measurements are evidently not precise to the mm level. But clearly the mode matching efficiency is strongly sensitive to the position of this lens. Nevertheless, I believe that the conclusion that shifting the position of this lens by just 2.5mm from its optimal position degrades the theoretical maximum mode matching efficiency from >95% to 50% remains valid. I propose that we align the beams onto the BBPD in the near and far fields, and then shift this lens which is conveniently mounted on a translational stage, by a few mm to maximize the beat amplitude from the BBPDs. 

Unrelated to this work: I also wish to shift the position of the PSL green shutter. Currently, it is located before the doubling oven. But the IR pickoff for the IR beat setup currently is located after the doubling oven, so when the PSL green shutter is closed, we don't have an IR beat. I wish to relocate the shutter to a position such that it being open or closed does not affect the IR beat setup. Eventually, we want to implement some kind of PID control to make the end laser frequencies track the PSL frequency continuously using the frequency counter setup, for which we need this change...

Attachment 1: CurrentX.pdf
CurrentX.pdf
Attachment 2: CurrentY.pdf
CurrentY.pdf
Attachment 3: ProposedShift_copy.pdf
ProposedShift_copy.pdf
  12604   Mon Nov 7 19:49:44 2016 JohannesUpdateCDSacromag chassis hooked up to PSL

[Lydia, Johannes]

We're waiting on the last couple electrical components to arrive that are needed to complete the acromag chassis, but it is essentially operational. Right now it is connected to the PSL Mephisto's diagnostics port, for which only a single XT1221 A/D unit is needed. We assigned the IP address 192.168.113.121 to it. For the time being I'm running a tmux session on megatron (named "acromag") that grabs and broadcasts the epics channels, with Lydia's original channel definitions. Since the chassis is 4U tall, there's not really any place in the rack for it, so we might want to move it to the X-end before we start shuffling rack components around. Once we finalize its location we can proceed with adding the channels to the frames.

For the eventual gradual replacement of the slow machines, we need to put some thought into the connectors we want in the chassis. If we want to replicate the VME crate connectors we probably need to make our own PCB boards for them, as there don't seem to be panel-mount screw terminal blocks readily available for DIN 41612 connectors. Furthermore, if we want to add whitening/AA filters, the chassis may actually be large enough to accomodate them, and arranging things on the inside is quite flexible. There are a few things to be considered when moving forward, for example how many XT units we can practically fit in the chassis (space availability, heat generation, and power requirements) and thus how many channels/connectors we can support with each.

Steve: 1X3 has plenty of room

Attachment 1: acromag_chassis_location.jpg
acromag_chassis_location.jpg
Attachment 2: acromag_chassis_top_view.jpg
acromag_chassis_top_view.jpg
  12605   Tue Nov 8 08:51:59 2016 SteveUpdatePEMmouse hole sealed

This is where the mammal came though. It is reach able from room 108 CES

Quote:

We may have a mouse in the lab.  Do not leave any food scrap in trash ! Traps will be set.

 

 

Attachment 1: CES108rs.jpg
CES108rs.jpg
  12606   Tue Nov 8 11:54:38 2016 gautamUpdateSUSPRM Sat. Box. looks to be fixed

Looks like the PRM Sat. Box is now okay, no evidence of the kind of glitchy behaviour we are used to seeing in any of the 5 channels.

Quote:
 
GV Edit 2230 hrs 7Nov2016: The signs from the last 6 hours has been good - see the attached minute trend plot. Usually, the glitches tend to show up in this sort of time frame. I am not quite ready to call the problem solved just yet, but I have restored the connections to the SRM suspension (the PRM and SRM Sat. Boxes are still switched). I've also briefly checked the SRM alignment, and am able to lock the DRMI, but the lock doesn't hold for more than a few seconds. I am leaving further investigations for tomorrow, let's see how the Sat. Box does overnight.

 

  12607   Tue Nov 8 17:51:09 2016 LydiaUpdateCDSacromag chassis hooked up to PSL

We set up the chassis in 1X7 today. Steve is ordering a longer 25 pin cable to reach. Until then the PSL diagnostic channels will not be usable.

  12608   Wed Nov 9 11:40:44 2016 ericqUpdateCDSsafe.snap BURT files now in svn

This is long overdue, but our burt files for SDF now live in the LIGO userapps SVN, as they should.

The canonical files live in places like /opt/rtcds/userapps/release/cds/c1/burtfiles/c1x01_safe.snap and are symlinked to files like /opt/rtcds/caltech/c1/target/c1x01/c1x01epics/burt/safe.snap

  12609   Wed Nov 9 23:21:44 2016 gautamUpdateGreen LockingGreen beat setup on PSL table

I tried to realize an improvement in the mode matching onto the BBPDs by moving the lens mentioned in the previous elog in this thread. My best efforts today yielded X and Y beats at amplitudes -15.9dBm (@37MHz) and -25.9dBm (@25MHz) respectively. The procedure I followed was roughly:

  1. Do the near-field far-field alignment of the arm and PSL green beams
  2. Steer beam onto BBPD, center as best as possible using the usual technique of walking the beam across the photodiode
  3. Hook up the output of the scope to the Agilent network analyzer. Tweak the arm and PSL green alignments to maximize the beat amplitude. Then move the lens to maximize the beat amplitude.

As per my earlier power budget, these numbers translate to a mode matching efficiency of ~53% for the X arm beat and ~58% for the Y arm beat, which is a far cry from the numbers promised by the a la mode simulation (~90% at the optimal point, I could not achieve this for either arm scanning the lens through a maximum of the beat amplitude). Looks like this is the best we can do without putting in any extra lenses. Still a marginal improvement from the previous state though...

  12610   Thu Nov 10 19:02:03 2016 gautamUpdateCDSEPICS Freezes are back

I've been noticing over the last couple of days that the EPICS freezes are occurring more frequently again. Attached is an instance of StripTool traces flatlining. Not sure what has changed recently in terms of the network to cause the return of this problem... Also, they don't occur coincidentally on multiple workstations, but they do pop up in both pianosa and rossa.

Not sure if it is related, but we have had multiple slow machine crashes today as well. Specifically, I had to power cycle C1PSL, C1SUSAUX, C1AUX, C1AUXEX, C1IOOL0 at some point today

Attachment 1: epicsFreezesBack.png
epicsFreezesBack.png
  12611   Sat Nov 12 01:09:56 2016 gautamUpdateLSCRecovering DRMI locking

Now that we have all Satellite boxes working again, I've been working on trying to recover the DRMI 1f locking over the last couple of days, in preparation for getting back to DRFPMI locking. Given that the AS light levels have changed, I had to change the whitening gains on the AS55 and AS110 channels to take this into account. I found that I also had to tune a number of demod phases to get the lock going. I had some success with the locks tonight, but noticed that the lock would be lost when the MICH/SRCL boosts were triggered ON - when I turned off the triggering for these, the lock would hold for ~1min, but I couldn't get a loop shape measurement in tonight.


As an aside, we have noticed in the last couple of months glitchy behaviour in the ITMY UL shadow sensor PD output - qualitatively, these were similar to what was seen in the PRM sat. box, and since I was able to get that working again, I did a similar analysis on the ITMY sat. box today with the help of Ben's tester box. However, I found nothing obviously wrong, as I did for the PRM sat. box. Looking back at the trend, the glitchy behaviour seems to have stopped some days ago, the UL channel has been well behaved over the last week. Not sure what has changed, but we should keep an eye on this...

  12612   Sun Nov 13 23:42:43 2016 LydiaUpdateSUSETMX output matrix data

I took data of the ETMX SUSPOS, SUSPIT and SUSYAW channels while driving each of the 4 face coils. I manually turned off all the damping except the side. 

Excitation: I used white noise bandpassed from 0.4 to 5 Hz in order to examine the responses around the resonance frequencies. To avoid ringing things up too much, I started with a very weak drive signal and gradually increased it until it seemed to have an effect on the mirror motion by looking at the oplev signals/sensor RMS values on the SUS screen; it's possible I'll need to do it again with a stronger signal if there's not enough coherence in the data. 

Finding the matrix: The plan is to estimate the transfer function of the coil drive signal with the sensed degrees of freedom (specified by the already diagonalized input matrix). This transfer function can be averaged around the resonance peak for each dof to find the elements of the matrix that converts signals to dof responses, (the "response matrix", which is the inverse of the output matrix). Each column of the response matrix gets normalized so that the degrees of freedom influence the drive signals in the right ratio. 

Other notes: 

  • I had some trouble getting the awg python library to work: I had to manually edit a CDLL statement to use the absolute path of an .so file. I wasn't sure what environment variable to set to make it look in the right folder automatically.
  • The awg ArbitraryLoop object seems to be affected by cds getdata calls (The EXC signal stopes early and then stop() hangs) so I ended up doing the excitation and data reading in 2 separate scripts. 
  • Reminder that the watchdogs must be on "Normal" for the EXC signal to make it to the coils, so the damping must be turned off manually with the watchdogs still on if you want to drive without damping. 
ELOG V3.1.3-