40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  40m Log, Page 150 of 335  Not logged in ELOG logo
ID Date Author Type Category Subjectup
  4014   Mon Dec 6 11:59:41 2010 josephbUpdateCDSNew c1lsc computer moved to lsc rack

Computer moved:

The c1lsc computer has been moved over to the 1Y3 rack, just above the c1lsc IO chassis. 

It will talking to the c1sus computer via a Dolphin PCIe reflected memory card.  The cards have been installed into c1lsc and c1sus this morning.

It will talk to its IO chassis via the usual short IO chassis cable.


To Do:

The Dolphin fiber still needs to be strung between c1sus and c1lsc.

The DAQ cable between c1lsc and the DAQ router (which lets the frame builder talk directly with the front ends) also needs t to be strung.

c1lsc needs to be configured to use fb as a boot server, and the fb needs to be configured to handle the c1lsc machine.

  5577   Thu Sep 29 20:37:12 2011 MirkoUpdateComputersNew c1oaf c-code: Breaking in new way

[Mirko, Jenne]

Programmed a new implementation of the LMS in C. Compiles fine in gcc. The full code still kills c1lsc computer. Tried to go through the code uncommenting more and more. Not perfect in reproducability. The attached version should compile and keep c1oaf running, but not actually produce an adaptive filter. At some point the code just keeps c1oaf from starting up. Leaves the c1lsc computer in working order. At some point I got error messages like ..................................................................
    Warning: "Identical process variable names on multiple servers"
    Context: "Channel: "C1:OAF-ADAPT_CORR_BS_Name08", Connecting to:, Ignored: c1lsc:34533"
    Source File: ../cac.cpp line 1209
    Current Time: Thu Sep 29 2011 19:18:17.219208306
    Warning: "Identical process variable names on multiple servers"
    Context: "Channel: "C1:OAF-ADAPT_CORR_BS_Name09", Connecting to:, Ignored: c1lsc:34533"
    Source File: ../cac.cpp line 1209
    Current Time: Thu Sep 29 2011 19:18:17.225999915
    Warning: "Identical process variable names on multiple servers"
    Context: "Channel: "C1:OAF-ADAPT_CORR_ETMX_SW1R", Connecting to:, Ignored: c1lsc:34533"
    Source File: ../cac.cpp line 1209
    Current Time: Thu Sep 29 2011 19:18:17.243037042

This usually indicates that there are multiple carepeater running. Didn't find where that would be. After rebooting c1lsc and c1sus a couple of times everything seems fine.

Attachment 1: ADAPT_XFCODE11-09-29---20-12.c
// LMS algorithm adaptive filtering for the Caltech 40m -- Sept. 2011 by M. Prijatelj

#define nDOF 8
#define nWIT 21
#define nTAPS 1000

void ADAPT_XFCODE(double *in, int inSize, double *out, int outSize) {

//First the DOFs and their switches
//int nDOF=8;
... 136 more lines ...
  5424   Thu Sep 15 20:16:15 2011 jamieUpdateCDSNew c1oaf model installed and running

[Jamie, Jenne, Mirko]

New c1oaf model installed

We have installed the new c1oaf (online adaptive feed-forward) model.  This model is now running on c1lsc.  It's not really doing anything at the moment, but we wanted to get the model running, with all of it's interconnections to the other models.

c1oaf has interconnections to both c1lsc and c1pem via the following routes:

c1lsc ->SHMEM-> c1oaf
c1oaf ->SHMEM-> c1lsc
c1pem ->SHMEM-> c1rfm ->PCIE-> c1oaf

Therefore c1lsc, c1pem, and c1rfm also had to be modified to receive/send the relevant signals.

As always, when adding PCIx senders and receivers, we had to compile all the models multiple times in succession so that the /opt/rtcds/caltech/c1/chans/ipc/C1.ipc would be properly populated with the channel IPC info.


There were a couple of issues that came up when we installed and re/started the models:

c1oaf not being registered by frame builder

When the c1oaf model was started, it had no C1:DAQ-FB0_C1OAF_STATUS channel, as it's supposed to.  In the daqd log (/opt/rtcds/caltech/c1/target/fb/logs/daqd.log.19901) I found the following:

Unable to find GDS node 22 system c1oaf in INI files

It turns out this channel is actually created by the frame builder, and it could not find the channel definition file for the new model, so it was failing to create the channels for it.  The frame builder "master" file (/opt/rtcds/caltech/c1/target/fb/master) needs to list the c1oaf daq ini files:


These were added, and the framebuilder was restarted.  After which the C1:DAQ-FB0_C1OAF_STATUS appeared correctly.

SHMEM errors on c1lsc and c1oaf

This turned out to be because of an oversight in how we wired up the skeleton c1oaf model.  For the moment the c1oaf model has only the PCIx sends and receives.  I had therefore grounded the inputs to the SHMEM parts that were meant to send signals to C1LSC.  However, this made the RCG think that these SHMEM parts were actually receivers, since it's the grounding of the inputs to these parts that actually tells the RCG that the part is a receiver.  I fixed this by adding a filter module to the input of all the senders.

Once this was all fixed, the models were recompiled, installed, and restarted, and everything came up fine.

All model changes were of course committed to the cds_user_apps svn as well.

  15236   Fri Feb 28 19:37:18 2020 gautamUpdatePSLNew c1psl installed
  1. The new c1psl Acromag crate is now interfaced to the Eurocrate electronics in 1X1 (formerly VME c1psl) and 1X2 (formerly c1iool0).
  2. The PMC and IMC can be locked. We will investigate stability / duty cycle over the weekend.
  3. There were a few issues with the wiring - specifically, the worng kind of Acromag BIO unit (sourcing, whereas we want sinking) was used for the FSS board switches. Once Jordan fixed this issue, the IMC could be locked.
  4. I began to do the detailed tests of the IMC Servo card channels - there may be some issues with the boost stages, but I ran out of time yesterday, so tbc Monday.

On Monday, we will remove the old c1psl and c1iool0 machines from the electronics rack and install the Acromag crate in a more permanent way. We will also clean up some of the old cabling and cross connects, althoug the situation seems so complicated (some cross connects are also used by the rtcds c1ioo expansion chassis) that I am inclined not to remove any cables.

The area around 1X1/1X2 has a lot of dangling cables and general detritus. Be careful if you are walking around there. We will clean up on monday.

  15114   Tue Jan 7 18:51:51 2020 JonUpdatePSLNew c1psl server assembled

I've assembled a new SuperMicro rackmount machine to replace c1psl. It is currently set up on the electronics bench.

  • OS: Debian 10.2
  • Hostname: c1psl1 (will become c1psl after installation)
  • IP: (registered in the martian DNS)
  • Network drive mount point set up (/cvs/cds), which provides all the EPICS executables.
  14581   Fri Apr 26 19:35:16 2019 JonUpdateSUSNew c1susaux installed, passed first round of scripted testing

[Jon, Gautam]

Today we installed the c1susaux Acromag chassis and controller computer in the 1X4 rack. As noted in 14580 the prototype Acromag chassis had to first be removed to make room in the rack. The signal feedthroughs were connected to the eurocrates by 10' DB-37 cables via adapters to 96-pin DIN.

Once installed, we ran a scripted set of suspension actuation tests using PyIFOTest. BS, PRM, SRM, MC1, MC2, and MC3 all passed these tests. We were unable to test ITMX and ITMY because both appear to be stuck. Gautam will shake them loose on Monday.

Although the new c1susaux is now mounted in the rack, there is more that needs to be done to make the installation permanent:

  • New 15V and 24V power cables with standard LIGO connectors need to be run from the Sorensenn supplies in 1X5. The chassis is currently powered by bench supplies sitting on a cart behind the rack.
  • All 24 new DB-37 signal cables need to be labeled.
  • New 96-pin DIN connectors need to be put on two ribbon cables (1Y5_80 B, 1Y5_81) in the 1X4 rack. We had to break these connectors to remove them from the back of the eurcrates.
  • General cleanup of any cables, etc. left around the rack. We cleaned up most things this evening.
  • Rename the host computer c1susaux2 --> c1susaux, and update the DNS lookup tables on chiara.

On Monday we plan to continue with additional scripted tests of the suspensions.

gautam - some more notes:

  • Backplane connectors for the SUS PD whitening boards, which now only serve the purpose of carrying the fast BIO signals used for switching the whitening, were moved from the P1 connector to P2 connector for MC1, MC2, MC3, ITMX, ITMY, BS and PRM.
  • In the process, the connectors for BS and PRM were detatched from the ribbon cable (there wasn't any good way to unseat the connector from the shell that I know of). These will have to be repaired by Chub, and the signal integrity will have to be checked (as they have to be for the connectors that are allegedly intact).
  • While we were doing the wiring, I disconnected the outputs of the coil driver board going to the satellite box (front panel DB15 connector on D010001). These were restored after our work for the testing phase.
  • The backplane cables to the eurocrate housing the coil driver boards were also disconnected. They are currently just dangling, but we will have to clean it up if the new crate is performing alright.
  • In general the cable routing cleanliness has to be checked and approved by Chub or someone else qualified. In particular, the power leads to the eurocrate are in the way of the DIN96-DB37 adaptor board of Johannes' design, particularly on the SUS PD eurocrate.
  • Tapping new power rails for the Acromag chassis will have to be done carefully. Ideally we shouldn't have to turn off the Sorensens.
  • There are some software issues we encountered today connected with the networking that have to be understood and addressed in a permanent way.
  • Sooner rather than later, we want to reconnect the Acromag crate that was monitoring the PSL channels, particularly given the NPRO's recent flakiness.
  • The NPRO was turned back on (following the same procedure of slowly dialing up the injection current). Primary motivation to see if the mode cleaner cavity could be locked with the new SUS electronics. Looks like it could. I'm leaving it on over the weekend...
Attachment 1: IMG_3254.jpg
Attachment 2: IMG_3256.jpg
  10513   Wed Sep 17 13:41:00 2014 JenneUpdateSUSNew calibrated channels for test QPD

Steve asked about calibrating the QPD, so I set up some new epics records so that we can have calibrated versions of the QPD output.

The new channels are called C1:ASC-TESTQPD_Y_Calc and C1:ASC-TESTQPD_X_Calc for pitch and yaw, respectively.


 * I modified /cvs/cds/caltech/target/c1iscaux/QPD.db to add 2 new channels.  Since we are currently plugged into the IPPOS channels, I didn't want to modify the units of IPPOS, which is why I created new channels.  The new channels are just the IPPOS normalized X and Y channels, multiplied by a calibration factor.  Steve has already done a rough calibration for his setup, so I used those numbers (0.15 urad/ct for pitch and 0.25 urad/ct for yaw). 

* Rebooted c1iscaux.  This required adding it to chiara's /etc/hosts file.

* Added the channels to the /opt/rtcds/caltech/c1/chans/daq/C0EDCU.ini file so that the channels would appear in dataviewer.

* Restarted the framebuilder daqd process.

How to modify the calibration:

1) On a control room workstation, cd /cvs/cds/caltech/target/c1iscaux to get to the right folder.  (Note that this is still in the old cvs/cds place, *not* the new opt/rtcds place)

2)  open the epics database file by typing sudo emacs QPD.db.  Since this is a protected file, you need to use the "sudo" command, and will have to type in the usual controls password. 

