40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 47 of 344  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  1732   Sun Jul 12 20:05:06 2009 ranaOmnistructureEnvironmentChanged office temp
This is a 7-day minute trend. There's no obvious effect in any of the channels looking back 2 days.

Seems like the laser chiller fix has made the laser much more immune to the office area temperature.
Attachment 1: Picture_3.png
Picture_3.png
  8673   Tue Jun 4 20:19:07 2013 ranaConfigurationIOOChanged threshold for FSS SLOW loop

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

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

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

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

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

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

caput -c -t C1:PSL-FSS_LOCKEDLEVEL 12000

Then I restarted the code on op340m, by typing:

> nohup FSSSlowServo

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

  3128   Mon Jun 28 13:40:53 2010 josephb, AlexUpdateCDSChanges added to CDS SVN, new checkout, new features, some changes made

Last week Alex merged in the changes I had made to the local 40m copy of the Real Time Code Generator.  These were to add a new part, called FiltMuxMatrix, which is a matrix of filter banks, as well as fixing the filter medm generation code so the filter banks actually have working time stamps.

I checked out a new version of the CDS SVN with these changes merged in.  Changes that will be added in the near future by Rolf and Alex include the addition of "tags".  These are pieces in simulink which act as a bridge between two points, so you can reduce the amount of wire clutter on diagrams.  Otherwise they have no real affect on the generated C code.  Also the ADC/DAC channel selector and in fact the ADC/DAC parts will be changing.  The MIT group has requested the channel selector be freed up for its original purpose in matlab, so Rolf is working on that.

The new checkout includes the new directory scheme Rolf is pushing.  So when you run the code generator and more specifically, install SYS, it places code in /opt/rtcds/caltech/c1/ type directories, like medm, chans, target, scripts.

For the time being, Alex has created a directory /rtcds on Linux1 under /home/cds.  He then created softlinks to that directory on megatron, c1iscex, and allegra in the /opt directory.  This was an easy way to have a shared path.

However, it does mean on each new FE  machine after setting up the mounting of /home/cds from Linux1, we also need to create the /opt/rtcds link to /cvs/cds/rtcds.

After checking out the CDS SVN, we discovered there some files missing that Alex had added to his version, but not the main branch.  Alex came over to the 40m and proceeded to get all those files checked in.  We then checked it out again.  Changes were made to the awg, framebuilder, and nds codes and needed to be rebuilt. 

There's a new naming scheme for models.  You need to include the site before the 3 letter system name.  So lsc.mdl become c1lsc.mdl.

Certain other file name conventions were also changed.  Instead of tpchn_c1.par, tpchn_c2.par, etc, its now tpchn_c1lsc.par, tpchn_c2lsp.par, etc.  The system name is included at the end of the filename, to help make it clearer what file goes with what.

This required an edit of the chnconf file, which has explicit calls to those file names.  Once we edited that file, we had to reload the xinetd service which its apparently a subpart of (this can be accomplished by /etc/init.d/xinetd stop, then /etc/init.d/xinetd start).

/etc/rc.d/rc.local also had to be edited for the new model names (c1lsc, c1lsp, etc).

The daqdrc file (for the framebuilder) now parses which dcu_rate to use from the tpchn_c1lsc.par type files, so the dcu_rate 20 = 16384 lines have been removed.  set gds_server has also been removed, and replaced with tpconfig "/opt/rtcds/caltech/c1/target/gds/param/testpoint.par";  from which it can get the hostname.  This information is now derived from the c1SYS.mdl file.

Hostname needs to be added to the .mdl files, in the cdsParameter block (i.e. host=megatron).

After that Alex informed me the IOP processor needs to be running for the other models to work properly, as well as for the Framebuilder to work.

The models and framebuilder now get their timing signal from the IOP (input/output processor).  This must be running in order for the other models or FB to run properly.  Its generally named c1x00 or c1x01 or similar.  The last two numbers ideally are unique to each FE computer.

Initially there was a problem running on Megatron, because the IOP gets its timing signal from the IO chassis, and there was none connected to megatron.  However, he has since modified the code so that if there's no IO chassis, the IOP processor just uses the system clock.  It has been tested and runs on megatron now.

 

  739   Fri Jul 25 13:30:53 2008 SharonUpdate Changes in ASS computer
I editted the simulink diagram of the ASS computer so it now has 2 more channels reading 2 sets of the FIR coefficients to match Alex's changes in the C code.
The new simulink has already been compiled and can be found in /cvs/cds/caltech/users/alex/cds/advLigo/src/epics/simLink/ass.mdl
I backed up the old file and it's also in that folder under ass_BAK_24_jul.mdl

There is also a backup of the old ASS.ini file in caltech/chans/daq/C1ASS_BAK_24_jul.ini

Will update once it's all set and running
  15119   Mon Jan 13 23:30:53 2020 YehonathanSummaryPSLChanges made since Gautam left

As per Gautam's request, I list the changes that were made since he left:

1. The AOM driver was connected to a signal generator.

2. The first order beam from the AOM was coupled into the PMC while the zero-order beam is blocked. We might want to keep this configuration if the pointing stability is adequate.

3. c1psl got Burt restored to Dec 1st.

4. Megatron got updated.

Currently, c1susaux seems unresponsive and needs to be rebooted.

  14033   Fri Jun 29 18:16:32 2018 JonConfigurationPSLChanges to AUX Optical Layout on PSL Table

In order to use the 0th-order deflection beam from the AOM for cavity mode scans, I've coaligned this beam to the existing mode-matching/launch optics set up for the 1st-order beam.

Instead of being dumped, the 0th-order beam is now steered by two 45-degree mirrors into the existing beam path. The second mirror is on a flip mount so that we can quickly switch between 0th-order/1st-order injections. None of the existing optics were touched, so the 1st-order beam alignment should still be undisturbed.

Currently the 0th-order beam is being injected into the IFO. After attenuating so as to not exceed 100 mW incident on the fiber, approximately 50 mW of power reaches the AS table. That coupling efficiency is similar to what we have with the 1st-order beam. With the Y-arm cavity locked and the AUX PLL locked at RF offset = 47.60 MHz (an Y-arm FSR), I observed a -50 dBm beat note at Y-end transmission.

Attachment 1: PSL_AUX_SETUP_CHANGE.pdf
PSL_AUX_SETUP_CHANGE.pdf
  11840   Wed Dec 2 18:54:20 2015 gautamUpdateCDSChanges to C1MCS, C1PEM

Summary:

I've made several changes to the C1MCS model and C1PEM model, and have installed BLRMS filters for the MC mirror coils, which are now running. The main idea behind this test was to see how much CPU time was added as a result of setting up IPC channels to take the signals from C1MCS to C1PEM (where the BLRMS filtering happens) - I checked the average CPU time before and after installing the BLRMS filters, and saw that the increase was about 1 usec for 15 IPC channels installed (it increased from ~27usec to 28usec). A direct scaling would suggest that setting up the BLRMS for the vertex optics might push the c1sus model close to timing out - it is at ~50usec right now, and I would need, per optic, 12 IPC channels, and so for the 5 vertex optics, this would suggest that the CPU timing would be ~55usecI have not committed either of the changed models to the SVN just yet

