Based on new input from Chub, attached is the revised list of signal cable feedthroughs needed on the vacuum system Acromag crate. I believe this list is now complete.

After a couple of hickups, I was able to compile and install Koji's rework of the LSC model.

The main changes are that the model now use an RF_PD library part, and the channel names were tweaked to be more in line with what we expect.

I found a couple of small bugs in the model that were preventing it from compiling.  Those were fixed and it compiled with no further problems.

There was also some rearrangement of signal inputs to the PD_DOF matrix.  The matrix screen was updated to reflect the proper inputs.  However, this also meant that the burt restore scripts for the IFO configurations were setting the wrong elements in the matrix.  I fixed the settings for X and Y arm locking, and updated the burt snapshots using the burt/c1ifoconfigure/C1save{X,Y}arm scripts.  NOTE: burt settings will need to be updated for the MICH, PRM, DRM, and FULL IFO configurations as well.

During the build/install process, Joe and I also found a bug in the feCodeGen that was causing the filter screens to be created with the wrong names.  Joe sent out a patch that will hopefully be merged soon.  Building the model with Joe's patch fixed the screen names, so the screens are currently named correctly.

I updated the IP address on the Cisco Linksys wireless N router, which we're using to keep megatron separated from the rest of the network.  I then went in and updated megatrons resolv.conf and host files.  It is now possible to ssh into megatron again from the control machines.

I added input noises and angle to length coupling to the noise budget.

I added ADC and whitening filters noise contributions. The ADC noise is assumed to be 1uV/sqrtHz and the whitening noises were measured before in elog 17582. I use the measured whitening filter (elog   17584 ) to get the signal referred noise and calibrate.

The angle-to-length coupling is computed by taking the suppressed OpLev noise spectra of ITMX, ITMY, and BS and converting them to length noise by using the recently measured coupling coefficients in ELOG   17583 

Is the A2L coming from the optical lever feedback? If so, we can make a 30 Hz ELP to cut it off by 60 Hz.

Attached are updated plots of the T&R Measurements for a variety of mirrors, and diagrams for the setup used to make the measurements.

T is plotted for the 1064 nm measurement, since these mirrors are highly reflective at 1064, and either R or R&T are plotted for the 532 nm measurement, depending on how larger the R signal is.

As with the previous set of plots, the error bars here are purely statistical, and there are certainly other sources of error not accounted for in these plots.  In general, the T measurement was quite stable, and the additional errors
are probably not enormous, perhaps a few percent.

The mirrors are:

Y1-1037-00.50CC

Y1-2037-45S

Y1-2037-45P

Y1S-1025-0

Y1S-1025-45

The coil driver actuation strength for face coils was increased by 13 times in LO1, LO2, SR2, AS1, AS4, PR2, and PR3.

After the change the damping strenghth of POS, PIT, and YAW were reduced, but not SIDE coil output filter module requires higher digital input to cause same force at the output. This wouldn't be an issue until we try to correct for cross coupling at output matrix where we would want to give similar order of magnitude coefficients for SIDE coil as well. So I did the following changes to make input to all coil output filters (Face and side) same for these particular suspensions:

• C1:SUS-LO1_SUSSIDE_GAIN 40.0 -> 3.077
  C1:SUS-AS1_SUSSIDE_GAIN 85.0 -> 6.538
  C1:SUS-AS4_SUSSIDE_GAIN 41.0 -> 3.154
  C1:SUS-PR2_SUSSIDE_GAIN 150.0 -> 11.538
  C1:SUS-PR3_SUSSIDE_GAIN 100.0 -> 7.692
  C1:SUS-LO2_SUSSIDE_GAIN 50.0 -> 3.846
  C1:SUS-SR2_SUSSIDE_GAIN 140.0 -> 10.769

• C1:SUS-LO1_SDCOIL_GAIN -1.0 -> -13.0
  C1:SUS-AS1_SDCOIL_GAIN 1.0 -> 13.0
  C1:SUS-AS4_SDCOIL_GAIN -1.0 -> -13.0
  C1:SUS-PR2_SDCOIL_GAIN -1.0 -> -13.0
  C1:SUS-PR3_SDCOIL_GAIN -1.0 -> -13.0
  C1:SUS-LO2_SDCOIL_GAIN -1.0 -> -13.0
  C1:SUS-SR2_SDCOIL_GAIN -1.0 -> -13.0

In short, now 10 cts of input to C1:SUS-AS1_ULCOIL would create same actuation on UL as 10 cts of input to C1:SUS-AS1_SDCOIL will on SD.

In reply to

The medm screens have been updated further, with the hidden matrices added in bright colors.  An example screen shot is attached.

Megatron has been renamed c1ioo and moved to martian network.  Similarly, c1sus and c1iscex are also on the martian network.  Medm screens can be run on any of the control machines and they will work.

Currently the suspension controller is running on c1sus.

