40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 94 of 330  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  3661   Wed Oct 6 15:56:14 2010 josephbHowToCDSHow to load matrices quickly and easily

Awhile ago I wrote several scripts for reading in medm screen matrix settings and then writing them out.  It was meant as kind of a mini-burt just for matrices for switching between a couple of different setups quickly.

Yuta has expressed interest in having this instruction available.

In /cvs/cds/caltech/scripts/matrix/ there are 4 python scripts:

saveMatrix.py, oldSaveMatrix.py, loadMatrix.py, oldLoadMatrix.py

The saveMatrix.py and loadMatrix.py are for use with the current front end codes (which start counting from 1), where as the old*.py files are for the old system.

To use saveMatrix.py you need to specify the number of inputs, outputs, and the base name of the matrix (i.e. C1:LSP-DOF2PD_MTRX is the base of C1:LSP-DOF2PD_MTRX_0_0_GAIN for example), as well as an ouptut file where the values are stored.

So to save the BS in_matrix setting you could do (from /cvs/cds/caltech/scripts/matrix/)

./saveMatrix.py -i 4 -o 5 -n "C1:SUS-BS_TO_COIL_MTRX" -f -d ./to_coil_mtrx.txt

The -i 4 indicates 4 inputs, the -o 5 indicates 5 outputs, -n "blah blah" indicates the base channel name, -f indicates a matrix bank of filters (if its just a normal matrix with no filters, drop the -f flag), and -d ./to_coil_mtrx.txt indicates the destination file.

To write the matrix, you do virtually the same thing:

./loadMatrix.py -n "C1:SUS-PRM_TO_COIL_MTRX" -f -d ./to_coil_mtrx.txt

In this case, you're writing the saved values of the BS, to the PRM.  This method might be faster if you're trying to fill in a bunch of new matrices that are identical rather than typing 1's and -1's 20 times for each matrix.

I'll have Yuta add his how-to of this to the wiki.

  2938   Mon May 17 02:10:10 2010 KojiConfigurationIOOHow to lock / align the MC

Let me remind you how to lock and align the IMC

To lock

1. Open the doors for the IMC/OMC chambers. Open the manual shutter of the PSL just in front of the optical window

2. Run scripts/MC/mcloopson

3. Set the MC length path gain 0.3 / Set the MC total gain "+20"

4. If you want to avoid excitation of the mirrors by air turbulence, put a big plastic film and put three posters on the top and both the sides on the floor to block the wind go into the chamber.

To shut down

1. Run scripts/MC/mcloopsoff

2. Close the manual shutter, Remove the wind blockers, and the light door of the chambers

To align the MC

1. Tweak MC2 and MC3 to get maximum transmittion and/or minimum reflection.

  847   Mon Aug 18 15:32:18 2008 josephbConfigurationCamerasHow to multicast with gstreamer and Gige Cameras
In order to get multicasting to work, one simply needs to understand the address scheme.

In general, the address range 224.0.0.0 - 239.255.255.255 are reserved for multicasting. Within in this address space, there are some base level operations in the 224.0.0.x range which shouldn't be interfered with.

For a single site, the address range between 239.252.0.0 and 239.255.255.255 is probably best.

Gstreamer and the current 40m network hubs are designed to handle this kind of communication already, so one merely needs to point them at the correct addresses.

While in /cvs/cds/caltech/target/Prosilica/40mCode/SnapCode type:

CamServe -F 'Mono8' -c 44058 -E 20000 -X 0 -Y 0 -H 480 -W 752 -l 0 -m 300 | gst-launch-0.10 fdsrc fd=0 blocksize=360960 ! video/x-raw-gray, height=480, width=752, bpp=8,depth=8,framerate=60/1 ! ffmpegcolorspace ! queue ! smokeenc keyframe=8 qmax=40 ! udpsink host=239.255.1.1 port=5000

This will multicast to the 239.255.1.1 address, using port 5000.

On the machine you wish to subscribe type:

gst-launch udpsrc multicast-group=239.255.1.1 port=5000 ! smokedec ! ffmpegcolorspace ! ximagesink sync=false
  10515   Wed Sep 17 18:36:03 2014 KojiHowToGeneralHow to run DTT measurement automatically
  • Suppose you have a dtt template name test.xml
  • The file test.dtt

    open
    restore test.xml
    run -w
    save test2.xml
    quit
     
  • Run diag < test.dtt
  • The result is saved in test2.xml
  14865   Fri Sep 6 21:22:06 2019 KojiHowToCDSHow to save c1ioo

Q1 Can we run the machine with the reduced # of cores?

Q2 We might be able to order them quickly. What's the spec and configuration of the DIMMs (like DDR2-667MHz ECC 4GBx4, and even more specs (like Samsung 2GB DDR2 RAM PC2-6400 240-Pin DIMM M378T5663EH3) so that we are to identify the exact spec).

Q3 Can we scavenge the old OMC RT machine or even megatron to extract the memories?

  14866   Fri Sep 6 22:03:30 2019 aaronHowToCDSHow to save c1ioo

Saw these slightly delayed.

Q1: Not sure--is it a safe operation for me to remove the DIMM on CPU0, replace CPU0 (with no DIMM), and boot up to try this?

Q2: Specifically, it's this DIMM. The CPU core is compatible with DDR2, clock rate up to 333 MHz (DDR2-667) and 1, 2, or 4 GB of memory.

Q3: Hmm checking on that.
I see a message on megatron that it's currently running MC autolocker and the FSS slow servo, with nothing else listed. It's currently running 30-70% of its available memory on all 8 cores, so seems it's got some to spare. I need to relocate the old c1omc RT machine for myself, but becoming inefficient so I'm off.
 
Quote:

Q1 Can we run the machine with the reduced # of cores?

Q2 We might be able to order them quickly. What's the spec and configuration of the DIMMs (like DDR2-667MHz ECC 4GBx4, and even more specs (like Samsung 2GB DDR2 RAM PC2-6400 240-Pin DIMM M378T5663EH3) so that we are to identify the exact spec).

Q3 Can we scavenge the old OMC RT machine or even megatron to extract the memories?

  14867   Mon Sep 9 11:36:48 2019 aaronHowToCDSHow to save c1ioo

One pair of DIMM cards from the Sunstone box had the same Sun part number as those in c1ioo, so I swapped them in and reinstalled c1ioo's CPU0. c1ioo now boots up an seems ready to go, I'm able to log on from nodus. I also reinstalled optimus' CPU0, and optimus boots up with no problems.


  • old C1OMC RT
  • Megatron
    • I also found that megatron will require a CPU filler board if we remove one of its DIMM (it cannot operate with empty CPU module slots)
  • optimus
    • Rana says I can also consider using two of optimus' DIMM cards. Optimus appears to not be running any scripts currently, and I don't find any recent elog entries or wiki pages mentioning optimus with critical use.
    • I shutdown optimus (from the command line Mon Sep 9 13:17:58 2019).

While opening up optimus, I noticed a box labelled 'SUNSTONE' sitting below the rack--it contains two CPU modules a similar type as in c1ioo! I'm going to try swapping in the DIMM cards from this SUNSTONE box; I didn't find any elogs about sunstone--where are these modules from?

I reset c1lsc and c1sus, then ran rebootC1LSC.sh as before. All models started by the script are running with minimal red lights; c1oaf, c1cal, c1dnn, c1daf, and c1omc are not started by the script. I manually started these in the order c1cal->c1oaf->c1daf->c1dnn. Starting c1dnn crashed the other FE on c1ioo, so I reset all three FE again, and ran the script again (this time, including the startup for c1cal, c1oaf, and c1daf, but excluding c1dnn).

