[Joe, Kiwamu]

We modified the activateDAQ.py script which lives in /opt/rtcds/caltech/c1/chans/daq/ and updates the C1SUS.ini, C1MCS.ini, C1RMS.ini, C1SCX.ini and C1SCY.ini files.  These files contain the DAQ channels for all the optics.

It has been modified so that channels like C1:SUS-ITMX_ULSEN_OUT_DAQ become C1:SUS-ITMX_SENSOR_UL.  Similarly the oplev signals go from C1:SUS-ITMX_OLPIT_OUT to C1:SUS-ITMX_OPLEV_PERROR.

After some debugging, we ran the script successfully and checked the output was correct.  We then restarted the frame builder (telnet fb 8088 and then shutdown) and also hit the DAQ reload button for all the front ends.

I tested in dataviewer that I could go back several years as well as going back just 1 hour in the history and see data for C1:SUS-ITMX_SENSOR_LL as well as C1:SUS-ITMX_OPLEV_YERROR.  I also tested realtime is also working for these channels.

The contents of the script are below.

inputfiles=["C1SUS.ini","C1RMS.ini","C1MCS.ini","C1SCX.ini","C1SCY.ini"]
prefix="[C1:SUS-"
optics=["BS_","ITMX_","ITMY_","PRM_","SRM_","MC1_","MC1_","MC2_","MC3_","ETMX_"]
#channels=["SUSPOS_IN1","SUSPIT_IN1","SUSYAW_IN1","SUSSIDE_IN1","ULSEN_OUT","URSEN_OUT","LRSEN_OUT","LLSEN_OUT","SDSEN_OUT","OL_SUM_IN1","OLPIT_IN1","OLYAW_IN1"]
channels_dict = {'SUSPOS_IN1':'SUSPOS_IN1_DAQ',
'SUSPIT_IN1':'SUSPIT_IN1_DAQ',
'SUSYAW_IN1':'SUSYAW_IN1_DAQ',
'SUSSIDE_IN1':'SUSSIDE_IN1_DAQ',
'ULSEN_OUT':'SENSOR_UL',
'URSEN_OUT':'SENSOR_UR',
'LRSEN_OUT':'SENSOR_LR',
'LLSEN_OUT':'SENSOR_LL',
'SDSEN_OUT':'SENSOR_SIDE',
'OLPIT_OUT':'OPLEV_PERROR',
'OLYAW_OUT':'OPLEV_YERROR',
'OL_SUM_OUT':'OPLEV_SUM'}

suffix="_DAQ]\n"

## set datarate
datarate=2048

## read the ini files
for inputfile in inputfiles:
    print inputfile
    outputfile=inputfile
    ifile = open(inputfile,'r')
    lines = ifile.readlines()
    ifile.close()

    for k in range(len(lines)):
        for op in optics:
            for ch in channels_dict:
                if (prefix+op+ch+suffix) in lines[k]:
                    lines[k]=prefix + op + channels_dict[ch] + "]\n"
                    lines[k+1]=lines[k+1].lstrip("#").rstrip(lines[k+1].split("=")[1])+"1\n"
                    lines[k+2]=lines[k+2].lstrip("#")
                    lines[k+3]=lines[k+3].lstrip("#").rstrip(lines[k+3].split("=")[1])+str(datarate)+"\n"
                    lines[k+4]=lines[k+4].lstrip("#")
    ofile = open(outputfile,'w')
    for k in range(len(lines)):
        ofile.write(lines[k])
        #print lines[k]
    ofile.close()


I created two simple cron jobs, one running on linux1 and one running on nodus, to produce an updated copy of the martian host table linkable from the wiki every day.

The scripts live in /opt/rtcds/caltech/c1/scripts/AutoUpdate/.  One is called  updateHostTable.cron and run on linux1 everyday at 4 am, and the other is called moveHostTable.cron which is run on nodus everyday at 5am.

The new link has been added to the Martian Host table wiki page  here.

I wrote a new script that is in /opt/rtcds/caltech/c1/scripts/AutoUpdate/ called  webview_simlink_update.m. 

This m-file when run in matlab will go to the /opt/rtcds/caltech/c1/target directory and for each c1 front end, generate the corresponding webview files for that system and place them in the AutoUpdate directory. 

Afterwards the files can be moved on Nodus to the /users/public_html/FE/ directory with:

