40m QIL Cryo_Lab CTN SUS_Lab TCS_Lab OMC_Lab CRIME_Lab FEA ENG_Labs OptContFac Mariner WBEEShop
  ATF eLog, Page 42 of 56  Not logged in ELOG logo
ID Date Author Type Category Subject
  743   Wed Apr 28 19:07:07 2010 FrankLab InfrastructureGeneralmarking remaining holes

Quote:

I finally found a Sharpie that is not red or black; it is blue. I am happy to do the marking tomorrow morning (I am going to the 40m after class). If someone wants to do it this evening, the blue Sharpie is at my desk by the phone.

 i started marking the remaining ones using a GREEN dry erase marker we had in the lab. As the leaks are hard to see even if marked (the big ones were the ones on top of the ducts), i marked them with green arrows which point into the direction and which one can see without climbing. Maybe someone could check if i missed one...

  742   Wed Apr 28 15:39:45 2010 ZachLab InfrastructureGeneralmarking remaining holes

I finally found a Sharpie that is not red or black; it is blue. I am happy to do the marking tomorrow morning (I am going to the 40m after class). If someone wants to do it this evening, the blue Sharpie is at my desk by the phone.

  741   Wed Apr 28 15:28:04 2010 ZachMiscGeneralWhere is the camera??

Does this mean that the camera is gone? If you have the camera, please put it back or tell me so that I can come get it from you. Thanks.

Quote:

 I have been chosen, due in part to my particular altitudinal disposition, to document the sealing work that has recently been done in the lab. I am at a loss for how to do that without a camera.

Despite its obvious second capacity as a paperweight, and its stylish accentuation of your workspace's unparalleled charm notwithstanding,

PLEASE RETURN THE CAMERA TO THE DRAWER WHEN YOU ARE DONE USING IT!! 

That is all.

 

  740   Wed Apr 28 14:57:14 2010 ranaLab InfrastructureGenerallab cleanliness - latest particle counts

make new circles using BLUE markers to mark the remaining holes

  739   Wed Apr 28 13:21:11 2010 AlastairLab InfrastructureGenerallab cleanliness - latest particle counts

 

I've swept, mopped and wiped some of the surfaces (desks, sink, monitors and a few other easy to reach flat surfaces).  I also swept and mopped the outer area and threw out all the old shoe covers.  I'm sure it could do with having a better cleaning of other surfaces like the racks etc.  We should schedule that for after the workmen finish up down there 

  738   Wed Apr 28 11:19:36 2010 AlastairLab InfrastructureGenerallab cleanliness - latest particle counts

Quote:

really bad 

...

they tried to fix the leaks and fixed a lot of small ones but unfortunately the didn't fix the large ones. I checked five of the large ones and four of them still exist...
The general cleanliness is very bad, especially since a couple of month. You don't have to be an expert to see how bad it is. For some people it seems to be normal to step over the black (non-sticky anymore) mats and not to remove the (obviously) dirty and unfunctional top layer. And keeping the HEPAs on the 35W table off since a week(!) (or longer?)  doesn't help much to keep this very sensitive area clean...

Hey Frank, do we know when they're planning on being done down here?  The guy I spoke to said that they'd re-check for leaks once they turned the air back on.

Definitely needs cleaned, but I was hoping they would be done this week and we could clean after they had gone.  If it's going to take longer than that maybe we should arrange an intermediate cleaning.

There are some guys in the lab this morning switching out the smoke detectors for the fire system so I'll let them into the labs they need in.  They're turning off the air for five minutes to do this but I assume this isn't a problem since it's been on and off this week already.

 Does anyone know why the spectrum analyser is on it's side on the floor?

  737   Wed Apr 28 10:16:09 2010 FrankLab InfrastructureGenerallab cleanliness - latest particle counts

really bad 

AdhikariLab_data_repair.png...

they tried to fix the leaks and fixed a lot of small ones but unfortunately the didn't fix the large ones. I checked five of the large ones and four of them still exist...
The general cleanliness is very bad, especially since a couple of month. You don't have to be an expert to see how bad it is. For some people it seems to be normal to step over the black (non-sticky anymore) mats and not to remove the (obviously) dirty and unfunctional top layer. And keeping the HEPAs on the 35W table off since a week(!) (or longer?)  doesn't help much to keep this very sensitive area clean...

  736   Wed Apr 28 09:24:01 2010 AidanComputingfubarelog craziness - test to try and crash elog

 - apparently PDFs work okay. Frank is reporting continual crashes from last night when uploading a graph of the particle counter in different formats from Firefox in Windows.

Attachment 1: 40m_figure_ETM.pdf
40m_figure_ETM.pdf
  735   Tue Apr 27 11:46:30 2010 ZachMiscGeneralWhere is the camera??

 I have been chosen, due in part to my particular altitudinal disposition, to document the sealing work that has recently been done in the lab. I am at a loss for how to do that without a camera.

Despite its obvious second capacity as a paperweight, and its stylish accentuation of your workspace's unparalleled charm notwithstanding,

PLEASE RETURN THE CAMERA TO THE DRAWER WHEN YOU ARE DONE USING IT!! 

That is all.

  734   Fri Apr 23 17:20:34 2010 ZachElectronicsGYRORFPD circuit

 I finished stuffing our first RFPD board with everything we want (for now) this afternoon. This one will be used for one of the transmission PDs, so I tuned it to 95 MHz. The transfer function looked a little funny (it was oscillating at ~130 MHz), but Rich thinks this will go away once the diode is installed.

On Monday, I'll install the diode, do some more stuff with the test input, and then we can try some optical demod funny business.

  733   Tue Apr 20 22:33:59 2010 FrankComputingDAQfb0 up again and working

made all changes and fb0 is now up again and working. I didn't check everything in detail but all processes are running. I got data using dataviewer and the framebuilder is writing data to the disk. Didn't test DTT but testpoint manager process is running, awg too.

