40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 207 of 341  Not logged in ELOG logo
ID Date Author Type Category Subjectdown
  12277   Fri Jul 8 19:33:16 2016 PrafulUpdateComputer Scripts / ProgramsMEDM Tab on Summary Pages

A new MEDM tab has been added to the summary pages (https://nodus.ligo.caltech.edu:30889/detcharsummary/day/20160708/medm/), although some of the screens are not updated when /cvs/cds/projects/statScreen/cronjob.sh is run. In /cvs/cds/projects/statScreen/log.txt, the following error is given for those files: import: unable to read X window image `0x20011f': Resource temporarily unavailable @ error/xwindow.c/XImportImage/5027. If anyone has seen this error before or knows how to fix it, please let me know.

In the meantime, I'll be working on creating an archive of MEDM screens for every hour to be displayed on the summary pages.

  12279   Fri Jul 8 21:02:09 2016 KojiUpdateComputer Scripts / ProgramsMEDM Tab on Summary Pages

Very nice!

Some of the screens are up-to-date, and some are not. Are the errors associated with the screens that failed to get updated?

  12280   Fri Jul 8 21:15:03 2016 PrafulUpdateComputer Scripts / ProgramsMEDM Tab on Summary Pages

Thanks! Yes, only the screens that are not updated when the script is executed show this error. I'll try to keep debugging over the weekend.

Quote:

Very nice!

Some of the screens are up-to-date, and some are not. Are the errors associated with the screens that failed to get updated?

 

  4707   Thu May 12 23:41:47 2011 ranaUpdateCDSMEDM Snapshots not working

Looks like 2 different MEDM Snapshot functiions (at least) are broken.

The regular update of the screens here as well as the usual "Update Snapshot" and view "previous snapshot" button on all of the auto-generated screens.

Also, how do we add the snapshot button to the custom made screens?

  9022   Sun Aug 18 17:56:16 2013 ranaSummaryCDSMEDM Screen CPU Usages

I noticed at LLO (?) that the LSC screen there uses up ~25-30% of the CPU time on a single core for the control room iMac workstations - this seems excessive.

Here is an accounting of CPU usage percentages for some of our screens:

 

Screen Name CPU (%)
LSC_OVERVIEW 7
ALS_OVERVIEW 0
ALS 1
SUS_SUMMARY 0
IOO_WFS_MASTER 0.3
OPLEV_MASTER 0.5

These were measured using the program 'glances' on rosalba. MEDM running with only the sitemap used up 0.9% of a CPU. With the screens running, the fluctuation from sample to sample could be ~ +/- 0.5%. While the LSC screen seems to be the biggest pig, it is only big in comparison to small pigs. Certainly this pig has gotten bigger after getting sent to Louisiana.

Attachment 1: obama1404_666531c.jpg
obama1404_666531c.jpg
  13879   Tue May 22 17:29:27 2018 keerthanaUpdateelogMEDM Diagram for the auxilary laser system control and display.

(keerthana, gautam, jon)

In the morning, Jon gave me an overview of the Auxiliary laser system which we are planning to setup. Based on the diagram he uploaded in the elog, I have made the MEDM diagram for controlling and displaying the parameters. Here the parameters which we will be controlling are temperature (in terms of voltage), oscilator frequency ( with the help of IFR 2023B), the frequency offset and the PID controls. The display includes the beat frequency, error signal voltage, control voltage and a switch to give feed back to the AUX laser. As the frequency counter is not connected at the moment, I haven't included its channel number in it. The screenshot of the diagram is attached with this. I am also considering to give a PID feedback to the slow control from the AUX feedback signal. The screen can be accessed from the PSL dropdown menu in sitemap.

Attachment 1: MEDM_aux.png
MEDM_aux.png
  855   Tue Aug 19 17:15:34 2008 SharonUpdate MEDM
I plugged in the gains I got for the accelerometers in the accelerometers' filters in the PEM screen of the adaptive filter
  339   Fri Feb 22 21:19:38 2008 AndreyBureaucracyComputer Scripts / ProgramsMDV library does not work at "LINUX 2"

While working on Thursday evening with Matlab scripts "dttfft2" and "get_data", I noticed that mDV library does not work at computer "LINUX 2" (the third computer in the control-room if you enter it from the restroom). There are multiple error messages if we try to run "hello_world", "dttfft2" or "get_data". In order to take data from accelerometers, I changed the computer - I was working from "LINUX 3" computer, the most right computer in the control room, but for the future someone should resolve the issue at "LINUX 2". I am not experienced enough to revive the correct work of mDV directory at "LINUX 2".

Andrey.
  343   Thu Feb 28 12:31:33 2008 robBureaucracyComputer Scripts / ProgramsMDV library does not work at "LINUX 2"

Quote:

While working on Thursday evening with Matlab scripts "dttfft2" and "get_data", I noticed that mDV library does not work at computer "LINUX 2" (the third computer in the control-room if you enter it from the restroom). There are multiple error messages if we try to run "hello_world", "dttfft2" or "get_data". In order to take data from accelerometers, I changed the computer - I was working from "LINUX 3" computer, the most right computer in the control room, but for the future someone should resolve the issue at "LINUX 2". I am not experienced enough to revive the correct work of mDV directory at "LINUX 2".

Andrey.


This turned out to be due to /frames not being mounted on linux2, as a result of a reboot. The issue is discussed in entry 270. I remounted the /frames, and added a line to mdv_config.m to check whether the frames are mounted.
  13533   Thu Jan 11 18:50:31 2018 gautamUpdateIOOMCautolocker getting stuck

I've noticed this a couple of times today - when the autolocker runs the mcdown script, sometimes it doesn't seem to actually change the various gain sliders on the PSL FSS. There is no handshaking built in to the autolocker at the moment. So the autolocker thinks that the settings are correct for lock re-acquisition, but they are not. The PCdrive signal is often railing, as is the PZT signal. The autolocker just gets stuck waiting to re-acquire lock. This has happened today ~3 times, and each time, the Autolocker has tried to re-acquire lock unsuccessfully for ~1hour.

Perhaps I'll add a line or two to check that the signal levels are indicative of mcdown being successfully executed.

  13547   Mon Jan 15 11:53:57 2018 gautamUpdateIOOMCautolocker getting stuck

Looks like this problem presisted over the weekend - Attachment #1 is the wall StripTool trace for PSL diagnostics, seems like the control signal to the NPRO PZT and FSS EOM were all over the place, and saturated for the most part.

I traced down the problem to an unresponsive c1iool0. So looks like for the IMC autolocker to work properly (on the software end), we need c1psl, c1iool0 and megatron to all be running smoothly. c1psl controls the FSS box gains through EPICS channels, c1iool0 controls the MC servo board gains through EPICS channels, and megatron runs the various scripts to setup the gains for either lock acquisition or in lock states. In this specific case, the autolocker was being foiled because the mcdown script wasn't running properly - it was unable to set the EPICS channel C1:IOO-MC_VCO_GAIN to its lock acquisition value of -15dB, and was stuck at its in-lock value of +7dB. Curiously, the other EPICS channels on c1iool0 seemed readable and were reset by mcdown. Anyways, keying the c1iool0 crate seems to have fixed the probelm.

Quote:

I've noticed this a couple of times today - when the autolocker runs the mcdown script, sometimes it doesn't seem to actually change the various gain sliders on the PSL FSS. There is no handshaking built in to the autolocker at the moment. So the autolocker thinks that the settings are correct for lock re-acquisition, but they are not. The PCdrive signal is often railing, as is the PZT signal. The autolocker just gets stuck waiting to re-acquire lock. This has happened today ~3 times, and each time, the Autolocker has tried to re-acquire lock unsuccessfully for ~1hour.

Perhaps I'll add a line or two to check that the signal levels are indicative of mcdown being successfully executed.

 

Attachment 1: MCautolkockerStuck.png
MCautolkockerStuck.png
  12980   Wed May 10 12:37:41 2017 gautamUpdateCDSMCautolocker dead

The MCautolocker had stalled - there were no additional lines to the logfile after 12:17pm (~20mins ago). Normally, it suffices to ssh into megatron and run sudo initctl restart MCautolocker - but it seems that there was no running initctl instance of this, so I had to run sudo initctl start MCautolocker. The FSS Slow control initctl process also seemed to have been terminated, so I ran sudo initctl start FSSslowPy.

It is not clear to me why the initctl instances got killed in the first place, but MC locks fine now.

  12982   Wed May 10 16:57:52 2017 ranaUpdateCDSMCautolocker dead

I rebooted megatron around 12:20 today. It had dozens of stalled medm process (some of them there since February!). I couldn't kill them without them coming back like zombies, so I did sudo reboot.

  1825   Tue Aug 4 11:54:20 2009 JenneUpdateIOOMC_trans readout on LOCK_MC screen now normalized

The MC_trans QPD Pitch and Yaw readout on the Lock_MC screen are now normalized by the trans_sum. I used the method described in my entry elog 1488

/caltech/target/c1iool0/ioo.db now includes:

grecord(calc, "C1:IOO-MC_TRANS_P")
{
        field(INPA, "C1:IOO-MC_TRANS_VERT")
        field(INPB, "C1:IOO-MC_TRANS_SUM")
        field(SCAN, ".1 second")
        field(PREC, "3")
        field(CALC, "A/B")
}

grecord(calc, "C1:IOO-MC_TRANS_Y")
{
        field(INPA, "C1:IOO-MC_TRANS_HOR")
        field(INPB, "C1:IOO-MC_TRANS_SUM")
        field(SCAN, ".1 second")
        field(PREC, "3")
        field(CALC, "A/B")
}

 

The Lock_MC screen was changed to show these new P and Y channels. 

  1823   Mon Aug 3 22:54:53 2009 Jenne, Koji, ranaUpdateIOOMC_trans is now better, but not best

Jenne, Koji, Rana

After fixing up the Mode Cleaner a bit more (fiddling more with the MC_align sliders to get the alignment before locking, making sure that it is able to lock), we noticed that the MC Trans path could use some help. To align the MC, we put MC1 and MC3 back into the position where Rob left it on Thursday and then maximized the transmission with MC2. Then we went back and maximized with MC1/3 keeping in mind the Faraday. We got a good transmission and the X-arm had a transmission of 0.8 without us touching its alignment.

Upon looking at the AP table portion of the MC_trans path, we decided that it was all pretty bad.  The light travels around the edge of the AP table, then out the corner of the table toward the PSL table.  A periscope brings it down to the level of the PSL table, and then it travels through a few optics to the MC_trans QPD. 

The light was clipping on the way through the periscope, and so the MC_trans QPD was totally unreliable as a method of fine-tuning the alignment of the Mode Cleaner.  Ideally we'd like to be able to maximize MC_trans, and say that that's a good MC alignment, but that doesn't work when the beam is clipped.

 

Things done:

1. The first turning mirror on the AP table after the beam comes out of the vacuum was changed from a 1" optic to a 2" optic, because the spot size is ~4-6mm.  We were careful to avoid clipping the OMCT beam, by using a nifty U200 mount (C-shaped instead of ring-shaped). 

2.  We placed a lens with a RoC of 1m (focal length for 1064nm is ~2m), a 2" optic, between the first two mirrors, to help keep the beam small-ish when it gets to the periscope, to help avoid clipping.

3. Rana adjusted the angle of the upper periscope mirror, because even when the beam was centered on the steering mirror directly in front of the periscope and the spot was centered on the first periscope mirror, the beam wouldn't hit the bottom periscope mirror. 

4. We noticed that the bottom periscope mirror was mounted much too low.  It was mounted as if the optics after it were 3" high, which is true for all of the input optics on the PSL table.  However, for the MC_trans stuff, all the optics are 4".  We moved the periscope up one hole, which made it the correct height.

5. We removed the skinny beam tube which guided/protected the beam coming off the periscope after a steering mirror since it (a) wasn't necessary and (b) was clipping the beam. We cannot use such skinny tubes anymore Steve.

6. There was a lens just before the 2nd steering mirror on the PSL table portion, which we removed since we had placed the other lens earlier in the path.  2 lenses made the beam too skinny at the QPD.

7.  After this 2nd steering mirror, there had been a pickoff, to send a bit of beam at a crazy angle over to the RFAM mon, which we removed.  This results in a much brighter beam at the MC_trans QPD, and at the camera.  The QPDs readouts are now a factor of ~3.5 higher than they used to be.  These (especially the camera) could use some ND-filtering action.

8.  The steering optic directly in front of the MC_trans QPD is a beamsplitter, and instead of dumping the light which doesn't go to the MC_trans QPD, we used this to go over to the RFAM mon (instead of the pickoff which we had removed). 

9.  Koji fixed up the optics directly in front of the RFAM mon, accomodating the new position of the input light (now at a much more reasonable angle, and about 15cm farther back from the PD). Note the beam dump which is preventing the cables from the FSS board from entering the beam path. This included removing an ND filter wheel, so the RFAM mon values will all be higher now.  Koji also has the beam going to the PD going at a slight angle, so that the beam isn't directly reflected on itself, so that it can be dumped.

10. We aligned the beam onto the MC_trans QPD using the first steering mirror on the PSL table.

11. We also removed the giant wall of beam dumps separating the squeezing section of the table from the rest of the table.

Alberto will elog things about the RFAM mon, including different values of the PD output, etc.

 

Still on the to-do list:

A.  Replace the second steering mirror on the AP table after the MC_trans light leaves the vacuum with a 2" optic, since the lens we placed isn't tight enough to make the spot small there yet.  Us a U200A mount if possible, because they are really nice mounts.

B.  Put an ND filter in front of the MC_trans camera, because the image is too bright.

C.  Normalize the MC_trans QPD - the horz and vert are pretty much direct voltage readouts, with no normalization.  They should be divided by the DC value.  This lack of normalization results in higher sensitivity to input pointing.

D.  Long term, next time someone wants to optimize the MC_trans path, move all the optics, including the MC_trans QPD and the camera closer to the periscope on the PSL table.  There's no reason for the beam to be traveling nearly the full width of the PSL table when we're not manuvering around squeezing stuff.

E. Never, ever purchase these horrible U100 or U200 mounts with the full ring and the little plastic clips. They are the "AC28" version. Bad, bad, bad.

 

Image 1:  The new setup of the AP table, Mc_trans portion. 

Image 2:  New setup of the MC_trans part of the PSL table.

Attachment 1: P8030099_copy.JPG
P8030099_copy.JPG
Attachment 2: P8030102_copy.JPG
P8030102_copy.JPG
  5958   Sat Nov 19 06:04:43 2011 SureshUpdateIOOMC_WFS Servo: The MC2_TRANS_PIT and YAW loops switched ON

Without adding significant amounts of noise to other WFS loops I have engaged the MC2_TRANS_PIT and YAW loops. 

After several attempts to measure the system response and computing the output matrix, none of which gave any useful results, I gave up on that and decided to find three orthogonal actuation vectors which enable us to close the loops.  So using the last good output matrix (below left side)  as a template, I rounded it off to the nearest set of orthogonal vectors and arrived at the following matrix (right side):

WFS_OUTMx_Lastgood.png        WFS_OUTMATRIX_20111118.png

 

I also decided that WFS1 and 2 need not drive MC2.  This is just to decouple the loops and minimise cross-talk.   This (albeit heuristic)  matrix seems to work pretty well and the real matrix is probably quite close to it.

I show below the suppressed error signals after tweaking the gains a bit.   The blue line is with no WFS, the green one with only WFS1 and 2 loops on, while the red is with all loops turned on.  The WFS1Yaw and MC2_Trans_pit loops might benefit from a more careful study to determine a better output matrix.

WFS_err_MC2T_on_OMx5_20111118.png

  5959   Sat Nov 19 10:41:30 2011 ranaUpdateIOOMC_WFS Servo: The MC2_TRANS_PIT and YAW loops switched ON

I'm quite sure that this is not good: since MC2 can produce a signal in WFS1 and WFS2, it cannot be removed in this way from the actuation without introducing a significant cross-coupling between the MC_TRANS and WFS loops.

Really need loop TFs measured and compared with the model.

The WFS noise model will also show that we need to have a much lower UGF in the MCT loop since that sensor is just a DC QPD: it can never have as good of a sensing noise as a good WFS. In the current case with no Whitening, this is even more so.

  14276   Tue Nov 6 15:32:24 2018 SteveUpdatePSLMC_Transmitted

I tried to plot a long trend MC Transmitted today. I could not get farther than 2017 Aug 4

Quote:

The mode cleaner was misaligned probably due to the earthquake (the drop in the MC transmitted value slightly after utc 7:38:52 as seen in the second plot). The plots show PMC transmitted and MC sum signals from 10th june 07:10:08 UTC over a duration of 17 hrs. The PMC was realigned at about 4-4:15 pm today by rana. This can be seen in the first plot.

 

Attachment 1: MC_Trans.png
MC_Trans.png
  7430   Sun Sep 23 22:40:48 2012 DenUpdateModern ControlMC_L locking

I've applied LQR approach to MC_L locking. Results show that LQR does not make MC_F signal smaller below 0.3 Hz in contrast with classical locking. This might indicate that in this frequency range we see sensing noise as LQR was provided with state-space model of MC only so it tries to reduce displacement noise. It is also possible that state-space model is not accurate enough.

 

Attachment 1: LQR_MCL.pdf
LQR_MCL.pdf
  7252   Wed Aug 22 20:33:51 2012 DenUpdateAdaptive FilteringMC_L in ARMS

Jenne and I did adaptive filtering of MC_L and measured how X and Y ARM control signals change compared to non-filtered MC_L. We did the test during 1.5 Hz seismic noise activity and adaptive filter was able to subtract it. However, it adds noise at high frequencies, It is not seen in MC_L but it is present in the ARMs control signals.

I'll investigate this problem. May be we need to reduce adaptation gain. In this experiment it was 0.1 and adaptive filter convergence time was equal to 1-2 mins.

 oaf_arms.png

  1236   Fri Jan 16 18:45:20 2009 YoichiConfigurationIOOMC_L gain increased by a factor of 2
Rana, Yoichi

Since we fixed the FSS AOM double-pass, which used to be a single-pass, the MC_L gain was too low for
making the cross-over at 100Hz.
Rana increased it by a factor of two. Now it seems that the cross over is ok (attachment 1).

We also noticed that the MC_F spectrum is noisier than before (attachment 2).
The reference is from 6/24/2008.
Attachment 1: MC_F-MC_L-xover.pdf
MC_F-MC_L-xover.pdf
Attachment 2: MC_F.pdf
MC_F.pdf
  1768   Tue Jul 21 15:32:47 2009 JenneUpdateIOOMC_L flatlined

[Clara, Jenne]

While Clara was working on her Wiener filtering and optimizing the locations of the accelerometers, she discovered that MC_L and MC_L_256 are totally flatlined.  I looked at them, and it looks like they've been dead since ~9:30pm-ish on Sunday night.  Bootfest-type activities shall commence shortly.

  1770   Tue Jul 21 17:52:12 2009 JenneUpdateIOOMC_L flatlined

Quote:

[Clara, Jenne]

While Clara was working on her Wiener filtering and optimizing the locations of the accelerometers, she discovered that MC_L and MC_L_256 are totally flatlined.  I looked at them, and it looks like they've been dead since ~9:30pm-ish on Sunday night.  Bootfest-type activities shall commence shortly.

 Under Alberto's tutalage, I rebooted the whole vme set (iovme, sosvme, susvme1, susvme2), and after that MC_L was all good again.

  2062   Wed Oct 7 06:26:09 2009 ranaHowToIOOMC_L calibration + some DTT lore

I drove MC2 in POS and used the resulting response in MC_F to calibrate the IOO-MC_L channel.

Yoichi did an excellent job of calibrating MC_F last year. I have used his calibration of MC_F (220 Hz/count @ DC) to get the MC_L calibration at DC as well as at high frequencies. The hardware dewhitening was OFF for all these measurements.

Method

1. For the DC measurement I excited C1:SUS-MC2_MCL_EXC at 0.0731 Hz. At these frequencies, the MC_L path has much more gain than the MC_F path. So this excitation at the error point makes the length path to drive itself to cancel the digital excitation. Since the overall MC servo gain is huge, this causes the MC_F path to compensate the residual MC_L motion. One can simply take the ratio of MC_L/MC_F to get the calibration of MC_L in Hz.

2. For the AC measurement, I engaged FM9 of the MC2_MCL filter bank. This guy is an elliptic LP with a notch at 660.38 Hz. I then drove MC2_LSC at 660.38 Hz with a sine wave of 500 counts amplitude. The notch makes the gain of the MC_L feedback zero at that frequency. So MC_F has to do all the work. We can simply measure the ratio of MC2_LSC/MC_F to get the AC calibration of MC2_MCL_OUT (aka IOO-MC_L) and MC2_LSC_OUT (aka LSC-MC_L).

 

Results:

MCF/MCL @ 0.0731 Hz = 569.4. So the MC_L calibration at DC is 220 x 569.4 = 125 kHz/count or 6.02 nm/count.

From this we would expect the AC calibration to be (6 nm/count)*(660.38/f_pend)^2 = 13.0 x10^-15 m/count.

The AC measurement gave 1445 counts_peak** of MC_F for the 500 counts (peak) excitation in MC2_LSC. From Yoichi's entry we get that the high frequency calibration of MC_F should be 0.089 Hz/count. So the MC_L calibration at 660 Hz is 0.089*1445/500 = 0.25 Hz / count or 12.3 x 10^-15 m/count. So the AC/DC ratio is close to 1.

Splitting the difference, the new official MC_L calibration is 5.87 nm/counts @ DC with a complex pole pair at 0.972 Hz.

 

** note:  To convert from the peak height observed in DTT with a 50% Overlap Hanning window you must use the following intuitive formula:  counts_peak = (counts / rHz) * sqrt(2 * BW). In this case, BW is the number that DTT reports as BW on the screen, NOT the BW that you asked for on the measurement tab.

*** note: when measuring peak heights in a DTT FFT, make sure to unclick the box for 'Bin' under the config tab. Bin suppresses peaks in a plot with a lot of points and is ON by default.

**** note: I have updated the MCF reference in the Templates directory with the Yoichi calibration - spectrum attached. This is probably the most accurate MCF spectrum we have ever put in the elog in the history of the 40m. The implication is that the VCO phase noise is ~5 mHz/rHz. Not bad.

***** note: with the OAF off, I drove a 1.55 Hz sine wave into MC1 and measured the ratio of MC1_MCL_OUT/IOO-MC_L. This gives the DC calibration of MC1_MCL_OUT = 7.98 nm/count.

Attachment 1: mcl-cal.png
mcl-cal.png
Attachment 2: a.png
a.png
  7750   Tue Nov 27 00:45:20 2012 jamieUpdateIOOMC_L and laser frequency noise spectra

I grabbed the a plot of the iLIGO PSL frequency noise spectrum from the Rana manifesto:

laser_noise.pdf

Rana's contention is that this spectrum (red trace) is roughly the same as for our NPRO.

From the jenne/mevans/pepper/rana paper Active noise cancellation in a suspended interferometer I pulled a plot of the calibrated MC_L noise spectrum:

MCL_noise.pdf

The green line on this plot is a rough estimate of where the above laser frequency noise would fall on this plot.  The conversion is:

    L / f  =  10 m / 2.8e14 Hz = 3.5e-14 m/Hz

which at 10 Hz is roughly 1.5e-11 m.  This puts the crossover somewhere between 1 and 10 Hz.

  999   Fri Sep 26 16:13:57 2008 ranaUpdateIOOMC_L / MC_F crossover
We were trying to understand why the FAST_F signal had such large excursions (~1V ~ 5 MHz).

Some of this is due to the seismic noise and the resulting MC_F signals. Increasing the MCL
gain reduces it somewhat. But as you can see from the attached loop gain measurement, the
crossover is a healthy 90 Hz with the MCL digital gain = 1. But what's going on in the MC loop
in the 10-20 Hz band? That looks like bad news.

Then I noticed that changing the ISS gain slider puts a large step (~1V) into the FAST. My guess
is that the board has large DC offsets and also much of the switching supply noise. Not sure why
this would be worse than before though.

To prevent large noise in the FAST, I've changed the mcup script to set this gain to -5 dB. Our
intensity noise is now presumably 10-15 dB worse than the nominal good levels we had a year ago.
Needs investigation.
Attachment 1: mcx.png
mcx.png
  1393   Thu Mar 12 02:18:42 2009 YoichiUpdateLockingMC_I spectra (RF_AM)
I took several spectra of MC_I signal (see attm1).

The blue curve is when the MC was locked. The green curve (RF_AM) shows the MC_I spectrum when the MC is unlocked and MC2 is mis-aligned,
so that no resonance should happen. The brown curve is when the PSL shutter was closed (dark noise).
There are some structures in the green curve but not at 3.8kHz.

The second attachment compares the MC_I spectrum (the same as the green one in the first attachment) with the Xarm error signal.
Of course these two spectra were taken at different times.

Some of the peaks in the X-arm error signal seem to be coming from the MC RF_AM.
Attachment 1: MC_I_Spe.png
MC_I_Spe.png
Attachment 2: MC_I-Xarm.png
MC_I-Xarm.png
  968   Fri Sep 19 00:06:54 2008 ranaUpdateIOOMC_F: Too much frequency noise around 100 Hz
WE noticed this excess again in MC_F. We tried recentering the WFS, but no effect.

Also no effect from changing the FSS gain, PMC gain, or ISS gain.

Actually, there IS a change when changing the PMC gain -- the ISS can be made to saturate
by lowering the PMC gain by 10 dB. Jenne and I need to finish off the PMC loop.

10 kHz UGF or bust!
Attachment 1: mcf.png
mcf.png
  7003   Mon Jul 23 17:39:34 2012 JenneUpdateIOOMC_F vs. MC_L

[Rana, Jenne]

We looked at the different outputs of the MC servo board to make sure they make some kind of sense.  As per my elog 6625, the names of the channels were wrong, but we wanted to confirm that we have something sensible.

Currently, OUT1 of the servo board is called "MC_F" and the SERVO out is called "MC_SERVO".  We looked at the spectrum of each, and the transfer function between them.

You can see that in addition to a 2kHz pole, MC_L also seems to have a 10-100 zero-pole pair.

 

Also, while cleaning things up in the models, I fixed the names of these MCL/MCF channels.  OUT1 is now called MC_L, and is connected to ADC0_0, and SERVO is called MC_F and is connected to ADC0_6.  Both MC_L and MC_F go to the RFM, and thence on to the OAF.  MC_L (which used to be mis-named MC_F) still goes both to the MCS model for actuation on MC2, and to the OAF for MC-OAF-ing.  Right now MC_F is unused in the OAF model, but we can change that later if we want.

 

Attachment 1: MCF_vs_MCL_23July2012.pdf
MCF_vs_MCL_23July2012.pdf
  6689   Sat May 26 00:08:41 2012 DenUpdateIOOMC_F low frequency noise

 MC_F low frequency noise might be due to local damping electronics. I did not measure OSEM noise, but even without it electronics (AA -> ICS 110 -> ADC) provide sufficient amount of noise. 

These 2 image show electronics noise and coherence between OSEM signal / seismic

osem_noise.png           gur_suspos_coh.png

From these 2 plots we might think that SNR > 10 and coherence OSEM / GUR is high at the frequency range 0.1 - 10 Hz and this is not a big problem.

However, at low frequencies the length of seismic waves becomes large enough and relative oscillations of MC2 and MC13 decrease.

For 1 wave ( u(MC2) - u(MC1) ) / u(MC2) = sin(2 * pi * L  * f  / c), L - distance between MC1 and MC2 where 2 seismometers are located. So MC123 move according to seismic motion and electronics noise is not seen unless we look at MC Length. Here this noise is seen, because mirrors move in a synchronistic manner. 

To check this I measured seismic noise with 2 guralps at distance 12 meters - at MC1 and MC2. Then I've computed the difference between these signals. And indeed at low frequencies, relative motion is much less.

Green, blue - GUR1,2_X

Red - differential motion GUR1_X - GUR2_X

dgur.png

 

The following plot illustrates how electronics noise effects MC_F. Green is the signal to coils. Red - electronics noise. Blue, black, cyan - simulated contribution to MC_F for different seismic waves speed. Most probably seismic waves have waves in the range 50 - 800 m/s, others are deep. The plot shows that electronics noise is big enough to disturb coherence between MC_F and seismic noise. 

mc_noises.png

Here is a rough calculation of the seismic waves speed. The following plot shows the ratio of psd of differential MC2-MC1 motion to MC2 motion.

ratio.png

If seismometers would be very far, ratio would be 1 if we neglect the difference in transfer function SEISMOMETER -> ADC for each channel. The drift of the ratio from 1 to 1.3 demonstrates this effect. Ratio starts to decrease at 15 Hz according to sin (2*pi*L*f/c) ~ 2*pi*L/c * f. So 2*pi*L/c * f_0 = pi/2 => c = 4 * L * f = 600 m / sec.

  3231   Thu Jul 15 19:13:03 2010 ranaUpdateIOOMC_F check

Sometimes I like to plot the spectrum of MC_F. Its a good diagnosis of whether something is wrong.

The red trace is noisier than the blue reference. What is the cause of this?

Attachment 1: a.png
a.png
  1747   Wed Jul 15 11:38:31 2009 robUpdateLockingMC_F channel dead

It's railed.  This is what halted locking progess on Monday night, as this channel is used for the offloadMCF script, which slowly feeds back a CARM signal to the ETMs to prevent the VCO from saturating.

 

Attached is a 5 day trend, which shows that the channel went dead a few days ago.  All the channels shown are being collected from the same ICS110B (I think), but only some are dead.  It looks like they went dead around the time of the "All computers down" from Sunday.

Attachment 1: mcfdead.png
mcfdead.png
  1758   Thu Jul 16 14:41:38 2009 robUpdateLockingMC_F channel dead

Quote:

It's railed.  This is what halted locking progess on Monday night, as this channel is used for the offloadMCF script, which slowly feeds back a CARM signal to the ETMs to prevent the VCO from saturating.

 

Attached is a 5 day trend, which shows that the channel went dead a few days ago.  All the channels shown are being collected from the same ICS110B (I think), but only some are dead.  It looks like they went dead around the time of the "All computers down" from Sunday.

 Attached are the channels being recorded from the ICS110B in 1Y2 (the IOO rack).  Channels 12, 13, 16, 17, 22, 24, 25 appear to have gone dead after the computer problems on Sunday.

Attachment 1: IOO_ICS_0_15.png
IOO_ICS_0_15.png
Attachment 2: IOO_ICS_15_32.png
IOO_ICS_15_32.png
  1759   Thu Jul 16 14:54:05 2009 robUpdateLockingMC_F channel dead

Quote:

Quote:

It's railed.  This is what halted locking progess on Monday night, as this channel is used for the offloadMCF script, which slowly feeds back a CARM signal to the ETMs to prevent the VCO from saturating.

 

Attached is a 5 day trend, which shows that the channel went dead a few days ago.  All the channels shown are being collected from the same ICS110B (I think), but only some are dead.  It looks like they went dead around the time of the "All computers down" from Sunday.

 Attached are the channels being recorded from the ICS110B in 1Y2 (the IOO rack).  Channels 12, 13, 16, 17, 22, 24, 25 appear to have gone dead after the computer problems on Sunday.

 This has been fixed by one of the two most powerful & useful IFO debugging techniques: rebooting.  I keyed the crate in 1Y2.

  11281   Mon May 11 13:26:02 2015 manasaUpdateIMCMC_F calibration

The last MC_F calibration was done by Ayaka : Elog 7823

Quote:

And does anyone know what the MC_F calibration is?

 

  11284   Mon May 11 18:14:52 2015 ranaUpdateIMCMC_F calibration

I saw that entry, but it doesn't state what the calibration is in units of Hz/counts. It just gives the final calibrated spectrum.

  1032   Tue Oct 7 21:19:40 2008 YoichiUpdateIOOMC_F calibrated spectrum
I updated the plots because I did not take into account the double path AOM effect, which doubles the frequency actuation efficiency. (2008/10/8)

I determined the MC_F counts to the PSL frequency change calibration.
The attachment 1 is the calibrated MC_F spectrum, which is, above the cross over frequency, equivalent to the frequency noise seen by the MC.

The calibration method is the following:

1) I picked spare AD and DA channels (C1:IOO-MC_TMP1 and C1:OMC-SPARE_DAC_CH_16_EXC). C1:OMC-SPARE_DAC_CH_16_EXC is labeled C1:OMC-OSC_FM on the cable.