3)  Find the "records" that have the channel names C1:ASC-TESTQPD_Y_Calc and C1:ASC-TESTQPD_X_Calc by scrolling down.  (Right now they are on lines #550 and #561 of the text file).

4) For each of these 2 records, modify the calibration in the line that says something like field(CALC,"(A*0.25)").  In this example, the current calibration is 0.25 urad/oldCount.  Change the number to the new value.

5) Save the file.  If you followed the procedure in step2 and used the emacs program and you can't use the mouse, do the following:  Hold down the "ctrl" key.  Keeping ctrl pushed down, push the "x" key.  Still keeping ctrl pushed down, push the "s" key. 

6) Close the file.  If you followed the procedure in step2 and used the emacs program and you can't use the mouse, do the following:  Hold down the "ctrl" key.  Keeping ctrl pushed down, push the "x" key.  Still keeping ctrl pushed down, push the "c" key. 

7) Reboot the slow computer called c1iscaux.  You should be able to do this remotely by typing telnet c1iscaux, and then typing reboot.  If that doesn't work, you may have to go into the IFO room and power cycle the crate by turning the key.  This computer is in 1Y3, near the bottom.

8) Check that you can see your channels - you should be finished now!

For steps 3 and 4, here is a screenshot of the lines in the text file:


  13902   Thu May 31 15:36:59 2018 gautamUpdateGeneralNew camera channels

Jon informed me that there are some EPICS channels that JoeB's camera server code looks for that don't exist. I thought Jigyasa and I had added everything last year but turned out not to be the case. I followed my instructions from here, did the trick. While cleaning up, I also re-named the "*MC1" channels to "*ETMX", since that's where the camera now resides. New channels are:

C1: CAM-ETMX_ARCHIVE_INTERVAL (Archival interval in minutes)
C1: CAM-ETMX_ARCHIVE_RESET (Reset Archival interval in minutes)

C1: CAM-ETMX_CONFIG_FILE (Config file)

  3399   Wed Aug 11 13:28:44 2010 josephbUpdateCDSNew cdsIPCx parts, old part breaks models

While working on a test stand at LLO, I've discovered that there's a new update to the Real Time Code Generator that breaks virtually all of our current models.

Previously, we've been using the cdsIPCx part as a flexible link between models, and could be set to RFM (reflected memory), SHMEM (shared memory on the local computer), or PCIE (pci express or dolphin I think) depending on what was written in the IPC file (found in /cvs/cds/caltech/chans/ipc/C1.ipc).

Recently, three new parts were added called cdsIPCx_SHMEM, cdsIPCx_RFM, cdsIPCx_PCIE, and the previous cdsIPCx broken.  The cdsIPCx_***** has to match the type written in the IPC file or else it errors out with a rather unhelpful error message which doesn't tell you which part/line is in conflict...


***ERROR: IPCx type mis-match: I vs. ISHM
make: *** [g1lsc] Error 255

In anycase, when using a current checkout (updated or checked out after ~July 30th), all cdsIPCx blocks in the simulink models needs to be changed to the approriate type.  I'm trying to get a new CDS_PARTS.mdl file I updated into the svn, but for now you can just open up the model file directly in the /advLigoRTS/src/epics/simLink/lib directory and copy it in from there (i.e. cdsIPCx_SHMEM.mdl) to your model file.  I'm also trying to get the feCodeGen.pl file changed so the error message actually tells you what channel/part is mismatching so you don't have to guess.

An easy way to modify a file for all shared memory connections without doing a ton of cutting, pasting and renaming is:

sed -i 's/"cdsIPCx"/"cdsIPCx_SHMEM"/g' file_name_here.mdl

  2143   Mon Oct 26 17:45:34 2009 JenneUpdateAdaptive FilteringNew changes to the OAF fe code

[Alex, Jenne, Sanjit]

Alex came to the 40m today, and did several awesome things in OAF-land.