Details:

  1. On Eric's suggestion, I edited the C1_SUS_SINGLE_CONTROL library part to tap the signal at the input to the output filters to the coils, as this is what we want the BLRMS of. I essentially added 5 more outputs to this part, one for each of the coils, and they are named ULIn etc to differentiate it from the signal after the output filters. I have not committed the changed library part to the SVN just yet
  2. I used the cdsIPCx_SHMEM part to pipe the signals from C1MCS to C1PEM - a total of 15 such channels were required for the three IMC mirrors.
  3. I added the same cdsIPCx_SHMEM parts to the C1PEM model in the receiving configuration, and connected their outputs to BLRMS blocks. The BLRMS blocks themselves are named as RMS_MC2_UL_COIL_IN and so on.
  4. I shutdown the watchdogs to MC1, MC2 and MC3, and restarted the C1PEM and C1MCS models on C1SUS. Yutaro pointed out that on restarting C1MCS, the IMC autolocker was disabled by default - I have enabled it again manually.
  5. I was under the impression that each time a BLRMS block is added, a filter bank is automatically added to the C1PEM.txt file in /opt/rtcds/caltech/c1/chans - turns out, it doesn't and my script for copying the template bandpass and lowpass filtes into the .txt files was needlessly complicated. It suffices to change the filter names in the template file, and append the template file to C1PEM.txt using the cat command: i.e. cat template.txt > C1PEM.txt. The computer generated file seems to organize the filters in alphabetical order, and my approach obviously does not do so, but the coefficients are loaded correctlty and the filters seem to be functioning correctly so I don't think this is a problem (I measured the transfer function of one of the filters with DTT, it seems to match up well with the Foton bode plot). 
  6. I added a few lines to the script to also turn on the filter switches after loading the filter coefficients.

Next steps:

Now that I have a procedure in place to install the BLRMS filters, we can do so for other channels as well, such as for the coils and Oplevs of the vertex optics, and the remaining PEM channels (SEIS, accelerometers, microphones?). For the vertex optics though, I am not sure if we need to do some rearrangement to the c1sus model to make sure it does not time out...

  260   Thu Jan 24 20:03:40 2008 AndreyConfigurationSUSChanges to Dataviewer channels (XARM)

1) Good news. I added a chanel "C1:SUS-ETMX_POS" to Dataviewer.

I followed the instructions from WIKI-40:

modify the file "C1SUS_EX.ini" in /cvs/cds/caltech/chans/daq,
then telnet to fb40m,
then "click the appropriate blue button on the DAQ MEDM screen".

So, I can now read a signal from the channel "C1:SUS-ETMX_POS" in Dataviewer,

and this allows me to measure Q-factors of ETMX this evening (make similar work for what I did on Tuesday for ITMX).


2) BAD NEWS. While "clicking the appropriate blue button" on the DAQ MEDM screen,
namely CODAQ_DETAIL,adl screen, I obviously clicked some blue button that I should not have clicked,
and as a result the signal in Dataviewer from the channel "C1:SUS-ITMX_POS" has disappeared (it is now a straight line).


Description of what has happened and of my wrong actions:
I had two channels opened in Dataviewer simultaneously (both "C1:SUS-ETMX_POS" and "C1:SUS-ITMX_POS"),
and after clicking some blue button on CODAQ_DETAIL,adl screen, the signal from "C1:SUS-ITMX_POS" became
a straight line,
while signal from "C1:SUS_ETMX_POS" continued to be a random noise.

I was scared that I made worse for the channels and for Dataviewer, and I started clicking random blue buttons chaotically hoping that it will restore the signal from "C1:SUS-ITMX_POS". Random clicking on arbitrary blue buttons did not return the signal.

As the channel "C1:SUS-ETMX_POS" works normally, I will be measuring Q-factors of ETMX tonight,
but it is obvious that someone else (Rana, Robert,Steve?) needs to restore the correct settings for "C1:SUS-ITMX_POS".

Moreover, as I was clicking chaotically all the blue buttons on CODAQ_DETAIL,adl screen, someone else (Rana, Robert, Steve?) will need to check somehow that I did not destroy signals from some other channels.

I apologize for the negative consequences of my channel adding,

but Rana asked me in the very beginning in September to let others know if I spoil something, so that others would be aware of it and could fix the problem.

Again, I apologize and hope that the problem is not very serious.
  263   Fri Jan 25 08:55:26 2008 robConfigurationGeneralChanges to Dataviewer channels (XARM)

As a general rule,


Quote:
clicking random blue buttons chaotically


is not a good problem solving technique. It is thus now explicitly discouraged as an option in the LIGO 40m Lab.
  265   Fri Jan 25 10:14:35 2008 robConfigurationSUSChanges to Dataviewer channels (XARM)

Quote:

2) BAD NEWS. While "clicking the appropriate blue button" on the DAQ MEDM screen,
namely CODAQ_DETAIL,adl screen, I obviously clicked some blue button that I should not have clicked,
and as a result the signal in Dataviewer from the channel "C1:SUS-ITMX_POS" has disappeared (it is now a straight line).


Description of what has happened and of my wrong actions:
I had two channels opened in Dataviewer simultaneously (both "C1:SUS-ETMX_POS" and "C1:SUS-ITMX_POS"),
and after clicking some blue button on CODAQ_DETAIL,adl screen, the signal from "C1:SUS-ITMX_POS" became
a straight line,
while signal from "C1:SUS_ETMX_POS" continued to be a random noise.

I was scared that I made worse for the channels and for Dataviewer, and I started clicking random blue buttons chaotically hoping that it will restore the signal from "C1:SUS-ITMX_POS". Random clicking on arbitrary blue buttons did not return the signal.

As the channel "C1:SUS-ETMX_POS" works normally, I will be measuring Q-factors of ETMX tonight,
but it is obvious that someone else (Rana, Robert,Steve?) needs to restore the correct settings for "C1:SUS-ITMX_POS".

Moreover, as I was clicking chaotically all the blue buttons on CODAQ_DETAIL,adl screen, someone else (Rana, Robert, Steve?) will need to check somehow that I did not destroy signals from some other channels.

I apologize for the negative consequences of my channel adding,

but Rana asked me in the very beginning in September to let others know if I spoil something, so that others would be aware of it and could fix the problem.


I eventually resolved the situation by restarting the c1susvme1 processor, which had somehow got confused by the clicking random blue buttons chaotically. The data acquisition should be working again.
  302   Fri Feb 8 17:09:52 2008 Max JonesUpdateComputersChanges to NoiseBudget
Today I altered the following files

caltech/NB/matlab/utilities/get_dtt_dataset
In DARM_CTRL case I changed the second channel name to DARM_ERR. Messy but it may be effective.

caltech/NB/matlab/noise/getUGF.m
I commented out lines of code specifically pertaining to non-existent DARM_DAQ channel. Marked in
code around approximately line 60.

Please address all comments or concerns to me (williamj(at symbl)caltech.edu). Thank you.
  10037   Fri Jun 13 18:16:00 2014 NichinUpdateElectronicsChanges to the PD frequency response measurement system

 

As we had planned yesterday (ELOG 10034) I and Eric Gustafson wanted to manually measure the transimpedence for REFL33. But on closer inspection I found the RF signal cable coming from the Photodiode REF DET (mounted on the POY table), that we were supposed to plug into the network analyzer, did not have an SMA connector at the end. There was just the Teflon and metal part sticking out of the insulation. So we disconnected the cable labeled REF DET from the PD and pulled it out to fix it. (POY table and from near the 1Y1 rack)

 

 