Except for c1dnn and c1omc, all models are started. The status lights are attached.

Attachment 1: reboot.png
reboot.png
  14900   Thu Sep 19 15:59:29 2019 aaronHowToCDSHow to save c1ioo

New DIMM cards have arrived. I stored them in the digital cabinet along y arm.

  11399   Thu Jul 9 16:39:03 2015 KojiConfigurationGeneralHow to set up your own summary page environment on the LDG cluster

Here is the summary of my investigation how to set up my own "summary page" environment on the LDG (LIGO Data Grid) cluster.

Here all albert.einstein must be replaced with your own LIGO.ORG user name.


1. Obtain LDAS cluster account

Run the following from any of the terminal and use your LIGO.ORG credential
ssh albert.einstein@ssh.ligo.org
You will be suggested to visit a particular web site. Fill the form on the web site and wait for the approval e-mails.

2. Use LDG SSH login portal

Once you received the approval of the account, you should be able to log in to the system. Type the following command again from your local terminal
ssh albert.einstein@ssh.ligo.org
You are asked to select the site and machines. Select 2- CIT and b. ldas-pcdev1, c. ldas-pcdev2, or d. ldas-pcdev3.

3. Setup bash environment

Setting up the python library path is very important for the proper processing.

Here is my setup for .bash_profile

# .bash_profile
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
    . ~/.bashrc
fi

if [ -f ~/.profile ]; then
        . ~/.profile
fi

# User specific environment and startup programs
PATH=$PATH:$HOME/bin
export PATH

# So that ssh will work, take care with X logins - see .xsession
[[ -z $SSH_AGENT_PID && -z $DISPLAY ]] &&
  exec -l ssh-agent $SHELL -c "bash --login"

and .bashrc

# .bashrc

# Source global definitions
if [ -f /etc/bashrc ]; then
    . /etc/bashrc
fi

# Set Python environment (based on gpwy-env script)

# clean path environment variable of duplicate entries
cleanpath() {
    if [[ -z "$1" ]]; then
       $1=PATH
    fi
    # map to local variable
    local badpath=$(eval echo \$$1)
    badpath=${badpath%%:}
    # remove duplicates
    badpath="$(echo "${badpath}" | awk -v RS=':' -v ORS=":" '!a[$1]++')"
    # remove trailing colon
    badpath=${badpath%%:}
    # reset variable and export
    eval $1=${badpath}
    eval export $1
}

# set PATH
cleanpath PATH
cleanpath PYTHONPATH

PATH=${HOME}/.local/bin:${PATH}
PYTHONPATH=${HOME}/.local/lib/python2.6/site-packages:${PYTHONPATH}

The order of cleanpath and PYTHONPATH= is important as we want to use the local library installation before anything kicks in.

4. Install required Python libraries

Run the following lines with this order so that they are installed in your "~/local"

# PIP installation
wget https://bootstrap.pypa.io/get-pip.py
python get-pip.py --user
# numpy, scipy, distribute, matplotlib, astropy, importlib installation
pip install numpy --upgrade --user
pip install scipy --upgrade --user
pip install distribute --upgrade --user
pip install matplotlib --user --upgrade
pip install astropy --upgrade --user
pip install importlib --user --upgrade

# We need to use dev branch of gwpy to run gwsumm propery
cp -r /home/detchar/opt/gwpysoft/lib/python2.6/site-packages/gwpy* ~/.local/lib/python2.6/site-packages/

# gwsumm installation
pip install --user git+https://github.com/gwpy/gwsumm

5. Setup summary pages for the 40m

Copy summary page setting from Max's directory.

cp -r ~max.isi/summary ~/

And make temporary directory for the summary pages.

mkdir /usr1/albert.einstein/summary

6. Modify typos in gw_summary_custon

Use your own editor to fix typos

emacs ~/summary/bin/gw_daily_summary_custom

replace max.isi to albert.einstein
change summary40m -> summary


Now the installation is done. From here, the description is for the routine procedure.

7. Run your summary page code

Run Kerberos authentication
kinit albert.einstein@LIGO.ORG

Run a summary page code for a specific date (e.g. for Jul 1st, 2015)
bash ${HOME}/summary/bin/gw_daily_summary_custom --day 20150701

The result can be checked under

https://ldas-jobs.ligo.caltech.edu/~albert.einstein/summary/
https://ldas-jobs.ligo.caltech.edu/~albert.einstein/summary/day/20150701/

Rerun a code for a specific page. This requires the page structure already exists.
The red texts should be modified depending on what ini file you want to run for what day.

/home/albert.einstein/.local/bin/gw_summary day --on-segdb-error warn --verbose  --output-dir . --multi-process 20 --no-html  --ifo C1 --archive C1EVE 20150630  --config-file /mnt/qfs2/albert.einstein/public_html/summary/etc/defaults.ini,/mnt/qfs2/albert.einstein/public_html/summary/etc/c1eve.ini

This command can actually be found in
https://ldas-jobs.ligo.caltech.edu/~albert.einstein/summary/gw_summary_pipe.sh

8. Some useful command

To check which python library is used
python -c 'import gwpy; print gwpy.__file__'

To list installed python libraries and versions
pip list

This should return the list like the following.

...
astropy (1.0.3)
...
gwpy (0.1b1.dev121)
gwsumm (0.0.0.dev854)
...
matplotlib (1.4.3)
...
numpy (1.9.2)
...
scipy (0.15.1)
...

 

 

  11405   Mon Jul 13 18:27:27 2015 EveConfigurationGeneralHow to set up your own summary page environment on the LDG cluster

I'd like to build off of Koji's instructions with a few useful tips I discovered while setting up my own summary page environment.

To only make a specified selection of tabs for the summary pages, copy only the corresponding .ini files into /home/albert.einstein/summary/config and run the gw_daily_summary_custom following Koji's instructions below. When asked for nodus's password either hit "enter" three times without providing the password or comment out this section of the code to stop the summary page creation process from taking current data files from nodus. This is especially helpful when the 40m is down (like it is now).

After running the summary page code, the pages can be viewed at https://ldas-jobs.ligo.caltech.edu/~albert.einstein/summary/day/YYYYMMDD/ and corresponding error logs can be found at ~/public_html/summary/logs/gw_summary_pipe_local-687496-0.err.

  3658   Wed Oct 6 11:03:51 2010 josephb, yutaHowToCDSHow to start diaggui for right now

I'm hoping to get a proper install this week done, but for now, this a stop gap.

To start diagnostic test tools, go to rosalba.  (Either sit at it, or ssh -X rosalba).

cd /opt/apps

type "bash", this starts a bash shell

source gds-env.bash

diaggui

 --------- Debugging section ------

If that throws up errors, try looking with "diag -i" and see if there's a line that starts with nds.  In the case last night, Alex had not setup a diagconf configuration file in the /etc/xinetd.d directory, which setups up the diagconf service under the xinit service.  To restart that service (if for example the nds line doesn't show up), go to /etc/init.d/ and type "sudo xinit start" (or restart).

Other problems can include awg and/or tpman not running for a particular model on the front end machine.  I.e. diag -i should show 3 results from 192.168.113.85 (c1x02, c1sus, c1mcs) at the moment , for both awg and tp.  If not, that means awg and tpman need to be restarted for those.