The frame builder is currently running on the fb machine *however* it is not working well.  Test points and daq channels on the new front ends tended to crash it when Alex started the mx_stream to the fb via our new DAQ network (192.168.114.XXX, accessible through the front ends or fb - has a dedicated 1 gigabit network with up to 10 gigabit for the fb).  So for the moment, we're running without front end data. Alex will be back tomorrow to work on it. 

Alex claimed to have left the frame builder in a state where it should be recording slow data, however, I can't seem to access recent trends (i.e. since we started it today).  The frame builder throws up an error "Couldn't open raw minute trend file '/frames/trend/minute_raw/C1:Vac-P1_pressure', for example.  Realtime seems to work for slow channels however.  Remember to connect to fb, not fb40m. So it seems the fb is still in a mostly non-functional state.

Alex also started a job to convert all the old trends to the correct new data format, which should finish by tomorrow.

RA: Nice screen work. The old screens had a 'slow' slider effect when ramping the bias so that we couldn't whack the optic too hard. Is the new one instantaneous?

 Looking at the sliders, I apparently still need to connect them properly.  There's a mismatch between the medm screen channel name and the model name.  At the moment there is no "slow" slider effect implemented, so they are effectively instantaneous.  Talking with Alex, he suggests writing a little c-code block and adding it to the model.  I can use the c code used in the filter module ramps as a starting point.

I examined the use of a single lens system for the available range of focal lengths, for the required magnification and found that a focal length of at most 100 mm would be required to sufficiently cover the object distance range. This would greatly compromise with the f-number and hence lead to a lot more spherical aberrations.

Therefore, a two lens system would be more useful to implement. Using an eyepiece of 1” puts an additional constraint on the system such that the separation between the lenses must now at least equal or be greater than half the image distance from the first lens to ensure that no light from the light cone is lost. This is clarified in the schematic. The image from the first lens in absence of the second lens would form at point A, subtending an angle θ. In order to ensure that no part this light cone emerging from the first lens is lost, the second lens must be placed at a distance atleast v/2 from the first lens.

A combination of 125mm focal length 2” diameter objective with a 250 mm 1” eyepiece covers the required range of object distances (650mm to 1500 mm). Increasing the focal length of the eye piece increases the minimum object distance accessible to 700 mm. 

A glance at the accessible u, v points shows that all magnifications are not possible at a given object distance. To image the entire surface of the test mass, a distance of at least 1.25m is required from the objective, while a beam spot of 1'' diameter can be imaged easily at upto 1200 mm from the objective . This holds true even for the 150-250 mm biconvex 2" lens combination proposed earlier. 

If this sounds reasonable, we could proceed with ordering the lenses.

I re-measured the transfer function for Cable B, because the residuals in my previous post for cable B indicated a bad fit. 

I also realized I had made a mistake in calculating the time delay, and calculated more reasonable time delays today. 

Cable A had a delay of 202.43 +- 0.01 ns.

Cable B had a delay of 202.44 +- 0.01 ns. 

{Radhika, Paco, Yehonathan}

For educational purposes we update the XARM noise budget and add the POX11 calibrated dark noise contribution (attachment).

Also reply to: 40m/17352

Tomohiro, Anchal, and I did the following to make updates to the calibration constants for pitch and yaw on MC1, MC2 and MC3.

To acquire the data used for fitting a curve respective to the change in counts per change in mirror pitch and yaw, we utilized some code that Anchal has already developed.

The scripts used to take time averaged data points of the IMC mirrors can be found by entering the command $ s into a terminal window to enter the scripts folder. Then enter the path "SUS/angActCal"

The following scripts will be found there to be used for this experiment:

angActCal.py & parabolaFit.py

To take data we used the angActCal.py function with set values for the time averaging = 5 s, settle time = 5 s, and adjusted the offset such that we would acquire approximately 20 data points given our ASC Bias limits. We defined the limits for each plot based on where the transmission fall off from the maximum value reached an average range of 10,000 counts.

The "readChannel" for each was the "C1:IOO-MC_TRANS_SUMFILT_OUTPUT" and can be found from the site map at IOO>Lock MC> see MC2_TRANS

The adjustment channels for Pitch and yaw on each IMC mirror were entered as the offset value found in the IMC screen at ALIGNMENT OFFSETS > BIASPIT/BIASYAW > OFFSET

For the code to work, the offset switch must be turned on. parabolaFit.py 

The data from MC1, MC2, and MC3 for pitch and yaw was saved to individual text files which were then entered into the parabolaFit.py function to get the results seen in attachment 1 and 2.

The above images show the printout from the plot fitting function and one of the graphs produced.

From the fitted curve values we then derived the equations that will soon be described further by Tomohiro (see entry _____) to arrive at the final callibration constants.

Final Calibration Constants for MC1, MC2, & MC3

We then utilized our calculated calibration constants (as seen bellow) to adjust the following filter parameters in the IMC control panel.

To make the updates such that the IMC screens show the correct urad values at the output of the filter banks, we must do the following steps to MC1, MC2, and MC3:

First, to make changes to our calibration filters, we must first shut off the pitch and yaw feedback loop controls.