We discovered that there is, in fact, an ADC board connected to the ASS machine.  The tricky bit is that it only has a ribbon cable connector, so before we can use this ADC, we need to figure out how to make a breakout board/cable/something to connect the seismometer/accelerometer/microphone BNCs to this little board.  This is the same little board that connects the timing slave to the ASS machine.  For good or for ill, the timing slave is connected to this board via clip-doodles.  Potentially we can connect an ADC tester board to this board, and go from seismometer BNCs to clipdoodles to the tester board, but I'm not in love with the idea of utilizing clipdoodles as a semi-permanent solution until the upgrade.  I emailed Ben to see if he has a better idea, or (better yet) some spare hardware now that's the same as we'll use after the upgrade.  If we can use this ADC, it may solve our timing problem which is caused by the 110B ADC used by the PEM computer. Alex showed Sanjit and I how to connect the ASS's ADC card to the simulink diagram, when we're ready for that.

We also poked around in the code, and it seems that we can now save and restore OAF coefficients at will.  I added buttons to the OAF (ASS) screen, and Alex made it so the OAF coefficients are saved in RFM shared memory whenever you click the "save coeffs" button, and are restored when you click the "restore coeffs" button.  The buttons are the same as the 'Reset' button which has been there for a long time, so they seem to maybe have a similar problem in that you have to hold the button for a while in order for the code to realize that the button has been depressed.  We couldn't fix this easily, because it looks like our SimuLink cds stuff is a little out of date.  Some day (before/when Joe and Peter make new screens for the new 40m), we need to update these things.  Alex was concerned that it might take a while to do this, if the update broke some of the blocks that we're currently using.  Also, Sanjit and I now need to check that the coefficient-saving is going as planned.  When I have DTT open, and the OAF running, I see a certain shape to the signal which is sent to MC1 to correct for the seismic motion.  This shape includes at least several peaks at resonant frequencies that exist in our stacks/suspensions.  I can then save the coefficients, reset the active filter, and then restore the coefficients.  When I do this while watching DTT, it seems as though the general shape of the filter is restored, but none of the detailed features are.  The reason for this is still under investigation. 

The code-modifications involved a few iterations of 'remaking the ass'.

  3124   Sat Jun 26 20:16:44 2010 josephbUpdateCDSNew checkout of RCG from SVN and changes made

ORPHAN ENTRY FOUND ON ROSALBA:::::::::::::::::::::::::::::::::::::::::::::::::::>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

We did svn update.  Then Alex realized he missed adding some files, so added them to the svn, and then we checked out again.


We rebuilt awg, fb, nds.

We reloaded service xinet.d, after editing /etc/xinetd.d/chnconf.  We changes all the tpchn_c1 to tpchn_c1SYS


There's a new naming scheme for the model files.  They start with the site name.  So, lsc becomes c1lsc. 


On any machine you want code running, make a symbolic link to /cvs/cds/rtcds/ in /opt/

  7269   Fri Aug 24 11:46:59 2012 MashaUpdatePEMNew classification weights

I recently realized that I may have over-trained my classification neural network and used too many parameters, so that my weight vectors are too fine-tuned to my particular data set and do not generalize well. I lowered the number of hidden neurons in the network to 15, and the number of epochs to 25000, and regularized based on the deltas (the gradient). Here is the most recent learning curve:





The old weights and code are saved in the c1pem directory in the file "classify_seismic_20neurons.c", while the current 15 neuron network is saved as "classify_seismic.c". I'll monitor the performance of this current network throughout the day, and decide which one we should keep.

  809   Thu Aug 7 11:54:26 2008 josephbConfigurationCamerasNew code + gstreamer allows for easy saving and compression of images
Modified the CamSnap code to output the image data stream to standard out. This can then be piped into a gstreamer plugin and then be used to save, encode, transmit, receive, slice, dice and or mangle video (or virtually any type of data stream).

The gstreamer webpage can be found at: http://www.gstreamer.net/

Under documentation you can find a list off all available plug-ins. Some good, some bad, some ugly.

Running the following command on Mafalda (via ssh -X mafalda) or Rosalba while in /cvs/cds/caltech/target/Prosilica/40mCode/SnapCode/

CamSnap -F 'Mono8' -c 44058 -E 15000 -X 0 -Y 0 -H 480 -W 752 -l 0 -m 1000 | gst-launch-0.10 fdsrc fd=0 blocksize=360960 ! video/x-raw-gray, height=480, width=752, bpp=8,depth=8,framerate=1/1 ! ffmpegcolorspace ! ximagesink

This command will create a window which displays what the camera with UID 44058 is looking at. It will display 1000 images, then quit. (You can switch the -m 100 to -i to just have it continue until the process is stopped).

You can also encode the data into compressed format and save it in a media file. The following command line will encode the images into an ogg media file (.ogm), which can be played with the totem viewer (available on Rosalba or almost any machine running Ubuntu or Centos) or any other viewer capable of handling ogm files. By switching the plugins you can generate other formats as well.

The compression is good, putting 300 images normally about 500K individually uncompressed to about 580K as a single file.

The following command line was used to generate the attached video file:

CamSnap -F 'Mono8' -c 44058 -E 5000 -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=30/1 ! ffmpegcolorspace ! theoraenc ! oggmux ! filesink location="./testVideo.ogm"

Currently looking into plugins which allow you to pull individual frames out of a video file and display or save them in a variety of formats. This would allow us to save long term images in compressed video format, and then pull out individual frames as needed.

Also need to look into how to "T" the streams, so one can be displaying while another encodes and saves.
Attachment 1: testVideo.ogm
  812   Fri Aug 8 09:54:10 2008 ranaUpdateCamerasNew code + gstreamer allows for easy saving and compression of images

Modified the CamSnap code to output the image data stream to standard out. This can then be piped into a gstreamer plugin and then be used

Didn't work; Prosilica has only 1 "l". Even so, sshing from op440m to mafalda, I got this:
mafalda:SnapCode>CamSnap -F 'Mono8' -c 44058 -E 5000 -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=30/1 ! ffmpegcolorspace ! theoraenc ! oggmux ! filesink location="./testVideo.ogm"
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...

** (gst-launch-0.10:27121): WARNING **: Size 60 is not a multiple of unit size 360960
Caught SIGSEGV accessing address 0x487c
ERROR: from element /pipeline0/ffmpegcsp0: subclass did not specify output size
Additional debug info:
gstbasetransform.c(1495): gst_base_transform_handle_buffer (): /pipeline0/ffmpegcsp0:
subclass did not specify output size
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7deddae in __lll_mutex_lock_wait ()
#2  0xb7de9aac in _L_mutex_lock_51 () from /lib/tls/i686/cmov/libpthread.so.0
#3  0xb7de949d in pthread_mutex_lock ()
#4  0xb7e452e0 in g_static_rec_mutex_lock () from /usr/lib/libglib-2.0.so.0
#5  0xb7f1fa08 in ?? () from /usr/lib/libgstreamer-0.10.so.0
#6  0x080c1220 in ?? ()
#7  0x00000001 in ?? ()
#8  0x0809586c in ?? ()
#9  0x00000001 in ?? ()
#10 0x08095868 in ?? ()
#11 0xb7f7a2a8 in ?? () from /usr/lib/libgstreamer-0.10.so.0
#12 0xb7e8da80 in ?? () from /usr/lib/libglib-2.0.so.0
#13 0xb7f7a2a8 in ?? () from /usr/lib/libgstreamer-0.10.so.0
#14 0xb7f7a2a8 in ?? () from /usr/lib/libgstreamer-0.10.so.0
#15 0x00000000 in ?? ()
Spinning.  Please run 'gdb gst-launch 27121' to continue debugging, Ctrl-C to quit, or Ctrl-\ to dump core.
Caught interrupt -- 
  1261   Fri Jan 30 17:30:31 2009 Alberto, JosephbConfigurationComputersNew computer Ottavia set up