There are two models running on fb0 right now, ATF and PSL. ATF is running on cpu1, PSL on cpu2. the OS is running on cpu 0+3.
We still have to make slightly changes to the ATF model in order to specify the card id's, node id's and cpu, so that everyone can see which parameters we have to set or where we have to be careful when changing things. I will post a detailed example later...

  732   Tue Apr 20 19:54:24 2010 FrankComputingDAQcard identification

As we now have two expansion chassis connected to fb0 we have more cards in our device list

[root@fb0 etc]# /sbin/lspci -v | grep 31
        Subsystem: PLX Technology, Inc. Unknown device 3101
        Subsystem: PLX Technology, Inc. Unknown device 3120
        Subsystem: PLX Technology, Inc. Unknown device 3101
        Subsystem: PLX Technology, Inc. Unknown device 3101
        Subsystem: PLX Technology, Inc. Unknown device 3101
        Subsystem: PLX Technology, Inc. Unknown device 3120

"Unknown device 3101" is a ADC card, "Unknown device 3120" is a DAQ card.

So we start with 3101, 3120, which is the old chassis (only two cards). So the first adc and dac for the ATF are still id=0 and therefore nothing should change in that model.

The cards for the PSL are then id=1..3 for the ADC cards and id=1 for the DAC card.

  731   Tue Apr 20 18:54:18 2010 FrankComputingDAQDAQ odyssey - part 2

welcome to part 2: i forgot a couple of things in part 1 which i will post here now before we go on with the installation of a second model on the same frontend.

As explained yesterday, the gds configuration of the systems sharing the same cvs is stored in /caltech/target/gds/params. The testpoints are created and written to a file named tpchn_Cx.par, where x equals the gds_node_id in the model. This filename has to be added to /etc/xinetd.d/chnconf, which looks like this

service chnconf
{
        disable                 = no
        type                    = RPC
        rpc_version             = 2-3
        socket_type             = stream
        protocol                = tcp
        wait                    = yes
        user                    = root
        server                  = /apps/Linux/gds/bin/chnconfd
        env                     = HOME=/cvs/cds/caltech/target/gds
        server_args             = /cvs/cds/caltech/target/gds/param/tpchn_C2.par
}

The information (ip address and ports) about the services was configured in /cvs/cds/caltech/target/gds/param/diag_Cx.conf, where x was abritrary, but independent for each system!

&nds * *  10.0.0.12 8088 *
&chn * *  10.0.0.12 822087685 1
&leap * * 10.0.0.12 822087686 1
&ntp * *  10.0.0.12 * *
&err 0 *  10.0.0.12 5353 *

This file has to be added in /etc/xinetd.d/diagconf, which looks like this

service diagconf
{
        disable                 = no
        port                    = 5355
        socket_type             = dgram
        protocol                = udp
        wait                    = yes
        user                    = root
        passenv                 = PATH
        server                  = /apps/Linux/gds/bin/diagconfd
        env                     = HOME=/cvs/cds/caltech/target/gds
        server_args             = /cvs/cds/caltech/target/gds/param/diag_C3.conf
}


After running the script to start the frontend code we can check if everything is running by using the diag -i command, which gives us a list of all the processes actually running like ntp, nds, awg and the testpoint manager etc. If they don't show up something is wrong with the configuration. S
tarting awg and tpman on the machine manually could give some hints

sudo /cvs/cds/caltech/target/gds/bin/awgtpman -s psl -4
64 kHz system
Spawn testpoint manager

what we see is that the testpoint manager doesn't start and is waiting for something and after 10s or so we get an error message. The problem is the network configuration. The reason why we had to move to an isolated network was the broadcasting for the gds stuff. So we moved our second machine to a new subnetwork. But we still share the same /cvs directory. Here we have the testpoint.par file which only exists once for all testpoint managers (hard coded). This file contains the following in our example:

[L-node0]
hostname=10.0.1.10
system=atf

[L-node1]
hostname=10.0.0.12
system=psl

 

The problem is now that the code tries to start the manager by browsing

But even if everything is right we still have a problem which shows up if we wanna stop the code using the kill script:

[controls@fb2 param]$ killpsl
CA.Client.Exception...............................................
    Warning: "Identical process variable names on multiple servers"
    Context: "Channel: "C3:PSL-GENERIC_DOF2_Name02", Connecting to: fb2:5064, Ignored: 10.0.1.13:5064"
    Source File: ../cac.cpp line 1224
    Current Time: Tue Apr 20 2010 19:02:46.161552000
..................................................................
CA.Client.Exception...............................................
    Warning: "Identical process variable names on multiple servers"
    Context: "Channel: "C3:PSL-GENERIC_DOF2_Name04", Connecting to: fb2:5064, Ignored: 10.0.1.13:5064"
    Source File: ../cac.cpp line 1224
    errlog = 2370 messages were discarded

The problem is the network configuration. The reason why we had to move to an isolated network was the broadcasting for the gds stuff. So we moved our second machine to a new subnetwork. But we still share the same /cvs directory. Here we have the testpoint.par file which only exists once for all testpoint managers (hard coded). Thsi file contains the following in our example:

[L-node0]
hostname=10.0.1.10
system=atf

[L-node1]
hostname=10.0.0.12
system=psl

the problem now is that we can't start part of the services due to a timeout when trying to find the machines configured in that file. We don't see the other IP and so we get a timeout without starting the local one. This can be fixed by adding a second interface which is in this network WITHOUT connecting it(!). This is very important as we are not allowed to broadcast packets into the other network !!

If we do this we then can run everything. Now we get in trouble if we wanna stop the frontend code using the kill script. If we do so we get the following:

[controls@fb2 param]$ killpsl
CA.Client.Exception...............................................
    Warning: "Identical process variable names on multiple servers"
    Context: "Channel: "C3:PSL-GENERIC_DOF2_Name03", Connecting to: fb2:5064, Ignored: 10.0.1.13:5064"
    Source File: ../cac.cpp line 1224
    Current Time: Tue Apr 20 2010 19:15:18.18726000