2) C1:IOO-MC_TMP1 was calibrated by injecting a sine wave of known amplitude and measuring the amplitude in counts in dataviewer.
It was 63uV/cnt.

3) C1:IOO-MC_TMP1 was connected to the feedback BNC connector of the MC board, that is the direct monitor of the feedback voltage to the VCO.

4) C1:OMC-SPARE_DAC_CH_16_EXC was connected to the channel B excitation input of the MC board, which adds the signal to the fast feedback path.

5) Using DTT a swept sine signal was injected to the MC board through C1:OMC-SPARE_DAC_CH_16_EXC, and the transfer function from C1:IOO-MC_TMP1 to the
C1:IOO-MC_F was measured.

6) Using the calibration of C1:IOO-MC_TMP1, the transfer function from the MC_F count to the actual voltage applied to the VCO input was obtained.
(attm2)

7) Using the DC calibration of the VCO input voltage to the VCO frequency change (1.75MHz/V elog:993) and the fact that there is a 1.6Hz pole and a 40.8Hz zero between the VCO input connector and the actual input of the VCO chip, the final calibration transfer function from the MC_F count to the frequency change of the PSL (that is twice the frequency change of the VCO within the bandwidth of the FSS) can be obtained (attm3).

8) The analytic form of the calibration TF is, poles at [1.6Hz, 11.42Hz, 11.42Hz] and zeros at [40.8Hz, 113Hz, 113Hz] with the DC gain of 110Hz/cnt.
Attachment 1: MC_F-spectrum.png
MC_F-spectrum.png
Attachment 2: VCO_VoverMC_F.png
VCO_VoverMC_F.png
Attachment 3: PSL_FoverMC_F.png
PSL_FoverMC_F.png
  993   Thu Sep 25 15:24:05 2008 YoichiUpdateIOOMC_F VCO calibration
