40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 111 of 341  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  11963   Sat Jan 30 00:12:22 2016 gautamUpdateGreen LockingInnolight laser is 10 years old

 

Quote:

I don't think there's any evidence that the noise eater is bad. That would change the behavior of the relaxation oscillation which is at 1 MHz ?

While I was investigating the AM/PM ratio of the Innolight, I found that there was a pronounced peak in the RIN at ~400kHz, which did not change despite toggling the noise eater switch on the front panel (see plot attached). The plot in the manual suggests the relaxation oscillations should be around 600kHz, but given that the laser power has dropped by a factor of ~3, I think it's reasonable that the relaxation oscillations are now at ~400kHz? 

Attachment 1: RIN_comparison.pdf
RIN_comparison.pdf
  11964   Sat Jan 30 09:56:24 2016 KojiUpdateGreen LockingInnolight laser is 10 years old

It is strange that there is no difference between with and without NE, isn't it?

  11967   Mon Feb 1 15:16:28 2016 gautamUpdateGreen LockingInnolight laser is 10 years old

The Innolight laser control unit has a 25 pin D-sub connector on the rear which is meant to serve as a diagnostics aid, and the voltages at the various pins should tell us the state of various things, like the diode power monitor, laser crystal TEC error temperature, NE status etc etc. Unfortunately, I am unable to locate a manual for this laser (online or physical copy in the filing cabinets), so the only thing I have to go on is a photocopied page that Steve had obtained sometime ago from the manual for the 2W NPRO. According to that, Pin 1 is "Diode laser 1, power monitor, 1V/W". The voltage I measured (with one of the 25 pin breakout boards and a DMM) is 1.038V. I didn't see any fast fluctuations in this value either. It may be that the coefficient indicating "normal" state of operation is different for the 1W model than the 2W model, but this measurement suggests the condition of the diode is alright after all?

I also measured the voltage at Pin 12, which is described in the manual as "Noise Eater, monitor". This value was fluctuating between ~20mV and ~40mV. Toggling the NE switch on the front of the control unit between ON and OFF did not change this behaviour. The one page of the manual that we have, however, doesnt provide any illumination on how we are supposed to interpret the voltage measured at this pin...

  11968   Mon Feb 1 15:43:18 2016 KojiUpdateGreen LockingInnolight laser is 10 years old

This is the same one as what you got from Steve. But you can find full pages.

https://wiki-40m.ligo.caltech.edu/PSL/NPRO

  11987   Fri Feb 12 11:10:49 2016 SteveUpdateGreen LockingInnolight laser is 10 years old

It shipped out for repair evaluation.

Arrived to Hayward,CA   2016Feb16

 

Attachment 1: inno1W.jpg
inno1W.jpg
  4705   Thu May 12 22:54:20 2011 ranaUpdateDAQInput Beam Naming change (no more IP)

 We decided to rename the Input Beam channels (while keeping temporary backwards compatible aliases) as:

C1:ASC-IB_POS_X, C1:ASC-IB_POS_Y, C1:ASC-IB_ANG_SUM, etc.

  2584   Tue Feb 9 17:51:48 2010 JenneSummaryIOOInput Mode Matching Telescope design is complete

The upgrade's input mode matching telescope design is complete.  A summary document is on the MMT wiki page, as are the final distances between the optics in the chain from the mode cleaner to the ITMs.  Unless we all failed kindergarden and can't use rulers, we should be able to get very good mode matching overlap.  We seem to be able (in Matlab simulation land) to achieve better than 99.9% overlap even if we are wrong on the optics' placement by ~5mm.  Everything is checked in to the svn, and is ready for output mode matching when we get there.

  7012   Mon Jul 23 20:19:01 2012 LizUpdateComputer Scripts / ProgramsInput Needed (From everyone!)

The summary pages are now online (Daily Summary), and will eventually be found on the 40m Wiki page under "LOGS-Daily Summary". (Currently, the linked website is the former summary page site)

Currently, all of the IFO and Acoustic channels have placeholders (they are not showing the real data yet) and the Weather channels are not working, although the Weather Station in the interferometer room is working (I am looking into this - any theories as to why this is would be appreciated!!).

I am looking for advice on what else to include in these pages.  It would be fantastic if everyone could take a moment to look over what I have so far (especially the completed page from July 23, 2012) and give me their opinions on:

 

1.  What else you would like to see included

2.  Any specific applications to your area of work that I have overlooked

3.  What the most helpful parts of the pages are

4.  Any ways that I could make the existing pages more helpful

5.  Any other questions, comments, clarifications or suggestions

Finally, are the hourly subplots actually helpful?  It seems to me like they would be superfluous if the whole page were updating every 1-2 hours (as it theoretically eventually will).  These subplots can be seen on the July 24, 2012 page.

My email address is endavison@umail.ucsb.edu.

 Thank you!  

 

  11896   Tue Dec 22 16:23:33 2015 gautamUpdateIOOInput alignment to PMC tweaked

When I came in this afternoon, I saw that the PZT voltage to the PMC had railed. Following the usual procedure of turning the servo gain to zero and adjusting the DC offset, I got the PMC to relock, but the PMCR level was high and the alignment looked poor on the control room monitor. So I tweaked the input alignment on the PSL till I felt it was more reasonable. The view on the control room monitor now looks more like the usual state, and the "REFL (V)" field on the PMC MEDM screen now reads 0.02-0.03 which is the range I remember it being in nominally. 

  7699   Tue Nov 13 00:15:08 2012 JenneUpdateIOOInput and Output PZTs turned on

