What is the point to use the error instead of the feedback? It does not make sense to me.

If the cable is flaky why we don't solder it on the circuit? Why we don't put a buffer just after the test point?

It does not make sense to obtain the error signal in order to estimate the freeruning noise without the precise loop characterization.
(i.e. THE FEEDBACK LOOP TRINITY: Spectrum, Openloop, Calibration)

RA: I agree that feedback would be better because we could use it without much calibration. But the only difference between the "error signal" and the "feedback signal" in this case is a 1.6:40 pole:zero stage with DC gain of 0 dB. So we can't actually use either one without calibration and the gain between these two places is almost the same so they are both equally bad for the SNR of the measurement. I think that Suresh and Kiwamu are diligently reading about PLLs and will have a more quantitative result on Monday afternoon.

[Rana, Suresh, Kiwanu]

 We did the following things:

   *  taking the VCO stability data from the error signal instead of the feedback

   *  tried calibrating the signal but confused

   *  increased the modulation depth of the green end PDH.

--

 We found that a cable coming out from the VCO box was quite touchy. This cable was used for taking the feedback signal.

When we touched the cable it made a big noise in the feedback. So we decided to remove the cable and take the signal from the error point (i.e. just after the mixer and the LPF.)

In order to correct that signal to the one in terms of the feedback signal, we put a digital filter which is exactly the same as that of the PLL (pole at 1.5 Hz, zero at 40 Hz, G=1) .

However for some reasons the signal shown in the digital side looked completely mis-calibrated by ~ 100. We have no idea what is going on.

Anyway we are taking the data over tonight because we can correct the signal later. The 2nd round data started from AM1:40

Damn. If this figure is true, we were looking at wrong signal. We should look at the feedback signal to the VCO.

[Kiwamu, Suresh, Rana]

Our goal:

        We wished to determine the performance of the VCO PLL at low frequencies,. 

The procedure we followed:

        The scheme is to use the Marconi (locked to Rb Clock) as an 80MHz reference and lock to it using the PLL. 

        We set up the VCO PLL as in the diagram shown in the attachment and obtained the spectra shown below.

Results:

          We need to figure out the PLL servo gain profile in order to build the Inv PLL filter....

We've set up a beat note measurement between the VCO driver and the Marconi (see Suresh's elog).

Here's the 'unWhiten' filter for compensating the SR560 TF.

It has poles = 1 mHz, 5 kHz, 5 kHz

and  zeros = 30 mHz, 1 kHz

The gain is set to be ~0.001 in the 1-100 Hz band to compensate the G=1000 of the SR560.

The DAQ Wiki pages say to use port 8088 for restarting the Frame Builder. I tried this to no avail.

op440m:daq>telnet fb 8088
Trying 192.168.113.202...
Connected to fb.martian.
Escape character is '^]'.
^]
telnet> quit
Connection to fb.martian closed.
op440m:daq>telnet fb 8087
Trying 192.168.113.202...
Connected to fb.martian.
Escape character is '^]'.
daqd> shutdown
OK
Connection to fb.martian closed by foreign host.

Apparently, 8087 is the right port. Various elog entries from Joe and Kiwamu say 8087 or 8088. Not sure what's going on here.

After figuring this out, I activated the C1:GCV-XARM_COARSE_OUT_DAQ and C1:GCV-XARM_FINE_OUT_DAQ and set both of them to be recorded at 2048 Hz. We are loading filters and setting gains into these filter modules such that the OUT signals will be calibrated into Hz (that's why we used the OUT instead of the IN1 as there was last night).

The orientation of the Dolphin cards seems to be opposite on c1lsc and c1sus.  The wide part is on top on c1lsc and on the bottom on c1sus.  This means, the cable is plugged into the left Dolphin port on c1lsc and into the right Dolphin port on c1sus.  Otherwise you get a wierd state where you receive but not transmit.

[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.

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

 [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.

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.

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..............

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/

[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

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.

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 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.

 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.

[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.

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

 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.

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.

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

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.

 [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

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.

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 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 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.

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 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.

 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'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.

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.

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.

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

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.

 [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 

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.

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.

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

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.

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.

[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.

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 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.

[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]

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.

.

[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

[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.