I calibrated the VCO driving the AOM for the AO path of the MC feedback.

I injected DC voltage to the VCO and measured the output frequency with the SR620.

The attached plot shows the relation between the input voltage to the VCO and the output frequency.
The coefficient is 1.75MHz/V. Since the AOM is double path, the actual actuation efficiency is 3.5MHz/V.
We can use this value for the calibration of the MC_F. However, the MC_F DAQ channel is sampling the VCO input voltage through a 10Hz high-pass filter.
This filter has to be taken into account to convert the MC_F counts to frequency.
I will measure the transfer function from the VCO input to the MC_F counts tomorrow.
Attachment 1: VCO_Cal.png
VCO_Cal.png
  553   Mon Jun 23 19:33:01 2008 rana, jenneUpdateIOOMC_F Noise check
We looked at the MC_F spectrum because Rob and Yoichi said that it had gone 'all crazy'. It
seemed fine as we looked at it (even with only one boost stage on) so we looked for things
that might be marginal and make it go nuts.

At the error point (Q mon on the demod board and TEST IN1) of the MC Servo board we saw the
old 3.7 MHz signal (comes from the 33 MHz RFAM getting demodulated by the 29.5 MHz MC LO)
and thought that this might cause some worries. So we installed Jenne's passive elliptic
low pass which has a 3.7 MHz zero.