I turned on the power supplies for the output PZTs and pitch and yaw for PZT2.  This is back to the condition that we had during atmosphere alignment, so after Ayaka has finished tweaking the MC, we can have a look at alignment of the interferometer.

  8262   Fri Mar 8 20:51:00 2013 ManasaUpdateAlignmentInput beam drift - investigation **IMPORTANT**

Checking the drift in input pointing (TT2 is the main suspect)

I have centered IPPOS and the 2/3 part of IPANG that comes out of vacuum to the QPDs to see the drift in input pointing over the weekend or atleast overnight.

If anybody would be working with the IFO alignment over the weekend, do so only after recording the drift in IPANG and IPPOS or if you will be working later tonight, center them ion the QPDs before leaving.

  8267   Mon Mar 11 12:29:25 2013 ManasaUpdateAlignmentInput beam drift - weekend trend

I centered ipang and ippos on the QPDs (using only the steering mirrors) and wanted to see the drift over the weekend.

Observation
1. IPANG has drifted (QPD sum changed from -6 to -2.5); but it is still on the QPD.
2. IPPOS does not show any drift.
3. In the plot: The jump in IPANG on the left occured when I centered the beam to the QPD and that on the right is from the 4.7 earthquake and its aftershocks this morning.

Follow-up questions
1. Do we need to worry about this drift?
2. Which of the two TTs is resposible for the drift?
3. Do the TTs tend to drift in the same direction everytime?

P.S. The TTs were not touched to center on IPANG and IPPOS. The last time they were touched was nearly 6 hours before the centering. So the question of any immediate hysteresis is ruled out.

IPANG_drift.png

  8252   Thu Mar 7 18:12:03 2013 yutaUpdateAlignmentInput beam drift ~ 0.1 mrad/h in pitch

[Jenne, Manasa, Yuta]

We temporarily centered the beam on IPANG to see input pointing drift. From eyeball, drift was ~ 0.1 mrad/h in pitch.

What we did:

  1. Aligned TT1/TT2 and aligned input pointing to Yarm.

  2. Tweaked TT2 in pitch to center the beam on the first steering mirror of IPANG path. We still saw Yarm flash in higher order modes at this point. Before tweaking, the beam was hitting at the top edge.

  3. Centered the beam on IPANG QPD.

  4. Moved IPPOS first steering mirror because IPPOS beam was not on the mirror (off in yaw, on mirror edge). Also, IPPOS beam was coming out clipped in yaw.

  5. Centered the beam on IPPOS QPD. We put lens in the path to focus the beam on the QPD.

  6. Left input pointing untouched for 4 hours.

  7. Restored TT2 again. We tried to align Y arm with IPANG available, but it was not possible without touching TRY path and AS was also clipped.

Result:
  Below is the trend of IPANG sum, X, and Y. IPANG Y (IBQPD_Y) drifted by ~0.8 counts in 4 hours. IPANG is not calibrated yet, but Jenne used her eyeball to measure beam position shift on IPANG steering mirror. It shifted by ~2 mm. This means, input pointing drifts ~0.1 mrad/h in pitch.
IPangulardrift.png

Discussion:
  Compared with yaw, pitch drift is quite large considering beam size at ETMY(~5 mm). We can monitor input pointing drift in weekends get longer trend.

Note:
  - IPANG and IPPOS are both changed from the state before pumping.

  13827   Wed May 9 17:30:04 2018 gautamUpdateGeneralInput beam misaligned

There is no beam going into the IFO at the moment. There was definitely a spot on the AS camera after I restored the suspensions yesterday, as you can see from the ASDC level in Attachment #1. But at around 2pm Pacific yesterday, the ASDC level has gone to 0. I suspect the TTs. There is no beam on the REFL camera either when PRM is aligned, and PRM's DC alignment is good as judged by Oplev.

Normally, I am able to recover the beam by scanning the TTs around with some low frequency sine waves, but not today. We don't have any readback (Oplev/OSEM) of the TT alignment, and the DC bias values havent jumped abnormally around the time this happened, judging by the OUT16 monitor points (see Attachment #2). The IMC was also locked at the time when this abrupt drop in ASDC level happened. Unfortunately, we don't have a camera on the Faraday so I don't know where the misalignment is happening, but the beam is certainly not making it to the BS. All the SOS optics (e.g. BS, ITMX and ITMY) are well aligned as judged by Oplev.

Being debugged now...

Attachment 1: InputBeamGone.png
InputBeamGone.png
Attachment 2: TTpointing.png
TTpointing.png
  13828   Wed May 9 19:51:07 2018 gautamUpdateGeneralInput beam misaligned

As suspected - the problem was with the TTs. I tested the TT signal chain by driving a low frequency sine wave using AWG and looking at the signal on an o'scope. But I saw nothing, neither at the AI board monitor point, nor at the actual coil driver mon point. I decided to look at the IOP testpoints for the DAC channels, to see if the signals were going through okay on the digital side. But the IOP channels were flatlined, as viewed on dataviewer (see Attachment #1). This despite the fact that the DAC output monitor screen in the model itself was showing some sensible numbers, again see Attachment #1.

Looking at the CDS overview screen, there were no red flags. But there was a red indicator sneakily hidden away in the IOP model's CDS status screen, the "DAC" field in the state word is red. As Attachment #2 shows, a change in the state word is correlated with the time ASDC went to 0.