mv /opt/rtcds/caltech/c1/scripts/AutoUpdate/*slwebview* /users/public_html/FE/

This was run today, and the files can be viewed at:

https://nodus.ligo.caltech.edu:30889/FE/

Long term, I'd like to figure out a way of automating this to produce automatically updated screens without having to run it manually.  However, simulink seems to stubbornly require an X window to work.

[Rana, Jenne, Suresh]

Yesterday, We replaced the existing beam steering mirror and the PZT it was mounted on with a Gooch and Housego mirror (20ppm transmission at < 30deg incidence @1064nm) and a Polaris-K1 Newport steel mount. (JD)

We realigned the G&H mirror to get the MC flashing. 

We then had to reduce the gain in the servo circuit to accommodate the increased optical power going into MC. 

MC locked to PSL once again.

Note: 

      the old mirror stuck on the PZT has been removed.  The mirror had no markings and has been stored in the 'Unknown Optics' Box along the East Arm.

      The PZT has been stored in the PZT cabinet along with its 2in mirror mount.

[Larisa and Jenne]

We wanted to get rid of the awkward cart that was sitting behind the 1Y1 rack.  This cart was supplying a +5V offset to the PZT driver, so that we could use the MC length signal to feedback to lock the laser to the MC cavity.  Instead, we put the offset on the last op amp before the servo out on the Mc Servo Board.  Because we wanted +5V, but the board only had +5, +15, -15V as options, and we needed -5 to add just before the op amp (U40 in the schematic), because the op amp is using regular negative feedback, we made a little voltage divider between -15V and GND, to give ourselves -5V.  We used the back side of the voltage test points (where you can check to make sure that you're actually getting DC voltage on the board), and used a 511Ohm and 1.02kOhm resistor as a voltage divider. 

Then we put a 3.32kOhm resistor in ~"parallel" to R124, which is the usual resistor just before the negative input of the op amp.  Our -5V goes to our new resistor, and should, at the output, give us a +5V offset. 

Sadly, when we measure the actual output we get, it's only +2.3V.  Sadface.

We went ahead and plugged the servo out into the PZT driver anyway, since we had previously seen that the fluctuation when the mode cleaner is locked was much less than a volt, so we won't run into any problems with the PZT driver running into the lower limit (it only goes 0-10V).

Suresh has discovered that the op amp that we're looking at, U40 on the schematic, is an AD829, which has an input impedance of a measely 13kOhm.  So maybe the 3.32kOhm resistors that we are using (because that's what had already been there) are too large.  Perhaps tomorrow I'll switch all 3 resistors (R119, R124, and our new one) to something more like 1kOhm.  But right now, the MC is locked, and I'm super hungry, and it's time for some arm locking action.

I've attached the schematic.  The stuff that we fitzed with was all on page 8.

Today I have made the CCD Cable Upgrade Plan for improvement of sysmtem.

I have ~60 VIDEO cables to be worked for upgrades so I would like to ask all of your favor in helping me of replacing cables.

1. Background

Currently, VIDEO system is not working as we desire.

About 20 cables are of impedance of 50 or 52 ohm which is not matched with the whole VIDEO system.

Moreover, some cameras and monitors are out of connection.

2. What I have worked so far.

I have checked impedance of all cables so I figured out which cables can be used or should be replaced.

I measured cables' pathes along the side tray so that we can share which cable is installed along which path.

I have made almost of cables necessary for VIDEO system upgrades but no label is attached so far.

3. Upgrade plan (More details are shown in attached file)

4. This is a kind of  a first draft of the plan.

Any comment for the better plan is always welcome.

Moreover, replacing all the cables indicated in the files is of great amount of work.

I would like to ask all of your favors in helping me to replace the cables (from 1. to 2D. steps above).

I can not think of any reason that the input impedance of 13kOhm between the pos/neg inputs produces such a big change at the output. In any case, the differential voltage between the pos/neg inputs produces a big output. But the output was just 2V or so. This means that the neg input was actually about zero volt. This ensures the principle of the summing amplifier of this kind.

Because the input impedance of the summing node (the additional resister you put at the negative input) is not infinity, the voltage divider is not perfect and shows 10% reduction of the voltge (i.e. the output will have +4.5V offset instead of +5V). But still it is not enough to explain such a small output like 2.3V.

What I can think of is that the earlier stages somehow have the offset for some reason. Anyway, it is difficult to guess the true reason unless all of the nodes around the last stage are checked with the multimeters.

At least, we can remove the voltage divider and instead put a 10k between -15V and the neg input in order to impose +5V offset at the output. This costs 1.5mA instead of 10mA.

[Suresh, Kiwamu]

 We eventually succeeded in locking X arm with the infrared beam.

The PDH signal is taken at MCL's ADC instead of c1lsc's, and fedback to MC2_POS through the MCL path.

Right now the lock is not so stable for some reasons, so we need to investigate it more.

(what we did)

 - strung a long BNC cable to connect the demodulated signal and the ADC of c1ioo.

          We didn't touch anything on the demodulation system, so the setup for the demodulation is exactly the same as that of yesterday (see here).

 - disconnected the actual MCL cable from the ADC breakout board at 1X2 rack. And put the demodulated signal onto it.

 - checked the analog dewhitening filter state for the MC2 coil driver, found the analog filter are always off.

  So we just made simDW and invDW always on.

- changed the gain of the MCL loop to have a stable lock for the X arm.

    right now a reasonable setup in the MCL filters are:

         FM1:ON, FM10:ON, G=0.1

 - In fact the lock of the MC is not so stable compared to before, frequently an attempt of locking the X arm leads to the unlock of the MC.

[Rana, Kiwamu]

Here is the list for the daytime tasks of tomorrow, Jan. 12th.

The daytime task is a work basically to be done or quitted before the sun goes down.

Along with the tasks, we roughly assigned the people who are responsible for it.

The tasks below are basically separated from each other, so we can work in parallel.

--- 1.  LSC analog interface check (Joe/Koji)

   * check whitening filter

   * demodulation board check

    * check ADC connections

--- 2.  MC2 coil Dewhitening (Joe)

    * fix binary outputs.

    * FM9 must be the trigger of the binary outputs instead of FM10.

--- 3. 11MHz modulation depth (Kiwamu)

   * investigate why the depth is so low

--- 4. PEM DAQ name issue (Jenne)

   * change the name of seismic channels properly so that we can deal with the calibrated stuff

--- 5. phase adjustment for MC-PDH locking (Suresh)

--- 6. medm screens for C1LSC ()

    * make screens

[Koji, Suresh]

We wanted to check and make sure that the relative phase of the two inputs ( local oscillator and photodiode signal ) to the demod board is such that the Q output is maximised.   We displayed the I and  Q signals on the oscilloscope in XYmode with I along the X direction.  If Q is maximised (and therefore I is minimised) the oscillocope trace would be perfectly vertical since all the signal would be in Q and none in I. Initially we noted that the trace was slightly rotated to the CCW of the vertical and that a short cable was present in the PD input line.  Removing this rotated the trace CW and made it pretty much vertical.  The screen shot of the oscilloscope is below.

.

[josephb, osamu, kiwamu]

We worked over by the 1Y2 rack today, trying to debug why we didn't get any signal to the c1lsc ADC.

We turned off the power to the rack several times while examining cards, including the whitening filter board, AA board, and the REFL 33 demod board.  I will note, I incorrectly turned off power in the 1Y1 rack briefly. 

We noticed a small wire on the whitening filter board on the channel 5 path.  Rana suggested this was to part of a fix for the channels 4 and 5 having too much cross talk.  A trace was cut and this jumper added to fix that particular problem.

We confirmed would could pass signals through each individual channel on the AA and whitening filter boards.  When we put them back in, we did noticed a large offset when the inputs were not terminated.  After terminating all inputs, values at the ADC were reasonable, measuring on from 0 to about -20 counts.  We applied a 1 Hz, 0.1 Vpp signal and confirmed we saw the digital controls respond back with the correct sine wave.

We examined the REFL 33 demod board and confirmed it would work for demodulating 11 MHZ, although without tuning, the I and Q phases will not be exactly 90 degrees apart.

The REFL 33  I and Q outputs have been connected to the whitening board's 1 and 2 inputs, respectively.  Once Kiwamu  adds approriate LO and PD signals to the REFL 33 demod board he should be able to see the resulting I and Q signals digitally on the PD1 I and Q channels.

In an unrelated fix, we examined the suspensions screens, specifically the Dewhitening lights.  Turns out the lights were still looking at SW2 bit 7 instead of SW2 bit 5.  The actual front end models were using the correct bit (21 which corresponds to the 9th filter bank), so this was purely a display issue.  Tomorrow I'll take a look at the binary outputs and see why the analog filters aren't actually changing.

[Koji Suresh Kiwamu]

Suresh modified the MC board to have +5V offset at the output. (To be reported in the separated elog)

The MC lock has not been obtained at this point. An investigation revealed that there was very small (~5mVpp) PDH signal.

Kiwamu removed his triple resonant adapter and put the 50Ohm termination insted.
This restored the signal level normal although this changed the demodulation phase about 20deg.
We left the demodulation phase as it is because this is a temporary setup and the loss of the signal is not significant.

Now the MC is steadily locked with the single super boost.

I briefly checked the MC2 analog dewhitening filters.

It turned out that the switching of the dewhitening filters from epics worked correctly except for the UR path.

I couldn't get a healthy transfer function for the UR path probably because the UR monitor at the front panel on either the AI filter or the dewhitening filter maybe broken.

Need a check again.

[Koji, Suresh]

    We looked at the board and found that the resistor R119 (the feed back) is 1.65k instead of the 3.32k that was needed for unity gain.  The gain has been intentionally reduced to 0.5 so that output range would be close to the 0-10V that is required at the input range of the PZT driver which follows.   A note to this effect is already present in the D040180-B, page 8.

    The voltage divider with 1k and 0.5k provides 4.5V (ref Koji's note above) this provides 2.25V at the output due to the gain of 0.5.  To get to the original goal of introducing a 5V offset on the output, we introduced the modification shown in the  'D040180-B with 5V offset.pdf' uploaded below.  Please check page 8, the changes are marked in red.  We checked to make sure that the output is 5V when the input is disconnected. 

The PCB pics at the end are also attached.  The 4.99k resistor is glued onto the PCB with epoxy and placed as close to the opamp possible.

My goal this afternoon was to measure the quantum efficiency of the MC WFS.  In the process of doing this, I discovered that when I reverted a change in the MCWFS path (see elog 4107 re: this change), I had not checked the max power going to the WFS when the MC unlocks.

Current status:

MC locks (is locked now).  No light going to WFS at all (to prevent MC WFS french-fry action).  Quantum Efficiency measured.

The Full Story:

Power to WFS:

Rana asked me to check out the quantum efficiency of the WFS, so that we can consider using them for aLIGO.  This involves measuring the power incident on the PDs, and while doing so, I noticed that WFS1 had ~160mW incident and WFS2 had ~240mW incident while the mode cleaner was unlocked.  This is bad, since they should have a max of ~10mW ever.  Not that 200mW is going to destroy the PD immediately, but rather the current out, with the 100V bias that the WFS have, is a truckload of power, and the WFS were in fact getting pretty warm to the touch.  Not so good, if things start melting / failing due to extended exposure to too much heat.

The reason so much power was going to the WFS is that it looks like Yuta/Koji et. al., when trying to use the WFS as a MC1 oplev, changed out 2 of the beam splitters in the MC WFS / MC Refl path, not just one.  Or, we've just been crispy-frying our WFS for a long time.  Who knows?  If it is option A, then it wasn't elogged.  The elog 3878 re: BS changeout only mentions the change of one BS.

Since the MC Refl path has a little more than ~1W of power when the MC is unlocked, and the first BS (which was reverted in elog 4107) is a 10% reflector, so ~100mW goes to the MC Refl PD, and ~900mW goes to the MC WFS path.  In front of a Black Hole beam dump was sitting a BS1-33, so we were getting ~300mW reflected to be split between the 2 WFS, and ~600mW dumped.  The new plan is to put a W2 window in place of this BS1-33, so that we get hopefully something like 0.1% reflected toward the WFS, and everything else will be dumped.  I could not find a W2-45S (everything else is S, so this needs to be S as well).  I found a bunch of W2-0deg, and a few W2-45P.  Does anyone have a secret stash of W2-45S's???  To avoid any more excessive heat just in case, for tonight, I have just left out this mirror entirely, so the whole MC WFS beam is dumped in the Black Hole.  The WFS also have aluminum beam dumps in front of them to prevent light going in.  None of this affects the MC Refl path, so the MC can still lock nice and happily.

Quantum Efficiency Measurement:

I refer to Jamie's LHO elog for the equation governing quantum efficiency of photodiodes: LHO 2 Sept 2009

The information I gathered for each quadrant of each WFS was: [1] Power of light incident on PD (measured with the Ophir power meter), [2] Power of light reflected off the PD (since this light doesn't get absorbed, it's not part of the QE), and [3] the photo current output by the PD (To get this, I measured the voltage out of the DC path that is meant to go to EPICS, and backed out what the current is, based on the schematic, attached). 

I found a nifty 25 pin Dsub breakout board, that you can put in like a cable extension, and you can use clip doodles to look at any of the pins on the cable.  Since this was a PD activity, and I didn't want to die from the 100V bias, I covered all of the pins I wasn't going to use with electrical tape.  After turning down the 100V Kepco that supplies the WFS bias, I stuck the breakout board in the WFS.  Since I was able to measure the voltage at the output of the DC path, if you look at the schematic, I needed to divide this by 2 (to undo the 2nd op amp's gain of 2), and then convert to current using the 499 Ohm resistor, R66 in the 1st DC path.  

I did all 4 quadrants of WFS1 using a 532nm laser pointer, just to make sure that I had my measurement procedure under control, since silicon PDs are nice and sensitive to green.  I got an average QE of ~65% for green, which is not too far off the spec of 70% that Suresh found.

I then did all 8 WFS quadrants using the 1064nm CrystaLaser #2, and got an average QE of ~62% for 1064 (58% if I exclude 2 of the quadrants....see below).  Statistics, and whatever else is needed can wait for tomorrow.

Problem with 2 quadrants of WFS2?

While doing all of this, I noticed that quadrants 3 and 4 of WFS2 seem to be different than all the rest.  You can see this on the MEDM screens in that all 6 other quadrants, when there is no light, read about -0.2, whereas the 2 funny quadrants read positive values.  This might be okay, because they both respond to light, in some kind of proportion to the amount of light on them.  I ended up getting QE of ~72% for both of these quadrants, which doesn't make a whole lot of sense since the spec for green is 70%, and silicon is supposed to be less good for infrared than green.  Anyhow, we'll have to meditate on this.  We should also see if we have a trend, to check how long they have been funny.

Actually, I just found out that there are different flavors of 'YAG-444'.

There's a YAG-444AH and also a YAG-444-4AH. I'm not sure which one we have or even which is better. The diode's internal resistance is not listed.

They also say explicitly that he 'YAG Enhancement' is just using thicker Silicon. Since the absorption of 1064 nm light in Silicon is very small, most of the light just goes in and then comes back out without depositing much of the power.

After Rana pointed me to Yoichi's MEDM snapshot script, I learned how to use Xvfb, which is what Yoichi used to write screens without a real screen.  With this I wrote a new cron script, which I added to Mafalda's cron tab to be run once a day at 6am.

The script is called webview_update.cron and is in /opt/rtcds/caltech/c1/scripts/AutoUpdate/.

#!/bin/bash
DISPLAY=:6
export DISPLAY
#Check if Xvfb server is already running
pid=`ps -eaf|grep vfb | grep $DISPLAY | awk '{print $2}'`
if [ $pid ]; then
        echo "Xvfb already running [pid=${pid}]" >/dev/null
else
# Start Xvfb
echo "Starting Xvfb on $DISPLAY"
Xvfb $DISPLAY -screen 0 1600x1200x24 >&/dev/null &
fi
pid=$!
echo $pid > /opt/rtcds/caltech/c1/scripts/AutoUpdate/Xvfb.pid
sleep 3

#Running the matlab process
/cvs/cds/caltech/apps/linux/matlab/bin/matlab -display :6 -logfile /opt/rtcds/caltech/c1/scripts/AutoUpdate/webview.log -r webview_simlink_update

There was a problem with running the webview report generator in matlab on Mafalada.  It complained of not having a spare report generator license to use, even though the report generator was working before and after on other machines such as Rosalba.  So I moved the old 32 bit matlab directory from /cvs/cds/caltech/apps/Linux/matlab to /cvs/cds/caltech/apps/Linux/matlab_old.  I installed the latest R2010b matlab from IMSS in /cvs/cds/caltech/apps/Linux/matlab and this seems to have made the cron job work on Mafalda now.

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

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

The webview of the LSC model can be found here.

 [Koji, Kiwamu]

 We succeeded in locking the X arm with the C1LSC digital control.

As we did on the day before yesterday, the feedback signal goes to MCL (#4141), but this time the signal is transfered from C1LSC through the RFM.

 (key points) 

- checking the state of the analog whitening filters at C1LSC rack.

   We took the transfer function of them and found that they were always on regardless of the clicking any buttons on medm.

To cancel the filter shape of the whitening, we put an unWhitening filter so that these transfer functions becomes flat in total.

The whitening filter approximately has : pole:150Hz, pole:150Hz, zero:15Hz, zero:15Hz (although these numbers came from by our eye ball fitting)   

 - demodulation phase adjustment

   We performed the same measurement as that of Suresh and Koji did yesterday (#4143) to adjust the phase of the PDH demodulation.

By changing the cable length we roughly adjusted the I-phase to eventually ~10 deg, which is close enough to 0 deg.

(probably some more efforts should be made as a part of daytime tasks)

Note that we are currently using the REFL33 demodulation board for this purpose (#4144). The LO power we put is about 16dBm.

The angle between I and Q at 11MHz is actually almost 90 deg.

This fact has been confirmed by putting a sinusoidal signal with a slightly different frequency (~100Hz) from that of the LO onto the RF input.

 - attenuation of RF signal

  Since the PDH signal taken by C1LSC's ADC had been saturated somewhat, we introduced a ND filter of 10 on the photo diode to attenuate the RF signal.

As a result the amplitude of the PDH signal on dataviewer became more reasonable. No more saturations.

(some notes)

 unWhitening filter           pole:15Hz. pole:15Hz, zero:150Hz, zero:150Hz

 C1LSC_MC_FM1   pole:1kHz, zero:10Hz

 Gain in digital control       G ~ -1

measured UGF  ~  200-300 Hz

 measured RFM delay ~ 125 usec 

Here shows a plot of the expected open loop transfer function (TF) for the X arm locking.

I assume that the delay time of the digital system associated with the ADC/DAC and the digital filtering process is ~100 usec independently from the RFM delay according to Yuta's measurement (#3961).

Also I assume the MC2 pendulum has a pole at 1Hz with Q of ~5, and the X arm has its cavity pole at ~3kHz.

When the lock acquisition takes place, we used the red curve shown above in order to avoid a big DC feedback onto MC2.

Once the X arm became resonant at TEM00, we manually switched FM3 on, which is a boost filter containing a pole at  1Hz and a zero at 50Hz in order to suppress the residual motion below 1Hz.

The expected curve for the boosted state is drawn by the blue curve in the plot. 

With this open loop TF, the UGF can be realized only around 100-300 Hz due to the phase margin condition.

This expectation of the UGF is consistent with our measurement because we obtained the UGF around 200-300Hz.

In fact above 300Hz we observed that the control became unstable and started oscillating.

These are the next steps for a better operation of the arm locking. They are suitable for the day time activities

Reconfiguration of the X-End table

- End transmission power monitor (CDS model exists, need to configure the PD)

- IR steering mirror for the transmon

- Restore/align end green beam

- Relocate the end trans CCD

- Connect the video output cable for the X-end CRT monitor

LSC Whitening

- LSC Whitening binary IO connection

They are not urgent but also good things to do

MC servo characterization

- Error signal: frequency noise

- Loop characterization

Arm cavity characterization with cavity sweep

- Arm finesse for 1064nm and 532nm

- Arm FSR measurement with 1064 (and optionally with 532nm simultaneously)

- Arm g-factor for 1064nm and 532nm

My feeling was that the saturation was caused by the LSC whitening filter which was always on.
Once the LSC whitening filter is controlled from C1LSC, we would be able to remove the attenuator.

After getting some help from the Basler technical support, I was directed to the following ftp link:

ftp://Pylon4Linux-ro:h50UZgkl@ftp.baslerweb.com

I went to the pylon 2.1.0 directory and downloaded the pylon-2.1.0-1748-bininst-64.tar.bz2 file.  Inside of this tar file was another one called pylon-bininst-64.tar.bz2 (along with some other sample programs). I ran tar -jxf on pylon-bininst-64.tar.bz2 and placed the results into the /opt/pylon directory.  It produced a directory of includes, libraries and binaries there.

After playing around with the make files for several sample programs they provided, I finally have been able to compile  them.  At several places I had to have the make files point to /opt/pylon/lib64 rather than /opt/pylon/lib.  I'll be testing the camera with these programs on Monday.  I'd also like to see if this particular distribution will work on Centos machines.  There's some comments in one of the INSTALL help files suggesting packages needed for an install on Fedora 9, which may mean its possible to get this version working on the Centos machines.

 I'll be gone to Hanford site next week and come back to Caltech on 24th's week.

I setup a standalone RT system at the desk around circuit stock in the 40m.

Please leave this setup until I come back. I'll keep working when I come back.

 I summarized how we proceed our green locking in this month on the wiki.

Since step1 and 2 shown on the wiki are mostly done apparently, so we will move on to step 3-D and 3-E.

A short term target in the coming couple of days is to phase lock the VCO to the beat note.

I like this activateDAQ script, but someone (Jenne with Joe's help) still needs to add the PEM channels - we still cannot see any seismic trends.

Objective:

      We wish to study the coherence of the two NPROs i.e. PSL and the X-end-NPRO by locking both of them to the X-arm and then observing the green beat frequency fluctuations. 

What we did:

   a) locked the PSL to the X-arm as described in 4153

   b) locked the x-end-NPRO to the X-arm with a PDH lock to the reflected green from the ETMX

   c) Obtained the green beat signal with a spectrum analyser as described in 3771

Observations:

   Please see the attached screen shots from the spectrum analyser.   They are taken with different BW and sweep range settings.  They give a estimate of the width of the green beat signal and the range of the frequency fluctuations of the beat-note.

Estimates:

   a) width of the beat note is less than 6KHz if measured over time scales of a few milli seconds

   b) the frequency fluctuations of the beat note are about 100KHz over time scales longer than 100ms

Next Step:

    We wish to record the beat note frequency as a function of time in order to establish the stability over time scale of a day.

I installed NTPD on Megatron (its Ubuntu, so different from the CentOS workstations). Here's the terminal cap to show that its actually working:

megatron:/etc>sudo /etc/init.d/ntp restart
 * Stopping NTP server ntpd                                              [ OK ]
 * Starting NTP server ntpd                                              [ OK ]
megatron:/etc>/etc/init.d/ntp status
 * NTP server is running
megatron:/etc>ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 nodus.martian   204.123.2.72     2 u    7   64    1    0.217    3.833   0.001
 europium.canoni 193.79.237.14    2 u    6   64    1  155.354    3.241   0.001
megatron:/etc>date
Mon Jan 17 04:07:08 PST 2011

Along the way, I also updated the /etc/inet/ntp.conf file for nodus. It was using the USNO as a NTP server and I've pointed it to the Caltech NTP server as per the IMSS NTP page.

The Basler acA640-100gm is a power over ethernet camera.  It uses a power injector to supply power over an ethernet cable to the camera.  Once I got past some initial IP difficulties, the camera worked fine out of the box.

You need to set some environment variables first, so the code knows where its libraries are located.

setenv PYLON_ROOT /opt/pylon
setenv GENICAM_ROOT_V1_1 /opt/pylon
setenv GENICAM_CACHE /cvs/cds/caltech/users/josephb/xml_cache
setenv LD_LIBRARY_PATH /opt/pylon/lib64:$LD_LIBRARY_PATH

I then run the /opt/pylon/bin/PylonViewerApp

Notes on IP:

Initially, you need to set the computer connecting to the camera to an ip in the 169.254.0.XXX range.  I used 169.254.0.1 on megatron's eth1 ethernet connection.  I also set mtu to 9000.

You can then run the IpConfigurator in /opt/pylon/bin/ to change the camera IP as needed.

I used 50 mA to drive the laser diode. The light is split 50/50 between the DUT (Device Under Test) and the New Focus 1611 (1 GHz BW) diode used as the reference.

This measurement is the TF of DUT/(New Focus). The resonances are there, but clearly there's an issue with instability around 200 MHz. The setup is still powered up, so please be careful around the RFPD testing table (don't stomp around yank the cables out of the power supplies).

I looked at the RF Photodiode wiki that Alberto has started - most of the TF features are replicated there. Todo:

* Update the 'schematic' with a real schematic instead of the cartoon.

* Change the circuit to remove the resistor in the RF path.

* Add compensation to avoid the 200 MHz instability.

* Make sure to include opamp current noise in the noise model (it is the dominant noise source but has been left out in the noise estimation plot).

* Make the output into a true 50 Ohms.

The crane people are here. The Vertex chambers are covered with plastic. The PSL HEPAs will be running on high during the day.

It is going to be disturbingly noisy and dirty during the day. Please try start working in the evening if it can not wait till next week.

 [Kiwamu, Suresh]

Today we attempted to convert the beat-note frequency into an analog voltage using the SR620 frequency counter.

First an observation: the stability of the green beat was seen to be much better than the 100kHz fluctuation seen yesterday. Probably because Kiwamu noticed that one of the MC mirrors had a large variance in its motion and changed the  gain and filter parameters to decrease this.  The PSL was therefore more stable and the green peak fluctuation was less than 10kHz over time scales of a few seconds. 

SR620 D/A output resolution given by the manufacturer is 5mV over the -10 to +10V range and this range corresponding to 300MHz.  We, however saw fluctuations of 100mV on the screen which looked as if they corresponded to the  least significant bit.  This would imply a resolution of 1.5MHz at this range.   Even if the manufacturer's claim was true it would lead to a resolution of 75kHz, far in excess of the required resolution a few hundred Hz.

We therefore require to set up the VCO-PLL to obtain a finer frequency resolution.

In the mean time the green beat drifted beyond the 100MHz detection band of the green-PD.  So we changed the x-end-NPRO temperature by -0.05 to bring it back into the detection band.

We are also considering, Rana and Koji's suggestion of using a set of 14 flip-flops to divide the ~80MHz beat frequency so that it comes down to about 4kHz.  This could then be sampled by the usual 16-bit, 64kSa/s ADC cards and brought into the digital domain where further digital processing would be needed to extract the the required frequency variations  in the 0 to 10kHz band.  Found a nice paper on this object

I redid the optical POX transfer functions and updated the wiki at http://lhocds.ligo-wa.caltech.edu:8000/40m/Electronics/POX.

I measured each transfer function several times to calculate uncertainties for each measured point. There is one large transfer function from 1 MHz to 500 MHz showing a resonance peak at 11 MHz and notches at 22 MHz and 55 MHz. I also made more detailed measurements around each of these resonance peaks. These measurements were fit to a resonance curve to determine the resonant frequency, transimpedance at resonance, and Q for each peak. These measurements agree with the shot noise measurement for the transimpedance at 11 MHz taken earlier considering that this measurement was made at 11 MHz instead of at the resonant frequency of 11.14 MHz.

I measured these transfer functions with the Agilent 4395a using the netgpib.py script last week. I realized that when using this script to save multiple copies of the same measurement after setting up the instrument, the first and second measurements are saved but all measurements saved after are identical to the second measurement until the instrument is physically reset. This happens because the analyzer switches the trigger from continuous to hold after making a measurement using this script. Kiwamu said that the script can be modified to return the trigger to continuous after saving the data so that multiple measurements can be saved without being at the analyzer physically. I did not want to waste more time figuring out how to modify the script to do this so I used one of the netbooks and sat at the analyzer manually returning the trigger to continuous after each measurement.

Elog wasn't responding at around 10 am this morning.  I killed the elogd process, then used the restart script.

TF looks fine except for the large peak at around 200MHz which has been reported by Rana. The time series and the spectrum without the light are pathetic...

I still prefer to see the fit by LISO as the pole/zero fitting of LISO as the fit result is more physically understandable.
Anyone can ask me about the instruction how to use LISO

I guess Idc of 24mA would be just a mistake. It looks like ~0.2mA from the plot that sounds normal for the transimpedance of 2kOhm.

Question: What is the HWHM of the reesonance when you have f0 and Q.

 The value of I_dc was a mistake. The value should be 240 µA.

The widths of the resonance peaks are listed below the fits to each peak on the wiki.

Here is another trick for the DAQ setup when you add a DAQ channel associated with a new front end code.

 Once you finish setting up the things properly according to this wiki page (this page ), you have to go to 

      /cvs/cds/rtcds/caltech/c1/target/fb

and then edit the file called master. 

This file contains necessary path where fb should look at, for the daqd initialization.

Add your path associated with your new front end code on this file, for example:

        /opt/rtcds/caltech/c1/chans/daq/C1LSC.ini

       /opt/rtcds/caltech/c1/target/gds/param/tpchn_c1lsc.par

After editing the file, restart the daqd on fb by the usual commands:

             telnet fb 8088

             shutdown

[Koji, Kevin]

We fit the entire POX optical transfer function from 1 MHz to 500 MHz in LISO. The fit is on the wiki at http://lhocds.ligo-wa.caltech.edu:8000/40m/Electronics/POX. Using LISO's root fitting mode, we found that the transfer function has five poles and four zeros.

I will work on making plots of the residuals. This is difficult because by default, LISO does not calculate the fitting function at the frequencies of the data points themselves and I haven't figured out how to force it to do this yet.

 I found that c1scy was not running due to a daq initialization error.

 I couldn't figure out how to fix it, so I am leaving it to Joe.

 I connected the PLL signal to the ADC on c1ioo. 

So now we are able to take the data into the digital world, and will be able to feedback signals to the suspensions.

 The output signal from the VCO box goes to a black beakout board on 1X2 rack though a BNC cable.  

Then the signal comes out from the back side of the board with DB39 style, so I put a DB39 to SCSI adapter so that we can take it to the IO chasis.

Now the SCSI is connected to ADC_1 (the second ADC card) on the IO chasis at 1X1. 

  Additionally I modified the green locking simulink model, C1GCV, in order to pick the right ADC channels.

A medm screen for green locking is now under the construction. I put a link on the sitemap screen, so anyone can look at the half-baked green locking screen.

Any comments and suggestions are really welcome.

This is caused by an insufficient number of active DAQ channels in the C1SCY.ini file located in /opt/rtcds/caltech/c1/chans/daq/.  A quick look (grep -v # C1SCY.ini) indicates there are no active channels.  Experience tells me you need at least 2 active channels.

Taking a look at the activateDAQ.py script in the daq directory, it looks like the C1SCY.ini file is included, by the loop over optics is missing ETMY.  This caused the file to improperly updated when the activateDAQ.py script was run.  I have fixed the C1SCY.ini file (ran a modified version of the activate script on just C1SCY.ini).

I have restarted the c1scy front end using the startc1scy script and is currently working.

I realized that the black AA board I mentioned on the last entry has the same range issue as Valera reported before (see #3911). 

Basically our ADC card has +/- 10V input range, but on the other hand the AA board is already limited by approximately +/- 2V.

We have to fix it.

[Aidan, Kiwamu]

Kiwamu and I plugged the output from a DS3456 function generator into the ADC and started recording the data. The func. generator output a 237.8Hz, 1Vpp sine wave. We chose this value because it corresponds to the FSR of a 38.5m cavity (=3.896MHz) divided by 2^14, the frequency divider amount we intend to use.

Since 1 FSR divided down is 237.8Hz and corresponds to a length change of the cavity of 532nm/2 = 266nm, then we can, roughly, say that a frequency change of 1Hz corresponds to a length change in the cavity of approximately 1nm. The width of the 237.8Hz peak in the spectra corresponds to an upper limit on the noise floor due to digitizing the signal (this could be limited by the ADC, or the function generator, or the windowing on the FFT).

The FWHM of the peak in the spectrum was approximately 5mHz, corresponding to an uncertainty in the length of the cavity of about 6pm (we used a Hanning Window, 50% overlap and a BW of 2.92mHz, 7 averages). Regardless of what is the dominant contribution to the width of the peak, this implies that the frequency noise associated with digitizing a signal in the ADC is much smaller than we require and will not limit our performance if we choose to use a frequency divider and digital PLL with the Green Locking.

RA: Here's the previous measurement

If we use a digital PLL for locking the frequency of the PSL and END green lasers then we can expect a UGF of around 1kHz (assuming a sampling rate of 16kHz). Let's assume a simple 1/f loop giving a loop gain of ~1000x at 1Hz. If the free-swinging ETM pendulum motion at 1Hz is of the order of 1 micron, then the residual motion at 1Hz, once we lock the digital PLL by actuating on the ETM position, will be of the order of 1nm. This is bordering on too high.

Alternatively, is we use an analogue PLL then we can expect a much higher UGF and many orders of magnitude more gain at 1Hz (see here). So we would expect the residual motion of the pendulum to be much smaller - probably limited by some other noise source somewhere in the system (I doubt it's going to be reduced by 12 orders of magnitude).

RA: I think ballpark's not good enough for this. To see what's good enough, we need to to an analysis similar to what Bram has for the ALS. Get the 40m seismic spectrum from the arm locking spectrum or the green laser feedback signal and then correct it for a realistic loop shape.

KA: For this purpose I have made the simulink model for the green locking more than a year ago, but the entire green team has consistently neglected its presence...
https://nodus.ligo.caltech.edu:30889/svn/trunk/docs/upgrade08/Green_Locking/Servo_modeling/091121/

Since the 1U sized computers don't have enough slots to hold the host interface board, RFM card, and a dolphin card, we had to move the 2U computer from the end to middle to replace c1sus.

We're hoping this will reduce the time associated with reads off the RFM card compared to when its in the IO chassis.  Previous experience on c1ioo shows this change provides about a factor of 2 improvement, with 8 microseconds per read dropping to 4 microseconds per read, per this elog.

So the dolphin card was moved into the 2U chassis, as well as the RFM card.  I had to swap the PMC to PCI adapter on the RFM card since the one originally on it required an external power connection, which the computer doesn't provide.  So I swapped with one of the DAC cards in the c1sus IO chassis.

But then I forgot to hit submit on this elog entry..............

I found this old plot in an old elog entry of Osamu's (original link).

It gives us the differential displacement noise of the arms. This was made several months after we discovered how the STACIS made the low frequency noise bad, so I believe it is useful to use this to estimate the displacement noise of the arm cavity today. There are no significant seismic changes. The change of the suspension and the damping electronics may produce some changes around 1 Hz, but these will be dwarfed by the non-stationarity of the seismic noise.

 [Suresh, Kiwamu]

  We did the following things:

     - installed a 1/10 voltage divider such that the signal won't be saturated at the AA board (see here)

     - put a Ithaco preamplifier 1201 as a whitening filter

     - checked the entire beat detection system without using the real beat note

Here are some items to be done before the sun goes down tomorrow:

       - calibration of ADC and the interfaces including the voltage divider and the whitening filter.

     - fine matching of unwhitening filter at the digital side

         - PLL response measurement ( freq to voltage response ) over the frequency range of interest

         - plotting an well calibrated spectrum of the PLL output 

(whitening filter)

The Ithaco 1201 was setup to have a zero at 0 Hz and two poles at 0.1 Hz and 10 Hz in order to emphasize the signal over the frequency range of interest.

Around 1Hz it is supposed to have a gain of 1000. These settings have done by tweaking the knobs on the front panel of the Ithaco 1201.

In addition to that, we made an unwhitening filter in digital filter banks. This filter was designed to cancel the analog whitening filter.

(system check) 

 To check the entire beat detection system, we phase-locked the VCO to a Marconi running at 80 MHz, which is the center frequency of the VCO.

Then we imposed a frequency modulation on the Marconi to see if the signal is acquired to ADC successfully or not. It's quite healthy.

According to the spectra corrected by the unwhitening filter, we confirmed that the noise floor at 1Hz is order of 1Hz/sqrt Hz, which is already quite good.

Then we took several spectra while putting a modulation on the Marconi at a different frequency in each measurement.

The peak due to the artificial modulation essentially works as a calibration peak in the spectra.

So in this way we briefly checked the flatness of the response of the system in the frequency domain.

As a result we found that the response is not perfectly flat in the range of 0.05 - 30Hz, probably due to a mismatch of the combination of the whitening and unwhitening filters.

We will check it tomorrow.

 Agreed. It doesn't completely rule out the digital PLL. I'll check out Kiwamu's model.

[Joe, Koji]
Yesterday's CDS swap of c1sus and c1iscex left the interfometer in a bad state due to several issues.

The first being a need to actually power down the IO chassis completely (I eventually waited for a green LED to stop glowing and then plugged the power back in) when switching computers.  I also plugged and plugged the interface cable from the IO chassis and computer while powered down.  This let the computer actually see the IO chassis (previously the host interface card was glowing just red, no green lights).

Second, the former c1iscex computer and now new c1sus computer only has 6 CPUs, not 8 like most of the other front ends.  Because it was running 6 models (c1sus, c1mcs, c1rms, c1rfm, c1pem, c1x02) and 1 CPU needed to be reserved for the operating system, 2 models were not actually running (recycling mirrors and PEM).  This meant the recycling mirrors were left swinging uncontrolled.

To fix this I merged the c1rms model with the c1sus model.  The c1sus model now controls BS, ITMX, ITMY, PRM, SRM.  I merged the filter files in the /chans/ directory, and reactivated all the DAQ channels.  The master file for the fb in the /target/fb directory had all references to c1rms removed, and then the fb was restarted via "telnet fb 8088" and then "shutdown".

My final mistake was starting the work late in the day.

So the lesson for Joe is, don't start changes in the afternoon.

Koji has been helping me test the damping and confirm things are really running.  We were having some issues with some of the matrix values.  Unfortunately I had to add them by hand since the previous snapshots no longer work with the models.