..................................................................
CA.Client.Exception...............................................
    Warning: "Identical process variable names on multiple servers"
    Context: "Channel: "C3:PSL-GENERIC_DOF2_Name04", Connecting to: fb2:5064, Ignored: 10.0.1.13:5064"
    Source File: ../cac.cpp line 1224
errlog = 354 messages were discarded
CA.Client.Exception...............................................
    Warning: "Identical process variable names on multiple servers"
    Context: "Channel: "C3:PSL-GENERIC_DOF6_Name01", Connecting to: fb2:5064, Ignored: 10.0.1.13:5064"
    Source File: ../cac.cpp line 1224
    Current Time: Tue Apr 20 2010 19:15:18.21537000

The reason is that we have now two interfaces on the same machine which gives us the "Identical process variable names on multiple servers" error message from the EPICS part. This prevents us from stopping the code. The only way to stop it is to manually kill the processes.

This however can be fixed by making a manual entry for two environmental variables:

EPICS_CA_ADDR_LIST="10.0.x.x"
EPICS_CA_AUTO_ADDR_LIST="NO"

using the local ip address for EPICS_CA_ADDR_LIST which tells EPICS that there is only one Channel Access Server which is our local machine and nothing else.

After adding those everything is fine and the second frontend is working as usual. Of cause we have to make all the changes for the first frontend too, because this is not working anymore since we edited the config files for awg, tptman etc....

part3 of the odyssey will describe why our second frontend computer doesn't work and how we managed to run a second model on fb0 using an additional expansion chassis connected via fiber to the PSL lab.

 

 

  730   Mon Apr 19 19:11:31 2010 FrankComputingDAQfront-end down due to major software changes

fb0 is not working until tomorrow due to major changes in the configuration to get more then one model running at the same time...

  729   Mon Apr 19 19:09:42 2010 FrankComputingDAQtodays DAQ odyssey - part 1

when we started last week setting up a second fronend i thought it might be simple as making another copy of the main disk, changing some config files and here we go - what alex and i learned is that it is way more complicated with a touch of impossible at all. but lets get started from the beginning:

the idea was to set up a second RT frontend computer with it's own framebuilder, either in the same network or a different subnetwork. The reason why we should have seperate framebuilders is that if we have only one and the first (which whatever we define as the first) of the frontends is down, the whole thing is down. So having more then one model running on different machines, the one which we define as the "main" or first one has to be alive, at all times. If not the others don't work anymore. 

Trying to setting it up with independent framebuilders in the same network is impossible due to broadcast messages on the network prohibiting both working at the same time and still using tools like DTT, which listen only to one broadcasting in the network. The minimum requirement is to have physically seperate networks.

Ok, thats fine with us, we decided to split our networks into seperate subnetworks anyway, but then we can't use the existing workstations and the installed tools for more than one network due to the broadcasting stuff. Using the same workstations requires to log into the corresponding frontend/framebuilder and start all tools localy, which is not nice but still works.


Said this we decided to set everything up like that an the next thing we realized is that the stuff we have currently installed uses a the cvs-stuff mounted from one central source. But the frontend code we had was not designed for that, e.g. important parameters are not set in the matlab model and main configuration files are simply overwritten when compiling one of the frontend codes. So we had to add a couple of things in the matlab file, like the gds_node_id. An example of current cdsparameters are:

site=C3
rate=64K
dcuid=10
gds_node_id=2
shmem_daq=1
specific_cpu=3

We had to hack plenty of things which i can't remember all but e.g. we had to add the right node ID in the testpoint.par file in /opt/apps/Linux/gds/param/ as "L-node" - yes we have to use LHO not Caltech here , e.g

[L-nodex]  (here x=gds_node_id of atf model)
hostname=ip of frontend running atf model
system=atf

[L-nodez] (here y=gds_node_id of psl model)
hostname=ip of frontend running psl model
system=psl