Note that there are also no errors on the c1lsc frontend itself, judging by dmesg. I want to do a model restart, but (i) this will likely require reboots of all vertex FEs and (ii) I want to know if any CDS experts want to sniff for clues to what's going on before a model restart wipes out some secret logfiles. I'm a little confused that the rtcds isn't throwing up any errors and causing models to crash if the values are not being written to the registers of the DAC. It may also be that the DAC card itself is dead sad. To re-iterate, all the EPICS readbacks were suggesting that I am injecting a signal right up to the IOP.

Quoting from the runtime diagnostics note:

NOTE: As V2.7, if this error is detected, the IOP will output zero values to all DAC modules, as a protective measure. Only method to clear this is to restart the IOP and all applications on that computer
Attachment 1: DACweirdness.png
DACweirdness.png
Attachment 2: DACerror.png
DACerror.png
  7210   Thu Aug 16 20:18:39 2012 YaakovUpdateSTACISInput for feedforward/feedback in the STACIS

Below is the bottom view of the geophone preamplifier and controller for the STACIS. It slides into the upper part of the STACIS, under the blue platform. The geophone signal goes in the bottom left, gets amplified, filtered, and otherwise pampered, and goes out from the bottom right. From there it goes on to the high voltage amplifier, and finally to the PZT stacks. Below right is a closer view of the output port for the preamplifier, top and bottom.

SAM_0256.JPGSAM_0259.JPGSAM_0258.JPG