This wiped out the 3.7 MHz noise but we were not able to re-create the extra frequency noise
so its unlikely to have fixed the main problem. However, we leave it in because its good. If
there is a need to revert it, we have left hanging on the side of the rack the old cable which
was a SMA->TNC making a direct, unfiltered connection between the MC Demod board and the MC
servo board.

More before and after results from Jenne tomorrow, but for now here is a calibrated MC_F spectrum
using the new MC_F-Reference.xml template file.

We also noticed that we could make some small effects on the MCF spec by adjusting the PMC gain so
there's probably more hay to be made there using a lead brick and a gain slider. More in Jenne's
entry.
Attachment 1: mcf.png
mcf.png
  15857   Wed Mar 3 12:00:58 2021 Paco, AnchalHowToIMCMC_F ASD

[Paco, Anchal]

- Saved BURT backup in /users/anchal/BURTsnaps/
- Copied existing code for mode cleaner noise budget from /users/rana/mat/mc. Will work on this from home to convert it inot new pynb way.

Get baseline IMC measurements (passive):
- MC_F:
  - What is MC_F? Let's find out.
  - On MC_F Cal window titled 'C1IOO-MC_FREQ', we turned off ON/OFF and back on again.
  - Using diaggui, we measured ASD of MC_F channel in units of counts/rtHz.