the testpoints are created and written to a file named tpchn_Cx.par, where x equals the gds_node_id again, so a model in ifo=C1 and node-id=2 creates a file tpchn_C2.par !!! So this C2 does not correspond to the IFO set in the model. So e.g. using two different models, IFO=C2 and C3, both running on different frontends (!) but starting with node-id=1 (if you don't specify it in the model default is 1) overwrites the one from the other model each time the model is recompiled !!!! So be carefull. Also a link named tpchn_Lx.par has to point to tpchn_Cx.par (the LHO thing again).... this file has to be also added to the list in the fb master file...

the gds stuff is configured in diag_Cx.conf, x is abritrary, but independent for each system. It looks like:

&nds * *  10.0.1.10 8088 *
&chn * *  10.0.1.10 822087685 1
&leap * * 10.0.1.10 822087686 1
&ntp * *  10.0.1.10 * *
&err 0 *  10.0.1.10 5353 *

containing the ip address for the corresponding machine for all the services.

Same for AWG, which setting can be found in awg.par (again, use LHO(!):

[L1-awg0]
hostname=10.0.1.10

at the end it didn't work because the second frontend computer, even if it is almost identical (it's the same identical model, but a slightly newer version of the mainboard/bios) which is not capable of running the RTcore in realtime.  So, this is the end of part 1 of this odyssey, having only one computer where we can run stuff on which brought us to the point where we had to use the same machine (fb0) for both models, but read part 2 of this odissey why it took another four hours to get it (basically) work, which will be posted soon.....

 

 

  728   Sun Apr 18 18:34:50 2010 FrankLab InfrastructureGeneralrouter keeps diconnecting, backup connection installed

the router keeps disconnecting, so i've set up a second, backup connection until we fix the problem. fb0 is now connected directly to the outside world via eth1.

131.215.114.220

As we get a dynamic IP for this interface the address might change in the future...

  727   Sat Apr 17 19:05:50 2010 FrankLab InfrastructureGeneralrouter problems

since a couple of days we have a lot of trouble with our router. we have to power cycle it very often, the last days at least once per day.

As Alex and i are working on the RT frontend stuff right now we have to login very often from outside to change configurations, scripts etc to make it work. Right now we are not able to run a second RT system in parallel, alex tries to fix this.

  726   Wed Apr 14 16:00:56 2010 DmassLaserDoublingBoth MZ and ISS locked

Quote:

Dmass and Koji

Last night we engaged the MZ and the ISS paths with the analog servos.

When I went to the lab, the MZ was locking but the ISS was oscillating at around 70kHz.
We reduced the gain of the last stage by a factor of 3, the oscillation was removed.

Dmass planned a comprehensive set of the measurements and is expected to reveal it on the e-log.

 These are the measurements I have planned, in order:

  • Look @ green difference versus IR difference on a scope, use the Lissajous figure to calibrate the phase response
  • Take Spectra of the IR and Green difference (now calibrated to phase) with the MZ locked and free, and see if the phase in the MZ locked state changes with ISS on/off
    - (The green difference / green phase is my out of loop measurement of the IR phase - which I am locking - so I should be able to infer whether or not I am seeing excess noise in the green. I can figure out whether it is explained by the known sensing noise later)
  • Do a series of four arm blocked measurements where I use one IR PD to do ISS, use the other as an OL PD, and then compare this to the green PDs (which are also OL), and see if I see excess intensity noise
  • Consider whether or not I want better phase numbers closer to the UGF of the Mach Zehnder - PZT system. If I do, and I think I can win by doing some subtraction - AC couple into the DAQ (with SR560s), and then just record those and apply the existing frequency domain subtraction algorithm.
  • Think about what exactly I should do for trying to get phenomenological transfer functions of Temperature / RIN into phase noise. (I still need to doodle out a setup here)
  725   Tue Apr 13 15:32:51 2010 KojiLaserDoublingBoth MZ and ISS locked

Dmass and Koji

Last night we engaged the MZ and the ISS paths with the analog servos.

When I went to the lab, the MZ was locking but the ISS was oscillating at around 70kHz.
We reduced the gain of the last stage by a factor of 3, the oscillation was removed.

Dmass planned a comprehensive set of the measurements and is expected to reveal it on the e-log.

  724   Tue Apr 13 00:19:00 2010 Mott, FrankComputingDAQfb0 boot disk copies

Alex and I made four copies of the master boot disk of the fronend computer. I used one of those disks for the PSl frontend computer i'm currently setting up.
So we have three spares now, which we keep in our lab and which can be used to set up new frontends or as a backup in the case of fatal failure (as the one happened some weeks ago).
We will also create a mirror on fb0 the next days to reduce the risk such a failure.

  723   Fri Apr 9 21:19:33 2010 FrankComputingDAQfb0 online again

i changed the order of the drives. Now sda/sdb are the boot drives (mirrored), sdc for full data and sdd for trend data.

Added four more disks to fb0 in order to speed up the copy process. As sda is a spare disk from alex this drive is not identical with sdb, so i don't know if we can create a mirror.
I think we should create the mirror with two identical drives in order to avoid problems. So i copied everything to sdb already and i will copy the content of sdb to the other four disks.
Two them we will keep as a backup, the other two will be the boot disks for the second RT system for peters lab.

 

  722   Fri Apr 9 11:35:56 2010 MottLaserISSfb0 error

 

 fb0 is going down for a little while so that we can backup the boot drive and raid it.

Process should take 1-2 hours, assuming no problems...

  721   Fri Apr 9 11:26:08 2010 MottLab InfrastructureGeneralGPIB Controllers

The 5 new GPIB controllers are in the lab.  We are ordering some WLAN bridges (the ones that are in use at the 40m are no longer sold, so we will have to find an appropriate replacement).  We should also find/order some power strips that we can ziptie to the carts, since both the GPIB and WLAN bridges need to be powered.

  720   Wed Apr 7 21:29:48 2010 DmassLaserDoublingMZ lock

I kidnapped Mott and was working on closing the ISS loop, but saw some funny things which I didn't understand.

  • We saw a strange rail to rail flipping of ISS err, and I traced it upstream, eventually to the ISS PD box. I somehow was causing the ISS PD box output to flip rail to rail for the channel which I didn't have plugged into my circuit. I need to write down the connection states, and understanding this may be immediately clear.
  • With one arm blocked, and the box off, there were these ~3Hz glitches in the PDs for the MZ. I believe the problem to be downstream of the PMC. I tried to close the ISS loop, but am unsure where I was going wrong. I will tackle this again later.
  718   Wed Apr 7 19:12:47 2010 ZachLaserGYROY1S reflectivities

 This morning, I realigned the CW beam path through the AOM and then into the cavity. I was able to isolate the TEM00 to some decent degree, but there is still a bunch of higher order crap visible (likely due to the fact that we are no longer using the optimum modulation frequency of ~33 MHz---see Alastair's previous post).

In doing so, I was reminded of the issue we have regarding the reflectivities of the (supposedly Y1S) curved mirrors we have in the cavity at the moment. A few weeks ago, Rana, Alastair and I measured the transmission through these to be MUCH higher than they should be. As a result, the impedance matching of the cavity is piss poor.

This afternoon, I measured T for the 9-m Y1Ss that we ordered at the same time. I got T ~ 5e-5 at 45 degrees, which is consistent with Mott's measurement on the wiki. So, either the 6-m mirrors were different or we screwed them up somehow. Our original plan was to use the 9-m ones, so we might as well stick those in and see if our coupling improves. Also, we can start thinking about modematching (not yet, not yet..).

 

  717   Tue Apr 6 21:32:42 2010 FrankComputingGeneralspare hard disks

got 20 250GB hard disks today (same as the ones we use already in both the frontend and the second framebuilder / fileserver). There is already a spare disk in the frontend which (for unknown reasons) we don't use for a simple mirror of the main disk (as we do it in the other computer already) So we should create a simple raid and use that disk for it. Before we do that we should re-arrange the order as that disk is i think sdc, sda is the boot disk, sdb full frames and sdd trend data. So it would be nice to have sda/sdb the raid and then sdc+sdd the data.

  716   Tue Apr 6 21:06:21 2010 FrankMiscPulserdiode damage tests

Rich and me did some brainstorming this afternoon to identify possible parameters we wanna measure during/after pulsing the DUT


1.  Dark Current and Noise (can be done using the same high sensitive amplifier)
2.  Camera for physical damage
3.  Scatter (can be done with camera)
4.  I/V curve (including zener breakdown)
5.  Temperature (monitoring, to not destroy the device due to too high repetition rates of the pulses)
6.  Responsivity (or QE), relative changes
7.  Internal capacitance and resistance

  715   Tue Apr 6 11:51:15 2010 KojiLaserDoublingMZ lock

Dmass and Koji

Last night we worked on the MZ lock for the doubling experiment.
Dmass made a custom circuit for sum/diff and servoing for the MZ locking.
However it did not lock the MZ when I came into the room.

After some modification of the servo filter, we eventually succeeded to lock it.

Moral of the story:
All of the servo systems should have this kind of response analysis
so that we can easily improve the servo design and can analyze noises from various noise injection points.


1) Measured the PZT response.

The PZT driver has the dewhitening stages with two pairs fo 1Hz single pole / 10Hz single zero. We put 7.3Vpp@0.5Hz to the PZT driver input and saw a complete single fringe wrapping. This means that the PZT response is 0.43 rad/V@0.5Hz. ==> DC gain is 0.54

2) Measured the MZ response.