Alberto, Joseph,

Today we installed the computer that some time ago Joe bought for his GigE cameras. It was baptized "OTTAVIA".

Ottavia is black, weighs about 20 lbs and it's all her sister, Allegra (who also pays for bad taste in picking names). She runs an Intel Core 2 Quad and has 4GB of RAM. We expect much from her.

Some typical post-natal operations were necessary.

1) Editing of the user ID
  • By means of the command "./usermod -u 1001 controls" we set the user ID of the user controls to 1001, as it is supposed to be.

2) Connection to the Martian network
  • Ottavia was given IP address by editing the file /etc/sysconfig/networ-scripts/ifcfg-eth0 (we also edited the netmask and the gateway address as in the Wiki)
  • In linux1, which serves as name server, in the directory /var/named/chroot/var/named, we modified both the IP-to-name and name-to-IP register files 131.215.113.in-addr.arpa.zone and 131.215.11in-addr.martian.zone.
  • We set the file /etc/resolv.conf so that the OS knows who is the name server.

3) Mounting of the /cvs/cds path
  • We created locally the empty directories /cvs/cds
  • We edited the files /etc/fstab adding the line "linux1:/home/cds /cvs/cds nfs rw,bg,soft 0 0"
  • We implemented the common variables of the controls environment by sourcing the cshrc.40m: in the file /home/controls/.cshrc we added the two lines "source /cvs/cds/caltech/cshrc.40m" and "setenv PATH ${PATH}:/cvs/cds/caltech/apps/linux64/matlab/bin/"
  2967   Fri May 21 14:31:46 2010 josephb,alexUpdateCDSNew computer and IO chassis working in 1X4

Alex brought over a ADC, DAC, and PCIe card which goes into the computer and talk to the IO chassis.  We tried installing the new "small" IO chassis in 1X4, but initially it couldn't find the ADC/DAC boards, just the Contec Binary out board.

We tried several different configurations (different computer, different IO chassis, the megatron chassis, the megatron IO chassis with new cards, a new IO chassis with megatron cards.

The two things were concluded once we got a new IO chassis talking with the new computer. 

1) Its possible one of the slots is in the IO chassis as we didn't see the ADC until we moved it to a different slot in the new chassis

2) The card that Alex had brought over to put in the computer doesn't behave well with these IO chassis.  He went back to downs to try and figure out what it is, and test it with the chassis over there.

Currently, Megatron's IO chassis is sitting on a table behind racks 1Y5 and 1Y6, along with the new "large" IO chassis.  Megatron's PCIe card for talking to the IO chassis was moved to the computer in 1X4.  The computer in 1X4 is currently being called c1iscex with IP 

  12831   Wed Feb 15 22:16:05 2017 Max IsiUpdateSummary PagesNew condor_q format

There has been a change in the default format for the output of the condor_q command at CIT clusters. This could be problematic for the summary page status monitor, so I have disabled the default behavior in favor of the old one. Specifically, I ran the following commands from the 40m shared account: mkdir -p ~/.condor echo "CONDOR_Q_DASH_BATCH_IS_DEFAULT=False" >> ~/.condor/user_config This should have no effect on the pages themselves.

  15960   Wed Mar 24 22:54:49 2021 gautamUpdateLSCNew day, new problems

I thought I'd get started on some of the tests tonight. But I found that this problem had resurfaced. I don't know what's so special about the REFL55 photodiode - as far as I can tell, other photodiodes at the REFL port are running with comparable light incident on it, similar flat whitening gain, etc etc. The whitening electronics are known to be horrible because they use the quad LT1125 - but why is only this channel problematic? To describe the problem in detail:

  • I had checked the entire chain by putting an AM field on the REFL 55 photodiode, and corroborating the pk-to-pk (counts) value measured in CDS with the "nominal" setting of +18dB flat whitening gain against the voltage measured by a "reference" PD, in this case a fiber coupled NF1611.
  • In the above test, I confirmed that the measured signal was consistent with the value reported by the NF1611.
  • So, at least on Friday, the entire chain worked just fine. The PRMI PDH fringes were ~6000cts-pp in this condition.
  • Today, I found that while trying to acquire PRMI lock, the PDH fringes witnessed in REFL55 were saturating the ADC. I lowered the whitening gain to 0 dB (so a factor of 8). Then the PDH fringes were ~20,000cts-pp. So, overall, the gain of the chain seems to have gone up by a factor of ~25. 
  • Given my NF1611 based test, the part of the chain I am most suspicious of is the whitening filter. But I don't have a good mechanism that explains this observation. Can't be as simple as the input impedance of the LT1125 being lowered due to internal saturations, because that would have the opposite effect, we would measure a tiny signal instead of a huge one

I request Koji to look into this, time permitting, tomorrow. In slightly longer term, we cannot run the IFO like this - the frequency of occurrence is much too high and the "fix" seems random to me, why should sweeping the whitening gain fix the problem? There was some suggestion of cutting the PCB trace and putting a resistor to limit the current draw on the preceeding stage, but this PCB is ancient and I believe some traces are buried in internal layers. At the same time, I am guessing it's too much work to completely replace the whitening electronics with the aLIGO style units. Anyone have any bright ideas?

Anyway, I managed to lock the PRMI (ETMs misaligned) using REFL165I/Q. Then, instead of using the BS as the MICH actuator, I used the two ITMs (equal magnitude, opposite sign in the LSC output matrix).

  • The digital demod phase in this config is different from what is used when the arm cavities are in play (under ALS control). Probably the difference is telling us something about the reflectivity of the arm cavity for various sideband fields, from which we can extract some useful info about the arm cavity (length, losses etc). But that's not the focus here - the correct digital demod phase was 11 degrees. See Attachment #1 for the sensing matrix. I've annotated it with some remarks.
  • The signals appear much more orthogonal when actuating on the ITMs. However, I was still only able to null the MICH line sensed in the PRCL sensor to a ratio of 1/5 (while looking at peaks on DTT). I was unable to do better by fine tuning either the digital demod phase, or the relative actuation strength on each ITM
  • The PRCL loop had a UGF of ~120 Hz, MICH loop ~60 Hz.
  • With the PRMI locked in this config, I tried to measure the appropriate loop gain and sign if I were to use the REFL55 photodiode instead of REFL165 - but I didn't have any luck. Unsurprising given the known electronics issues I guess...

I didn't get around to running any of the other tests tonight, will continue tomorrow.

Update Mar 26: Attachments #2 and #3 show that there is clearly something wrong with the whitening electronics associated with REFL55 channels - with the PSL shutter closed (so the only "signal" being digitized should be the electronics noise at the input of the whitening stage), the I and Q channels don't show similar profiles, and moreover, are not consistent (the two screenshots are from two separate sweeps). I don't know what to make of the parts of the sweep that don't show the expected "steps". Until ndscope gets a log-scaled y-axis option, we have to live with the poor visualization of the gain steps which are dB (rather than linearly) spaced. For this particular case, StripTool isn't an option either because the Q channel as a negative offset, and I opted agains futzing with the cabling at 1Y2 to give a small fixed positive voltage instead. I will emphasize that on Friday, this problem was not present, because the gain balance of the I and Q channels was good to within 1dB.

Attachment 1: PRMI3f_noArmssensMat.pdf
Attachment 2: REFL55_whtGainStepping.png
Attachment 3: REFL55_whtGainStepping2.png
  15714   Mon Dec 7 14:32:02 2020 gautamUpdateLSCNew demod phases for POX/POY locking