Being unable to locate any SMA male connectors in the 40m lab [pasternack PE4025], we headed over to Downs where Rich Abbott did a quick and awesome job of soldering the SMA connector and also teaching me in the process. I will write an ELOG on how to do a clean solder of the SMA connectors to the RF cable shortly for future reference.

 

 

Coming back to the 40m we rerouted the REF DET cable from near the 1Y1 rack and into the POY table. This job was done mostly by Eric. We were also unable to locate a torque wrench to tighten the cable at the PD’s end and had to leave it finger tight. Eric is planning to buy a new torque wrench as we will need it often.

 

 

Also, I cross checked the SwithList located at /users/alex.cole/switchList with the RF switch connections at 1Y1 rack and turns out it is consistent, except that at CH2 of the first switch where MC REFL was to be connected, there is a unlabeled cable. It might belong to the correct PD, but must be made sure of. The rest of the channels that are not mentioned in the list were unconnected on the RF switch.

 

Now instead of disconnecting REFL 33 to make measurements with the NA, we had to take out AS55 from the RF switch, as the former was very hard to remove without the torque wrench. Then Eric removed the optical fiber which was illuminating the AS55 (AS table) from its mount to hook it up to the power meter. But then we were not sure of how to operate the Laser diode controller (LDC 3744C) and decided to leave stuff as it is and continue either tomorrow or on Monday. Right now we closed the optical fiber of AS55 with a cap and it remains unmounted. The RF cables of REF DET and AS55 were left hanging near the 1Y1 rack.

  10062   Wed Jun 18 18:16:26 2014 NichinUpdateElectronicsChanges to the PD frequency response measurement system

[Nichin, Eric G, Koji]

Continuing out work from elog:10037, we wanted to check if the frequency response of AS55. Having figured out exactly how to use the Laser diode controller (LDC 3744C), we hooked up a fiber power meter to the optical fiber illuminating AS55 (that we disconnected from its mount last Friday ) and raised up the current to 150mA to get almost 0.8mW power reading.

When aligning the fiber to illuminate the PD, we found that the beam was pretty wide. So we pulled out the collimator and tweaked it to get a focused beam. The fiber was mounted back and was aligned to get a maximum DC reading. The multimeter readout 30mV finally. Taking the transimpedence as 200ohm approx., the hot current is about 1.5mA.

Network analyzer was now connected to the modulation input of the laser and the RF output from REF DET and AS55 (inputs to RF switch at rack 1Y1) were connected as input to measure the transfer function. We got just noise on the scope of NA. So, then we tried REFL33 as the Input and still got nothing (We were also not sure if this PD was properly illuminated, we did not check). However the REF DET was giving a nice response on the scope. Turns out all the PDs were disconnected form the Demodulator (D990511) on rack 1Y2.

On closer inspection the RF cable between domodulator and RF switch that was labelled AS55 had a loose SMA connector at the switch end. I will have to fix that tomorrow . For the time being Koji connected the cable labelled REFL33 to the AS55 demodulator and we finally got a response form the AS55 PD on the NA. However no readings were recorded. The power supply to REF DET was turned off in the end as Eric G claimed that it has been ON for almost a year now, which is not a good thing. Also, we removed the modulation input from NA to the diode laser and terminated the input with a 50ohm terminator.

We planned to pull out and check each and every RF cable (especially the SMA ends for faulty soldering and loose connections) and fix/ replace them as needed.

  10065   Wed Jun 18 21:53:48 2014 KojiUpdateElectronicsChanges to the PD frequency response measurement system

Not "hot" current but "photo" current. Is this my bad!?

It was me who told Nichin that the DC transimpedance was 200Ohm. But according to this entry I checked the RF transimpedance of AS55 before.
In my code, the DC transimpedance was defined to be 50Ohm. If we believe it, 30mV corresponds to 0.6mA.

Quote:

The multimeter readout 30mV finally. Taking the transimpedence as 200ohm approx., the hot current is about 1.5mA.

 

  3866   Thu Nov 4 19:26:51 2010 SureshUpdateLockingChanges to the Video MUX reversed

All the temporary changes to the video cables and the video MUX ( 3843 ) have been reversed and the system returned to its original state.

  9669   Tue Feb 25 02:46:38 2014 rana, jenneUpdateLSCChanging PRCL offset changes REFL 165 degeneracy

[Jenne, Rana]

We put offsets in the PRCL and MICH loops, and measured sensing matrices for each condition. 

What we found was that PRCL offsets of order 1/20th a linewidth (calibration to be checked tomorrow) would give significant changes in the angles of the REFL signal sensing matrix elements.  We broke MICH lock before we were able to put in a significant enough offset to see the demod phases change.

Because there are so many plots, I've put them together in a pdf. Each page has a set of radar plots for sensing matrix elements.  On the bottom of each page I note what our MICH and PRCL offset values were, and where the data is saved (in the 40m scripts directory). To see the differences, make sure your pdf viewer is set to single-page, not scrolling.

PRC_offsetCheck_24Feb2014.pdf

One major thing that we noted was that putting in a PRCL offset also changed the MICH offset.  When we increased the PRCL offset, we saw the AS port get brighter (but not as bright as when we were putting in large MICH offsets). 

Tomorrow, I need to check the calibrations we were using, to see how many meters we were moving the optics.  Also, Q, Gabriele and I need to meditate and do some modelling to figure out why the length offset could be affecting the degeneracy so strongly. 

  9670   Tue Feb 25 14:48:49 2014 ericqUpdateLSCChanging PRCL offset changes REFL 165 degeneracy

After speaking with Jenne and Gabriele, I did a little bit of simulating based on my earlier code that looked at the angle of MICH vs. PRCL, just with cavity detuning instead of macroscopic length change.

The zero point in the following plots is with the PRC locked on the sideband. The PRC detuning was done by changing the PRM-BS microscopic length (in terms of phase), and the MICH detuning was done by adding half of the detuning to the BS-ITMY distance, and subtracting half of it from the BS-ITMX distance. 

MICHvPRCLangle_wOffset.pdf

 

This plot is in terms of radians, so to roughly relate it to line width, here's a plot of the POP powers as a function of the PRC detuning. 

SBprclPeaks.pdf 

  9671   Tue Feb 25 16:07:33 2014 ericqUpdateLSCChanging PRCL offset changes REFL 165 degeneracy

 And glossing over the MICH offset, here's the PRC offset plots in displacement, rather than radians.

The simulation is actually slightly different now. I now use nominal ITM T values (T=.014) instead of the random R=.99 I had in place. 

MICHvPRCLangle_wOffset.pdfMICHvPRCLangle_wOffset_fullscale.pdf

(correction: Field Power should be Field Amplitude in the first plot)

  9676   Wed Feb 26 01:49:08 2014 JenneUpdateLSCChanging PRCL offset changes REFL 165 degeneracy

I have measured the sensing matrix at a variety of PRCL offset values.

DemodPhaseSeparation.pdf

During this each measurement, I also took a 20 second average of the POP 2f signals and the ASDC signal:

POP_AS_PDvalues.pdf

All of this data was taken during a single lock stretch. 

If / when I do this again, I want to go out to larger offsets.  I won't take as many points, but I do want to see how far I can go before I lose lock, and what the phase separation looks like at larger offset values (this time, I stopped at +700 counts which is about 0.7nm, to start checking the negative values. MC has been unhappy, so I wasn't able to take very many negative offset values.) 