The amplitude of the MZ fringe was measured at the error point (after the diff amp for the 2 IR-PDs). It was 18.5Vpp. This means the slope at the operating point is 9.25 V/rad.

3) Measured the sevo filter response.

The swept sine signal was injected from the IR PD input, while the TF was measured from the error point to the PZT driving output. It shows +24dB@1Hz and Dmass knew that there is a single pole @0.6Hz. ==> DC gain is 31.


Responses of the components are shown in the first plot. The combined openloop tf is shown in the second plot (BLUE)

It turned out that the gain is too small by a factor of 20~30 despite we only have the room to increase the gain by 5.5.

Thus we decided to move the cut off of the filter from 0.6Hz to 16Hz. Then the servo was expected to be unconditionally stable and the UGF is pushed up ~100Hz, including the increase of the gain by 5.5. The modified openloop tf is shown in the second plot (RED)

Once the servo was modified, it immediately locked. Yeeeeah!

Attachment 1: response.png
response.png
Attachment 2: oltf.png
oltf.png
  714   Mon Apr 5 14:46:05 2010 AlastairLaserGYROCCW locking

I've realigned the CCW mode and it is now locking reasonably.  The cavity had become misaligned and I had to adjust it to get it back on resonance.  I then swept the laser and maximised the peaks in transmission.  Next I put the PD back in for reflection locking.  I had to replace the mirror mounts with lens mounts because of the lack of room.  I adjusted the PD position to get maximum DC power, and then plugged it back into the PDH box.  We are getting dips that are approx 50% in voltage.  I couldn't get a decent error signal after the mixer until I reduced the sideband frequency (it's at 9MHz just now) but at the lower frequency we do get an error signal.  It's now locking reasonably but needs more work on the servo settings to get back to where we were before.

  713   Fri Apr 2 19:54:27 2010 AlastairLaserGYROBox

A few steps forward and a few back.  We now have the box over the gyro.  I drilled the holes for the input and output beams and it is cleaned.  However there were a few things in the way of getting it in place.  

Firstly there were some parts we realised we would need to move - the AOM and the PD for the CCW beam.  In order for us to be able to move the AOM it also had to go sideways a little so it wouldn't foul one of the mirrors.  This meant moving basically all parts - curved mirror, iris, AOM, mirror, lens, polarizing beam splitter and the mirror that directs the beam into the faraday.  I've not set up the PD yet.

Next I had to move the EOM slightly so that the cable would fit.  This meant moving the mirror before it, a couple of wave plates, the polarizing beam splitter after it and also the mirror on the corner of the bench before the mode matching telescope.

I've started realigning things. The parts are aligned up to where the beam splits for the two paths.  I've also got the AOM aligned and maximized the power for the 1st order on the way through (not on the way back yet) and have a diffraction efficiency of 76%.

Attachment 1: DSC03070.JPG
DSC03070.JPG
  712   Tue Mar 30 16:44:20 2010 MottLaserISSfb0 error

 

 Alex replaced the drive in fb0 and it should now be back up and running.

I would like to propose that we buy another hard drive for fb0 and either make a static copy of the boot disk, so we can just swap the drive in ourselves if this one fails, or raid the boot disks.  This would allow us to recover fb0 in a few hours, rather than having to wait for someone to come in and fix it.

  711   Fri Mar 26 17:05:43 2010 MottLaserISSfb0 error

 

 I am still working on fb0, but for now I put fb1 in the DMZ of the router so we can ssh into the lab network.

I created a CentOS minimal liveCD and was able to rebuild the initrd files, but this did not fix the problem.  Based on this, I think it is more likely a filesystem error than a ramdisk error.  I tried to use the CentOS 5.3 rescue mode, but it could not mount the system disks, which further supports the conclusion that this is a fs error.  fsck found multiple filesystem errors which I fixed, but this did not fix the booting problem.  I think at this point we are going to have to wait for Alex to be back next week, because I am fresh out of ideas to fix the system.  If I get any flashes of insight over the weekend I will come in and give it a shot, but otherwise hopefully Alex can fix it.

  710   Thu Mar 25 14:16:32 2010 DmassLaserISSMZ Spectra!

This is the phase noise of the locked Mach Zehnder.

There is no subtraction, but since it is locked, any actual phase we could subtract should be supressed by the loop feeding back to the MZ PZT (single pole @ 1 Hz with a UGF somewhere around 20)

I am plotting the difference of the green PDs, and the difference of the IR PDs (they are in loop for the Mach Zehnder)

  • Green: [min,max] = [-4.7,7.2]
  • IR: [min,max] = [-8,8.5]   
  • Green DC = -1.36
  • IR DC = 2.84

Calibration is:

dV/dthet = Vpp/2*sqrt(1-(2V/Vpp)^2)

Notes:

  • I think we didn't realign the Mach Zehnder PZT after connecting the driver, which tosses 150V offset onto the PZT - I don't know if this could effect our contrast (if its a pointing change)
  • I think the large offset in green means that we have a PD imbalance, I have to think about this. If this is the case, I'll toss some balancing amplifier with a POT after the transimpedance amps to make the signals equal amplitude.
  • We are operating off fringe for both Green and IR, the point is somewhat abritrarily chosen for now, though I can conceivably make a more intelligent decision about this later.
Attachment 1: rawdata.zip
Attachment 2: LockedPhaseNoise.pdf
LockedPhaseNoise.pdf
  709   Thu Mar 25 13:29:18 2010 DmassLaserISSISS Spectra

Quote:

As far as I remember, 100uV/rtHz@10Hz & ~20urad/rtHz.

Quote:

Saw a noise of 100 mV/rtHz at 10 Hz, which corresponds to ~20 mrad/rtHz at 10 Hz. This is about a factor of 5 improvement over the previous result, with no subtraction yet.

 

 

This is correct, I sleepily entered the wrong "m" unit

  708   Thu Mar 25 12:40:28 2010 AlastairThings to BuyGeneralShoe covers on order - should be here in about 2 days

 Also ordered some solid core wire from Jameco and a couple of solderless breadboards.

  707   Thu Mar 25 10:38:24 2010 mevansLaserISSISS Spectra

Quote:

As far as I remember, 100uV/rtHz@10Hz & ~20urad/rtHz.

Some conversions:

  • displacement noise of the MZ = 20urad/rtHz  * (532 nm / 6 rad) ~ 2 pm / rtHz
  • relative frequency noise = 20urad/rtHz * 10 Hz ~ 200 uHz / rtHz
  • length noise for aLIGO arm  dL = 4e3 m * 2e-5 Hz/rtHz / 6e14 Hz ~ 1e-16 m / rtHz
  706   Thu Mar 25 02:38:54 2010 KojiLaserISSISS Spectra

As far as I remember, 100uV/rtHz@10Hz & ~20urad/rtHz.

Quote:

Saw a noise of 100 mV/rtHz at 10 Hz, which corresponds to ~20 mrad/rtHz at 10 Hz. This is about a factor of 5 improvement over the previous result, with no subtraction yet.

 

  705   Thu Mar 25 02:06:53 2010 DmassLaserISSISS Spectra

Hartmut, Koji, and Matt came to party with me downstairs. I am tired so the plots and pix will follow at a later date...

We

  • Locked the PMC in analog with an SR560
  • Locked the Mach Zehnder with a PZT I had made up forever ago, using the spare output from the ISS drive box (with the IR PD difference signal)
  • Changed the ISS to supress noise in the MZ PD sum output

and

  • Saw a noise of 100 uV/rtHz at 10 Hz, which corresponds to ~20 urad/rtHz at 10 Hz. This is about a factor of 5 improvement over the previous result, with no subtraction yet.

Huzzah.

  704   Wed Mar 24 22:12:49 2010 MottLaserISSfb0 error

 

 It looks like fb0 won't be back up tonight.  I think the error we are getting is related to an invalid inetrd file, which needs to be reconstructed using a CentOS 5.3 install/rescue disk.  Unfortunately, there don't appear to be any 5.3 liveCDs floating around the lab or on the internet (which I find somewhat odd), so we will have to wait until Alex is in and ask him.  I tried to rebuild the inetrd with a generic linux rescue disk, but wasn't able to (I couldn't chroot properly because the architecture of the disk and the system were different, and without being chroot'ed, I couldn't figure out how to make mkinetrd run).  bad RAM can sometimes cause a kernel panic, but I memtested and all the tests passed, so this is probably OK.