In favor of keeping the same servo gains, I tuned the digital demod phases for the POX and POY photodiode signals to put as much of the PDH error signal in the _I quadrature as possible. The changes are summarized below:

POX / POY demod phases
PD Old demod phase [deg] New demod phase [deg]
POX11 79.5 -75.5
POY11 -106.0 116.0

The old locking settings seem to work fine again. This setting isn't set by the ifoconfigure scripts when they do the burt restore - do we want it to be?

Attachments #1 and #2 show some spectra and TFs for the POX/POY loops. In Attachment #2, the reference traces are from the past, while the live traces are from today. In fact, to have the same UGF as the reference traces (from ~1 year ago), I had to also raise the digital servo loop gain by ~20%. Not sure if this can be put down to a lower modulation depth - at least, at the output on the freq ref box, I measured the same output power (at the 0dB variable attenuator gain setting we nominally run in) before and after the changes. But I haven't done an optical measurement of the modulation depth yet. There is also a hint of lesser phase available at ~100 Hz now compared to a year ago.

Attachment 1: POX_POY_OLTF.pdf
Attachment 2: POX_POY_spectra.pdf
  4735   Tue May 17 22:50:00 2011 JamieConfigurationLSCNew digital lockin added to LSC model/screen

I added a lockin to the LSC model, and added it's corresponding control to the LSC screen.  Here's is what I added to the LSC model:


On the left are the froms from the normalized RF PD outputs. Those go into a matrix, whose single row goes into the lockin signal input. The clock output from the lockin goes into the LSC output matrix (last row).

Here is what I added to the LSC master screen:


I also modified the lockin overview screen:


I think this new screen looks a lot cleaner.  Maybe we could start using this one as a template for lockin screens.

  4743   Wed May 18 22:11:31 2011 ranaConfigurationLSCNew digital lockin added to LSC model/screen


 This is OK....but, the input matrix should come from the same place as the regular input matrix: i.e. it should be just another row like CARM, DARM, etc. rather than have its own screen.

Also, I think a nice mod to all the matrices would be if the ORANGE triangle was only visible when there's a signal flowing through it.

  4766   Wed May 25 20:12:55 2011 JamieConfigurationLSCNew digital lockin added to LSC model/screen


This is OK....but, the input matrix should come from the same place as the regular input matrix: i.e. it should be just another row like CARM, DARM, etc. rather than have its own screen.

 You're absolutely right.  That was a brain-fart oversight.  I fixed the model so that the input from the lockin comes from another output row in the RFPD input matrix.  I then fixed the C1LSC medm screen accordingly:


This is obviously much simpler and more straight-forward.

A future improvement would be to modify the DCPD input matrix to be able to route those signals to the lockin as well.  This is actually currently possible since the DCPD input matrix is just a subset of the full input matrix, but it's not available via medm yet.

  4767   Thu May 26 17:10:21 2011 JamieConfigurationLSCNew digital lockin added to LSC model/screen


A future improvement would be to modify the DCPD input matrix to be able to route those signals to the lockin as well.  This is actually currently possible since the DCPD input matrix is just a subset of the full input matrix, but it's not available via medm yet.

 I went ahead and added the lockin output to the DCPD input matrix.


  16252   Wed Jul 21 14:50:23 2021 KojiUpdateSUSNew electronics


Jun 29, 2021 BIO I/F 6 units
Jul 19, 2021 PZT Drivers x2 / QPD Transimedance amp x2


Attachment 1: P_20210629_183950.jpeg
Attachment 2: P_20210719_135938.jpeg
  16281   Tue Aug 17 04:30:35 2021 KojiUpdateSUSNew electronics


Aug 17, 2021 2x ISC Whitening

Delivered 2x Sat Amp board to Todd


Attachment 1: P_20210816_234136.jpg
Attachment 2: P_20210816_235106.jpg
Attachment 3: P_20210816_234220.jpg
  16436   Wed Oct 27 19:34:52 2021 KojiSummaryElectronicsNew electronics racks

1. The rack we cleaned today (came from West Bridge) will be placed between 1X3 and 1X4, right next to 1X4 (after removing the plastic boxes). (Attachment 1)
For easier work at the side of the 1X4, the side panel of the 1X4 should be removed before placing the new rack. Note that this rack is imperial and has 10-32 threads

2. In terms of the other rack for the Y arm, we found the rack in the storage is quite dirty. Anchal pointed out that we have a few racks standing along the Y arm (as the storage of the old VME/Euro card electronics) (Attachments 2/3)
They are not too dirty and also doing nothing there. Let's vacate one of them (the one right next to the optics preparation table). Use this space as a new storage area placing a wire shelving rack for something.

BTW, I thought it is good to have the rack at the vertex side of 1Y1 (as 1Y0?), but the floor has "KEEP OUT" marking. I have no idea why we have this marking. Is this for crane operation??? Does any one know?

Attachment 1: P_20211027_180737.jpg
Attachment 2: P_20211027_180443.jpg
Attachment 3: P_20211027_180408.jpg
Attachment 4: P_20211027_180139.jpg
  16149   Fri May 21 00:05:45 2021 KojiUpdateSUSNew electronics: Sat Amp / Coil Drivers

11 new Satellite Amps were picked up from Downs. 7 more are coming from there. I have one spare unit I made. 1 sat amp has already been used at MC1.

We had 8 HAM-A coil drivers delivered from the assembling company. We also have two coil drivers delivered from Downs (Anchal tested)

Attachment 1: F3CDEF8D-4B1E-42CF-8EFC-EA1278C128EB_1_105_c.jpeg
  16212   Thu Jun 17 22:25:38 2021 KojiUpdateSUSNew electronics: Sat Amp / Coil Drivers

It is a belated report: We received 5 more sat amps on June 4th. (I said 7 more but it was 6 more) So we still have one more sat amp coming from Todd.

- 1 already delivered long ago
- 8 received from Todd -> DeLeone -> Chub. They are in the lab.
- 11 units on May 21st
- 5 units on Jun 4th
Total 1+8+11+5 = 25
1 more unit is coming



11 new Satellite Amps were picked up from Downs. 7 more are coming from there. I have one spare unit I made. 1 sat amp has already been used at MC1.

We had 8 HAM-A coil drivers delivered from the assembling company. We also have two coil drivers delivered from Downs (Anchal tested)


Attachment 1: P_20210604_231028.jpeg
  5815   Fri Nov 4 21:15:38 2011 KatrinUpdateGreen LockingNew fiber coupler (YARM)

63% coupling efficiency into the new fiber collimator (Thorlabs XXXX) and the blue fiber.This should be sufficient for a beat measurement with the PSL laser.

I think the coupling efficiency is not too bad with having no mode matching lenses and no adjustable collimator lens.


252mW in front of the fiber

159 mW fiber output

  15549   Sat Aug 29 22:46:29 2020 gautamUpdateBHDNew homodyne-phase control electronics


The electronics chain used to drive the three elements of the PI PZT on which a mirror is mounted with the intention of controlling the LO phase has been changed, to now use the Trek Mode603 power amplifier instead of the OMC high voltage driver. Attachment #1 shows the new configuration.


The text of Attachment #1 contains most of the details. The main requirement was to map the DAC output voltage range, to something appropriate for the Trek amplifier. The latter applies a 50V/V gain to the signal received on its input pin, and also provides a voltage monitor output which I hooked up to an ADC channel in c1ioo. The gain of the interfacing electronics was chosen to map the full output range of the DAC (-5 to +5 V for a single-ended receiving config in which one pin is always grounded) to 0-2.5 V at the input of the Trek amplifier, so that the effective high voltage drive range is 0-125 V. I don't know what the damage threshold is for the PI PZT, maybe we can go higher. The only recommendation given in the Trek manual is to not exceed +/-12 V on the input jack, so I have configured D2000396 to have a supply voltage of 11.5 V, so that in the event of electronics failure, we still don't exceed this number.