I suggest de-soldering and bending up the pins that carry the geophone signal (so the signals don't go directly to the high voltage amplifier), and adding the circuit below between the preamp and amplifier. The preamp connector is still attached to the high voltage amplifier connector in this setup, only the geophone signal pins are disconnected.

x-chip.png

More on the circuit and its placement:

The first op-amp is a summing junction, and the second is just a unity gain inverter so that signal doesn't go into the high voltage amplifier inverted. I tested this with the breadboard, and it seems to work fine (amplitudes of two signals add, no obvious distortion). The switches allow you to choose local feedback, external feedforward, or both.

The geo input will be wires from the preamp (soldered to where the pins used to go), and the external input will be BNC cables, with the source probably a DAC. The output will go to the bent up pins that used to be connected to the preamp (they go into the high voltage amplifier). This circuit can sit outside of the STACIS- there is a place to feed wires in and out right near where the preamplifier sits. For power, it can use the STACIS preamp supply, which is +/- 15V. The resistors I used in the breadboard test were 10 kOhm, and the op-amp I used was LT1012 (whose noise should be less than either input, see eLog 7190).

This is visually represented below, with the preamp pin diagram corresponding to the soldering points with the preamp upside down (top right picture):

SAM_0266.JPGSAM_0265.JPG

 

  5438   Fri Sep 16 17:16:15 2011 JenneUpdateSUSInput matrix diagonalization: Fail!

[Jenne, Anamaria]

I put the new matricies in from the free swinging test for the: ITMX, ITMY, ETMX, ETMY, PRM, BS

Some of the optics damped okay, but ETMX and BS were not good at all.  ETMX was ringing up when I turned on the damping.  BS wasn't, but when I gave it a kick, it wouldn't damp.  No good.

I tried ITMY, and it was totally fine, with nice damping Qs of ~5.  So, I don't know what's going on. 

Anamaria is trying a new 4x4 matrix-inverter, so we can look at the inversion of just the face osems.  We'll see how it goes. 

Since things were crappy, I did a BURT restore, so things are as they were earlier this morning.

  4653   Fri May 6 15:42:55 2011 valeraMetaphysicsIOOInput mode cleaner length and 11 MHz modulation frequency

 After Kiwamu set the REFL11 phases in the PRMI configuration (maximized PRM->REFL11I reesponse) I tried to measure the MC length and the 11 MHz frequency missmatch by modulating the 11 MHz frequency and measuring the PM to AM conversion after the MC using the REFL11Q signal. The modulation appears in the REFL11Q with a good snr but the amplitude does not seem to go through a clear minimum as the 11 MHz goes through the MC resonance.

We could not relock the PRMI during the day so I resorted to a weaker method - measuring the amplitude of the 11 MHz sideband in the MC reflection (RF PD mon output on the demod board) with a RF spectrum analyzer. The minimum frequency on the IFR is 11.065650 MHz while the nominal setting was 11.065000 MHz. The sensitivity of this method is about 50 Hz.

  15567   Thu Sep 10 15:43:22 2020 JonUpdateBHDInput noise spectra for A+ BHD modeling

As promised some time ago, I've obtained input noise spectra from the sites calibrated to physical units. They are located in a new subdirectory of the BHD repo: A+/input_noises. I've heavily annotated the notebook that generates them (input_noises.ipynb) with aLOG references, to make it transparent what filters, calibrations, etc. were applied and when the data were taken. Each noise term is stored as a separate HDF5 file, which are all tracked via git LFS.

So far there are measurements of the following sources:

  • L1 SRCL
  • H1 SRCL
  • L1 DHARD PIT
  • L1 DSOFT PIT
  • L1 CSOFT PIT
  • L1 CHARD PIT

These can be used, for example, to make more realistic Hang's bilinear noise modeling [ELOG 15503] and Yehonathan's Monte Carlo simulations [ELOG 15539]. Let me know if there are other specific noises of interest and I will try to acquire them. It's a bit time-consuming to search out individual channel calibrations, so I will have to add them on a case-by-case basis.

  15181   Fri Jan 31 16:04:30 2020 gautamUpdateIOOInput pointing drift

One factor which hampers locking efforts is the apparent drift of the input beam into the IFO. Over timescales of ~1 hour, I have noticed that the spot on the AS camera drifts significantly (~1 spot size) in pitch. The IPPOS QPD bears out this observation, see Attachment #1. The IMC WFS control signals do not show a correlated drift, hence my claim that the TTs are to blame.

I am able to correct this misalignment by moving TT1 in pitch (see Attachment #2, which shows some signals from a ~1 hour PRMI lock, during which time the pointing drifted, and I corrected it by moving TT1 pitch). Assuming the problem is purely TT1 pitch drifting, this corresponds to 3mm / 6m ~500urad of shift in 1 hour - seems very large. The fact that the drift is only present in pitch and doesn't really show up in yaw makes me think the problem is likely mechanical (unless the voltage to the top two coils is drifting relative to the bottom, but no LR drift, which would be very coincidental). At the moment, this is just an annoyance, but it'd be good for this problem to be fixed.

I haven't yet figured out how to make ndscope export these plots to SVG preserving the dark color theme, hence the weird light axes...

Attachment 1: IPdrift.pdf
IPdrift.pdf
Attachment 2: IPdrift_PRMI.pdf
IPdrift_PRMI.pdf
  15841   Wed Feb 24 12:29:18 2021 gautamUpdateGeneralInput pointing recovered

While working at the LSC rack, I lost the input pointing into the IFO (the TT wiring situation is apparently very fragile, and this observation supports the hypothesis that the drifting TTs are symptomatic of some electronics issue). After careful beam walking, it was recovered and the dither alignment system was used to maximize TRX/TRY once again. No lasting damage done. If I can figure out what the pin-mapping is for the TT coils in vacuum, I'm inclined to try installing the two HAM-A coil drivers to control the TTs. Does anyone know where I can find said pin-out? The wiki page links seem broken and there isn't a schematic available there...

Ok it should be possible to back it out from the BOSEM pin out, and the mapping of the in-vacuum quadrupus cable, though careful accounting of mirroring will have to be done... The HAM-A coil driver actually already has a 15 pin output like the iLIGO coil drivers that are currently in use, but the pin mapping is different so we can't just replace the unit. On the bright side, this will clear up 6U of rack space in 1Y2. In fact, we can also consider hooking up the shadow sensor part of the BOSEMs if we plan to install 2 HAM-A coil drivers + 1 Dual satellite amplifier combo (I'm not sure if this number of spares is available in what we ordered from Todd).

  3114   Thu Jun 24 11:16:32 2010 Sharmila, Rana and KiwamuHowToVACInspection of the BS (sorry, no sounds)
  3093   Mon Jun 21 14:21:34 2010 Jenne, KiwamuUpdatePhotosInspection of Magnets for the TTs

Some pictures of "magnet inspection" from Picasa.

The coating of some magnets are chipped...

  3095   Mon Jun 21 20:11:21 2010 KojiUpdatePhotosInspection of Magnets for the TTs

Were these magnets chipped before the Ni plating?

RA: Yes, it looks like this is the case. We also smashed some of the magnets against a metal surface and saw that a black grime was left. We should hold the magnets with a clean teflon clamp to measure the Gauss. Then we have to wipe the magnets before installing. I share Jenne's concern about the press-fit damaging the plating and so we need to consider using using glue or the ole magnetic attachment method. We should not rely on the structural integrity of the magnets at all.

  15865   Thu Mar 4 23:57:35 2021 KojiSummaryElectronicsInspection of the new custom dsub cables

I made the inspection of the new custom DSub cables (came from Texas).

The shelled version gives us some chance to inspect/modify the internal connections. (good)
The wires are well insulated. The conductors are wrapped with the foils and then everything is in the braid tube shield. The braid is soldered on one of the connectors. (Attachment  3/4 shows the soldering of the conductor by intentionally removing one of the insulations).

It wasn't clear that if the conductors are twisted or not (probably not).

Attachment 1: 20210304235251_IMG_0527.jpg
20210304235251_IMG_0527.jpg
Attachment 2: 20210304235302_IMG_0528.jpg
20210304235302_IMG_0528.jpg
Attachment 3: 20210304235339_IMG_0529.jpg
20210304235339_IMG_0529.jpg
Attachment 4: 20210305000050_IMG_0530.jpg
20210305000050_IMG_0530.jpg
Attachment 5: 20210305000610_IMG_0531.jpg
20210305000610_IMG_0531.jpg
Attachment 6: 20210305000615_IMG_0532.jpg
20210305000615_IMG_0532.jpg
  14175   Wed Aug 22 00:22:05 2018 KojiSummaryElectronicsInspection of the possible dual backplane interfaces for Acromag DAQ

[Johannes, Koji]

We went around the LSC, PSL, IOO, and SUS racks to check how many dual backplane interfaces will be required.

Euro card modules are connected to the backplane with two DIN 41612 connectors (as you know). The backplane connectors provide DC supplies and GND connections.
In addition, they are also used for the input and output connections with the fast and slow machines.

According to the past inspection by Johannes, most of the modules just use the upper DIN41612 connector (called P1). But there are some modules exhibited the possibility of the additional use of the other connector (P2).

Tuesday afternoon Johannes and I made the list of the modules with the possible dual use. And I took a time to check the modules with DCC, Jay's schematics, and the visual inspection of the actual modules.

LSC Rack

  • Common mode servo (D040180 Rev B)
    • Schematic source D040180 Rev B D1500308
    • Assesment: Both P1 and P2 are to be connected to Acromag, but there are only a few channels on P2
    • P1: 1A-32A Digital In
    • P2: 1A-3A Analog Out (D32/33/34, SLOW MON and spare?)
            9A Digital Out for D35 (Limitter)
            10A-15A Spare
            16A Digital In (Latch Enable/Disable)
            25A, 25C  Differential Analog in (Differential offset input, indicated as "BIAS") 
  • PD Interface (D990543 Rev B)
    • Schematic source D990543 RevB
    • Assesment: No connection necessary. We don't monitor/control anything of any LSC PDs from Acromag.

PSL Rack

  • Generic DAQ Interface (D990155) - This is a DAC interface.
    • Schematic source: Jay's page D990155 Rev.B All the lines between P2 and P3 are connected.
    • Assesment: Only P2 is to be connected to Acromag.
    • P1 DAC mon -> not necessary
    • P2 A1-A16, Connected to DAC in P2-P3
  • PMC Servo
    • Schematic source: LIGO DCC D980352
    • Assesment: Only P1 (1A-9A) is to be connected to Acromag. (Just one DSub is sufficient)
    • P1 1A-9A
  • Crystal Ref (D980353)
    • Schematic source: LIGO DCC D980353
    • Assesment: Only P1 (1A-4A) is to be connected to Acromag. (Just one DSub is sufficient)
    • P1 1A-4A
  • TTFSS REV A
    • Schematic source: PNot found
    • Assesment: Probably Only P1 is sufficient. We need to analyze the board to figure out the channel assignment.

IOO Rack

  • PD Interface (D990543 Rev B)
    • Schematic source D990543 RevB
    • Assesment: Only P1 connection is sufficient.
  • Generic DAQ Interface (D990155)
    • Assesment: Remove the module. We already have the same module in PSL Rack. This is redundant.
  • Common mode servo (D040180 Rev B)
    • See above
  • Pentek Generic Input Board D020432
    • Schematic source Jay's page D020432-A
    • Assesment: No connection. There is no signal on the backplane.

SUS Rack

  • SUS Dewhitening
    • Schematic source: Jay's page D000316-A
    • Assesment: No connection.
    • We can omit Mon CHs.
    • Bypass/Inputs are already connected to the fast channels.

 

  14177   Wed Aug 22 12:22:27 2018 ranaSummaryElectronicsInspection of the possible dual backplane interfaces for Acromag DAQ

I think we don't need to keep Crystal Ref: we can change this into a regular Wenzel box with no outside control or monitoring.

Quote:

 

  • Crystal Ref (D980353)
    • Schematic source: LIGO DCC D980353
    • Assesment: Only P1 (1A-4A) is to be connected to Acromag. (Just one DSub is sufficient)
    • P1 1A-4A

 

  5672   Sat Oct 15 17:06:20 2011 KojiUpdateLSCInstallation REFL165

REFL165 was installed on the AP table last night.

Meanwhile I found the DC power level at the REFL PDs were 0.8~1.2V if the PRM is aligned and the IFO is not locked.
This corresponds to 16~24mA (20~30mW). This is too big.

The HWP of the REFL path were adjusted so that we have 6~10mA (8~12mW) on each PDs.

  4002   Wed Dec 1 02:39:00 2010 SureshUpdateSUSInstallation of ETMU07 as ETMX

[Kiwamu, Jenne, Koji, Suresh]

The following steps in this process were completed.

1)  Secured the current ETMX (Old ETMY) with the earth quake stops.