I conclude that these sensing matrix measurements do see changes in the phase separation with PRCL length offset (what we saw / said yesterday), but that they do not line up with Q's simulation from this afternoon in elog 9671.

The simulation says that we shouldn't be seeing large phase changes until we get out to several nanometers, however the measurement is showing that we get large phase chnages with picometer scale offsets.  Yesterday, Rana and I said that the offsets due to RAM were small (of order picometer), and that they were therefore likely not important (elog 9668).  However, now it seems that the RAM is causing significant length offsets which then cause poor MICH/PRCL phase separation.

To Do List:

* Confirm MIST simulation with Optickle.

* Look at sensing matrix data pre-lockins (in the raw sensors).

* Check that there is no clipping anywhere in the REFL path (at least out of vacuum), and that the beam is sufficiently small on all 4 REFL diodes.

* Calculate the new PRC g-factor with the new length.

  3633   Fri Oct 1 11:33:15 2010 josephb, alexConfigurationCDSChanging gds code to the new working version

Alex is installing the newly compiled gds code (compiled on Centos 5.5 on Rosalba) which does in fact include the ezca type tools. 

At the moment we don't have a solaris compile, although that should be done at somepoint in the future.  It means the gds tools (diaggui, foton, etc) won't work on op440m.  On the bright side, this newer gds code has a foton that doesn't seem to crash all the time on Linux.

 

  517   Wed Jun 4 13:46:42 2008 josephbConfigurationCamerasChanging incident angle images
Attached are images from the GC650 and GC750 when the incident angle was varied from 0 tilt (normal incidence) to 5,10, and 20 degrees. Each time the beam was realigned via the last turning mirror to be on roughly the same spot. This light was a pickoff of the PSL table light just before it leaves the table.

Images include the raw data, fit to the data, residual normalized by peak power "w(1)", and normalized by the individual bin power.

The first pdf includes 0 degrees (normal) and ~5 degrees of tilt for the GC650 (CCD) camera.

The second pdf includes ~10 and ~20 degrees of tilt images for the GC650 (CCD) camera.

The third pdf includes 0 and ~5 degrees of tilt for the GC750 (CMOS) camera.

The fourth pdf includes ~10 and ~20 degrees of tilt for the GC750 (CMOS) camera.

Things to note:
1) GC750 camera seems to have a structure on the camera itself, somewhat circular in nature. One possible explanation is the camera was damage at a previous juncture due to too much light. Need to check earlier images for this problem.
2) GC650 has "bands" which change direction and thickness with angle. Also at higher incidence angle, the sensitivity seems to drop (unlike the GC750 where overall power level seems to stay constant with increasing angle of incidence).
3) GC650 seems to have a higher noise floor,seen from the last plot of each pdf (where each pixel of the residual is normalized by the power in the corresponding pixel of the fit).
Attachment 1: GC650_0dg_5dg.pdf
GC650_0dg_5dg.pdf GC650_0dg_5dg.pdf GC650_0dg_5dg.pdf GC650_0dg_5dg.pdf GC650_0dg_5dg.pdf GC650_0dg_5dg.pdf GC650_0dg_5dg.pdf
Attachment 2: GC650_10dg_20dg.pdf
GC650_10dg_20dg.pdf GC650_10dg_20dg.pdf GC650_10dg_20dg.pdf GC650_10dg_20dg.pdf GC650_10dg_20dg.pdf GC650_10dg_20dg.pdf GC650_10dg_20dg.pdf
Attachment 3: GC750_0dg_5dg.pdf
GC750_0dg_5dg.pdf GC750_0dg_5dg.pdf GC750_0dg_5dg.pdf GC750_0dg_5dg.pdf GC750_0dg_5dg.pdf GC750_0dg_5dg.pdf GC750_0dg_5dg.pdf
Attachment 4: GC750_10dg_20dg.pdf
GC750_10dg_20dg.pdf GC750_10dg_20dg.pdf GC750_10dg_20dg.pdf GC750_10dg_20dg.pdf GC750_10dg_20dg.pdf GC750_10dg_20dg.pdf GC750_10dg_20dg.pdf
  1579   Wed May 13 02:53:12 2009 robSummaryloreChannel Hopping: That ancient enemy (MC problems)

We were stymied tonight by a problem which began late this afternoon.  The MC would periodically go angularly unstable, breaking lock and tripping the MC2 watchdogs.  Suspicion fell naturally upon McWFS.

Eventually I traced the problem to the MC3 SIDE damping, which appeared to not work--it wouldn't actually damp, and the Vmon values did not correspond to the SDSEN outputs.  Suspicion fell on the coil driver.

Looking at the LEMO monitors on the MC3 coil driver, with the damping engaged, showed clear bit resolution at the 100mV level, indicating a digital/DAC problem.  Rebooting c1sosvme, which acquires all the OSEM sensor signals and actually does the side damping, resolved the issue. 

  1582   Wed May 13 14:43:29 2009 robSummaryloreChannel Hopping: That ancient enemy (MC problems)

Quote:

We were stymied tonight by a problem which began late this afternoon.  The MC would periodically go angularly unstable, breaking lock and tripping the MC2 watchdogs.  Suspicion fell naturally upon McWFS.

Eventually I traced the problem to the MC3 SIDE damping, which appeared to not work--it wouldn't actually damp, and the Vmon values did not correspond to the SDSEN outputs.  Suspicion fell on the coil driver.

Looking at the LEMO monitors on the MC3 coil driver, with the damping engaged, showed clear bit resolution at the 100mV level, indicating a digital/DAC problem.  Rebooting c1sosvme, which acquires all the OSEM sensor signals and actually does the side damping, resolved the issue. 

 Lies!  The problem was not resolved. The plot shows a 2-day trend, with the onset of the problem yesterday clearly visible as well as the ineffectiveness of the soft-reboot done yesterday.   So we'll try a hard-reboot.

Attachment 1: MC3sidemon.png
MC3sidemon.png
  1583   Wed May 13 21:15:04 2009 ranaSummarySUSChannel Hopping: That ancient enemy (MC problems)
The MC side problem could also be the side tramp unit problem. Set the tramp to 0 and see if that helps.
  1584   Thu May 14 00:15:39 2009 robSummarySUSChannel Hopping: That ancient enemy (MC problems)

Quote:
The MC side problem could also be the side tramp unit problem. Set the tramp to 0 and see if that helps.


This started around April 23, around the time that TP1 failed and we switched to the cryopump, and also when there was a mag 4 earthquake in LA. My money's on the EQ. But I don't know how.
Attachment 1: sidemon.png
sidemon.png
  1587   Thu May 14 16:07:20 2009 peteSummarySUSChannel Hopping: That ancient enemy (MC problems)

Quote:

Quote:
The MC side problem could also be the side tramp unit problem. Set the tramp to 0 and see if that helps.


This started around April 23, around the time that TP1 failed and we switched to the cryopump, and also when there was a mag 4 earthquake in LA. My money's on the EQ. But I don't know how.


I wonder if this is still a problem. It has been quiet for a day now. I've attached a day-long trend. Let's see what happens.
Attachment 1: mc3_5days.jpg
mc3_5days.jpg
  13662   Wed Feb 28 21:14:34 2018 gautamSummaryPEMChannel admin