One odd thing is that I cannot boot the system to an ubuntu live cd.  The splash screen comes up, but when I try to select the interactive environment it stalls.  I will try it one more time, but this might also be a clue to what our problem is.

  703   Wed Mar 24 20:09:49 2010 Zach & AlastairLaserGYROnoise/signal diagram

 Alastair and I have been doing some thinking about servo loops, noise and readout schemes. Below is a simple servo diagram which highlights (most of) the important players.

servo_diagram.png

Blocks:

P (plant): The cavity response in W/Hz (this contains the mixer demod and LPF implicitly). Really, P1 = P2.

D (diode): PD response in V/W. P and D are split up in this case so that we can add in shot noise in watts between them. Ideally, D1 = D2.

F (filter): the PDH box gains in V/V

A (actuator): the gains of the laser PZT (1) and AOM (2) in Hz/V.

 

Inputs:

δL: Laser frequency noise in Hz. This includes noise in the laser itself as well as mechanical noise in the beam path before the beamsplitter. Common to both loops.

δ1,2: Frequency noise imparted by mechanical effects between the beamsplitter and the cavity input mirror in the CCW and CW paths, respectively. Includes VCO frequency noise for CW beam. This noise is differential.

δc: Cavity noise from mirror motion in Hz. Common mode.

S: Unidirectional Sagnac frequency shift. Anti-common mode in the sense that its value in one loop is opposite that in the other. This is added in with δc because it is manifest as an apparent cavity length change.

SN1,2: Shot noise on REFL photodiodes in W. Differential.

 

Signals:

δV1,2: Error signals input into the PDH boxes. The loops act to minimize these.

ER: The gyro signal in the reflection sensing scheme, which is just the actuation signal to the AOM.

ET: Gyro signal in the transmission sensing scheme. Mixer shown represents optical demod, have to include phaselock loop for electrical demod and frequency shift readout… working on this.

 

Conclusions that can be drawn so far:

ER is easy to read out, but contains extra noise. The signal fed from the CCW loop to the CW loop (this is just the laser PZT acting on the common laser) suppresses δL and δc, and it adds half the total Sagnac signal, S. However, it also imparts the shot noise of REFL CCW (SN1) and the CCW precavity frequency noise δ1. This means that ER is proportional to [2S + δ2 - δ1 + (1/P2)(SN2 - SN1)], that is, signal + differential precavity noise + differential shot noise suppressed by the cavity finesse.