On the electronics bench, I tested the drive chain, and also measured the transfer function, see Attachment #2. Seems reasonable (the Trek amplifier was driving a 3uF capacitive load used to protect the SR785 measurement device from any high voltage, hence the roll-off). The gain of D2000396 was changed from 1/8 to 1/4 after I realized that the DAC full range is only +/- 5 V when the receiving device is single-ended at both input and output. Maybe the next iteration of this curcuit should have differential sending, to preserve the range.


To test the chain, I used the single bounce beam from the ITM, and interfered it with the LO. Clear fringing due to the seismic motion of the ITM (and also LO phase noise) is visible. In this configuration, I drove the PZT mirror in the LO path at a higher frequency, hoping to see the phase modulation in the DCPD output. However, I saw no signal, even when driving the PZT with 50% of the full DAC range. The voltage monitor ADC channel is reporting that the voltage is faithfully being sent to the PZTs, and I measured the capacitance of the PZTs (looked okay), so not sure what is going on here. Needs more investigation.

Update Aug 30 5pm: Turns out the problem here was a flaky elbow connector I used to pipe the high voltage to the PI PZT, it had some kind of flaky contact in it which meant the HV wasn't actually making it to the PZT. I rectified this and was immediately able to see the signal. Played around with the dark fringe Michelson for a while, trying to lock the homodyne phase by generating a dither line, but had no success with a simple loop shape. Probably needs more tuning of the servo shape (some boosts, notches etc) and also the dither/demod settings themselves (frequency, amplitude, post mixer LPF etc). At least the setup can now be worked on interferometrically.

Attachment 1: zetaDrive.pdf
Attachment 2: trekTFs.pdf
  11423   Fri Jul 17 02:46:07 2015 IgnacioUpdateGeneralNew huddle test data for Wilcoxon 731A results

On Thursday, new huddle test data for the Wilcoxon 731A was aquired by Eric. 

The difference between this new data and the previous data, is:

1) We used three accelerometers instead of six this time around.

2) We used a foam box, and clamped cables on the experimental set up as shown in the previous elog, http://nodus.ligo.caltech.edu:8080/40m/11389

I have analyzed the new data. Here I present my results.

The following plot shows the ASD's for the three accelerometers raw outputs as well as their error signals computed using the three cornered hat method,

As before, I computed the mean for the output signals of the accelerometers above as well as their mean self noise to get the following plot


Now, below I compare the new results with the results that I got from the old data, 

Did the enclosure and cable clamping do much? Not really, according to the computed three hat results. Also, notice how much better, even if its a small improvement, we get from using six accelerometers and calculating their self noise by the six cornered hat method.


Now, I moved on to analyzing the same data with Wiener Filtering.

Here are again, the raw outputs, and the self noises of each individual accelerometer calculated using Wiener filtering,

The accelerometer in the Y direction is show a kind of funky signal at low frequncies. Why? Anyways, I calculated the mean of the above signals as I did for the three cornered hat method above to get the following, I also show the means of the signals computed with the old data using wiener filtering,

Is the enclosure really doing much? The Wiener filter that I applied to the huddle test old data gave me a much better, by an order of magnitude better self noise curve. Keep in mind that this was using SIX accelerometers, not THREE as we did this time. I want to REDO the huddle test for the WIlcoxon accelerometers using SIX accelerometers with the improved experimental setup to see what I get.

Finally, I compare the computed self noises above with what the manufacturer gives,


As I expected, the self noise using six accelerometers and Wiener filtering is the best I could work out. The three cornered hat method works out pretty well from 1 to 10 Hz, but the noise is just too much anywhere higher than 10 Hz. The enclosed, clamped, 3 accelerometer wiener filter result is an order of magnitude worse than the six accelerometer wiener filtered result, and two orders of magnitude worse than the three cornered hat method in the 1 to 10 Hz frequency band. 

As I stated, I think we must performed the huddle test with SIX accelerometers and see what kind of results we get.

Attachment 1: selfnoise_allthree_threehat_enclosed.png
Attachment 2: selfnoise_3hat_enclosed_averages.png
Attachment 3: selfnoise_3hat_6hat_enc.png
Attachment 4: miso_wiener_enclosedall.png
Attachment 5: selfnoise_wiener_enclosed.png
Attachment 6: compare_encl.png
  2886   Thu May 6 16:18:37 2010 AlbertoUpdate40m UpgradingNew improved design for the 11MHz photodiode

After munching analytical models, simulations, measurements of photodiodes I think I got a better grasp of what we want from them, and how to get it. For instance I now know that we need a transimpedance of about 5000 V/A if we want them to be shot noise limited for ~mW of light power.

Adding 2-omega and f1/f2 notch filters complicates the issue, forcing to make trade-offs in the choice of the components (i.e., the Q of the notches)

Here's a better improved design of the 11Mhz PD.

Attachment 1: pox11.pdf
  2893   Thu May 6 19:57:26 2010 AlbertoUpdate40m UpgradingNew improved design for the 11MHz photodiode


After munching analytical models, simulations, measurements of photodiodes I think I got a better grasp of what we want from them, and how to get it. For instance I now know that we need a transimpedance of about 5000 V/A if we want them to be shot noise limited for ~mW of light power.

Adding 2-omega and f1/f2 notch filters complicates the issue, forcing to make trade-offs in the choice of the components (i.e., the Q of the notches)

Here's a better improved design of the 11Mhz PD.

 This should be better. It should also have larger resonance width.

Attachment 1: pox11.pdf
  2894   Fri May 7 11:21:49 2010 kojiUpdate40m UpgradingNew improved design for the 11MHz photodiode

How much is the width?


 This should be better. It should also have larger resonance width.


  2896   Fri May 7 18:18:02 2010 AlbertoUpdate40m UpgradingNew improved design for the 11MHz photodiode


How much is the width?


 This should be better. It should also have larger resonance width.


 The transfer function phase drops by 180 degrees in about 2MHz. Is that a good way to measure the width?

  2897   Fri May 7 19:02:27 2010 ranaUpdate40m UpgradingNew improved design for the 11MHz photodiode

To measure the width of a resonance, the standard method is to state the center frequency and the Q. Use the definition of Q from the Wikipedia.

As far as how much phase is OK, you should use the method that we discussed - think about the full closed loop system and try to write down how many things are effected by there being a phase slope around the modulation frequency. You should be able to calculate how this effects the error signal, noise, the loop shape, etc. Then consider what this RFPD will be used for and come up with some requirements.

  8116   Wed Feb 20 18:35:42 2013 JenneUpdateAlignmentNew in-vac alignment procedure