Since we decided to use the Acromag for readback of the temperature sensor for Kira's seismometer temperature control, I enabled logging of the channel Johannes had reserved for this purpose last week. Kira has made the physical connection of a temperature sensor to the BNC input for this channel - it reads back -2.92 V right now, which is around what I remember it being when Kira was doing her benchtop tests. I edited C0EDCU.ini to enable logging of this channel at 16 Hz. Presumably, a study of the ADC noise of the Acromag at low frequencies has to be made to ensure appropriate whitening (if any) can be added. Channel name is C1:PEM-SEIS_EX_TEMP_MON. Similarly, there is C1:PEM_SEIS_EX_TEMP_CTRL which is meant to be the control channel for the servoing. Calibration of the temperature sensor readback into temperature units remains. It also remains to be verified if we can have these slow EPICS channels integrated with a fast control model, or if the PID temperature control will be purely custom-script based as we have for the FSS slow loop.

I removed the fast channels I had setup temporarily in c1als. Recompilation and restart of the model went smoothly.

Quote:
 I then made a "PEM" namespace block inside the c1als model, and placed a single CDS filter module inside it (this can be used for calibration purposes). The filter module is named "C1:PEM-SEIS_EX_TEMP", and has the usual CDSfilt channels available. I DQ'ed the output of the filter module (@256 Hz, probably too high, but I'm holding off on a recompile for now). Recompilation and model restart of c1als went smoothly. 
 
Attachment 1: tempSensData.png
tempSensData.png
  13873   Mon May 21 15:34:19 2018 gautamConfigurationElectronicsChannel hijacking history

Since we've been hijacking channels like there is no tomorrow for the AUX-PLL setup, I'm documenting the channel names here. The next time c1psl requires a reboot, I'll rename these channels to something more sensible. To find the channel mapping, Koji suggested I use this. Has worked well for us so far... We've labelled all pairs of wires pulled out of the cross connects and insulation taped the stripped ends, in case we ever need to go back to the original config.

Previously unused C1PSL Channels now used for AUX PLL

Channel name AI/AO Function
C1:PSL-126MOPA_126CURADJ AO Slow temperature control
C1:PSL-FSS_RFADJ AO Servo trigger TTL
C1:PSL-126MOPA_126PWR AI PLL error signal monitor
C1:PSL-126MOPA_DMON AI PLL control signal monitor
C1:PSL-FSS_PHCON AO

To mitigate integrator railing

  4152   Thu Jan 13 16:41:07 2011 josephbUpdateCDSChannel names for LSC updated

I renamed most of the filter banks in the c1lsc model.  The input filters are now labeled based on the RF photodiode's name, plus I or Q.  The last set of filters in the OM subsystem (output matrix) have had the TO removed, and are now sensibly named ETMX, ETMY, etc.

We also removed the redundant filter banks between the LSCMTRX and the LSC_OM_MTRX.  There is now only one set, the DARM, CARM, etc ones.

The webview of the LSC model can be found here.

  14744   Wed Jul 10 14:57:01 2019 KojiSummaryCDSChannel recipe for iscaux upgrade

The list of the iscaux channels and pin assignments were posted to google drive.
The spreadsheet can be viewable by the link sent to the 40m ML. It was shared with foteee@gmail for full access.

Summary

  • We need
    4 ADC modules
    5 DAC modules
    5 Binary I/O modules
  • Be aware that there are bundled multiple digital I/O channels such as "mbboDirect" and "mbbi".
  • The full db record of the new channels need to be inferred from the existing channels.

Necessary electronics modification

1. D990694 whitening filter modification (4 modules)

This module shares the fast and slow channels on the top DIN96pin (P1) connector. Also, the whitening selector (done by an analog signal per channel) is assigned over 17pin of the P1 connector, resulting in the necessity of the second DSUB cable. By migrating the fast channels, we can swap the cable from the P1 to P2.  Also, the whitening selectors are concentrated on the first Dsub. (See Attachment1 P1)

2. D040180 / D1500308 Common Mode Board

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

3. D990543A1 LSC Photodiode Interface

PD I/F board has the DC mon channels spread over the 16pin limit. P1 21A can be connected to 6A so that we can accommdate it in the first Dsub.
Also the board uses AD797s. This is not necessary. We can replace them to OP27s. I actually don't know what is happening to those bias control, temp mon, enable, and status. These features should be disables at the I/F and the PDs. (See Attachment2 P1)

Attachment 1: D990694-B.pdf
D990694-B.pdf D990694-B.pdf D990694-B.pdf D990694-B.pdf D990694-B.pdf D990694-B.pdf D990694-B.pdf D990694-B.pdf
Attachment 2: D990543A1.PDF
D990543A1.PDF D990543A1.PDF D990543A1.PDF
  13710   Tue Mar 27 11:11:16 2018 KiraUpdatePEMChannel setup

[Kira, Gautam]

We setup the channels for PID control of the seismometer can. First, we ssh into c1auxex and went to /cvs/cds/caltech/target/c1auxex2 and found ETMXaux.db. We then added in new soft channels that we named C1:PEM-SEIS_EX_TEMP_SLOWKP, C1:PEM-SEIS_EX_TEMP_SLOWKI, C1:PEM-SEIS_EX_TEMP_SLOWKD that will control the proportional, integral and differential gain respectively. These channels are used in the script FSSSlow.py for PID control. We then had to restart the system, but first we turned off the LSC mode and then shut down the watchdog on the X end. After doing the restart, we disabled the OPLEV as well before restarting the watchdog. Then, we enabled the LSC mode again. This is done to not damage any of the optics during the restart. The restart is done by using sudo systemctl restart modbusIOC.service and restarted with sudo systemctl status modbusIOC.service. Then, we made sure that the channels existed and could be read and writtten to, so we tried z read [channel name] and it read 0.0. We then did z write [channel name] 5, and it wrote 5 to that channel. Now that the channels work, we can implement the PID script and check to make sure that it works as well.

  8911   Tue Jul 23 19:38:58 2013 gautamUpdateCDSCharacterisation of DAC at 1X9

 

 I just finished carrying out the same checks for the DAC at 1X9 (with channels 9 through 16 that are unused as of now) as those I had done for the DAC at 1Y4, as the hardware prep up till now was done with the characterisation of the DAC at 1Y4. Conclusions:

  • The accessible range of output voltage are -10 V to +10V w.r.t ground --> No change needs to be made to the gain of the HV amplifier stage on the PZT Driver Board
  • The pin-outs of the DAC Adaptor Board at 1X9 is identical to that at 1Y4 --> Custom ribbons do not need to be modified.
  • The PSD of the DAC output has a peak at 64 kHz --> Notches on AI Board do not need to be moved again.

I will now proceed to install various pieces of hardware (AI Board, PZT driver board, HV Power Supply and cabling) at 1X9, while not making the connection to the PZTs till I receive the go ahead. 

  17073   Wed Aug 10 20:30:54 2022 TegaSummarySUSCharacterisation of suspension damping

[Yuta, Tega]

We diagnosed the suspension damping of the IMC/BHD/recycling optics by kicking the various degree of freedom (dof) and then tuning the gain so that we get a residual Q of approx. 5 in the cases where this can be achieved.

MC1: Good
MC2: SIDE-YAW coupling, but OK
MC3: Too much coupling between dofs, NEEDS ATTENTION
LO1: Good
LO2: Good
AS1: POS-PIT coupling, close to oscillation, cnt2um off, NEEDS ATTENTION
AS4: PIT-YAW coupling, cannot increase YAW gain because of coupling, No cnt2um, No Cheby, NEEDS ATTENTION
PR2: No cnt2um, No Cheby
PR3: POS-PIT coupling, cannot increase POS/PIT/YAW gain because of coupling, No cnt2um, No Cheby, NEEDS ATTENTION
SR2: No cnt2um