2) Removed the OSEMs and noted the Sl no. of each and its position

3) Placed four clamps to mark the location of the current ETMX tower (Old ETMY's position on the table)

4) Moved the ETMX (Old ETMY) tower to the clean table flow bench.  In the process the tower had to be tilted during removal because it was too tall to pass upright through the vacuum chamber port.  It was scary but nothing went wrong.

5) Koji calculated the location of the new ETMX and told us that it should be placed on the north end of the table.

6) Moved the OSEM cables, counter balancing weights and  the 'chopper' out of the way.  Had to move some of the clamps securing the cables.

7) Moved the ETMU07 tower from the clean room to the ETMX table

8) Positioned the OSEMs as they were placed in the earlier tower and adjusted their position to the middle of the range of their shadow sensors.  The four OSEMs on the face did not give us any trouble and were positioned as required.  But the side OSEM could not be put in place.  The magnet on the left side, which we are constrained to use since the tower is not designed to hold an OSEM on the right side, seems a little too low (by about a mm) and does not interrupt the light beam in the shadow sensor.  The possible causes are

   a) the optic is rotated.  To check this we need to take the tower back to the clean room and check the location of the optic with the traveling microscope.  If indeed it is rotated, this is easy to correct.

   b) the magnet is not located at the correct place on the optic.  This can also be checked on the clean room optical bench but the solution available immediately is to hold the OSEM askew to accommodate the magnet location.  If time permits the magnet position can be corrected.

We have postponed the testing of the ETMU07 tower to 1st of Nov Dec.

 

  10261   Wed Jul 23 11:15:54 2014 AkhilUpdateElectronicsInstallation of FCs in the 40m

 As a part of installation of two(X-ARM and Y-ARM) frequency counters in the 40m, I have tested their performance when using them both on a single Raspberry Pi. The timing plots are attached. There are almost no timing issues in this configuration and it can be said that there is no harm using both of the FCs on the same platform.