I have updated the vacuum checklist for in vacuum alignment.  Please take a look (https://wiki-40m.ligo.caltech.edu/vent/checklist) and see if I missed anything.  My goal was to make it incredibly step-by-step so there can be no mistakes.

  6969   Thu Jul 12 15:43:07 2012 YaakovUpdateSTACISNew input point, using accelerometers for feedback

 Here's a picture of where I am now inputting signals into the STACIS with the accelerometers (the orange and blue wires): 


I know this is the right point because I could see the geophone signal from these points . By inputting a swept sine signal into this point, I was able to take a transfer function of this first amplifier/filtering circuit board, which will be useful if I need to make my own filter for the STACIS:


I have unplugged the geophones and am inputting a signal from an accelerometer into this point. The accelerometers output a different signal than the geophones, so I am trying to modify the accelerometer signal to be closer to the geophone one. I've lowered the gain on all the pots for the z axis and put in several BNC attenuators to lower the accelerometer signal amplitude.

At the moment, using the accelerometers as feedback makes the platform vibration worse, which will hopefully be solved by some more attenuation or filtering of the accelerometer signal.

  10990   Mon Feb 9 17:23:17 2015 diegoUpdateComputer Scripts / ProgramsNew laptops

I forgot to elog about these ones, my bad... The new/updated laptops are giada, viviana and paola; paola is already in the lab, while giada and viviana are in the control room waiting for a new home. The Pool of Names Wiki page has already been updated to reflect the changes.

  15508   Thu Aug 6 22:57:20 2020 gautamUpdatesafetyNew live HV Supplies

Be aware that there is now a KEPCO HV supply that is energized, sitting on the floor immediately adjacent to the OMC rack, east of the AP table. It is currently set to 100 V DC, and a PI PZT installed on the AP table has its 3 PZTs energized by said supply (via an OMC piezo driver). I will post pictures etc of the work from the last 10 days over the weekend.

  9250   Thu Oct 17 13:40:55 2013 JenneUpdateLSCNew lockin / sensing matrix frequencies

I locked PRMI, and (after fixing the POP QPD situation, noted in elog 9249) took power spectra of all the REFL RFPDs.  It looks like the area above 500 Hz is pretty clean and flat for all the signals, so I'm going to use 560Hz, 562Hz, 564Hz, 566Hz and 568Hz for my 5 sensing matrix frequencies.

Also, I'm not sure what is going on with REFL11, but there's a weird dip between 630 Hz and 660 Hz in both I and Q.  I recentered this guy not too long ago (elog 9218), but it clearly needs some more looking-at.


  9245   Wed Oct 16 03:04:37 2013 JenneUpdateLSCNew lockin / sensing matrix model parts


Still to do:

* Put a little more stuff into the front end so that we get total mag and phase of the sensing matrix element, not just uncalibrated lockin outputs.

 I worked today some more on the new Sensing Matrix situation.  I have added stuff to the CAL model, so that the sensing matrix elements come out calibrated to W/m, with phase in degrees.  The idea is that we can see time series of the calibrated lockin outputs, so that we have minimal post-processing to do, since these are things that will be interesting to look at live.


The first step is to go from I and Q to magnitude and phase.  Each "sensor" (ex. REFL55Q) is demodulated with a lockin part, which outputs sub I and Q channels (so, something like REFL55Q_I and REFL55Q_Q).  We are only interested in the _I component of the lockin.  But, REFL55I also has a _I and _Q.  Again, we only take the _I part.  Now, we have REFL55I_I and REFL55Q_I.  We call these the I and Q components of the sensors (this is exactly what we normally call them, but it can get confusing since the lockins also have _I and _Q before we discard the _Q part).  Now, we want to take these I and Q components, and transform them to a magnitude and phase. After we do that, we want to calibrate the magnitude to "Watts per meter" from "counts sensed per counts driven".  I also converted the phase to degrees, since that's the unit we usually use when talking about the sensing matrices. 

To go from the I and Q components to Mag and Phase, I wrote a little block of c-code, which is in /opt/rtcds/caltech/c1/userapps/release/isc/c1/src/MagPhaseFromIQ.c . Since we can't use the arctan function, I approximated it using equation 17 from Full Quadrant Approximations for the Arctangent Function [Tips and Tricks] from IEEE.  (I used x -> y/x in equation 17, so that I had a 2D situation).  I also have an "if / else if" cascade to determine what quadrant I'm in.  Since the formula in the paper is from [0,pi/2), I just needed to add pi, subtract the answer from pi, or negate the answer to get to the other quadrants.  Also, note that they are using a "normalized" arctan function, so equation 17 is really from [0,1), and you have to remember to multiply by pi/2 on your own.

To get from drive counts to drive meters, I put in an EPICS variable for the optic's actuation constant (ex, PRM's constant can be found in elog 8255).  Right now, we have to transfer the oscillation frequency from the oscillator part's _FREQ variable to a new EPICS variable, but Zach and Joe just today made a new oscillator part that makes it easier to access the frequency and amplitude of the drive within the front end.  See LLO aLog 9139 for details on this new part.  I had trouble compiling with their new part, but once I get that figured out, I won't need to do this transfer of information.  Anyhow, the drive calibration is (optic actuation constant)/[(drive frequency)^2]. 

Then the total calibration of the magnitude is Mag in cts/m = 2 * mag / [(drive amplitude) * (drive calibration)] .  The factor of 2 comes from the fact that the lockin output is a factor of 2 smaller than the true sensing matrix element.  The lower case "mag" in the formula is the output of the c-code. 

After this, there is yet another EPICS variable, to hold the calibration for the photodiode, to get from counts sensed to Watts of power at the actual port.  By "actual port", I mean the true IFO port, taking into account any optical elements between the port and the photodiode, like beam splitters and dumps, or loss from the imperfect reverse isolation of the input Faraday.

The code all compiles and runs fine, although I haven't done any explicit testing yet.

Still to-do for Sensing Matrix:

* Find all of the numbers for all of the EPICS variables.  In particular, I need to get the ratio of the power hitting each photodiode to the power at that port. 

* Write a script to do a burt-restore with all the correct settings, and turn on the dither lines.

* Put the lowpass filters back in the demodulators, now that they have new (shorter) names.

* Try it, and compare with the optickle model, and previous measurements.

* Copy Anamaria's script to look at the error statistics for my measurements.


  9270   Wed Oct 23 19:28:22 2013 JenneUpdateLSCNew lockin / sensing matrix model parts

I have modified the Sensing Matrix I,Q to Mag, Phase library part in the new sensing matrix system.

I had forgotten that in the c-code, I convert from radians to degrees, and so was doing the conversion again in the model.  As it turns out, this gives you a nonsense number.  I removed the multiplication by 180/pi in the model, and just use the output of the c-code, which is already in degrees.

I also put in some "choice" blocks just before the divisions in the calibration section of this library part.  If it's about to divide by zero, divide by one instead.

The last modification so far today was adding the _PHASE_DEG and _MAG_WPERM (watts per meter) channels to a DAQ channels block, so that they are saved.

The RCG was very unhappy with me having 2 channels, with no data rate after them (doing this is supposed to imply that both should be saved at the default data rate), however after I put in "2048", it was happy.  The symptom was a little tricky:  The channel names in Dataviewer showed up red, even though the model compiles and runs.  An indicator that you have a problem is a note in the model's "GDS" screen (the details screen that you can click to from the CDS front end overview screen).  The channel name is "C1:FEC-50_MSGDAQ" (where the number 50 is specific to the c1cal model).  After restarting the model, but before restarting the framebuilder's daqd process, this channel said "Error reading DAQ file!", rather than the date and time of the last successful read.   At this point, before restarting the daqd process on the framebuilder, all of the fb statuses are green and good.  However, after restarting the daqd process on the framebuilder, I got status "0x2000".  Anyhow, after trying many different things, I determined that I could have 1 channel, without a specified rate, but if I wanted more than one channel, I needed to specify the rate for both.

  9227   Wed Oct 9 22:05:55 2013 JenneUpdateLSCNew lockin / sensing matrix screens

After finishing up working on the models for today, I made corresponding screens.  

The new Sensing Matrix (and lockin) overview screen is accessible from the sitemap:  LSC -> Sensing Matrix. 