These can be started manually by going to the front end, to the /opt/rtcds/caltech/c1/target/gds/bin/ directory, and running awgtpman -s sysname (or in the case of IOP files [c1x02, c1x03, etc], awgtpman -s sysname -4.  Better is probably to run the start scripts which live /opt/rtcds/caltech/c1/scripts/ which kills and restarts all the process for you.

 

 

  2867   Sun May 2 17:16:43 2010 KojiUpdateSUSHow to steer the incident beam to the MC?

Deviations of the MC spot from the center of the mirrors were measured.

MC1H = +0.29 mm
MC1V = -0.43 mm
MC3H = +1.16 mm
MC3V = -0.68 mm

1) The vertical deviation looks easy being adjusted as they are mostly translation. They are ~0.5mm too high.
The distance from SM2 to MC is 1.8m. Thus what we have to do is
rotate SM2 Pitch in CW knob by 0.25mrad.
1 turn steers the beam in 10mrad. So 0.25mrad is 1/40 turn (9deg)

2) The horizontal deviation is more troublesome. The common component is easily being adjusted
but the differential component (i.e. axis rotation) involves large displacement of the beam
at the periscope sterring mirrors.

(MC3H - MC1H) / 0.2 m * 1.8 m = 8 mm

The beam must be moved in 8mm at the periscope. This is too big.

We need to move the in-vac steering mirror IM1. Move SM2Yaw in 7mrad. This moves the spot on IM1 by 5mm*Sqrt(2).
Then Move Im1 Yaw such that we see the resonance.

For the alignment adjustment, try to maximize the transmission by MC2 Yaw (cavity axis rotation) and SM2Y (beam axis translation)  

Actual move will be:

- Move IM1Y CCW (assuming 100TPI 1.5 turn in total...half turn at once)
- Compensate the misalignment by SM2Y CW as far as possible.
- Take alignment with MC2Y and SM2Y as far as possible

This operation will move the end spot something like 15mm. This should be compensated by the alignment of MC1Y at some point.

Attachment 1: steering.png
steering.png
  2868   Mon May 3 00:36:49 2010 KojiUpdateSUSHow to steer the incident beam to the MC?

Actually, I tried some tweaks of the input steering to get the beam being more centered on the MC mirrors on Saturday evening.

I made a mistake in the direction of the IM1Y tuning, and it made the horizontal spot position worse.

But, this also means that the opposite direction will certainly improve the horizontal beam angle.

Rotate IM1Y CCW!!!


The current setting is listed below

Alignment
MC1P 3.2531
MC1Y -0.5327
MC2P 3.3778
MC2Y -1.366
MC3P -0.5534
MC3Y -2.607


Spot positions
MC1H = +1.15 mm
MC1V = -0.13 mm
MC3H = +0.80 mm
MC3V = -0.20 mm

 

Quote:

Deviations of the MC spot from the center of the mirrors were measured.

MC1H = +0.29 mm
MC1V = -0.43 mm
MC3H = +1.16 mm
MC3V = -0.68 mm

 

  3336   Fri Jul 30 17:54:55 2010 steveHowToVACHow to stop and start slow pumpdown

Quote:

Bob and Steve closed BS chamber with the help of the manual Genie lift and the pump down started. The PSL shutter was closed and manual block was placed in the beam path. High voltage power supplies were checked to be off.

Pumping speed ~ 1 Torr/min was achieved at  1/8 of a turn opened roughing valve RV1

 We are at 370 Torr at 9 hrs of  pumping. RV1 is opened to ~ 3/8 turn orifice. We are using one roughing pump RP3  and butterfly valve is in place.

 

How to stop: 1, close RV1 by torque wheel  2, close V3 from MEDM screen  3, turn off RP3 roughing from MEDM screen  4, disconnect metal hose to oily pump

after butterfly valve. This KF-45 O-ring seal should be kept clean 5, place/close  45 mm cover blanks at the end of the hose and and on the 5" nipple.

 

How to start: 1, remove blanks from  hose and nipple 2, reconnect roughing pump hose to RV1 nipple  3, turn on PR3  4, open V3  5, open RV1 by wrench to ~3/8

6, fine tune RV1 opening to 1 Torr/min

 

ESSENTIAL: one operator has to be present when oilly roughing pump is connected to the vac. envelope

  3338   Fri Jul 30 22:07:42 2010 KojiHowToVACHow to stop and start slow pumpdown

Kiwamu and Koji

The rough pumping was stopped at 230mmTorr. We are going to resume the pumping tomorrow morning.

  • RV1 was closed with torque wheel.
  • V3 was closed from MEDM
  • RP3 wss stopped from MEDM
  • The quick coupling to RP3 was disconnected.

Quote:

    How to stop: 1, close RV1 by torque wheel  2, close V3 from MEDM screen  3, turn off RP3 roughing from MEDM screen  4, disconnect metal hose to oily pump

after butterfly valve. This KF-45 O-ring seal should be kept clean 5, place/close  45 mm cover blanks at the end of the hose and and on the 5" nipple. 

    How to start: 1, remove blanks from  hose and nipple 2, reconnect roughing pump hose to RV1 nipple  3, turn on PR3  4, open V3  5, open RV1 by wrench to ~3/8

6, fine tune RV1 opening to 1 Torr/min

ESSENTIAL: one operator has to be present when oilly roughing pump is connected to the vac. envelope

  16413   Tue Oct 19 11:30:39 2021 KojiUpdateVACHow to vent TP1

I learned that TP1 was vented through the RGA room in the past. This can be done by opening VM2 and a manual valve ("needle valve")
I checked the setup and realized that this will vent RGA. But it is OK as long as we turns of the RGA during vent and bake it once TP1 is back.

Additional note:

- It'd be nice to take a scan for the current background level before the work.
- Turn RGA EM and filament off, let it cool down overnight. 
- Vent with clean N2 or clean air. (Normal operating temp ~80C is to minimize accumulation of H-C contaminations.)
- There is a manual switch and indicators on the top of the RGA amp. It has auto protection to turn filament off if the pressure increase over ~1e-5.

Attachment 1: Screen_Shot_2021-10-18_at_14.52.34.png
Screen_Shot_2021-10-18_at_14.52.34.png
  16418   Wed Oct 20 15:58:27 2021 KojiUpdateVACHow to vent TP1

Probably the hard disk of c0rga is dead. I'll follow up in this elog later today.

Looking at the log in /opt/rtcds/caltech/c1/scripts/RGA/logs , it seemed that the last RGA scan was Sept 2, 2021, the day when we had the disk full issue of chiara.
I could not login to c0rga from control machines.
I was not aware of the presence for c0rga until today, but I could locate it in the X arm.
The machine was not responding and it was rebooted, but could not restart. It made some knocking sound. I am afraid that the HDD failed.

I think we can
- prepare a replacement linux machine for the python scripts
or
- integrate it with c1vac

  11138   Thu Mar 12 19:54:31 2015 Q UpdateLSCHow to: PRY

Q doesn't like elogging, but he sent me this nice detailed email, so I'm copying it into the log:

I’ve locked the power recycled Y arm numerous times today, to try and find a usable AO recipe for the full locking.

Really, the “only" things that I think are different are the DC gain and pole frequency of the REFL11 CARM signal. The pole frequency can be simulated in the CM board (through the 1.4k:80 zero/pole pair), and the DC gain can be changed by changing the REFL1 gain on the CM board. 
 
The crossover frequency only depends on the relative gains of the digital and AO path, which is independent of these two factors, since they’re common to both. So, if we scale the common part appropriately, the same AO crossover procedure should work. I think.
 