We will be installing the FC box inside the lab and carry out few tests with RF mon beat note inputs.

Attachment 1: Timingwith2FCs.png
Timingwith2FCs.png
  6090   Thu Dec 8 16:54:05 2011 JenneUpdateRF SystemInstallation of new demod box

So far:

* New demod box has been placed in the LSC rack.

* An extra set of +\- 24V has been prepared at the terminal block where all the Crates get their power on the LSC rack.  The grounds were all connected up, but the hot wires weren't.  So there were extra spots available, but none that were pre-wired with my voltages.

     * To do this I turned off all the power supplies in the short rack, since I decided to be a live chicken rather than a dead duck.  After hooking up the new terminal block slots, I turned on the power supplies.

 * Make a power cable to go from the terminal block to the box

Still to do:

 * Connect the spare 55MHz LO and the POP (or POX or POY) unused 11MHz LO to the back of the box

 * Move the PD inputs to the new demod box rather than the borrowed AS11 and POP55 boards

 * Plug the I & Q outs for each freq into some spare ADC channels - must first make sure we have 4 open channels.

 * See if it works.

  15500   Fri Jul 24 15:40:59 2020 JordanUpdateVACInstallation of two new UPS units

I installed the Tripp Lite SMX1000RT2U and Tripp Lite Smart1000LCD at the bottom of the 1x8 electronics rack. These are plugged in to power, and are ready for testing. All other cables (serial, usb, etc.) have been left on the table next to the 1x8 rack.

Attachment 1: UPS.jpg
UPS.jpg
  16826   Tue May 3 14:02:09 2022 AnchalSummaryBHDInstalled POP path in ITMX Chamber

[Anchal, JC]

I installed POP_SM4 and POP_SM5 in the ITMX chamber in the nominal positions. This must have affected the ITMX Oplev because I could see that one of the ITMX oplev beam was going through POP_SM5. It needs to be changed in order to follow the original plan. However, since POP_SM5 is a 1064 line mirror, it is transparent to the opleve beam, so maybe we can just use the ITMX oplev in the current fashion.

Next steps:

  • Get flashing back on the XARM.
  • Try to get the correct phase angle in POX11 so that we can lock XARM with IR too.
  • Inspect ITMX Oplev. The quadrant sum is low so maybe it needs adjustment in the in-ar table.
  • Check if ITMX oplev path needs to be adjusted inside the chamber.
  15916   Fri Mar 12 18:10:01 2021 AnchalSummaryComputer Scripts / ProgramsInstalled cds-workstation on allegra

allegra had fresh Debian 10 installed on it already. I installed cds-workstation packages (with the help of Erik von Reis). I checked that command line caget, caput etc were working. I'll see if medm and other things are working next time we visit the lab.

  10905   Thu Jan 15 18:06:34 2015 JenneUpdateComputer Scripts / ProgramsInstalled kerberos on Rossa

I have installed kerberos on Rossa, so that I don't have to type my name and password every time I do an svn checkin, since I'm making some modifications and want to be sure that everything is checked in before and afterwards. 

I ran sudo apt-get install krb5-user.  I didn't put in a default_realm when it prompted me to during install, so I went into the /etc/krb5.conf file and changed the default_realm line to read default_realm = LIGO.ORG

Now we can use kinit, but we must (as usual) remember to kdestroy our credentials when we're done.

As a reminder, to use:

> kinit albert.einstein

Password for albert.einstein@LIGO.ORG: (type your pw here)

When you're finished, run

> kdestroy

The end.

  10906   Thu Jan 15 18:10:19 2015 jamieUpdateComputer Scripts / ProgramsInstalled kerberos on Rossa
Quote:

I have installed kerberos on Rossa, so that I don't have to type my name and password every time I do an svn checkin, since I'm making some modifications and want to be sure that everything is checked in before and afterwards. 

I ran sudo apt-get install krb5-user.  I didn't put in a default_realm when it prompted me to during install, so I went into the /etc/krb5.conf file and changed the default_realm line to read default_realm = LIGO.ORG

Now we can use kinit, but we must (as usual) remember to kdestroy our credentials when we're done.

As a reminder, to use:

> kinit albert.einstein

Password for albert.einstein@LIGO.ORG: (type your pw here)

When you're finished, run

> kdestroy

The end.

WARNING: since the workstations are all shared user, if you forget to kdestroy the next user can commit under your user ID.  It might be good to set the timeout to be something much shorter than 24 hours, like maybe 1, or 2.

  10907   Thu Jan 15 18:30:18 2015 JenneUpdateComputer Scripts / ProgramsInstalled kerberos on Rossa

 

Quote:

WARNING: since the workstations are all shared user, if you forget to kdestroy the next user can commit under your user ID.  It might be good to set the timeout to be something much shorter than 24 hours, like maybe 1, or 2.

Good call.  I added a line ticket_lifetime = 3600, which should make it destroy the credentials after an hour.

  4511   Mon Apr 11 19:09:59 2011 SureshUpdateRF SystemInstalled low pass filters in the demod boards

 

As part of the RF system upgrade some of the demod boards in the lab were modfied.  The filter U5 (see the circuit schematic) was replaced. These changes are tabulated below.

 