Attachment 1: BHD_SUSPIT_KICK.png
BHD_SUSPIT_KICK.png
Attachment 2: BHD_SUSPOS_KICK.png
BHD_SUSPOS_KICK.png
Attachment 3: BHD_SUSSIDE_KICK.png
BHD_SUSSIDE_KICK.png
Attachment 4: BHD_SUSYAW_KICK.png
BHD_SUSYAW_KICK.png
Attachment 5: IMC_SUSPIT_KICK.png
IMC_SUSPIT_KICK.png
Attachment 6: IMC_SUSPOS_KICK.png
IMC_SUSPOS_KICK.png
Attachment 7: IMC_SUSSIDE_KICK.png
IMC_SUSSIDE_KICK.png
Attachment 8: IMC_SUSYAW_KICK.png
IMC_SUSYAW_KICK.png
Attachment 9: PRSR_SUSPIT_KICK.png
PRSR_SUSPIT_KICK.png
Attachment 10: PRSR_SUSPOS_KICK.png
PRSR_SUSPOS_KICK.png
Attachment 11: PRSR_SUSSIDE_KICK.png
PRSR_SUSSIDE_KICK.png
Attachment 12: PRSR_SUSYAW_KICK.png
PRSR_SUSYAW_KICK.png
  3197   Mon Jul 12 15:49:56 2010 nancyUpdateSUSCharacterisation of the QPD

I and koji setup the measurement of the QPD response to the pitch and yaw displacements of the beam spot.

We did this using a 100mW 1064nm laser. Its power was attenuated to ~ 1.9mW, and the spot size at the QPD position was 6000-7000 um .

The QPD was put on a translation stage, using which, the center of teh QPD wrt the beam spot could be moved in pitch and yaw.

Following are the measurements :

For yaw

:fullyaw.jpg

The slope of teh linear region is -8356 /inch

yaw_linear.jpg

 For pitch

fullpitch.jpg

The slope of the linear region in this is 9085/inch

 

pitch_linear.jpg

 

  3198   Mon Jul 12 17:05:30 2010 nancyUpdateSUSCharacterisation of the QPD

Quote:

I and koji setup the measurement of the QPD response to the pitch and yaw displacements of the beam spot.

We did this using a 100mW 1064nm laser. Its power was attenuated to ~ 1.9mW, and the spot size at the QPD position was 6000-7000 um .

The QPD was put on a translation stage, using which, the center of teh QPD wrt the beam spot could be moved in pitch and yaw.

Following are the measurements :

 

 The old plots looked horrible, and so here is a new plot

plot.png

The slopes and other stats are

Pitch

Linear model Poly1:
     f(x) = p1*x + p2
Coefficients (with 95% confidence bounds):
       p1 =        8550  (7684, 9417)
       p2 =       -2148  (-2390, -1906)

Goodness of fit:
  SSE: 9944
  R-square: 0.9923
  Adjusted R-square: 0.9907
  RMSE: 44.59

Yaw

Linear model Poly1:
     f(x) = p1*x + p2
Coefficients (with 95% confidence bounds):
       p1 =       -8310  (-8958, -7662)
       p2 =        2084  (1916, 2252)

Goodness of fit:
  SSE: 6923
  R-square: 0.9954
  Adjusted R-square: 0.9945
  RMSE: 37.21

Attachment 1: plot.png
plot.png
  16939   Wed Jun 22 17:04:06 2022 DeekshaSummaryElectronicsCharacterising the AUX control loop

[Cici, Deekha]

Setup loop to measure transfer function of control loop - the aim is to find the open loop gain of the system using the SR785 to inject noise (a swept sine) into the system and taking observations using the scope. We tried to calculate the gain algaebraically, in order to understand what our readings meant and what we can determine from them. Need to figure out how to run python script for the SR785, but took readings from cmd today.

Included - changes/additions made to circuit; frequency reponse obtained (need to check the frequency response as it does not look like the expected result, need to correct the loop itself, or increase the magnitude of the inserted noise as its possible that the noise is currently being suppressed by the system).

To do - circuit needs to be checked + laser lock improved - laser keeps leaving resonance while trying to take readings.

 

Attachment 1: after.jpeg
after.jpeg
Attachment 2: before.jpeg
before.jpeg
Attachment 3: freq_response.png
freq_response.png
  14111   Sat Jul 28 22:16:49 2018 John MartynUpdate Characterization of Transimpedance Amplifier

Kevin and I meaured the transfer function of the photodiode circuit using the Jenne laser and agilent in the 40m lab. The attached figures depict our measured transfer function over the modulation frequency ranges of 30kHz-30MHz and 1kHz-30MHz when the power of the laser was set to 69 and 95 μW. These plots indicate a clear roll off frequency around 300 kHz. In addition, the plots beginning at 1kHz display unstable behavior at frequencies below 30kHz. I am not sure why there is such a sharp change in the transfer function around 30kHz, but I suspect this to be due to an issue with the agilent or photodiode. 

Attachment 1: PD_TF1.pdf
PD_TF1.pdf
Attachment 2: PD_TF2.pdf
PD_TF2.pdf
Attachment 3: PD_and_TIA_Transfer_Function_Measurements.zip
  14112   Sun Jul 29 00:59:54 2018 KojiUpdateElectronicsCharacterization of Transimpedance Amplifier

You have this measurement problem when the IF bandwidth is larger than the measurement frequency. I suspect the IF bandwidth is 30kHz.

  10036   Fri Jun 13 11:33:55 2014 AkhilUpdateElectronicsCharacterization of UFC-6000 RF Frequency Counter

 Goal:

To characterize the Mini-Circuits RF FC (Model UFC-6000) and plot Bode Plots at varying Modulation frequencies.

Work Done:

Here are the list of measurements(files attached) taken from FC using SRS(Model DS345) Synthesized Function Generator for a Sinusoidal signal at different Modulation Frequencies ranging from 0.01 Hz to 1 KHz:

Carrier Frequency                          Modulation Depth                                                        Attached measurement Folder 

5 MHz                                                     Δ f = 5 MHz                                                                            Bode_5

10 MHz                                                   Δ f = 10 MHz                                                                          Bode_10

20 MHz                                                   Δ f = 20 MHz                                                                           Bode_20 

 

The measured data will be used to estimate:

1) Transfer Function of FC 

2) Quantization noise from Power Spectral Density(PSD) vs Hz

 

To Do Next:

1)Complete interfacing the Pi with EPICS.

2)Make bode plots (Matlab script attached) and PSD plots and estimate the control parameters for optimal design of FOLL PID loop.

 

 

Attachment 1: Bode_Plots.zip
  10238   Fri Jul 18 17:10:57 2014 NichinSummaryElectronicsCharacterization of demodulator boards.

Rack 1Y2, I took transfer function measurements for each of the following demodulator boards: REFL11, REFL33, REFL55, REFL165, AS55, POP22, POX11 and POY11.

What I did:

1) Removed the wire at PD Input to demodulator board.

2) Put the MOD output from network analyzer into PD input of board.

3) Ran a sweep from 100kHz to 100MHz.