TO do so for the Lock Filters, we will set the pitch and yaw SUS ASC inputs to 0 but entering the sitemap > IOO > C1IOO_WFS_MASTER

Nex head to action at the top right, and we can select "MC WFS relief 60s", this will relieve the values from the pitch and yaw inputs to the 40m Mode Cleaner Alignment settings to save the overall alignment and allow us to turn off the WFS servos to make the necessary adjustments on the lock filters.

Once we have waited a sufficient amount of time for the values on the ASC inputs to hover around 0, select Turn WFS ON/OFF button and choose "Turn OFF MCWFS Servo"

Next, we will press on the "on/off" button (see attachment 3 - circled in orange) for pitch and yaw found in just the LOCK FILTERS windows.

Once these are off we will stay in the same screen and adjust the gain values (boxed in yellow) for pitch and yaw.

Next, we will take the current value and divide it by the newly found corresponding calibration constant. This is to adjust for the changes we will be making on the output end of the filter banks such that all values in the feedback controls are normalized to the same scale.

The changes made here can be seen bellow:

Now that these changes have been made in the damp and lock filter banks, with the pitch and yaw feedback loops STILL OFF, we may adjust the newly made calibration filters for pitch and yaw (as seen in attachment 4).

The "P" and "Y" filters may be opened (boxed in red) and we may adjust the gain (circled in yellow). Because each of these filters have just been created, the value is set to 1. This value can be completely replaced with the calibration constant found in our table above. Thus we will now change MC1 Pitch to have a "gain" of 12.66 and so forth.

Once each of the calibration filters have been updated, you may go back into the damp filters and reinitiate the feedback loops.

Once all values have been entered,

This concludes the updating of the IMC filter calibration constants at DC.

Alex, Anchal, and I did the following to make updated angular actuation calibration for IMC mirrors. This is the revised version of Anchal's: 40m/16125.

In order to make the calibration formulas, we consider a matrix : connecting displacements and rotations of the IMC's beam waist to PIT and YAW rotations of every mirror

The parameters used in the above equation are listed in the next table.

	horizontal displacement of beam waist position
	vertical displacement of beam waist position
	PIT of the beam axis and/or each mirror
	YAW of the beam axis and/or each mirror
(subscript)	parameters for the beam
(subscript)	parameters for

 are the flat mirrors and  is the curved mirror in IMC. Components in  are refered from F. Kawazoe+ 2011 (doi: 10.1088/2040-8978/13/5/055504). In the paper, displacement and/or rotation of the beam parameters obtained from the PIT and YAW of each mirror are obtained not by  but by common or differential rotation of both two flat mirrors . Therefore, we divide  into two parts  (relation ):

• : relation between the beam parameters and the PIT and YAW rotation with 

• : relation between  and 

 is represented by revewing F. Kawazoe+ (2011):

Here we use  as RoC of ,  as height from the shorter side of the isoscele triangle, and  as half-long length of the shorter side. Intuitive discussion about the components are written in the last of the log.

Transmitted power is reduced by the small displacement and/or the small rotation of the beam axis, and can be represented by the Gaussian factor. It is described in /users/OLD/kakeru/oplev_calibration/oplev.pdf by Takahashi-san:

• parallel displacement

where  is the small displacement of the beam waist. It corresponds to .  is beam waist diameter inside IMC.

• beam axis rotation

where  is the small rotation of the beam axis. It corresponds to .  is divergence angle of the beam and is written by  and wavelength of laser 

Total power reduction is measured by multiplied gaussian factor of the displacement and the rotation. We can obtain the calibration formulas  with summed reduction Gaussian factor

where  is the vector of the PIT and YAW rotation .  are the calibration fomulas of PIT and YAW in 40m/16125 defined by Anchal, respectively, and have a unit of . Every calibration fomula is expressed as follows:

We intuitively describe how to obtain the components in . The detail is discussed in F. Kawazoe+ (2011).

• : 2-flat mirrors rotate with differential YAW 

When the 2-flat mirrors rotate, the shape of the isoscele triangle is thick, that is, the beam waist does not rotate but slightly displaces from its original one. Considering that the longer side of the triangle are almost perpendicular to the shorter side and ,  can be obtained by focusing on the right triangle shown in the following picture

• : 2-flat mirrors rotate with common YAW 

From , new triangle beam line is very similar to the isoscele triangle by rotating  from original one. So  is approximated to , but actually the new one is breaked its symmetry. The result becomes as follows

• : curved mirror rotates by 

It is similar to the case of . But the pivot to rotate the triangle is near than the case , so  has bigger factor than that of 

• : curved mirror rotates by 

It is completely the same as the discussion of linear cavity which has flat end mirror and curved input mirror.

• : 2-flat mirrors rotate with common PIT 

It is also the same as the linear one except that 2-flat mirrors are angled by 45 degrees. Angled 45 degrees reduce the effective rotation by factor of . The detail is discussed in A. Freise (2010).

• : 2-flat mirrors rotate with differential PIT ​

The differential rotation with the effect of  directly reflects to the PIT rotation of the beam

Updated Apps:

I created a new setup script for the newest build of the gds tools (DTT, foton, etc), located in /opt/apps (which is a soft link from /cvs/cds/apps) called gds-env.csh.

This script is now sourced by cshrc.40m for linux 64 bit machines.  In addition, the control room machines have a soft link in the /opt directory to the /cvs/cds/apps directory.

So now when you type dtt or foton, it will bring up the Centos compiled code Alex copied over from Hanford last month.

Wow. I typed DTT on rossa and it actually worked! No complaints about testpoints, etc. I was also able to use its new 'NDS2' function to get data off of the CIT cluster (L1:DARM_ERR from February). You have to use the kinit/kdestroy stuff to use NDS2 as usual (look up NDS2 in DASWG if you don't know what I mean).

To fix a problem one of the models was having, I checked the CVS version of the Bitwise.pm file into the SVN (located in /home/controls/cds/advLigoRTS/src/epics/util/lib), which adds left and right bit shifting funtionality.  The yec model now builds with the SVN checkout.

Also while trying to get things to work, I discovered the cdsRfmIO piece (used to read and write to the RFM card) now only accepts 8 bit offsets.  This means we're going to have to change virtually all of the RFM memory locations for the various channels, rather than using the values from its previous incarnation, since most were 4 bit numbers.  It also means it going to eat up roughly twice as much space, as far as I can tell.

Turns out the problem we were having getting to compile was nicely answered by Koji's elog post.  The shmem_daq value was not set to be equal to 1.  This caused it to look for myrimnet header files which did not exist, and caused compile time errors.  The model now compiles on megatron.

[Edit by KA: 4 bit and 8 bit would mean "bytes". I don't recall which e-log of mine Joe is referring.]

I've updated the c1auxey wiring plan for compatibility with the new suspension electronics. Specifically it is based on wiring schematics for the new HAM-A coil driver (D1100117), satellite amplifier (D1002818), and HV bias driver (D1900163).

Changes:

• The PDMon, VMon, CoilEnable, and BiasAdj channels all move from DB37 to various DB9 breakout boards.
• The DB9 cables (x2) connecting the CoilEnable channels to the coil drivers must be spliced with the dewhitening switching signals from the RTS.
• As suggested, I added five new BI channels to monitor the state of the CoilEnable switches. For lack of a better name, they follow the naming convention C1:SUS-ETMY_xx_ENABLEMon.

@Yehonathan can proceed with wiring the chassis.

Except for the feed-throughs that require a DB9-M connector I finished wiring and labeling the Acromag, following Jon's updated wiring plan.

We can start testing the differential inputs until the missing connectors arrive.

We took a Supermicro from the lab (along with a keyboard, a mouse, and a screen taken from a table on the Y arm) and placed it near the Acromag chassis.

We installed Debian 10 on the machine. I followed the steps on the slow machine wiki for setting up the host machine. Some steps had to be updated. Most importantly, in the new Debian, the network interfaces are given random names like enp3s0 and enp4s0 instead of eth0 and eth1. I updated the wiki accordingly.

To operate the chassis using one 15V source I disconnected the +24V cable from the Acromag units and jumpered the +15V wire into the power input instead. I started up the Acromags. They draw 0.7A. I connected an Ethernet cable to the front interface. I checked that all the Acromags are connected to the local network of the host machine by pinging them one by one.

I installed the EPICs base, asyn and modbus modules according to Jon's instructions.

Since the modbus configurations files were already writtten for c1auxey1 (see elog 15292) the only thing I did was to change the IP addresses in ETMYaux.cmd to match the actual assigned IPs.

I followed the rest of the instructions as written.

The modbus service was activated succesfully.

The only thing left to do is to change ETMYaux.db to reflect to new channels that were added. I believe these are BI channels named C1:SUS-ETMY_xx_ENABLEMon.

We received a stock of DB9 male feed-through connectors. That allowed me to complete the remaining wiring on the c1auxey Acromag chassis. The only thing left to be done is the splicing to the RTS.

We finished the installation procedure on the c1auxey1 host machine. There were some adjustments that had to be made for Debian 10. The slow machine wiki page has been updated.

A test database file was made were all the channel names were changed from C1 to C2 in order to not interfere with the existing channels.

We starting testing the channels one by one to check the wiring and the EPICs software. We found some misswirings and fixed them.

Its getting late. I'll continue with the rest of the channels on Monday.

Notice that for all the AI channels the RTN was disconnected while testing.

It seemed like the BIO channels were not working, both the inputs and the outputs. The inputs were working on the windows machine though. That is, when we shorted the BIO channel to the return, or put 0V on it, we could see the LED turn on on the I/O testing screen and when we ramped up the voltage above 3 the LED turned off. This is the expected behavior from a sinking digital input. However, the EPICs caget didn't show any change. All the channels were stuck on Disabled.

We checked the digital outputs by connecting the channels to a fluke. Initially, the fluke showed 13V. We tried to toggle the digital output channels with caput and that didn't work. We checked the outputs with the windows software. For that, we needed to stop the Modbus. To our surprise, the windows software was not able to flip the channels either. We realized that this BIO Acromag unit is probably defective. We replaced it with a different unit and put a warning sticker on the defective unit. Now, the digital outputs were working as expected. When we turned them on the voltage output dropped to 0V. We checked the channels with the EPICs software. We realized that these channels were locked with the closed loop definition. We turned on the channels tied to these output channels (watchdog and toggles) and it worked. The output channels can be flipped with the EPICs software. We checked all the digital output channels and fixed some wiring issues along the way.

The digital input channels were still not working. This is a software issue that we will have to deal with later.

(Yehonathan) Rana noticed that the BNC leads on the chassis front panel didn't have isolation on them so I redid them with shrinking tubes.

After sitting down for 5 minutes and thinking about it, I realized the names I had been using for internal RFM communication were pretty bad.  It was because looking at a model didn't let you know where the RFM connection was coming from or going to.  So to correct my previous mistakes, I'm instituting the following naming convention for reflected memory, PCIE reflected memory (dolphin) and shared memory names.  These don't actually get used anywhere but the models, and thus don't show up as channel names anywhere else.  They are replaced by raw hex memory locations in the actual code through the use of the IPC file (/opt/rtcds/caltech/c1/chans/ipc/C1.ipc).  However it will make understanding the models easier for anyone looking at them or modifying them.

The new naming convention for RFM and Dolphin channels is as follows.

SITE:Sending Model-Receiving Model_DESCRIPTION_HERE

The description should be unique to that data being transferred and reused if its the same data.  Thus if its transfered to another model, its easy to identify it as the same information.

The model should be the .mdl file name, not the subsystem its a part of.  So SCX is used instead of SUS.  This is to make it easier to track where data is going.

In the unlikely case of multiple models receiving, it should be of the form SITE:Sending Model-Receiving Model 1-Receiving Model 2_DESCRIPTION_HERE.  Seperate models by dashes and description by underscores.

Example:

C1:LSC-RFM_ETMX_LSC

This channel goes from the LSC model (on c1lsc) to the RFM model (on c1sus).  It transfers ETMX LSC position feedback.  The second LSC may seem redundant until we look at the next channel in the chain.

C1:RFM-SCX_ETMX_LSC

This channel goes from the RFM model to the SCX model (on c1iscex). It contains the same information as the first channel, i.e. ETMX LSC position feedback.

I have updated all the models that had RFM and SHMEM connections, as well as adding all the LSC communciation connections to c1rfm.  This includes c1sus, c1rfm, c1mcs, c1ioo, c1gcv, c1lsc, c1scx, c1scy.  I have not yet built all the models since I didn't finish the updates until this afternoon.  I will build and test the code tomorrow morning.

Updated the c1scx model to have two Lockin demodulators (C1:SUS-ETMX_LOCKIN1 and C1:SUS-ETMX_LOCKIN2).  There is a matrix C1:SUS-ETMX_INMUX which directs signals to the inputs of LOCKIN1 and LOCKIN2.  Currently only the GREEN_TRX signal is the only signal going in to this matrix, the other 3 are grounds.  The actual clocks themselves had to be at the top level (they don't work inside blocks) and thus named C1:SCX-ETMX_LOCKIN1_OSC and C1:SCX-ETMX_LOCKIN2_OSC.

There is a signal (IPC name is C1:GCV-SCX_GREEN_TRX) going from the c1gcv model to the c1scx model, which will contain the output from Jenne's green transmission PD which will eventually be placed. I've placed a filter bank on it in the c1gcv model as a monitor point, and it corresponds to C1:GCV-GREEN_TRX.

The suspension control screens were modified to have a screen for the Matrix feeding signals into the two lockin demodulators.  The green medm screen was also modified to have readbacks for the GREEN_TRX and GREEN_TRY channels.

So on the board, the top channel (labeled 1, corresponds to code ADC_0_0) is MCL.

Channel 2 (ADC_0_1) is assigned to frequency divided green signal.

Channel 3 (ADC_0_2) is assigned to the beat PD's DC output.

Channel 4 (ADC_0_3) is assigned to the green power transmission for the x-arm.

Channel 5 (ADC_0_4) is assigned to the green power transmission for the y-arm.

I started modifying the cshrc.40m file in /cvs/cds/caltech/ so that it starts pointing at the new directories.

# misc aliases
alias target 'cd /opt/rtcds/caltech/c1/target'
alias scripts 'cd /opt/rtcds/caltech/c1/scripts'
alias chans 'cd /opt/rtcds/caltech/c1/chans'
alias c 'cd /opt/rtcds/caltech/c1'
alias s 'cd /opt/rtcds/caltech/c1/scripts'
alias u 'cd /cvs/cds/caltech/users'

I also added "alias screens 'cd /opt/rtcds/caltech/c1/medm'" as a quick way to get to the medm directory.

Once we get multiple compiled versions (i.e. i386, x86_64, Solaris) of the new gds tools from Alex, we'll have to some more serious surgery on this file.

I removed the "New Computer Restart Procedures" and simply moved the changes into the "Computer Restart procedures", found here.  I've removed everything I don't think applies anymore (all the VME FE reboot procedures for example).

I updated the design requirements for the Stewart platform.  I weighed the unloaded "dirty" SOS that was sitting on the workbench in the control room; its mass is 11 kg.  Steve suggested that the OSEMs (not installed on this model) would add another 0.5 kg.  From the specs in the final SOS design document, LIGO-T970135, I added 0.25 kg for the optic itself; I am therefore taking the total payload mass to be 11.75 kg.  (Now, the upper stage of the Stewart platform itself will likely add a nontrivial amount, but I am not worrying about this yet.)

I have e-mailed Janeen Romie to obtain the actual center of mass and principal moments of inertia of the platform.  I also cooked up a simple scheme to measure both quantities, should this information not be available.  It would involve rigidly mounting the dirty SOS to a rigid bar hung from a pivot.  By translating the mount point in two dimensions and measuring the period of the pendulum, I ought to be able to find the center of mass and moments of inertia by multilinear regression.  However, this elaborate scheme is not necessary to just compute some ballpark figures; it could wait until a later stage in the design.  For the time being, I just rescaled the moment of inertia proportional to the increase in mass, such that the torque-to-force ratio is unchanged.

As such, the design requirements are now 

• linear travel: 40 microns peak to peak (based on SOS design requirements in LIGO-T950011)
• angular travel: 3 mrad peak to peak (based on SOS design requirements in LIGO-T950011)
• payload mass: 11.75 kg (measured unloaded mass, plus educated guesses about combined mass of OSEMs and optic)
• payload moment of inertia: 0.0232 kg m^2 (wild guess)
• bandwidth: 500 Hz (suggestion of Rana and Koji: ~kHz)

From these assumptions, the revised actuator requirements and dimensions are:

• peak actuator force: 2.04 kN
• minimum radius of top platform: 15 cm
• minimum radius of bottom platform: 30 cm
• minimum height: 26 cm

See the attached PDF document.

It appears that the actuator that I had originally nominated, PI's model P-225.80, would very nearly meet the actuator force requirement.  Steve also pointed out the following single-axis shakers that are already in use in the 40m:

• Brüel & Kjær type 4809
• Brüel & Kjær type 4810

I want to find out if either of these would meet the present need, but I'm waiting on a response from the manufacturer to get access to the data sheets.

(Updated as of 4pm)

 - ALS

End PDH UGF improvement / post mixer LPF investigation (with in 2 weeks)

- MC/FSS

Riju measured the MC REFL PD transimpedance. See ELOG and related.

- ASC

Why do we want to see less PRM motion? I thought PRC motion was causing
LSC issue of the central part. We wanted to maximize the PRM effect, don't we?
(Or is this to supress ETM motion during full lock?)

 End PDH - good point, thanks.

ASC - Yes, this is so that we can use the POP QPD to feed back to the common ETMs after the CARM offset is already quite small.  We will not use POP DC QPD for PRC any more. 

Also, for future PRC ASC, I keep coming back to this in my head, but maybe it is less painful to install oplevs for PR2, PR3 than it would be to make an RF QPD.  Neither is going to be trivially easy.  But if we had sensors of the tip tilt motions, we could feed all of that back to the PRM to stabilize the PRC.

Got the idea of ASC.

- Oplevs for PR2, PR3 => PR2 seems OK. PR3 almost impossible. well turned out not too crazy. We need outside electronics.

- RF QPD => not trivial and very technical but possible. All outside work.

- Better TT => might be a good solution.

 Because of the limited table space inside?  That's the main reason I can think of that this method is hard.  Am I missing something?

I modified the generate_master_screens.py script in /opt/rtcds/caltech/c1/medm/master/ to handle changing the MCL (and MC_L) listings to ALS for the two ETM suspension screens and associated sub-screens.

The relevant added code is:

custom_optic_channels = ['ETMX',
{'MCL':'ALS','MC_L':'ALS'},
'ETMY',
{'MCL':'ALS','MC_L':'ALS'}]

for index in range(len(custom_optic_channels)/2):
   if optic == custom_optic_channels[index*2]:
     for swap in custom_optic_channels[index*2+1]:
       sed_command = start_sed_string + swap + "/" + custom_optic_channels[index*2+1][swap] + middle_sed_string + optic + file
       os.system(sed_command)

When run, it generates the correctly named C1:SUS-ETMX_ALS channels, and replaces MCL and MC_L with ALS in the matrix screens.

After thinking about the interpretation of the various peaks seen in the scan through 2 FSRs, I have revised the information presented in the previous elog. Yutaro pointed out that the modulation frequency isn't exactly 11MHz, but according to this elog, is 11.066209 MHz. So instead of using mod(11e6,FSR), I really should have been using mod(11.066209,FSR) and mod(5*11.066209,FSR) to locate the positions of the 11MHz and 55MHz sidebands relative to the carrier resonances. With this correction, the 'unknown' peaks identified in Attachment #1 in elog 11743 are in fact the 55MHz sideband resonances. 

However, this means that the peaks which were previously identified as 55MHz sideband resonances have to be interpreted now - I'm having trouble identifying these. If we assume that the types of peaks present in the scan are 11 MHz sideband, 55MHz sideband, and the TEM00, TEM10, TEM20, TEM30, and TEM40 mode resonances, then the peaks marked in grey in Attachment #1 to this elog can be interpreted as TEM30 (right of a carrier resonance) and TEM40 (left of a carrier resonance) mode resonances - however, the fitted center frequencies differ from the expected center frequencies (determined using the same method as elog 469) by ~3% (for TEM30) and ~20% (for TEM40) - therefore I am skeptical about these peaks, particularly the 4th HOM resonances. In any case, they are the smallest of all the peaks, and any correction due to them will be small. 

The updated modulation depths are as follows (computed using the same method as described in elog 11743, the updated plot showing the ratio of bessel functions as a function of the modulation depth is Attachment #2 in this elog):

@11.066209 MHz ---- 0.179

@5*11.066209 MHz --- 0.226

These numbers are now reasonably consistent with those reported in elog10211.

As for the mode-matching efficiency, the overall number is almost unchanged if I assume the TEM30 peaks are accurately interpreted: 92.11%. But the dominant HOM contribution comes from the first HOM resonance: (TEM00 = 1, TEM20 = 0.0325, TEM10 = 0.0475, TEM30 =  0.0056). These numbers may change slightly if the 4th HOM resonances are also correctly identified.

ETMx is still not well behaved and the mode cleaner isnt too happy either, so I think we will save the measurement of the round trip arm loss for daytime tomorrow.  

I'm sorry. I misunderstood two things when writing elog 11741: the number of modulation frequencies, and how to distinguish modulation peaks and HOM peaks.

Now, I report about interpretation of the peaks marked in grey in Attachment #1 in elog 11745.

Summary:

The peaks marked in grey are interpreted as 3rd and 4th HOM resonance, if we assume that the radius of curvature of ETMY is slightly different from measured value. (measured: 57.6 m --> assumed: 59.3 m)

What I have done:

I plotted the differences in frequency between HOM peaks and 00 mode peaks (see Attachment #1) vs. expected orders of modes. The plot is shown in Attachement #2.

By fitting these data points, I calculated most likely value of gradient of this plot. This value corresponds: g_ITMYg_ETMY=0.3781. However, measured data of the radii of curvature suggests that g_ITMYg_ETMY=0.358. Assuming that this disagreement comes from the difference between measured and real values of ROC of ETMY (ITM is almost flat so that change of ROC of ITM doesn't have significant effect on g_ITMg_ETM), ROC of ETMY should be 59.3 m, different from measured value 57.6 m.

What I'd like to know:

-- Is such disagreement of ROC usual? Could it happen?

-- Are there any other possible explanations for this disagreement (or interpretations of the peaks marked in grey)?

What is the uncertainty of your RoC estimation?

One measurement of the ETMY ROC was 57.6m, but we trust another measured value of 60.26m than the other.
The value is always dependent on the spotposition on the mirror and how the ROC is calculated from the mirror phase map (e.g. spotsize, averaging method).
So I don't think this is a huge deviation from the spec.

FYI: I've also reported the similar mod depths of

11M: 0.194
55M: 0.234

in ELOG11036 with a different kind of measurement method.

The uncertainty came from the residual of linear fitting and based on my estimation,

ROC_ETMY = 59.3 +/- 0.1 m.

And I attach the updated figure of the fitting (with residual zoomed up).

Data points in the lower are (intentionally) slightly shifted horizontally to make it easy for us to see them.

It is hard, I think, to estimate the error of each data point, but I used 17 kHz for the errors of all data points; 17 kHz is the error of FSR estimation of this measurement, and since FSR is the distance between two carrier peaks we can consider that HOM distances, which are the distance between carrier peaks and HOM peaks, have similar order errors comared with that of FSR. 

I've updated the LSC and IFO models that Rana created with new shared memory locations.  I've used the C1:IFO- for the ifo.mdl file outputs, which in turn are read by the lsc.mdl file.  The LSC outputs being lsc control signals are using C1:LSC-.  Optics positions would presumably be coming from the associated suspension model, and am currently using SUP, SPX, and SPY for the suspension plant models (suspension vertex, suspension x end, suspension y end).

I've updated the web view of these models on nodus.  They can be viewed at: https://nodus.ligo.caltech.edu:30889/FE/

I've also created a C1.ipc file in /cvs/cds/caltech/chans/ipc  which assigns ipcNum to each of these new channels in shared memory.

Alex and I updated the open mx drivers from 1.3.3 to 1.3.901 (1.4 release candidate).  We downloaded the drivers from: http://open-mx.gforge.inria.fr/

We put them in /root/open-mx-1.3.901 on the fb machine (and thus get mounted by all the front ends.).  We did configure and make and make install.

We did a quick check with /opt/mx/bin/mx_info on the fb machine at this point and realized the MAC addresses and host names were all messed up, including two listings for c1iscex with different mac addresses (neither of which was c1iscex).

We then brought all the front ends mx_streams down, brought the fb down, then cleared all the peer names with mx_hostname.  We then brought the fb up, and the front end mx_stream processes.

/opt/mx/mx_info now shows a clean and correct set of hostnames and mac addresses.  Testpoints and trends are working.

{Paco, Yehonathan, Yuta}

Paco and Yuta locked PRMI carrier and I took the MICH OLTF measurement (attachment 1).

I downloaded 300secs of C1:LSC-MICH_IN1_DQ from when the PRMI was locked yesterday and calibrated it with the OLTF. I plot it together with the noise budget (attachment 2).

I included the output electronic noises into the PRMI carrier noise budget (attachment 1).

The coil driver noise was calculated using the Johnson noises of the coil driver resistor:

PRM 430 ohm

BS 100 ohm

ITMX/Y 400 ohm

For the dewhitening noises I use the measurements from yesterday. As expected fro yesterday's measurements, the ITMX dewhitening noise is dominating. For the coil driver gain I use the recently measured actuation calibration (elog   17522 ) to extract it. I find that these gain values:

PRM 1.009

BS 1.333

ITMX/Y 0.24

For the DAC noise I assume 1uV/sqrtHz and use the simDW filters from the coil outputs MEDM screens as the DW filters TFs.

Next:

1. Break down input noises.

2. Measure how much light is reaching REFL11 to correct the sensing matrix and get the right shot noise.

{Mayank, Yehonathan}

Yesterday, we measured AS55 and REFL11 dark noises at the IQ demod boards outputs (attachment 1) using SR560+SR785 setup.

We also measured the whitening board noise of REFL11 using an improvised adapter (picture will come later). The measurement result is shown in attachment 2. Didn't have time to measure the whitening noise for AS55

Also, after realizing the Finesse model doesn't account for the REFL port attenuation I measure how much DC power at the REFL11 PD to be 0.8mW by aligning PRM and misaligning the rest of the optics.

For some reason, the power before the attenuation is only ~ 360mW. The Finesse model predicts around 700mW. Where is the rest of the light going?

I added the PDs Dark noises (using the recently measured IQ demod gains) and shot noise to the PRMI carrier noise budget (attachment 3). ADC and whitening noises coming soon.

Measurements and PRMI noise budget notebooks were uploaded to the 40m git.

I updated parse_mdl_to_ipc.py to correctly work with the 3 new cdsIPCx parts, namely cdsIPCx_PCIE (for dolphin connections), cdsIPCx_RFM (for our traditional reflected memory connections), and cdsIPCx_SHMEM (local shared memory on the computer).  These parts replaced cdsIPCx awhile back (see here ).

The code now correctly counts each type independantly with regards to ipcNum (I.e. you can have ipcNum = 0 for RFM and ipcNum = 0 for SHMEM for example).

I also went in and modified a few sections of the feCodeGen.pl (in /opt/rtcds/caltech/c1/core/advLigoRTS/src/epics/util/) so as to properly assign names to matrix adl files, matrix of filter bank adl files, and filter bank adl files.

The updated script for remotely getting data from Agilent 4395A network analyzer is located at /users/nichin

This network analyzer device is located at crocetta.martian (192.168.113.108)

How to run the script:

> python NWAG4395A_modified.py [filename.yml]

1. The script accepts sweep parameters and output options via a .yml file that is written following a template that can be found at /users/nichin/NWAG4395template.yml
2. The data obtained is stored as a .dat file and the corresponding details regarding the acquired data is in a .par parameter file
3. You can choose to get a plot of the data obtained by specifying it in the .yml file. The plots are automatically stored as PDF.
4. Plots, data and parameter files are all stored in a new folder that is created with a timestamp in its name.
5. NOTE: Plotting options are only available in computers running numpy versions of 1.6.0 or above. The plotting sections of the code worked on Chiara, which has a 1.6.1 numpy, but did not work on Rossa which only had 1.3.0 numpy. Anyway, I have added an extra function that checks the version and skips the plotting part if needed.

Test Run:

I connected a simple 2MHz Low pass filter between the modulation output and signal input of the NA and ran a scan from 0Hz to 20MHz. The script was run from Chiara.

The expected plot was obtained and is attached here.

Further work:

I now have to work on setting up the RF switch in rack 1Y1 to select between required PDs and also on the code that chooses which channel is being selected.

There is also a problem of 2 8x1 RF switches being present, instead of one 16x1. Alex's code for RF switching does not take this into account.

RXA: I've deleted your plot because it didn't meet the minimal Bode plot standards. Please look up "Bode Plot" using Google/Wikipedia and try to follow some good example. Bode plot should contain Phase as well as magnitude. Also, the axes must be labeled with some physical units.

Sorry Rana for not giving much attention to the plot. I will definitely change the way they are being plotted.

I was more focused on getting the data acquisition to work. Also, the current script gets only the magnitude and not the phase... I still have to work on that.