So, concretely, I set up the gain in the CM_SLOW input filter so that 1x CM_SLOW_OUT -> CARM in the input matrix matched the ~120Hz UGF that we get with a gain 6 or 7 in the CARM FM. The REFL1 gain on the CM board was 0dB. 
 
I then normalized the signal by 1/Trmax. (i.e. I had TRY of ~3.3, so I put 0.30 in the normalization matrix), so that at full resonance, the slope should bee the same as with no normalizing. 
 
Then, with the Yarm locked on ALS through 1xCARM_A, PRY locked on REFL165, and at zero arm offset (TRY~3.3), I did the following
 
  • Transition the digital loop from 1xCARM_A (ALS) to 1xCARM_B (1xCM_SLOW_OUT)
  • Turn on CM_SLOW FM1 (whitening)
  • With CM board gains: 0db REFL1, 0dB AO, negative polarity, MC In2 gain=-32dB, turn on In2 on MC servo
  • Slowly ramp up MC In2 gain to -10dB (this starts pulling up the phase bubble of the loop)
  • Turn on the 300:80 filter in the CM_SLOW input filter (this provides a f^-2 slope around the crossover region)
  • Go from [AO,REFL1]=[-10,0] to [-4,+6] by stepping them together. (This brings you to a UGF of a few hundred Hz with tons of phase margin)
  • At this point, up the REFL1 gain to +12 or so. Turn on the :300 FM in the CM_SLOW input filter (This rolls off the digital part of the loop, makes the violin filters stop interfering with the shape)
  • UGF is now ~1kHz. Boosts can be turned on once the gain is ramped up high enough. 
 
The moral of the story is: if you set the REFL1 gain such that a +1.0 element in the input matrix gives you about the right UGF, then the above recipe should work, just with the REFL1 gains offset by your starting gain. (I suppose if you need a minus sign in the input matrix, that just means that the AO polarity needs to change too)
 
Every time the REFL1 gain is changed, the electronic offset changes, so I had to keep an eye on POY as a DC out-of-loop sensor and adjust the CM board voltage offset. For the full IFO, I think REFL55 would work for this. However, I hope that, since less REFL1 gain will be needed for the PRFPMI, the changes will be smaller….
 
Lastly, I think it’s good to keep the digital UGF at around 120, because the crossover steals some gain below the UGF, and you want to have some gain margin there. Turning off boosts may help with this too; I did all of this with all the normal CARM boosts on. 
 
Hope this made some sense!
  6185   Wed Jan 11 14:06:28 2012 Leo SingerHowToComputer Scripts / ProgramsHowTo for getting data from NDS off site

 This may or may not be general knowledge already, but Jamie and I added a HowTo explaining how to retrieve channel data from the frame builder via NDS, but off site on one's own computer.  See the Wiki page:

https://wiki-40m.ligo.caltech.edu/How_To/NDS

  13606   Mon Feb 5 14:11:01 2018 gautamUpdateALSHuge harmonics in ALS channels

I've been trying to setup for the THD measuremetn at the LSC rack for a couple of days now, but am plagued by a problem summarized in Attachment #1: there are huge harmonics present in the channel when I hook up the input to the whitening board D990694 to the output of a spare DAC channel at the LSC rack. Attachment #2 summarizes my setup. I've done the following checks in trying to debug this problem, but am no closer to solving it:

  • The problem is reminiscent of the one I experienced with the SR785 not too long ago - there the culprit was a switching power supply used for the Prologix GPIB-ethernet box.
  • Then I remembered sometime ago rana and i had identified the power supply for the Fibox at the LSC rack as a potential pollutant. But today, I confirmed that this power supply is not to blame, as I unplugged it from its powerstrip and the spectrum didn't change.
  • There are a couple of Sorensens in this LSC rack, from what it looks like, they supply power to a BIO interface box in the LSC rack. I thought we would want to keep this rack free of switching power supplies? Wasn't that the motivation behind keeping the (linear) power supplies for all the LSC rack electronics in a little separate rack along the east arm?
  • I confirmed that when the D990694 input is terminated, these harmonics are no longer present. 
  • I plugged the output of the SOS dewhite board to an oscilloscope - there is a ~20mVpp signal there even when the DAC output is set to 0, but this level seems too small to explain the ~1000 ct-pp signal that I was seeing. The whitening gains for these channels are set to 0dB.
  • I also looked at the signal in the time domain using DTT - indeed the peak-to-peak signal is a few thousand counts.
  • This isn't a problem with the particular input channel either - the behaviour can be reproduced with any of the 4 ALS input channels.

Am I missing something obvious here? I think it is impossible to do a THD measurement with the spectrum in this condition...

Attachment 1: ALSpowerlineHarmonics.pdf
ALSpowerlineHarmonics.pdf
Attachment 2: 2A1B3AC4-4059-416A-AD88-8AB0431D7A55.jpeg
2A1B3AC4-4059-416A-AD88-8AB0431D7A55.jpeg
  13608   Mon Feb 5 22:57:28 2018 gautamUpdateALSHuge harmonics in ALS channels

Did some quick additional checks to figure out what's going on here.

  1. The SOS/dewhite board for which I didn't have a DCC number is D000316. It has a single ended output.
  2. I confirmed that the origin of this noise has to do with the ground of the aforementioned D000316 - as mentioned in my previous elog, having one end of a BNC cable plugged into the whitening board D990694 and the other end terminated in 50ohms yields a clean spectrum. But making the ground of this terminator touch the ground of the SMA connector on the D000316 makes the harmonics show up.
  3. Confirmed that the problem exists when using either the SMA or the LEMO monitor output of these D000316 boards.

So either something is busted on this board (power regulating capacitor perhaps?), or we have some kind of ground loop between electronics in the same chassis (despite the D990694 being differential input receiving). Seems like further investigation is needed. Note that the D000316 just two boards over in the same Eurocrate chassis is responsible for driving our input steering mirror Tip-Tilt suspensions. I wonder if that board too is suffering from a similarly noisy ground?

Quote:
 

Am I missing something obvious here? I think it is impossible to do a THD measurement with the spectrum in this condition...

 

  7989   Sun Feb 3 13:20:02 2013 KojiSummaryGeneralHypothesis

Rana mentioned the possibility that the PR2 curvature makes the impact on the mode stability. Entry 7988
Here is the extended discussion.


Hypothesis:

The small but non-negligible curvatures of the TT mirrors made the recycling cavity unstable or nearly unstable.


Conclusion:

If the RoC of the TT mirrors are -600 m (convex), the cavity would be barely stable.
If the RoC of the TT mirrors are less than -550m, the horizontal modes start to be unstable.
Assumption that all of the TT mirrors are concave should be confirmed.


Fact (I): Cavity stability

- The folded PRMI showed the mode stability issue. (L=6.78m from Jenne's entry 7973)
- The folded PRM-PR2-PR3-flat mirror cavity also showed the similar mode issue. (L=4.34m)
- The unfolded PRM-PR2 cavity demonstrated stable cavity modes. (L=1.91m)

Fact (II): Incident angle

- PRM 0deg
- PR2 1.5deg
- PR3 41deg

Fact (III): Mirror curvature

- RoC of PRM (PRMU02): +122.1m (measured, concave), or +115.6m (measured by the vendor)
- RoC of G&H mirrors: -600m ~ -700m (measured, I suppose the negative number means convex) (Jenne's entry 7851)
  [Note that there is no measurement of the phase map for the PR2 mirror itself.]
- RoC of LaserOptik mirrors: -625m ~ -750m (measured, I suppose that the measurement shows the mirrors are convex.) (Jan's entry 7627 and 7638)

Let's assume that the TT mirrors are always convex and have a single number for the curvature radius, say RTT


Cavity mode calculation with Zach's arbcav

1) The unfolded PRM-PR2 cavity:

The cavity becomes unstable when 0 > RTT > -122m  (This is obvious from the g-factor calculation)
==> The measured RoC of the TT mirrors predicts the cavity is stable. (g=0.98, Transverse Mode Spacing 3.54MHz)

2) The folded PRM-PR2-PR3-flat mirror cavity:

The cavity becomes unstable when RTT < -550 m
==> The measured RoC of the TT mirrors (RTT ~ -600m) predicts the cavity is barely stable (g=0.997, TMS ~600kHz).

- The instability occurs much faster than the unfolded case.
- The horizontal mode hits unstable condition faster than the vertical mode.
- The astigmatism mainly comes from PR3.

3) The folded PRMI:

The cavity becomes unstable when RTT < -550 m
==> The measured RoC of the TT mirrors (RTT ~ -600m) predicts the cavity is barely stable. (g=0.995, TMS ~500kHz)

- The instability occurs with almost same condition as the case 2)

The calculation result for the PRMI with RTT of -600 m. The code was also attached.


Q&A:

Q. What is the difference between unfolded and folded?
A. For the unfolded case, the PR2 reflect the beam only once in a round-trip.
For the folded case, each TT mirror reflects the beam twice. Therefore the lens power by the mirror is doubled.

Q. Why the astigmatism mainly comes from PR3?
A. As the angle of incidence is much bigger than the others (41deg).

Q. Why the horizontal mode is more unstable than the vertical mode?
A. Off-axis reflection of a spherical mirror induces astigmatism. The effective curvature of the mirror in
the horizontal direction
is R / Cos(theta) (i.e. longer), while it is R Cos(theta) (i.e. shorter). Indeed, the vertical and horizontal ROCs are factor of 2 different
for the 45deg incidence.

Q. Why the stability criteria for the case 2) and 3) similar?
A. Probably, once the effective curvature of the PRM-PR2-PR3 becomes
negative when RTT < -550 m.

Q. You said the case 2 and 3 are barely stable. If the TMS is enough distant form the carrier, do we expect no problem?
A. Not really. As the cavity get close to the instability, the mode starts to be inflated and get highly astigmatic.
For the case 2), the waist radii are 5.0mm and 3.7mm for the horzontal and vertical, respectively.
For the case 3), they are 5.6mm and 4.1mm for the horzontal and vertical, respectively.
(Note: Nominally the waist radius is 3.1mm)

Q. What do you predict for the stability of the PRM-PR2-Flat_Mirror cavity?
A. It will be stable. The cavity is stable until
RTT becomes smaller than -240 m.

Q. If the TT mirrors are concave, will the cavity stable?
A. Yes. Particularly if PR3 is concave.

Q. Rana mentioned the possibility that the mirrors are deformed by too tight mounting of the mirror in a ring.
Does it impact the stability of the cavity?

A. Possible. If the curvature is marginal and the mounting emphasizes the curvature, it may meet the unstable condition.

Q. How can we avoid this instability issue?
A.
1. Use flatter mirrors or at least concave mirrors.

2. Smaller incident angle to avoid emphasis of the RoC in the horizontal direction
3. Use weaker squishing force for mounting of the mirrors
4. Flip the PR3 mirror in the mounting ring by accepting the compromise that the AR surface is in the cavity.

Attachment 1: mode_density_PRC.pdf
mode_density_PRC.pdf mode_density_PRC.pdf
Attachment 2: mode_density_PRC.zip
  7992   Mon Feb 4 15:06:56 2013 KojiSummaryGeneralHypothesis

Quote:

Q. How can we avoid this instability issue?
A.
1. Use flatter mirrors or at least concave mirrors.

2. Smaller incident angle to avoid emphasis of the RoC in the horizontal direction
3. Use weaker squishing force for mounting of the mirrors
4. Flip the PR3 mirror in the mounting ring by accepting the compromise that the AR surface is in the cavity.

 Another possibility is to use a ring heater to correct the curvature. I talked a bit with Aidan about this.

  6479   Tue Apr 3 12:42:19 2012 Mike J.UpdateComputersHysteresis Model

Here's my first hysteresis model in Simulink. It's based on the equation y=Amplitude*sin(frequency*t+phase)+(hysteresis/frequency2) as a solution to y''+frequency2*y+hysteresis=0. All values in the model are variables that should be manipulated through the model workspace or external code.