4) Measured the transfer function between PD RF MON and PD Input. (The PD RF MON signal came out of the RF multiplexer, so the mux is included as well )

5) Put the original wire back at PD Input.

Results:

The plots clearly show an attenuation of 20dB (factor of 10) for all the demodulator boards. This explains why my transimpedance measurements are off by 10 times.

Note: for REFL 165, there was an extra 100MHz high pass filter installed at PD Input. I did not remove this and made my measurements along with this.

To Do:

a) Modify the PDFR system to calibrate out this attenuation.

b) Measure the transfer function between the input and output of RF mux, so that we can have just the transfer function between PD input an PD RF MON (for documentation's sake)

 

Attachment 1: Demodulators_TF.pdf
Demodulators_TF.pdf Demodulators_TF.pdf Demodulators_TF.pdf Demodulators_TF.pdf Demodulators_TF.pdf Demodulators_TF.pdf Demodulators_TF.pdf Demodulators_TF.pdf
  10252   Tue Jul 22 15:50:35 2014 NichinSummaryElectronicsCharacterization of demodulator boards.

Quote:

Rack 1Y2, I took transfer function measurements for each of the following demodulator boards: REFL11, REFL33, REFL55, REFL165, AS55, POP22, POX11 and POY11.

What I did:

1) Removed the wire at PD Input to demodulator board.

2) Put the MOD output from network analyzer into PD input of board.

3) Ran a sweep from 100kHz to 100MHz.

4) Measured the transfer function between PD RF MON and PD Input. (The PD RF MON signal came out of the RF multiplexer, so the mux is included as well )

5) Put the original wire back at PD Input.

Results:

The plots clearly show an attenuation of 20dB (factor of 10) for all the demodulator boards. This explains why my transimpedance measurements are off by 10 times.

Note: for REFL 165, there was an extra 100MHz high pass filter installed at PD Input. I did not remove this and made my measurements along with this.

To Do:

a) Modify the PDFR system to calibrate out this attenuation.