[Rana, Paco]

- Using diaggui, measured ASD from a template (under /users/Templates) and overlay the 1/f noise of the NPRO (Attachment 1)

[Anchal, Paco]

- WFS Master
  - Went through the schematic and tried to understand what is happening.
  - Accidentally switched on MC WF relief (python 3). Bunch of things were displayed on a terminal for a while and then we Ctrl-C it.
  - The only thing we noticed that change is a slight increase in WFS1 Yaw, and a corresponding decrease in WFS1 Pitch, WFS2 Pitch, and WFS2 Yaw.
  - We need to find out what this script does.


Future work:

  • Create an automated script for taking MC_F_DQ spectrum and refer it against reference trace.
  • Use pynb to create a noise budget for mode cleaner.
  • Identify excess noise between 10-40 Hz.
  • Configure output matrix in WFS Master to reduce the noise. Automate this process as well.
Attachment 1: 20210303_MC_F_Spectrum.pdf
20210303_MC_F_Spectrum.pdf
Attachment 2: 20210303_MC_F_Spectrum.tar.gz
  5869   Fri Nov 11 00:55:53 2011 DenUpdateAdaptive FilteringMC_F

[Mirko, Den]

Not satisfactory work of adaptive filtering make us to think about the signals that we use. Now we try to deal with mode cleaner and analize its length. We take MC_F channel. We know that MC_F is used as a feedback signal to the laser frequency and laser changes it's frequency linear to the input modulation signal up to ~1kHz. Than is MC_F is length of MC, not velocity or acceleration. If so, it's form due to seismic noise + company of other noises + stacks and wires should be approximately like the left plot. Instead we see the right plot.