Filters installed in the demod boards
Serial number Old name of the card New name of the card Filter installed Remarks
107 POY33 REFL33 SCLF-33+ R14=50Ohm
118 AP133, ASDD133 REFL55 SCLF-65  
114 PO199 REFL165 SCLF-190 R14=50Ohm
120 PO133 POP110 SCLF-135  
123 SP133 POP55 SCLF-65+ AT1 removed, R14=50Ohm
122 SP199, REFLDD199 AS165 SCLF-190  
121 SP166, REFL16 POP11 SCLF-10.7  
116 AP199 199 MHz POP165 SCLF-190  
126 AS166 33.3 MHz POX11 SCLF-10.7  
119 POX 33.3 MHz POY11 SCLF-10.7  
021 24.5 MHz (LLO) REFL11 SCLF-10.7  
020 24.5 MHz SCLF-45 POP22 SCLF-21.4  
022 24.5 MHz SCLF-45 AS11 with amp SCLF-10.7  
029 24.5          SCLF-f5 AS55 with amp SCLF-65  

 

Next, I and Q phase has to be checked for orthogonality. And noise levels of the cards have to measured.

 

 

 

  4514   Mon Apr 11 23:35:02 2011 ranaUpdateRF SystemInstalled low pass filters in the demod boards

I am a little concerned about using these low pass filters so close to the band edge. Recall that there is no on-board preamp for the RF input to the mixer.

So, if the input impedance of the filters is not 50 Ohms, we will get some unwanted reflections and sensitivity to cable length.

I think its worth while to check the impedance or S-parameters of these things with the LO activated to find out if we need to remove them or not.

  10890   Tue Jan 13 03:47:46 2015 ericqUpdateCDSInstalled new ethernet driver on Chiara

Chiara threw another network hissy fit. Dmesg was spammed with a bunch of messages like eth0: link up appearing rapidly. 

Some googling indicated that this error message in conjuction with the very ethernet board and driver that Chiara had in use could be solved by updating with an appropriate driver from the manufacturer.

In essence, I followed steps 1-7 from here: http://ubuntuforums.org/showthread.php?t=1661489

So far, so good. We'll keep an eye out to see how it works...

  4238   Wed Feb 2 09:56:55 2011 KojiSummaryGreen LockingInstalled the freq divider and Rana's PFD

- The freq divider and Rana's PFD were hooked up to the ADCs. (Attachment 1)
(I leave the analog PFD not explained in this entry.)
For this purpose, the VCO feedback signal has been disconnected and the beat signal was moved from the VCO loop to the analog PFD.

The output level of the splitter was +12dBm and was too high for the freq divider.
So, I had to stupidly add an attenuator of 10dB before the box.

- Gain of the digital PFD LPF

The LPF of the digital PFD had the gain of -4096 to let the output signal indicate the direct frequency reading.

The gain has been changed to -67.108864
such that the output shows the direct reading of the beat freq in the unit of MHz

-4096*2^14/10^6 = -67.108864

 

- Attachment 2 shows the acquired beat note through the freq divider.
The blue is the beat note between "green locked" and "IR locked only to MC" (i.e. MC vs XARM)
The red is the beat note with the both beam locked to the arm

The freq divider is a bit flaky in some freq region as the divided output sometimes shows freq jumps or the captured at a freq.
I still don't know why it happens. We have to check why this happens.

Attachment 1: freq_divider_installation.pdf
freq_divider_installation.pdf
Attachment 2: 110201_freq_divider_output.pdf
110201_freq_divider_output.pdf
  3650   Tue Oct 5 13:59:17 2010 Leo SingerConfigurationComputersInstalled x264-devel on Allegra

 I installed the package x264-devel on allegra.martian.  This package provides headers and libraries for the popular h264 video codec.  I am going to use this in the GStreamer streaming media server on Allegra.

  4806   Fri Jun 10 18:49:40 2011 kiwamuUpdateIOOIntensity Noise after the MC

Last night the relative intensity noise (RIN) of the beam after MC was measured.

It looks like the RIN is dominated by the motion of the MC mirrors, possibly the angular motions because we don't have any angular stabilization servos.

Suresh will estimate the contribution from the MC mirrors' angular motion to the RIN in order to see if this plot makes sense.

 

(RIN)

 The spectrum below 30 Hz seems to be dominated by the motion of the MC suspensions because it very resembles the spectra of those.

Above 30 Hz the spectrum becomes somehow flat, which I don't know why at the moment.

A rough estimation of the shot noise gave me a level of 10^{-9} RIN/sqrtHz, which is way below the measured spectrum.

RIN_afterMC.png

 

(Setup)

 All of the suspended mirrors were intentionally misaligned except for the MC mirrors and PRM to avoid interference from the other optics.

In this setup it allows us to measure the intensity noise of the laser which is transmitted from MC.

The beam transmitted from MC is reflected by PRM and finally enters into the REFL11 RFPD.

The DC signal from the RFPD was acquired at C1:LSC-REFL_DC_DQ as the laser intensity.

As well as the RIN measurement I took a spectrum when the beam is blocked by a mechanical shutter on the PSL table.

This data contains the dark noise from REFL11 and circuit noise from the whitening, AA board and ADC. It is drawn in black in the plot.

The cut off at 15 Hz is possibly due to the digital unwhitening (two poles at 15 Hz and two zeros at 150 Hz) filter to correct the analog whitening filter.

  8224   Mon Mar 4 19:38:21 2013 CharlesUpdateGeneralIntensity Stabilization and Control Systems

 I have been studying Jamies master's thesis concerning intensity stabilization of a solid-state laser (the 1064 nm specifically) to the ~10^-9 level, as well as relevant supporting material. I have also been reading about general control systems, photodiodes and acousto-optic modulators to help facilitate work on the ISS. 