Attachment 1: hysteresis1.mdl
Model {
  Name			  "hysteresis1"
  Version		  7.6
  MdlSubVersion		  0
  GraphicalInterface {
    NumRootInports	    0
    NumRootOutports	    0
    ParameterArgumentNames  ""
    ComputedModelVersion    "1.9"
    NumModelReferences	    0
... 734 more lines ...
  6487   Thu Apr 5 01:07:08 2012 Mike J.UpdateComputersHysteresis Plots

Here are the hysteresis plots from the most recent model, which uses a modified harmonic oscillator equation y''=-(Frequency)2*y-Hysteresis.  The hysteresis constant seems to change both the amplitude and equilibrium point of the pendulums, which is akin to changing the length of a pendulum without changing the frequency. This does not make sense. Perhaps the hysteresis value should be moved to the "spring" constant for the pendula and not restricted to a position-biasing value.

SHO_hyst_plot.png

  1314   Mon Feb 16 22:58:51 2009 rana, yoichiConfigurationSUSHysteresis in SUS from Misalignments
WE wondered if there was some hysteresis in the SUS alignments. When we leave the optics misaligned for a
long time it seems to take awhile for the optic to settle down. Possibly, this is the slow deformation of
the wires or the clamps.

The attached PNG shows the plot of the bias sliders for a few days. You can see that we misalign some of the
optics much more than the others. This must be stopped.

Kakeru is going to use his nearly complete optical lever calibrations to quatify this by stepping the optics
around and measuring the effect in the optical lever. Of course, the misalignment steps will be too large to
catch on the OL, but he can calibrate the align-sliders into radians to handle this.
Attachment 1: a.png
a.png
  6142   Wed Dec 21 14:23:08 2011 ranaConfigurationSUSHysteresis in suspensions?

While discussing the suspension hysteresis measurements, Koji, Kiwamu, and I realized that the suspension wire standoff is aluminum, whereas the standoff for the LIGO LOS are using quartz.

Using a soft aluminum standoff is bad. The movement of the suspension will slowly wear the groove and produce opportunities for mechanical upconversion and hysteresis.

In fact, the wire standoff as well as the clamping block on the top should be made of sapphire or ruby to prevent any such wearing issues. Steve is hot on the case.

 

  6128   Sat Dec 17 01:56:16 2011 KojiSummarySUSHysteresis test

[Koji Kiwamu]

We wonder if the flakiness of MC2 comes from the suspension or not.

To test it, we are shaking all of the suspension biases +/-1.0 with a script.

The script is here:
/users/koji/111216/SUS_hysteresis.sh

For this test, we closed the mechanical shutter before the MC.

Also some amount of misalignment is anticipated.
Don't be surprised if you see nothing is working when you come to the lab in the weekend.

 

 -- EDIT by KI:
I found the ITMY watchdogs tripped around 2:40 AM and then re-engaged it.
  72   Tue Nov 6 18:18:15 2007 tobinConfigurationComputersI broke (and fixed) conlogger
It turns out that not only restart_conlogger, but also conlogger itself checks to see that it is running on the right machine. I had changed the restart_conlogger script to run on op340, but it would actually silently fail (because we cleverly redirect conlogger's output to /dev/null). Anyway, it's fixed now: I edited the conlogger source code where the hostname is hardcoded (blech!) and recompiled.

On another note, Andrey fixed the "su" command on op440m. It turns out that the GNU version, in /usr/local/bin, doesn't work, and was masking the (working) sun version in /bin. Andrey renamed the offending version as "su.backup".
  4525   Thu Apr 14 17:45:59 2011 BryanConfigurationGreen LockingI leave you with these messages...

OK… the Y-arm may be locked with green light, which was the goal, and this is all good but it's not yet awesome. Awesome would be locked and aligned properly and quiet and optimised. So...  in order to assist in increasing the awesome-osity, here are a few stream-of-consciousness thoughts and stuff I've noticed and haven't had time to fix/investigate or have otherwise had pointed out to me that may help...

 

Firstly, the beam is not aligned down the centre of the cavity. It's pretty good horizontally, but vertically it's too low by about 3/4->1cm on ETMY. The mirrors steering the beam into the cavity have no more vertical range left, so in order to get the beam higher the final two mirrors will have to be adjusted on the bench. Adding another mirror to create a square will give more range AND there will be less light lost due to off 45degree incident angles. When I tried this before I couldn't get the beam to return through the Faraday, but now the cavity is properly aligned this should not be a problem.

 

A side note on alignment - while setting cameras and viewports and things up, Steve noticed that one of the cables to one of the coils (UL) passes behind the ETMY. One of the biggest problems in getting the beam into the system to begin with was missing this cable. It doesn't fall directly into the beam path if the beam is well aligned to the cavity, but for initial alignment it obscures the beam - this may be a problem later for IR alignment.

 

Next, the final lambda/2 waveplate is not yet in the beam. This will only become a problem when it comes to beating the beams together at the vertex, but it WILL be a problem. Remember to put it in before trying to extract signals for full LSC cavity locking.

 

Speaking of components and suchlike things, the equipment for the green work was originally stored in 3 plastic boxes which were stored near the end of the X-arm. These boxes, minus the components now used to set up the Y-end, are now similarly stored near the end of the Y-arm.

 

Mechanical shutter - one needs to be installed on the Y-end just like the X-end. Wasn't necessary for initial locking, but necessary for remote control of the green light on/off.

 

Other control… the Universal PDH box isn't hooked up to the computers. Connections and such should be identical to the X-arm set-up, but someone who knows what they're doing should hook things up appropriately.

 

More control - haven't had a chance to optimise the locking and stability so the locking loop, while it appears to be fairly robust, isn't as quiet as we would like. There appears to be more AM coupling than we initially thought based on the Lightwave AM/PM measurements from before. It took a bit of fiddling with the modulation frequency to find a quiet point where the apparent AM effects don't prevent locking. 279kHz is the best point I've found so far. There is still a DC offset component in the feedback that prevents the gain being turned up - unity gain appears limited to about 1kHz maximum. Not sure whether this is due to an offset in the demod signal or from something in the electronics and haven't had time left to check it out properly yet. Again, be aware this may come back to bite you later.

 

Follow the bouncing spot - the Y-arm suspensions haven't been optimised for damping. I did a little bit of fiddling, but it definitely needs more work. I've roughly aligned the ETMY oplev since that seems to be the mass that's bouncing about most but a bit of work might not go amiss before trusting it to damp anything.

 

Think that's about all that springs to mind for now…

 

Thanks to everyone at the 40m lab for helping at various times and answering daft questions, like "Where do you keep your screwdrivers?" or "If I were a spectrum analyser, where would I be?" - it's been most enjoyable!

 
  4532   Fri Apr 15 13:43:23 2011 BryanConfigurationGreen LockingI leave you with these messages...

Y-end PDH electronics.

The transfer function of the Y-end universal PDH box:

Y_End_Electronics_TF.png

 

  1707   Sat Jun 27 02:48:09 2009 ClaraUpdatePEMI moved accelerometers and made some pretty pictures

I have been working on finding the best spots to put the accelerometer sets in order to best subtract out noise (seismometers next!). Here is a plot of what I've done so far:

80min_accel_0123.png

All of these were 80-minute samples. The dashed line is unfiltered, solid line filtered. So, Setup #1 looks the best so far, but I didn't leave it there very long, so perhaps it was just a really awesome 80 minutes. I've put the accelerometers back in the Setup #1 position to make sure that it is really better.

And, in case you can't intuitively figure out what configuration the accelerometers are in by such descriptive names, here are some helpful pictures. I didn't know about the digital cameras at first, so these are actually sketches from my notebook, which I helpfully labeled with the setup numbers, color-coded to match the graph above! Also, there are some real-life photographs of the current arrangement (Setup #1' if you forgot).

MC1_accel_sketch_side.png

MC1_accel_sketch_top.png

MC2_accel_sketch.png

Doesn't this one look kind of Quentin Blake-esque? (He illustrated for Roald Dahl.)

MC1acc_S01.JPG

This is the MC1 set.

MC2acc_S123.JPG

Guess which one this is!

  4998   Wed Jul 20 11:13:59 2011 Larisa ThorneUpdateelogI restarted the ELOG as it seemed to have crashed

 

  4872   Thu Jun 23 22:59:45 2011 kiwamuUpdateABSLI-P curve of LWE

 The I-P curve was measured again, but this time in a lower current range of 1.0-1.9 [A].

The plot below is the latest I-P curve.

IP_curve_small.png

(Decision)

Based on the measurement and some thoughts, I decided to run this laser at about 1.8 [A] which gives us a middle power of ~ 360 [mW].

In the 40m history, the laser had been driven at 2.4 [A] in years of approximately 2006-2009, so it's possible to run it at such a high power,

but on the other hand Steve suggested to run it with a smaller power such that the laser power doesn't degrade so fast.


(notes)

  The laser controller handed from PK (#4855) was used in this measurement.

The nominal current was tuned to be 1.8 [A] by tuning a potentiometer on the laser head (see page.18 on the manual of LWE).

There was a huge bump around 1.4 [A] and sudden power drop at 1.48 [A] although I don't know the reason.

Quote from #4842

The old days the NPRO ( inside the MOPA ) was running ~1.7A  500 mW

  4877   Fri Jun 24 07:49:23 2011 steveUpdateABSLI-P curve of LWE with serial numbers

Quote:

 The I-P curve was measured again, but this time in a lower current range of 1.0-1.9 [A].

Quote from #4842

The old days the NPRO ( inside the MOPA ) was running ~1.7A  500 mW

 Lightwave Laser Head M126-1064-700   sn238,  mounted on full size Al base and side heat sink on

Controller 125/126 Smart Supply   sn 201M

  4840   Mon Jun 20 11:38:49 2011 kiwamuUpdateABSLI-P curve of LightWave M126-1064-700

The I-P curve of the LightWave NPRO (M126-1064-700), which was taken out from the MOPA box, was measured. It looks healthy.

The output power can go up to about 1 W, but I guess we don't want it to run at a high power to avoid any further degradation since the laser is old.

 

IP_curve.png

 X-axis is the current read from the display of the controller. Y-axis is the output power, directly measured by Coherent PM10.

The measurement was done by changing the current from the controller.

Quote from #4832

 [Things to be done]

   - measure the beam profiles and power

   - get a laser controller, which will be dedicated for this laser, from Peter King

  4841   Mon Jun 20 13:48:25 2011 KojiUpdateABSLI-P curve of LightWave M126-1064-700

Hmm. Was the current within the operating range? (i.e. Is it a 700mW laser or a 1W one?)

You can obtain the nominal operating current from the old EPICS values (or some elog entries).

Note that NPROs are designed to be healthy only at around the nominal pumping power
(i.e. thermal gradient, and thermal lensing of the crystal, etc.)

ALSO:

Be aware that this laser should be used under the old SOP. So the appropriate interlocking is mandatory.

And probably we need to modify the SOP such that it reflects the latest situation.

Quote:

The I-P curve of the LightWave NPRO, which was taken out from the MOPA box, was measured. It looks healthy.

The output power can go up to about 1 W, but I guess we don't want it to run at a high power to avoid any further degradation since the laser is old.

  4842   Mon Jun 20 16:44:02 2011 steveUpdateABSLI-P curve of LightWave M126-1064-700

 

 Put the serial numbers into the elog. So we can identify the laser and controller in the future.

The old days the NPRO ( inside the MOPA ) was running ~1.7A  500 mW

  1685   Thu Jun 18 23:20:40 2009 robSummaryLSCI-Q ratio with RF detected DARM

This is a ratio of PD1_I to PD1_Q (so a ratio of the two quadratures of AS166), measured in an anti-spring state.  It's not flat because our set up has single sideband RF heterodyne detection, and using a single RF sideband as a local oscillator allows one to detect different quadratures by using different RF demodulation phases.   So the variation in frequency is actually a measure of how the frequency response of DARM changes when you vary the detection quadrature.  This measure is imperfect because it doesn't account for the effect of the DARM loop.

Even though you can choose your detection quadrature with this setup, you can't get squeezed quantum noise with a single RF sideband.  The quantum noise around the other (zero-amplitude) RF sideband still gets mixed in, and negates any squeezing benefits.

Attachment 1: IQratio.jpg
IQratio.jpg
  6809   Tue Jun 12 23:18:18 2012 yutaUpdateGreen LockingI-Q signals for the beat

[Mengyao, Yuta]

Yes!! We have I-Q signals for the beat!!

What we did:
  1. Aligned Y arm to the Y end green incident beam. The transmission to the PSL was about 195 uW.

  2. Aligned IR beam to the Y arm by adjusting PZTs and got the transmission, C1:LSC-TRY_OUT ~ 0.86.

  3. Aligned green optics on the PSL table to get the beat signal. The beat was found when;

  PSL laser temperature on display: 31.41 deg C
  C1:PSL-FSS_SLOWDC = 1.43
  Y end laser "T+": 34.049 deg C
  Y end laser "ADJ": 0
  Y end laser measured temperature: 34.14 deg C
  C1:GCY-SLOW_SERVO2_OFFSET = 29950
  Y end slow servo: off (was on)

  4. Connected the beat PD output to the beatbox.

  5. Kicked ETMY position to change the cavity length and while the ringdown, we run pynds to get data. We plotted C1:ALS-BEATY_FINE_I_ERR vs C1:ALS-BEATY_FINE_Q_ERR, and C1:ALS-BEATY_COARSE_I_ERR vs C1:ALS-BEATY_COARSE_Q_ERR (below). We got nice circle as expected.

FINEIQplot20120612.pngCOARSEIQplot20120612.png

Current setup:
  Only AA filers are put between the output of the beatbox and the ADC.

beatysetup20120612.png

  16012   Sat Apr 10 08:51:32 2021 JonUpdateCDSI/O Chassis Assembly

I installed three of the 16-bit ADC adapter boards assembled by Koji. Now, the only missing hardware is the 18-bit DACs (quantities below). As I mentioned this week, there are 2-3 16-bit DACs available in the FE cabinet. They could be used if more 16-bit adapter boards could be procured.

C1BHD    
Component Qty Required Qty Installed
16-bit ADC 1 1
16-bit ADC adapter 1 1
18-bit DAC 1 0
18-bit DAC adapter 1 1
16-ch DIO 1 1
C1SUS2    
Component Qty required Qty Installed
16-bit ADC 2 2
16-bit ADC adapter 2 2
16-bit DAC 1 1
16-bit DAC adapter 1 1
18-bit DAC 5 0
18-bit DAC adapter 5 5
32-ch DO 6 6
16-ch DIO 1 1
  16093   Thu Apr 29 10:51:35 2021 JonUpdateCDSI/O Chassis Assembly

Summary

Yesterday I unpacked and installed the three 18-bit DAC cards received from Hanford. I then repeated the low-level PCIe testing outlined in T1900700, which is expanded upon below. I did not make it to DAC-ADC loopback testing because these tests in fact revealed a problem with the new hardware. After a combinatorial investigation that involved swapping cards around between known-to-be-working PCIe slots, I determined that one of the three 18-bit DAC cards is bad. Although its "voltage present" LED illuminates, the card is not detected by the host in either I/O chassis.

I installed one of the two working DACs in the c1bhd chassis. This now 100% completes this system. I installed the other DAC in the c1sus2 chassis, which still requires four more 18-bit DACs. Lastly, I reran the PCIe tests for the final configurations of both chassis.

PCIe Card Detection Tests

For future reference, below is the set of command line tests to verify proper detection and initialization of ADC/DAC/BIO cards in I/O chassis. This summarizes the procedure described in T1900700 and also adds the tests for 18-bit DAC and 32-channel BO cards, which are not included in the original document.

Each command should be executed on the host machine with the I/O chassis powered on:

$ sudo lspci -v | grep -B 1 xxxx

where xxxx is a four-digit device code given in the following table.

Device Device Code
General Standards 16-bit ADC 3101
General Standards 16-bit DAC 3120
General Standards 18-bit DAC 3357
Contec 16-channel BIO 8632
Contec 32-channel BO 86e2
Dolphin IPC host adapter 0101

The command will return a two-line entry for each PCIe device of the specified type that is detected. For example, on a system with a single ADC this command should return:

10:04.0 Bridge: PLX Technology, Inc. PCI9056 32-bit 66MHz PCI IOBus Bridge (rev ac)
             Subsystem: PLX Technology, Inc. Device 3101
  16116   Tue May 4 07:38:36 2021 JonUpdateCDSI/O Chassis Assembly

IOP models created

With all the PCIe issues now resolved, yesterday I proceeded to build an IOP model for each of new FEs. I assigned them names and DCUIDs consist with the 40m convention, listed below. These models currently exist on only the cloned copy of /opt/rtcds running on the test stand. They will be copied to the main network disk later, once the new systems are fully tested.

Model Host CPU DCUID
c1x06 c1bhd 1 23
c1x07 c1sus2 1 24

The models compile and install successfully. The RCG runtime diagnostics indicate that all is working except for the timing synchronization and DAQD data transmission. This is as expected because neither of these have been set up yet.

Timing system set-up

The next step is to provide the 65 kHz clock signals from the timing fanout via LC optical fiber. I overlooked the fact that an SPX optical transceiver is required to interface the fiber to the timing slave board. These were not provided with the timing slaves we received. The timing slaves require a particular type of transceiver, 100base-FX/OC-3, which we did not have on hand. (For future reference, there is a handy list of compatible transceivers in E080541, p. 14.) I placed a Digikey order for two Finisar FTLF1217P2BTL, which should arrive within two days.

Attachment 1: Screen_Shot_2021-05-03_at_4.16.06_PM.png
Screen_Shot_2021-05-03_at_4.16.06_PM.png
  16130   Tue May 11 16:29:55 2021 JonUpdateCDSI/O Chassis Assembly
Quote:

Timing system set-up

The next step is to provide the 65 kHz clock signals from the timing fanout via LC optical fiber. I overlooked the fact that an SPX optical transceiver is required to interface the fiber to the timing slave board. These were not provided with the timing slaves we received. The timing slaves require a particular type of transceiver, 100base-FX/OC-3, which we did not have on hand. (For future reference, there is a handy list of compatible transceivers in E080541, p. 14.) I placed a Digikey order for two Finisar FTLF1217P2BTL, which should arrive within two days.

Today I brought and installed the new optical transceivers (Finisar FTLF1217P2BTL) for the two timing slaves. The timing slaves appear to phase-lock to the clocking signal from the master fanout. A few seconds after each timing slave is powered on, its status LED begins steadily blinking at 1 Hz, just as in the existing 40m systems.

However, some other timing issue remains unresolved. When the IOP model is started (on either FE), the DACKILL watchdog appears to start in a tripped state. Then after a few minutes of running, the TIM and ADC indicators go down as well. This makes me suspect the sample clocks are not really phase-locked. However, the models do start up with no error messages. Will continue to debug...

Attachment 1: Screen_Shot_2021-05-11_at_3.03.42_PM.png
Screen_Shot_2021-05-11_at_3.03.42_PM.png
  16131   Tue May 11 17:43:09 2021 KojiUpdateCDSI/O Chassis Assembly

Did you match the local PC time with the GPS time?

  6814   Wed Jun 13 11:19:05 2012 steveUpdateSUSIDC receptacles clamped

The MC_ IDC 64 pin cables from sat. amplifiers to junction-interface-board towards  whitening - dewhitening at the back of rack 1 X 5 are finally  clamped with

All other sus cables of the same kind have the correct short latch arm to lock them in for reliable contact.

Attachment 1: IMG_1341.JPG
IMG_1341.JPG
  10113   Mon Jun 30 16:55:24 2014 ericqUpdateGeneralIFO (mostly) aligned

IR Alignment of the IFO is recovered! Green alignment could use some attention. 

Arms and PRC hold well, powers are within normal ranges. (TR[X,Y] >.9, POP110I > 400)

Details:

  • Starting from where Koji had brought things (i.e. beams on REFL, AS), I gradually stepped the PRM back to where I had a PRC lock right before the bootfest, using SUSPIT_IN and SUSYAW IN, while stepping the TT pointing (arbitrarily shifting TT1 and TT2) to keep the REFL camera spot centered. 
  • Green was locked fairly well to the Yarm (GTRY = 0.8), so I knew it supported a mode. I misaligned ITMX to keep the Xarm out of the way. 
  • Adjusting TT1 and TT2, I was able to get some light on the POP camera, while keeping REFL spot visible with small adjustments to PRM
  • I set up the PRM to set up some PRM-ITMY retroreflection, and saw tiny flashes in TRY. 
  • From here, I wandered around with the tip-tilts to try and get better arm pointing, while tweaking PRM for the REFL spot and retroflection, and BS for the AS spot. I got this to TRY flashes of ~0.3

Then, Jenne took over, worked some alignment magic, and did the hard part of getting the Yarm locked and ASS'd. 

  • I then took back over and got the Xarm locked and ASS'd.
  • I saved relevant mirror positions, and set up the PRMI, got it locked, saved PRM position. 
  • Jiggled the BS/PRM oplev HeNe power connector, it turns on now, oplevs are working. 
  • Similar to TT1, TT2 gains for PIT and YAW are now 300. Strictly speaking, they don't have to be, but PIT would be very nearly railed, and I changed YAW so that all four gains would be consistent.

Caveats:

Green no longer locks to 00 on the Y-arm, and the X-arm green transmission isn't the best despite PZT fiddling (~.6). Also, when green is locked to the Xarm, I see a distinct circular spot on the GTRY camera, with Y green and PSL green shutters closed. 

While Jenne used Yarm ASS successfully, when I run it now, it slowly pushes things out of alignment, and two of the traces (YARM_ETM_YAW_L_DEMOD_I_OUTPUT, and the same for ITM) have a reasonable constant offset that doesn't move away. 

 

  10114   Mon Jun 30 22:06:55 2014 JenneUpdateASCIFO (mostly) aligned - ASS working

[Koji, Jenne]

The Yarm ASS is now working (as is the Xarm ASS).  Both of the TT's pitch servos had a sign flip.  We don't know why.

To start, we lowered the matrix elements that push on the TTs by a factor of 3, to compensate for the new factor of 3 in the slider gains:  ezcastep C1:ASS-YARM_OUT_MTRX_5_5 /3 C1:ASS-YARM_OUT_MTRX_5_7 /3 C1:ASS-YARM_OUT_MTRX_6_6 /3 C1:ASS-YARM_OUT_MTRX_6_8 /3 C1:ASS-YARM_OUT_MTRX_7_5 /3 C1:ASS-YARM_OUT_MTRX_7_7 /3 C1:ASS-YARM_OUT_MTRX_8_6 /3 C1:ASS-YARM_OUT_MTRX_8_8 /3

We turned off all 4 tip tilt ASS servos (in the Yarm ASS servo screen), and turned them on one at a time.  By doing this, we discovered that the pitch servos for both TT1 and TT2 needed to have the opposite sign from what they used to have.  However, the yaw servos kept the original signs.  It really doesn't make sense to me why this should be, but this is the way the ASS servo works.  We left both Xarm and Yarm ASSs on for several minutes, and saw that they didn't push any mirrors out of alignment.

The ASS_DOTHER_ON burt snapshot has been resaved with the new values.

 

Also, earlier this evening, I aligned the Yarm green beam to the cavity, although the cavity was not optimally aligned, so this needs to be re-done.

 

On our to-do list should be to add the tip tilt slider values to the DAQ channels list.

  1830   Tue Aug 4 23:03:56 2009 albertoUpdateLockingIFO Alignment

After the mini boot fest that Jenne did today, I checked whether that fixed the overflow issues we yesterday prevented the alignemnt of the arms. 

I ran the alignment script for the arms getting 0.85 for TRX and 0.75 for TRY: low values.

After I ran the script ,C1SUSVME1 and C1SUSVME2 started having problems with the FE SYNC (counter at 16378). I rebooted those two and fix the sync problem but the transmitted powers didn't improve.

Are we still having problem due to MC misalignment?

  1833   Wed Aug 5 09:48:05 2009 albertoUpdateLockingIFO Alignment

Quote:

After the mini boot fest that Jenne did today, I checked whether that fixed the overflow issues we yesterday prevented the alignemnt of the arms. 

I ran the alignment script for the arms getting 0.85 for TRX and 0.75 for TRY: low values.

After I ran the script ,C1SUSVME1 and C1SUSVME2 started having problems with the FE SYNC (counter at 16378). I rebooted those two and fix the sync problem but the transmitted powers didn't improve.

Are we still having problem due to MC misalignment?

I also noticed that the FSS transmitted power has been constantly decaying for the last 6 months. Only in the last month tt dropped by 15%. The laser power hasn't decayed as much, so it's probably not the cause.
Maybe this is one reason why lately of less power going to the IFO.
 
We call it FSS Transmission, but I guess we mean power transmitted TO the IFO, that is it measures the power reflected from reference cavity, right?
 
Still on the front of the FSS, the reflected power has dropped from -0.5 to -1.2. Here I also wonder about the reason of negative values for that.
 

See attachments

Attachment 1: 2009-08-09_FSStransPD.png
2009-08-09_FSStransPD.png
Attachment 2: 2009-08-09_FSreflPD.png
2009-08-09_FSreflPD.png
ELOG V3.1.3-