mcl_sim.jpgmcl_real.jpg

 

Possibly, left-plot form signal is not possible to transmit through the wires and adc. Most signal at medium and high frequencies would be lost because of wire and adc noise. For that reason mode cleaner length signal might be amplified at frequecnies >~20 Hz by some bandpass filter.

Where is this highpass filter and what is the form of this filter?

It might be just after the photodetector in order not to transmit real mode cleaner length through the wires. But if wires and not very noisy, it could be somewhere before ADC.

But anyway, for the laser frequency feedback the corresponding low pass filter should be used.

Where is this lowpass filter and what is the form of the filter?

We followed the mode cleaner length signal up to TT FSS and measured the mode cleaner length, that is used as an input to TT FSS. As shown http://nodus.ligo.caltech.edu:8080/40m/5867 MC_F is different from the signal that is given to TT FSS. This is not clear because we do not have smth that could effect on the signal that much before branch node and recording of MC_F. The main difference is the cut off at the MC_F signal at 3 Hz. It might be a digital filter but we do not see any filters between adc_0_0 up to MC_F test point - straight line. This means that we have an analog filter somewhere between that blue box where the branch point is and ADC. We need to find it. But at least, we do not have a lowpass filter before FSS. So it is probably after it.

So, we need to find the 3 filters that we think affect on the MC_F channel in order to figure out why we have such a bad coherence between seismic signal and mode cleaner length.

  5871   Fri Nov 11 10:30:27 2011 ranaUpdateAdaptive FilteringMC_F

 

 There should be a whitening filter in the Pentek Generic DAQ board (Eurocard with 8 differential LEMO inputs). It used to be that the MC_L channel came in through here and I believe it has 2 stages of 150:15 pole:zero filters.