Now that Altium has been properly installed, I have also begun familiarizing myself with the program and general libraries of boards and devices that have already been modeled with the program.

  4392   Wed Mar 9 18:17:11 2011 kiwamuUpdateGreen LockingIntensity noise coupling

Here is a new plot for the differential noise measurement. I plot a noise contribution from the intensity noise (brown curve).

If we believe this data, the differential noise is NOT dominated by the intensity noise of the PSL.

diff_noise.png

 


(intensity noise coupling measurement)

 Here is a plot for the transfer functions (TFs) from the intensity noise DCPD to the beat signal.

IN_TF.png

   In principle these TFs tell us how much intensity noise are contributed into the differential noise.

When I measured the spectra shown above, the frequency offset of the beatnote was at about 8 MHz from the zero cross point.

Keeping the same lock, I measured the transfer function (red curve) by using the swept sine technique on DTT. The setup for this measurement is depicted on the last entry (#4389).

Then I made the spectra above by multiplying the intensity spectrum by this TF.

  Later I measured another transfer function when the beatnote was at about 2 MHz from the zero cross point.

According to this measurement, our MFD gets insensitive to the intensity noise as the beat offset goes close to the zero cross point. This is consistent with what we expected.

  4397   Thu Mar 10 14:06:54 2011 kiwamuUpdateGreen LockingIntensity noise limits the beatnote sensitivity

We are limited by the intensity noise of the X arm transmitted green light.

Since the intensity noise from the PSL wasn't big enough to explain the differential noise (#4392), so this time I measured the noise contribution from the X arm transmitted light.
diff_noise_Mar8.png

 


(coupling measurement)

  IN_TF_complete.png

  I performed the same intensity noise coupling measurement, but this time between the DC signal of the beatnote RFPD and the beatnote signal.

 While measuring it, I excited the intensity of the PSL laser by using the same AOM like I did yesterday. This AM cause the observable intensity noise on the beatnote RFPD.

With the excited AM, we can pretend to have an excited AM on the green transmitted light from the X arm, of course assuming the intensity noise coupling from the PSL is less.

  4398   Thu Mar 10 14:22:58 2011 kiwamuUpdateGreen LockingIntensity noise limits the beatnote sensitivity

The next steps we should do are :

    - to investigate a cause of the intensity fluctuation
          * end green laser
          * suspensions' angular motions
          * doublecheck the RIN contribution if it's from the PSL or the X arm in the beatnote RFPD to make sure the RIN is dominated by the X arm transmitted light
  
    - to think about how to make the system insensitive to the intensity noise
          - bring the beat frequency to the zero cross point of the MFDs ?
          - PLL ?

Quote:

We are limited by the intensity noise of the X arm transmitted green light.

  4399   Thu Mar 10 14:29:05 2011 KojiUpdateGreen LockingIntensity noise limits the beatnote sensitivity

We can modify the freq divider circuit to make it a comparator.

Quote:

The next steps we should do are :

    - to investigate a cause of the intensity fluctuation
          * end green laser
          * suspensions' angular motions
          * doublecheck the RIN contribution if it's from the PSL or the X arm in the beatnote RFPD to make sure the RIN is dominated by the X arm transmitted light
  
    - to think about how to make the system insensitive to the intensity noise
          - bring the beat frequency to the zero cross point of the MFDs ?
          - PLL ?

Quote:

We are limited by the intensity noise of the X arm transmitted green light.

 

  4400   Thu Mar 10 14:30:53 2011 ranaUpdateGreen LockingIntensity noise limits the beatnote sensitivity

There are 3 standard techniques to reduce this effect:

1) Stabilize the end laser by sensing the green light coming into the PSL before recombination and feeding back with SR560 (this is the only one that you should try at first).

2) Moving to the center of the MFD fringe via ETM steps.

3) Auto-alignment of the beam to the arm.

  4383   Tue Mar 8 06:29:06 2011 kiwamuUpdateGreen LockingIntensity noise setup

[Jenne, Chris, Kiwamu]

 A photo diode and an AOM driver have been newly setup on the PSL table to measure the intensity noise coupling to the beat note signal.

We tried taking a transfer function from the PD to the beat, but the SNR wasn't sufficient on the PD. So we didn't get reasonable data.

 

(what we did)

  - put a DCPD after the doubling crystal on the PSL table. The PD is sitting after the Y1 mirror, which has been used for picking off the undesired IR beam.

  - installed the AOM driver (the AOM itself had been already in place)

  - injected some signals onto the AOM to see if we can see an intensity fluctuation on the PD as well as the beat signal

 

(intensity noise)

  In order to have better SNR for the intensity measurement, we put an AC coupled SR560 with the gain of 100 just before the ADCs.

When a single frequency signal was applied from a Stanford Research's function generator to the AOM, we could clearly see a peak at the doubled frequency of the injected signal.

Also a peak at the same frequency was found on the beat note signal as well.

But when random noise was injected from the same function generator, the random noise looked below the ADC noise.

Jenne adjusted the output voltage from the PD to about 1 V to avoid a saturation in the analog path, but later we realized that the ADC counts was marely ~ 20 counts.

So we will check the ADC tomorrow. Hopefully we will get a good SNR.

ELOG V3.1.3-