In the transmission sensing scheme, the optical signals are combined after they have interacted with the input optics, and their differential noise is suppressed by the CW loop gain. They contain the frequency fluctuations required to stay matched to the cavity (-δc), but this noise is common mode and is rejected by the CMRR of the transmission demod. The only noise in the transmission scheme is thus the REFL shot noise suppressed by the cavity finesse as well as any other frequency noise occurring after the cavity mirrors (vibrations in the MZ, noise in the PLL VCO, and shot noise on the TRANS PDs, which is suppressed by a factor of f). If these can be attenuated to better than the junk at the input side, then we're better off in transmission.

 

Other notes: There is an additional nose source from phase modulation of the REFL signal (beat between leakage beam and SBs) caused by the mirrors on the way back through the faradays. These come in where SN does. Assuming small δϕ (which we can do because the mirrors are only moving a very small fraction of the beat wavelength), the resultant power fluctuation is second order in δϕ. Numbers coming soon but we think this can be ignored.

 

As far as the physical experiment is concerned, our next step is to monitor δV1 and adjust the CCW loop to minimize noise therein. The quieter this is, the better the common mode rejection. Then we can worry about gyro signals and sensitivity curves.


 

  702   Wed Mar 24 00:09:39 2010 DmassLaserISSISS Spectra

Mott and I are trying to repair the drive that's in there. Alex is home, and I guess the spare HD is sitting on his desk. Zach has emailed Alex about the spare drive, and I presume we want to have him go ahead and make a nice backup.

Mott and I will try to get a WORKING version of the frontend checking in to some repository, so in the future we can close the loop without Alex.

fb1 and ws2 are running Centos 5.3, kernel 2.6.18-(164?)

fb0 was trying to run 2.6.16 and failing.

we tried booting in one of the older 2.6.18 kernels, but it got to "kernel panic" state.

Does anyone know why we were running 2.6.16 on fb0? If we can't get 2.6.18 to work I will email Alex this question

  701   Tue Mar 23 21:24:57 2010 DmassLaserISSISS Spectra

FB0 hard crashed at some point last night or this morning. We put fb0 back in its home @ the bottom of hte rack (it was just sitting on the floor) since we had to give it a nice hard shutdown anyways.

I tried booting it several times, having to hold the power off button to shutdown then press it again each time, since it never got to a point where I could do anything with it.

It is currently stuck on:

Decompressing Linux...done
booting the kernel

Other times it got to "Kernel Panic...".

I think we need to Alex a new drive

  700   Tue Mar 23 21:05:45 2010 FrankLab InfrastructureGenerallaser safety sign replacement bulbs

i bought some of the laser safety sign replacement lamps ( 2-pin fluorescent lamp) as we were short of those (-1 already :-) ). As they are for all the signs inside and outside of the labs (TCS, ATF, PSL, CRYO) i,ve put them on top of the router/switch in the change room for easier access. If we are short again plz let me know to order more. Lifetime is ~ 8000-10000h (~1 year).

  699   Tue Mar 23 17:05:11 2010 DmassLaserISSISS Spectra

Quote:

On Hartmut's suggestion, I have tested my subtraction algorithm.

  • I took the raw spectra of on of the IR PDs (PD3).
  • I generated two white time series via MATLAB's "rand" function at a level of several below the "signal floor" of this spectrum
  • I added this to the PD3 time series to generate the
  • I subtracted one noisy time series from the other.
  • I recovered the subtraction I expect from the noise levels, and this is consistent with the predicted subtraction based on the coherence

I have shorted the green PDs together after the transimpedance amplifier, and the IR PDs together before the buffer I made (after the ISS PD box). I will check if the problem is upstream of the ADC next, since the subtraction works. Hopefully I find some electronics shenanigans, and won't be able to subtract the two identical PD spectra

 Currently waiting for FB0 to successfully restart, so far it has said it failed to mount something, then read "Kernel Panic..." and not gotten farther. This seems not good.

  698   Tue Mar 23 15:01:29 2010 DmassLaserISSISS Spectra

On Hartmut's suggestion, I have tested my subtraction algorithm.

  • I took the raw spectra of on of the IR PDs (PD3).
  • I generated two white time series via MATLAB's "rand" function at a level of several below the "signal floor" of this spectrum
  • I added this to the PD3 time series to generate the
  • I subtracted one noisy time series from the other.
  • I recovered the subtraction I expect from the noise levels, and this is consistent with the predicted subtraction based on the coherence

I have shorted the green PDs together after the transimpedance amplifier, and the IR PDs together before the buffer I made (after the ISS PD box). I will check if the problem is upstream of the ADC next, since the subtraction works. Hopefully I find some electronics shenanigans, and won't be able to subtract the two identical PD spectra

Attachment 1: SubtractTestCoh.pdf
SubtractTestCoh.pdf
Attachment 2: SubtractTest.pdf
SubtractTest.pdf
  697   Tue Mar 23 10:41:58 2010 AlastairLaserGYRONotch filter

Err, yes that is what I meant.  The filter is at 24.79kHz and the peak frequency of the resonance that we are seeing is at 24.8kHz.

Quote:

Sweet. You do mean 24.8 kHz, right? Be down in a second.

Quote:

I put together a notch filter to help with the 25kHz resonance that we have.  I checked the exact frequency from a spectrum we had taken and it is at 2.48kHz.  I built an active twin-T type of filter as shown, with the following component values:

C= 2.188nF (I matched the capacitors when doing this and got them to around 0.2%)

R=2933 ohm (also matched resistors to around 0.1%)

The amplifier is an OP27 at the moment, and there are 12volt regulators for both power rails.