I don't remember if it is one or two stages, but this should be easy to measure with a function generator or by driving this input using the MC2 UL Coil monitor and doing the transfer function in DTT (as Koji and Jenne did for the demod boards).

  1405   Mon Mar 16 01:20:40 2009 ranaConfigurationIOOMCWFS noise filtered on the SUS-MC
Recently, we noticed that the IOO-WFS system runs at 2048 Hz and sends its signals to the MC SUS
systems which run at 16 kHz. There is no upsampling filter or anti-imaging filter.

So, I've implemented an RLP666 filter as FM1 in the SUS-MCn_ASC(PIT/YAW) filter banks. This is like a 4th order
Cheby low pass with a low Q notch at 2048 Hz to catch the first image.

The attached PNG shows the ASCPIT_OUT signals before and after the filter is implemented. As you can see, the
big aliased spikes are gone. The reason that MC2 is different from MC1/3 is that they have a hardware 28Hz low pass
and MC2 doesn't. So MC2 had a 28 Hz low pass in software already to match the actuation phase between all the MC
mirrors. The apparent power law noise floor from 40-300 Hz in MC2 is not real - just the Hanning window tail.

And yes, it has been this way for several years and none of us noticed. It remains to be seen if this was causing
any noise in the MC coil drivers via slew rate limiting.
Attachment 1: xarm.png
xarm.png
  4107   Tue Jan 4 18:37:18 2011 JenneUpdateIOOMCWFS aligned

I undid Yuta's temporary setup, and put beam back on both WFS.  Since Koji had just aligned the Mode Cleaner, I centered the beam on the WFS using the WFS QPD screen, while watching the WFS Head screen, to make sure that the beam was actually hitting the QPD, and not off in lala land. 

Quote from Koji:

- We must check the MCWFS path alignment and configuration.

Quote from Jenne:

* Noticed that the MCWFS path is totally wrong.  Someone (Yuta?) wanted to use the MCWFS as a reference, but the steering mirror in front of WFS1 was switched out, and now no beam goes to WFS2 (it's blocked by part of the mount of the new mirror). I have not yet fixed this, since I wasn't using the WFS tonight, and had other things to get done.  We will need to fix this.

 

  2448   Wed Dec 23 16:34:25 2009 KojiUpdateIOOMCT QPD/MC REFL QPD disabled

For a certain investigation of the sum/diff module for MCT QPD/MC REFL QPD, I removed it from the system.

 

  2451   Thu Dec 24 19:13:29 2009 KojiUpdateIOOMCT QPD investigation

I found that MCT QPD has a dependence of the total output on the position of the spot. Since the QPD needs the supply and bias voltages from the sum/diff amp, I could not separate the problems of the QPD itself and the sum/diff amplifier by the investigation on Tuesday. On Wednesday, I investigated a generic quad photodiode interface module D990692.

...I was so disappointed. This circuit was left uninvestigated and used so long time with the following sorrowful conditions.
- This circuit has 4 unbuffered inputs with input impedance of 300~400 Ohm. It's way too low!
- Moreover, those channels have different input impedances. Ahhhh.
- Even worse, the QPD circuit D990272 has output impedance of 50 Ohm.
- The PCB of this circuit has four layers. It is quite difficult to make modifications of the signal route.
- It is a headache: this circuit is "generic" and used in many places.

D990692 has 4 channel inputs that are not buffered. Each channel has two high impedance buffers but they are used only for the monitors. The signal paths have no buffer.

The differential amplifier is formed by R=1k Ohm. The inverted side of the input has 1kOhm impedance. The non-inverted side has 1.5kOhm impedance.

CH1: 10K // 1.5k // 1.5k // 1k = 411 Ohm
CH2: 10K // 1.5k // 1k // 1k = 361 Ohm
CH3: 10K // 1k // 1k // 1k = 323 Ohm
CH4: 10K // 1k // 1.5k // 1k = 361 Ohm

Considering the output impedance of 50Ohm for the QPD, those too low input impedances result in the following effect:
- Because of the voltage division, we suffer absolute errors of 10.8~13.4%. This is huge.
- Because of the input impedance differences, we suffer a relative error of 1.5%~3%. This is also huge.

Unfortunately, the circuit has no room to modify; the signal paths are embedded in the internal layer.

I decided to replace the resistors of the sum/diff amps from 1k to 10k. Also the input impedance of the buffer was removed as the input is terminated by the sum/diff amps in any case.This changes the input inpedance to the followings:

CH1: 15k // 15k // 10k = 4286 Ohm
CH2: 15k // 10k // 10k = 3750 Ohm
CH3: 10k // 10k // 10k = 3333 Ohm
CH4: 10K // 15k // 10k = 3750 Ohm

These yield the absolute error of 1.2-1.5%. The relative error is now 0.3%. I can accept these numbers, but later I should put additional terminating resistors to compensate the differencies.

So far I have modified the resistors for the MCT as the modification for a QPD needs 17 10k resistors.
Next thing I have to check is the dependence of the QPD outputs on the spot positions.

-----------------------------------------------

Edit: Feb 11, 2010

I talked with Frank and he pointed out that the impedances are not the matter but the gains of the each channels are the matters (after considering the output impedance of the QPD channels).
If we assume the ideal voltage sources at the QPD and the symmetric output impedances of 50Ohm, the gain of the each circuit are affected but the change should be symmetric.

He found that several things:
- The analog switch (MAX333) used in the QPD unit adds more output impedance (somewhat randomly!).
- The resistance of the sum/diff circuits may vary each other unless we use 0.1% resistors.

 

Attachment 1: D990692.png
D990692.png
  2454   Sun Dec 27 23:44:59 2009 ranaUpdateElectronicsMCT QPD investigation

Quote:

I found that MCT QPD has dependence of the total output on the position of the spot. Since the QPD needs the supply and bias voltages from the sum/diff amp, I could not separate the problems of the QPD iteself and the sum/diff amplifier by the investigation on Tuesday. On Wednesday, I investigated a generic quad photodiode interface module D990692.

 This is indeed sad. But, we can perhaps bypass all of this by just using the individual segment outputs. According to the circuit diagram and the c1iool0 .db file, we should be able to just do the math on the segments and ignore the VERT/HOR/SUM signals completely. In that case, we can just use high impedance for the sum/diff buffers as Koji says and not suffer from the calibration errors at all I think.

  2455   Mon Dec 28 01:17:01 2009 KojiUpdateElectronicsMCT QPD investigation

Unfortunately, the signals for individual segments also suffer from the voltage drop as all of the low impedance amplifiers are hung from the same input.
In order to utilize the individual channels, we anyway have to remove the resistors for the VERT/HOR/SUM amps.
That is possible. But does it disable some fast channels for future ASC purposes?

 

Quote:

 This is indeed sad. But, we can perhaps bypass all of this by just using the individual segment outputs. According to the circuit diagram and the c1iool0 .db file, we should be able to just do the math on the segments and ignore the VERT/HOR/SUM signals completely. In that case, we can just use high impedance for the sum/diff buffers as Koji says and not suffer from the calibration errors at all I think.

 

  13716   Wed Mar 28 21:47:37 2018 arijitUpdateIOOMCREFL_PD Optical response measurement

Kevin, Gautam and Arijit

We did a optical measurement of the MCREFL_PD transimpedance using the Jenny Laser set-up. We used 0.56mW @1064nm on the NewFocus 1611 Photodiode as reference and 0.475mW @1064nm on the MCREFL_PD. Transfer function was measured using the AG4395 network analyzer. We also fit the data using the refined LISO model. From the optical measurement, we can see that we do not have a prominent peak at about 300MHz like the one we had from the electrical transimpedence measurement. We also put in the electrical transimpedence measurement as reference. RMS contribution of 300MHz peak to follow.

 

As per Rana`s advice I have updated the entry with information on the LISO fit quality and parameters used. I have put all the relevant files concerning the above measurement as well as the LISO fit and output files as a zip file "LISO_fit" . I also added a note describing what each file represents. I have also updated the plot with fit parameters and errors as in elog 10406.

Attachment 1: LISO_fit_with_info.pdf
LISO_fit_with_info.pdf
Attachment 2: LISO_fit.zip
  13719   Thu Mar 29 17:57:36 2018 arijitUpdateIOOMCREFL_PD Optical response measurement

Kevin, Gautam and Arijit

Today we performed the in-loop noise measurements of the MCREFL-PD using the SR785 to ascertain the effect of the Noise Eater on the laser. We took the measurements at the demodulated output channel from the MCREFL-PD. We performed a series of 6 measurements with the Noise Eater ''ON'' and ''OFF''. The first data set is an outlier probably, due to some transient effects. The remaining data sets were recorded in succession with a time interval of 5 minutes each between the Noise Eater in the ''ON'' and ''OFF'' state. We used the calibration factor of 13kHz/Vrms from elog 13696 to convert the V_rms to Hz-scale.

The conclusion is that the NOISE EATER does not have any noticeable effect on the noise measurements.

ALS beat spectrum and also the arm control signal look as they did before. coherence between arm control signals (in POX/POY lock) is high between 10-100Hz, so looks like there is still excess frequency noise in the MC transmitted light. Looking at POX as an OOL sensor with the arm under ALS control shows ~10x the noise at 100 Hz compared to the "nominal" level, consistent with what Koji and I observed ~3weeks ago.

We tried swapping out Marconis. Problem persists. So Marconi is not to blame. I wanted to rule this out as in Jan, Steve and I had installed a 10MHz reference to the rear of the Marconi.

Attachment 1: NOISE_EATER_On_OFF.pdf
NOISE_EATER_On_OFF.pdf
ELOG V3.1.3-