b) Measure the transfer function between the input and output of RF mux, so that we can have just the transfer function between PD input an PD RF MON (for documentation's sake)

 

I repeated the exact steps above and made sure everything was back where it should be after I was done.

Reason I had to retake the measurements:

My script for acquiring data from the AG4395A network analyzer was such that it first acquired the magnitude data from channel 1 and then recorded phase data from channel 2 without holding its trace. Hence the phase and magnitude data were not exactly in sync with each other. So, when I tried to fit the data to a model using vector fitting, I ended up with very bad results.

I have now changed every single script relating to the network analyzer to just get the real and imaginary data in one go and then calculate the phase using this data.

The fitting process is now in progress and results will be up shortly.

Attachment 1: Demodulators_TF.pdf
Demodulators_TF.pdf Demodulators_TF.pdf Demodulators_TF.pdf Demodulators_TF.pdf Demodulators_TF.pdf Demodulators_TF.pdf Demodulators_TF.pdf Demodulators_TF.pdf
  10263   Wed Jul 23 11:54:27 2014 NichinUpdateElectronicsCharacterization of demodulator boards.

Quote:

 

I repeated the exact steps above and made sure everything was back where it should be after I was done.

Reason I had to retake the measurements:

My script for acquiring data from the AG4395A network analyzer was such that it first acquired the magnitude data from channel 1 and then recorded phase data from channel 2 without holding its trace. Hence the phase and magnitude data were not exactly in sync with each other. So, when I tried to fit the data to a model using vector fitting, I ended up with very bad results.

I have now changed every single script relating to the network analyzer to just get the real and imaginary data in one go and then calculate the phase using this data.

The fitting process is now in progress and results will be up shortly.

The plots in the previous Elog includes delay and a little attenuation by RF cables and the RF mux.

Today I separately calculated the delay and attenuation for an RG405 cable (550 cm) and the RF mux(using really small RF cables). These delays should be accounted for when fitting the transfer function of Demodulator boards and transimpedance of PDs.

The plots are in both semilogx and linear.

Attachment 1: 1.pdf
1.pdf 1.pdf
Attachment 2: 2.pdf
2.pdf 2.pdf
  5849   Wed Nov 9 14:49:07 2011 kiwamuSummaryLSCCharacterization of the Power Recycled Michelson

EDIT by KI:

  The definition of the recycling gain is wrong here.

See the latest entry (#5875)

 

Here is a summary about the Power Recycled Michelson (PRMI).

It seems the mode matching is also one of the greatest contributor on the low recycling gain.

 

 

 (Estimated parameters)

    Loss = 5.3% (or effective reflectivity of  93.28% in Michleson) => Under coupling !!

     +  Mode matching efficiency = 47.4 %  => Really bad !!

   With these values we end up with a recycling gain of 7 and a normalized REFLDC of  0.5 as observed (#5773).

Also according the incident beam scan measurement (#5773) the loss is NOT a local effect like a clipping, it is more like uniformly distributed thing.

As for the mode matching, the number indicates that approximately the half of the incident light is coming back to the REFL port without interacting with PRMI.

This is bad because the non-mode-matched light, which is just a junk light, is entering into the photo detectors unnecessarily.

In the worst scenario, those junk light may create a funny signal, for example a signal sensitive to the alignment of PRM.

 

(Estimation method)

The method to estimate the loss and the MM (Mode-Matching efficiency) is essentially the same as before (#5541).

One difference from the previous estimation is that the I used more realistic parameters on the transmissivity of ITMs and PRM :

     PRM : T = 5.637 %  (see the 40m wiki)

     ITM : T = 1.384 %  (see the 40m wiki)

 

 In addition to the basic calculations I also made plots which are handy for figuring out where we are.

Quantities we can measure are the reflected light from PRMI and the recycling gain using the REFL PD and the POY PD respectively.

So I wanted to see how the loss and MM can be estimated from the measured REFL DC and recycling gain.

The plots below are the ones.

contour_loss.png   contour_MM.png

[Loss map]

 The first figure shows a contour map of the loss as a function of the measured REFL DC and recycling gain.

The white area is a place where no proper solutions can be found (for example MM can get to more than 100 or loss becomes negative).

The star mark in the plot corresponds to the place where we are now. Obviously the loss is about 5%.

If we somehow decrease the amount of the loss the star mark will mostly go up in the plot.

[MM map]
 The second figure shows a contour map of the MM as a function of the measured REFL DC and recycling gain. 

The X and Y axis are exactly the same as that of the first plot. Again the star mark represents the place where we are.

We are currently at MM=47%

 

(Solutions)

Here are some solutions to bring the recycling gain higher.

We don't work on these things immediately since it requires opening of the chambers again and it will take some times.

But we should think about those options and prepare some stuff for a coming vent.

  + Refinement of the position of the mode matching telescopes.  => The Recycling gain can go up to 15.

     => Assuming the loss in the cavity doesn't change, the star mark in the first plot will go to the left hand side along the "0.05" black solid line.

     => However PRMI will be still under coupled.

     => Needs an estimation about which way we move the telescopes.

 + Locate the place of the dominant loss source and reduce it somehow.

    => The recycling gain will be more than 18 if the loss reduces by a factor of more than 5.

    => Needs a clever way to find it otherwise we have to do it in the classical way (i.e. white light and trying to find dirty surfaces)

  5851   Wed Nov 9 16:29:36 2011 KojiSummaryLSCCharacterization of the Power Recycled Michelson

Difficult to understand.

The mode matching does not change the recycling gain. It changes the coupling of the incident light into the cavity.
It changes the reflected and accumulated power, but the recycling gain is not affected.

The recycling gain is determined by the optical configuration and the optical loss in the cavity.

In the actual measurement, of course, we should take both of the loss and the mode matching into account.
But this is the issue of the measurement method.

The essential questions are:
How much is the actual recycling gain? And how does it affect the signal extraction?

  5875   Fri Nov 11 14:55:47 2011 kiwamuSummaryLSCCharacterization of the Power Recycled Michelson : take 2

Quote from #5851

The recycling gain is determined by the optical configuration and the optical loss in the cavity.

How much is the actual recycling gain? And how does it affect the signal extraction?

 As Koji pointed out I made a wrong definition on the recycling gain of PRMI (Power-Recycled Michelson Interferomter).

In the correct definition the estimated recycling gain is 15.
In order to answer Koji's second question,which is about the effect on the signal extraction,
I need to scratch my head for a while.
( Give me some time..)
 
The value what I called "Recycling gain" must have been called "measured power build up" or something like that.
For clarity I put the definitions of the quantities.
    Recycling gain :      rec_gain.png 

   Reflectivity of PRMI (measured by REFLDC): refl.png

    Power build up (measured by POY DC) : pbu.png

    Mode Matching (MM) efficiency :  MM.png

    Loss in the PRMI cavity : loss.png

 


 (Results of Measurement and Estimation)

     Estimated recycling gain = 15

     Estimated MM efficiency = 47.4%

     Estimated Loss = 5.3%

     Measured power build Up = 7

     Measured reflectivity of PRMI = 0.5

  16950   Mon Jun 27 13:25:50 2022 CiciUpdateGeneralCharacterizing the Transfer Loop

[Deeksha, Cici]

We first took data of a simple low pass filter, and attempted to perform a fit to both the magnitude and phase in order to find the Z of the components. Once we felt confident in our ability to measure tranfer functions, we took data and plotted the transfer function of the existing control loop of the AUX laser. What we found generally followed the trend of, but was lower than, 10^4/f, which is what we hoped to match, and also had a strange unexplained notch ~1.3 kHz. The magnitude and phase data both got worse after around 40-50 kHz, which we believe is because the laser came out of lock near the end of the run. 

Edit: 

[Attachment 2 and 3] are the frequency response of the low pass filter, curves fitted using least squares in python.

[Attachment 1 and 4] is the same measurement of OLTF of the actual AUX circuit, and the control diagram pointing out the location of excitation and test point.

Attachment 1: TF_measurement_b.png
TF_measurement_b.png
Attachment 2: transfer_function_mag_fit.png
transfer_function_mag_fit.png
Attachment 3: transfer_function_phase_fit.png
transfer_function_phase_fit.png
Attachment 4: control_flow.png
control_flow.png
  3419   Fri Aug 13 09:41:00 2010 nancyOmnistructureComputersCharger for dell laptop

 I have taken the charger for the dark gray dell laptop from its station, and have labelled the information there too.

Will keep it back tonight.

  16196   Wed Jun 9 18:29:13 2021 Anchal, PacoSummaryALSCheck for saturation in ITMX SOS Driver

We did a quick check to make sure there is no saturation in the C1:SUS-ITMX_LSC_EXC analog path. For this, we looked at the SOS driver output monitors from the 1X4 chassis near MC2 on a scope. We found that even with 600 x 10 = 6000 counts of our 619 Hz excitation these outputs in particular are not saturating (highest mon signal was UL coil with 5.2 Vpp). In comparison, the calibration trials we have done before had 600 counts of amplitude, so we can safely increase our oscillator strength by that much yes


Things that remain to be investigated -->

  • What is the actual saturation level?
  • Two-tone intermodulation?
  14060   Thu Jul 12 21:16:25 2018 aaronUpdateOMCChecking OMC Electronics

In preparation for tomorrow's vent, I'm checking some of the OMC-related electronics we plan to use.

First up is the HV Piezo Driver (D060283).

(well, technically the first up was the Kepco HV power supply... but I quickly tested that its output works up to 300V on a multimeter. The power supply for OMC-L-PZT is all good!)

According to the DCC, the nominal HV supply for this board is 200V; the board itself is printed with "+400V MAX", and the label on the HV supply says it was run at 250V. For now I'm applying 200V. I'm also supplying +-15V from a Tektronix supply.

I used two DB25 breakout boards to look at the pins for the DC and AC voltage monitors (OMC_Vmon_+/-, pins 1/6, and OMC_Vmon_AC+/-, pins 2 and 7) on a scope. I hooked up a DS345 function generator to the piezo drive inputn (pins 1,6). According to the 2013 diagram from the DCC, there is just one drive input, and an alternative "dither in" BNC that can override the DAC drive signal. I leave the alternative dither floating and am just talking to the DAC pins.

Aspects of the system seem to work. For example, I can apply a sine wave at the input, and watch on the AC monitor FFT as I shift the frequency. However, anything I do at DC seems to be filtered out. The DC output is always 150V (as long as 200V comes from the supply). I also notice that the sign of the DC mon is negative (when the Vmon_+ pin is kept high on the scope), even though when I measure the voltage directly with a multimeter the voltage has the expected (+) polarity.

A few things to try:

  • The DC_Readout electronics scheme on the wiki has separate oscillator and control inputs. This diagram has lied to us in the past and is older, and the traces on top of the breadboard seem to only go to pins 1 and 6, but I'm going to first try to apply a voltage across pins 2 and 7 in case there actually is a separate control I'm ignoring.
    • Driving on these pins seems to do nothing

On further investigation this was the key clue. I had the wrong DCC document, this is an old version of this board, the actual board we are using is version A1 of D060283-x0 (one of the "other files")

Gautam and Koji returned at this point and we started going through the testpoints of the board, before quickly realizing that the DC voltage wasn't making it to the board. Turns out the cable was a "NULL" cable, so indeed the AC wasn't passing. We swapped out the cable, and tested the circuit with 30V from the HV supply to trim the voltage reference at U14. The minimum voltage we could get is 5V, due to the voltage divider to ground made by R39. We confirmed that the board, powered with 200V, can drive a sine wave and the DC and AC mons behave as expected.

  14072   Sat Jul 14 16:04:34 2018 aaronUpdateOMCChecking OMC Electronics

Next check is the DCPD/OMMT Satellite Box

I traced a cable from the OMC electrical feedthrough flanges to find the DCPD/OMMT Satellite Box (D060105). I couldn't find the DCC number or mention of the box anywhere except this old elog.

Gautam and I supplied the box with power and tested what we think is the bias for the PD, but don't read any bias... we tracked down the problem to a suspicious cable, labelled.

We confirmed that the board supplies the +5V bias that Rich told us we should supply to the PDs.

We tested the TFs for the board from the PD input pins to output pins with a 100kHz low pass (attached, sorry no phase plots). The TFs look flat as expected. The unfiltered outputs of the board appear bandpassed; we couldn't identify why this was from the circuit diagram but didn't worry too much about it, as we can plan to use the low passed outputs.

Attachment 1: Screenshot_2018-07-14_17.53.40.png
Screenshot_2018-07-14_17.53.40.png
Attachment 2: Screenshot_2018-07-14_17.57.17.png
Screenshot_2018-07-14_17.57.17.png
ELOG V3.1.3-