I've attached a spectrum of the response.  The notch frequency is 2.479kHz, and we get around 24dB attenuation.  The bandwidth is about 1.6kHz at the moment but we can set this with a preset in the filter (this will alter the gain at the same time though as the two are linked).

 

 

  696   Tue Mar 23 10:32:46 2010 ZachLaserGYRONotch filter

Sweet. You do mean 24.8 kHz, right? Be down in a second.

Quote:

I put together a notch filter to help with the 25kHz resonance that we have.  I checked the exact frequency from a spectrum we had taken and it is at 2.48kHz.  I built an active twin-T type of filter as shown, with the following component values:

C= 2.188nF (I matched the capacitors when doing this and got them to around 0.2%)

R=2933 ohm (also matched resistors to around 0.1%)

The amplifier is an OP27 at the moment, and there are 12volt regulators for both power rails.

I've attached a spectrum of the response.  The notch frequency is 2.479kHz, and we get around 24dB attenuation.  The bandwidth is about 1.6kHz at the moment but we can set this with a preset in the filter (this will alter the gain at the same time though as the two are linked).

 

  695   Tue Mar 23 10:22:31 2010 AlastairLaserGYRONotch filter

I put together a notch filter to help with the 25kHz resonance that we have.  I checked the exact frequency from a spectrum we had taken and it is at 2.48kHz.  I built an active twin-T type of filter as shown, with the following component values:

C= 2.188nF (I matched the capacitors when doing this and got them to around 0.2%)

R=2933 ohm (also matched resistors to around 0.1%)

The amplifier is an OP27 at the moment, and there are 12volt regulators for both power rails.

I've attached a spectrum of the response.  The notch frequency is 2.479kHz, and we get around 24dB attenuation.  The bandwidth is about 1.6kHz at the moment but we can set this with a preset in the filter (this will alter the gain at the same time though as the two are linked).

Attachment 1: active_twin_t.png
active_twin_t.png
Attachment 2: notchfilter.jpg
notchfilter.jpg
  694   Tue Mar 23 10:22:30 2010 ZachLaserGYROlooking in the wrong place?

That's weird; I tried two different disks and go the same error. Oh well, glad it's working now.

Quote:

Quote:

 Alastair started playing with some notch filter ideas today while I sorted some stupid government 633-nm tape. When I got back, I figured I would try to play with the current servo setup to make the lock more robust and to try and minimize the low-frequency noise.

The thought occurred to me while I was adjusting the AOM loop gain and looking at the change to the PSD of the error signal that perhaps we're not really looking where we ought to. We converted voltage noise to equvalent angular velocity noise using an estimated VCO gain ([Hz/V]) and the usual formula for Hz --> rad/s, but it seems to me that this assumes something about the way in which the loop is operating. The reason this came to mind is that I saw nearly no change in the low-frequency (DC - ~ 100 Hz) spectrum of the error signal while cranking the gain of the servo from 0 to 10 and back, though it was clear that the AOM loop lock was better with higher gain (up to the oscillation point).

I think a more unambiguous way to measure the noise in the signal (short of setting up the full demod at the output) is to AC couple the TRANS_CW (AOM) PD and look at the noise there. Sure enough, when I did this I saw appreciable differences in the spectrum with different gain settings. I was ready to do a systematic set of trials with different combinations of gain level and boost on both blueboxes when the SR785 told me it doesn't like reading floppies anymore.

Will retry in the morning with another analyzer. I am also working on a Simulink model of the full scheme so that we can decide on what changes to make where.

(of course, we won't be able to do very well at all until we get the notch(es) in place to take out the PZT resonance @ 25kHz, and my suspicion is that we will have to do the same for the AOM path, which seems to have problems closer to 4-5 kHz, but I think it's worthwhile to play around a bit in the meantime)

The SR785 was just pissed at that particular floppy.  I reformatted it and it works okay now.  Also the file setting for the 'print screen' button was set to something weird.  I had to go into some deep dark menu to alter this to being an ASCII dump.  All working now.

ps.  I hope you didn't have anything on that floppy.....  I tried it in a disk drive also and it wouldn't read till I formatted it.

 

  693   Tue Mar 23 10:10:20 2010 AlastairLaserGYROlooking in the wrong place?

Quote:

 Alastair started playing with some notch filter ideas today while I sorted some stupid government 633-nm tape. When I got back, I figured I would try to play with the current servo setup to make the lock more robust and to try and minimize the low-frequency noise.

The thought occurred to me while I was adjusting the AOM loop gain and looking at the change to the PSD of the error signal that perhaps we're not really looking where we ought to. We converted voltage noise to equvalent angular velocity noise using an estimated VCO gain ([Hz/V]) and the usual formula for Hz --> rad/s, but it seems to me that this assumes something about the way in which the loop is operating. The reason this came to mind is that I saw nearly no change in the low-frequency (DC - ~ 100 Hz) spectrum of the error signal while cranking the gain of the servo from 0 to 10 and back, though it was clear that the AOM loop lock was better with higher gain (up to the oscillation point).

I think a more unambiguous way to measure the noise in the signal (short of setting up the full demod at the output) is to AC couple the TRANS_CW (AOM) PD and look at the noise there. Sure enough, when I did this I saw appreciable differences in the spectrum with different gain settings. I was ready to do a systematic set of trials with different combinations of gain level and boost on both blueboxes when the SR785 told me it doesn't like reading floppies anymore.

Will retry in the morning with another analyzer. I am also working on a Simulink model of the full scheme so that we can decide on what changes to make where.

(of course, we won't be able to do very well at all until we get the notch(es) in place to take out the PZT resonance @ 25kHz, and my suspicion is that we will have to do the same for the AOM path, which seems to have problems closer to 4-5 kHz, but I think it's worthwhile to play around a bit in the meantime)

The SR785 was just pissed at that particular floppy.  I reformatted it and it works okay now.  Also the file setting for the 'print screen' button was set to something weird.  I had to go into some deep dark menu to alter this to being an ASCII dump.  All working now.

ps.  I hope you didn't have anything on that floppy.....  I tried it in a disk drive also and it wouldn't read till I formatted it.

 

ELOG V3.1.3-