From there, you have the oscillators, input matrices (one per degree of freedom), output matrix, and the lockin modules themselves.  You can either look at several PDs for one degree of freedom (ex. there is a screen for all the AS RFPDs, demodulated for the DARM oscillation), or all the degrees of freedom for a single PD (ex. how are all the degrees of freedom seen in AS55Q?).  The LSC screen has been updated to match - now you see 5 oscillator readbacks, and a larger output matrix.  There is a button for the Sensing Matrix overview screen, and if you click on the cartoons of the oscillators, it'll take you to the oscillators screen.

Still to do:

* Decide what 5 frequencies to use for excitation.

* Put the bandpass and lowpass filters into the lockin modules.

* Put matching notch filters into each LSC servo.

* Re-write the sensing matrix scripts.

* Put a little more stuff into the front end so that we get total mag and phase of the sensing matrix element, not just uncalibrated lockin outputs.

  9234   Fri Oct 11 17:37:08 2013 JenneUpdateLSCNew lockin / sensing matrix screens


Still to do:

* Decide what 5 frequencies to use for excitation.

* Put the bandpass and lowpass filters into the lockin modules.

* Put a little more stuff into the front end so that we get total mag and phase of the sensing matrix element, not just uncalibrated lockin outputs.

 I worked on some of these "to-do" things today for the new sensing matrix setup.  I chose several frequencies around 90 Hz for my measurements.  This was an area (while PRMI was locked with REFL 165 I&Q, and all 4 REFL PDs had their whitening on) there was a pretty wide clean space in the noise spectrum.

I put bandpass filters into the _SIG banks of the lockin modules, and lowpass filters into the _I banks.  However, when I loaded the new filter coefficients, it looks like not all of them are showing up in the screens.  I'm a little confused as to why.  They are still there if I close and re-open Foton, so I think I really put them in.

Also, I don't think that I'm successfully getting any signal from the LSC model into the new lockin modules on the CAL model.  I'm not sure if this is to do with the fact that I added 32 more IPC connections the other day.  I've emailed Jamie to ask whether or not we may have hit some limit.

I also tried testing out a small bit of c-code for the calibration of the lockin outputs.  It seems as though I cannot do an arctangent in the front end.  When I compile the c1tst model, and start it up, if I have an "atan2" in the code, it tells me "No Sync".  However, if I remove that line of c-code, the model compiles fine (which it did in the case with the arctan), and the model runs just fine (which it doesn't with the arctan).  My backup plan is to include a Taylor expansion for the arctangent in some c-code.

  9236   Sun Oct 13 13:29:09 2013 ranaUpdateLSCNew lockin / sensing matrix screens

  I think that we always drive above the UGF for sensing matrix measurements since we like to put notches in the servo. In principle, we could drive within the control band and then take out the effect by measuring the control signal and undoing the gain in the digital filters. But that seems pretty complicated for any MIMO system.

  9237   Mon Oct 14 17:40:15 2013 JenneUpdateLSCNew lockin / sensing matrix screens

 Hmmmm, yup.  I forgot to pay attention to what the UGFs of our LSC loops are when I was picking a low-noise region.  Since they're (currently, at least) around 100Hz, I want to find a frequency in the few hundred Hz region.  Masayuki has the IFO right now for ALS diagnostics, so I'll pick new frequencies later.   If we decide to omit the bandpass filters, it's even easier to change frequencies on the fly (although we'll always still have to make the servo notch filters match).

  9239   Mon Oct 14 21:12:35 2013 JenneUpdateLSCNew lockin / sensing matrix screens

After staring and thinking, I remembered that there is a limit to the number of characters that a channel name can have.  So, I removed the "_LOCKIN" part of the names, and recompiled, and everything seems to work.  I modified the screens that I had made, and they show all the appropriate things now.  

The symptoms were that the numbers in the filter banks (for example, INMON) were white with the usual black background.  The numbers are supposed to be green with a black background.  After I recompiled, all the numbers were green.

This also means I need to re-put in the low pass filters. 

  13789   Wed Apr 25 19:09:37 2018 gautamConfigurationALSNew look EX Fiber coupling


I implemented most of the things outlined in my previous elog. Implementing the a la mode solution after including all lenses, I managed to achieve >90% mode-matching into the fiber. Power monitor PD has not been re-installed yet, neither has the bracket I removed. The polarization monitoring setup on the PSL table has now been hooked up to the EX fiber, let's see how it does overnight. All quoted power measurements in this elog were made with the Ophir power meter (filter off).


Attachment #1 shows the implemented MM solution. I did not include the PBS substrate in the calculation, maybe that will help a little.

Attachment #2 shows the new layout. The beam is a little low on the PBS and HWP - I will swap these out to mounts with slightly lower height, that should improve the situation a little. There is no evidence of clipping, and the beam clears all edges by at least 3 beam diameters.

Attachments #3 and #4 show the EX fiber before and after cleaning respectively. Seems like the cleaning was successful.

Attachment #5 shows the beam incident on the coupler with on an IR card. This beam only goes through a QWP, lens, BS and 45 degree steering mirror, so I'm not sure what's responsible for the large halo around the main beam. There is significant power in the halo too - I measured 25mW right before the coupler, but if I use an iris to try and cut off the halo, the power is measured to be ~19mW.

Alignment Procedure:

  • Connect spare fiber such that I can monitor coupled power (minus fiber losses and joint loss) at EX table.
  • Use Fluke fault analyzer to align input and collimator modes coarsely.
  • Monitored coupled power continuously using Fiber Power Meter (although MM calculations were made with Ophir, this was more convenient for "Live" viewing).
  • Tweaked one available steering mirror and K6XS axes to maximize coupled power. 
  • Tweaked lens positions slightly to see if significant improvement could be made.
  • After optimizing, I measured 17.1mW coming out of the EX fiber at the PSL table. As mentioned earlier, the input power is tricky to measure given the large amount of junk light around the main mode. But I measured 18.6 mW after the iris. So this is ~95%. In any case, safe to say that we are waaaay better than the previous situation of 380uW out of 1.9mW. 
  • Added PBS and HWP to cut the incident power to 1.6mW. I measured 1.2mW on the PSL table. Probably adding the PBS screwed up the MM a bit, to be tweaked tomorrow. 
  • I had moved the Green shutter a bit during this work - as a result, the Green REFL was not making it back to the REFL PD. I remedied this, and EX Green TEM00 mode was locked to the arm. GTRX of ~0.4 was recovered, which is around the number I'm used to seeing.
Attachment 1: EX_fiber_MM.pdf
Attachment 2: IMG_6977.JPG
Attachment 3: IMG_6972.JPG
Attachment 4: IMG_6974.JPG
Attachment 5: IMG_6976.JPG
  13791   Thu Apr 26 11:24:50 2018 gautamConfigurationALSNew look EX Fiber coupling - pol stability

Here is a first look at the overnight stability. For the temperature, I used the calibration I found in the old psl database file, seems to give sensible results. It's only 15 hours of data plotted, so we don't see the full 24 hour temperature swing, but I think it is safe to say that for the EX fiber, the dominant cause of the "waveplate effect" is not in fact temperature drift. The polarization extinction is still better than 10dB in the entire period of observation though... I'm going to push ahead with a beat spectrum measurement, though there is room for improvement in the input coupling alignment to fiber special axes.

The apparent increase in these plots towards the end of the 15 hour period is because the lights on the PSL table were switched on.

Annoyingly, it seems like the PSL NPRO channels (which I have hijacked to do this test) do not have minute trend data directly accessible from NDS2. Not sure whether this is an NDS2 problem, or something missing in the way the channels are setup with Acromag. Probably the former, as I am able to generate minute trend plots with dataviewer. I forget whether this is the same as the infamous minute trend problem. Second trend data is available though, and is what I used to make these plots...

Attachment 1: polStab.pdf
ELOG V3.1.3-